最近在做智能助手类项目时团队内部一直围绕“context-mode”上下文模式这个设计反复讨论。说白了它就是一套关于“怎么把历史对话、业务背景、当前问题打包交给大模型”的交互策略。很多从单轮问答切到多轮对话场景的开发者都会在某个节点突然意识到如果上下文处理不好模型再强也白搭。这篇文章就把我们实践中积累的设计思路、实现方案和踩坑记录整理出来给正在做对话系统、AI辅助工具或者Prompt工程相关项目的朋友一个参考。1. context-mode 到底是什么以及为何关键1.1 无状态 API 与真实对话之间的天然矛盾大模型接口本身是无状态的。每次调用就像一次考试你交一张答卷它给你一份答案考完就忘。但用户在使用聊天机器人、AI 编程助手、智能客服这些产品时默认会认为对方“记得我说过的话”。这个矛盾直接催生了 context-mode 的雏形——我们需要在应用层自己搭一套上下文管理机制把多轮对话的历史信息重新组织成模型能理解的输入。其实在最早期做这类功能时我犯过一个特别基础的错误直接把所有聊天记录一股脑全塞进 prompt。当时觉得模型有几百 KB 的上下文窗口塞进去总没问题。结果发现两个严重后果一是 token 费用飙得离谱二是模型经常被无关历史干扰回答反而变差。从那时候起我才意识到 context-mode 不是“有无”的问题而是一个“如何组织、如何取舍、如何更新”的系统工程。所谓 context-mode我在实践中的理解是在不同业务场景下选择不同的上下文组织策略。比如在代码生成场景需要精确保留用户最近一段代码在知识问答场景需要把历史结论提炼成摘要在数据整理场景则可能需要关联所有表格结构。同一套对话系统针对不同任务应该动态切换这些模式而不是固定一种策略走到底。1.2 逐字保存、摘要压缩与语义路由单说抽象概念不够这里拿我们实际落地时拆解的三种 context-mode 策略举例。当然你也可以理解为这是“三级模式”实际中往往需要组合使用。全量模式Full Context Mode 基本把窗口内的对话原始内容全部保留适合代码编辑、法律文书审阅这类对细节极度敏感的场景。优点是信息无损失、模型理解最准确缺点是 token 占用量大、响应变慢、费用偏高。摘要模式Summarized Context Mode 将早期对话内容提炼成几十字的摘要插入 prompt最近几轮则用原文保留。适合客服工单、资料调研等长会话场景既让模型理解“来龙去脉”又控制了上下文体积。路由模式Routed Context Mode 先对用户当前问题进行语义识别判断属于哪个业务域只拉取该域历史记录与知识库片段把这些内容拼接进上下文。适合垂直场景、知识库问答、企业内网助手等指向性更强背景干扰最少。真正理解 context-mode 的价值不能只看某一次回答是否“聪明”而要观察它对整条会话成本、响应速度和产品体验的影响。很多团队在模型选型、微调上花了大量精力却忽略了这个工程层最关键的控制点——上下文怎么管。2. 从零搭建 context-mode核心模块与关键参数2.1 整体设计思路把上下文当作独立的一等公民过去做代码时我们习惯把“对话记录”当成聊天对象身上的一个数组用的时候直接取 last 50 条。但真正能支撑业务长期演进的 context-mode一定需要把上下文当作一个独立模块来设计。我画过一版很朴素但足够用的架构这里用文字描述一下。Conversation Manager会话管理器 负责记录原始对话、管理会话生命周期为每条消息打上时间戳、角色标识、业务标签。Context Builder上下文构建器 接受模式指令决定当前请求携带哪些内容。它从会话管理器取数据经过裁剪、摘要、路由等处理生成最终的 prompt 前缀部分。Token EstimatorToken 估算器 在发送前估算 prompt 的总 token 数当超过阈值时触发压缩策略或告警。Policy Engine策略引擎 定义各模式的规则比如“摘要模式中原文保留几轮”“路由模式下路由关键词来源”“全量模式下最多保留多少字符”等。这个设计的核心价值在于上下文逻辑与业务逻辑彻底解耦。后续调整模式策略时不会影响功能主流程也不用手忙脚乱地去改一堆散落的拼接字符串。如果你的项目正处于从单轮到多轮对话的进化阶段强烈建议先把这一层独立出来。2.2 消息结构设计不只是拼字符串还要设计“索引”很多人写 prompt 拼接时直接 f{role}: {content} 一行行堆。代码确实能跑但一旦模式复杂起来你很快会发现没法精准定位“第 2 轮用户到底说了什么”“某条消息隶属于哪个业务域”。我在实践中会引入结构化消息这是实现 context-mode 的底层基础。核心字段我一般包括msg_id: 消息唯一 ID方便缓存与追溯。role: system / user / assistant有时还会拆分 tool。content: 消息正文可能是用户提问、模型回复、工具返回结果。ts: 时间戳用于判断消息新鲜度。biz_tag: 业务标签比如 “intentcreate_task”支持路由模式下按标签筛选。token_count: 估算的 token 数量提前算好可以避免构建时重复计算。存储上生产环境我建议用 Redis 或 MongoDB线上并发比较高时会保留最近一周的会话记录同时定期归档到对象存储或数仓中。数据量未到千万级之前SQLite 也完全可以用重点是字段设计要提前预留扩展位。2.3 模式切换的动态策略一次请求怎么决定带多少历史静态配置模式很简单难在场景是变化的。同一个用户可能上一句在闲聊下一句就开始写代码也可能早上还在查资料下午就在修改需求。硬编码成“一律用摘要模式”显然太粗暴。因此我给模式引擎设计了几个判断维度组合使用。会话轮数阈值 少于 3 轮用全量模式3-12 轮默认摘要模式超过 12 轮触发路由模式或清理策略。语义意图路由 调用一次轻量级意图识别判断用户当前任务属于代码生成、知识问答、数据分析还是闲聊映射到对应上下文策略。时间衰减权重 超过 30 分钟的消息权重下调超过 2 小时的消息基本只保留摘要或主题标签。长时间挂机后新请求如果历史与当前任务关联度低可以直接以空上下文开始让模型主动询问。用户手动指定 某些高级用户有明确需求比如“记住我整个方案”或者“只根据这段代码回答”那就提供 UI 开关让 context-mode 策略由用户侧覆盖。这个部分可以通过接口拿到很直观的体验同样一句话 “这个功能怎么实现”在路由模式下会先判断用户当前所在业务模块再附带对应模块的历史背景而在摘要模式下则直接携带该会话最近几条对话摘要回答侧重点完全不一样。2.4 Token 估算与窗口控制数学上下文模式最核心的工程指标是 token 预算。我见过不少团队不估算 token等模型报错才去裁这是非常被动的。这里分享一下我常用的快速估算方法。如果你使用的是 OpenAI 系模型可以直接用 tiktoken 库做精确估算如果用的是国产模型或其他开源模型通常 1 个汉字约等于 1-2 个 token1 个英文单词约等于 1.3-1.5 个 token。这里有个工程惯例值得一提token 估算值不用过于精确上下浮动 10% 完全可接受我们的目的只是不让 prompt 超限而不是做计费级精确统计。例如用户当前场景是摘要模式配置规则如下system prompt 固定为 300 token最近 2 轮原始内容保留每轮约 800 token早期 10 轮压缩为 3 条摘要每条约 120 token候选知识库片段最多 2 条每条约 400 token那总预算估算为300 800×2 120×3 400×2 300 1600 360 800 3060 token。假设模型窗口上限是 8000留出约 40% 给生成本身预算判定为合理。如果超了我就按优先级降级先裁剪知识库片段再压缩早期摘要最后才动最近两轮原文。注意不要试图把窗口塞满。生成回复通常需要输出几百到几千 token如果 prompt 占了 90% 的窗口模型可用生成空间不足会出现回复截断、内容语无伦次等问题。我个人的经验是prompt 部分最好不要超过上下文窗口的 60%。3. context-mode 的核心技术实现与工程细节3.1 上下文压缩怎么提炼才能不丢关键信息压缩是摘要模式的关键也是最容易翻车的环节。一开始我用“直接调大模型把上面十轮对话写个 100 字总结”这种最朴素方式发现两个问题成本太高每轮都要额外调一次模型信息失真模型经常漏掉最重要的用户约束比如“不要用 Java”这种否定性指令在摘要里总是被吞掉。后来我的实现方法是“分层摘要 关键信息锚点”双通道方案。分层摘要 每 5 轮对话生成一层摘要新请求只对“上一次摘要 新出现的对话”做增量合并。这样可以减少重复压缩带来的信息衰减。关键信息锚点 在对话过程中实时抽取用户的需求约束、偏好和明确指令单独存放一个动态列表。构建上下文时把它和摘要一起注入 prompt确保最容易影响回答方向的约束不被摘要淹没。举个我们知识库问答场景的例子。用户先问了 3 个关于某 SDK 的用法中途说了一句“我只需要 Python 版本的示例”。如果只用对话摘要这条约束很可能被压成“询问 SDK 用法”几个字后续模型就可能给出 Java 或 Go 的实现。有了关键信息锚点机制系统会单独记录“约束只需要 Python 示例”每次构建上下文都带上模型就不会跑偏。3.2 路由策略不要让上下文变成“大杂烩”开启路由模式后如果相关场景数据做得粗糙反而更容易翻车——上下文变成了一锅“大杂烩”什么都有一点但相互之间没有逻辑关系。我这边的做法是给每个业务域建独立的索引库并且上下文窗口按域切分。假设系统有三个域产品知识库、技术支持库、销售政策库。当用户提问“这个产品支持导出哪些格式”路由模块命中“产品知识库”域并在该域下检索最近问题与相关文档片段。此时 prompt 结构大致为[系统指令与通用说明 200 token] [产品知识库域历史相关消息 400 token] [检索到的知识片段 800 token] [用户当前问题]这个设计刻意省略了其他域的历史记录即使之前聊过销售价格相关问题也不会被拉进来。路由模式下上下文体积控制得最严格响应速度和准确性也最高。3.3 冷启动与上下文继承新会话怎么延续旧结论这是一个经常被忽略但实际很影响体验的细节。用户前一天跟机器人讨论了一套方案第二天打开新会话期望机器人“还记得”关键结论。但按标准 context-mode 设计新会话上下文为空模型会一脸茫然。我们的解决方案是会话摘要持久化。每次会话结束后异步生成一份 200-300 字的总结包含达成的结论、待办事项、用户偏好等存到用户维度。开启新会话时把上一份会话摘要作为 system prompt 的一部分注入告诉模型“用户上一个会话的结论是……请基于此继续”。这样一来跨会话的 context-mode 就延展成了上一会话摘要 本会话历史 当前问题的三层结构。不过这里有一个坑需要注意。如果用户明确开启了新话题或者前一个会话已经是很多天前的仍强制注入旧摘要反而会影响模型判断。所以我会加入一个时间因子和“话题漂移检测”如果用户当前提出的问题与旧摘要计算出的相似度低于阈值就直接丢弃旧摘要让上下文从零开始。3.4 性能调优如何让上下文构建不拖慢响应context-mode 的实现很容易引入额外延迟尤其在路由模式和摘要模式下——必须先调用一次路由分类、一次摘要提取然后才能发给大模型。为了把这个过程变快我做了一些优化措施。预计算会话标签 会话建立时就进行意图分类和关键词提取而不是请求时临时算。异步预取知识片段 基于用户当前正在输入的内容提前检索请求到来时直接使用缓存结果。摘要结果缓存 一个会话的摘要在 10 分钟内不会发生变化直接缓存复用不必每次请求都重新压缩。路由模型轻量化 意图识别和路由判断不用强模型用 embedding 余弦相似度或小型分类模型就足够速度快且成本低。按照这套优化方案实测下来摘要模式的额外延迟从最早的 800ms 降到了 150ms 左右路由模式额外延迟控制在 100ms 以内。对于大多数交互型产品用户感知基本无差别。4. 常见问题与排查实录4.1 上下文污染导致模型“精分”现象 用户问 A 问题模型答得还行但当对话超过 10 轮后模型回答开始逐渐跑题甚至出现前后矛盾、角色混乱。排查思路 第一件事就是查 prompt 的上下文构成。用调试日志打印出每次请求实际发送给模型的 prompt我几乎每次都能发现原因要么是无用信息太多例如一些“嗯”“好的”“谢谢”之类的低价值来回要么是早期会话摘要太粗糙错误信息被反复引用。解决办法 给上下文构建器加入消息价值过滤。像“嗯”“好的”这类无实质信息的消息直接剔除同义重复的多轮提问只保留问题最完整的版本摘要压缩前先进行实体和意图校验避免摘要包含与原始对话矛盾的内容。4.2 token 黑洞费用暴涨的元凶现象 上线 context-mode 后日均 token 消耗明显增加费用一周涨了 30%。排查思路 我们把 token 记录按会话维度和模式维度做聚合很快定位到问题全量模式被默认配置成了“永远保留全部对话”哪怕会话已经持续了几百轮系统仍在往 prompt 里塞。解决办法 对全量模式增加硬性限制单次最大携带 20 轮或 6000 token超出部分自动降级为摘要模式。同时把全量模式的适用场景限制得更加严格只有显式触发代码补全或文档精读时才启用。4.3 路由模式下的“答非所问”现象 在路由模式下模型给出的回答内容泛泛而谈判断不出用户想问什么。排查过程 检查上下文日志后发现知识库片段检索出来的内容质量非常差根本没有和用户问题直接相关的内容甚至拿的是“匹配度 0.2”的边角料文档。问题出在检索阈值设得太低加上没有做重排序。解决办法 把检索相似度阈值从 0.3 提到 0.55并引入重排序机制用更精细的模型对 Top 10 结果重新打分只保留 Top 3 进入上下文。这样一来虽然偶尔会检索不到内容但能被检索到的都是高质量内容总体效果明显提升。4.4 常见问题速查表问题现象可能原因解决办法回答前后矛盾上下文过长、摘要信息失真增加关键信息锚点缩短摘要间隔费用异常增长全量模式无限制使用设置窗口上限超限降级摘要模式模型忽略用户约束否定性指令在摘要中丢失抽取关键指令单独注入 prompt新会话记不住旧结论未做会话摘要持久化增加上一会话摘要注入逻辑上下文构建延迟高每次实时调用摘要与路由预计算标签、缓存摘要结果检索内容不相关相似度阈值过低、未重排序提高阈值并引入重排序模型4.5 上下文模式调试的三板斧说实话context-mode 这种偏工程侧的模块调试起来最烦人的一点是“不可见”——你很难直观看到模型到底收到了什么。我的经验是开发和调试阶段一定要把三件套做齐全量 prompt 日志 每条请求发出的完整 prompt无论正确与否都要落盘。单条消息溯源 能从 prompt 中的某段话反查到它来自哪一轮、哪个摘要、哪个知识片段。A/B 对比面板 同一问题分别用全量模式、摘要模式、路由模式跑一遍并排看答案差异。有了这三样排查问题基本能覆盖 80% 的场景。我自己维护过一个小型内部面板输入一个问题选两种模式并排展示结果和各自 token 开销对模式策略调优非常有用。5. context-mode 的落地效果与使用心得5.1 数据表现成本、质量、延迟三个视角我们用同一个内部知识问答机器人做了约两周对比试验。对照组固定使用“尽可能多保留历史”的全量模式实验组启用带路由与摘要的 context-mode。数据差异还挺明显。指标对照组全量硬塞实验组context-mode平均每次请求 token 量约 5200约 1800首 token 延迟约 1.8s约 0.9s回答相关性人工评分3.4 / 54.2 / 5周成本基准降低约 61%数字永远不会骗人。context-mode 并不是靠“牺牲质量换成本”而是通过更合理的上下文组织把模型注意力聚焦到了真正重要的信息上所以回答质量反而提升了。这才是它最核心的价值所在。5.2 哪些场景适合开 context-mode哪些不适合适合的场景有几个典型共性会话轮数多、业务领域垂直、上下文信息存在大量冗余、用户对响应速度有要求。比如智能客服、企业知识助手、代码生成辅助、长文档分析工具等这些都是 context-mode 能发挥最大效果的地方。不适合的场景同样明显单轮问答型产品或者用户每次提问之间毫无关联的工具型应用硬加 context-mode 只会白白消耗 token 和增加延迟。这种情况下不如老老实实用裸接口最多加一层业务规则没必要为了“智能”而“智能”。另外还有一种需要警惕的场景——强隐私和合规要求下的对话系统。如果上下文被路由器跨域组合或摘要处理时出现“信息越权”风险会非常高。因此在这种场景下我建议 context-mode 的策略配置要单独走审慎流程该隔离的域必须物理隔离该删除的敏感字段必须提前脱敏再进上下文。5.3 从 context-mode 到更完整的记忆体系做到这一步context-mode 已经能解决绝大多数多轮对话工程问题。但如果往前再走一步你会发现它本质上只是“记忆体系”的一部分。完整的记忆应该包含短期工作记忆当前会话上下文、长期情景记忆跨会话的用户画像与偏好以及语义记忆业务知识库。这三层记忆相互配合才是真正让 AI 产品从“问答机”升级成“贴身助手”的关键。我们在项目里已经开始尝试把 context-mode 的摘要结果自动沉淀成用户画像标签后续做推荐、主动提醒等功能时直接调用效果不错。这块后续有机会再单独写一篇文章展开。最后分享一个实操中的小建议不要把 context-mode 的所有细节一次性做完。先做好“全量 简单摘要”两种模式跑通主流程再逐步迭代路由、分层摘要、跨会话继承这些高级能力。上下文管理是典型的“可以无止境优化”的方向但在产品没有明确需求前过度设计只会给自己增加不必要的维护负担。先从业务最痛的点入手把成本降下来、把质量提上去你会很快感受到这个设计带来的真实改变。