1. 从“context-mode”说起：一个被低估的上下文管理思路

第一次看到“context-mode”这个词，是在一个做智能对话系统的朋友的项目文档里。当时他正被多轮对话中上下文爆炸的问题折磨得焦头烂额——用户聊到第十轮，模型已经忘了第三轮说过什么，回复开始胡言乱语，体验直线下降。他试过截断、试过摘要、试过向量检索，效果都不太理想。后来他换了个思路，把“上下文”当成一个有状态、有模式、有生命周期的对象来管理，而不是简单地拼接字符串。这个思路，就是我今天想聊的context-mode。

说白了，context-mode 是一套关于“如何组织、切换、压缩和复用对话上下文”的工程方法论。它不是一个具体的库或框架，而是一种设计模式——你可以把它理解成给对话系统装了一个“上下文调度器”。它要解决的问题很具体：当对话轮次变多、信息量变大、任务类型变复杂时，怎么让模型始终“记得住重点、分得清场景、不跑偏”。适合谁看？如果你正在做智能客服、AI 助手、多轮问答、Agent 编排，或者任何需要模型“记住前文”的产品，这套东西你迟早会碰到。

我朋友那个项目上线后，多轮对话的准确率从 62% 提到了 89%，token 消耗反而降了三分之一。这不是什么黑科技，就是把上下文管理这件事做细了。下面我把自己踩过的坑、试过的方案、以及最终沉淀下来的实操细节，完整拆一遍。

2. 为什么需要 context-mode：上下文管理的三个核心痛点

2.1 痛点一：上下文窗口不是无限大的，但对话是无限的

很多人做对话系统的第一反应是“把历史全塞进去”。早期确实能跑，因为对话短。但一旦用户聊了二三十轮，或者中间穿插了长文档、表格、代码，token 数直接爆炸。我实测过一个客服场景，平均对话 18 轮，每轮用户输入加系统回复约 120 token，光历史就 2000+ token，再加上系统提示词、知识库片段、工具定义，轻松突破 4000。如果模型窗口是 8K，留给当前轮次的思考空间就非常局促了。

更麻烦的是，上下文越长，模型对中间部分的注意力越弱。这不是玄学，是 Transformer 架构的固有特性——首尾信息权重高，中间容易“被淹没”。你把关键信息放在第 5 轮，到第 20 轮时模型可能已经“看不见”了。所以“全量拼接”不仅浪费 token，还会稀释重点。

2.2 痛点二：不同任务需要不同的上下文“视角”

同一个对话系统，可能同时处理多种任务：用户先问天气，再问订单状态，然后让你写一段代码，最后又回到订单修改地址。如果你把所有历史一股脑塞给模型，它会混淆任务边界。比如写代码时，模型可能把前面订单里的地址当成变量名；改地址时，又可能把代码片段里的字符串当成新地址。

context-mode 的核心洞察就是：上下文应该按“模式”隔离和切换。天气模式只需要地理位置和当前时间；订单模式需要订单号、用户身份、历史操作；代码模式需要编程语言、依赖版本、已有代码片段。把这些混在一起，模型不晕才怪。

2.3 痛点三：上下文的质量比数量重要十倍

我做过一组对比实验：同样 2000 token 的上下文，一组是原始对话历史，一组是经过摘要和结构化提取的“精华版”。在 50 个多轮测试用例上，精华版的回答准确率高出 23 个百分点。原因很简单——原始历史里充斥着“嗯”“好的”“谢谢”这类无效信息，以及重复确认、口语化表达。模型需要花大量注意力去过滤噪声，真正有用的信息反而被稀释了。

所以 context-mode 不是简单地“管理长度”，而是管理信息密度。它要回答的问题是：在当前这个任务模式下，哪些信息是必须的？哪些可以压缩？哪些可以丢弃？哪些需要换一种形式存储？

3. context-mode 的核心设计：四层结构与模式切换机制

3.1 第一层：会话级上下文——全局记忆的锚点

会话级上下文是整个对话的“底座”，它不随任务模式切换而消失。通常包含：用户身份信息（ID、偏好、权限）、会话开始时间、全局约束（比如“不要推荐竞品”“回复控制在 100 字以内”）、以及一个滚动摘要——把之前所有轮次的对话压缩成一段 200 字以内的概述。

滚动摘要的更新策略很关键。我的做法是：每新增 5 轮对话，触发一次摘要更新。更新时不是简单地把旧摘要和新对话拼接再摘要，而是把旧摘要、最近 5 轮原文、以及当前任务模式一起喂给模型，让它生成新的摘要。这样摘要始终围绕“用户目标”和“关键事实”展开，而不是流水账。

注意：滚动摘要一定要保留“否定信息”。比如用户说“不要发邮件”，摘要里必须体现“用户拒绝邮件通知”。很多摘要模型会忽略否定词，导致后续行为出错。

3.2 第二层：任务级上下文——模式切换的核心载体

任务级上下文是 context-mode 的灵魂。每当系统识别到用户意图发生变化，就创建一个新的任务上下文，并切换到对应的“模式”。每个模式定义了三样东西：必填槽位、可选槽位、上下文裁剪规则。

举个例子，订单查询模式：

当模式切换时，系统只把该模式需要的槽位从会话级上下文和历史任务中“拉”过来，其他信息一律不传。这样每次请求模型的 token 数能控制在 800 以内，而且信息高度聚焦。

模式切换的触发条件有三种：显式意图（用户说“我要查订单”）、隐式推断（用户输入了订单号格式的字符串）、以及任务完成后的自动回退（订单查完了，回到通用模式）。我建议显式优先、隐式兜底，因为隐式推断容易误判。比如用户随口说了一串数字，可能是订单号，也可能是电话号码，贸然切换模式会打断对话节奏。

3.3 第三层：轮次级上下文——当前回合的精细控制

轮次级上下文只关注“这一轮”需要什么。它包含：当前用户输入、上一轮系统回复、以及从任务级上下文里提取的少量关键信息。这一层的作用是防止历史信息过度干扰当前轮。

我见过一个典型错误：把整个任务级上下文全量塞进每一轮请求。结果模型在回答“今天天气怎么样”时，还要处理订单号、用户地址、历史操作记录，不仅浪费 token，还可能导致模型“过度联想”——比如把天气和订单地址关联起来，回答“您所在地区今天下雨，建议订单延迟发货”。这显然不是用户想要的。

轮次级上下文的裁剪规则很简单：只保留与当前输入语义相关的槽位。实现上可以用一个轻量级的相关性打分，或者直接用规则匹配。比如当前输入包含“天气”，就只注入地理位置和时间；包含“订单”，就注入订单相关槽位。

3.4 第四层：工具级上下文——函数调用的参数隔离

如果系统支持工具调用（function calling），每个工具应该有独立的上下文视图。比如“查询物流”工具只需要订单号和物流公司，“发送短信”工具只需要手机号和内容模板。工具级上下文确保模型在生成调用参数时，不会被无关信息干扰。

这一层最容易被忽略，但实际影响很大。我测试过一个场景：模型在调用“计算器”工具时，把用户之前说的地址当成了数字参数，导致计算错误。后来加了工具级上下文隔离，问题消失。

4. 实操落地：从零搭建一个 context-mode 管理模块

4.1 数据结构设计：用 JSON Schema 定义模式

先定义模式的结构。我习惯用 JSON Schema，因为可读性好、易校验、方便动态加载。

{ "mode_name": "order_query", "display_name": "订单查询", "required_slots": ["order_id", "user_id"], "optional_slots": ["time_range", "product_name"], "context_rules": { "max_history_turns": 3, "include_session_summary": true, "include_task_summary": false }, "transition_triggers": { "explicit": ["查订单", "订单状态", "物流"], "implicit_patterns": ["^[A-Z0-9]{10,20}$"] } }

这个 Schema 里，context_rules决定了该模式下注入多少历史。订单查询通常不需要太多历史，3 轮足够；但如果是“技术支持”模式，可能需要 10 轮以上的排查记录。

4.2 模式切换的判定逻辑：规则 + 轻量模型双保险

纯规则容易漏判，纯模型容易误判。我的方案是：先用规则做快速匹配，命中则直接切换；未命中则调用一个轻量级意图分类模型（比如 100M 参数以内的小模型）做二次判断。这样兼顾速度和准确率。

规则匹配的优先级要设计好。比如“取消订单”和“查询订单”都包含“订单”，但意图完全不同。我的做法是：长词优先、动词优先。“取消”比“查询”优先级高，因为取消是动作，查询是状态。如果用户说“取消订单查询”，那应该先进入取消模式，因为取消的紧迫性更高。

4.3 上下文压缩：摘要 + 槽位提取 + 向量化三件套

压缩是 context-mode 最耗工程的部分。我的流水线是这样的：

1. 槽位提取：用规则 + NER 模型从每轮对话中抽取结构化信息，存入任务级上下文。比如从“我的订单 12345 什么时候到”中提取order_id=12345。
2. 滚动摘要：每 5 轮更新一次会话级摘要，保留用户目标、关键事实、否定信息。
3. 向量化存档：把每轮对话的原始文本和摘要都做 embedding，存入向量库。当需要回溯细节时，用当前输入做相似度检索，把最相关的 2-3 条历史拉回来。

这三件套配合下来，上下文 token 能压缩到原始历史的 20%-30%，而关键信息召回率保持在 95% 以上。

实操心得：槽位提取一定要做“冲突检测”。比如用户先说“地址是 A”，后来说“改成 B”，任务级上下文里必须只保留 B，并且记录“地址已从 A 改为 B”。否则模型可能同时看到两个地址，随机选一个。

4.4 注入顺序：把最重要的信息放在首尾

前面说过，模型对首尾信息更敏感。所以注入顺序应该是：

• 开头：系统提示词 + 当前模式说明 + 必填槽位
• 中间：可选槽位 + 历史摘要 + 检索到的相关历史
• 结尾：当前用户输入 + 输出格式要求

这样模型在生成回复时，开头有全局约束，结尾有当前任务，中间的历史作为参考。实测下来，比随机顺序的准确率高 15% 左右。

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

5.1 模式切换太频繁，对话被割裂

现象：用户说“我想查订单，顺便问下天气”，系统先切订单模式，又切天气模式，回复变成两段割裂的内容。

排查：这是典型的“多意图混合”场景。规则匹配只认第一个命中的模式，忽略了后面的意图。

解决：引入“复合模式”概念。当检测到多个意图时，创建一个临时复合模式，把两个模式的槽位合并，但分别标注来源。回复时也分两段，先答订单，再答天气，中间用过渡语连接。如果复合模式出现频率高，可以考虑把它固化成正式模式。

5.2 摘要丢失关键否定信息

现象：用户明确说“不要打电话”，但后续系统还是调用了电话通知工具。

排查：检查摘要生成 prompt，发现没有强调“否定信息必须保留”。模型在压缩时把“不要打电话”简化成了“用户提到了电话”。

解决：在摘要 prompt 里加一条硬规则：“所有包含‘不’‘别’‘无需’‘禁止’的表述，必须原样保留在摘要中，并标注为约束条件。”同时，在任务级上下文里单独维护一个“约束列表”，不依赖摘要。

5.3 向量检索召回不相关历史

现象：用户问“怎么退款”，系统检索到了三个月前另一笔订单的退款记录，导致回复混淆。

排查：向量检索只用了语义相似度，没有加时间衰减和用户 ID 过滤。

解决：检索时加三个过滤条件：同一用户 ID、最近 7 天内、同一任务模式。如果结果为空，再放宽时间范围。另外，相似度阈值设高一点（0.85 以上），宁可少召回，不要错召回。

5.4 工具调用参数被污染

现象：调用“发送邮件”工具时，收件人地址变成了用户之前提到的某个商品名称。

排查：工具级上下文没有隔离，模型把任务级上下文里的所有字符串都当成了候选参数。

解决：每个工具定义独立的参数 Schema，注入时只传 Schema 里声明的字段。同时，在工具描述里明确写“收件人必须是邮箱格式”，让模型自己校验。

5.5 常见问题速查表

6. 进阶技巧：让 context-mode 更智能的三个方向

6.1 动态模式权重：根据用户行为调整模式优先级

不同用户的使用习惯不同。有的用户 80% 的对话是查订单，有的用户主要用来写代码。可以统计每个用户的历史模式分布，动态调整模式切换的阈值。高频模式降低触发门槛，低频模式提高门槛。这样能减少误切换，提升响应速度。

6.2 上下文缓存：相同模式复用已压缩的上下文

如果用户连续多轮都在同一模式下，没必要每轮都重新压缩。可以把压缩后的上下文缓存起来，只增量更新变化的部分。比如订单模式里，订单号没变，就只更新“最近操作”字段。这样能省掉大量重复计算。

6.3 模式继承：子模式自动继承父模式约束

有些模式是包含关系的。比如“退款申请”是“订单服务”的子模式。子模式应该自动继承父模式的约束（如“必须验证用户身份”），同时可以覆盖或扩展。这样模式定义不用重复写，维护成本更低。

7. 我个人在实际操作中的几点体会

这套 context-mode 的思路，我从最早的手工拼接字符串，到后来写规则引擎，再到现在的四层结构，前后迭代了差不多一年半。最大的感受是：上下文管理不是“技术问题”，而是“产品问题”。你得先想清楚用户在这个场景下最需要模型记住什么、忽略什么，然后再去设计数据结构。

另一个体会是，不要追求一步到位。我一开始就想做全自动的模式识别和上下文压缩，结果规则复杂到没人能维护。后来改成“规则为主、模型为辅”，先把高频场景覆盖住，再逐步扩展，反而跑得更稳。

还有一点，监控比设计更重要。上线后一定要记录每次请求的 token 数、模式切换次数、摘要更新频率、检索命中率。这些指标能帮你快速定位问题。我见过太多团队把上下文管理做成了黑盒，出了问题只能靠猜。

最后分享一个小技巧：给每个模式写一个“最小可用上下文”示例。比如订单模式的最小上下文就是“用户ID + 订单号 + 当前问题”。把这个示例作为基准，任何注入的内容如果不能让回复质量明显提升，就果断砍掉。这样能有效防止上下文膨胀。

这套东西没有银弹，不同业务场景需要不同的裁剪策略。但只要你把“模式”这个概念用起来，把上下文当成有状态的对象来管理，而不是一堆字符串，效果一定比全量拼接好得多。