聊到context-mode我得先从一个让我抓狂的下午说起。当时我在给一个企业内部文档问答助手调系统用户连续问了十几个问题前几条还在聊“Q3销售预测的假设前提”后几条已经跳到“那这个预测和去年的口径怎么对齐”。模型答到后面突然开始胡言乱语回头一看控制台发现对话历史里塞了20多轮消息token数早就超过了预设窗口旧的指令被挤掉了模型根本记不住最开始约定的回答规范。后来我把整套上下文处理逻辑重写了一遍引入了一个自己定义的context-mode机制——本质上是针对不同对话阶段、不同任务类型动态切换上下文管理策略。这套东西上线之后长对话的稳定性明显提升API费用也降了不少。今天这篇就当一次复盘把“上下文模式”这件事讲透它到底是什么、为什么单独拎出来做一套模式管理、具体怎么落地、实测会遇到哪些坑以及怎么把手上的方案从“能用”调成“好用”。适合正在做对话类应用、RAG系统或者被长上下文窗口和token成本折磨的开发者参考。1. 先搞清楚“上下文模式”到底在管什么做LLM应用的人每天打交道最多的其实不是一个“模型”而是messages数组。无论你用哪家API请求体里基本都是system、user、assistant三条角色消息按顺序堆在一起。模型的“记忆”就藏在这些消息里而context-mode说白了就是你决定哪些消息放进去、哪些不放、哪些被改写后再放进去的一套规则集合。1.1 模型本身没有记忆你喂什么它就记什么把LLM想象成一个每轮对话都“失忆”但阅读能力很强的临时员工。你递给它一叠聊天记录它读一遍然后作答。下一轮来了新问题你又递给它“上一轮的问答 新一轮问题”这叠新记录它再读一遍再作答。这个过程里任何你没放进messages里的内容模型都“不知道”任何你放进去了但被截断的内容模型会“记错”。所以“上下文模式”本质上是在做记忆的代管。多数人第一次遇到这个问题时的反应是加长上下文窗口——从4k换成8k从8k换成32k甚至直接买百k级别的版本。我一开始也这么干过问题确实暂时消失了但成本曲线也很感人上下文一长每次请求的输入token费用成比例上涨响应还变慢。更麻烦的是窗口再长也有天花板对话到100轮照样会爆。context-mode要解决的就是“如何在有限窗口里塞下最有价值的信息”。1.2 三个维度的冲突成本、效果、体验做上下文管理实际上是在三个变量之间找平衡成本每一次请求都要为输入token付费。上下文越长单次调用越贵频繁对话的日成本可能翻好几倍。效果上下文过长反而会稀释关键信息。我做过对比5轮以内的精准问答命中率很高一旦塞进30轮无关紧要的记录模型经常被早期内容“带偏”回答质量下降。体验如果为了省token把上下文砍得太狠用户会发现AI“失忆”追问历史问题时答不上来。体验上的伤害比多花几毛钱严重得多。context-mode不是一个单一方案而是一个状态管理思路让系统在不同时刻切换到不同的上下文策略在三个变量之间动态取舍。我把它拆成了三种基础模式组合使用。1.3 一句话描述它解决的问题如果你现在还在手动往prompt里拼接历史消息或者直接用“只保留最近N条”这种粗暴截断方式那大概率遇到过这些问题模型忘记最初的指令、回答前后矛盾、长对话费用失控、微调过的行为规则失效。context-mode 就是用一个显式的上下文管理器把这些不可控的“记忆决策”变成可配置、可切换、可观测的逻辑。2. 三种核心上下文模式的原理与取舍我自己在项目里沉淀了一套三层模式组合分别对应短期记忆、长期记忆和外部知识注入。它们不是互斥的而是会根据对话状态动态叠加。2.1 滑动窗口模式让模型只记住“眼前”的事这个模式是大多数人的起点只保留最近N轮对话。实现逻辑简单到不能再简单——从一个固定长度的队列里取消息满了就把最老的丢掉。项目说明核心机制保留最近K轮或最近M个token的消息超出部分直接丢弃典型参数window_size8轮或max_tokens6000最适配场景单轮问答、客服对话、日常闲聊任务连续性弱主要优点实现成本极低推理速度快token消耗可控主要缺点历史信息永久丢失聊到长话题时AI必然“失忆”这里有个关键参数不是轮数而是token数。因为“最近8轮”可能只值500 token也可能值5000 token。按轮数截断最容易翻车用户在贴长文档时一轮对话就占满窗口。我建议window_size同时设置轮数上限和token上限哪个先到就触发截断。但说实话滑动窗口模式只能算“能用”。对真正的业务场景它的问题是灾难性的用户在第3轮说的关键约束第10轮就查不到了。所以它只适合做其他模式的“兜底”策略而不是唯一方案。2.2 摘要压缩模式把旧对话“压成记忆碎片”摘要压缩是滑动窗口的进阶版。思路是用模型去总结旧对话生成一段结构化摘要塞入system消息而原始消息丢掉。这样“长期记忆”还在只是变成了一种高密度压缩格式。一个典型的压缩prompt长这样示意请将以下对话历史压缩成一个JSON对象必须保留 1. 用户提出的所有硬性约束格式、语气、术语要求 2. 已经确定的事实结论 3. 尚未解决、待继续追问的问题 4. 用户偏好和禁忌 原始对话 {old_messages} 输出JSON格式的摘要控制在800 token以内。这套玩法的核心收益是把“记忆”从线性消息列表变成了“结构化记忆存档”。模型在回答后续问题时能快速读到用户的核心诉求和历史结论而不是翻一大堆细节。我实测下来28轮对话压缩成一份600~800 token的摘要64k窗口下的总输入只有原来的一半左右回答质量反而上升了——因为噪音少了。但摘要压缩有个致命弱点压缩会丢细节。摘要让它记住“用户要求尽快上线”但忘了“上线时间是下周三18点前”。所以我的建议是这里做摘要保留的侧重不是“事实”而是“约束和偏好”。而且摘要要结构化不能是流水账否则一方面模型理解成本高另一方面你要在后端对摘要做逻辑处理时也很费劲。2.3 检索注入模式长期记忆存在外面按需取用第三种模式解决的是“对话历史极长甚至跨会话”的场景。核心思路是把历史对话、业务知识存进外部存储向量数据库或普通数据库每轮请求前做检索只把相关内容注入上下文。流程大致是把历史对话切成块做embedding后存入向量库。用户新消息进来先用向量检索找出最相关的历史块。把检索结果以“记忆片段”的形式注入到system或user消息里。项目说明核心机制向量库/全文索引 相关性检索 动态注入典型参数top_k3~5个历史片段每片段200~500 token最适配场景知识库问答、跨会话记忆、企业级业务系统主要优点信息量上限高不受窗口限制跨会话可用主要缺点需要维护embedding链路检索质量直接影响效果延迟略高这才是真正能让AI“记住很久以前的事情”的模式。我做过一个客户系统用户隔了三天回来说“上次那个方案的第二点再细化一下”。如果没有检索注入模式模型根本猜不到“上次那个方案”是什么但系统在对话开始前先检索出上次讨论的内容片段注入上下文模型就能无缝接上。2.4 三种模式的组合逻辑分层记忆架构单独用任何一种都只能解决单点问题。我现在跑在生产的架构是三层叠加表层滑动窗口保留最近4~6轮原始对话保证模型对“正在讨论的事”有完整感知。中层摘要压缩对超过窗口范围的历史对话做结构化摘要塞入system消息保留硬约束。深层检索注入跨会话或更久以前的细节通过向量检索按需取用。这三层其实对应人脑的工作记忆、情景记忆和语义记忆。context-mode的管理器在每一轮请求前判断该注入哪些层每层占多少token然后拼装出一个最终发给模型的messages。3. 用 ContextManager 实现模式切换的关键设计概念归概念真正写代码时最核心的是一个ContextManager类它负责维护对话状态、做token估算、执行模式切换。下面是我在生产环境验证过的核心结构。3.1 基础数据结构给对话加上“模式状态”先定义会话状态。不要只存messages数组要给它附加元信息当前模式、token估算值、摘要缓存、上次切换时间。dataclass class SessionState: session_id: str messages: list[dict] # 原始消息列表 current_mode: str # window / summary / retrieval / hybrid mode_history: list[str] # 模式切换轨迹便于排查问题 estimated_tokens: int # 当前messages的总token估算 summary_cache: dict | None # 结构化摘要缓存 last_switch_at: datetime | None def append(self, message: dict): self.messages.append(message) self.estimated_tokens estimate_tokens(self.messages) self._maybe_switch_mode()这里的核心思路是把“模式切换”变成状态对象的一个内置行为每来一条新消息就重新估算token然后触发切换判断。而不是在业务代码里到处写if-else判断历史长度。3.2 模式切换的触发策略切换不能太频繁否则用户没察觉对话变了系统自己先精神分裂了。我设定的触发条件有三类token阈值触发当estimated_tokens超过预设的soft_limit比如16k自动摘要压缩旧对话。会话类型触发创建会话时就声明类型。客服会话默认window项目协作会话默认summaryretrieval。显式切换允许业务方调用API手动切换比如用户点击“开启长期记忆模式”。def _maybe_switch_mode(self): if self.estimated_tokens self.soft_limit: return # 1. 先尝试压缩最老的5条消息 old_messages self.messages[:-5] summary self._summarize(old_messages) self.summary_cache summary # 2. 把原始消息替换为压缩摘要计入消息列表 self.messages [{ role: system, content: f历史对话摘要{summary} }] self.messages[-5:] self.current_mode summary self.estimated_tokens estimate_tokens(self.messages)注意摘要不是丢给模型就不管了我会在摘要里加summary_version字段。当摘要版本之间发生冲突比如用户后来反悔了之前的要求检索模式能优先取用最近的摘要。这个机制帮我在实际项目中减少了很多“模型坚持说过时结论”的尴尬情况。3.3 拼装最终上下文的规则所有模式最终都汇到一个方法生成发给模型的消息序列。它有固定顺序system包含摘要和约束→ 检索到的历史片段 → 最近的原始对话 → 当前问题。def build_context(self, query: str) - list[dict]: system_parts [] if self.summary_cache: system_parts.append(f【历史摘要】{self.summary_cache}) if self.current_mode in (retrieval, hybrid): snippets retrieve_related(self.session_id, query, top_k3) if snippets: system_parts.append(f【相关历史片段】{snippets}) system_content \n\n.join(system_parts) recent self.messages[-6:] return [ {role: system, content: system_content}, *recent, {role: user, content: query} ]这套设计的核心原则是system只放“稳定的记忆”user附近只放“当下的对话”。如果system里既有摘要又有原始记录模型不知道哪个优先级更高容易乱。4. 实测踩坑记录短对话没事长对话接二连三出事理论框架只花了半天就搭好了真正让我挠头的是联调阶段。以下四个坑每一个我都花了至少半天排查希望你能绕开。4.1 坑一中文token估算不准摘要触发过早或过晚最初我用字符数除以4来估算token结果中文对话的误差能达到40%以上。中文一个字算1~2 token标点符号也占token单纯乘系数很容易把阈值算偏。最典型的现象是66%的内容还没聊完就触发了摘要压缩导致近期对话被压缩成摘要模型在后续几轮中重复问“你刚才说啥”。排查链路我先在日志里打印每一步的estimated_tokens和API返回的真实token数对比发现偏差一直在30%上下。后来又对比了不同长度对话的误差规律才确认是中文编码的问题。修复方式换用官方tokenizer做估算。OpenAI的话就是tiktoken还顺带做了一层缓存同一个消息体不重复估算。import tiktoken _enc tiktoken.get_encoding(cl100k_base) def estimate_tokens(messages: list[dict]) - int: # 对组装后的字符串整体估算而不是逐条累加避免重复计费格式token raw \n.join(f{m[role]}: {m[content]} for m in messages) return len(_enc.encode(raw))换完之后误差基本控制在5%以内。计算token时不要逐条编码再求和因为API实际计费还包含消息格式token最好拼接成接近真实请求的字符串再统一编码。4.2 坑二摘要压缩的信息失真模型产生幻觉回怼用户这是最恶劣的坑。摘要压缩跑了一个星期后用户反馈“AI老是不承认自己说过的话”。查了一圈日志发现是摘要prompt写得太随意模型把“用户未确认的内容”也归纳成了“已确认结论”后期回答时拿错误结论当依据开始理直气壮地输出错误答案。修复方案把摘要prompt从“总结这段对话”改成“只提取四类信息”:硬性约束、已确认事实、待办事项、风险问题。并且强制输出JSON由程序解析再决定哪些内容能放入 system。有一次被模型总结出一句“用户同意月底前交付”但原文里根本没有这层意思由于是自由文本摘要所以模型自由发挥了。改成强制JSON 字段拆分之后这种幻觉少了很多。4.3 坑三上下文“泄漏”摘要内容串到别的会话里检索注入模式上线后我遇到了一个诡异问题A用户问的问题回答里出现了B用户的名字。第一反应是向量库查错了检查后确认embedding和检索逻辑都没问题。后来才定位到是SessionState缓存写得太随意——会话结束时没有及时清理内存里的summary_cache新会话的system组装时误用了上一个会话的缓存摘要。修复方式在build_context方法开头强制检查session_id是否匹配以及给summary_cache加会话过期时间。从那次之后我再也没有把内存态当作持久态用过。上下文管理器的状态必须和会话生命周期严格绑定这是我从这个坑里得到的最深体会。4.4 坑四模式切换后缓存没有失效旧的摘要一直撑着最后这个坑比较隐蔽。summary模式和retrieval模式叠加使用时为了省开销我对retrieval结果做了缓存缓存key是query的前50个字符。问题在于用户后续输入改变了意图但query前缀没变缓存一直返回旧片段导致模型反复用同一个角度的历史信息回答新角度的提问。修复方式缓存key改用“query的embedding向量”而不是文本前缀。或者其他方案比如给缓存加TTL30秒内相同embedding才命中。这算是对context-mode系统里子模块的优化但对于整体体验的影响非常大——失忆感往往不是模型造成的而是检索缓存造成的。5. 从“能用”走向“好用”的进阶配置解决了上面的坑context-mode系统就算稳定可用了。但如果想让它真正在不同业务场景下表现出彩下面几个方向的精调很关键。5.1 多级记忆的容量分配策略我推荐的初始参数基线是这样的记忆层级策略建议配置工作记忆滑动窗口保留最近对话window_size6轮情景记忆结构化摘要soft_limit16000 token超出后压缩语义记忆向量库检索top_k3每片段300~500 token系统约束常驻system固定长度不参与裁剪这套配置在大多数通用问答场景下能获得“既不失忆又省钱”的效果。如果你做的是垂直客服系统窗口可以调小一点4轮即可摘要权重拉高因为客服对话的约束比细节重要如果你做的是创作辅助工具那么检索的权重应该降低保留更多原始对话风格摘要容易抹平语气特点。5.2 结合业务场景调整检索权重检索注入不是每轮都要做的。我做过一个统计在闲聊型会话中过度注入历史片段对回答质量没有正向影响反而让模型回答显得生硬。所以我在上下文管理器里加了一个“意图分类”步骤判断用户当前的问题属于“延续历史”需要检索还是“新话题”不需要检索。def need_retrieval(self, query: str) - bool: # 简单启发式包含“刚才”“上次”“之前”“那个方案”等词时触发 keywords [刚才, 上次, 之前, 之前说的, 那个方案, 上回] return any(kw in query for kw in keywords)启发式规则虽然简单但在大多数场景下命中率很高。更复杂的做法是用一个小分类模型判断query类型但如果只是内部工具我觉得先跑关键词规则就够了加分类模型反而增加延迟。5.3 可观测性是上下文管理的生命线这套系统最容易被忽视的就是可观测性。context-mode一旦跑起来你很难直观判断“模型为什么用这段记忆”除非每一步都能回溯。我在实际项目里维护了一张context_log表每次请求都会记录当前模式(mode)每次组装出来的消息数量和总token数摘要的版本号检索命中了哪些片段及其相关性得分触发模式切换的原因排查问题时这张表比什么调试工具都管用。有一次用户反馈“AI今天记性特别差”我看log发现是摘要prompt更新后summary_version没变旧缓存一直有效。这种问题要是没有日志可能得排查一整天。5.4 成本优化的最后一步模式降级最后分享一个省钱技巧。context-mode系统里我加了一个“成本路由”当对话模式为window且窗口占用不到30%时直接用一个小参数模型处理只有触发摘要或检索模式时才升级到大参数模型——因为这时问题变复杂了小模型撑不住。这个策略帮我省了接近40%的推理成本而用户无感知。因为简单问题的上下文本来就短不需要大模型“杀鸡用牛刀”。6. 几个压箱底的经验整套context-mode设计里我最想强调的不是某个算法而是“分层思维”。很多开发者一上来就想用最复杂的方案——先把对话全量embedding再引入向量检索结果上下文倒是全了成本和延迟也一起上去了。我自己经历过从“粗暴截断”到“无脑全存”最后才落到三层组合这个过程最能说明问题上下文管理的核心不是技术堆料而是对不同层级记忆的清晰规划。如果你打算在自己的项目里落地这套机制我建议从简化版开始只做“滑动窗口 摘要压缩”两层就可以跑通业务先观察模型的行为变化和token开销再逐步引入检索注入。一次引入太多机制出了问题都不知道该查哪个环节。等你真的跑起来你自然会发现context-mode最大的价值不是省了多少钱而是让AI的“人格连续性”稳定了下来——用户会觉得这个AI有记忆、懂分寸、不乱说话这比任何花哨的功能都能留住用户。 
长河君 · 2026/10/29 6:34:56 · 阅读 1.2k context-mode实战：大模型对话上下文管理模式设计与落地
聊到context-mode我得先从一个让我抓狂的下午说起。当时我在给一个企业内部文档问答助手调系统用户连续问了十几个问题前几条还在聊“Q3销售预测的假设前提”后几条已经跳到“那这个预测和去年的口径怎么对齐”。模型答到后面突然开始胡言乱语回头一看控制台发现对话历史里塞了20多轮消息token数早就超过了预设窗口旧的指令被挤掉了模型根本记不住最开始约定的回答规范。后来我把整套上下文处理逻辑重写了一遍引入了一个自己定义的context-mode机制——本质上是针对不同对话阶段、不同任务类型动态切换上下文管理策略。这套东西上线之后长对话的稳定性明显提升API费用也降了不少。今天这篇就当一次复盘把“上下文模式”这件事讲透它到底是什么、为什么单独拎出来做一套模式管理、具体怎么落地、实测会遇到哪些坑以及怎么把手上的方案从“能用”调成“好用”。适合正在做对话类应用、RAG系统或者被长上下文窗口和token成本折磨的开发者参考。1. 先搞清楚“上下文模式”到底在管什么做LLM应用的人每天打交道最多的其实不是一个“模型”而是messages数组。无论你用哪家API请求体里基本都是system、user、assistant三条角色消息按顺序堆在一起。模型的“记忆”就藏在这些消息里而context-mode说白了就是你决定哪些消息放进去、哪些不放、哪些被改写后再放进去的一套规则集合。1.1 模型本身没有记忆你喂什么它就记什么把LLM想象成一个每轮对话都“失忆”但阅读能力很强的临时员工。你递给它一叠聊天记录它读一遍然后作答。下一轮来了新问题你又递给它“上一轮的问答 新一轮问题”这叠新记录它再读一遍再作答。这个过程里任何你没放进messages里的内容模型都“不知道”任何你放进去了但被截断的内容模型会“记错”。所以“上下文模式”本质上是在做记忆的代管。多数人第一次遇到这个问题时的反应是加长上下文窗口——从4k换成8k从8k换成32k甚至直接买百k级别的版本。我一开始也这么干过问题确实暂时消失了但成本曲线也很感人上下文一长每次请求的输入token费用成比例上涨响应还变慢。更麻烦的是窗口再长也有天花板对话到100轮照样会爆。context-mode要解决的就是“如何在有限窗口里塞下最有价值的信息”。1.2 三个维度的冲突成本、效果、体验做上下文管理实际上是在三个变量之间找平衡成本每一次请求都要为输入token付费。上下文越长单次调用越贵频繁对话的日成本可能翻好几倍。效果上下文过长反而会稀释关键信息。我做过对比5轮以内的精准问答命中率很高一旦塞进30轮无关紧要的记录模型经常被早期内容“带偏”回答质量下降。体验如果为了省token把上下文砍得太狠用户会发现AI“失忆”追问历史问题时答不上来。体验上的伤害比多花几毛钱严重得多。context-mode不是一个单一方案而是一个状态管理思路让系统在不同时刻切换到不同的上下文策略在三个变量之间动态取舍。我把它拆成了三种基础模式组合使用。1.3 一句话描述它解决的问题如果你现在还在手动往prompt里拼接历史消息或者直接用“只保留最近N条”这种粗暴截断方式那大概率遇到过这些问题模型忘记最初的指令、回答前后矛盾、长对话费用失控、微调过的行为规则失效。context-mode 就是用一个显式的上下文管理器把这些不可控的“记忆决策”变成可配置、可切换、可观测的逻辑。2. 三种核心上下文模式的原理与取舍我自己在项目里沉淀了一套三层模式组合分别对应短期记忆、长期记忆和外部知识注入。它们不是互斥的而是会根据对话状态动态叠加。2.1 滑动窗口模式让模型只记住“眼前”的事这个模式是大多数人的起点只保留最近N轮对话。实现逻辑简单到不能再简单——从一个固定长度的队列里取消息满了就把最老的丢掉。项目说明核心机制保留最近K轮或最近M个token的消息超出部分直接丢弃典型参数window_size8轮或max_tokens6000最适配场景单轮问答、客服对话、日常闲聊任务连续性弱主要优点实现成本极低推理速度快token消耗可控主要缺点历史信息永久丢失聊到长话题时AI必然“失忆”这里有个关键参数不是轮数而是token数。因为“最近8轮”可能只值500 token也可能值5000 token。按轮数截断最容易翻车用户在贴长文档时一轮对话就占满窗口。我建议window_size同时设置轮数上限和token上限哪个先到就触发截断。但说实话滑动窗口模式只能算“能用”。对真正的业务场景它的问题是灾难性的用户在第3轮说的关键约束第10轮就查不到了。所以它只适合做其他模式的“兜底”策略而不是唯一方案。2.2 摘要压缩模式把旧对话“压成记忆碎片”摘要压缩是滑动窗口的进阶版。思路是用模型去总结旧对话生成一段结构化摘要塞入system消息而原始消息丢掉。这样“长期记忆”还在只是变成了一种高密度压缩格式。一个典型的压缩prompt长这样示意请将以下对话历史压缩成一个JSON对象必须保留 1. 用户提出的所有硬性约束格式、语气、术语要求 2. 已经确定的事实结论 3. 尚未解决、待继续追问的问题 4. 用户偏好和禁忌 原始对话 {old_messages} 输出JSON格式的摘要控制在800 token以内。这套玩法的核心收益是把“记忆”从线性消息列表变成了“结构化记忆存档”。模型在回答后续问题时能快速读到用户的核心诉求和历史结论而不是翻一大堆细节。我实测下来28轮对话压缩成一份600~800 token的摘要64k窗口下的总输入只有原来的一半左右回答质量反而上升了——因为噪音少了。但摘要压缩有个致命弱点压缩会丢细节。摘要让它记住“用户要求尽快上线”但忘了“上线时间是下周三18点前”。所以我的建议是这里做摘要保留的侧重不是“事实”而是“约束和偏好”。而且摘要要结构化不能是流水账否则一方面模型理解成本高另一方面你要在后端对摘要做逻辑处理时也很费劲。2.3 检索注入模式长期记忆存在外面按需取用第三种模式解决的是“对话历史极长甚至跨会话”的场景。核心思路是把历史对话、业务知识存进外部存储向量数据库或普通数据库每轮请求前做检索只把相关内容注入上下文。流程大致是把历史对话切成块做embedding后存入向量库。用户新消息进来先用向量检索找出最相关的历史块。把检索结果以“记忆片段”的形式注入到system或user消息里。项目说明核心机制向量库/全文索引 相关性检索 动态注入典型参数top_k3~5个历史片段每片段200~500 token最适配场景知识库问答、跨会话记忆、企业级业务系统主要优点信息量上限高不受窗口限制跨会话可用主要缺点需要维护embedding链路检索质量直接影响效果延迟略高这才是真正能让AI“记住很久以前的事情”的模式。我做过一个客户系统用户隔了三天回来说“上次那个方案的第二点再细化一下”。如果没有检索注入模式模型根本猜不到“上次那个方案”是什么但系统在对话开始前先检索出上次讨论的内容片段注入上下文模型就能无缝接上。2.4 三种模式的组合逻辑分层记忆架构单独用任何一种都只能解决单点问题。我现在跑在生产的架构是三层叠加表层滑动窗口保留最近4~6轮原始对话保证模型对“正在讨论的事”有完整感知。中层摘要压缩对超过窗口范围的历史对话做结构化摘要塞入system消息保留硬约束。深层检索注入跨会话或更久以前的细节通过向量检索按需取用。这三层其实对应人脑的工作记忆、情景记忆和语义记忆。context-mode的管理器在每一轮请求前判断该注入哪些层每层占多少token然后拼装出一个最终发给模型的messages。3. 用 ContextManager 实现模式切换的关键设计概念归概念真正写代码时最核心的是一个ContextManager类它负责维护对话状态、做token估算、执行模式切换。下面是我在生产环境验证过的核心结构。3.1 基础数据结构给对话加上“模式状态”先定义会话状态。不要只存messages数组要给它附加元信息当前模式、token估算值、摘要缓存、上次切换时间。dataclass class SessionState: session_id: str messages: list[dict] # 原始消息列表 current_mode: str # window / summary / retrieval / hybrid mode_history: list[str] # 模式切换轨迹便于排查问题 estimated_tokens: int # 当前messages的总token估算 summary_cache: dict | None # 结构化摘要缓存 last_switch_at: datetime | None def append(self, message: dict): self.messages.append(message) self.estimated_tokens estimate_tokens(self.messages) self._maybe_switch_mode()这里的核心思路是把“模式切换”变成状态对象的一个内置行为每来一条新消息就重新估算token然后触发切换判断。而不是在业务代码里到处写if-else判断历史长度。3.2 模式切换的触发策略切换不能太频繁否则用户没察觉对话变了系统自己先精神分裂了。我设定的触发条件有三类token阈值触发当estimated_tokens超过预设的soft_limit比如16k自动摘要压缩旧对话。会话类型触发创建会话时就声明类型。客服会话默认window项目协作会话默认summaryretrieval。显式切换允许业务方调用API手动切换比如用户点击“开启长期记忆模式”。def _maybe_switch_mode(self): if self.estimated_tokens self.soft_limit: return # 1. 先尝试压缩最老的5条消息 old_messages self.messages[:-5] summary self._summarize(old_messages) self.summary_cache summary # 2. 把原始消息替换为压缩摘要计入消息列表 self.messages [{ role: system, content: f历史对话摘要{summary} }] self.messages[-5:] self.current_mode summary self.estimated_tokens estimate_tokens(self.messages)注意摘要不是丢给模型就不管了我会在摘要里加summary_version字段。当摘要版本之间发生冲突比如用户后来反悔了之前的要求检索模式能优先取用最近的摘要。这个机制帮我在实际项目中减少了很多“模型坚持说过时结论”的尴尬情况。3.3 拼装最终上下文的规则所有模式最终都汇到一个方法生成发给模型的消息序列。它有固定顺序system包含摘要和约束→ 检索到的历史片段 → 最近的原始对话 → 当前问题。def build_context(self, query: str) - list[dict]: system_parts [] if self.summary_cache: system_parts.append(f【历史摘要】{self.summary_cache}) if self.current_mode in (retrieval, hybrid): snippets retrieve_related(self.session_id, query, top_k3) if snippets: system_parts.append(f【相关历史片段】{snippets}) system_content \n\n.join(system_parts) recent self.messages[-6:] return [ {role: system, content: system_content}, *recent, {role: user, content: query} ]这套设计的核心原则是system只放“稳定的记忆”user附近只放“当下的对话”。如果system里既有摘要又有原始记录模型不知道哪个优先级更高容易乱。4. 实测踩坑记录短对话没事长对话接二连三出事理论框架只花了半天就搭好了真正让我挠头的是联调阶段。以下四个坑每一个我都花了至少半天排查希望你能绕开。4.1 坑一中文token估算不准摘要触发过早或过晚最初我用字符数除以4来估算token结果中文对话的误差能达到40%以上。中文一个字算1~2 token标点符号也占token单纯乘系数很容易把阈值算偏。最典型的现象是66%的内容还没聊完就触发了摘要压缩导致近期对话被压缩成摘要模型在后续几轮中重复问“你刚才说啥”。排查链路我先在日志里打印每一步的estimated_tokens和API返回的真实token数对比发现偏差一直在30%上下。后来又对比了不同长度对话的误差规律才确认是中文编码的问题。修复方式换用官方tokenizer做估算。OpenAI的话就是tiktoken还顺带做了一层缓存同一个消息体不重复估算。import tiktoken _enc tiktoken.get_encoding(cl100k_base) def estimate_tokens(messages: list[dict]) - int: # 对组装后的字符串整体估算而不是逐条累加避免重复计费格式token raw \n.join(f{m[role]}: {m[content]} for m in messages) return len(_enc.encode(raw))换完之后误差基本控制在5%以内。计算token时不要逐条编码再求和因为API实际计费还包含消息格式token最好拼接成接近真实请求的字符串再统一编码。4.2 坑二摘要压缩的信息失真模型产生幻觉回怼用户这是最恶劣的坑。摘要压缩跑了一个星期后用户反馈“AI老是不承认自己说过的话”。查了一圈日志发现是摘要prompt写得太随意模型把“用户未确认的内容”也归纳成了“已确认结论”后期回答时拿错误结论当依据开始理直气壮地输出错误答案。修复方案把摘要prompt从“总结这段对话”改成“只提取四类信息”:硬性约束、已确认事实、待办事项、风险问题。并且强制输出JSON由程序解析再决定哪些内容能放入 system。有一次被模型总结出一句“用户同意月底前交付”但原文里根本没有这层意思由于是自由文本摘要所以模型自由发挥了。改成强制JSON 字段拆分之后这种幻觉少了很多。4.3 坑三上下文“泄漏”摘要内容串到别的会话里检索注入模式上线后我遇到了一个诡异问题A用户问的问题回答里出现了B用户的名字。第一反应是向量库查错了检查后确认embedding和检索逻辑都没问题。后来才定位到是SessionState缓存写得太随意——会话结束时没有及时清理内存里的summary_cache新会话的system组装时误用了上一个会话的缓存摘要。修复方式在build_context方法开头强制检查session_id是否匹配以及给summary_cache加会话过期时间。从那次之后我再也没有把内存态当作持久态用过。上下文管理器的状态必须和会话生命周期严格绑定这是我从这个坑里得到的最深体会。4.4 坑四模式切换后缓存没有失效旧的摘要一直撑着最后这个坑比较隐蔽。summary模式和retrieval模式叠加使用时为了省开销我对retrieval结果做了缓存缓存key是query的前50个字符。问题在于用户后续输入改变了意图但query前缀没变缓存一直返回旧片段导致模型反复用同一个角度的历史信息回答新角度的提问。修复方式缓存key改用“query的embedding向量”而不是文本前缀。或者其他方案比如给缓存加TTL30秒内相同embedding才命中。这算是对context-mode系统里子模块的优化但对于整体体验的影响非常大——失忆感往往不是模型造成的而是检索缓存造成的。5. 从“能用”走向“好用”的进阶配置解决了上面的坑context-mode系统就算稳定可用了。但如果想让它真正在不同业务场景下表现出彩下面几个方向的精调很关键。5.1 多级记忆的容量分配策略我推荐的初始参数基线是这样的记忆层级策略建议配置工作记忆滑动窗口保留最近对话window_size6轮情景记忆结构化摘要soft_limit16000 token超出后压缩语义记忆向量库检索top_k3每片段300~500 token系统约束常驻system固定长度不参与裁剪这套配置在大多数通用问答场景下能获得“既不失忆又省钱”的效果。如果你做的是垂直客服系统窗口可以调小一点4轮即可摘要权重拉高因为客服对话的约束比细节重要如果你做的是创作辅助工具那么检索的权重应该降低保留更多原始对话风格摘要容易抹平语气特点。5.2 结合业务场景调整检索权重检索注入不是每轮都要做的。我做过一个统计在闲聊型会话中过度注入历史片段对回答质量没有正向影响反而让模型回答显得生硬。所以我在上下文管理器里加了一个“意图分类”步骤判断用户当前的问题属于“延续历史”需要检索还是“新话题”不需要检索。def need_retrieval(self, query: str) - bool: # 简单启发式包含“刚才”“上次”“之前”“那个方案”等词时触发 keywords [刚才, 上次, 之前, 之前说的, 那个方案, 上回] return any(kw in query for kw in keywords)启发式规则虽然简单但在大多数场景下命中率很高。更复杂的做法是用一个小分类模型判断query类型但如果只是内部工具我觉得先跑关键词规则就够了加分类模型反而增加延迟。5.3 可观测性是上下文管理的生命线这套系统最容易被忽视的就是可观测性。context-mode一旦跑起来你很难直观判断“模型为什么用这段记忆”除非每一步都能回溯。我在实际项目里维护了一张context_log表每次请求都会记录当前模式(mode)每次组装出来的消息数量和总token数摘要的版本号检索命中了哪些片段及其相关性得分触发模式切换的原因排查问题时这张表比什么调试工具都管用。有一次用户反馈“AI今天记性特别差”我看log发现是摘要prompt更新后summary_version没变旧缓存一直有效。这种问题要是没有日志可能得排查一整天。5.4 成本优化的最后一步模式降级最后分享一个省钱技巧。context-mode系统里我加了一个“成本路由”当对话模式为window且窗口占用不到30%时直接用一个小参数模型处理只有触发摘要或检索模式时才升级到大参数模型——因为这时问题变复杂了小模型撑不住。这个策略帮我省了接近40%的推理成本而用户无感知。因为简单问题的上下文本来就短不需要大模型“杀鸡用牛刀”。6. 几个压箱底的经验整套context-mode设计里我最想强调的不是某个算法而是“分层思维”。很多开发者一上来就想用最复杂的方案——先把对话全量embedding再引入向量检索结果上下文倒是全了成本和延迟也一起上去了。我自己经历过从“粗暴截断”到“无脑全存”最后才落到三层组合这个过程最能说明问题上下文管理的核心不是技术堆料而是对不同层级记忆的清晰规划。如果你打算在自己的项目里落地这套机制我建议从简化版开始只做“滑动窗口 摘要压缩”两层就可以跑通业务先观察模型的行为变化和token开销再逐步引入检索注入。一次引入太多机制出了问题都不知道该查哪个环节。等你真的跑起来你自然会发现context-mode最大的价值不是省了多少钱而是让AI的“人格连续性”稳定了下来——用户会觉得这个AI有记忆、懂分寸、不乱说话这比任何花哨的功能都能留住用户。