说起 context-mode我一直觉得这是个被低估的设计。很多人做 AI 应用模型换了一个又一个提示词调了一版又一版最后效果上不去问题往往不在模型本身而是上下文没有被真正管起来。这个项目是我在做一个智能协作工具时沉淀下来的核心模块简单说就是给模型配置一套可切换、可裁剪、可追溯的上下文管理模式让它在不同任务场景下只读取该读的东西。这个标题看起来只是一个功能开关但背后涉及的是上下文窗口管理、会话状态设计、语义检索、缓存策略和成本控制这一串问题。如果你正在做聊天机器人、文档问答、Agent 工作流或者只是被长对话“失忆”和 token 超限折腾过这篇东西应该能给你一些可以直接抄作业的思路。1. 从场景倒推设计为什么要单独做一个 context-mode1.1 乱炖式上下文是最大的性能杀手先聊一个大多数人都经历过的场景。你在对话框里问了模型十几个问题从“帮我写个周报”聊到“对比三家云服务的价格”再回到“刚才那个周报的数据来源是什么”模型大概率已经忘了前面在聊什么。这不是模型笨而是你把所有历史消息一股脑塞进了上下文窗口而模型对早期信息的注意力天然会衰减。实测下来当对话超过 10 轮、累计 token 超过窗口的 60% 时模型对早期关键信息的召回准确率会明显下降。更麻烦的是你塞进去的很多内容本身就是干扰项中间聊过的无关话题、临时贴的报错日志、反复修改的草稿版本这些都在挤占有限的注意力资源。我在做这个项目之前团队里的方案是“全量拼接 暴力截断”——把所有消息按时间顺序拼起来超过窗口就砍掉最老的。这种做法相当于把一整本小说每一页都摊开让你找一句话能找到才怪。context-mode 的初衷就是给上下文建立“模式”不同任务用不同形态的上下文而不是永远一锅炖。1.2 一个被反复验证的设计前提上下文是可以被结构化的很多人觉得上下文就是“聊天记录”但实际生产中上下文至少包含四类信息用户本轮输入和即时需求这是最高优先级的指令信号。任务相关的背景资料比如文档片段、代码文件、数据库查询结果。历史会话中的有效决策信息比如已经确认的方案、修正过的偏好。全局约束包括系统提示词、安全规则、输出格式要求。这四类信息的生命周期完全不同。即时需求用完就该丢背景资料按需取用历史决策要长期保留但不需要每轮都完整出现全局约束则必须始终在场。context-mode 做的事情就是给这四类信息分配不同的容器、不同的保留策略和不同的注入方式。我把这套机制落地成了四种模式会话模式、文档模式、知识库模式和自动模式。接下来逐个拆解它们的适用场景和实现要点。2. 模式谱系context-mode 的四种工作形态2.1 会话模式只留“决策轴”丢掉“流水账”会话模式对应的是日常多轮对话场景。它的核心思想是不需要把所有消息都喂给模型只需要保留那些真正影响后续回答的决策节点。怎么判断哪些是决策节点我用的方案是给每条消息打标签。用户消息里出现“改成”“不要”“换一种”“重点强调”这类指令性词汇时标记为“变更指令”模型回复里包含明确结论、方案、参数选型时标记为“决策输出”。在下一次请求组装上下文时优先保留最近 3 轮完整对话用于理解当前语境再往前只保留标记过的决策节点其他内容转入滚动摘要。滚动摘要这个设计是关键。每 5 轮对话结束后单独调用一次模型把前面的对话压缩成 200 字以内的结构化摘要格式固定为“已完成事项 / 当前待办 / 用户偏好 / 遗留问题”。下一次构建上下文时把摘要放在历史消息的最前面后面再跟完整保留的近期对话。这里有一个容易踩的坑摘要不能只是“前文概要”四个字开头的信息浓缩必须要求模型输出“用户已经确定用 Vue 3 TypeScript不要再说 jQuery 方案”。也就是摘要里只保留对后续对话有约束力的内容。我在提示词里明确写了“如果一条信息不影响后续对话决策就丢掉它。”实测这个约束能砍掉约 40% 的无用历史内容而且模型对用户偏好的记忆稳定性明显提升。2.2 文档模式全量塞不如按需切片文档问答场景是另一个重灾区。用户上传一本几百页的 PDF直接全文塞进上下文token 直接爆掉而且模型会把十八章的内容和第三章的内容混淆。文档模式解决这个问题的方式是切片 定位 局部注入。文档在入库时按语义切成 500 token 左右的片段每个片段生成向量索引。用户提问时先用问题向量去检索 top-k 相关片段把这些片段连同它们的章节位置信息一起注入上下文。这里要特别说明一个细节检索出来的片段不要按相似度从高到低排序后直接拼接。我实测下来按原文顺序排列检索到的片段比按相似度排序的版本在连贯性上强很多。因为模型读到的是一段在原文中连续的内容而不是东一块西一块的碎片。另外每个切片前加一行“来源第三章 第二节 / 原书第 45 页”模型在回答时会更倾向于引用准确位置而不是自己脑补。文档模式里还有一个容易被忽略的参数top-k 的选择。k 太小会漏信息k 太大会引入噪声。我用的是动态 k 策略——先粗召回 15 个候选片段然后用一个简单重排逻辑挑选与问题关键词重合度最高的 6-8 个。比固定 k 的效果好尤其在问题涉及多个章节时。2.3 知识库模式全局无压只带路径图知识库模式适合团队级问答比如内部文档库、产品 FAQ、历史工单。它的特殊之处在于知识量级很大不可能全部塞进任何模型的上下文窗口而且知识的更新频率高缓存策略必须灵活。我的做法是把知识库分成两层第一层是目录层包含所有知识条目的标题、标签和一句话摘要第二层是内容层存完整正文。每次请求时先把用户的 query 和目录层做一次检索找到 10-20 个可能相关的条目再对候选条目的摘要做第二轮精排最终只把命中的 3-5 个条目的完整正文注入上下文。这样做有一个额外的好处目录层小到可以整个放进上下文。当模型拿到的是“全局地图 局部详情”它回答问题时会天然带着全局视角。比如用户问“我们有没有关于退款流程的文档”即使具体文档没有被完整注入模型也能根据目录层信息给出准确指引——先告诉用户有这份文档再说明它涉及哪些要点。知识库模式最考验的是数据更新。文档改了向量索引要同步更新但目录层的摘要如果没跟着改模型就可能引用过时信息。我后来加了一个校验机制每次注入知识条目前先比对条目的“最后更新时间”如果超过 7 天就要求模型在回答里标注信息来源时间。这个细节在工单系统里救过我好几次。2.4 自动模式用规则判断该用哪种形态自动模式不是第五种上下文结构而是一个路由器。它根据当前请求的特征自动切换到上述三种模式中的一种。路由判断的输入有三个当前会话的近期消息、用户的显式指令、传入内容的类型标记。比如检测到用户消息中带有 文档 或“根据这个文件回答”时走文档模式检测到消息中包含“查一下我们团队”“内部资料”等短语时走知识库模式都没有特殊信号时走默认的会话模式。自动模式的实现在工程上并不复杂就是一组 if-else 加关键词匹配但我建议不要做得太“聪明”。最开始我想用一层模型调用来判断“用户意图”结果每个请求多出一次网络调用响应延迟增加几百毫秒准确率却只比关键词匹配高 2 个点。后来我干脆把路由规则做成可配置的指标模式名称、触发关键词、优先级、超时失效时间。运营同学直接在配置文件里维护就行不需要改代码。自动模式对用户的价值是“无感”。用户不需要理解上下文管理只需要知道这个工具有时候能够记住他几轮之前说过某个要求有时候又能翻出一份他完全没提过的内部文档。这种体验背后就是模式路由在起作用。3. 核心实现细节与参数调优3.1 上下文管理器的数据流结构整个 context-mode 的实现核心是一个上下文管理器ContextManager它负责在请求前组装 context在响应后更新 context。我用一个类来描述它的骨架class ContextManager: def __init__(self, mode: str, max_tokens: int 8000): self.mode mode self.max_tokens max_tokens self.records [] # 全部会话记录带 metadata self.summaries [] # 滚动摘要每 5 轮生成一份 self.rule_set load_rules(mode) # 模式对应的上下文组装规则 def build_context(self, user_input: str) - list[dict]: # 1. 按当前模式的路由规则决定要注入哪些来源 sources self.route(user_input) # 2. 从各来源拉取候选内容 candidates [] if session in sources: candidates self.collect_session(user_input) if document in sources: candidates self.collect_document(user_input) if kb in sources: candidates self.collect_kb(user_input) # 3. 按优先级排序 token 预算裁剪 ordered self.prioritize(candidates) return self.fit_budget(ordered, self.max_tokens) def update_context(self, user_input: str, response: str): # 1. 保存完整消息 self.records.append({user: user_input, assistant: response}) # 2. 按模式规则判断是否需要触发摘要 if self.mode session and len(self.records) % 5 0: summary self.generate_summary(self.records[-10:]) self.summaries.append(summary) # 3. 更新文档/知识库的引用频次用于后续优先级排序这段代码是简化后的架构示意但有几个点我希望你注意。3.2 缓冲区和临时上下文的取舍构建上下文时我最开始是把所有候选内容一股脑往 messages 里塞然后让模型自己“挑重点”。后来发现这非常浪费因为模型每多读一个 token 就多一份钱而且无关内容会稀释注意力。于是我为每个上下文来源单独设立了“预算池”会话模式通常占 30% 的 token 预算文档检索片段占 40%知识库条目占 20%系统提示词和工具定义占 10%。如果某个来源的内容超预算不是直接截断而是先尝试降级——比如把完整文档段落换成摘要段落再不行才截断。设计 budget pool 有一个好处就是你可以针对不同模式调节比例。比如一个客服工单场景历史决策其实很少用户每次都是新问题那么会话模式的比例可以降到 15%把更多空间留给知识库检索结果。我把这些比例做成配置项台面上是四个浮点数实际上背后是一整套上下文资源的分配策略。3.3 关键参数配置经验下面几个参数是我反复调出来的每个都对应一个真实踩坑故事。token 回收阈值80% 到 85%。这是触发上下文裁剪的阈值。当已用 token 占总窗口的 85% 时启动裁剪流程而不是等到超限报错。预留 15% 的空间是为了给输出留余地——很多模型在生成时会先计算一次 prompt 长度你在 prompt 边缘疯狂试探很容易出现请求失败或者结果被腰斩。摘要触发轮数5 轮。少于 5 轮就压缩信息损失比较大多于 8 轮才压缩中间这几轮的低价值对话会挤占大量空间。每 5 轮做一次摘要再加上保留最近 3 轮完整对话这个组合在“记忆完整性”和“token 开销”之间最平衡。文档片段长度500 token。短了语义不完整长了检索精度会下降。500 token 既保证一段内容能表达一个完整观点又方便做精准的局部注入。优先级权重全局约束 10本轮输入 2近期对话 1历史摘要 0.5。这个权重矩阵直接决定裁剪时先丢什么。我见过一个反面案例团队把历史摘要的权重设得比近期对话还高结果模型总是回复太“老练”只认摘要里浓缩过的结论对用户最新表述的语气和细节反应迟钝。这些参数没有标准答案和你的模型能力、应用场景强相关。我给的建议是先跑通机制再在真实流量上回放参数用“回答准确率 单次请求成本”两个指标来调优。不要拍脑袋调参数一定要看数据。4. 测试与踩坑实录三个最隐蔽的上下文事故4.1 上下文漂移模型记住了不该记的我最开始做会话模式时只保留决策节点和摘要但很快发现一个新问题模型偶尔会引用前面很多轮的内容而这些内容其实已经被裁剪掉了。它回答得一本正经细节却是我从来没喂给它的——典型的幻觉。排查了很久才找到原因。滚动摘要在生成时模型会把原始对话中一些“语气信息”也吸收进来比如用户最初带情绪地说“这个必须周五前上线”摘要里就写了“用户强调上线时间紧急”。后续模型看到“紧急”这个词直接在回答里脑补了一些焦虑情绪甚至给出了不必要的加急方案。解决办法是在摘要提示词里加了一条护栏“只陈述客观事实和明确指令不推断用户情绪不转述修辞性表达。”同时把摘要从自然语言改成结构化字段包括“已确认需求”“待决问题”“用户偏好”“附加约束”四栏。结构化之后模型能脑补的空间就小多了这个事故基本绝迹。4.2 上下文风暴token 分钟级爆表还有一次是知识库模式上线后线上突然报告 token 消耗飙升单次请求平均成本涨了 4 倍。查了监控发现问题出在知识库条目的“相关度粗召回”上——检索模块返回的前 15 个候选中有 10 多个都是同一篇大文档的不同切片导致最终注入的 5 个条目几乎全是同一篇文章的重复内容。说白了就是“上下文风暴”大量的重复信息挤占窗口成本高还影响回答质量。修复方式是给检索结果加了同源去重逻辑按文档来源分组每组最多选 2 个切片优先取覆盖范围最广的那段。同时把粗召回候选从 15 个减到 10 个精排阶段再扩展回 5 个。这样既避免了同一文档霸屏又保证了多文档覆盖。4.3 优先级错位定海神针被挤掉最后再讲一个特别容易被忽略的坑。文档模式中用户上传文件时会附带一句说明比如“这个 PDF 是 2025 年的财务预算表注意不要和 2024 年的混淆”。这句话在构建上下文时被我归到了“用户本轮输入”优先级是 2。但问题是当对话轮次增多、token 预算吃紧时这句话被裁剪的概率很高。结果用户在第 20 轮问“预算表里市场部的数字是多少”模型去检索的时候把 2024 年和 2025 年的内容搅在一起了因为这个区分指令已经从上下文里消失了。这类“针对某个文档的全局约束”应该单独归类优先级至少要设为 5 以上并且绑定到文档模式下只要该模式激活就一直保留在上下文中。我后来管这类信息叫“锚定指令”——它的作用不是参与多轮对话而是锚定整个文档问答任务的边界。从那之后我在 context-mode 里专门加了一个字段anchor_rules。它存放所有和当前任务强相关的固定约束任何裁剪逻辑都不能动它。结尾这个项目做到后面我有一个很深的体会上下文管理不是“缓存聊天记录”而是对信息的分类和取舍。你要先认清楚哪些信息决定回答质量哪些信息只是历史包袱然后用机制保证前者始终在场、后者优雅退场。context-mode 只是一组规则的名字真正的价值在于它逼着你想清楚了这些问题。如果再让我重新做一遍我会在项目一开始就加入模式可观测性的设计——每次请求结束后记录上下文组装明细包含哪些来源被注入了、哪些被裁剪了、裁剪原因是什么。这样调试对比时就不用靠猜了。这算是我实际使用中踩了不少坑之后最想提醒你的一点。