大模型多轮对话上下文管理：context-mode实战指南

开头

做 AI 应用最怕什么？不是模型不够聪明，是模型“记性太差”。我之前带着团队做一个知识库问答助手，上线第一天就被用户吐槽：“我刚问的内容，换个说法再问一遍，它居然不记得了。”排查来排查去，问题就出在没有一套上下文管理机制。后来我们把 context-mode 这套方案完整落地到系统里，多轮对话的连续性才真正稳下来。

这篇文章就是围绕 context-mode 这个主题，把我们在实际项目里的设计思路、实现路径、工程落地和踩坑记录完整梳理一遍。不管你是正在做智能客服、Copilot 工具、AI 搜索还是 Agent 工作流，只要你的产品需要跟大模型做多轮交互，这套东西就值得仔细看一遍。文章不会只讲概念，会直接给出可以复用的模块设计和代码片段，你看完就能在自己项目里抄作业。

1. 先搞明白 context-mode 到底在解决什么问题

1.1 为什么多轮对话的“上下文”这么难管

大模型的 context window 是有限的，哪怕像目前主流模型一样能支持几十万 token 的上下文，也不能无限塞。而且塞得越多，推理越慢、成本越高，模型还容易“注意力漂移”——也就是被一堆无关紧要的历史信息干扰，抓不住用户当前最重要的意图。

更麻烦的是，用户说话是有“信息密度”的。一次 20 轮的对话里，真正对后续回答有长期影响的内容可能只占 10%：用户确认过的偏好、明确拒绝过的方案、某个专有名词的定义、过程中的关键决定。剩下的 90% 都是寒暄、重复确认、废话和中间尝试。如果把这些全部塞给模型，它分不清哪些是“需要长期记住的事实”，哪些只是“本轮临时聊天的背景音”，回答自然会飘。

这里可以用一个生活化的类比。你让一个实习生去旁听一个 1 小时的会议，然后让他写会议纪要。如果他只是把录音全文丢给 AI 转写，最后出来的东西一定没法看。一个合格的实习生会记下结论、待办、责任人，忽略中间的争论和废话。context-mode 干的活，本质上就是给大模型当这个“会做会议纪要的实习生”。

1.2 context-mode 的产品定位和适用场景

从产品视角看，context-mode 不只是一个开关，而是一整套“上下文处理策略”的组合：它决定了哪些历史信息需要保留、以什么形式保留、在什么时机注入到当前请求里、以及超出预算时如何降级。

我们当时做的是企业知识库问答助手，典型对话长这样：用户先问一个制度问题，然后接着问“如果员工请了病假，这个制度还适用吗”，再过几轮又问“综合刚才说的两种情况，能不能给我一个判断流程”。你会发现，第三轮的问题天然依赖前两轮的讨论结论。没有上下文管理，模型根本接不上这种对话。

适合接入 context-mode 的场景，我大致归纳成四类：

• 多轮客服机器人：用户在同一个 session 里反复修改需求，系统要记住每次修改的内容。
• AI Copilot / 编程助手：用户在对话里定义了代码风格、指定了某个函数名，后续所有生成都要遵守。
• AI 搜索与问答：需要结合历史问答意图，理解当前问题的真实指向。
• Agent 工作流：模型要基于之前多步工具调用的结果继续推理，上下文一旦断裂，整个流程就废了。

只要你的产品落在这些场景里，context-mode 就是刚需，不是可选项。

2. 三种主流的 context-mode 实现路径

2.1 显式持久模式：把关键信息“钉”在上下文里

显式持久模式的核心思路是：把对话里出现的“关键信息”抽出来，用结构化的形式独立存储，每次请求构造 prompt 时，直接把这段结构化信息注入进去，不依赖对话历史的完整性。

那什么是“关键信息”？在我们的知识库助手里，定义了三类：用户意图（用户到底想干什么）、实体（部门、员工、日期、制度编号等）、约束条件（用户明确说过的限制，比如“只看销售部”“不考虑临时工”）。抽取动作可以在每一轮对话结束时触发，也可以由意图识别模块在特定节点触发。

举个例子，用户说了这么一段话：

我们销售部的员工下个月请了三天病假，按照公司制度，绩效奖金怎么算？对了，不要考虑那些已经离职的人。

抽取出来的结构化信息就是：

{ "intent": "query_leave_and_bonus", "entities": { "department": "销售部", "leave_type": "病假", "leave_duration": "3天", "time": "下个月" }, "constraints": ["排除已离职员工"] }

每次构造 prompt 时，这段 JSON 放在对话历史之前，模型就知道这些信息是“已经确认过的事实”，不需要再从历史里重新推断。优点是稳定性极高，只要 schema 设计得好，关键信息基本不会丢。缺点是需要额外的抽取逻辑和字段定义，业务复杂时 schema 会变得很胖。这种模式最适合任务明确、流程固定的场景，比如请假审批、订单查询、表单填写类对话。

2.2 窗口滑动模式：让模型始终看到“最近发生的事”

窗口滑动模式是最简单粗暴的做法：只保留最近 N 轮对话，超出窗口的部分直接丢弃。很多初版产品都是这么干的，因为一行代码就能实现。

但它的缺陷非常明显。第一，窗口长度不好定：设短了容易被用户投诉“失忆”，设长了 token 成本扛不住。第二，信息丢失没有区分度：用户第 3 轮说的关键需求，如果对话到第 15 轮才被用到，不好意思，已经滑出窗口了。我们一开始踩过这个坑，窗口设为 10 轮，结果用户在第 11 轮问“我刚才说的那个方案行不行”，模型完全不知所云。

后来我们的改进是：按 token 数滑动，而不是按轮数滑动。因为一轮对话可能是 5 个字，也可能是 500 个字。用轮数切分误差太大，用 token 数才可控。实现上也简单，维护一个对话消息队列，每次新消息进来就累加 token，超过阈值就从头部弹出。为了让“最近的对话”始终贴近用户当前输入，我们还会在最终组装时调整顺序：最近的对话永远放在 prompt 里离当前问题最近的位置。

单纯用窗口滑动模式，适合那些“本轮对话基本独立，历史参考价值有限”的场景，比如简单的天气查询、翻译工具。但做复杂业务，它只能当最底层的基础设施，不能当作完整的 context-mode 方案。

2.3 关键摘要模式：压缩历史，保留记忆精华

摘要模式是对窗口滑动模式的一种升级：与其把历史粗暴丢进回收站，不如把历史“压成一句话”，塞进上下文里。

具体做法是：对话累积到一定轮数或 token 阈值时，触发一次摘要。摘要的内容要回答几个固定问题：用户确认了什么需求、拒绝了什么方案、留下了哪些偏好、待办事项有哪些。然后把摘要作为一整个系统消息，放在每次请求的 prompt 里。模型既不需要读完整历史，也能通过摘要了解前因后果。

我们在项目里用的是混合触发策略：每满 8 轮触发一次固定摘要，同时一旦发现单轮 token 超过预算的 20%，立刻触发一次紧急摘要。摘要不是每次都完整重写，而是增量更新——新摘要会引用旧摘要的内容，再补充最近几轮的新信息。这样才能避免摘要越做越长。

必须强调一点：这三种模式不是互斥的，真正靠谱的 context-mode 往往是它们的组合。窗口滑动负责兜底近几轮、摘要负责压缩中长历史、显式持久负责锁定最关键的实体和约束。我们最终的线上方案就是“显式持久 + 窗口滑动 + 增量摘要”三合一，具体怎么组合，下面会说。

2.4 实际选型时我的建议

别一上来就追求最复杂的方案，先回答三个问题：第一，用户的后续问题依赖前文信息的比例有多高？如果高，窗口滑动模式必须加摘要或显式持久。第二，对话里有没有强结构化的关键信息？如果有，优先做显式持久，因为它最稳。第三，上下文预算紧不紧张？紧张就优先上摘要，避免成本失控。

我们知识库助手的组合方案是这样的：实体和约束走显式持久，最近 6 轮对话全量保留，超过 6 轮的部分让摘要模块接管。相当于把信息分成三层：第一层是“钉子”，永远在；第二层是“临时桌布”，近几轮随便铺；第三层是“仓库”，旧东西打包好，要用的时候再拆。

3. 工程化落地：把 context-mode 真正跑起来

3.1 核心模块与数据结构设计

理论讲再多，不落地都是空谈。我直接给你看我们项目里可复用的最小实现。用 Python 写一个 ContextManager，它管三件事：维护各类上下文数据、控制 token 预算、生成最终 prompt。

class ContextManager: def __init__(self, total_budget: int = 8000): self.total_budget = total_budget # 第一层：显式持久化信息，不走 token 滑动，常驻上下文 self.sticky_info = { "entities": {}, "constraints": [], "user_preferences": {} } # 第二层：最近对话缓存，按 token 计算，超出就淘汰 self.recent_messages = [] self.recent_token = 0 self.recent_limit = 3000 # 第三层：历史摘要，由摘要模块生成和维护 self.history_summary = "" self.summary_token = 0 self.summary_limit = 1500 # 预算分配时，剩余部分留给系统指令和当前用户输入 self.system_prompt_token = 2000 def add_message(self, role: str, content: str): token_count = estimate_tokens(content) self.recent_messages.append({"role": role, "content": content}) self.recent_token += token_count self._trim_recent() def _trim_recent(self): # 按 token 从旧到新淘汰，始终保持最近的消息在队列尾部 while self.recent_token > self.recent_limit and len(self.recent_messages) > 1: removed = self.recent_messages.pop(0) self.recent_token -= estimate_tokens(removed["content"])

这个结构对应三种模式：sticky_info 对应显式持久，recent_messages 对应窗口滑动，history_summary 对应关键摘要。分开管理，互不干扰，后续优化某个模块不会拖累其他部分。

3.2 上下文注入顺序与预算分配

拿到了三部分上下文，接下来最关键的步骤就是组装 prompt。组装顺序是有讲究的，不能随便排。我们最终固定的顺序如下：

1. 系统指令（System Prompt）：定义角色、能力边界、回答规范。
2. 显式持久信息：用户实体、约束、偏好，让模型明确知道哪些是既定事实。
3. 历史摘要：如果存在，说明之前的对话结论。
4. 最近对话（仅保留近几轮）。
5. 用户当前的输入。

这里有两个原则。第一，系统指令和显式信息必须放在前面，因为它们是需要被模型“优先服从”的内容，越靠前注意力权重越高。第二，最近对话必须紧贴当前输入，保证模型在回答时能看到完整的“前因”。

预算分配上，我建议按比例切分而不是按绝对值切分，因为不同模型的总窗口不一样。用一个 8k 总预算的例子：

budget_plan = { "system_prompt": 2000, "sticky_info": 500, "history_summary": 1500, "recent_messages": 3000, "current_input_reserved": 1000, } def build_prompt(self, user_input: str): sections = [ f"System: {self.system_prompt}", f"StickyInfo: {json.dumps(self.sticky_info, ensure_ascii=False)}", f"HistorySummary: {self.history_summary}", *[f"{m['role']}: {m['content']}" for m in self.recent_messages], f"User: {user_input}", ] prompt = "\n\n".join(sections) # 最后一个动作：超限检查 if estimate_tokens(prompt) > self.total_budget: prompt = self._truncate_to_budget(prompt) return prompt

如果你用 OpenAI SDK 这类工具，消息数组的顺序也是同样的逻辑。关键点在于：不是把所有内容堆给模型，而是分层给。模型跟人一样，一次性读太多信息会疲劳，但给它一个清晰的层次结构，它的表现会稳定得多。

3.3 更新策略与触发时机

上下文管理最容易被忽略的，是“什么时候更新”这个问题。一开始我们做的是每次请求都全量重算上下文，结果 token 消耗巨大，而且频繁刷新摘要反而导致信息波动。后来改成事件触发式更新，效果立刻改善。

触发时机我们定了四类：

• 用户完成了关键操作（比如提交了一个表单、确认了一个方案），立刻更新 sticky_info。
• 消息轮数达到阈值（我们设为 8 轮），触发增量摘要。
• 单轮消息 token 异常大（超过预算 20%），触发紧急摘要并压缩 recent_messages。
• 新用户输入进来时，只做读取和组装，不主动改任何状态。

def process_user_input(self, user_input: str): self.add_message("user", user_input) if self._should_extract_sticky_info(user_input): extracted = extract_entities_and_constraints(user_input) self._merge_into_sticky_info(extracted) if self._should_trigger_summary(): self._update_summary() return self.build_prompt(user_input)

这里面最核心的经验是：更新的时机比用什么算法更重要。你摘要算法再强，触发频率不对，效果也好不了。触发太频繁，摘要一直在变，模型无法建立稳定的“记忆”；触发太少，摘要跟不上新信息，等于白做。

3.4 可观测性：一定得能“回放”上下文

这一点我放到工程化里讲，是因为吃过亏。之前线上 prompt 偶尔“抽风”，输出质量突然下滑，但我们不知道模型到底看到了什么。没有上下文快照，排查无从下手。

后来我们给 ContextManager 加了快照日志，每次请求都记录三样东西：组装后的完整 prompt、各部分的 token 占比、以及 sticky_info 的变化历史。日志量级不大，但这些数据在排查问题时价值极高。

def log_snapshot(self, prompt: str): log_entry = { "timestamp": time.time(), "prompt": prompt, "token_breakdown": { "system": estimate_tokens(self.system_prompt), "sticky": estimate_tokens(json.dumps(self.sticky_info)), "summary": estimate_tokens(self.history_summary), "recent": self.recent_token, }, "sticky_version": self.sticky_version, } logger.info(json.dumps(log_entry, ensure_ascii=False))

建议你把上下文快照和业务日志、模型响应日志关联到同一个 trace_id。这样用户反馈一个问题，你直接按 trace_id 拉出当时的完整上下文，立刻能判断是模型的问题、上下文管理的问题、还是用户本身输入就有歧义。

4. 常见问题与排查技巧实录

4.1 上下文漂移：模型回答着回答着就跑题了

现象：同一个 session 内，前几轮回答很精准，越到后面越偏，甚至开始自说自话，跟用户问的完全不搭边。

排查思路：先看上下文快照，重点检查 sticky_info 和 history_summary 是否被“污染”。我们遇到过这样的情况：摘要模块把用户的一句玩笑话“我可以接受任何方案”当成了真实偏好写进了 sticky_info，结果后续每一轮模型都在迎合这个并不存在的偏好。定位方式很简单，打开快照日志，看模型突然跑题的那一轮前后，sticky_info 或摘要里多了什么奇怪内容。

解决办法：给摘要和实体抽取都加置信度阈值。抽取出来的实体或约束，如果置信度低于 0.7，宁可不进 sticky_info。另外，每过一段时间（比如每 20 轮）把摘要和 sticky_info 发给模型做一次“一致性校验”，让它判断这些信息是否与最近对话矛盾，有矛盾就触发更新。

4.2 token 超限和成本失控

现象：某个用户对话特别长，请求报 400 错误，或者月底看账单发现成本翻倍。

排查思路：token 超限多半是摘要模块写得太长，或者 sticky_info 里的实体被后续过程不断追加，越攒越多。成本飙高通常是因为某些请求没有走 context-mode 的预算控制，完整历史一股脑全塞进去了。

解决办法：给 total_budget 设硬上限，组装完 prompt 之后必须做一次校验，超了就按优先级丢弃——先丢 history_summary 的冗余内容，再丢 recent_messages 里最早的消息，最后显式降级：模型给出简短回答，不做深度分析。

注意：token 估算一定要用实际模型的 tokenizer，不能简单按字数算。中文一个字可能对应 1-2 个 token，英文一个词也可能拆成多个 token。估算不准，前面所有的预算分配都是空中楼阁。

4.3 关键信息丢失：用户说“我刚刚说的那个”却接不上

现象：用户明明在前几轮提到了一个具体方案，后面用指代词提问，模型完全不知道指的是什么。

排查思路：这类问题几乎都是显式持久层没做好的表现。用户说的是“那个方案”，但方案名称、方案内容都没有被抽取成结构化实体，只存在于 recent_messages 里，一旦被滑出窗口就丢了。

解决办法：强化实体抽取模块，把用户的关键指代词与历史实体做“指代消解”。实现上可以简单粗暴：用户输入里出现“那个”“这个”“刚才的”等指代词时，自动从 sticky_info 里最近更新的三个实体中做匹配，把匹配结果拼接到用户输入后面。比如：

User: 那个方案可以落地吗？ AugmentedInput: 用户指代的“那个方案”是【降低销售提成至5%的方案】，针对该方案提问：那个方案可以落地吗？

这个技巧非常有效，而且实现成本低。

4.4 结果不稳定：同样的问题前后答案不一致

现象：用户把同样的问题换了种说法，模型给出的答案关键数字或结论明显冲突。

排查思路：这里要区分是上下文没生效，还是模型本身的采样随机性导致的。先在 context 快照里确认两次请求的 prompt 是否一致。如果不一致，问题大概率出在上下文组装没做好；如果完全一致，则是模型温度参数和采样策略的问题。

解决办法：把 temperature 调低，同时引入约定俗成的“回答一致性自检”——在系统指令里加一句“回答前先对比当前信息和历史结论，若存在矛盾，请向用户说明并询问确认”。模型本身有对比能力，只要你给它对比的依据（也就是完整的摘要和 sticky_info），效果立竿见影。

4.5 常见问题速查表

把上面这些经验整理成一张速查表，你在排查时直接对着查。

另外补一个通用技巧：任何 context-mode 相关 bug，先复现再修。复现不了的问题，因为有快照日志，也能直接定位到当时的输入和输出。一定要把“可回放”当作硬性要求，不要省这一步。

5. 进阶扩展：面向 Agent 场景的 context-mode 演进

5.1 从单轮对话到多步工具调用

如果你的产品不是简单问答，而是 Agent 自动化，context-mode 要管理的内容就更多了：工具调用历史、中间返回结果、子任务状态、多 Agent 之间传递的数据。上下文一旦断裂，整个任务链条会完全瘫痪。

我的建议是引入“任务栈”机制：每次 Agent 要执行一个子任务，就把当前任务上下文入栈，包括目标、输入参数、依赖的历史结果。子任务执行完毕，把结果和状态合并回栈顶。一旦某个环节出错，可以从栈的某个位置回滚，而不是让整个上下文作废。这种设计其实跟多人协作很像——每个人只负责自己的部分，但必须清楚地知道上游给了什么、下游要什么。

5.2 用向量召回补充长期记忆

摘要模式住的时间长了也会遗忘细节。比如用户在第 100 轮提了一句“我偏好用数据透视表呈现”，第 200 轮想引用这个偏好，光靠摘要大概率拉不回来。

这种情况下，可以考虑给关键历史片段做向量化存储。每当摘要模块生成或更新时，同步把摘要和历史消息切成小块，存进向量数据库。当前用户输入进来时，先用 embedding 检索最相关的历史片段，把命中的片段临时加到 prompt 的上下文里。

我们实测下来，这个方案在长会话场景里能把相关信息的召回率提升不少，适合对上下文深度有苛刻要求的场景。但代价是多了向量检索这一跳，响应时延会增加几十毫秒，需要你根据业务场景做取舍。

5.3 上下文分层与生命周期管理

最后分享一个项目架构层面的建议：把上下文分成 L0、L1、L2 三层。

• L0：常驻层。系统指令、角色设定、全局不可变约束，基本不随对话变化。
• L1：会话层。sticky_info、摘要、最近对话，跟着当前 session 走，session 结束就释放。
• L2：归档层。历史会话摘要、用户长期偏好，存储在外围，需要时按需召回。

生命周期上，L0 永远存在，L1 随会话创建和销毁，L2 跨会话存在。这套分层不只让上下文管理更清晰，也让之前的三种模式各有归属：显式持久对应 L1、窗口滑动对应 L1 里的临时区、摘要和向量召回对应 L1 到 L2 的桥梁。架构一旦理顺，后面加功能、做扩展都轻松很多。

说句大实话，context-mode 这个方向没有银弹。不同的业务形态、不同模型能力、不同成本约束，都需要不同的组合策略。但底层逻辑是共通的：你要么让模型记住该记住的，要么帮它忘掉该忘掉的，两头都不做，光靠堆窗口长度，早晚会被用户教做人。我现在每做一个新项目，都会默认把“分层 + 快照 + 预算控制”这三个基础设施先搭好，再谈上层业务，省去了后面无数的返工和扯皮。你们要是有更好的方案，欢迎一起交流。