1. 从“context-mode”这个命名说起它到底在解决什么问题第一次看到context-mode这个词我的直觉是这大概率跟“上下文管理”有关而且带-mode后缀说明它不是一个具体功能而是一种可切换的运行模式或状态机。在工程实践中凡是带mode的命名通常意味着系统存在多种行为分支而context-mode就是其中一种特定的行为策略。那它到底解决什么问题我举一个最常见的场景。你在开发一个对话系统、一个代码助手、或者任何一个需要“记住之前发生了什么”的应用时会遇到一个核心矛盾上下文窗口是有限的但对话历史是无限增长的。你不能把所有历史都塞进去那样既慢又贵还会触发长度限制你也不能简单粗暴地只保留最近几条那样会丢失关键信息导致答非所问。context-mode要处理的就是这个矛盾。它本质上是一套上下文生命周期管理策略——决定哪些信息进入上下文、哪些被压缩、哪些被丢弃、哪些被提升为长期记忆。你可以把它理解成一个“上下文调度器”它不生产内容它只是内容的搬运工和裁剪师。我之所以对这个话题感兴趣是因为在实际项目里上下文管理做得好不好直接决定了系统的响应质量、推理成本和用户体验。一个设计糟糕的上下文策略会让模型反复问用户“你刚才说的是什么”或者把无关的旧信息当成当前指令来执行。而一个设计良好的context-mode能让系统在有限的窗口里保持“记忆连贯性”同时把成本控制在可接受范围内。这篇文章适合谁看如果你正在做对话系统、智能客服、代码补全工具、或者任何需要维护多轮状态的 AI 应用那这篇内容就是为你准备的。我会从核心原理、模式设计、实操步骤、踩坑经验几个维度把context-mode这件事讲透。即使你之前没接触过上下文管理也能跟着思路一步步理解。提示本文讨论的context-mode是一个通用工程概念不绑定任何特定平台或框架。所有代码示例均为伪代码或通用逻辑你可以根据自己的技术栈做适配。2. 上下文窗口的物理限制与信息密度的博弈2.1 为什么“全量保留”是最昂贵的懒惰很多刚接触对话系统开发的人第一反应是我把所有历史消息都拼接到 prompt 里不就行了反正模型支持的长度越来越长。这个想法在 demo 阶段没问题但一上生产就会崩。原因有三层。第一层是成本。上下文长度直接和计费挂钩你每多塞一千个 token每次请求就多花一份钱。如果是一个高频调用的服务这个成本会指数级放大。我见过一个项目因为没做上下文裁剪单次请求的 token 消耗是优化后的 8 倍一个月下来账单多出好几万。第二层是延迟。上下文越长模型的推理时间越长。对于实时交互场景比如语音助手或在线客服延迟超过 2 秒用户就会明显感到卡顿。而全量上下文会让首 token 延迟显著上升。第三层是信息稀释。这是最容易被忽略的。当上下文里塞了大量无关的旧消息时模型对当前指令的注意力会被分散。你问“帮我改一下刚才那个函数”模型可能因为前面有 50 条无关对话而找不到“刚才那个函数”到底指哪个。信息太多等于没有信息。所以context-mode的第一个设计原则就是上下文不是越多越好而是越精准越好。你要做的不是保留一切而是保留“对当前决策有影响”的那部分。2.2 信息密度的三个维度时效性、相关性、指令性那怎么判断哪些信息该保留我通常从三个维度来评估每条消息的“信息密度”。时效性越近的消息通常越重要。但这不是绝对的比如用户在第一轮设定的角色偏好可能在整个会话中都有效。所以时效性要结合“是否被后续消息覆盖”来判断。相关性这条消息和当前用户输入的主题是否一致。如果用户突然切换了话题那之前话题的细节就可以压缩或丢弃。相关性的判断可以基于关键词匹配、向量相似度、或者简单的主题分类。指令性这条消息是否包含必须遵守的约束。比如“用 Python 写”“不要用第三方库”“输出 JSON 格式”这些是指令一旦设定在整个会话中都应该保留除非用户明确修改。把这三个维度组合起来你就能给每条消息打一个“保留优先级”。高优先级的完整保留中优先级的压缩成摘要低优先级的直接丢弃。这就是context-mode的核心决策逻辑。2.3 一个反直觉的结论摘要比原文更容易导致误解很多人觉得把旧消息压缩成摘要是一种“无损”操作。但实际经验告诉我摘要是有损压缩而且损失的部分往往是你最需要的细节。举个例子。用户说“帮我写一个函数输入是一个列表输出是去重后的列表但是要保持原来的顺序而且不能用 set。” 如果你把这条压缩成“用户要一个去重函数”那“保持顺序”和“不能用 set”这两个关键约束就丢了。模型可能会用 set 来实现然后你还要再纠正一轮。所以我的做法是对于包含明确约束和指令的消息不做摘要直接保留原文。摘要只用于那些“背景性”的对话比如寒暄、确认、无关的闲聊。这样既能控制长度又不会丢失关键约束。这个策略在context-mode里对应一个开关preserve_instructions: true。开启后系统会识别包含指令关键词的消息并将其标记为“不可压缩”。3. 设计一个可落地的 context-mode 状态机3.1 四种基础模式full、sliding、summary、hybrid在实际工程中我不会只设计一种上下文策略而是设计一组模式根据场景动态切换。下面是我常用的四种基础模式。模式名称行为描述适用场景token 开销full保留全部历史短会话、调试阶段高sliding只保留最近 N 轮实时对话、长会话低summary旧消息压缩为摘要需要长期记忆的助手中hybrid指令保留 近期完整 远期摘要生产环境通用中高full模式最简单但只适合会话轮次很少的情况。sliding模式最省 token但会丢失早期设定。summary模式适合需要记住用户偏好的场景但摘要质量依赖模型能力。hybrid是我最推荐的它结合了前两者的优点指令类消息永久保留最近 K 轮完整保留更早的消息压缩成摘要。3.2 模式切换的触发条件轮次、token 数、话题漂移模式不能写死要根据运行时状态动态切换。我通常设置三个触发器。轮次触发器当对话轮次超过阈值比如 10 轮从full切换到hybrid。这个阈值取决于你的平均消息长度如果每条消息很短可以设大一点。Token 触发器当累计 token 数超过窗口的 70%触发压缩。留 30% 的余量给当前请求和模型输出。这个比例是我实测下来比较稳的太低会导致频繁压缩太高会触发截断。话题漂移触发器当检测到当前输入和最近几轮的主题相似度低于阈值比如 0.3说明用户切换了话题此时可以把之前话题的上下文整体压缩或归档。话题漂移检测可以用简单的关键词重叠率也可以用 embedding 相似度。def should_switch_mode(history, current_input, config): # 轮次触发 if len(history) config.max_turns: return hybrid # token 触发 if count_tokens(history) config.window_size * 0.7: return summary # 话题漂移触发 if topic_similarity(history[-3:], current_input) 0.3: return sliding return full这段逻辑不复杂但效果很直接。你可以把它放在每次请求前执行根据返回的模式来决定如何组装上下文。3.3 指令识别哪些消息绝对不能丢在hybrid模式里最关键的一步是识别“指令类消息”。我总结了几类必须保留的内容。角色设定比如“你是一个资深 Python 工程师”“用中文回答”。格式约束比如“输出 JSON”“不要用 markdown”“只返回代码”。否定指令比如“不要用第三方库”“不要解释”。用户偏好比如“我喜欢简洁的回答”“用 TypeScript 而不是 JavaScript”。识别方法可以很简单维护一个关键词列表命中就标记为指令。比如包含“不要”“必须”“只能”“用...而不是”这些词的消息大概率是指令。更稳妥的做法是让模型自己判断但那样会增加一次调用。我的经验是规则匹配 人工兜底在大多数场景下够用了没必要为了 5% 的准确率提升引入额外的模型调用。注意指令识别不要过度。如果一条消息既包含指令又包含普通内容比如“用 Python 写一个排序函数顺便解释一下原理”那“用 Python”是指令“解释原理”是普通请求。你可以把整条消息保留因为它的长度通常不大没必要拆分。4. 实操从零实现一个最小可用的 context-mode4.1 数据结构设计消息、摘要、指令标记先定义数据结构。我习惯用三个列表来管理上下文。class ContextStore: def __init__(self): self.instructions [] # 指令类消息永久保留 self.recent [] # 最近 K 轮完整消息 self.summaries [] # 远期消息的摘要 self.max_recent 6 # 最近 6 条消息完整保留instructions列表只增不减除非用户明确修改。recent列表用队列管理超过max_recent就把最旧的消息移到摘要流程。summaries列表存储压缩后的文本每条摘要附带一个时间戳或轮次范围方便追溯。组装最终 prompt 时顺序是系统提示 → 指令列表 → 摘要列表 → 最近消息 → 当前输入。这个顺序很重要因为模型对开头和结尾的信息注意力最强。指令放前面当前输入放最后中间是背景信息。4.2 摘要生成用模型压缩但保留关键实体摘要生成我一般用一个小模型或者同一个模型的一次轻量调用。Prompt 可以这样写请将以下对话压缩成一段简洁的摘要保留所有关键实体人名、文件名、函数名、参数名和约束条件。不要添加新信息不要遗漏否定指令。 对话内容 {history_text} 摘要关键点是保留实体。很多摘要失败是因为把“函数名process_data”压缩成了“那个函数”导致后续无法引用。所以我在 prompt 里明确要求保留实体。实测下来这个改动能让摘要的可用性提升一大截。另外摘要不要追求“一句话概括”。我通常允许摘要长度在 100 到 200 字之间太短会丢信息太长就失去压缩意义。4.3 组装顺序系统提示、指令、摘要、近期消息、当前输入组装顺序我前面提过这里展开说一下为什么。系统提示放最前面因为它是全局设定模型对开头的注意力最稳定。指令列表紧随其后确保模型在阅读具体对话前就知道约束。摘要放在中间作为背景知识。最近消息放在摘要之后因为它们是“正在进行的对话”需要和当前输入紧密衔接。当前输入放最后这是模型最需要回应的部分。如果你用的是某些对位置敏感的结构可以把指令在开头和结尾各放一次强化约束。我试过在结尾重复“记住不要用第三方库”确实能降低违反指令的概率但会增加 token 消耗。是否值得看你的场景对指令遵守的严格程度。4.4 一个完整的调用示例def build_prompt(store, current_input): parts [] parts.append(你是一个有帮助的助手。) if store.instructions: parts.append(必须遵守的指令\n \n.join(store.instructions)) if store.summaries: parts.append(历史摘要\n \n.join(store.summaries)) if store.recent: parts.append(最近对话\n format_messages(store.recent)) parts.append(当前输入 current_input) return \n\n.join(parts)这个函数每次请求前调用一次返回组装好的 prompt。你可以在build_prompt之后加一个 token 计数如果超过窗口限制就触发一次强制摘要。5. 踩坑实录那些让我熬夜排查的上下文问题5.1 摘要循环越摘要越短最后什么都没了这是我踩过最坑的一个问题。早期我设计了一个“每次请求都把全部历史摘要一次”的逻辑。结果跑了十几轮之后摘要越来越短最后变成“用户和助手进行了对话”这种废话。原因很简单摘要是有损的对摘要再摘要损失会累积。修复方案是摘要只对原始消息做不对摘要做。也就是说summaries列表里的内容不再参与后续摘要。每次压缩时只把recent里溢出的原始消息压缩成新摘要追加到summaries末尾。这样损失只发生一次不会累积。5.2 指令被“挤”掉为什么模型突然不遵守格式了另一个常见问题是用户明明设定了“输出 JSON”但几轮之后模型开始输出 markdown。排查后发现是因为sliding模式把包含指令的那条消息滑出去了。指令不在上下文里模型自然不遵守。修复方案就是前面说的指令类消息不参与滑动窗口永久保留。我在ContextStore里单独维护instructions列表组装时始终放在前面。这个改动之后格式违反率从 15% 降到了 2% 以下。5.3 话题切换后的“上下文污染”用户从“帮我写代码”切换到“今天天气怎么样”如果上下文里还保留着大量代码相关的消息模型可能会在回答天气时莫名其妙地提到“函数”或“变量”。这就是上下文污染。我的处理方式是检测到话题漂移后把之前话题的 recent 消息全部归档到 summaries并清空 recent。这样新话题开始时上下文是干净的只有指令和摘要作为背景。摘要里虽然还有旧话题的影子但因为是压缩过的污染程度低很多。5.4 Token 计数不准导致的截断事故Token 计数是个细节坑。不同模型的 tokenizer 不一样同一个文本在不同模型下的 token 数可能差 20%。如果你用 A 模型的计数去限制 B 模型的输入就会出现“以为没超实际超了”的情况导致请求被截断或报错。我的做法是用目标模型的 tokenizer 来计数并且留 10% 的安全余量。比如窗口是 4096我按 3600 来限制。另外计数要包含系统提示、指令、摘要、近期消息和当前输入的全部内容不能只算对话部分。6. 进阶优化让 context-mode 更智能的几个方向6.1 基于向量检索的动态上下文召回前面的方案都是“规则驱动”的优点是可控、可解释。但如果你有大量历史消息而且用户可能引用很久之前的内容那规则就不够用了。这时候可以引入向量检索。具体做法是把所有历史消息存入向量库每次请求时用当前输入去检索最相关的 K 条消息动态加入上下文。这样既能召回远期信息又不会把无关内容塞进去。检索的相似度阈值要调太低会引入噪声太高会召回不足。我一般从 0.7 开始试根据效果调整。6.2 上下文优先级评分模型如果你有标注数据可以训练一个小的评分模型给每条消息打一个“保留价值”分。特征可以包括消息长度、是否包含指令词、与当前输入的时间距离、与当前输入的语义相似度、是否包含实体等。然后用这个分数来决定保留、压缩还是丢弃。这个方案比纯规则更灵活但需要数据。如果没数据可以先用手工权重比如“指令词命中 10 分时间距离每轮 -1 分相似度 * 5 分”也能得到一个可用的排序。6.3 多轮摘要的层级结构对于超长会话单层摘要不够用。可以设计层级摘要每 10 轮压缩成一个“段落摘要”每 5 个段落摘要再压缩成一个“章节摘要”。这样既能保留宏观脉络又能在需要时展开细节。实现上可以用树形结构每个节点是一个摘要叶子节点是原始消息。检索时从根到叶逐层判断相关性只展开相关的分支。这个方案复杂度较高适合会话轮次上百的场景。7. 我在实际项目中的几条经验之谈第一不要过早优化。如果你的会话平均只有 3 到 5 轮直接用full模式就行别上来就搞摘要和向量检索。复杂度是成本不是炫耀的资本。第二监控比策略更重要。上线后一定要记录每次请求的 token 数、模式切换次数、摘要触发频率、指令违反率。这些指标能告诉你策略是否有效。我见过一个项目摘要逻辑写错了导致每次请求都触发摘要token 消耗反而比全量还高但因为没监控跑了一周才发现。第三给用户一个“重置上下文”的入口。有时候上下文污染太严重与其费力修复不如让用户一键清空。这个功能成本很低但体验提升很明显。第四摘要质量要人工抽检。自动化指标只能看长度和压缩比但摘要是否保留了关键信息需要人工看。我一般每周抽 20 条摘要检查是否有实体丢失或语义扭曲。这个习惯帮我提前发现了好几次潜在问题。第五指令的优先级高于一切。在任何模式下指令都不应该被压缩或丢弃。这是底线。如果 token 实在不够宁可丢弃最近的对话也要保留指令。最后分享一个小技巧在系统提示里加一句“如果上下文中有任何你不确定的信息请先向用户确认不要猜测”。这句话能显著降低模型因为上下文不完整而胡编乱造的概率。我在多个项目里都加了这句效果很稳。