AI Agent 自动总结丢信息怎么办,哪些内容压不得
长会话自动压缩后报错栈、diff、ID 和数字全变模糊?把事实与叙事分开,压缩前落盘,用检索代替总结,附 Claude Code 压缩行为的官方说明。

长会话跑到一半自动压缩,回头问「刚才那个报错在哪一行」,模型给了个差不多的答案。ai agent 自动总结丢信息怎么办,可行的做法是提前把压不得的东西搬出对话。
总结在优化理解,不在保存事实
Towards AI 上那篇文章(第三方博客)的例子很值得复述:客服会话开头,客户给了 Customer ID、Order ID 和退款金额 249.50 美元。三十轮之后系统把前面的历史总结了一遍,再问退多少,回答变成「大约 250 美元」。没人改过数据,那五十美分是在总结那一步蒸发的。
原因在总结这个动作本身。你让模型「保留重点、去掉细节」,它没有依据判断 249.50 的小数位不属于细节。对读者来说这是个小数字,对退款接口来说它就是整笔交易。
更麻烦的是叠加。上下文再次涨满时,你压缩的已经是上一份摘要,摘要的摘要每轮再掉一点。故事线一直活着,事实一层层脱水。原文把这个现象叫 progressive summarization,并且指出更大的上下文窗口只是把问题推后,不解决状态管理。
四类内容压一次就废
按能不能重建来分,长会话里有四类内容压缩一次就基本报废,共同点是精确值本身就是全部信息量。
报错栈:文件路径、行号、调用顺序缺一个都没法重跑定位,压成「构建失败」等于没有。
diff:- if (a > b) 改成 + if (a >= b),摘要写「调整了比较逻辑」,下一轮谁都说不清动的是哪一边。
配置片段:ENABLE_TOOL_SEARCH=auto、端口号、超时毫秒数,模型复述时很容易给你一个看着像那么回事的值。
ID 与数字:commit sha、容器 ID、job 编号、金额,这类东西被四舍五入就是事故。
能压的部分同样明确:讨论过程、试错记录、已经被推翻的方案、模型自己的推理链。它们的价值落在结论上,压完不影响后续判断。这个分界和 Agent 的 token 都花在哪 是同一套账。
Claude Code 自动压缩到底做了什么
官方文档写得比很多人以为的具体:上下文接近上限时,Claude Code 先清掉较早的工具输出,还不够才总结对话。原文明确说你的请求和关键代码片段会被保留,而会话早期的详细指令可能丢失,所以持久规则应该写进 CLAUDE.md 而不依赖对话历史。
由此有两个可控点。一是带焦点的手动压缩,例如 /compact focus on the API changes;二是在 CLAUDE.md 里放一个 Compact instructions 小节,固定告诉它每次压缩必须保住什么,官方给的示例就是测试输出和代码改动。
还有一个成本细节容易被忽略:/compact 会读一遍它要总结的对话,因此在大上下文里压缩本身就是一次大请求。只想重新开始的话,/clear 不花钱。至于常驻部分各占多少,/context 一条命令就能看,具体读法在 Claude Code 上下文窗口管理 里有展开。
如果单个文件或工具输出大到每次总结完上下文立刻又满,Claude Code 会在尝试几次后停下报错,不会一直循环。这时该处理的是那个大输出,不是压缩策略。
该压什么,该原样留什么
那篇文章给的工程做法是把事实单独拎出来放进一个 Case Facts Block,压缩流程只碰对话历史,这个块原样贴回下一次请求。三条规则分别是:放在对话之前、不允许模型改写它、永远不参与总结。
第一条有依据。长上下文研究里的 lost in the middle 现象说的就是埋在超长提示中段的信息比放在开头或结尾更容易被忽略,所以生产系统把关键事实钉在最前面。
第二条最反直觉。摘要允许改写措辞,事实块不允许。会话里模型说了「大约 250 美元」,事实块里那一行仍然是 249.50;只有客户真的更正了金额,才轮到改它。
放到编码 agent 上,等价做法是把这类内容写进仓库文件而非对话:当前分支和 commit、正在复现的报错原文、已经跑通的命令、待验证的假设。文件躺在磁盘上,压缩碰不到它。
外置到文件,用检索代替压缩
官方成本文档里有个很有代表性的数字:与其让模型读一万行日志找错误,不如用一个 PreToolUse hook 先 grep ERROR,只把命中行交回去,上下文从几万 token 降到几百。外置加检索的完整思路就在这句话里。
落到日常操作有三件事可以马上做。长输出一律重定向到文件,比如 npm test > /tmp/test.log 2>&1,然后让 agent 按需 grep,别把整段吐进对话。压缩之前先落盘,把关键 ID、报错原文、跑通的命令写进一个临时 markdown,压完让它重读这一个文件就能恢复现场。高噪声操作交给 subagent,官方文档说 subagent 有自己独立的上下文,跑完只把摘要返回主会话,冗长输出留在它那边,这也是 subagent 省 token 的主要来源。
skill 也参与这件事,不过要知道它的边界。自动压缩之后 Claude Code 只把最近调用过的 skill 重新贴回来,每个保留前 5000 token,全部重贴的 skill 共享 25000 token 预算,调得多了早期那些会被整个丢掉。
什么时候该开新会话
有两个比感觉可靠的判据:同一份摘要已经被压过第二轮,或者你开始纠正模型对早期事实的复述。这两种情况下继续压只会亏得更多。会话之间是独立的,新会话从一个干净的上下文窗口开始。
换会话的成本可以压得很低,前提是现场落了盘。开新会话时只喂三样东西:那份事实文件、当前要做的一件事、一条明确的验证方式。这比让它在三层摘要里考古快得多。
顺手还能省掉一笔隐性开销。官方文档提到,会话开着几个小时后,一句简短提问也会按缓存价重读整段历史;而超过缓存生命周期的第一条消息会完全 miss 掉缓存,重新处理全部上下文。任务已经切换的时候,/clear 比继续压更划算。
参考资料
- The Summarization TRAP(Towards AI,第三方博客) — 249.50 变 250 的案例、叙事与事实的分类、Case Facts Block 三条规则
- Manage costs effectively(Claude Code 官方文档) — compact instructions、hook 过滤日志的 token 对比、subagent 隔离与缓存开销
- How Claude Code works(官方文档) — 上下文填满时先清工具输出再总结、早期指令可能丢失、压缩 thrashing 报错
- Extend Claude with skills(官方文档) — 压缩后 skill 重贴的 5000 与 25000 token 预算