开头我先说清楚这篇文章讨论的context-mode是我在给一个AI售后客服机器人做上下文管理时完整落地的一套“上下文模式”设计方案。它解决的是大模型对话中最常见也最要命的问题——聊着聊着模型就“失忆”前面答应的退款条件后面全忘光或者明明只是随口问一句价格系统却把整本产品手册塞进上下文里结果回答缓慢、费用飙升。如果你也在做基于大模型的产品无论是客服、写作助手还是企业内部知识问答这篇文章里的模式划分、切换规则、压缩策略和踩坑记录都能直接拿来参考。1. 一次真实翻车模型忘了三分钟前自己说过的话事情起因很简单。我们内部上线了一个基于大语言模型的售后客服机器人用来处理退款、物流查询和产品使用问题。刚开始只做了最基础的对话接入也就是用户说一句我们把它拼上历史消息一起发给大模型模型返回一句。听起来没毛病应用层甚至没做任何额外的处理因为模型本身就宣称支持很长的上下文窗口。结果上线第三天用户群里炸了。一个用户提交了退款申请客服机器人明确回复“退款将在3个工作日内原路退回”用户继续追问“那我要不要寄回商品”机器人回答了寄回地址。三分钟后用户又问了一句“你们刚说几天退款来着”机器人居然回答“您好退款将在15个工作日内审核完成”。前后完全矛盾。第一反应是模型抽风。但仔细翻日志问题不在模型而在我们传递的“历史消息”上。为了省事我们把用户进入会话以来的全部消息原样累积在第八轮对话的时候消息总长度已经超过了模型上下文的合理工作区间而系统对超长上下文采取的策略是粗暴截断——只保留最近两轮。之前的退款承诺自然被截掉了模型看到的对话史里只有“用户问退款时间系统答15个工作日审核”这几条于是顺着新信息答了15个工作日。这次事故让我意识到对话上下文绝不是一个“全部拼上就行”的简单东西它需要一套明确的管理模式。后来我把它做成了一套机制名字就叫context-mode。1.1 没有上下文管理的对话为什么必然失控先说一个反直觉的点模型上下文窗口很大并不等于你能放心地把所有东西都塞进去。我做过一个简单实验。一个约8k token的对话历史分别用完整拼装和按固定长度截断两种方式喂给同一个模型结果显示当输入接近窗口上限时模型回答的准确率明显下降具体表现是复述用户名字会出错、中途提到的数字会算错。这不是模型变笨了而是长上下文中存在大量的信息挤压模型对“新近内容”的关注权重天然更高对稍早之前的细节就照顾不到了。为什么会这样可以把它理解成一个会议室。上下文窗口就是会议室里的白板面积你要把用户问题、业务背景、历史问答记录、系统提示词全都写在上面。白板有限写得越多每句话占的位置越小后排的字自然看不清楚。大模型在处理时注意力机制会优先聚焦在近期信息上就像开会到最后谁还记得会议开始时在白板左上角写的那句“本次退款周期为3个工作日”大概率不记得。更麻烦的是成本。token是按输入量计费的上下文越长每次请求的成本越高。内部测算下来如果一个客服会话平均有30轮消息无脑拼装会让单次请求的token数比最初高出约十倍左右。在高峰期每小时几千次请求的场景下这不是一个可以忽略的数字。1.2 很多人对上下文管理的两个错误理解第一个错误理解是“把历史消息全丢掉只保留最近几条不就行了”这条路我也走过。刚开始为了避免上下文过长我们直接做过一个滑动窗口只保留最近6条消息。结果模型彻底“失忆”用户中途补充的一句关键信息比如订单号会被丢掉后续对话接不上。第二个错误理解是“用向量数据库把所有历史拉出来检索一遍每次找到最相关的几条加进去就行了。”这条路能解决一部分问题但会引入新的风险检索本身有误差召回内容可能和当前问题无关反而污染了上下文。我在后文会专门讲这个教训。真正的上下文管理不是简单地“留多少”或“取多少”而是要设计一套基于场景的上下文模式什么时候保留完整记录什么时候压缩成摘要什么时候只取相关片段什么时候彻底清空。这就是context-mode的核心思想。2. context-mode的本质把“全量记忆”变成“分层记忆”想通了前面的问题后我为自己定了一个目标设计一套机制让它能根据当前对话所处的阶段自动决定“模型需要看哪些内容、不需要看哪些内容”。这套机制不再把上下文看成一个整体而是拆成多个层级。2.1 分层记忆的三个核心层级我把对话上下文分成三层。第一层是“即刻信息”也就是当前这一轮用户说了什么加上系统需要立即执行的指令比如“你是售后客服回答必须简洁”。这一层必须完整保留最多控制在少量token以内。第二层是“近期上下文”通常指最近几轮的消息原文。大部分普通对话的语义依赖都集中在这一层用户上一轮说“那我不用寄回了吧”你这一轮就必须知道上轮在聊“是否要寄回商品”否则回答必然跑偏。这一层的保留策略是“原文保留但设上限”。第三层是“远期背景”包括会话早期的关键事实比如用户的订单号、当初承诺的退款周期、产品型号等等。这些内容如果全部用原文保留到会话后期会占掉大量空间如果不保留又会丢失关键约束。所以这一层的策略是“压缩成摘要”或“按需提取”。2.2 模式不是配置项而是状态机很多人在设计上下文管理时会做成一个布尔开关开就全部带上关就只带当前轮。但实际场景里一段对话是不断演化的。同一个用户前10轮可能还在“核对订单信息”中间5轮变成“咨询如何使用某个功能”最后3轮又回到“完成退款操作”。每个阶段的上下文需求完全不同。所以我把context-mode设计成一组可切换的状态每个状态对应一套上下文组装规则。切换条件由对话意图或业务规则触发。例如我最终实现的四种模式连续对话模式用户和客服在解决一件连续的事情采用“原文保留近期上下文远期事实压缩”的策略。任务隔离模式用户突然问了一个和当前任务无关的新问题这时清空前一个任务的对话细节只保留必要的基本身份信息避免两个任务互相干扰。知识索引模式用户的问题明显是询问产品某个功能怎么用此时不依赖对话历史而是从知识库中检索相关内容插入上下文。降本压缩模式对话轮次多、输入token高在确保关键事实不丢失的情况下把整段历史转化成结构化摘要。从状态机角度看context-mode就是定义了一套转移条件什么时候从连续对话切到任务隔离什么时候从任务隔离切回连续对话什么时候整体压成摘要。这个视角比单纯调参数更接近问题本质。2.3 用一段配置描述context-mode的组装规则在设计落地时我并没有在代码里写死逻辑而是用一份配置来描述“模式、输入来源、保留策略”的对应关系。下面是一个简化的示例不是最终生产代码但能帮你理解结构。{ mode: continuous, context_sources: [ {name: system_prompt, strategy: always}, {name: recent_messages, strategy: keep_last, params: {rounds: 6}}, {name: session_summary, strategy: compress, params: {max_tokens: 400}} ] }配合的切换判断用伪代码表示大致是这样def resolve_mode(conversation): if conversation.current_intent in TASK_SWITCH_INTENTS: return isolated if conversation.total_tokens TOKEN_HIGH_WATERMARK: return compressed if conversation.current_intent in KNOWLEDGE_INTENTS: return knowledge return continuous这个结构的好处是调整上下文策略不用改动主流程代码只改配置就行。后面我们在线上调参时频次最高的改动就是换“最近保留几轮”和“摘要上限多少token”这两个数字。3. 我实现的context-mode工作流四种模式与切换规则理论层面理清之后最麻烦的是落地。下面把我实现的四种模式具体展开包括每种模式的设计原因、组装规则和实际效果。3.1 连续对话模式日常对话的主力方案适用场景是用户和机器人在解决同一个问题比如核对订单、查询物流、处理退款。这类对话的特点是话题稳定但关键信息会零散分布在多轮消息里。组装规则是系统提示词完整保留最近6轮消息原文保留更早的历史内容统一压缩成一份总结性摘要。其中摘要由上一轮对话结束时异步生成而不是在每轮请求时临时生成。这样能保证响应速度稳定不会因为生成摘要而额外等待。实施时有个关键点摘要生成任务和用户请求是并行的。当用户还在打字时后台已经在消化前一段对话并生成摘要了。等到下一轮请求进来摘要已经就绪直接拼进上下文即可。3.2 任务隔离模式防止上一个话题污染当前话题这个模式源于一个很典型的翻车案例。用户在聊退款流程聊到一半突然问“你们公司上班时间是几点”。如果不做隔离模型很容易把“上班时间”的话题和“退款流程”的历史糅在一起回答时掺杂上一话题的上下文产生奇怪的回答。任务隔离模式的规则是一旦检测到用户意图与当前任务明显不一致就重新组装上下文只保留系统提示词和用户当前这一轮的输入历史记录暂时移出上下文。但这不等于丢弃历史而是把它们存到会话侧的临时存储中如果用户接下来又切回原任务可以从临时存储中恢复摘要。判断意图切换我最初用规则匹配关键词效果很差。后来改成用一个轻量级的意图分类模型把用户当前输入映射到预设意图集合中再结合“意图变化幅度”决定是否切换。实测准确率在业务场景下能到80%以上规则匹配只有不到60%。3.3 知识索引模式不聊历史聊知识模式名称虽然叫“知识索引”实质是处理“用户问的是一个事实性问题和之前的对话历史几乎无关”的情况。典型场景用户正在走退款流程又问了一句“你们的运费险包括哪些内容”。这时候如果硬要把退款历史塞进上下文模型反而容易被之前的情绪判断影响。知识索引模式的做法是从产品知识库中检索运费险相关说明与当前问题拼装组成一个新的临时上下文。这里我吃过亏为了让回答更“有温度”我最初把最近几轮对话原文也一起放进上下文结果用户问“运费险赔多少”模型回答却提到了用户之前抱怨退款慢的事表达出略带情绪的语气看起来非常奇怪。后来知识索引模式彻底与对话历史解耦只携带用户画像级别的中性信息比如用户是否已购买该产品不带情绪内容。3.4 降本压缩模式当上下文成本高到无法忽略时当一次请求的输入token数明显偏高时就触发降本压缩模式。触发条件我建议用“输入token超过预设水位线”作为硬指标水位线系数可以根据单次请求的成本与回答质量做权衡。这个模式的核心操作是把更早期的大段历史消息全部折叠成结构化的摘要字段比如退款意向: 是 最初承诺退款周期: 3个工作日 订单号: 20240612XXXX 当前进度: 等待用户寄回商品结构化摘要比自然语言摘要更可靠因为它强制模型只保留“事实字段”而不是用自己的语言复述一遍减少信息扭曲。实际效果是在50轮左右的会话场景中单次请求的token消耗从原先的约4000降到约800质量评分基本持平。3.5 模式切换状态机不要让模型替你做判断模式切换逻辑不能放在模型提示词里让模型“根据情况自行决定”因为模型判断不稳定而且每次切换消耗额外token。我把切换逻辑放在应用层用一个独立的模块去处理。事件流大致是用户输入进入后先经过意图识别与模式解析输出一个“目标模式”再结合会话当前模式和历史跳转记录决定是保持原模式还是切换到新模式最后按照新模式的组装规则生成上下文发给模型。整个过程在请求内容提交给模型之前完成不额外占用推理时间。这里要特别提一个细节切换动作本身不应该太频繁。我设定了一个“模式冷却区”30秒内最多切换一次模式。理由很简单很多用户的输入很短意图本身也不稳定比如先问一句产品价格又紧接着追问一句物流时效这在意图上看确实是两个话题但真实场景里用户并没有想“切换任务”只是随口追问。过度切换反而会破坏对话连贯性。4. 关键实现细节窗口切分、压缩策略与召回逻辑模式划分清楚之后剩下的就是三个核心实现问题窗口怎么切、摘要怎么压缩、需要检索时怎么召回。这三个问题是所有上下文管理模式都绕不开的底层能力。4.1 窗口切分不按“条数”切按“token预算”切我第一版实现是按消息条数切窗口保留最近6条。后来发现问题很大有的用户一句话只有几个字有的用户会粘贴一大段报错信息按条数切会导致token预算分配极不均匀。有时6条消息只有200 token有时一条消息就有800 token。正确的做法是转为按token预算切。先设定多个池子的预算比如系统提示词池、近期原文池、远期摘要池然后按优先级从高到低分配。系统提示词固定近期原文池优先但上限控制如果原文超过上限就把最老的消息移出把移出的部分合并进摘要池。切分时我用tiktoken做token计数在消息进入上下文前统一截断到上限。这里要注意必须把“用户侧的字符数”和“实际token数”区分开中文一个字可能对应一到两个token纯按字符截断会出现token数远超预期的情况。4.2 摘要压缩三种策略的对比与取舍摘要压缩是context-mode里最容易做出质量问题的地方。我先后试过三种策略。第一种是自然语言摘要让模型用一段话总结历史对话的“关键信息”。优点是信息密度高缺点是模型会自行发挥偶尔漏掉关键数字或把否定意义的话改写成肯定意义。典型失误用户说“不申请退款了”摘要被写成“用户申请退款”后续对话全乱了。第二种是结构化字段抽取让模型输出一个固定结构的JSON只填关键事实。这个方案最稳定我最终用的就是这个。优点是可验证、可校验缺点是只能抽取预设字段如果某个事实不在预设字段里就会被漏掉。第三种是重要性打分对每条历史消息算一个重要性分数保留高分消息原文。这个方案适合消息条数非常多、但又不想完全转成摘要的场景缺点是打分本身要花钱和时间在低延迟场景下不划算。我用一个表格总结过这三种策略在实际应用中的表现供你参考。压缩策略信息保真度实现成本适用场景自然语言摘要中偶发逻辑反转低一次生成对准确度要求不高的闲聊类场景结构化字段抽取高可校验低一次生成客服、售后、订单等有明确字段的业务场景重要性打分高保真原文较高需逐条打分长文档理解、复杂多轮分析场景4.3 召回逻辑九成的问题不是召回不到是召回了不该召回的东西在设计知识索引模式和远期背景恢复时我使用了向量召回。当时以为这是最简单的路线结果在实测中暴露出不少问题这里我详细说一下。我用embedding模型把历史消息切成片段存进向量库。用户当前问题进来后先转成向量再检索最相近的片段。问题是对话历史里有大量“口语化”内容比如“嗯嗯”“好的”“谢谢”这些内容在向量空间里和任何问题都可能有一定相似度召回来后完全没用却占了上下文空间。另一个问题是语义相似度不等于业务相关性。用户问“运费险保什么”向量召回可能返回一段“用户问退款要多久”的对话因为两个句子中都有“钱”相关的语义特征但业务上并不是用户当前想要的。解决思路是给召回加限制条件限定召回范围必须在同一业务标签下且把召回结果的相似度阈值调高。宁可少召回也不要召回无关内容。后续我又加了一个“召回内容必须与当前模式匹配”的约束比如在知识索引模式下只从知识库里召回不从历史对话里召回在连续对话模式下只从当前任务摘要里召回不从知识库召回。这样看似限制了召回范围实际效果反而好很多。5. 实测数据与踩坑记录把context-mode跑起来之后我做了两周的内部压测结论是方向正确效果明显但过程中踩了三个大坑每一个都值得单独说。5.1 效果对比上线前后的关键指标我选取了100个真实售后会话分别用旧方案全量拼接和新方案context-mode跑一遍集中看几个指标。指标旧方案全量拼接新方案context-mode单次请求平均token数约3800约110020轮以上会话回答一致率41%87%平均响应延迟约2.8秒约1.2秒召回污染导致答非所问次数-从偶发降到极低频回答一致率的变化我最看重。从41%升到87%说明分层记忆对“保持长期一致性”的价值非常大。token成本降了近三分之二但回答质量没有明显下降。这就是上下文模式该有的效果用更少的输入达成更稳的结果。5.2 踩坑记录一模式切换时把“会话中的所有上下文”一刀切清空任务隔离模式上线时我最初的实现是一旦检测到任务切换就清空除了系统提示词以外的所有上下文。这个做法在短会话语境下看起来没问题但在真实售后场景里很快就出事了。一位用户在聊产品使用问题中途问了一句“这个功能收费吗”系统判定为“新任务”把所有产品使用场景的上下文都清了。用户紧接着又问“那我刚才的问题怎么办”模型完全不知道“刚才的问题”是什么只能给出“请您再说一遍”的回复。修复方式是引入“上下文恢复槽”。切换任务时旧的上下文内容不会被清空而是进入一个暂存区比如“任务A上下文存档”同时保留一份摘要级的关键事实。如果模型检测到用户又拉回到任务A的相关话题就恢复存档中的原文或者至少恢复摘要。这个机制大幅降低了切换对长时间会话的破坏性。5.3 踩坑记录二摘要压缩把否定信息压成了肯定信息摘要压缩最隐性的坑是模型在总结时把否定句改写成了肯定句。经典案例是用户说“不要自动续费”模型生成的摘要却是“用户希望自动续费”。原因可能在于模型对“不要”这类否定词的信息敏感度不够或者是在压缩时把用户语气理解为要求保留某种功能。这类问题在人工检查时很容易被忽略因为摘要看起来“信息量很大”但关键语义已经反转了。处理方式有几个组合拳第一所有摘要必须包含原文中的否定词关键片段比如保留“不要”的原文表述第二摘要生成后把其中的事实字段和原文中的关键字段做抽取式对齐不一致时以原文为准第三对高价值操作类对话比如退款、续费、取消订阅不做摘要压缩改为原文保留这类场景宁可多花token也不能冒失真风险。5.4 踩坑记录三检索召回内容污染了上下文前文提过召回污染是知识索引模式的难题。它在实际中还有一个升级版召回了“另一个任务阶段的对话内容”导致模型把不同任务的信息混合起来。举个例子用户在售后任务里问退款进度系统召回了用户在咨询购买时的一句“我要买支持自动续费的套餐”模型在回答退款进度时反而建议用户“继续续费”完全跑偏。修复方式是给召回内容打“任务标签”。存储消息时每条消息都带有任务ID召回时召回范围内必须限定当前任务ID或知识库全局范围不能跨任务召回。这个修改不大但把任务隔离和知识检索结合了起来解决了污染的核心问题。6. 关于context-mode的选型反思与后续扩展文章最后一部分我想聊聊这几天做下来的一些总体反思以及对context-mode未来方向的判断。6.1 为什么我没有直接套用RAG很多人会建议上下文管理直接用RAG不就行了把全部历史文档切片进向量库每次检索最相关的片段拼进上下文。这套路在“知识问答”场景很好用但在“多轮任务型对话”场景并不完全适用。因为任务型对话的关键不在于“哪个文档片段最相关”而在于“多轮之间的逻辑链条完整”比如用户上一轮答应寄回商品这一轮问“地址填哪里”两轮之间没有词语级相似关系但业务逻辑是连贯的。向量检索很难捕捉这种逻辑链条而原文保留和摘要压缩更适合。我最终采用的方案是“RAG与上下文模式配合”知识问答时走检索增强多轮业务对话时走上下文管理而不是用一套方案覆盖所有场景。这个判断我认为是这次实践中最重要的一步。6.2 后续可以考虑的三个扩展方向第一个扩展方向是把上下文摘要做成“异步增量更新”。目前摘要生成依赖上一轮完整对话每次都会多消耗一次模型调用。如果改成增量式的摘要更新比如每轮只计算新增部分与旧摘要的合并费用会进一步下降。第二个扩展方向是让模式切换具备“自学习能力”。当前的模式切换依赖意图识别加规则整体上已经能跑但对一些边缘场景的判断还是不够灵活。后续可以把“最终用户是否满意”作为反馈信号用强化学习的方式自动调整切换阈值。第三个扩展方向是把context-mode推广到非对话场景。例如代码生成工具中是否保留“用户最近的代码编辑记录”作为上下文既能提升代码补全的准确率又能控制上下文长度。这不是AI对话专属的模式而是一种通用的上下文管理思想。6.3 个人体会最后说一点实际操作的体会。context-mode这个概念听起来不复杂但真正落地时你很快会发现它牵扯到的东西非常多意图识别要准摘要压缩要稳模式切换要快召回范围要拧紧。这几个环节单独看都不难难的是组合在一起之后的平衡。我在实际项目里最大的收获不是代码结构设计得多巧妙而是养成了一个“上下文成本意识”每一次往模型里塞内容之前先想一下这块内容是不是真的需要、是不是可以用摘要替代、是不是可以晚点再取回来。长期来看这种意识对AI应用的成本和稳定性都有直接帮助。如果你正在做类似的东西希望这篇记录能帮你少踩几个坑。