上周有个朋友跑来跟我吐槽他做的AI客服机器人聊到第20轮就开始“装失忆”用户在前面确认过的订单编号、收货地址到后面全都不记得用户气得直说“你是鱼吗只有七秒记忆”。我瞄了一眼他的代码发现每次请求都把完整对话历史原封不动塞进prompt20轮下来光历史就占了6000多个token而上下文窗口一共才8000。我没直接给答案只问了一句“你觉得这像是病根吗”他沉默三秒说“是不是得搞个 context-mode”对就是 context-mode上下文模式。大模型应用刚火起来那阵子这个词很少被单独拎出来讲因为大家做的都是demo上下文短、场景简单。可一旦到了生产环境、面对真实用户的连续对话context-mode 就成了决定产品能上线还是只能躺PPT里的分界线。这篇文章想从工程视角把上下文模式讲透为什么要做、怎么设计、参数怎么调、哪些坑必须绕开。不管你做的是AI客服、智能体、知识库问答还是聊天插件这套思维方式都直接用得上。1. context-mode到底在解决什么问题1.1 从一次“失忆”事故说起先回到开头那个客服机器人。用户连续说出自己的需求系统要记住用户的身份、订单状态、设备型号、收货地址等多个信息并在后续对话里持续引用。如果不做任何上下文管理直接把原始消息全部追加进prompt会发生三件坏事。第一是token迅速膨胀。一个订单号加上前后自然语言表述少说20个token一段50字的用户描述大概是70到90个token。十轮下来即使每轮只有两三百字累积的历史也接近2000token。到了三四十轮撑爆上下文窗口是早晚的事。一旦超出窗口有的API直接报错有的默默截断不论哪种对用户来说都是“系统突然失忆”。第二是模型“中段遗忘”。这不是玄学是Transformer注意力机制带来的现实问题。注意力矩阵是平方级复杂度模型在处理超长文本时对中间token的关注度天然低于开头和结尾。换句话说你辛辛苦苦存的20轮对话真正被模型“看见”的可能只有前几轮和最近几轮。前面确认过的关键信息实际上是被淹没了。第三是延迟和成本。token越多prefill阶段计算量越大响应时间肉眼可见往上走按token计费的API每一轮都在为历史消息重复买单。我做过一次粗算一次请求带4000token历史、一天10万次请求按不同模型的价格差异一个月光历史token的成本就可能够买一台开发机。这不是劝退而是必须解决的现实问题。1.2 别把context-mode当成一个现成开关这里要澄清一个容易踩的误区很多人以为context-mode是模型API自带的一个功能打开开关就完事了。确实现在不少服务商提供了类似“自动上下文压缩”“长对话记忆”的选项但你上了生产环境就会明白它通常只是在入口处做简单截断或者把窗口撑大真正要贴合业务逻辑远远不够。我更喜欢把context-mode理解成一套“上下文管理策略”你决定哪些历史消息进prompt、哪些被压缩、哪些被丢弃、哪些被摘要替代以及什么时候触发这些动作。这其实是一个系统工程涉及token计算、压缩策略、摘要触发条件、检索增强的配合甚至还要考虑多轮会话怎么分组。所以后面提到的“context-mode”不是某一个产品里的按钮而是一套可以落到代码里的机制。先把这个认知建立起来接下来的内容才有意义。2. 为什么不能把完整历史一股脑塞给模型2.1 上下文窗口是办公桌不是仓库任何大模型都有上下文窗口。即便某些模型号称128K、200K也不代表你真能无脑把海量文本灌进去。窗口越接近上限模型的注意力质量下滑越明显。你可以把上下文窗口理解成一张办公桌桌面越大能摊开的东西越多但人眼扫来扫去真正仔细看的部分依然有限。更麻烦的是超过桌面边界的材料会被直接扫到地上——对应到模型就是被截断用户前一秒说的关键信息后一秒就被丢弃。所以窗口再大上下文管理也不是可选项而是必选项。窗口大只是让你更从容不会免除你的规划义务。我自己见过不少团队觉得“反正模型支持200K全塞进去就行”结果线上效果一塌糊涂用户多问两句就开始胡说。2.2 信息稀释效应越长越容易“看不见”我用一个生活化现象来解释你读一篇2000字的文章能记住开头和结尾中间很多细节其实是模糊的。大模型也一样长prompt里中段信息的关注度会明显下降。学术界给这个现象起了个名字叫“lost in the middle”中文可以叫“中段迷航”。这个现象带来的直接后果是对话历史越长重要信息被“淹没”的概率越高。信息并没有真正丢失而是在注意力分配中被稀释了。所以context-mode要做的不仅仅是“减少token”还要把重要信息放到显眼的位置。实操中一个很有效的小技巧是如果必须携带较长的前置信息把关键事实放在最后面也就是靠近当前问题的地方同时用摘要压缩掉中段内容让它不再占用太多注意力预算。2.3 成本账单是赤裸裸的很多开发者在初期不算这笔账。我拿一个常见的模型单价举例假设输入每百万token收费20元一次请求带着2000token的历史一天10万次请求那么光是历史token的费用就是2000 × 0.000001 × 20 × 100000 4000元/天一个月就是12万。这还没算输出token。如果通过context-mode把历史压缩到500token成本直接降到原来的四分之一。做C端产品的团队这个优化有时候直接决定商业模型能不能跑通。所以context-mode看着是技术活实际上也是算钱活。延迟上的影响同样直观。大模型的首token延迟高度依赖输入长度我实测过一个常规模型输入从1000token涨到8000token首token延迟能翻三倍还要多。在用户侧这种感觉就是“转圈半天才开始出字”体验非常糟糕。3. 五种主流的context-mode设计怎么选3.1 滑动窗口模式最简单适合轻量场景滑动窗口的思路很直白只保留最近N轮对话更早的一律丢弃。实现起来就是维护一个固定长度的队列新消息进来旧消息出队。优点是简单、稳定、不消耗额外的token去生成摘要线上出问题容易排查。缺点是粗暴被丢掉的旧消息里如果有用户早先提供的关键信息比如手机号、地址后面就再也找不回来了。适用场景是那些对话轮次少、关键信息会不断重提的场景。比如一些简单的问答机器人、表格填报助手用户很少在20轮之后还在依赖第3轮的指令。如果你做的产品就是轻交互滑动窗口完全够用别为了炫技上复杂方案。3.2 摘要压缩模式给对话做“读书笔记”摘要压缩模式的核心是当历史消息累计到一定长度调用模型把“旧对话”总结成一段结构化摘要之后只保留摘要加上最近几轮完整对话。它相当于给对话做读书笔记把长篇对话压成几个要点。这种模式能在保留关键信息的同时大幅降低token占用是目前生产环境里最常见、也最可靠的context-mode实现。缺点是需要额外调用一次模型来做摘要可能引入延迟和成本。另外摘要生成质量如果不好关键信息照样会丢。我做过的客服类项目里效果最稳的组合是保留一份滚动摘要每次压缩时把旧摘要和新对话一起喂给模型生成新的摘要。这样信息可以持续传递而不是每压缩一次就把前面摘要的成果给清零。3.3 检索增强模式让模型“按需查资料”检索增强模式不再保留完整历史而是把每一轮用户消息、系统回复甚至从外部知识库拉到的资料都做向量化存储。每次生成回答前先根据当前问题做相似度检索把最相关的几段历史捞出来拼进prompt。这个模式的优点是理论上的信息量不受上下文窗口限制历史再久也能查到。缺点是实现复杂度高要做向量库、要处理嵌入模型的选择、还要设计相关性的阈值。而且“漏检”是个让人头疼的问题——如果历史关键信息和当前语义不相似检索就捞不回来模型照样失忆。我的体会是检索增强适合和知识库问答结合但它不应该完全替代摘要模式。比较好的产品实践是“摘要保底 检索增强”摘要负责兜底整体脉络检索负责补充特定历史细节。3.4 结构化上下文模式把prompt变成“档案柜”结构化上下文模式是在提示词层面做文章把对话拆分成多个固定区域比如system区放固定的事实和用户画像instruction区放当前指令recent区放最近对话memory区放长期偏好。每个区域承担不同职责模型自然更容易“分门别类”读取信息。这种方式往往不是单独存在的而是跟摘要、检索配合使用。它的价值在于给context-mode提供了一个好的“组织框架”。就算你做了摘要把摘要塞在哪、最近对话放在哪都会影响效果。实践中固定一个模板比每次动态拼prompt要稳定得多。3.5 选型对比一张表说清楚我把几种常见模式的优劣势和适用场景整理成一张选型表方便对照模式核心思路优点缺点典型场景滑动窗口只留最近N轮实现简单、零额外成本旧信息永久丢失轻交互、短对话摘要压缩旧历史变摘要保留关键信息、稳定需额外调用模型、有延迟客服、多轮任务型对话检索增强按需向量检索理论无历史上限架构复杂、可能漏检知识库问答、长会话翻旧账结构化上下文按职责分区组织prompt稳定性高、可解释性强需要设计模板生产级Agent、复杂业务选型时不要只盯着效果还要考虑团队维护成本。我的建议很简单第一版先做滑动窗口跑通后如果发现用户确实需要跨很多轮引用旧信息再升级成摘要压缩模式。直接上来就做检索增强大概率是给自己挖坑。4. 实操从0到1实现一个上下文管理器4.1 先把接口想清楚再动手写码很多人在实现上下文管理时容易犯一个错误上来就写一堆if else把逻辑散落在各个地方。正确的做法是先定义好接口再填实现。我会把核心能力收敛成一个类对外暴露三个方法add_message写入新消息、get_messages取当前prompt、以及内部的压缩触发逻辑。在设计时还需要支持不同模式可选。至少应该支持“关闭上下文管理”“滑动窗口”“摘要压缩”这三种模式。这样你可以随时切换对比效果也方便做A/B实验。我自己在项目里一般还会加一个统计入口用来记录每次请求的token数、摘要触发次数、被截断的旧消息数量。没有这些指标你就只能“凭感觉调参”出了问题无从下手。4.2 核心代码实现我用Python写了一个简化但可运行的版本核心逻辑都放在里面。为了便于阅读我做了必要的精简但关键链路是完整的import json import tiktoken from openai import OpenAI class ContextMode: MODE_FULL full MODE_WINDOW window MODE_SUMMARY summary def __init__(self, modeMODE_SUMMARY, max_tokens6000, keep_recent_rounds2, modelgpt-4o): self.mode mode self.max_tokens max_tokens self.keep_recent_rounds keep_recent_rounds self.model model self.enc tiktoken.encoding_for_model(model) self.client OpenAI() self.history [] self.summary def _count_tokens(self, messages): total 0 for msg in messages: total len(self.enc.encode(msg[content])) return total def add_message(self, role, content): self.history.append({role: role, content: content}) if self._should_compress(): self._compress() def _should_compress(self): if self.mode ContextMode.MODE_WINDOW: return len(self.history) self.keep_recent_rounds * 2 if self.mode ContextMode.MODE_SUMMARY: return self._count_tokens(self.history) self.max_tokens return False def _compress(self): if self.mode ContextMode.MODE_WINDOW: keep self.keep_recent_rounds * 2 self.history self.history[-keep:] return if self.mode ContextMode.MODE_SUMMARY: keep self.keep_recent_rounds * 2 recent self.history[-keep:] older self.history[:-keep] self.summary self._create_summary(older) self.history recent def _create_summary(self, older_messages): # 把旧摘要和旧消息一起喂给模型生成滚动摘要 content f下面是一段历史对话请总结出其中的关键信息包括用户诉求、已确认的事实、待办事项、用户偏好等\n if self.summary: content f\n之前的摘要{self.summary}\n for msg in older_messages: content f\n{msg[role]}: {msg[content]} resp self.client.chat.completions.create( modelself.model, messages[{role: user, content: content}], temperature0.2, ) return resp.choices[0].message.content def get_messages(self): result [] if self.summary: result.append({ role: system, content: f对话摘要{self.summary} }) result.extend(self.history) return result代码里有几个关键点需要说明。第一_should_compress里对token的判断用的是_count_tokens这里我用的是tiktoken对token数做预估比单纯按字符数判断准确得多。如果你接入的模型在tiktoken里找不到对应的编码可以退一步用近似编码或者直接用字符数估算然后打个折扣。第二摘要压缩时我并没有把所有历史都压掉而是保留了最近keep_recent_rounds轮完整对话。这是因为模型回答当前问题时往往最依赖最近几轮的原话如果全压成摘要回答的流利度和准确性都会下降。这个“保留最近完整对话”的细节是生产环境里非常有效的trade-off。第三_create_summary里我把旧摘要也拼了进去让模型基于“旧摘要 更新的旧消息”生成新摘要。这样信息能持续接力不会因为每轮压缩而丢掉前面压缩的结果。4.3 关键参数怎么定三个核心配置项上面代码里有三个关键参数需要重点理解max_tokens决定摘要触发时机。设得太小对话没聊几句就频繁压缩不仅浪费额外调用还可能让摘要信息过于稀疏设得太大又失去了压缩的意义。一般建议把max_tokens设为模型上下文窗口的50%到70%。以8K窗口为例6000比较合理留出足够空间给system prompt、检索结果和模型输出。keep_recent_rounds决定保留几轮完整对话。这个值我在不同场景试下来2到3是比较好的平衡点。保留太少近期对话细节丢失保留太多压缩效果不明显。注意“轮”是用一条user加一条assistant算一轮所以保留2轮对应4条消息。temperature在生成摘要时我设置成了0.2目的是让摘要更稳定、更贴近原文事实。摘要不是创作不需要发散。如果这里的温度太高摘要里会出现模型自己的“脑补”在生产环境是非常危险的事。4.4 接入大模型调用完整链路示例有了ContextMode类之后接进业务代码非常自然cm ContextMode(modeContextMode.MODE_SUMMARY, max_tokens6000, keep_recent_rounds2) def chat(user_input): cm.add_message(user, user_input) resp client.chat.completions.create( modelgpt-4o, messagescm.get_messages(), ) reply resp.choices[0].message.content cm.add_message(assistant, reply) return reply每来一条用户消息先写入上下文管理器再拿去请求模型拿到模型回复后也写入历史。整个过程对外部调用方完全透明。测试时如果要对比效果只要把mode改成MODE_FULL和MODE_WINDOW跑同一批用例就行。4.5 别忘了边界情形上下文管理器有几个必须处理的边界情况。第一是首轮对话摘要还为空时不要调用_create_summary否则会白白浪费一次额外请求。第二是历史消息里如果包含工具调用、函数返回结果这类非自然语言内容摘要提示词里要明确要求“保留结构化数据”否则模型容易把其中的JSON丢掉。第三是并发场景如果多个会话共用同一个ContextMode实例会产生数据串线。生产环境必须做到“一个会话一个实例”或者把状态持久化到Redis这类外部存储。5. 参数调优与效果验证指南5.1 压缩阈值不是拍脑袋定的很多人在调max_tokens时喜欢取整比如直接设8000理由是“反正窗口有8K”。这种做法的问题是没有给模型输出留空间。要知道prompt里除了你的对话历史还要有system指令、检索增强内容、示例few-shot模型才能作答。输出也要占token。如果输入塞到8000输出只能被截断或者被迫变得极其简短。我一般会先统计线上真实请求的token分布然后取P75的prompt长度作为阈值设置参考。什么意思呢把线上样本按token数排序取排在75%位置的那个值。比如统计下来有75%的请求prompt在5000token以内那max_tokens就可以先设为5000之后再观察多少比例的请求会触发压缩。目的是让压缩器“该出手时才出手”而不是让大部分正常请求都白白挨一刀。5.2 摘要提示词用“信息清单法”摘要的质量好坏直接影响context-mode的上限。我踩过最狠的坑是提示词只说“总结这段对话”模型就会输出一段高度概括的车轱辘话比如“用户咨询了订单问题并得到了客服回复”。这种摘要放进后续对话完全没用。解决办法是给摘要规定一个“信息清单”明确列出哪些信息必须保留。我常用的模板包含这几类用户明确提出的诉求、双方确认过的事实订单号、地址、价格、时间、待办动作、用户的情绪和偏好、工具调用产生的结构化结果。可以让摘要模型按清单逐项提取宁可信息冗余一点也决不能把关键事实丢掉。5.3 摘要触发时机的几个候选策略除了简单的“超过阈值就压缩”还可以做更精细的触发策略。比如“只在user消息到来时压缩”可以避免在流式输出过程中反复压缩减少延迟或者“只在历史消息是纯assistant回复、没有正在执行的任务时压缩”避免打断业务状态流转。实测下来最稳的是“用户新消息到来时判断且发生在请求模型之前”因为这时候压缩带来的额外延迟可以和正常请求的延迟重叠一部分用户感知不明显。另一个思路是做分级压缩先触发一次轻量压缩把最近几轮完整对话截断成更短的原文如果还是超限再做摘要压缩。这种渐进策略能减少模型调用次数同时效果也更平滑。建议有精力的团队可以尝试。5.4 怎么验证context-mode没搞坏业务上线前一定要准备一套“回放测试”流程。具体做法是收集一批真实多轮对话数据用旧的未管理上下文跑一遍记录每个回答再用context-mode跑一遍然后逐条对比回答质量。重点看两类样本一类是长对话中后段涉及前文事实的问题验证摘要有没有保住关键信息另一类是对近期原话强依赖的问题比如用户说“把刚才那句话里的价格改一下”验证保留最近轮次有没有生效。我还会额外埋点统计三个指标摘要触发率每百轮对话触发几次压缩、压缩后token下降比例、以及用户侧的“上下文相关错误”发生概率。如果压缩后token降了30%但用户相关投诉反而上升说明摘要质量不过关需要回去优化提示词而不是单纯调阈值。6. 常见问题与排查技巧实录6.1 对话被截断关键信息当场失踪症状是用户提到一个早前聊过的信息模型一脸茫然。排查的第一步不是改代码而是打开日志看一眼那一次请求的prompt到底长什么样。我见过不少“假截断”prompt根本没被截断只是模型生成回复过长被API侧截断了模型后半段内容丢失看起来就像“不记得”。如果是这种解决办法是限制输出max_tokens而不是调整上下文管理。如果确认prompt里确实没有历史信息那就看压缩逻辑。很可能是滑动窗口的保留轮数设得太小旧信息被清掉了。这时候要么把窗口调大要么切换到摘要压缩模式。记住一条铁律先复现现场再动手改参数。6.2 摘要出来一段“正确的废话”摘要提示词没有按信息清单约束或者temperature太高是最常见的两个原因。前者让摘要模型不知道该保什么后者让摘要模型自由发挥过度。我的排查顺序是先看摘要原文如果通篇都是“用户就某个问题进行了咨询”“客服提供了帮助”那就是提示词的问题改用信息清单法重新生成。如果摘要本身看起来有信息量但模型后续没有使用就要检查get_messages的拼接顺序。摘要放在system区只是第一步还要在摘要前面加上“以下信息来自之前对话如果当前问题涉及相关事实请优先参考”之类的引导。不加引导模型可能把摘要当成无关背景直接忽略。6.3 压缩之后回答质量忽好忽坏触发条件不一致是常见病根。比如_should_compress在第一条user消息刚进来时触发了压缩此时最近两条完整对话里可能只有一条user消息没有assistant回复。以此生成的摘要就会缺失模型的答复内容造成后续信息断档。修复方式是给压缩加一个约束只有当history里至少存在keep_recent_rounds轮完整对话即至少包含等量的user和assistant消息对时才允许压缩。不要小看这个边界判断我在线上主要就靠它解决了一大批“偶尔失忆”的问题。6.4 延迟压不下去如果加了一层摘要逻辑每次新消息都要额外调一次模型延迟自然会上升。我的习惯是把摘要模型和主模型解耦摘要用便宜的小模型主对话用大模型。小模型虽然理解能力稍弱但提炼信息清单这种结构化任务完全够用成本低、速度快。另外一个延迟优化点是异步执行。在用户发送消息的瞬间可以先不阻塞而是把摘要压缩任务放到后台执行等用户连续对话的间隙再完成。不过这个方案会带来状态一致性问题需要做好锁和补偿我建议团队有一定基础后尝试。6.5 我的独家排查路径每次context-mode出问题我都按一条固定路线排查拿到样本后先看prompt实际内容确认信息缺失属于“没进来”还是“进来了但模型没用上”第二步看统计指标是摘要触发太频繁还是触发太晚第三步针对性地调参数或提示词而不是一次性改多个变量。最后提醒一句所有上下文管理策略上线前都要做回放测试不然你根本不知道一次参数调整是在帮忙还是帮倒忙。关于context-mode最后想说的做了这么多项目我最大的感受是上下文模式不是那种“跑起来就行”的功能它属于典型的“平时感觉不到、出问题就致命”的后台能力。用户不会夸你“上下文管理做得好”但一旦失忆他们会把这个体验牢牢记住。所以做这模块时别图省事把日志埋点、回放测试、参数文档都补齐这才是长期主义的做法。另外分享一个小技巧我在每个会话的上下文里都会加一段“记忆清单”持续记录当前对话中已经确认的关键事实。这样就算摘要压缩偶尔丢掉某个细节模型还能从清单里捞回来。这个技巧成本极低但对用户体验的提升非常明显强烈建议你也试一试。 上周有个朋友跑来跟我吐槽他做的AI客服机器人聊到第20轮就开始“装失忆”用户在前面确认过的订单编号、收货地址到后面全都不记得用户气得直说“你是鱼吗只有七秒记忆”。我瞄了一眼他的代码发现每次请求都把完整对话历史原封不动塞进prompt20轮下来光历史就占了6000多个token而上下文窗口一共才8000。我没直接给答案只问了一句“你觉得这像是病根吗”他沉默三秒说“是不是得搞个 context-mode”对就是 context-mode上下文模式。大模型应用刚火起来那阵子这个词很少被单独拎出来讲因为大家做的都是demo上下文短、场景简单。可一旦到了生产环境、面对真实用户的连续对话context-mode 就成了决定产品能上线还是只能躺PPT里的分界线。这篇文章想从工程视角把上下文模式讲透为什么要做、怎么设计、参数怎么调、哪些坑必须绕开。不管你做的是AI客服、智能体、知识库问答还是聊天插件这套思维方式都直接用得上。1. context-mode到底在解决什么问题1.1 从一次“失忆”事故说起先回到开头那个客服机器人。用户连续说出自己的需求系统要记住用户的身份、订单状态、设备型号、收货地址等多个信息并在后续对话里持续引用。如果不做任何上下文管理直接把原始消息全部追加进prompt会发生三件坏事。第一是token迅速膨胀。一个订单号加上前后自然语言表述少说20个token一段50字的用户描述大概是70到90个token。十轮下来即使每轮只有两三百字累积的历史也接近2000token。到了三四十轮撑爆上下文窗口是早晚的事。一旦超出窗口有的API直接报错有的默默截断不论哪种对用户来说都是“系统突然失忆”。第二是模型“中段遗忘”。这不是玄学是Transformer注意力机制带来的现实问题。注意力矩阵是平方级复杂度模型在处理超长文本时对中间token的关注度天然低于开头和结尾。换句话说你辛辛苦苦存的20轮对话真正被模型“看见”的可能只有前几轮和最近几轮。前面确认过的关键信息实际上是被淹没了。第三是延迟和成本。token越多prefill阶段计算量越大响应时间肉眼可见往上走按token计费的API每一轮都在为历史消息重复买单。我做过一次粗算一次请求带4000token历史、一天10万次请求按不同模型的价格差异一个月光历史token的成本就可能够买一台开发机。这不是劝退而是必须解决的现实问题。1.2 别把context-mode当成一个现成开关这里要澄清一个容易踩的误区很多人以为context-mode是模型API自带的一个功能打开开关就完事了。确实现在不少服务商提供了类似“自动上下文压缩”“长对话记忆”的选项但你上了生产环境就会明白它通常只是在入口处做简单截断或者把窗口撑大真正要贴合业务逻辑远远不够。我更喜欢把context-mode理解成一套“上下文管理策略”你决定哪些历史消息进prompt、哪些被压缩、哪些被丢弃、哪些被摘要替代以及什么时候触发这些动作。这其实是一个系统工程涉及token计算、压缩策略、摘要触发条件、检索增强的配合甚至还要考虑多轮会话怎么分组。所以后面提到的“context-mode”不是某一个产品里的按钮而是一套可以落到代码里的机制。先把这个认知建立起来接下来的内容才有意义。2. 为什么不能把完整历史一股脑塞给模型2.1 上下文窗口是办公桌不是仓库任何大模型都有上下文窗口。即便某些模型号称128K、200K也不代表你真能无脑把海量文本灌进去。窗口越接近上限模型的注意力质量下滑越明显。你可以把上下文窗口理解成一张办公桌桌面越大能摊开的东西越多但人眼扫来扫去真正仔细看的部分依然有限。更麻烦的是超过桌面边界的材料会被直接扫到地上——对应到模型就是被截断用户前一秒说的关键信息后一秒就被丢弃。所以窗口再大上下文管理也不是可选项而是必选项。窗口大只是让你更从容不会免除你的规划义务。我自己见过不少团队觉得“反正模型支持200K全塞进去就行”结果线上效果一塌糊涂用户多问两句就开始胡说。2.2 信息稀释效应越长越容易“看不见”我用一个生活化现象来解释你读一篇2000字的文章能记住开头和结尾中间很多细节其实是模糊的。大模型也一样长prompt里中段信息的关注度会明显下降。学术界给这个现象起了个名字叫“lost in the middle”中文可以叫“中段迷航”。这个现象带来的直接后果是对话历史越长重要信息被“淹没”的概率越高。信息并没有真正丢失而是在注意力分配中被稀释了。所以context-mode要做的不仅仅是“减少token”还要把重要信息放到显眼的位置。实操中一个很有效的小技巧是如果必须携带较长的前置信息把关键事实放在最后面也就是靠近当前问题的地方同时用摘要压缩掉中段内容让它不再占用太多注意力预算。2.3 成本账单是赤裸裸的很多开发者在初期不算这笔账。我拿一个常见的模型单价举例假设输入每百万token收费20元一次请求带着2000token的历史一天10万次请求那么光是历史token的费用就是2000 × 0.000001 × 20 × 100000 4000元/天一个月就是12万。这还没算输出token。如果通过context-mode把历史压缩到500token成本直接降到原来的四分之一。做C端产品的团队这个优化有时候直接决定商业模型能不能跑通。所以context-mode看着是技术活实际上也是算钱活。延迟上的影响同样直观。大模型的首token延迟高度依赖输入长度我实测过一个常规模型输入从1000token涨到8000token首token延迟能翻三倍还要多。在用户侧这种感觉就是“转圈半天才开始出字”体验非常糟糕。3. 五种主流的context-mode设计怎么选3.1 滑动窗口模式最简单适合轻量场景滑动窗口的思路很直白只保留最近N轮对话更早的一律丢弃。实现起来就是维护一个固定长度的队列新消息进来旧消息出队。优点是简单、稳定、不消耗额外的token去生成摘要线上出问题容易排查。缺点是粗暴被丢掉的旧消息里如果有用户早先提供的关键信息比如手机号、地址后面就再也找不回来了。适用场景是那些对话轮次少、关键信息会不断重提的场景。比如一些简单的问答机器人、表格填报助手用户很少在20轮之后还在依赖第3轮的指令。如果你做的产品就是轻交互滑动窗口完全够用别为了炫技上复杂方案。3.2 摘要压缩模式给对话做“读书笔记”摘要压缩模式的核心是当历史消息累计到一定长度调用模型把“旧对话”总结成一段结构化摘要之后只保留摘要加上最近几轮完整对话。它相当于给对话做读书笔记把长篇对话压成几个要点。这种模式能在保留关键信息的同时大幅降低token占用是目前生产环境里最常见、也最可靠的context-mode实现。缺点是需要额外调用一次模型来做摘要可能引入延迟和成本。另外摘要生成质量如果不好关键信息照样会丢。我做过的客服类项目里效果最稳的组合是保留一份滚动摘要每次压缩时把旧摘要和新对话一起喂给模型生成新的摘要。这样信息可以持续传递而不是每压缩一次就把前面摘要的成果给清零。3.3 检索增强模式让模型“按需查资料”检索增强模式不再保留完整历史而是把每一轮用户消息、系统回复甚至从外部知识库拉到的资料都做向量化存储。每次生成回答前先根据当前问题做相似度检索把最相关的几段历史捞出来拼进prompt。这个模式的优点是理论上的信息量不受上下文窗口限制历史再久也能查到。缺点是实现复杂度高要做向量库、要处理嵌入模型的选择、还要设计相关性的阈值。而且“漏检”是个让人头疼的问题——如果历史关键信息和当前语义不相似检索就捞不回来模型照样失忆。我的体会是检索增强适合和知识库问答结合但它不应该完全替代摘要模式。比较好的产品实践是“摘要保底 检索增强”摘要负责兜底整体脉络检索负责补充特定历史细节。3.4 结构化上下文模式把prompt变成“档案柜”结构化上下文模式是在提示词层面做文章把对话拆分成多个固定区域比如system区放固定的事实和用户画像instruction区放当前指令recent区放最近对话memory区放长期偏好。每个区域承担不同职责模型自然更容易“分门别类”读取信息。这种方式往往不是单独存在的而是跟摘要、检索配合使用。它的价值在于给context-mode提供了一个好的“组织框架”。就算你做了摘要把摘要塞在哪、最近对话放在哪都会影响效果。实践中固定一个模板比每次动态拼prompt要稳定得多。3.5 选型对比一张表说清楚我把几种常见模式的优劣势和适用场景整理成一张选型表方便对照模式核心思路优点缺点典型场景滑动窗口只留最近N轮实现简单、零额外成本旧信息永久丢失轻交互、短对话摘要压缩旧历史变摘要保留关键信息、稳定需额外调用模型、有延迟客服、多轮任务型对话检索增强按需向量检索理论无历史上限架构复杂、可能漏检知识库问答、长会话翻旧账结构化上下文按职责分区组织prompt稳定性高、可解释性强需要设计模板生产级Agent、复杂业务选型时不要只盯着效果还要考虑团队维护成本。我的建议很简单第一版先做滑动窗口跑通后如果发现用户确实需要跨很多轮引用旧信息再升级成摘要压缩模式。直接上来就做检索增强大概率是给自己挖坑。4. 实操从0到1实现一个上下文管理器4.1 先把接口想清楚再动手写码很多人在实现上下文管理时容易犯一个错误上来就写一堆if else把逻辑散落在各个地方。正确的做法是先定义好接口再填实现。我会把核心能力收敛成一个类对外暴露三个方法add_message写入新消息、get_messages取当前prompt、以及内部的压缩触发逻辑。在设计时还需要支持不同模式可选。至少应该支持“关闭上下文管理”“滑动窗口”“摘要压缩”这三种模式。这样你可以随时切换对比效果也方便做A/B实验。我自己在项目里一般还会加一个统计入口用来记录每次请求的token数、摘要触发次数、被截断的旧消息数量。没有这些指标你就只能“凭感觉调参”出了问题无从下手。4.2 核心代码实现我用Python写了一个简化但可运行的版本核心逻辑都放在里面。为了便于阅读我做了必要的精简但关键链路是完整的import json import tiktoken from openai import OpenAI class ContextMode: MODE_FULL full MODE_WINDOW window MODE_SUMMARY summary def __init__(self, modeMODE_SUMMARY, max_tokens6000, keep_recent_rounds2, modelgpt-4o): self.mode mode self.max_tokens max_tokens self.keep_recent_rounds keep_recent_rounds self.model model self.enc tiktoken.encoding_for_model(model) self.client OpenAI() self.history [] self.summary def _count_tokens(self, messages): total 0 for msg in messages: total len(self.enc.encode(msg[content])) return total def add_message(self, role, content): self.history.append({role: role, content: content}) if self._should_compress(): self._compress() def _should_compress(self): if self.mode ContextMode.MODE_WINDOW: return len(self.history) self.keep_recent_rounds * 2 if self.mode ContextMode.MODE_SUMMARY: return self._count_tokens(self.history) self.max_tokens return False def _compress(self): if self.mode ContextMode.MODE_WINDOW: keep self.keep_recent_rounds * 2 self.history self.history[-keep:] return if self.mode ContextMode.MODE_SUMMARY: keep self.keep_recent_rounds * 2 recent self.history[-keep:] older self.history[:-keep] self.summary self._create_summary(older) self.history recent def _create_summary(self, older_messages): # 把旧摘要和旧消息一起喂给模型生成滚动摘要 content f下面是一段历史对话请总结出其中的关键信息包括用户诉求、已确认的事实、待办事项、用户偏好等\n if self.summary: content f\n之前的摘要{self.summary}\n for msg in older_messages: content f\n{msg[role]}: {msg[content]} resp self.client.chat.completions.create( modelself.model, messages[{role: user, content: content}], temperature0.2, ) return resp.choices[0].message.content def get_messages(self): result [] if self.summary: result.append({ role: system, content: f对话摘要{self.summary} }) result.extend(self.history) return result代码里有几个关键点需要说明。第一_should_compress里对token的判断用的是_count_tokens这里我用的是tiktoken对token数做预估比单纯按字符数判断准确得多。如果你接入的模型在tiktoken里找不到对应的编码可以退一步用近似编码或者直接用字符数估算然后打个折扣。第二摘要压缩时我并没有把所有历史都压掉而是保留了最近keep_recent_rounds轮完整对话。这是因为模型回答当前问题时往往最依赖最近几轮的原话如果全压成摘要回答的流利度和准确性都会下降。这个“保留最近完整对话”的细节是生产环境里非常有效的trade-off。第三_create_summary里我把旧摘要也拼了进去让模型基于“旧摘要 更新的旧消息”生成新摘要。这样信息能持续接力不会因为每轮压缩而丢掉前面压缩的结果。4.3 关键参数怎么定三个核心配置项上面代码里有三个关键参数需要重点理解max_tokens决定摘要触发时机。设得太小对话没聊几句就频繁压缩不仅浪费额外调用还可能让摘要信息过于稀疏设得太大又失去了压缩的意义。一般建议把max_tokens设为模型上下文窗口的50%到70%。以8K窗口为例6000比较合理留出足够空间给system prompt、检索结果和模型输出。keep_recent_rounds决定保留几轮完整对话。这个值我在不同场景试下来2到3是比较好的平衡点。保留太少近期对话细节丢失保留太多压缩效果不明显。注意“轮”是用一条user加一条assistant算一轮所以保留2轮对应4条消息。temperature在生成摘要时我设置成了0.2目的是让摘要更稳定、更贴近原文事实。摘要不是创作不需要发散。如果这里的温度太高摘要里会出现模型自己的“脑补”在生产环境是非常危险的事。4.4 接入大模型调用完整链路示例有了ContextMode类之后接进业务代码非常自然cm ContextMode(modeContextMode.MODE_SUMMARY, max_tokens6000, keep_recent_rounds2) def chat(user_input): cm.add_message(user, user_input) resp client.chat.completions.create( modelgpt-4o, messagescm.get_messages(), ) reply resp.choices[0].message.content cm.add_message(assistant, reply) return reply每来一条用户消息先写入上下文管理器再拿去请求模型拿到模型回复后也写入历史。整个过程对外部调用方完全透明。测试时如果要对比效果只要把mode改成MODE_FULL和MODE_WINDOW跑同一批用例就行。4.5 别忘了边界情形上下文管理器有几个必须处理的边界情况。第一是首轮对话摘要还为空时不要调用_create_summary否则会白白浪费一次额外请求。第二是历史消息里如果包含工具调用、函数返回结果这类非自然语言内容摘要提示词里要明确要求“保留结构化数据”否则模型容易把其中的JSON丢掉。第三是并发场景如果多个会话共用同一个ContextMode实例会产生数据串线。生产环境必须做到“一个会话一个实例”或者把状态持久化到Redis这类外部存储。5. 参数调优与效果验证指南5.1 压缩阈值不是拍脑袋定的很多人在调max_tokens时喜欢取整比如直接设8000理由是“反正窗口有8K”。这种做法的问题是没有给模型输出留空间。要知道prompt里除了你的对话历史还要有system指令、检索增强内容、示例few-shot模型才能作答。输出也要占token。如果输入塞到8000输出只能被截断或者被迫变得极其简短。我一般会先统计线上真实请求的token分布然后取P75的prompt长度作为阈值设置参考。什么意思呢把线上样本按token数排序取排在75%位置的那个值。比如统计下来有75%的请求prompt在5000token以内那max_tokens就可以先设为5000之后再观察多少比例的请求会触发压缩。目的是让压缩器“该出手时才出手”而不是让大部分正常请求都白白挨一刀。5.2 摘要提示词用“信息清单法”摘要的质量好坏直接影响context-mode的上限。我踩过最狠的坑是提示词只说“总结这段对话”模型就会输出一段高度概括的车轱辘话比如“用户咨询了订单问题并得到了客服回复”。这种摘要放进后续对话完全没用。解决办法是给摘要规定一个“信息清单”明确列出哪些信息必须保留。我常用的模板包含这几类用户明确提出的诉求、双方确认过的事实订单号、地址、价格、时间、待办动作、用户的情绪和偏好、工具调用产生的结构化结果。可以让摘要模型按清单逐项提取宁可信息冗余一点也决不能把关键事实丢掉。5.3 摘要触发时机的几个候选策略除了简单的“超过阈值就压缩”还可以做更精细的触发策略。比如“只在user消息到来时压缩”可以避免在流式输出过程中反复压缩减少延迟或者“只在历史消息是纯assistant回复、没有正在执行的任务时压缩”避免打断业务状态流转。实测下来最稳的是“用户新消息到来时判断且发生在请求模型之前”因为这时候压缩带来的额外延迟可以和正常请求的延迟重叠一部分用户感知不明显。另一个思路是做分级压缩先触发一次轻量压缩把最近几轮完整对话截断成更短的原文如果还是超限再做摘要压缩。这种渐进策略能减少模型调用次数同时效果也更平滑。建议有精力的团队可以尝试。5.4 怎么验证context-mode没搞坏业务上线前一定要准备一套“回放测试”流程。具体做法是收集一批真实多轮对话数据用旧的未管理上下文跑一遍记录每个回答再用context-mode跑一遍然后逐条对比回答质量。重点看两类样本一类是长对话中后段涉及前文事实的问题验证摘要有没有保住关键信息另一类是对近期原话强依赖的问题比如用户说“把刚才那句话里的价格改一下”验证保留最近轮次有没有生效。我还会额外埋点统计三个指标摘要触发率每百轮对话触发几次压缩、压缩后token下降比例、以及用户侧的“上下文相关错误”发生概率。如果压缩后token降了30%但用户相关投诉反而上升说明摘要质量不过关需要回去优化提示词而不是单纯调阈值。6. 常见问题与排查技巧实录6.1 对话被截断关键信息当场失踪症状是用户提到一个早前聊过的信息模型一脸茫然。排查的第一步不是改代码而是打开日志看一眼那一次请求的prompt到底长什么样。我见过不少“假截断”prompt根本没被截断只是模型生成回复过长被API侧截断了模型后半段内容丢失看起来就像“不记得”。如果是这种解决办法是限制输出max_tokens而不是调整上下文管理。如果确认prompt里确实没有历史信息那就看压缩逻辑。很可能是滑动窗口的保留轮数设得太小旧信息被清掉了。这时候要么把窗口调大要么切换到摘要压缩模式。记住一条铁律先复现现场再动手改参数。6.2 摘要出来一段“正确的废话”摘要提示词没有按信息清单约束或者temperature太高是最常见的两个原因。前者让摘要模型不知道该保什么后者让摘要模型自由发挥过度。我的排查顺序是先看摘要原文如果通篇都是“用户就某个问题进行了咨询”“客服提供了帮助”那就是提示词的问题改用信息清单法重新生成。如果摘要本身看起来有信息量但模型后续没有使用就要检查get_messages的拼接顺序。摘要放在system区只是第一步还要在摘要前面加上“以下信息来自之前对话如果当前问题涉及相关事实请优先参考”之类的引导。不加引导模型可能把摘要当成无关背景直接忽略。6.3 压缩之后回答质量忽好忽坏触发条件不一致是常见病根。比如_should_compress在第一条user消息刚进来时触发了压缩此时最近两条完整对话里可能只有一条user消息没有assistant回复。以此生成的摘要就会缺失模型的答复内容造成后续信息断档。修复方式是给压缩加一个约束只有当history里至少存在keep_recent_rounds轮完整对话即至少包含等量的user和assistant消息对时才允许压缩。不要小看这个边界判断我在线上主要就靠它解决了一大批“偶尔失忆”的问题。6.4 延迟压不下去如果加了一层摘要逻辑每次新消息都要额外调一次模型延迟自然会上升。我的习惯是把摘要模型和主模型解耦摘要用便宜的小模型主对话用大模型。小模型虽然理解能力稍弱但提炼信息清单这种结构化任务完全够用成本低、速度快。另外一个延迟优化点是异步执行。在用户发送消息的瞬间可以先不阻塞而是把摘要压缩任务放到后台执行等用户连续对话的间隙再完成。不过这个方案会带来状态一致性问题需要做好锁和补偿我建议团队有一定基础后尝试。6.5 我的独家排查路径每次context-mode出问题我都按一条固定路线排查拿到样本后先看prompt实际内容确认信息缺失属于“没进来”还是“进来了但模型没用上”第二步看统计指标是摘要触发太频繁还是触发太晚第三步针对性地调参数或提示词而不是一次性改多个变量。最后提醒一句所有上下文管理策略上线前都要做回放测试不然你根本不知道一次参数调整是在帮忙还是帮倒忙。关于context-mode最后想说的做了这么多项目我最大的感受是上下文模式不是那种“跑起来就行”的功能它属于典型的“平时感觉不到、出问题就致命”的后台能力。用户不会夸你“上下文管理做得好”但一旦失忆他们会把这个体验牢牢记住。所以做这模块时别图省事把日志埋点、回放测试、参数文档都补齐这才是长期主义的做法。另外分享一个小技巧我在每个会话的上下文里都会加一段“记忆清单”持续记录当前对话中已经确认的关键事实。这样就算摘要压缩偶尔丢掉某个细节模型还能从清单里捞回来。这个技巧成本极低但对用户体验的提升非常明显强烈建议你也试一试。