如果你经常和大模型 API 打交道一定碰到过这种头疼时刻对话才过十几轮模型就开始把前面说过的关键信息忘得干干净净更烦的是把全部历史一股脑塞进请求token 费用蹭蹭涨最后还经常因为超长被拒。很多初稿项目都死在这个环节上其实问题不在模型而在“上下文管理”。我前段时间把自己反复踩坑后沉淀的一套方案抽成了独立模块名字就叫 context-mode。它的工作很单纯用几种可切换的模式决定哪些历史对话要保留、哪些要压缩、哪些干脆丢弃。这篇文章会完整拆解 context-mode 的设计逻辑、实操代码和调参经验适合正在做对话机器人、AI 助手、Agent 后台的开发者参考。1. context-mode 到底解决什么问题1.1 大模型对话中的“失忆”现象做过真实对话应用的人都知道模型不是真的“记得”你之前说过什么。每次请求都是一次“重新读档”你需要把系统提示词、历史对话、用户当前输入全部拼进 prompt模型才能根据这些内容生成回复。任何上下文窗口都有长度上限一旦超限服务端会直接报错不超限也不能无脑把所有历史都塞进去因为大段中间内容很容易被模型“视而不见”这在业界被称为“Lost in the Middle”问题。我一个实际项目里遇到过很典型的场景用户和客服机器人聊到第 40 轮时突然问“我之前说的收货地址你还记得吗”。如果只保留最近 20 轮地址在第 5 轮早就被挤掉了如果保留全量历史请求体巨大响应延迟翻倍而且模型可能在 80% 的情况下忽略中间部分的地址直接给出模棱两可的回答。这类现象不是模型笨而是没有做结构化的上下文管理。context-mode 的核心价值就是把“历史消息怎么处理”这个横切关注点从业务代码里剥离出来。你可以像切换算法一样切换上下文策略而不是在每个接口里手写一堆 if-else 去拼接 messages。它会帮你计算 token、控制预算、决定裁剪方式以及在不同模式之间自动降级。1.2 手工拼 Prompt 的痛点和 context-mode 的定位很多团队第一版都是这么干的拿一个 list 存对话请求前把最近的 N 条取出来再加 system prompt然后发给模型。一开始没问题等对话轮数上去了问题就全冒出来了。首先是截断很粗暴。只按“条数”截断不考虑内容的长度差异。可能最近 10 条里有一条特别长的工具返回结果直接把 16k token 撑爆。其次是系统提示词可能被挤出有效范围。如果连续消息太长部分服务端实现会从最前面开始丢掉内容丢掉的可能不是你最想丢的历史消息而是你辛辛苦苦写的系统指令模型行为当场漂移。再次是信息丢失没有感知。业务里明明需要用户手机号、订单号、偏好这些事实但截断后这些字段没了模型就会一本正经地编造一个“默认值”这对生产环境是致命的。context-mode 的定位很简单它不替代 RAG也不替代向量数据库它是对话系统里的“内存管理器”。它知道你手头有哪些历史数据也知道模型能吃下多少更知道哪些信息值得被长期记住。你只需要告诉它“当前是什么场景、预算上限是多少”它会在每个请求前给你一份组织好的上下文而不是给你一堆原始聊天记录。2. 核心设计三种上下文模式怎么选2.1 滑动窗口模式最简单有效的基线方案滑动窗口是我建议所有项目最先实现的模式也是 context-mode 默认开启的模式。它的思路很朴素只保留最近 N 轮对话窗口之外的内容全部丢弃。这里的“轮”不是严格意义上的一问一答而是一组 user 和 assistant 消息的配对。实现上可以用一个固定长度的队列超过长度就把最老的消息弹出。但有两个细节不能省系统提示词要单独放在最前面并且永远不参与滑动淘汰。容量限制最好按 token 数算而不是按消息条数算。因为一条超长工具调用可能顶几十条普通消息。按 token 数做滑动窗口初始化时会根据模型的最大上下文长度、计划输出 token 数、系统提示词占用算出历史消息预算。每次新增消息后如果总 token 数超过预算就从最老的非系统消息开始淘汰直到回到预算内。这样能保证请求永远不会因为“超长”被拒代价是早期关键信息会被丢掉。这个模式适合什么场景呢智能客服、闲聊机器人、短期任务型对话。这些场景对“最近说了什么”的依赖远大于“很久以前说过什么”。如果用户在第 3 轮报了手机号第 30 轮再要求你复述滑动窗口大概率已经记不住了那就需要更聪明的模式。2.2 摘要压缩模式用 token 换记忆既然滑动窗口会丢信息那就把旧内容“浓缩”一下再留下。摘要压缩模式的核心思路是当历史消息超过某个阈值调用一次摘要模型把窗口外的早期对话压缩成一段 200~500 字的摘要然后让这条摘要成为一个独立的上下文消息放在系统提示词之后。这样做的好处是明显的。同样是 80 轮对话滑动窗口可能只能留最后 15 轮而摘要模式可以把 80 轮的关键事实压缩进一段摘要再结合最近 15 轮既保住了用户偏好和关键指令又控制住了 token 总量。但摘要模式有两个坑必须提前设计好增量摘要 vs 从零摘要。每轮窗口滚动后都重新把完整历史送进摘要模型token 开销巨大不现实。更好的做法是“增量摘要”把上一版摘要 新产生的历史片段送进摘要模型生成新摘要。成本低但一旦某次摘要出错错误会被“滚雪球”式放大。摘要内容的失真。摘要模型也是模型它可能漏掉具体数字、省略否定表达。解决方法是把“必须保留字段”以结构化方式额外存储比如用户 ID、订单号、金额、时间节点这些字段不靠自然语言摘要而是单独放在一个 JSON 块里附加到摘要后面。摘要模式适合需要跨多轮保持角色设定、用户偏好、项目背景的应用。它比滑动窗口聪明但比向量召回模式轻量是很多商业产品实际会采用的第一套升级方案。2.3 向量召回模式长期记忆的正确打开方式如果对话系统要具备“记忆一个月前某天提到过的事情”摘要模式也会力不从心因为摘要本身有长度限制存不下足够细节。这时候需要向量召回模式把历史对话切片、向量化存进内存向量索引或向量数据库每次构造上下文时拿当前用户输入去检索召回最相关的若干历史片段。我知道很多人会问这不就是 RAG 吗本质上机制类似但定位不同。RAG 通常检索外部知识库、文档库而 context-mode 的向量召回检索的是“这个会话自己的历史记忆”。你可以把它理解成给对话系统装了一个长效记忆皮层。实现时最核心的问题是切片粒度。切太大召回精度低切太小上下文碎片化。我的经验是单条消息超过 200 token 就单独成片连续短消息可以按每 3~5 轮合并成一个 chunk再重叠 1 轮做切分。这样既保留了语义完整性又避免召回片段太碎。向量召回模式适合 Agent、个人助手、陪伴型应用以及任何需要“长期人设记忆”的产品。但要注意它不是万能的。向量检索有召回精度问题不能保证 100% 找到那条关键信息。所以在生产里我通常不建议单独用向量模式而是把它和滑动窗口、摘要模式组合起来形成混合上下文。我用一个表格对比三种模式的核心差异方便你做选型模式实现复杂度token 占用关键信息保留率适用场景滑动窗口低低中客服、闲聊、短期任务摘要压缩中低较高长会话、角色设定、偏好记忆向量召回高低高受召回精度影响Agent、个人助手、长期记忆3. 实操从零实现一个 context-mode 模块3.1 数据结构和基础接口设计第一版 context-mode 我建议只做一个核心类ContextManager它负责维护全量历史、状态切换和上下文生成。注意一点原始全量历史要一直存着不要为了省内存而直接把它删掉。build_context输出的只是模型的输入不是你的记忆源头。下面这段是基础骨架我用 Python 写方便你移植到任意语言from collections import deque class ContextManager: def __init__(self, modesliding_window, max_context_tokens20000, system_promptNone): self.mode mode self.max_context_tokens max_context_tokens self.system_prompt system_prompt self.history [] # 原始全量历史永不清空 self.summary # 摘要模式下的浓缩记忆 self.vector_store None # 向量模式下的检索器 self._recent_count 20 # 每次保留最近多少轮 def add_message(self, role, content): self.history.append({role: role, content: content}) def build_context(self): if self.mode sliding_window: return self._build_sliding() elif self.mode summary: return self._build_summary() elif self.mode vector: return self._build_vector() else: raise ValueError(funsupported mode: {self.mode})add_message负责把新消息追加到历史列表。调用方拿到模型返回后也应该调用它把 assistant 消息写回。build_context是核心入口它返回一个 messages 列表可以直接作为 Chat 接口的请求体。_build_sliding实现如下。注意 system prompt 要第一个返回并且永远不计入淘汰范围def _build_sliding(self): messages [] if self.system_prompt: messages.append({role: system, content: self.system_prompt}) # 按 token 数保留最近消息而不是按条数 recent deque() token_used 0 for msg in reversed(self.history): delta estimate_tokens(msg[content]) if token_used delta self.max_context_tokens: break recent.appendleft(msg) token_used delta messages.extend(recent) return messages这里的estimate_tokens可以先用简单规则英文字符数除以 4中文字符数直接算 1 个汉字约 1.5 token。生产环境建议使用你接入模型的 tokenizer 做精确计算否则并发高了以后会出现误差累积。3.2 模式切换与自动触发的实现不同模式不是做成三个孤立的类而是通过 ContextManager 内部的策略函数切换。这样做的目的是为了支持“自动降级”当预算充足时用高质量模式当预算紧张时自动回退到省 token 的模式。我在 context-mode 里设计了一个ensure_within_budget方法。每次build_context之前先计算当前全量历史的 token 数如果超过预算的 70%就触发一次压缩或截断。70% 这个数字不是随便拍的它是经验值给模型输出留出空间也给用户正在输入的消息预留余量避免刚构建完又超限。自动触发逻辑示例def _maybe_compress(self): current_tokens sum(estimate_tokens(msg[content]) for msg in self.history) if current_tokens self.max_context_tokens * 0.7: return if self.mode sliding_window: # 不需要额外操作_build_sliding 会自然截断 return if self.mode summary: self._refresh_summary() # vector 模式下不强制压缩靠检索控制规模注意不要在每次请求时都做摘要刷新否则 token 成本会让你怀疑人生。我通常只在两处触发连续新增消息超过 10 轮或者历史 token 超过阈值的 1.5 倍。也就是说给压缩留一个缓冲区间。3.3 完整接入 Chat API 的示例下面是一个接入大模型 Chat 接口的完整伪代码你可以把它直接抄到自己的 FastAPI 服务里跑起来context_manager ContextManager( modehybrid, max_context_tokens24000, system_prompt你是一个耐心的客服助手 ) def chat_with_user(user_message: str) - str: context_manager.add_message(user, user_message) messages context_manager.build_context() # 这里的 chat_completion 调用替换成你实际用的模型接口 response chat_completion( messagesmessages, max_tokens2048, temperature0.7 ) assistant_text response[choices][0][message][content] context_manager.add_message(assistant, assistant_text) return assistant_text这就是 context-mode 最舒服的使用方式业务代码里只要add_message和build_context所有上下文策略都被封装在模块内部。你先用这套写业务等以后想切换模式只需要改初始化参数不用动接口逻辑。hybrid 模式的build_context会这样组织消息def _build_hybrid(self, user_query): messages [{role: system, content: self.system_prompt}] # 第一段摘要放最前面 if self.summary: messages.append({role: system, content: 历史摘要 self.summary}) # 第二段最近窗口保留最后 20 条 messages.extend(self._recent_messages(20)) # 第三段向量召回检索与当前 query 相关的历史片段 if self.vector_store: recalled self.vector_store.search(user_query, top_k3) for chunk in recalled: messages.append({role: user, content: f[回忆片段] {chunk}}) return messages这里有个小技巧向量召回的片段不要直接塞成 user 消息避免模型分不清哪句是当前输入。我给它们加了[回忆片段]前缀再放进 user 消息这样模型知道这些是历史背景不是当前指令。如果你不加前缀模型很可能把记忆片段当成用户的即时输入导致回答跑偏。4. 参数调优与 Token 成本控制4.1 窗口大小怎么算一个实际计算例子很多人在初始化 ContextManager 时最纠结的是max_context_tokens到底设多少。这个值不能拍脑袋我一般用下面这个公式反推历史消息预算 模型最大上下文 - 计划输出 - 系统提示词 - 安全余量举个例子。假设你用的模型支持 128k 上下文计划每次输出 2k token系统提示词加人设定义大概 1k token再留 3k 作为安全余量那么历史消息预算就是128000 - 2048 - 1024 - 3072 121856看起来很大但我强烈不建议真的把它用满。原因有两个一是 token 单价摆在那里每次都接近上限成本会很难看二是模型对超长上下文的注意力会分散中间内容经常被忽略。所以我实际应用中会把预算再打个六折也就是初始设置max_context_tokens 73000左右。那么 73000 token 大概能放多少轮对话中文场景下一个汉字大约对应 1~1.5 token一句 20 字的用户消息加 100 字的模型回复一轮对话大概 150~200 token。73000 / 180 约等于 400 轮。也就是说滑动窗口模式下你理论上可以保留近 400 轮日常对话。注意这已经比大多数人想象中长很多了问题从来不是“窗口不够大”而是“没有有效组织窗口内的内容”。4.2 压缩触发阈值和摘要保留策略我建议压缩阈值设置在历史预算的 60%~70%。比如max_context_tokens24000那么当历史消息累计超过 16800 token 时就触发一次摘要或截断。为什么不是 90% 或 95%因为模型输出本身也要占 token如果在请求构造前一刻历史已经占了 95%很可能等模型生成长回答时会冲破上限被服务端报错整个交互直接失败。摘要保留策略我总结为三句话摘要放最前别放中间。摘要信息密度高应该紧跟在系统提示词之后确保模型优先看到。摘要要定期重建。增量摘要越滚越飘每隔 20 轮或摘要长度超过 1000 token就全量重写一次。关键字段单独存。用户手机号、地址、订单号这种硬信息不要只依赖摘要模型去记单独用 JSON 存一份在 build_context 时拼到摘要里。这里给一个增量摘要的请求模板你可以参考你是摘要助手。下面是上一版摘要和新对话请生成一版更新的摘要。 要求保留所有数字、日期、地名人名、用户偏好不要遗漏否定信息。 上一版摘要 {old_summary} 新增对话 {new_messages} 新的摘要注意一定要在指令里强调“不要遗漏否定信息”。我踩过很多次坑摘要模型把“用户不需要快递”压缩成“用户需要快递”后面所有回答全都建立在错误记忆上。这个坑如果不提前规避到了生产环境就是重大事故。4.3 实测性能对比不同模式的响应延迟与效果我给过自己一个内部测试用 100 轮对话历史分别跑 full-context、滑动窗口、摘要、向量召回和混合模式测 token 消耗和关键信息保留率。表格如下策略历史 token 消耗请求延迟关键信息保留率成本全量历史超限不可用不可用不可用不可用滑动窗口(最近20轮)约 16000低40%低摘要压缩约 3000中70%中向量召回约 4000中高85%中高摘要窗口向量混合约 6000中90%中这里的“关键信息保留率”不是官方指标是我在一个固定测试集里数出来的提前埋伏 20 个必须记住的事实跑完 50 轮对话后再询问这 20 个事实的正确率。结果很明显混合模式效果最好但它也不是免费的午餐需要维护摘要和向量索引两套基础设施。所以在项目初期我强烈建议先上滑动窗口把整体链路打通后再逐步加摘要和向量。不要一上来就搞最复杂的混合模式否则你会在排查问题时同时面对“摘要失真、向量召回不准、截断策略互相干扰”三个难题根本不知道 bug 出在哪一层。5. 常见问题与排查技巧实录5.1 上下文截断导致记忆错乱有段时间我发现模型偶尔会忽然改变语气从客服变成“全能助手”排查了半天才发现是截断逻辑把 system prompt 给删了。因为我最初用的是简单 List 切片只保留history[-N:]而 system prompt 也在 list 里当历史超长时它会被整体挤出去。解决方法是把 system prompt 和对话历史彻底分开存储每次构建上下文时重新拼装。你在任何模式里都不要把系统指令放进可变的历史队列。这是一个非常基础但必须强制的要求。另一个容易漏掉的是工具定义。如果你做了 function calling工具描述也是上下文的一部分它同样要单独保护不能用“最近 N 条”的逻辑去淘汰。否则模型突然失效不会报错但会不停地生成无效工具调用。5.2 摘要失真与“滚雪球”问题摘要失真的本质是信息在压缩过程中被有损编码类似 JPEG 压缩图片压缩完回不到原始精度。一旦第一次摘要漏掉了“用户偏好安静”下一次摘要看到的是“用户偏好”再下一次可能就变成“用户热爱音乐”错误像滚雪球一样被放大。我的应对方案有两层第一层对硬信息使用结构化字段不用自然语言摘要承载。第二层设置“记忆检查点”。每累计 20 轮对话或者摘要长度超过 1000 token就把原始全量历史重新喂给摘要模型生成一个新的基准摘要。这个重建动作是有成本的但能有效打断错误传播。你可以把这两层理解成“记录正本”和“定期对账”。正本永远保留在本地摘要只是副本副本有问题就用正本重造。所以前面我说原始历史不要清空就是为这个检查点服务的。5.3 多轮调用中的 session 管理最后一个常见问题也是很多人上线后才发现的context-mode 的内存数据必须按 session 隔离。假如你把所有用户的对话都塞进同一个 ContextManagerA 用户说“我要退款”B 用户接着问“我的订单在哪”模型会把两件事混在一起后果非常严重。正确做法是给每个会话创建一个独立的 ContextManager 实例并用 session_id 做字典索引。在服务端可以这样组织sessions {} def get_context_manager(session_id: str): if session_id not in sessions: sessions[session_id] ContextManager(modehybrid, ...) return sessions[session_id]当然session 对象存多了也会占内存你可以加一个 LRU 淘汰策略把超过 1 小时没有活跃的会话状态写到 Redis 或本地磁盘再清空内存。并发环境还要注意一个问题同一个 session 的多个请求可能同时触发摘要刷新导致重复写入。最简单的方法是给 ContextManager 加一个线程锁或者把 add_message 和 build_context 做成单线程串行处理。我在生产里见过因为并发修改 summary 导致上下文错乱的案例排查起来极其痛苦建议一开始就把锁加上。5.4 排查工具记录每次请求的 token 构成最后分享一个小技巧也是我强烈建议收入你工具箱的每次请求结束把system_prompt_tokens、history_tokens、recalled_tokens、output_tokens、summary_refresh_count全部打到日志里。为什么要这么做因为 context-mode 这类模块是典型的“黑盒状态机”状态在模块内部你不记录日志出了问题就只能靠猜。日志里一旦发现某次请求 history_tokens 异常高就可以立刻定位到是不是摘要压缩没触发发现 summary_refresh_count 猛增就可以知道是不是摘要重建条件太激进。我之前在排查一个成本飙升事故时就是靠日志发现向量召回在某个 session 里反复触发把同一条历史消息嵌了十几次进上下文。如果没有日志单看最终请求体完全看不出来问题。这个习惯养成之后你调参也会快很多因为你不再靠感觉而是靠数据。context-mode 这个模块我从最初的几十行截断代码一路迭代到现在的混合策略版本最大的感受是上下文管理没有银弹只有清晰的层级划分和明确的降级路径。你先保证最简单模式能跑通再逐步叠加上下文策略比一开始就追求“全知全能的记忆系统”要靠谱得多。希望这篇记录能让你少走我走过的那些弯路。