我最近把一套跑了大半年的 AI 对话服务翻出来重构最触动我的不是模型换成了哪个而是 context-mode 这一层几乎决定了产品的用户体验上限。同样一个模型上下文拼得好不好回答质量能差出一整个量级拼得不好用户三句话之后就开始跟一个“失忆”的机器人吵架。这篇文章把我踩过的坑、验证过的方案和梳理出的细节都写下来目标读者是想自己搭对话应用的人——不管你是做客服机器人、AI 写作助手还是知识库问答只要和长对话、多轮交互打交道context-mode 的处理方式都值得花时间看一遍。1. 为什么需要单独的上下文模式1.1 对话漂移从一句“它”开始你肯定遇到过这种场景用户问“上次说的那个方案它第三点能再解释下吗”模型如果还记得之前的对话它会自动把“它”指代到“上次说的那个方案”如果模型不记得它要么瞎猜要么直接跟你道歉说“我没有找到相关信息”。这就是典型的对话漂移问题。对话漂移不是模型变笨了而是上下文断了。用人话说模型每一次收到请求都像是一个新员工被临时叫来开会你只把当前这句话递给他他根本不知道前面几十轮聊了啥。我在实际测试里做过一个对照实验同一个模型、同一个问题不带上下文直接问和带上前面五轮对话再问答案准确率差了大概 35% 到 40%。这不是模型问题是 input 构造问题。你喂给模型的信息不完整模型就只能靠猜。context-mode 要做的事情就是管理好“模型每次能看到什么”。它不是一个具体的算法更像是一套组织对话信息的策略。核心思路很简单让模型永远处于“知道来龙去脉”的状态而不是每轮都像第一次见面。1.2 上下文窗口的物理限制你可能会说那把全部对话历史都丢给模型不就行了问题就在这模型有上下文窗口上限窗口是有限的。拿常见的模型举例有的支持 8k token有的支持 32k、64k 甚至 200k。听起来很大对吧但一个汉字大概要占 1 到 2 个 token一屏普通对话内容换算下来可能就要 1000 到 2000 token。如果用户聊了半小时光历史记录可能就超过一万 token再加上系统提示词、知识库片段、工具返回结果很快就触顶了。而且就算窗口够大也不是越大越好。我试过一次把 3 万 token 的完整历史全塞进去模型确实能看到所有内容但回答的聚焦度明显下降——它像是被海量信息淹没了一样经常把早期某个无关细节当成重点来展开该盯住的目标反而丢了。这就像让一个人同时看二十份材料然后做汇报他大概率会抓错重点。所以上下文窗口不是单纯的“能塞多少”而是“该塞什么、不该塞什么”。1.3 上下文模式要解决的两件事把这些问题归结起来context-mode 的核心使命就两件事第一保真。关键信息——用户的意图、任务目标、约定的规则、之前已经确认过的结论——不能被截断、不能被淹没、不能被遗漏。第二聚焦。模型每一轮要处理的信息应该是最相关的那部分而不是把所有历史一股脑堆上去让模型自己去大海捞针。这两件事很多时候是矛盾的。你想保住的信息越多模型的聚焦就越差你想让模型聚焦就必然要砍掉一些内容砍掉的万一恰好是关键信息就麻烦了。一个好的 context-mode 方案本质上就是在“保真”和“聚焦”之间找一个平衡点。下面我拆解几种我实际用过的落地形态每种形态适合什么场景、有什么代价都一起说清楚。2. 上下文模式的三种落地形态2.1 显式注入模式开局就定基调显式注入是最初级但也最常用的一种形态。它的做法是在每一轮请求发给模型之前把系统提示词、用户目标、关键背景信息等作为固定的前缀拼接到消息里。我早期做的知识库问答机器人用的就是这个模式。用户问一个问题我就把检索到的相关文档片段和“你是客服助手回答要简洁不要编造事实只依据给定资料回答”这段系统提示一起拼给模型。这样每一轮模型看到的都是“规则 相关资料 当前问题”不会受之前闲聊影响。这种模式的优点非常明显实现简单、行为稳定、每次请求都是独立的不会出现历史错误被不断放大。但它有个致命短板——完全没有多轮记忆。用户说“刚才那个问题再帮我确认一下”模型根本不知道“刚才那个问题”是哪个。所以显式注入适合的场景是单轮问答为主、对历史依赖不强、需要严格保证每次回答不跑偏。比如搜索问答、文档解析、单步工具调用。如果你要做的是陪伴式聊天或者复杂任务的多轮交互光靠显式注入是不够的。2.2 滚动剪裁模式让模型只看到最近的戏滚动剪裁是目前最主流的上下文管理方式也是我重构之后的主力方案。核心逻辑一句话留下最近的 N 轮对话砍掉更早的。N 的设置取决于你的上下文窗口预算和业务需要。比如窗口有 32000 token你留出 6000 给系统提示和注入材料剩下 26000 给对话历史大约能容纳最近 15 到 20 轮用户和助手消息。这种做法非常实用因为大多数场景下用户当前的问题只依赖最近几轮的信息。一个客服对话用户如果在第 30 轮说“那退款流程呢”模型需要知道的是他当前的诉求和前面提到的订单信息而不是第 2 轮他问过发票怎么开。我用滚动剪裁踩过的坑主要是“窗口大小怎么定”。定太小模型记不住前面的关键约定定太大token 成本哗哗地流而且响应速度也会变慢。后来我总结出一个经验法则先设一个保守值比如保留最近 10 轮跑一个礼拜看用户的平均对话轮数和问题类型再逐步调整。没有万能值只有适合你业务的数值。2.3 分层锚定模式关键信息永远不丢滚动剪裁有个天然缺陷最近 N 轮里的内容不一定是关键信息。假设用户在第 2 轮说过“我需要的是英文报告”第 3 轮又说“预算控制在五万以内”然后接下来聊了二十轮细节等二十轮之后用户说“那按之前的要求出报告吧”滚动剪裁很可能已经把那两条关键信息挤出去了。分层锚定就是为这个问题设计的。它的思路是把上下文拆成两层第一层叫“会话锚点”存放那些从开聊到现在一直有效的核心信息比如用户身份、任务目标、关键约束、已经拍板过的决策。这些内容每一轮都会注入但会被压缩成精炼的要点而不是完整的历史记录。第二层叫“近景对话”就是滚动剪裁里那部分最新的对话轮次保存细节和具体的上下文氛围。我实现的时候会把锚点放在系统提示词里用结构化的方式列出来。比如用户目标撰写一份季度总结报告 关键约束英文、预算五万以内、需要可视化图表 已确认决策采用折线图展示趋势不采用柱状图 待办事项补充竞品分析部分这段锚点每轮都带着但只占两三百 token 的成本换来的是“模型永远不失忆”。近景对话则放在用户消息和助手消息的列表里滚动保留。这三种模式不是互斥的我实际项目里几乎都是显式注入 分层锚定的组合规则和锚点固定注入对话历史滚动保留。下面进入实操层面讲讲怎么把这套东西写进代码里。3. 实操在自己的应用里实现一套 context-mode3.1 数据结构设计消息别只存“内容”很多人做对话应用数据库里就两张表用户消息表、AI 回复表字段就是 id、content、time。这种设计做 context-mode 的时候会非常痛苦因为你不知道哪些对话是“闲聊”、哪些是“关键约定”、哪些内容已经过时。我重构之后采用的是消息列表 元数据标注的结构。每条消息除了 role 和 content还附带一个meta字段里面标记这条消息的类型和重要性。大概长这样message { role: user, # 消息角色system / user / assistant / tool content: 预算控制在五万以内可能超一点也没关系, # 消息正文 meta: { msg_type: user_intent, # 消息类型user_intent / fact / decision / small_talk ... importance: 8, # 重要等级0-10越高越不能丢 ts: 1710000000 # 时间戳排序用 }, extracted_anchor: { category: budget_limit, value: 50000, note: 用户表示可以适当放宽 } }extracted_anchor字段是给锚点提取用的。你可以用程序自动从对话里抽也可以在半自动模式下人工确认。这一步做扎实了分层的上下文管理就有了数据基础。我强烈建议从一开始就别偷懒给消息加上msg_type和importance两个字段。等对话量上来之后你会发现这两个字段在做会话摘要、用户画像分析、问题复盘时全部用得上前期多花一小时的编码后面省的是几天的返工。3.2 注入策略按需组装的模板有了数据结构下一步就是组装。我见过很多人的做法是写一大坨函数把系统提示、历史消息、知识库片段来回拼接最后代码乱成一团。我的建议是用模板 装配器的思路每一类信息都有自己的模板装配器负责按顺序把它们拼成最终发给模型的 messages 数组。下面是一个简化版的 Python 实现体现核心装配逻辑def build_messages(user_query: str, session: Session): messages [] # 1. 系统提示固定规则 system_prompt { role: system, content: ( 你是一名专业的业务助理回答要准确、简洁。\n 如果信息不足明确说明缺失了什么不要猜测。\n 必须遵守会话锚点中的关键约束。 ) } messages.append(system_prompt) # 2. 会话锚点压缩后的关键信息 anchor_text session.render_anchor_text() if anchor_text: messages.append({ role: system, content: f【会话核心信息】\n{anchor_text} }) # 3. 近景对话最近 N 轮按时间正序 recent session.get_recent_messages(max_rounds10) messages.extend(recent) # 4. 当前用户问题 messages.append({ role: user, content: user_query }) return messages这套逻辑看起来简单但细节都在render_anchor_text和get_recent_messages这两个方法里。render_anchor_text负责把锚点转成文本我的经验是一行一个要点用“类别|值|备注”的格式模型理解最稳。比如预算限制|50000|可适当放宽 输出语言|英文|所有报告均需英文 已确认决策|图表用折线图|不用柱状图get_recent_messages也不是简单的 slice我会先按 importance 过滤如果重要等级大于等于 9 的消息掉出了滚动窗口我会把它提升到锚点区如果重要等级低于 3 的消息还留在窗口里我反而会把它提前剔除只保留一个“该轮发生了简单对话”的极简占位防止上下文被无关内容占满。3.3 状态切换与反馈闭环context-mode 真正难的不是函数怎么写而是“什么时候该切换模式”。同一个会话里用户可能在闲聊、在查资料、在改需求、在确认方案这几个状态下模型该看到的上下文完全不同。闲聊时只需要最近两轮就够了改需求时必须把最初的目标锚点和所有已确认决策全部带上查资料时反而要压缩历史给知识库片段腾空间。我采用的方案是给会话建一个“状态机”。定义四种会话状态CHIT_CHAT、TASK_EXECUTION、REQUIREMENT_CHANGE、KNOWLEDGE_QUERY。每轮用户消息进来先用一个轻量分类器判断属于哪个状态可以用模型自己判断也可以跑关键词规则然后按状态选择不同的装配策略。举个例子CHIT_CHAT状态不注入锚点只保留最近 4 轮对话模型语气放开。TASK_EXECUTION状态注入全部锚点保留最近 15 轮。REQUIREMENT_CHANGE状态在锚点基础上额外把“历史所有涉及需求变更的对话片段”搜出来附在后面。KNOWLEDGE_QUERY状态压缩历史到最近 2 轮把检索到的知识片段插到用户问题之前。这个状态机一开始是手工规则判断的后来我改成让模型在每个请求返回一个state字段准确率高很多代价是每轮多花几十个 token。值得。但这里必须提醒一个关键点反馈闭环不能少。状态机判断错了怎么办上下文策略选错了怎么办我当时专门加了一个评估模块每轮请求之后记录“模型是否回答成功”“用户是否追问”“回答是否引用锚点信息”这三个信号。连续三轮出现异常就把这轮的状态识别结果和装配策略打上日志每周复盘一次调整规则和阈值。4. 常见问题与排查实录4.1 模型开始“忘事”了怎么办这是 context-mode 最常见的故障。现象是用户明明一开始就说了“我要 AI 创业方向的报告”结果聊到第 20 轮模型突然把方向理解成了“传统企业数字化转型”。排查路径我建议按顺序来第一步看会话锚点有没有被注入到 messages 里。我把这个检查点叫“锚点可见性测试”——直接在调试终端打印出来看锚点区在不在内容对不对。第二步看锚点是否被后边的内容淹没了。模型虽然有上下文窗口但靠近末尾的指令往往比开头更容易被遵循。所以当锚点很多、重要级别很高的时候我会在用户消息里再加一句话“请注意你之前和用户确认过目标是 XXXX预算 YYYY不要违背这些约束。”这相当于在模型“最容易听进去”的位置再强调一次。第三步如果还是忘就要检查是不是锚点更新时机的问题。很多“忘事”不是忘了而是后来用户改了需求但锚点区还写着旧需求。我踩过这个坑用户第 5 轮说“预算五万”第 18 轮说“算了三万吧”我没更新锚点模型还在按五万执行。后来我专门加了一个变更检测模块凡是检测到“预算”“方案”“目标”这些关键词出现在新的用户消息中就强制触发一次锚点重写把新值替换旧值。对了释放注意历史消息里的旧值要不要删我的做法是锚点区改写历史区保留。因为用户有时候自己都想不起来自己改过模型如果完全没看到旧值遇到用户说“我之前不是说五万吗”反而会懵。而锚点区记录的是最新值历史区保留演变过程两者配合准确率最高。4.2 上下文压缩后回答质量下降滚动剪裁必然导致部分信息丢失回答质量下降几乎不可避免。关键是判断“这轮质量下降是压缩造成的还是模型本身的问题”。我建议用一个“压缩对比”测试法把同样的问题分别用“完整历史”和“压缩后的历史”跑一遍对比两个输出。如果完整历史的输出明显更好说明是压缩策略问题如果两者输出差别不大说明压缩没伤到关键信息问题在别处。压缩质量下降最常见的原因是“一刀切”——不管内容重不重要统一只保留最近 N 轮。解决办法就是我前面讲的importance分级把高优先级的历史片段提取出来放到一个“长期记忆区”哪怕对话已经滚出近景窗口长期记忆区的摘要仍然每轮注入。如果还觉得不够可以用“三句话摘要法”每经过 10 轮对话把前面的内容压缩成三句话——用户说了什么、你确认了什么、现在做到哪一步了。然后把这个摘要替换掉原始的历史记录。实测下来摘要压缩比能达到 20:1 以上关键信息保留率不错成本却能省很多。注意摘要也不是随便写的。我踩过的坑是摘要写得过于泛化变成“用户询问了项目进展”这种摘要对模型毫无帮助。有效摘要要具体到能用于回答的细节比如“用户确认了预算三万时间两周内完成优先用现有团队不考虑外包”。原则就是摘要里出现的每个信息都要能回答未来某个可能的问题。4.3 token 成本和多轮一致性怎么权衡这是每一位做对话应用的人都会遇到的老问题。多塞历史一致性好了但成本上去了压缩历史成本下来了一致性可能崩。我算过一组数据某客服机器人日活 1000 人平均每用户每天聊 30 轮如果每轮都带 20 轮历史按标准模型 token 单价算一个月光对话历史 token 费用就到六位数。但如果把历史压缩到最近 8 轮加锚点摘要费用能降到原来的三分之一回答质量几乎没有明显变化。所以我的成本优化策略是“分层预算”给每轮请求设定一个 token 预算上限比如 8000 token。其中系统提示固定占 2000锚点占 500知识库片段占 2500剩下 3000 给近景对话。哪个模块超出了先砍近景对话再砍知识库片段系统提示和锚点不砍。因为这两部分是保命用的。另外还有一个省 token 的小技巧近景对话里系统消息、用户消息、助手消息的角色其实不必全部原样保留。对于很早之前的轮次可以把“用户问了一句相关内容 助手回复了相关内容”合并成一行摘要。反正模型要去理解的是语义脉络不是逐字记录。这个技巧在长会话中能将 token 消耗降低 40% 左右非常值得试。5. 经验沉淀与调试小技巧5.1 判断上下文模式的触发时机我踩了无数坑之后得到一个最核心的经验不要试图用一个固定策略走完全程。会话状态判断对了context-mode 就成功了一半。现在我的判断流程是这样的每一轮用户消息进来先做三个快速检查——这条消息里有没有出现“你刚才说的”“我之前说的”“上面那条”“那件事”这类指代性词有就必须把足够的历史语境注入进去至少要有上下文锚点。这条消息里有没有出现“不是那个意思”“我要的不是这个”“重新来”“改一下”这类变更信号有就要考虑更新锚点并且把历史中相关的决策对话也一并带上。这条消息里有没有出现具体的时间、数字、名称等需要外部知识才能回答的内容有就优先压缩历史给知识库片段让路。这三个检查可以全部用规则完成不需要每次都用模型判断速度很快。不匹配任何一条的时候才默认进入标准模式。5.2 一个被验证过的小技巧上下文快照最后分享一个我自己觉得特别值的小技巧——上下文快照。做法很简单在用户明确说出“就按这个来”“这个方案定了”“我们确认一下”这类确认性语句时把当前整段上下文保存为一个快照带上时间戳和状态标签。这样做的好处是万一后面聊崩了、用户反悔了、或者模型把方向带偏了你可以直接从最近的快照恢复上下文而不是从零开始重建。我后来甚至把快照升级成了“分支切换”能力——用户说“算了回到刚才那个方案”我直接把上下文切回那个方案对应的快照模型立刻就知道“刚才那个方案”是什么。这种体验上的提升非常明显用户会觉得你做的产品真的记住了他说过的话。快照的存储开销并不大一份压缩后的快照一般几百 token三个月也攒不了几个 G 的文本。对比它带来的体验收益这个成本可以说是微乎其微。5.3 后续还能往哪扩展context-mode 这套东西我目前还在往两个方向折腾。一个是把锚点提取做得更智能化不再依赖关键词规则而是用一个小的 finetune 模型自动从每轮对话里抽关键约束和决策点。另一个是把快照做成可视化的时间线用户在界面上能看到“3 月 2 日确认过预算”、“3 月 5 日改过主题方向”对多轮复杂任务的理解会友好很多。限于篇幅这次主要讲的是思路和关键实现。如果你正在做多轮对话应用建议先把消息结构的元数据字段补上这是所有后续改进的根基。数据结构一乱任何优化都是空中楼阁。等这层打牢了再一步步加状态判断、加锚点、加快照你会发现在 context-mode 上的每一点投入最后都会实打实地兑换成模型回答质量的提升。