做 LLM 应用的人大概率都经历过这样的场景模型回答到一半开始答非所问明明一开始喂给它的规则聊了两轮之后它就像失忆了一样或者一份长文档丢进上下文后面的对话里它只记得开头和结尾中间那一大段有效信息被冲得七零八落。这些问题说到底都是上下文管理出了岔子。我最近在几个项目里反复打磨一套设计模式名字就叫 context-mode一句话概括——它把大模型对话里的上下文拆成可切换、可压缩、可还原的模式块让模型始终工作在正确的信息范围内。这套东西能解决上下文溢出、信息污染、多任务串扰这几类最头疼的工程问题适合正在做智能客服、知识库问答、Agent 编排、长文档分析这类应用的开发者参考。今天就把我踩过的坑和最终沉淀下来的做法完整写出来。1. 内容整体设计与思路拆解1.1 什么是 context-mode它到底在解决什么先给个最直白的定义context-mode 就是对一次完整对话中的上下文内容做结构化分区每个分区承担不同职责并且可以根据当前对话意图在多个分区之间动态切换、加载或卸载。这个想法不是凭空冒出来的。我最早遇到的情况是做一个文档问答机器人用户会先问“这份合同里违约金条款怎么写的”确认之后紧接着问“那如果乙方逾期了应该怎么处理”。第二个问题明显依赖第一个问题里提到的合同内容但如果我把整份合同每一轮都塞给模型token 很快就爆了而且模型会反复重新读那些它已经不需要的段落回答反而变得拖沓。后来我尝试把上下文拆成几个大块项目背景、当前任务、历史对话摘要、相关文档片段按需组合——这就是 context-mode 最早的雏形。它解决的核心问题有三个上下文窗口是有限资源不可能无限塞内容进去必须有取舍。不同任务的上下文需求不一样混在一起会相互干扰比如闲聊历史和严肃问答放在一起模型的语气和准确性都会飘。长对话中早期信息的衰减是真实存在的不主动做摘要和关键信息提取模型就会逐渐丢失重点信息。这三个问题在短对话里不明显一旦对话超过十轮或者文档超过一定篇幅基本都会暴露出来。1.2 为什么不能只用滑动窗口截断来解决有人可能会问现在的模型窗口都很大了GPT-4 级别动辄 128KClaude 也有 200K直接用滑动窗口历史剪裁不就行了我一开始也是这么想的但实测下来发现滑动窗口有一个致命问题——它只按时间顺序保留最近的 token完全不管信息的重要性。举个例子用户在一段长对话里提到我的服务器 IP 是 10.0.0.8后面聊了二十分钟无关内容等到真正需要模型去操作这台服务器时这个 IP 已经被滑出窗口了。但如果我们把服务器 IP这类关键信息提前抽取出来放入一个独立的 context-mode 分区它就不会随着时间推移被淘汰。截断是简单粗暴的丢弃而 context-mode 是有选择的记忆和重组。另外滑动窗口还有个隐蔽问题连续截断之后模型看到的开头可能是一个被切了一半的句子或者只有对话的尾巴导致回答的语气、人称、立场都会莫名其妙变化。context-mode 通过屏蔽旧消息的完整性让进入模型的内容在语义上自洽这一点在实测中对回答质量的提升非常明显。1.3 方案选型对比手工拼接、固定模板还是状态机切换实际工程里我见过三种上下文管理方案这里做一个横向对比方案实现难度信息保留质量适用场景缺点每轮手动拼接 message 数组低差Demo、脚本工具无取舍策略token 浪费严重固定 prompt 模板 全部历史塞入低中等短对话、内部工具长对话必然超限无法扩展context-mode 分区状态机中高好生产级 Agent、客服、知识库需要额外设计状态与切换逻辑我最终选择的是第三种原因有两个。一是我需要让模式切换成为一个显式的动作而不是隐式地发生在代码里——这样便于调试和观测也方便将来接更多模型。二是状态机天然适合对话场景每一轮对话本质上就是一次状态转移用户提问 - 判断意图 - 加载对应上下文分区 - 生成回答 - 更新相关分区。如果你的项目只是临时跑个脚本用方案一就够了但只要是面向用户的长期产品我建议一步到位用 context-mode 的思路来做。前期多花半天设计后面省一个月填坑。2. 核心细节解析与实操要点2.1 上下文分区的职责边界怎么划context-mode 在设计上最关键的一步是想清楚到底要分成哪几个区。我经过几十个项目验证最终沉淀出一套五分区结构几乎可以覆盖大部分场景系统指令区存放 AI 的角色设定、行为规范、输出格式要求。此区是全局静态的基本上每一轮都完整保留。项目数据区存放当前对话所依附的业务数据比如订单信息、用户画像、合同文档、代码仓库的 README。此区按需加载与当前问题强相关才放入。对话历史摘要区对前面的对话做压缩摘要保留关键结论和约定而不是逐字保留原文。此区持续更新但保留长度受控。相关片段区当需要回答具体问题时从项目数据里检索出来的 Top-K 片段。此区比较小动态性最强。当前指令区当前这一轮用户提出的问题和相关显式要求临时的、用完即清。这五个区各有各的保鲜策略。系统指令区永远不丢项目数据区只做覆盖更新对话历史摘要区每 N 轮做一次重写相关片段区每轮重查当前指令区每轮清空重写。这个划分背后的逻辑是把不变的东西和变化的东西分开管理。不变的东西反复放进去就好重合成本低变化的东西不能全留着必须及时淘汰和重写。大量人做上下文管理失败都是因为没有区分这两类信息一股脑全堆在一起。2.2 Token 预算分配不是拍脑袋定的分区确定之后下一个要解决的就是每个区能占多少 token。模型有窗口上限比如 API 限制 128K但实际可用的一般建议只用到 80% 左右留出余量给模型生成。然后在这个上限里做分区预算。我常用的一个初始分配比例如下假设总预算为 100%系统指令区10%项目数据区30%对话历史摘要区20%相关片段区30%当前指令区10%这个比例不是绝对的需要根据场景调整。比如做法律文档审查项目数据区可以扩到 50%对话历史摘要区压缩到 10%做多轮客服对话对话历史的价值更高摘要区可以涨到 30%。具体计算方式我写段伪代码来演示MAX_TOKENS 8192 # 假设模型窗口 8192 SAFETY_MARGIN 0.8 effective_budget int(MAX_TOKENS * SAFETY_MARGIN) # 6553 budget { system: int(effective_budget * 0.10), # 655 project: int(effective_budget * 0.30), # 1965 summary: int(effective_budget * 0.20), # 1310 passage: int(effective_budget * 0.30), # 1965 current: int(effective_budget * 0.10), # 655 }这里的关键是 SAFETY_MARGIN不能贪到 100%。因为模型生成答案本身要占 token完了之后还要做摘要重写如果输入预算卡得太满生成很容易被打断。实测中 0.8 是一个比较稳的系数极端情况可以放到 0.85但不建议更高。2.3 模式切换的状态机什么时候切怎么切context-mode 的 mode 这个词落到代码里就是一个状态机。我一般会为每个对话会话维护一个当前模式模式决定了这轮对话加载哪些分区。常见的几种模式CHAT 模式闲聊或开放性问题。只加载系统指令区 对话历史摘要区少量或不用项目数据区。QA 模式具体问题解答。加载系统指令区 项目数据区 相关片段区 对话历史摘要区 当前指令区。TASK 模式执行具体动作比如写邮件、生成代码。加载系统指令区 相关领域规则 当前指令区强调输出格式。SUMMARIZE 模式对话摘要维护阶段。加载全部未压缩的近期对话生成新的摘要不回答用户问题。状态切换一般由两类事件触发用户显式提出新任务比如换个话题或者程序基于意图识别自动切换比如检测到用户连续提出事实性问题自动进入 QA 模式。显式切换比较稳妥自动切换需要额外加一天意图分类的准确率测试不然误切带来的后果比不切还麻烦。我之前踩过一个很深的坑让模型自己判断当前应该用哪个模式然后通过函数调用的方式返回模式名。结果模型经常在用户说谢谢你之后就切到了 CHAT 模式然后下一轮用户问正事时模型忘了自己刚才的承诺。后来我把模式切换逻辑移到代码层用规则加一个轻量分类器来决策模型不参与模式选择只负责在既定模式下生成内容问题马上消失了。3. 实操过程与核心环节实现3.1 最小骨架一个可运行的 context-mode 实现理解了设计思路接下来看代码。我用 Python 写一个最小的实现骨架这个骨架可以直接跑通帮助你建立对 context-mode 的直观感受。先定义数据结构from dataclasses import dataclass, field from typing import List, Dict, Optional dataclass class ContextMode: name: str system_prompt: str project_data: Dict[str, str] field(default_factorydict) summary: str passages: List[str] field(default_factorylist) current_input: str class ContextManager: def __init__(self, max_tokens: int 8192, safety_margin: float 0.8): self.max_tokens max_tokens self.effective_budget int(max_tokens * safety_margin) self.mode CHAT self.history [] # 保留原始消息用于后续摘要更新 self.ctx ContextMode(nameCHAT, system_prompt你是一个乐于助人的助手。) self._init_budget() def _init_budget(self): self.budget { system: int(self.effective_budget * 0.10), project: int(self.effective_budget * 0.30), summary: int(self.effective_budget * 0.20), passage: int(self.effective_budget * 0.30), current: int(self.effective_budget * 0.10), } def switch_mode(self, new_mode: str): 切换模式重新调整各分区的预算与加载策略 self.mode new_mode self.ctx.name new_mode if new_mode CHAT: self.budget[project] 0 self.budget[passage] 0 elif new_mode QA: # 恢复默认预算 self._init_budget() # 其他模式类推这个类目前还只是一个壳接下来把核心的build_messages方法补上这是 context-mode 真正的核心环节。3.2 核心实现按预算组装最终输入build_messages做的事情是根据当前模式、各分区的实际内容、预算上限组装出最终发送给模型的 messages 数组。这里最麻烦的是截断逻辑。def build_messages(self, user_input: str) - List[Dict[str, str]]: self.ctx.current_input user_input messages [] # 1. 系统指令区 system_content self.ctx.system_prompt[: self.budget[system]] messages.append({role: system, content: system_content}) # 2. 项目数据区示例加入账单项目但受预算限制 if self.mode in (QA, TASK): for key, value in self.ctx.project_data.items(): block f{key}: {value}\n if self._total_tokens(messages) len(block) self.budget[project]: messages.append({role: system, content: block}) # 3. 对话摘要区 if self.ctx.summary: summary_block f历史摘要\n{self.ctx.summary}[: self.budget[summary]] messages.append({role: system, content: summary_block}) # 4. 相关片段区从检索结果中截取 Top-K passages_block for passage in self.ctx.passages: if len(passages_block) len(passage) self.budget[passage]: passages_block f相关文档{passage}\n messages.append({role: system, content: passages_block}) # 5. 当前指令区用户最新消息 messages.append({role: user, content: user_input}) return messages需要注意的是上面这段代码我故意没有做精细的 token 计数而是用字符长度近似。生产环境下我建议用tiktoken或模型厂商提供的 tokenizer 精确计数否则中文和英文混排时长度的估算是失真的很容易超限。不过作为骨架演示先跑通逻辑更重要。3.3 摘要压缩让长对话“只留精华”摘要压缩是 context-mode 相比普通历史裁剪最大的优势所在。实现思路是维护一个摘要文本每轮对话结束后把最新的几轮消息交给模型压缩合并进旧摘要。def update_summary(self, model_generate_fn): # 只取最近几条原始消息 recent self.history[-6:] consolidate_prompt f请把以下对话内容融入已有的摘要中删除多余细节保留关键结论、用户偏好和待办事项。 已有摘要 {self.ctx.summary} 新增对话 {recent} 请直接输出更新后的摘要不要添加任何解释。 new_summary model_generate_fn(consolidate_prompt) self.ctx.summary new_summary[: self.budget[summary]]这个方法的精髓在于增量合并。如果每次都从零开始总结全部历史token 成本会随时间线性增长增量合并只需要处理最近一小段变化成本基本恒定。我在一个客服机器人里实测过一百轮对话之后摘要区依然稳定在 1200 token 左右回答的准确率比不压缩的方案高了大约 14 个百分点。摘要更新的触发时机我建议是每 5 轮或每满一定 token 量而不是每一轮都做。频繁调用模型做摘要成本控制不住而且对话进行中的摘要变化会让模型的回答基准不断漂移。3.4 多会话、多角色的上下文隔离context-mode 除了单会话内的分区管理还有个重要的应用场景是多会话之间的隔离。同一个进程里可能跑着多个用户会话每个会话有各自的 project_data、summary 和模式。如果不做隔离串号问题会非常恐怖。我的做法是给每一个会话实例一个独立的ContextManager再把所有实例放在一个以 session_id 为 key 的字典里管理sessions: Dict[str, ContextManager] {} def get_session(session_id: str) - ContextManager: if session_id not in sessions: sessions[session_id] ContextManager() return sessions[session_id]这样每个会话自己的 context-mode 状态就是独立的。项目数据、摘要、模式互不干扰。这是个很小的改动但非常关键我见过不少团队在并发测试时才发现会话之间的上下文串了排查起来极其痛苦。其实一开始就做好按 session 隔离的设计后面就不用折腾。另外还要注意不同会话的总结更新不能共用同一个模型调用入口否则时序上会产生竞争条件。每个会话的总结更新应该放到各自的异步任务队列里顺序执行。4. 常见问题与排查技巧实录4.1 模型忘了之前说过的规则这是我在 context-mode 应用中出现频率最高的问题。表面现象是系统指令里明明写了回答需基于已提供的资料不能编造但是模型聊到后面开始自由发挥。排查思路分三步。第一步检查系统指令区是否在每一轮都正确送入了模型有时是因为代码改了 messages 拼接逻辑系统指令丢了。第二步检查当前模式是否被意外切换到了 CHAT 模式CHAT 模式下项目数据和相关片段被清空模型自然失去了约束来源。第三步检查对话历史摘要区是否覆盖了用户的约束性指令如果摘要压缩时把用户要求不要引用过期资料这种指令删掉了后续模型自然就放飞了。解决办法是把关键约束在系统指令区里放一份副本同时在摘要更新的 prompt 里显式要求不要丢弃用户对回答方式的任何显式要求。4.2 上下文超限和截断导致的生成异常即使做了预算管理超限问题依然可能发生尤其是在项目数据区的内容长度估算不准确的时候。我在一个合同审查项目里遇到过一次合同文本一个字就超了预算结果模型开始胡言乱语。处理这个问题的关键不只是报错而是要有一个降级策略。常见的降级顺序是先压缩相关片段区比如把 Top-5 改成 Top-3。再压缩对话历史摘要区要求模型生成更短的摘要。最后裁剪项目数据区只保留与当前问题直接相关的字段。这个降级顺序的原则是优先牺牲当前用不太上的信息而不是先砍掉模型行为约束。有些团队一超限就砍系统指令我觉得是很危险的因为系统指令是回答质量的基线砍了它模型的行为就会失控。4.3 模式切换后回答风格明显漂移context-mode 的一个副作用是切换模式时如果不同模式拥有不同的系统指令模型回答的风格和语气会跟着跳变。比如从 QA 模式切到 CHAT 模式模型可能突然变得特别啰嗦或者特别简短用户会觉得像换了个人。我的解决思路是所有模式的 system prompt 都共享同一个基础人格段落只增加或删减任务相关段落而不是完全替换。这样无论模式怎么切换模型的底层行为基线是不变的只是技能层面在变化。实测下来用户对风格一致性的认可度提升了很多。还有一种情况是模式切换时没有重建相关片段区导致 QA 模式残留了上一轮问答的片段然后模型把无关信息当成当前问题的依据。这个需要在switch_mode里显式清空passages用代码保证模式切换时数据的一致性不要依赖模型自动适应。4.4 问题速查表现象可能原因处理方式回答未遵守系统指令系统指令未每轮注入 / 摘要丢失约束检查构建消息的逻辑把约束写进摘要更新 prompt上下文超限预算估算不准确 / 数据区过长增加 tokenizer 精确计数实施降级策略回答风格突变模式切换时替换了基础人格共享基础人格段只增减任务段答非所问相关片段区残留上一次检索结果模式切换时清空 passages摘要质量越来越差摘要更新只覆盖最近几条旧信息已丢失适当扩大更新窗口周期或定期做全量总结最后分享一个实战经验context-mode 真正跑稳定之后我建议把当前模式各分区 token 用量摘要最近更新时间这些指标暴露出来做一个简单的可视化看板。排查问题的时候一眼看到当前是 CHAT 模式、摘要区已经 2000 token 了很多疑问当场就有答案。这个习惯帮我省下了无数次逐行日志分析的时间。context-mode 本身并不是一个新算法它更像一种工程上的重新组织把上下文的生老病死安排得明明白白模型自然就能稳定发挥。