多轮对话如何控制上下文膨胀

dev.to · AI#上下文管理#对话记忆#Gemini

Editor brief · 编辑速览

文章围绕 Gemini API 构建模块化 Python 框架，以三层混合记忆机制应对历史消息不断累积的问题。已展示的设计包括固定系统指令层，目标是兼顾对话记忆、Token 成本与响应延迟。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

多轮 AI 对话越聊越贵，问题往往出在应用把所有历史消息一遍遍发给模型。作者围绕 Google Gemini API 设计了一套 Python 记忆框架：固定系统指令，保留最近对话，把更早的内容压成摘要，让长会话的输入规模更可控。

这套方案值得看，因为它把「记住用户」拆成了不同层次，也补上了重试、配置校验和成本监控。不过，原文提供的是架构思路，没有性能对照，也没有证明摘要能完整保留上下文。

原文的出发点是：LLM API 无状态，每次请求都需要应用重新组织上下文。开发者最容易实现的方案，就是不断往消息数组里追加用户输入和模型回答，下次请求再整包发送。

问题会随会话长度累积。输入越来越长，首个 token 的等待时间可能增加；反复传输旧消息，会增加输入费用；大量无关历史还可能干扰当前指令。作者把最后一种情况称为上下文稀释（context dilution），也就是模型能看到很多内容，却更难抓住眼前真正相关的信息。

这里要区分两个成本口径：作者说成本随轮次线性增长，更适合理解为历史不断增长时，单次请求的输入成本变化。整个会话的累计费用，还要算上旧消息被重复发送的部分，不能直接套用同一个结论。

作者在 Valentius Kryptix 的 AI 工程工作中设计了这套框架，核心是让不同信息进入不同的存储层。

第一层是系统指令锚定（System Instruction Anchoring）。角色设定、输出限制和操作边界放在固定的顶层配置中，每轮持续提供，避免这些要求随着聊天推进被遗漏。它提供稳定的规则入口，但原文没有证明这样就能保证模型始终遵守规则。

第二层是 FIFO 滑动窗口（FIFO Sliding-Window Buffer）。只保留最近的 k 轮对话原文，超出窗口的旧对话依次移出。近期代码块、追问和逐步调试记录需要精确引用，保留原文比压缩成摘要更可靠。

第三层是异步滚动摘要（Asynchronous Rolling Summaries）。移出窗口的对话不会直接丢弃，而是压缩进一份持续更新的摘要，放在系统提示之后。用户的长期目标、之前作出的决定，由这一层承接。

近期细节保留原文，长期信息保留摘要，是这套设计最有用的分工。

作者认为这样可以让输入 token 总量保持平稳。不过，这需要窗口和摘要都受到限制。如果摘要不断追加，或者某轮贴入特别长的代码，仅限制 k 轮仍然无法固定输入规模。原文没有给出 k 的取值、摘要长度上限或触发压缩的具体阈值。

作者还提出三项配套措施，让客户端具备更接近生产使用的基础能力。

首先是带随机抖动的指数退避（Jittered Exponential Backoff）。遇到 HTTP 429 限流响应或 5xx 服务端错误时，自动重试，并逐步拉长等待间隔。随机抖动用于错开客户端的重试时间，减少大量请求同时再次冲击服务端的机会。

其次是独立的环境配置校验。模型参数、temperature、token 阈值和 API 凭证通过严格校验的环境配置管理，避免散落在硬编码脚本里。原文没有展示配置格式和校验实现。

最后是每轮 token 遥测（Per-Turn Token Telemetry），记录输入 token、生成开销和请求往返延迟。只有持续观察这些指标，才能知道记忆压缩是否真正控制了成本。

这里仍缺一块说明：滚动摘要本身也需要计算或模型调用。原文没有交代这部分开销是否计入遥测，也没有给出实际日志、延迟数据或费用对比。

我赞成按信息用途拆分记忆。相比完整重放历史，它减少重复输入；相比直接截断旧消息，它保留了一条延续长期目标和决策的路径。对于持续调试、反复修改代码的会话，这个取舍有清晰的理由。

但摘要是有损压缩。一次旧的排查结论如果遗漏了成立条件，后面就可能被当成始终有效的事实。异步更新还会带来时序问题：新请求到达时，最新摘要是否已经生成？原文没有说明。

这是一份有参考价值的架构经验，效果仍需团队自己的对照测试来确认。

作者没有提供实现代码、测试集或基准数据，不能据此断言它一定更快、更便宜，或者长会话不会丢失上下文。与检索式记忆相比，它也没有展示按需找回早期原文的能力；需要精确回溯时，仅靠摘要未必够用。