1. 为什么“context-mode”是比模型本身更能决定体验的变量前几天有个做 AI 应用的朋友找我调问题他基于大模型做了一款内部客服助手上线后用户聊个七八轮就开始“打太极”。他把模型换成更强的版本问题依旧。后来我们打开日志才意识到真正管不住的是上下文——每次请求发出去模型看到的内容早就乱了。这就是很多人低估的 context-mode。把大模型真正落到产品里模型本身的推理能力只是下限上下文怎么组织才是拉开体验差距的上限。同一个模型有人拿它做出来的 Agent 条理清晰能在一个小时的长对话里记住关键承诺有人做出来的机器人三句话就“断片”差别基本都出在这里。context-mode 不是某个 API 开关它指的是对上下文进行选取、裁剪、压缩、索引和注入的一整套工程策略。它要解决的问题非常现实一是模型的上下文窗口再长也是有限的总有装不下的时候二是每次都把所有历史原样塞进去成本和首字延迟双双爆炸三是无关信息越多模型越容易被带偏回答准确率不升反降。我见过太多团队死磕提示词和模型选型却没发现真正拖后腿的是上下文治理。这篇文章就是我自己在这类项目里的实操复盘。会讲清楚 context-mode 有哪些常见流派怎么选型怎么落地以及踩过的坑。适合正在做 AI 客服、Agent、RAG 问答和大模型应用的人参考。1.1 先看三个数字成本、延迟、准确率先说成本。假设客服机器人平均聊 15 轮解决一个问题按每轮中英文混合约 400 token 估算15 轮原始文本就有 6000 token。如果每个环节都把整段历史原样发给模型一次完整服务可能要调用 5 次模型累计输入就是 3 万 token。用户量上来以后这串数字会直接反映在账单上而且完全是可以避免的浪费。再说延迟。上下文越长模型首字返回的时间就越长。同样一次请求300 token 和 20000 token 的输入首字延迟可能有几百毫秒的差距。在客服这种对响应时间敏感的场景里用户不会等一个转圈的机器人太久。最后是准确率这个往往最隐蔽把 50 轮的完整对话全部塞进模型中间轮次的关键信息会被注意力稀释而寒暄和重复内容反而成为显眼信号模型自然容易被带偏。这也是为什么我说 context-mode 本质上是一种记忆治理。我们需要模拟人脑的短期记忆和长期记忆机制保留该保留的压缩可以压缩的丢弃应当丢弃的。本文后面所有方案都是围绕这三个动作展开的。1.2 适合谁看能解决什么问题如果你是刚接触大模型应用这篇文章能让你少走三个月的弯路。它会告诉你不要上来就想上多复杂的向量检索先用滑动窗口加摘要压缩就能解决八成问题。如果你已经在跑线上项目第四节的坑位清单和监控指标可以直接抄作业。如果你在做多智能体或者更复杂的 Agent第五节给出的共享上下文思路会给你一个扩展方向。2. 上下文模式的五种常见形态与选型逻辑很多人第一次搜 context-mode看到的是一堆碎片化名词滑动窗口、摘要、向量库、记忆池。这些其实不是互相替代的关系而是不同记忆粒度的实现手段。这一节我带你把五种主流形态过一遍每种的优缺点适配场景都讲清楚。2.1 滑动窗口最简单但也最“健忘”滑动窗口的思路很直接只保留最近 N 轮对话超出窗口的部分直接丢弃。实现上几乎零成本就是在组装请求时从消息列表末尾取一段。# 伪代码只保留最近 window_size 轮 def build_context(messages, window_size10): recent messages[-window_size:] # 系统提示词永远要保留在最前面 return [system_prompt] recent优点是简单、稳定、延迟低。缺点是毫无长期记忆用户上一轮提过的重要约束聊到第十一轮可能就没了。它比较适合两类场景一类是任务型对话比如查天气、订闹钟、调工具这类对话天然不需要记太久另一类是早期 MVP先用最朴素的方式跑通流程后续再迭代。我自己做工具调用类 Agent 时初期用的就是 10 轮窗口效果稳定问题出现在用户开始依赖它做多步操作之后。2.2 摘要压缩用“遗忘”换“记忆”摘要压缩是目前性价比最高的方案。它在对话超出阈值时不是把旧消息丢掉而是先让模型把旧消息压缩成一段摘要再放进上下文。新消息保持原文摘要负责承载更早的信息。这么做的好处是上下文增长是缓慢的、可控的。缺点也明显摘要本身有信息损失而且压缩动作需要额外的模型调用会带来延迟和成本。但实测下来只要压缩策略写得好损失是可以控制的。我在客服项目里用过这个方案22 轮之后模型依然能准确说出用户在第七轮提过的退款金额。2.3 分层记忆把上下文做成三级缓存如果你有开发经验可以把分层记忆理解成 CPU 的多级缓存最热的数据放 L1稍旧放 L2更早的放 L3。对应到对话场景就是L1最近 3 到 6 轮原始对话保留完整细节L2较早对话的滚动摘要按每段时间段生成L3摘要再摘要或者沉淀下来的用户画像、关键事实每次请求组装时L1 永远完整保留L2 按需带上一部分L3 只在涉及长期记忆的任务中注入。这种结构兼顾了短期精度和长期记忆但逻辑复杂度明显上升需要有一层专门的状态管理。适合对话轮次非常长、记忆要求高的产品比如心理陪伴类、深度咨询类、项目协作类应用。2.4 向量检索外置的长期记忆向量检索是把历史消息切成块做 embedding存进向量库。每次请求时把当前问题转成向量去库里找最相似的历史片段然后拼进上下文。它的真正优势是支撑超大历史规模。十万条历史消息不可能塞进有限上下文但可以用向量库当外挂大脑。但它有个很值得警惕的问题相似度高的片段未必是时间上最相关的。比如用户昨天订过酒店今天问机场路线检索到的可能是昨天那段订酒店闲聊而不是上周提过的航班信息。所以做这个方案时最好在检索结果里混入时间权重让近期片段优先。2.5 混合模式工程上的最终归宿落地项目做久了会发现单一模式永远不够用。现在比较成熟的架构是“五段式”混合上下文系统提示词固定不变最近 3 到 6 轮对话原文从会话开始到现在的滚动摘要向量库命中的历史片段工具或数据库返回的结果我自己的落地经验是先按这个骨架搭起来再根据场景增删。混合模式并不是把所有技术都堆上去而是让每一层各司其职原文保细节摘要保时间线向量保长尾记忆工具结果保事实。模式记忆长度实现成本主要风险推荐场景滑动窗口低极低信息丢失任务型对话、MVP摘要压缩中高中摘要失真客服、咨询分层记忆高高状态复杂长期陪伴型应用向量检索很高中高相关性偏差知识库、RAG混合模式可调高组合噪声生产级 Agent3. 从零搭建一套可靠上下文模式实操、参数与调优看完方案选型很多人的下一步是直接写代码。但我劝你先停下来做一次场景分析。因为 context-mode 没有银弹与其抄一个复杂的方案回来调不通不如先搞清楚自己要什么。3.1 选型之前先问自己四个问题第一个问题是对话轮次到底有多长。如果你的用户平均聊 5 轮就走滑动窗口完全够用如果动辄聊上百轮就必须考虑分层或者向量方案。第二个问题是关键信息出现在上下文哪个位置。中间位置的信息最容易丢失如果这些信息是业务强相关摘要压缩就要做得非常细致。第三个问题是延迟预算。压缩和检索都会增加耗时实时性要求高的产品要控制每轮调用的模型次数。第四个问题是成本敏感度。有些场景 p95 延迟比成本更敏感反之亦然。我的建议是做一个简单的表格填一下平均轮数、单轮 token 数、可用首字延迟、单次会话预算、关键信息热点位置。填完以后选型基本就出来了。比如单轮 token 少、轮数多、预算有限那就别犹豫摘要压缩起步。3.2 滑动窗口落地的两个容易忽视的细节直接取最近 N 轮看起来简单但有两个细节容易翻车。第一是按“轮”切分不是按消息切分。一个轮次包含用户消息和助手回复如果按消息切可能把用户的问题留下了把模型刚才的回答截掉了导致上下文不完整。第二是窗口切割后要保证内容语义连贯。假设窗口恰好从用户的一句“那你再帮我看看”开始模型看到的是一个没有前因后果的半句话自然无法正确回答。所以我建议实现时按消息组切分并保留最小完整轮次。同时为了控制 token可以对每条消息做截断比如每条最多保留 300 字而不是无脑保留整条。这样窗口能容纳的轮次更多信息密度反而更高。3.3 摘要压缩的工程化实现摘要压缩的整个链路是维护一个 running summary每次新对话进来时判断上下文是否超阈值如果超了就把 running summary 和最早一段对话一起交给摘要模型生成新的 summary然后把原始对话从上下文中移除。判断阈值时我习惯用 token 数量而不是消息条数。控制变量是 max_context_token比如窗口是 8000 token日志超过 6500 token 就触发压缩。阈值建议设置在窗口的 75% 上下留出摘要模型输出和本轮新内容的空间。摘要提示词我踩过不少坑。初期用的提示词太笼统比如“请总结对话要点”结果把退款金额这种关键数据丢了。后来改成结构化要求请对以下对话进行压缩必须保留人名、身份、时间、地点、金额、结论、承诺事项。 忽略寒暄、重复表达、语气词、与任务无关的闲聊。 输出为一段流畅文字不超过 300 字。 对话.../对话实测下来这种字段式约束能显著减少信息丢失。不过要注意摘要本身也是模型生成的仍然存在二次压缩时的信息损失。我的处理方法是做两层摘要先按时间分段生成分段摘要最后在检索到该时间段时再生成总摘要。这样每次压缩只做一次信息取舍不会因为反复摘要而失真。3.4 缓存层把成本和延迟一起降下来很多人做 context-mode 只关注内容怎么组织忽略了缓存。实际上系统提示词和早期摘要基本是固定的这些内容每次请求都重新编码一遍纯属浪费。在大模型推理服务里前缀缓存可以让相同前缀的输入跳过部分计算大幅降低首字延迟。实操上把一个调整好的五段式上下文按稳定程度排序最稳定的系统提示词放最前面。保证同一会话内前缀尽量稳定不反复修改。这样每次请求只有末尾的新内容需要完整计算之前的编码结果可以被复用。我实测过的项目里这一项优化能把首字延迟降低接近一半。3.5 监控上下文模式的三项核心指标没有一个指标你很难判断 context-mode 调整得好不好。我长期盯三个数字有效记忆率在对话进行到第 N 轮时问一个第 N-10 轮的信息看模型能否答对。上下文利用率每次请求实际消耗的 token 数是否超过了设定阈值。首字延迟与 p95保证体验不失控。每次调整参数以后跑一组固定测试集把这三个指标拉出来对比。很多团队喜欢靠感觉调参这是最忌讳的。上下文模式的优化非常容易被线上样本淹没一定要有量化反馈。4. 实战中的高频问题与避坑记录做完这套东西之后我又在真实项目和社区交流中攒了一批问题。挑几个典型的说。4.1 挂了 context-mode为什么还是“失忆”最常见的原因并不是策略不对而是组装上下文那一步根本就没生效。很多框架里配了窗口参数但实际发到模型接口的 message 列表仍然包含全部历史。排查思路很简单在调用模型前打印一次实际请求体确认发给模型的到底是什么。我见过不止一次开发调试时看的是本地拼接结果线上跑的却是另一套逻辑。另外一个原因是系统提示词被窗口截断了。有些实现是直接对 message 列表从尾部截取忘了把最前面的系统提示词冻结保留。系统提示词一旦被挤掉模型相当于失去了基础行为约束后面无论怎么配上下文都会乱。4.2 摘要压缩把关键细节压没了这个问题的根源在摘要提示词的颗粒度。如果你只写“总结要点”模型大概率输出一个模糊的概貌。我的做法是把必须保留的字段全部列出来甚至做成固定模板。尤其是在客服和交易场景“金额、商品、时间、承诺、售后方案”这些字段一个都不能少。还有一个技巧是给摘要加一个“意外发现”通道。当模型在压缩时发现一条与之前摘要矛盾的信息单独写入一个“变更记录”字段而不是直接覆盖旧摘要。这样即使模型判断错了你也能在检索时发现冲突而不是悄悄丢掉事实。4.3 混合模式拼接后模型反而答非所问五种上下文拼在一起以后有时模型会分不清哪段是当前对话哪段是检索出来的历史。我一开始也遇到过模型一本正经地在回答一段三个月前的旧问题。解决办法是给拼接的每个区块加明确的分隔标签例如[系统指令] [本会话最近对话] [历史会话摘要] [检索片段用户2025年3月关于XX的讨论] [当前问题]标签本身不额外消耗太多 token但能强烈提示模型各段的角色。实测下来加了标签之后模型“串台”的概率显著下降。这个细节非常小但价值很大。4.4 为了“多记住一点”反而把延迟和准确率搭进去很多人的第一个反应是既然窗口有 200k那就全部塞进去。结果首字延迟高得离谱用户反馈“机器变笨了”。上下文越长模型在无关信息上分配注意力的比例就越大。上下文管理的目标不是把每一条都记住而是用最小的上下文达成最高的有用信息密度。我的建议是宁缺毋滥。如果你发现某段历史加进去以后答案质量没有提升就果断把这段历史从上下文中摘掉。通过减少输入来换取更快、更准的响应这是 context-mode 优化的核心心法。症状可能原因处理方式聊几轮就失忆窗口未生效或系统提示词被截打印实际请求体冻结系统提示词关键数字丢失摘要提示词太笼统字段化约束加入变更记录通道答非所问拼接部分无分隔标签加分区标签明确各段角色延迟过高上下文塞太多按信息密度裁剪用缓存复用前缀历史里搜到旧话题向量检索没有时间权重加入时间衰减因子近期片段优先4.5 滚筒式容错设置一个兜底开关最后再分享一个兜底的策略。我会在上下文组装层留一个开关mode_normal 和 mode_fallback。如果模型或者线上指标出现异常直接把模式切到 fallback即清空全部历史只保留系统提示词和当前问题用这种最干净的方式先保住基本可用性而不是带着一个坏掉的上下文反复试错。等你定位到问题再切回来。这个开关在调试复杂上下文问题时帮了我大忙。5. 进阶思路从“管住上下文”走向“用好上下文”聊完了基础接下来是扩展。很多人做到摘要和检索就停了但 context-mode 的上限远不止如此。这一节讲几个我现在在探索的方向。5.1 让模型自己维护“记忆文件”一个很有潜力的思路不把所有历史塞给模型而是给模型一个可以读取和写入的“记忆文件”。记忆文件里存放用户偏好、关键事实、长期目标。每次需要时模型主动决定读哪个字段而不是被动接收全部历史。这种模式更接近人对长期记忆的使用方式。不必把和用户聊过的每一句话都存在脑子里只需要记住那些对后续对话有影响的事实。实现上记忆文件的读写可以用模型完成也可以结合规则引擎。比如团队协作 Agent 里把“任务截止时间”“成员偏好”“已确认的排期”维护成结构化字段每次对话结束时让模型更新这些字段。5.2 多智能体协作中的共享上下文做多智能体时最常见的错误是给每个 Agent 都复制一份全量上下文结果成本翻倍信息也互相污染。我的做法是维护一个中心化的共享上下文池每个子 Agent 只保留自己的轻量上下文需要其他模块信息时再向共享池订阅。这就类似于总线架构上下文总线负责流转任务状态、中间结论、目标变更。各 Agent 从总线读取和自己的任务相关的片段。实测下来这种方式不仅降低了 token 消耗还让整体行为更容易追踪因为每个 Agent 到底看到了什么信息都有据可查。多智能体的 context-mode重点在于上下文共享的边界设计而不是把每个模块都堆成胖上下文。5.3 异步压缩与增量记忆最后是性能方向。线上服务不适合在关键请求路径里做同步压缩因为这会明显拉长延迟。我现在做的是异步压缩把上下文快照丢到消息队列里后台任务在空闲时计算摘要生成后写回缓存。用户下一次请求读取时摘要已经准备好了。增量记忆也是一种优化。它的思路是每次只对新增的对话做增量摘要再和旧摘要合并而不是每次都全量压缩。配合异步机制这一步几乎无感。好处非常直接长会话的成本增长从线性变成亚线性模型记忆却仍然保持连续。我在实际项目中的体会是context-mode 做得好的团队后期维护成本反而更低。它不是一锤子买卖而是一个需要不断测量、调整的活系统。每次改动上线后记得把那三项核心指标重新跑一遍。如果你正准备重构自己的上下文方案建议先从小步改动开始不要一次性把窗口、摘要、检索全部换掉。保留一个干净的对比基线一次只动一个变量你会看得更清楚也更容易定位问题。