总结税：当压缩消耗的 Token 超过了它节省的量

一个长时间运行的 Agent 每 12 轮就会达到其压缩阈值。每一次压缩的成本都相当于一次规模等同于当前运行窗口的 LLM 调用——首先是 8K tokens，然后是 14K，接着是 22K——因为被总结的内容跨度随着每次触发而增长。到了第 60 轮，用户在观察 Agent 自我总结上花费的 token，已经超过了在实际推理上花费的 token。成本仪表盘将“用户推理成本”显示为一个单一数字，完全没有意识到其中一半是为用户永远不会再看的上下文压缩而付费的。

这就是“总结税”：一类随着对话长度增加而增长的开销，在用户回合之间悄然触发，并作为一个单一项目出现，将用户付费的工作与系统为自我管理而进行的内务处理混为一谈。这是现代 Agent 架构中最接近“垃圾回收停顿时间（garbage-collection pause time）”的东西——而大多数团队在生产环境中运行时都关闭了 -verbose:gc。

问题的本质是机械性的，而非罕见现象。生产环境中的 Agent 会积累状态。状态超过了预算。系统进行压缩。每一次压缩本身都是一次模型调用，其计费费率与面向用户的工作相同，且单位成本以每轮仪表盘无法察觉的方式复利增长。一旦你知道去寻找它，数据会令你震惊；一旦你测量过一次，你就会不再相信任何没有将其拆分出来的成本报告。

总结税如何复利增长

朴素压缩被实现为“每当超过阈值时，就总结截止点之前的所有内容”。这种策略的问题在于它是几何级增长的。由于每次触发时需要总结的跨度都在增加，总结成本和延迟随对话长度线性增加，而整个会话中的 累积 总结支出则像三角级数一样增长。

一些团队已经发布了这种复利增长背后的数学模型。在长 Agent 会话中，成本增长大致遵循 n(n+1)/2（其中 n 是扩展上下文的轮数），而不是随轮数线性增长；一旦考虑到累积效应，那些独立建模每轮成本的团队会发现其系统定价低估了 3 到 5 倍。平均上下文长度增加 50% 会直接导致用户可见调用的推理成本增加 50%——并且在下次触发阈值时，还会导致更大的总结跨度。

几何增长的部分破坏了直觉。第一感官的心理模型会说“压缩只是偶尔增加一次额外的 LLM 调用”。而经过测量的模型则会说“压缩是一次额外的、规模等同于运行历史记录的 LLM 调用，其触发频率与上下文填充率成正比，并在整个会话中持续增长”。在 30 轮的会话中，这两个模型的结果会相差一个数量级。

总结之总结的漂移

层级式总结（Hierarchical summarization）是显而易见的应对方案：与其每次都重新总结原始对话，不如总结“之前的总结 + 新的回合”。它限制了单次压缩的成本。但它也会在每次迭代中流失保真度，而且这种流失是不对称的。

每一次压缩都会丢掉细节。在第 3 次压缩中丢失的一个微小事实，在第 7 次压缩时是无法恢复的；模型此时是在总结一个已经丢失了该事实的总结。长时间运行的会话会产生一条特征衰减曲线，早期事实变得越来越抽象，直到消失，Agent 的行为也不再符合用户两小时前所说的内容。公开的迹象非常熟悉：“如果一个错误的事实进入了总结，它会毒化未来的行为”；“在极长对话中，总结可能会偏离原始意图或丢失重要的基础上下文”。拥有约百万 token 窗口的模型仍然无法单次总结最长的会话，因此多阶段分块压缩会将延迟和漂移叠加在一起。

你最终得到的是一个虽然便宜但会慢慢撒谎的记忆系统。便宜的部分是真实的——每轮压缩的成本保持在有限范围内。而撒谎的部分则表现为“Agent 忘记了我告诉它的内容”这类工单率的缓慢上升，被 Prompt 团队归类为模型质量问题并塞进 Prompt 调优队列，然后石沉大海，因为 Prompt 其实并不是真正的 Bug 所在。

大多数团队未记录的每会话账本

大多数生产环境 Agent 栈的成本仪表盘只有一列用于“推理”。那一列是核心谎言。一个有用的账本至少应该拆分为三行：

• 主推理（Primary inference）：用于产生用户可见响应或推进 Agent 步骤的调用所消耗的 token。
• 压缩开销（Compaction overhead）：用于总结、总结之总结、结构化记忆提取或任何其他“管理上下文窗口”调用所消耗的 token。
• 工具载荷累积（Tool payload accumulation）：在随后的每一轮中重新发送累积工具输出历史所消耗的 token，这在单次调用层面是不可见的，但在每个会话层面非常明显。

一旦你完成了这种拆分，就会得出两个衍生指标，它们比任何每 token 价格都更具诊断意义。第一个是 总结-Token 比例（summary-token ratio）——即每个会话中，压缩 token 除以主推理 token 的值。长尾时长的会话中，这个比例几乎总是错误的：超过 1 并不罕见。第二个是 每轮压缩的边际效用（marginal utility per pass）——对于每一次总结，下游回合是否真的因为总结而减少了上下文加载，还是说 Agent 反正又通过工具调用重新获取了被总结的内容？不减少后续上下文的压缩纯粹是浪费。

加载中…