企业官网建设流程全解析

这两年做 AI 应用的开发者，几乎都被同一个问题磨过头皮：模型的上下文到底该给多少？给少了它像个金鱼，聊两句就忘事；给多了它又像一座塞满杂物的仓库，翻找半天反而把真正有用的信息压在了最底下。我在去年底接手了一个内部知识库问答系统的重构，老板丢给我的需求只有四个字——“context-mode”，翻译过来就是“上下文模式”。就是这看起来轻飘飘的一个词，让我把上下文管理从“玄学”硬生生做成了“工程”。

这篇文章不打算讲那种浮在表面的概念科普，而是直接围绕 context-mode 这个模式设计展开：它到底在解决什么真实问题、核心参数怎么定、怎么落地成可维护的代码，以及我在线上环境里踩过的那些坑。无论你是在做聊天机器人、Agent 工作流，还是给传统 SaaS 加 AI 能力，这篇文章里的思路都能直接抄作业。

1. 先搞清楚：Context Mode 到底是解决什么问题

1.1 从“对话框”到“上下文系统”的失控

很多人对上下文的第一印象停留在“聊天记录越长越好”，这个直觉在 demo 阶段是成立的。你给模型塞十轮对话，它表现不错；再塞二十轮，好像也行。但一旦进入生产环境，场景从“陪聊”变成“回答基于某份 200 页技术手册的问题”之后，问题就全冒出来了。

我遇到过的最典型场景是：用户问“上次说的部署方案里，端口要改成多少”，如果只把最近的几条消息丢给模型，它根本没有“上次”的索引；但如果把整份操作手册、几十篇历史文档全塞进去，光是输入就有几十万 token，模型不仅慢，回答还会被无关信息带偏。

这里面的本质矛盾是：模型的上下文窗口是有限的资源，而业务需要的信息是海量的。context-mode 这个模式设计，本质上就是在回答一个问题——当信息放不下时，你选择放什么、不放什么、以什么顺序放。

1.2 Context Mode 不是玄学，是三个约束下的取舍

我后来把上下文管理总结成三个约束，所有设计决策都能归到这三条上：

• 长度约束：模型上下文窗口有上限，超了就报错或者截断，这是硬边界。
• 质量约束：塞入越多无关信息，模型越容易“分心”，回答精度反而下降。注意力机制不是无限的，相关性稀释是真实存在的退化现象。
• 成本约束：token 就是钱，也是延迟。每多塞一万 token，响应时间肉眼可见地变慢，账单也肉眼可见地变厚。

context-mode 的“模式”二字，就是在这些约束之间做显式的取舍。我常用的一个类比是：上下文管理不是自助餐，而是配餐制。自助餐想吃什么拿什么，最后盘子堆成山，真正吃下去的没几口；配餐制是根据你这顿饭的目标（回答什么）、你的胃口（窗口大小）、你的预算（成本），帮你把最有价值的那几样摆上桌。

我把常见的模式分成了四类，你可以直接对照自己的场景选：

这四种模式并不互斥，优秀的 context-mode 设计通常允许组合：比如“对话+检索”是最常见的基础形态，“对话+检索+记忆”则是进阶形态。

2. 核心设计拆解：一个可用的 Context Mode 应该长什么样

2.1 把“模式”翻译成作用域

模式这个词听起来抽象，落到工程上其实就是一个词：作用域。对话模式作用域是“当前会话”，检索模式作用域是“当前问题命中的文档片段”，记忆模式作用域是“该用户跨会话的长期画像”。

我在设计系统时，第一件事不是写代码，而是把整个业务信息画成一张分层地图：哪些是通用知识、哪些是团队内部文档、哪些是某个项目的动态状态、哪些是该用户独有的私人信息。然后给每一层定义一个独立的上下文来源。这样做的最大好处是，模式切换变成了一次“指向”操作，而不是一次“搬运”操作。

举个例子，我的系统里有个字段叫scope，它不是一个布尔值，而是一组来源标识：

{ "mode": "retrieval", "scope": ["team-wiki", "project-techdocs"], "user_profile": true, "recent_dialogue_turns": 6 }

这样一看就清楚：这个请求要从团队 wiki 和技术文档里检索内容，带上用户画像，并保留最近 6 轮对话。模式不再是产品经理嘴里含糊其辞的形容词，而是可配置、可记录、可回放的数据结构。

2.2 关键参数与默认值：把模糊的“上下文”量化成可调的数

光有作用域还不够，要让 context-mode 真正稳定运行，必须把感受变成参数。以下是我在项目里实际用下来的一组核心参数，附上了默认值和调整逻辑：

• 上下文预算（context_budget）：这是最上层的大闸。假设模型窗口是 32k token，我不会把 32k 全用满，而是预留 20% 给模型输出，再预留一部分给 system prompt 和少样本示例，剩下的才是可分配预算。实际公式是：available = window * 0.8 - system_prompt_len - few_shot_len。以 32k 窗口为例，system prompt 约 2k、few-shot 约 3k，那么可用上下文约32000*0.8 - 5000 = 20600token。
• 检索块大小（chunk_size）：单块 256~512 token 是我试验下来性价比最高的区间。太小的块语义不完整，太大的块噪声太多，512 是一个平衡点。
• 命中数量（top_k）：我通常设置为 8 到 12 块。别被搜索引擎的习惯带偏，以为返回越多越好。模型读 12 块优质内容，比读 50 块掺杂噪声的内容表现好得多。
• 相关度阈值（threshold）：余弦相似度低于 0.55 的检索结果直接丢弃。这个值可以配合 top_k 一起用：先按 top_k 粗筛，再按阈值精筛，两道关卡把无关内容挡在上下文门外。
• 时间衰减权重（recency_weight）：对话历史不是平等的。用户 10 分钟前说的“改成 8080 端口”比昨天说的“我们默认用 3000 端口”更重要。我在排序综合相关度时用了加权公式：final_score = sim * 0.7 + recency * 0.3，这个 0.7/0.3 的配比是我用几组测试集调出来的，效果比较稳，你可以当作起点再调。

这里有一个新手很容易忽略的点：参数必须可观测。每一个请求都应当能在日志里查出“这次用了哪种模式、检索了哪些块、各自的分数是多少、最终拼进去多少 token”。否则模式排障就是盲人摸象。

2.3 为什么“切换模式”比“自动全量塞入”更好

很多人会问：既然有这么多规则，能不能做个智能入口，让系统自动决定每次该用哪种模式？我的答案是：自动路由只能做兜底，显式的模式切换必须保留。

原因有三。第一，可解释性。用户问“你为什么用检索模式”，你能明确回答；如果是黑盒自动决策，出了问题你根本无从追起。第二，可控性。某些敏感场景必须强制使用全景模式，比如合规审计要基于全文生成报告，这时候自动路由把模式切到检索，漏了一个条款就是事故。第三，可调优。显式模式天然就是 A/B 测试的对照组，你可以在同样的用户、同样的问题下对比两种模式的效果，拿数据反哺排序模型。

所以我的做法是：产品层暴露一个模式切换器，默认自动，但允许用户手动指定；系统层记录每次选择，持续做效果归因。这既照顾了体验，又保住了工程底线。

3. 实操落地：从零搭建一个轻量级 Context Manager

3.1 数据模型设计：先定义“上下文块”和“上下文会话”

代码层面，我建议先抽象出两个核心数据结构。第一个是上下文块，代表一块不可再分的信息单元；第二个是上下文会话，代表一次请求最终拼装出来的上下文对象。

from dataclasses import dataclass, field from typing import Optional @dataclass class ContextChunk: """一块上下文，来源可能是文档、对话或用户画像""" chunk_id: str source_type: str # doc / dialogue / profile / system content: str token_len: int score: float = 0.0 # 综合相关度 timestamp: float = 0.0 # 用于时间衰减 @dataclass class ContextSession: """一次请求的上下文快照""" session_id: str mode: str system_prompt: str chunks: list[ContextChunk] = field(default_factory=list) total_tokens: int = 0 def to_messages(self): """按顺序拼装最终发给模型的消息列表""" messages = [{"role": "system", "content": self.system_prompt}] for c in self.chunks: messages.append({ "role": "system" if c.source_type in ("doc", "profile") else "user", "content": f"[{c.source_type}] {c.content}" }) return messages

这段代码的精髓在于，所有内容都规范成块，排序和截断都发生在块级别而不是字符级别。这样既方便做 token 精确控制，也方便做各种策略的插拔式替换。

3.2 核心函数实现：检索、排序、拼装、截断

接着是实现四个核心函数。第一个是检索召回，根据当前问题和作用域，从向量库里取出候选块；第二个是排序加权，把相关度和新鲜度合成一个分数，取 top_k；第三个是拼装截断，在预算之内把块按顺序填入上下文；第四个是兜底策略，超出预算时用摘要或滚动窗口降级处理。

def pack_context(query, mode, scope, history): # 1. 检索候选块：从向量库召回 candidates = retrieve(query, scope, top_k=30) # 2. 综合排序：相关度 + 时间衰减 for c in candidates: c.score = 0.7 * c.score + 0.3 * recency_penalty(c) candidates.sort(key=lambda x: x.score, reverse=True) candidates = [c for c in candidates if c.score >= 0.55][:12] # 3. 按预算拼装 budget = get_context_budget() # 之前算过的可用 token 数 session = ContextSession(session_id=gen_id(), mode=mode, system_prompt=get_system_prompt(mode)) used = token_len(session.system_prompt) for c in candidates: if used + c.token_len > budget: break session.chunks.append(c) used += c.token_len # 4. 截断对话历史：保留最近 N 轮 for turn in history[-6:]: if used + turn.token_len > budget: break session.chunks.append(turn) used += turn.token_len session.total_tokens = used return session.to_messages()

这里有个容易被忽略的坑：拼装顺序不是按时间排就行，而是按“重要度优先”排。知识库检索出来的关键块应当放在对话历史之前，因为模型对中部位置的注意力会衰减，两头的内容影响最大。我内部叫这个“三明治布局”——两头放最重要的信息，中间放辅助细节。

3.3 接入应用的方式与注意事项

Context Manager 不是一个独立服务常驻在那里就行，关键是接入点要选对。我推荐在 API 网关或请求路由层加一个拦截器，所有进出模型的请求都走同一套上下文拼装逻辑。这样做有三点好处：统一收口，避免各业务线自己拼上下文导致风格混乱；统一观测，每个请求的 token 消耗和模式选择都落在日志里；统一升级，排序算法迭代一次，全业务线同时生效。

接入时还有几个细节要特别留心。第一，不要把用户原始输入直接拼进 system prompt，这是注入风险高发区，用户内容一律走普通 user 消息。第二，预留输出预算永远是第一优先级，宁可少塞上下文，也不能把模型的回答空间挤没，否则会得到大量“半句话”输出。第三，模式切换要带用户确认回执，尤其是从窄模式切到宽模式时，提示用户“这次将检索 200 篇文档，可能增加 3 秒延迟”，让用户有预期，不然线上反馈会被延迟投诉淹没。

4. 常见问题与排查技巧实录

4.1 上下文漂移与污染：模型回答里冒出“不该知道”的内容

上线第一个月，我收到最多的人工反馈就是“模型怎么把 A 项目的方案答到 B 项目的问题里了”。查日志之后发现，检索阈值的相似度判断出了问题——两篇技术文档都提到了“容器化部署”这个通用词，余弦相似度都很高，系统就把 A 项目的内容当成了 B 项目的补充材料。

解决思路分两层。第一层是检索层加语义消歧：把业务线、项目代号作为过滤标签写进检索条件，而不是只靠向量相似度。第二层是上下文标注层：在为模型拼装内容时，给每块加一行前缀说明“以下内容来自 A 项目技术手册”，模型看到来源后会自动做归属判断，大幅减少串味现象。

这也让我总结出一条经验：上下文污染不是模型的问题，是信息路由的问题。排查时永远先看“这块内容该不该进来”，而不是抱怨模型不听话。

4.2 超限、截断与“沉默故障”：输出突然变短怎么办

有段时间用户反馈“回答越来越短，经常一句话就停”。起初我以为是模型抽风，后来一查 token 统计才发现，可用预算计算错了：我把模型输出的 20% 预留写成了固定值 4096，但当 system prompt 被运营同学悄悄加长到 8000 token 后，上下文实际可分配空间被挤压到不足 4000，模型读到一半内容就撞上输出预算，被迫“戛然而止”。

这类故障有个共同特征：系统不报错，只是默默退化。排查手段只有一个——全链路的 token 账单。我给每个请求都打印一条结构化日志，包含 system prompt 长度、各块长度、最终可用预算、实际使用量。一旦发现“实际使用量经常逼近预算上限”，就说明该优化了，而不是等用户来投诉。

4.3 场景速查表：现象、原因、对策

4.4 一个调试利器：模式回放

最后分享一个我私藏的调试方法——模式回放。每当用户报一个问题，我会把这次请求的所有上下文数据完整存下来：模式、作用域、查询改写、候选块分数、最终拼装结果、模型回复。然后可以在本地重新发一遍，微调某个参数再发一遍，对比两轮回复的差异。

这个方法的价值被远远低估了。没有回放能力，排查就是瞎猜；有了回放能力，每一次线上问题都能变成离线数据集，积累到一千条之后，你就可以做自动化的参数回归测试。到那个阶段，context-mode 就不是一个靠经验维护的功能，而是一个有测试集、有指标、有迭代流程的成熟模块了。

我个人的体会是，context-mode 这类设计的难点从来不在算法，而在“能不能量化”。只要你把每个选择都变成参数，把每个参数都变成日志，把每份日志都变成可回放的调试样本，再玄学的问题也会显出清晰的脉络。最后再分享一个小技巧：每次上线新模型版本，我会把同一组测试问题在四种模式下各跑一遍，把输出存成基线。模型升级不是测试替身，这个基线才是你的免死金牌——它能在一小时内告诉你新模型是升级还是灾难。