Token Budget、Compaction、Prompt Cache 与 History

上下文窗口再大，也不适合把全部历史永久往里加。先给回答和工具结果留空间，再决定哪些旧内容保留、压缩或按需取回。缓存解决重复输入的成本问题，压缩解决材料长度问题，两者不是同一件事。

版本与资料依据

  • last_verified: 2026-08-24
  • version_scope: provider-neutral; cache APIs vary by provider
  • source_type: official-provider-docs + engineering synthesis
  • stability: version-sensitive

先分清：保存过，不等于这一轮看得到

想象你让 Agent 调查一个错误。它读过十个日志文件，但下一次模型请求只带了其中三段。那么模型这一轮能利用的是这三段，以及请求里的其他消息；磁盘上还存着七个文件，并不代表模型正在阅读它们。History 是保存的过程，Context 是本轮实际送入的材料。

Compaction 可以理解成“给接班的人写交接记录”。一份有用的记录要说清任务还差什么、哪些假设被推翻、修改了哪些文件，以及原始证据在哪里。只写“已经检查了项目”几乎没有帮助。摘要生成后最好抽查几项事实，还要保留原记录供重新读取。

Prompt Cache 则像复用此前处理过的请求前缀。它减少重复输入的处理成本，但不替你保存业务事实，也不保证回答正确。具体缓存命中条件、保存时间和费用由服务商规定。先保持稳定内容的顺序，再测量命中率；不要为了命中缓存而保留已经失效的工具权限。

1. Budget 是分配策略

先为输出和工具回填留出硬余量，再给约束、当前任务、代码证据、history、retrieval 分配预算。window - prompt = output 只是容量关系；真正的预算还需考虑并行分支、重试和成本上限。

Text
input_budget = context_window
             - reserved_output
             - tool_protocol_margin
             - provider_safety_margin

2. Compaction 不是简单截断

压缩顺序通常是：去重 → 移除可重取的大输出 → 保留决定/错误/未完成项 → 对旧 history 结构化摘要 → 必要时窗口化。摘要必须记录生成版本与源范围，并保存原始 trace 的可追溯引用。

需要保留：当前目标、不可变约束、已做决定及理由、未解决错误、artifact 地址、permission、stop/cancel 状态。可以外置：重复工具输出、已成功且可重建的中间日志、与当前分支无关的旧讨论。

3. Prompt Cache 布局

Cache 是 provider/runtime 能力而不是通用语义保证。常见策略：稳定 instruction/tool catalog 前缀保持字节级稳定；易变时间戳、当前 observation 放后；tool 列表使用确定排序；记录 cache key 与命中指标。不要为追求命中把过期权限或旧 schema 固定下来。

4. History 管理

历史记录按时间保存用户消息、模型响应、工具结果和控制事件。工具调用与结果要用 ID 对应，重试要记录次数，压缩后也要知道摘要来自哪一段原文。这样才能复盘和恢复。保存了这些事件，并不意味着已经完成了长期记忆的筛选与管理。

5. Failure modes

  • lost constraint：摘要丢失验收条件；
  • stale cache：权限或工具 schema 已变化；
  • orphan tool result：压缩后 result 找不到 call；
  • summary drift：多轮摘要逐渐改写事实；
  • budget cliff：估算与 provider tokenizer 差异导致请求拒绝。

用同一组任务比较成功率、输入 token、缓存命中、压缩次数和重要事实丢失情况。抽取摘要中的说法回查原始记录，确认压缩没有改变事实；省下 token 但丢掉关键条件，并不是有效优化。

压缩更勤，不一定更便宜

Hermes 当前的 micro-compaction 提供了一个很直观的反例：它把压缩工作分散到每轮结束后，逐步吸收旧回合；这个选项默认关闭。文档明确提醒，压缩需要额外模型调用，而且改写历史可能破坏提示缓存的稳定前缀。

所以不要只比较“压缩后剩多少 token”。准备同一段长对话，分别记录总输入、缓存命中、压缩调用、端到端等待时间，以及一个早期约束在最后是否仍被遵守。只有这些结果放在一起，才能判断更频繁的压缩是否适合你的任务。

这是一个具体实现的取舍，不是所有 Agent 都该采用的规则。尤其要保留原始记录的位置：摘要说“已经保存工单”，恢复时仍应查询实际工单，不能把摘要当作写入成功凭证。

本节的核验依据

2026-10-25 查阅。下面的链接支持本节的机制说明；练习场景和选型建议是本教程的教学设计。