最近逛技术社区总能看到有人在问 context-mode 到底怎么实现。这个东西其实不神秘但很多人容易把它理解成把聊天记录多塞一点给模型结果要么费用暴涨要么对话越来越蠢。我在几个 AI 应用项目里用 context-mode 做过完整的上下文管理从最简单的全量保留到后来逐步上摘要压缩、检索召回是一步步踩坑调过来的。这篇文章就围绕 context-mode 聊聊我自己的设计思路、落地方法和排查经验给正在做聊天机器人、知识库助手、智能体这类项目的朋友一些参考。内容偏实操代码部分是简化示意重点是把逻辑讲透。1. context-mode 是个什么问题先搞懂上下文的物理限制1.1 大模型没有记忆上下文全靠重读很多人第一次做 AI 应用时都会有一个错觉模型是不是像人一样聊过几句就记住我了实际完全不是这么回事。大模型本身没有记忆所谓上下文就是你每次调用时把它之前看到过的内容重新拼进输入里再喂给它。这个过程可以类比成一张固定大小的草稿纸每轮对话你都在纸上写新内容但纸的面积是有限的写满了就必须擦掉旧内容。擦掉哪块、保留哪块、怎么腾地方就是 context-mode 要解决的问题。窗口大小是模型决定的比如常见的 128k、200k甚至更大的长上下文模型但怎么用好这些空间却是你决定的。这里有个特别容易忽略的点token 是花钱的而且处理时长和 token 数量直接相关。你每多塞 1000 个 token 的历史记录不仅多一笔费用还会让首字延迟变高。更重要的是研究早就提过lost in the middle现象模型对输入中间部分的内容注意力会明显弱于开头和结尾。也就是说哪怕你硬把 10 万字的对话全塞进去模型也不一定真能把中间某条细节用起来。1.2 为什么要有模式显式取舍比隐式遗忘更可控既然不能全塞那是不是简单从后面截断、只留最近几轮就行了如果只做玩具项目确实可以。但一旦你的应用要服务真实用户你会发现不同场景对记忆的要求完全不同。打个比方客服机器人需要记住用户从头到尾的诉求变化但不需要记住每一句寒暄法律文档问答需要精确引用原文一个字都不能错角色扮演类应用则需要牢牢记住早期设定的人设和关系哪怕中间聊了一百轮无关内容。这些诉求如果都用一个截断最近 N 轮的规则去处理必然顾此失彼。context-mode 的核心价值就是把这种取舍逻辑显式化。它不是让模型自己随机遗忘而是由开发者预先定义几种模式每种模式对应一套可预测的行为全量模式追求信息无损压缩模式追求成本可控检索模式追求知识面广。这样做最大的好处是行为可预期、问题可复现。之前我在项目里遇到过模型突然失忆排查了半天才发现是某个中间状态把旧消息截断了但如果当时用了明确的模式管理这类问题一眼就能看出来。1.3 context-mode 的适用边界也不是所有项目都需要纠结 context-mode。如果你只是做一个一次性问答工具输入一段文本、输出一段结果那上下文管理根本不存在。真正需要它的是多轮对话和多来源信息场景用户会持续追加问题、历史记录会影响当前回答、回答需要引用外部资料。判断标准很简单如果单次请求里历史消息 外部资料 系统指令加起来超过模型窗口的一半而且用户很在意回答的一致性和准确性那你就有必要认真设计 context-mode。反之如果每个请求都是独立短对话那么把窗口开大、直接全量拼接反而是最省事的方案。2. 三种常见的 context-mode 设计思路与选型2.1 全量保留模式直接用但要算成本全量保留Full-context Mode是所有方案里最朴素的把全部历史消息、系统提示、当前输入原样拼在一起丢给模型。它的优点是信息零损失任何一轮对话里的细节都在模型印象最完整。适用场景也很明确会话轮数短、单条消息长、对精度要求高的任务。比如代码审查开发者贴了一段代码问了几轮修改意见每轮指向的都是同一段代码里的不同位置这时候任何压缩都可能丢掉关键修改点全量模式是最稳妥的。但全量模式有两个必须正视的问题。第一是成本历史消息是线性增长的聊到第 50 轮时你可能每轮都在给模型重复喂前 49 轮的内容费用曲线非常难看。第二是注意力稀释窗口塞得越满模型在无关内容上浪费的注意力越多。我在一个文档解析项目里实测过当上下文超过 6 万 token 时模型对尾部指令的遵从度会出现肉眼可见的下降这还是在用了较新的长上下文模型的情况下。所以全量模式不是无脑可用而是要配合一个硬性上限超了就触发其他模式。2.2 摘要压缩模式给对话做归档摘要压缩Compressed Mode解决的是对话太长的问题。思路是每隔一段时间把旧的历史对话交给模型做一次总结生成一个压缩后的摘要块然后上下文里只保留摘要块 最近 N 轮完整原文。举个例子用户聊到第 20 轮时你把前 15 轮的内容总结成 300 字的要点只保留第 16-20 轮的完整对话。这样模型既能大致记得前面发生了什么又不用每次都背上全部原文。我在客服机器人项目里用的就是这种方案用户先在对话里描述了自己的产品型号和问题现象中间又穿插了一些不相关的闲聊压缩后那些闲聊会被过滤关键信息却留在了摘要里后续回答明显更聚焦了。不过压缩模式有个特别容易翻车的细节摘要会丢细节。数字、日期、名称、约束条件这些恰恰是最不能丢的。我的经验是不要让摘要只输出一段自然语言而是让模型同时输出一个结构化字段块把用户身份、核心诉求、已确认的偏好、待办事项单独提取出来。这样就算摘要正文写歪了关键字段还在后续流程可以优先读取结构化字段。2.3 检索召回模式把记忆变成查资料检索召回Retrieval Mode跟前两种思路完全不同。前两种是把历史对话当成记忆检索模式把外部知识库也纳入记忆体系。常见做法是把长期不变的知识产品文档、规章制度、历史 FAQ切成小块做向量化存到向量数据库里。用户提问时先在知识库里召回最相关的 Top-K 块再连同当前问题一起送给模型。这个模式很适合知识库问答、企业内部助手这类场景。因为知识库可能是一千页文档你不可能每次都全量塞进去只能让模型带着问题去查资料查到什么就引用什么。但检索模式的关键瓶颈不在模型而在召回质量。召回不对后面全都白搭。影响召回的因素很多文本切块的大小、向量模型与领域是否匹配、是否做了相关性阈值过滤、有没有重排环节。我见过太多项目把向量化 余弦相似度 Top-K当成万能药结果用户问一个稍微口语化的问题召回回来的都是驴唇不对马嘴的内容。这部分我在第四节会细讲排查方法。2.4 选型对照别指望一种模式走天下三种模式不是互斥的实际项目里往往是组合使用。比如客服机器人可以同时用压缩模式管历史对话 检索模式管产品文档而智能体工具则可能短任务全量、长任务压缩、跨领域检索三档并存。给一张我常用的选型对照表方便你快速判断维度全量保留模式摘要压缩模式检索召回模式适用会话长度短20轮中长20轮以上长且依赖外部资料信息保真度最高中等取决于召回质量单轮成本高中低到中实现复杂度低中高典型场景代码审查、精读任务客服、角色扮演、多轮任务知识库问答、文档检索我的建议是先明确你的应用最痛的是哪个问题。如果最痛的是对话太长记不住先上压缩模式如果最痛的是知识太多答不准先上检索模式。一上来就三件套齐上往往会把系统搞得很难排查。3. 从零实现一个最小可用的 context-mode 管理器3.1 数据结构与模式定义在写代码之前先把数据模型定好。我习惯把上下文管理抽象成一个独立模块不跟业务代码耦合。核心数据结构有三个消息列表、会话元信息、记忆存储区。消息列表就是原始对话记录每条消息至少包含角色和内容会话元信息保存会话 ID、当前模式、累计 token 数等记忆存储区则放压缩后的摘要块、从对话里提取的关键字段、以及检索用的向量索引。模式定义我用一个枚举来管理方便后续扩展from enum import Enum class ContextMode(str, Enum): FULL full # 全量保留 COMPRESSED compressed # 摘要压缩 RETRIEVAL retrieval # 检索召回接着定义一个上下文管理器类对外暴露的核心方法就三个追加消息、构建请求、触发维护。注意构建请求是个关键动作它决定了最终塞给模型的是什么内容。class ContextManager: def __init__(self, mode: ContextMode, max_tokens: int): self.mode mode self.max_tokens max_tokens self.messages [] self.summary self.key_facts {} def add_message(self, role: str, content: str): self.messages.append({role: role, content: content}) def build_payload(self, query: str): if self.mode ContextMode.FULL: history self.messages[-20:] # 硬性上限防止无限增长 elif self.mode ContextMode.COMPRESSED: history self._build_compressed_history() elif self.mode ContextMode.RETRIEVAL: history self._build_retrieval_context(query) return self._assemble(history, query)这段代码是简化示意真实项目里还要加上 token 计数、缓存、并发控制。但核心思想已经出来了模式不同取历史的方式完全不同最后都汇聚成同一条请求方便上层业务统一调用。3.2 token 预算怎么算先分蛋糕再写代码很多新手忽略 token 预算代码写完了才发现一调用就超限。我建议拿到一个模型窗口后先把它当成一块蛋糕来分而不是上来就写代码。以一个 128k 窗口的模型为例我通常这样分配最大输出预留8k给模型生成回复留足空间系统提示与指令4k人设、规则、输出格式安全余量6k防止响应过长或工具调用中途插入内容真正给上下文的110k在 110k 里如果当前是压缩模式我一般再拆成摘要块 15k、最近原文 60k、检索结果 20k、用户当前输入 15k。分配的比例不是固定的但要有个明确规划否则某个模块悄悄膨胀迟早把窗口挤爆。token 估算也要养成习惯。中文场景下1 个汉字大约占 1 到 2 个 token英文则是 1 个单词约 1.3 个 token代码和符号的估算更不稳定。最稳妥的办法是用模型的 tokenizer 在本地做计数而不是靠大概多少字来猜。我见过因为估算偏差历史消息被截断一半还毫无提示的情况那是最尴尬的。3.3 三种模式的核心实现逻辑全量模式最简单每次直接把消息列表拼进请求但要加一个硬性截断逻辑。我曾经天真地以为窗口够大不用截断结果第十轮对话时单次请求已经超过 3 万 token延迟肉眼可见地变高。后来我定了个规则超过 80k token 时从最早的消息开始丢弃但保证最近的 10 轮永远保留。这是全量模式最实用的兜底策略。压缩模式的触发条件要设计好。我用的不是固定轮数而是 token 阈值每当历史消息累计超过 32k token就触发一次压缩把最旧的一半交给模型总结。这样做的好处是用户少说话时不触发用户话痨时自动压缩行为更平滑。摘要的 prompt 也要固定格式强约束输出包含对话主线、用户核心诉求、已确认事实、遗留问题四块内容格式用 JSON方便程序直接解析。检索模式里最容易被忽略的是 query 改写。用户原话往往口语化、指代不清直接拿原话去检索效果很差。我会先用一个小模型把用户问题改写成适合检索的关键句式比如它什么时候能发货改写成物流发货时间查询规则再去做向量召回。这一步在 ColBERT 这类稠密检索方案下提升特别明显。3.4 实测一组参数看看差异在哪我在一个知识库客服项目里跑过一组对比测试记录如下供你参考方案差异有多大模式上下文大小单轮耗时回答准确率抽样50题全量保留不截断35k token6.8s82%压缩模式摘要原文14k token3.1s78%检索模式Top-5召回8k token2.4s88%检索模式 压缩模式10k token2.9s90%这个结果很有代表性纯全量模式耗时最高准确率还因为无关内容太多而下降检索模式因为只带最相关的资料准确率反而更高最后的组合方案在延迟和准确率上取得了最好的平衡。所以我现在的默认做法是历史对话走压缩知识库走检索两者拼起来一起用。组合模式里要控制好文字配比摘要块别太大检索结果别超过 6 个块否则同样会引入噪音。4. 常见问题与排查实录上下文方案翻车的 4 个典型现场4.1 关键信息莫名其妙消失了这是出现频率最高的问题用户前面明明说过的信息到了后面模型就像完全不知道。排查时先问自己三个问题这条信息是不是被截断了是不是被压缩摘要丢掉了是不是被检索漏掉了我建议的排查顺序是先用日志把每次请求的实际 prompt 打出来直接看这条信息在不在里面。有一次排查了半天用户名字记不住的问题最后发现是压缩触发条件写错了摘要只保留了最近一次对话用户开头的自我介绍直接被吞了。从那以后我在所有压缩模式下都强制把用户基本信息放进结构化 key_facts 里不管摘要怎么写关键字段永不参与压缩覆盖。4.2 摘要压缩后事实出错日期和数字尤其危险摘要压缩最隐蔽的问题是看着合理实际错了。模型在总结时偶尔会把日期改掉、把数字四舍五入、把否定语气弄反。这类错误在长会话里会被反复引用最后越滚越离谱。我的解法是摘要 原文兜底双轨制摘要负责提供整体脉络但凡是涉及数字、日期、金额、型号、操作步骤的原文片段会被单独抽取出来保留原始文本。构建请求时原始关键片段按优先级排在最前面模型优先看到精确内容。另外一个实践技巧是压缩 prompt 里明确要求不得改写任何数字和专有名词原文引用原样输出实测能显著降低事实性错误。4.3 检索模式召回一堆废话相关性还不如不检索检索模式的问题多数出在召回环节。常见原因有三类一是文本切块不合理要么块太大导致一个块里塞了太多主题要么块太小导致语义不完整二是向量模型与业务领域不匹配通用模型对专业术语理解差三是没有做相关性阈值过滤随便什么内容都往 prompt 里塞。我这里有一个值得一试的改进流程先做粗召回取回 Top-20再用一个轻量模型或基于关键词匹配的规则做精排只留下 Top-5。同时给相关的相似度设一个下限低于 0.7 的直接不召回。比起召回全部塞进去这种召回一半丢一半的方案效果反而更好因为模型不会被大量低质量内容干扰。4.4 成本失控每轮调用都在烧钱context-mode 做完了成本反而比之前更高的情况我也遇到过。最典型的原因是压缩本身变成了高频操作每轮都触发压缩而压缩本身要调用一次模型等于每次对话要付两倍的钱。另一个原因是检索结果长期不缓存同一个问题反复查向量库白白增加延迟和费用。压缩频率一定要降下来。我现在用的策略是惰性压缩只在上下文占比超过 70% 时才触发而且压缩结果会缓存起来后续几轮对话直接复用。检索结果的缓存也做了同样的用户问题在 10 分钟内直接命中缓存不再走向量库。这些优化做完单轮成本大约能下降 40% 到 60%效果非常明显。5. 我的一些落地经验和建议5.1 别一上来就三模式全上我很理解大家看到新方案就想全部上齐的心情但 context-mode 确实适合渐进式演进。我的建议是先用全量模式把整个链路跑通确认模型能力没问题之后再根据实际的 token 消耗数据决定是先上压缩还是先上检索。一上来就做三套模式的切换逻辑调试成本会成倍增加而且你根本分不清某个对话质量问题到底是模型问题还是上下文策略问题。5.2 把 prompt 构成晒出来看做 context-mode 最忌讳闭着眼调参。我在项目里加了一个调试面板每个请求都会展示最终的 prompt 由哪几部分组成系统指令多少 token、摘要块多少、历史原文多少、检索结果多少、当前输入多少。每次调整完策略先看这个分布是否合理再去看回答质量。这个面板帮我发现了不少问题比如系统指令被历史消息悄悄挤出窗口、检索结果占了 60% 的 token 还都是废话等等。5.3 为每个模式准备回归测试集上下文策略改动的风险是悄无声息变差。我维护了一个 50 到 100 条用例的回归测试集覆盖长对话、数字细节、指代消解、多轮任务切换等场景。每次改动 context-mode 相关的代码或参数都跑一遍回归测试对比回答准确率和关键信息保留率。这项工作看似麻烦但能避免很多上线第二天用户投诉变多的悲剧。5.4 模式切换要留手动入口最后补充一个容易忽视的设计点模式切换不能只靠自动规则要给用户或运营留一个手动覆盖的入口。比如客服场景里用户明确要求转人工或者强调我之前说过很多次了这时候系统应该能临时切到全量模式把历史原文完整调出来。自动规则负责大部分情况下的效率手动入口负责兜底特殊场景两者配合才能让整个上下文体系既聪明又稳当。我在实际开发和维护中也得到一个体会很多人把 context-mode 当成模型能力问题觉得换个更大的窗口就解决了。但窗口再大也只是扩大了草稿纸不会自动帮你决定哪些内容更重要。真正值得花时间打磨的永远是那套取舍逻辑——什么时候保留、什么时候压缩、什么时候去查资料。把这一层设计清楚了你的 AI 应用才谈得上真正的有记忆。