先讲个现象。我用各类智能编码工具的时候同一段需求描述同一个模型新开一个对话往往答得又快又准聊到二十轮以后哪怕模型再强也会开始犯一些低级错误比如把刚确认过的字段名忘掉、反复给同一个接口做无意义的修改。过去我一直以为这是“模型变笨了”后来把这些案例拉出来做排查才发现问题大多出在上下文的组织方式上。context-mode这类能力就是专门用来缓解这种问题的。这篇不铺垫太多理论直接说人话context-mode到底是什么、底层怎么运作、适合用在哪些场景、怎么配置才不容易出幺蛾子以及我在实际项目里踩过哪些坑。看到这篇文章的朋友应该可以分两类一类是正在做智能体、对话机器人、文档问答这类产品的研发另一类是把这类工具当生产力的人。不管哪一类我都保证你读完以后能把“上下文”三个字从玄学变成工程。1. context-mode 其实是一套“上下文经营策略”1.1 为什么上下文会越用越乱先说一个特别容易误解的事模型本身没有“记忆”。你感觉它记得住你之前说过的话是因为每次请求都会把“之前说过的话”再次送到模型面前。也就是说模型每回答一次你付出的实际请求内容会越来越长长到最后一次对话时它眼前摆着一大摞历史资料。我习惯用一个类比来理解这件事模型是一个开完会就得马上做决定的部门领导会议室里站满了人每个人手里都举着一张纸条。纸条越多领导越难分清到底哪张重要。如果某张纸条上写着今天要发布的版本号结果被挤到最底下领导很可能就按三个月前的旧版本号去执行了。这种状态在工程上有个很形象的称呼叫“上下文坍缩”不是模型缺失能力而是重要信息被淹没在大量低价值信息里模型“看不过来”。context-mode解决的就是这个“看不过来”的问题。它不等同于“把历史消息都传给模型”而是一套主动干预上下文内容的管理策略让你决定这一刻模型到底应该看到哪些纸条、纸条按什么顺序排、旧纸条什么时候应该被撤下来。1.2 context-mode 的本质规划、组装、维持如果你把市面上各种工具里的context-mode都拿来解剖一遍会发现它基本由三件事组成。第一件事是规划也就是在对话或者任务开始之前先定义清楚哪些信息属于当前问题的核心上下文。比如做代码审查时核心上下文是这次变更的 diff、关联模块的接口定义做长篇小说续写时核心上下文是人设卡、前文梗概、当前章节大纲。规划得越清楚后续的注入就越轻松。第二件事是组装指把不同来源的信息按重要性和逻辑顺序拼接成一个连贯的提示再送给模型。这一步看起来简单实际坑特别多。先放任务描述、再放参考资料、最后放历史对话和先放历史对话、再放参考资料、最后放任务描述得到的回答质量经常能差出一大截。第三件事是维持指上下文不是一成不变的它会随着对话推进不断更新。旧消息要压缩、过期信息要移除、新事实要补进来。很多context-mode实现里有一个“衰减”或者“过期”的概念目的就是防止旧内容把新内容挤掉。你如果在这三件事上任何一个环节偷懒最后表现出来的都是同一个症状模型答非所问或者输出内容“前三句正常后三句开始胡编”。2. 拆开看 context-mode 的核心机制2.1 token 预算是所有问题的根源做context-mode调优最先要建立的概念就是 token 预算。模型的上下文窗口是有限空间输入和输出共用这个空间。输入越长留给输出的空间就越小输入超过上限最常见的处理手段就是“截掉最早的内容”。这个“截掉最早”的策略非常粗暴它不区分哪句话重要只认时间顺序。你在对话第三轮说的一句“后端接口返回的字段名叫 order_id”如果到第二十轮才真正用上很早就被截掉了这时候模型就会一本正经地猜一个新字段名。所以我给自己定了一个死规矩凡是后面必须要用的关键信息必须通过某种机制反复出现在新鲜区域里或者干脆塞进一个固定的“常驻上下文”区块不能只靠历史对话自然保留。tokens 有限是客观约束我们做不到无限扩大窗口能做的是在有限空间里做更聪明的取舍。2.2 三种常见的上下文注入方式我见过的context-mode实现底层大多跑不开下面三种注入方式实际产品里往往是两三种混用。静态注入最容易理解。任务开始之前就把最重要的背景知识全部放进输入比如系统提示词、角色设定、项目说明。它的优点是很可控缺点是占地方。一个设计不合理的团队机器人可能会把一份 8000 字的规章制度全文塞进每个请求里光这一项就吃掉大量 token。静态注入要定期做减法。检索注入是目前智能问答类产品最主流的方案。它先把文档做切片并转成语义向量用户提问后从向量库里找出相似的几个片段再把这些片段作为上下文注入。这种方案的好处是不用把所有知识都放进去只在用到的时候“临时取证”。但它的缺点是检索质量不稳定一旦查出来的片段和问题对不上模型就会拿着不相关材料硬答这时候context-mode反而会放大错误。摘要注入是第三种也是长对话里最实用的一种。系统定期把一段历史对话压缩成摘要替代原始对话再作为上下文。比如每聊五轮就把前五轮的核心结论抽取出来扔到上下文的最前面同时把详细对话从历史里标记为可丢弃。这么做能让上下文窗口长期保持一个比较稳定的占用率不会因为聊太久而爆炸。2.3 一次 context-mode 生命周期的完整走向我在自己负责的一个文档问答模块里给context-mode定义过一条完整生命周期参考价值比较大分享给你。第一段是激活阶段。用户发送首个问题模块判断这个问题是否需要额外背景如果需要就把用户身份、项目代号、相关文档索引一并拉出来。第二段是检索阶段。根据问题关键词召回文档片段然后用重排模型过滤掉明显无关的内容保留三到五个切片。第三段是合成阶段。把任务说明、检索切片、最近两轮对话按顺序拼接交给模型生成回答。第四段是归档阶段。把当前这轮问答写入滚动消息列表同时检查消息列表长度是否超过阈值如果超过就自动提取摘要把最早的消息替换为简洁版的摘要。第五段是失效阶段。用户开启新任务或者会话超过预设时长系统清空当前会话的上下文状态回到激活前状态。这五段里面最容易被忽略的是归档和失效。不少团队只用前三个阶段觉得上下文模式就是“查完资料拼一下”。结果对话一长照样出问题。上下文持续的维护动作跟最初的注入同样重要。3. 实操把 context-mode 配置出最佳效果3.1 判断到底该不该开启 context-mode不是所有场景都适合开启完整版context-mode。我用一个极简单的判断表来决定开关你可以直接抄。短任务、单轮问答比如“把这句话翻译成英文”“帮我给这段文字起三个标题”默认不开因为这类任务依赖的知识量很小开启上下文管理只会增加延迟和 token 消耗。中等任务比如“根据这份需求文档写一版接口设计”默认开但注入范围严格限制在当前文档内。长周期任务比如“陪我把这个项目从零写到能跑”必须开而且还要配摘要机制和定期清理规则。还有一种情况要反着来偏创意发散的任务比如头脑风暴、写广告语、做发散联想我反而建议把上下文模式调成低干扰。因为这类任务需要模型放开限制如果给它注入太多前置背景思路会被框住。3.2 用最少必要注入原则配置内容源我再给一条核心原则叫“最少必要注入”。意思是每往上下文里塞一段内容都要能回答一个问题如果这段内容缺席模型给出的答案会不会变差如果不会那就不该放。信息化成具体配置我一般会分成三个区块。人和场景区固定放角色设定和用户最新的核心诉求控制在 200 到 400 字。事实区放所有当前必须遵守的硬性事实比如接口名、字段名、版本号不要放宣传文案、产品愿景这类软信息。参考资料区放检索到的文档切片切片量宁少勿多我一般限制在五篇以内超出五篇之后命中率上升幅度明显变小。写成配置逻辑大概是这样的仅供参考不同产品的写法会有差异def build_context(role, facts, refs): context [] context.append({type: fixed, content: role}) context.append({type: fixed, content: facts}) for ref in refs[:5]: context.append({type: reference, content: ref}) return context注意我这里把角色和事实放在最前面参考资料放后面。原因是靠前的内容会被模型更重地对待。你如果把自己的产品抓包看一下真实请求会发现很多项目把历史对话放在最前面系统提示词反而被挤到后面这种顺序问题会导致模型对系统约束的表现力明显下降。3.3 给 context-mode 配一套信息保鲜机制上下文的新鲜度比数量重要。我做过一次很典型的数据对比同样一个 200 轮的长对话不清理旧上下文模型对早期确定信息的正确引用率在 100 轮之后跌到了 54%每 15 轮自动做一次摘要清理正确引用率能维持在 85% 左右。所以我现在的每个项目都会配一套保鲜规则。第一条给关键信息打标签凡是被标记为核心事实的句子不允许被滑窗截掉。第二条设置清理触发条件可以用轮数做阈值也可以更聪明一点用 token 占用率做阈值比如上下文占用率超过 70% 就自动触发压缩。第三条过期归档某个子任务已完成的上下文移出活跃区摘要保存遇到相关问题再取出来。这三条都做对了context-mode才真正算是“模式”而不是一个永远开着的背景灯。3.4 一个可复用的效果验证方法每次调完context-mode不能只靠“感觉回答变好了”就收工。我一般会准备 20 个覆盖典型场景的测试问题固定模型版本跑两轮打分。第一轮看召回回答里有没有把正确事实带出来比如问“支付回调地址是什么”能不能答出正确的 URL。第二轮看污染回答里有没有引用不该出现的上下文比如问 A 模块的接口结果答案把 B 模块的内容混进来了。这两轮分数都过了 90%我才会把配置推到生产环境。这种验证方式成本很低但能快速暴露上下文模式最常见的两类问题信息缺失和信息混杂。4. 常见问题与排查技巧实录4.1 上下文污染无关信息抢占注意力这是在文档问答类产品里出现频率最高的问题。用户问了一个问题系统从向量库里召回的切片不相关但还是被强行拼进上下文里模型就顺着这些不相关内容开始发挥最后给出一个看起来很有道理、实际上完全跑偏的答案。我之前排查过一个案例用户问“订单超时之后还能不能发起退款”结果召回切片里有一段讲“退款超时时间如何配置”的文档两个概念很接近但适用范围完全不同。模型没有能力区分就混着答了。解决办法是在接入上下文之前加一道重排过滤把相关性打分过低的切片直接丢掉同时在提示词里写清楚“只依据参考资料回答参考资料不足时明确说不知道”。后者可以显著降低模型“被无关上下文带跑”的概率。4.2 关键内容被截断早期事实凭空消失长对话里最容易发生的就是“记了后面忘了前面”。前面聊过用户偏好深色主题后面做界面方案时模型浑然不知给了一套浅色方案。你以为是模型特性问题其实是早期上下文被滑窗截断了。排查方法很简单把发送给模型的真实请求打印出来看消息列表里有没有那条早期信息。没有就是被截断了。解决手段有两个方向一是把关键信息往上提通过摘要把它固化在靠前的位置二是用外部状态存储比如把用户偏好写进固定的 profile 字段每次请求都重新注入不依赖对话历史自然保留。4.3 上下文过期模型还在按旧配置执行还有一种问题比截断更难察觉叫上下文过期。系统提示词里写着“当前版本是 2.3”结果产品已经升到 2.5 了但对话会话还在继续模型继续按 2.3 的接口文档给建议。这个问题的根源往往不在上下文窗口大小而在于上下文没有失效机制。解决方法是给每个会话上下文加一个版本号或者时间戳发现版本变化时强制清空会话重新创建新的context-mode状态。别嫌粗暴这是目前最可靠的做法。你想让模型自动判断哪些旧知识该舍弃、哪些该保留其实非常困难工程上不如直接换会话。4.4 性能与费用失衡上下文越大并不是越好有人以为上下文模式开得越重输出质量就越高于是把所有项目资料全部塞进输入里。结果模型回答质量没提升多少首字响应时间却从 1 秒涨到 3 秒API 账单涨了接近一倍。我也这么干过后来做了对比才发现输入长度超过一定阈值后质量提升曲线非常平缓但成本曲线接近直线上升。所以我现在有一个比较极端的习惯生产环境里静态固定上下文不超过 2000 token检索切片总量不超过 3000 token历史对话经过摘要后不超过 2000 token。总体控制在 7000 token 以内。如果某个场景真的需要超大输入我会先考虑拆分任务而不是硬塞给单次请求。问题表现主要原因快速排查手段答非所问无关上下文注入检查输出引用来源打印检索切片遗忘早期事实滑窗截断查看真实请求确认信息是否存在于消息列表按旧信息执行上下文过期核对会话版本号与当前版本是否一致响应慢且贵冗长冗余上下文统计 token 分布削减静态固定段和冗余切片5. 我实测下来的一些配置倾向如果不想每个细节都重新调可以直接参考我近半年来比较稳的一套配置倾向。短问答类产品关闭复杂检索只把用户最新的问题和基本角色设定传进模型历史只保留最近一轮。理由是这类产品用户预期是快问快答不需要长篇背景任何额外上下文都是延迟和噪声的来源。代码助手类工具开启context-mode聚焦当前文件内容、相关符号定义、最近一次报错栈不要注入整个代码仓库最好基于代码索引做检索只把跟当前文件有依赖关系的片段拉进来。文档知识库类产品开启完整版重排过滤必须做切片数量控制在三到五个同时加一个明确的兜底话术避免模型在检索内容不足时强行编造。另外我还有一个习惯在提示词里配合一句话使用“你只能基于提供的上下文内容回答如果上下文里没有对应信息直接告诉我还缺什么资料。”这句话听上去很基础但它能把context-mode的收益放大不少。因为很多模型在信息不足时倾向于顺着上下文语气继续编加了这条限制之后编造率会明显下降。最后多提一嘴context-mode不是银弹它会引入新的不确定因素。配置完之后一定要做回归测试最好固定一组测试集每次改动都跑一遍。上下文这种事光靠肉眼感觉靠谱没用还是得让数据说话。