三个看似合理但不完整的目标
继续同一个 coding agent 任务：“定位失败测试、修改实现、运行完整测试并交付结果”。系统规则、工具定义、项目指令、文件读取和测试输出都会进入上下文。团队准备优化时，常先提出三个目标。它们都可能有用，也都不足以单独成为预算。
第一个目标是让 prompt 最短。删除重复日志、无关工具结果和已经放弃的探索，确实能减少后续输入；但若为了短而删掉项目约束、根因证据或完整测试状态，Agent 可能重读文件、重跑测试，甚至提交错误修改。靠前的裁剪还会改变原有前缀，使幸存历史重新处理。最短请求不一定对应最少返工，也不一定对应最低 task cost。
第二个目标是让 cache hit 或 cache-read ratio 最高。稳定前缀能降低重复 prefill 的机会成本，但命中的是计算复用，不是内容价值。为了维持漂亮的读取比例而持续携带几十轮无用日志，可能让上下文越来越大、注意力越来越分散；一段垃圾即使读取便宜，仍是垃圾。相反，阶段结束后主动 compact 会建立冷的新前缀，却可能让后续工作更可靠。
第三个目标是始终选择最便宜的模型。简单修改用低价模型可能足够；复杂根因分析若因此多次失败、重试或接受人工复核，整个任务反而更贵。中途再切高质量模型，还可能失去原模型与 Provider 下的缓存复用，承担一次 cold start。这里也不能反向推出“贵模型总是更好”：模型选择要看成功率、返工和任务风险，而不是只看单 token 价或排行榜。
三个目标都不是坏目标。问题在于它们只优化了请求长度、复用比例或单位价格中的一个局部量，却没有回答 Agent 最终能否正确修改、完成测试并交付。Context Budgeting 的第一条原则因此是：局部指标只能作为约束或诊断信号，不能代替任务结果。
从单轮优化转向任务级目标
一份实用预算可以先写成下面的工程目标：
minimize total task cost and completion time
subject to task quality, evidence retention, and success-rate thresholds
这是一项带约束的多目标决策，不是可以跨团队通用的一条标量公式。成本和 completion time 之间可能冲突，质量、证据保留和成功率又是硬约束还是软约束，也取决于业务。团队需要为具体工作负载选择阈值、权重和 SLO：例如补丁必须通过哪些测试，关键命令与批准必须保留到何时，端到端 p95 最多多久，失败后允许多少次自动重试。
任务边界也必须统一。对 coding agent，任务从接收目标开始，到补丁、完整测试与交付证据齐备为止，而不是模型生成第一段回答就结束。total task cost 至少包含模型输入、缓存写入与读取、输出、工具搜索和摘要调用；若能折算，还应包含失败重试、额外测试、人工 review 与 rework。completion time 则要覆盖模型 TTFT、生成、工具运行、排队、等待批准、冷启动和重试，而不只是某一轮 API latency。
这会改变许多看似确定的判断。较长但稳定的前缀，可能用较低的后续 TTFT 换取更大常驻 footprint；一次压缩会增加摘要成本与冷写入，却减少后续多轮输入；高质量模型单轮更贵，却可能一次定位根因并减少 review。预算不是先规定“最多 50k token”，再要求所有任务服从，而是先定义可接受的交付，再为上下文结构、模型、TTL、工具与压缩分配可测量的空间。
五类必须同时观察的变量
第一类是 footprint 与 mutation：每轮 context length、稳定前缀长度、易变后缀长度，system / tools / project / history / tool results 各自占比，以及首个 mismatch、prefix epoch、prune / compact 事件。只有总 token，没有区块与变更位置，就无法解释为什么一段短修改触发长重写。
第二类是 reuse：Provider 原始 cache read / write / uncached usage、cache-read ratio、TTL 配置、idle gap、cache key 或 affinity、模型与路由。比例要和绝对 token 一起看：读取 90% 的 200k 上下文与读取 90% 的 20k 上下文，不是同一份负担；读取量为零也只能证明本轮没有观察到读取，不能在缺少诊断时臆测一定是 TTL、路由或内容变化。
第三类是 latency：TTFT、首 token 后生成时间、工具执行时间与端到端 completion time。TTFT 应至少按 context length、cache read、模型、区域和请求阶段分组，避免把排队或网络尖峰误判为 prefill。长工具调用还要记录两次模型请求之间的 idle gap，因为“测试仍在运行”不等于缓存仍被刷新。
第四类是 quality 与 rework：task success、局部测试和完整测试是否通过、关键证据是否仍可回答、错误工具选择、重读文件、重跑命令、人工 review 时间与 rework effort。压缩后 token 下降却让 Agent 忘记用户约束，或者便宜模型需要工程师重写补丁，都应记为预算失败。
第五类是 total economics：完整任务的 total cost、完成时间、失败恢复成本与资源机会成本。托管 API 保存原始账单字段，自托管系统则分别记录 GPU 时间、显存驻留和吞吐，除非团队已有可信折算方法，否则不要硬合成一个虚假精确的金额。
所有指标都要看分布，不只看平均值：至少记录中位数、p95 或业务关心的尾部，并按任务阶段和上下文规模分桶。冷请求与 warm 请求必须分开；混在一起的平均 TTFT 和平均成本会同时掩盖冷启动风险与稳定命中的收益。task success 也要按难度或任务类型分层，否则简单请求占比变化就可能伪装成优化。
四种工作负载，四种预算策略
- **短、无状态请求。**稳定前缀策略是只保留必要系统规则，通常没有足够重复前缀值得专门优化；只有跨大量请求共享同一长前缀时，才引入确定性版本。TTL 立场是默认不为单次请求增加长 TTL、prewarm 或 heartbeat 复杂度，先验证复用机会。工具装载只带当前任务必需的小集合，不为未来可能性常驻专家工具。compaction trigger 是发现检索材料或工具结果与问题无关时直接裁掉；一次性请求通常无需生成摘要。主要指标看端到端成本、p95 latency 和 task success，并单列异常重试。
- **交互式 coding session。**稳定前缀由 system、核心工具、项目规则构成，并固定模板、schema 与 epoch；文件读取、测试结果按事件追加。TTL 要覆盖真实的人类思考、代码执行和工具间隔，用 idle-gap 分布选择，而不是看到“长会话”就开最长；若认证渠道改变 TTL，也要进入配置记录。
read/write/bash等核心工具常驻，数据库、部署或设计工具延后搜索。compaction trigger 放在根因确认、补丁完成、局部或完整测试结束等 phase boundary，先把文件版本、命令和测试证据写入 ledger。主要指标是 cache read、TTFT、review / rework、文件重读与测试通过情况。 - **带慢工具的长时自主 Agent。**稳定前缀保存安全规则、任务契约和少量核心能力，长运行事实进入强证据账本，并用 checkpoint 连接耐久工件。TTL 策略必须计划构建、浏览、审批等 idle gap，明确预热或刷新是否达到 break-even；不满足时接受可预算的冷启动，而不是盲发 heartbeat。工具只选择性装载当前阶段能力，避免大而易变的 loadout 长期常驻。compaction trigger 既包括里程碑，也包括接近窗口上限之前；压缩前保存目标、批准、精确错误、artifact ID、hash 与下一步。主要指标是证据在压缩后的 survival、task success、retry、cold-start 次数及其成本与 TTFT。
- **高吞吐共享前缀工作负载。**稳定前缀必须确定性构建，并用 system / tool / policy version 建立清晰 epoch；在 Provider 支持时使用合适的 cache key 或 deployment affinity，同时遵守租户隔离。TTL 选择要比较写入摊销、并发、驱逐与下一次读取概率，新 epoch 的 prewarm 要防止 stampede。工具集应稳定；若工具长尾很大，则谨慎 deferred，并确认发现位置与回放语义不会让每个请求重写共享根。compaction 只作用于各自 session 的动态历史，不改写所有请求共享的静态 root。主要指标是 prefix reuse、cache read / write ratio、p95 TTFT、单任务 total cost 与冷启动并发峰值。
这四套策略不是按产品名称分组，而是按复用形态、任务时长和失败代价分组。同一个 coding 产品里的“一次解释报错”可能属于第一类，“修复并跑完整测试”属于第二类，夜间自动迁移仓库属于第三类；公共政策前缀上的批量审查则可能属于第四类。预算应跟随 workload，而不是让整个 Agent 平台共享一个 TTL、工具表和压缩阈值。
用实验而不是直觉决定压缩点
每次优化都先写一个具名假设，例如：“在完整测试通过后的阶段边界压缩，可以降低后续交付阶段的 total cost，且不降低测试证据保留率与 task success。” 基线是当前 append-only 策略；实验版本只改变一个 primary variable——compaction trigger，不能同时换模型、TTL 和工具表。
工作负载应来自固定任务样本，能控制时使用相同 seed、仓库版本、工具权限与负载条件；运行要重复，但不存在适用于所有实验的固定样本量。冷、warm 请求分开报告，或随机化执行顺序，避免所有基线都先跑、所有实验都恰好继承暖缓存。每次记录 quality / success、total cost、TTFT、context length、cache read / write 字段，以及人工 review 和 rework。压缩实验还应检查目标、约束、文件版本、精确错误、测试命令和未解风险能否从新状态恢复。
事前写清 decision rule、置信要求与回滚条件：例如成功率和证据保留不得低于既定阈值，在此约束下比较成本与 p95；若出现遗漏用户批准或完整测试状态的案例，立即回滚该摘要版本。结论必须注明模型、Provider、任务样本、时间和配置，避免把一次实验变成永久常数。
《Don’t Break the Cache》可以作为长时程 Agent 中缓存策略会影响结果与成本的实证证据；但其结论受论文采用的 benchmark、模型、工作负载与实验设置约束。没有核对精确数字时，只应说“实验结果表明策略选择会产生差异”，不能把论文中的百分比写成所有生产 Agent 的预算承诺。
截至 2026-07-26，Anthropic 的 Manage tool context还提供了一个产品级拆分例子：Tool Search 针对初始工具定义，programmatic tool calling 减少中间工具结果往返模型的负担，prompt caching 复用稳定前缀，context editing 清理已进入历史的旧工具结果。它们处理的是不同 token 来源，应分别实验，也可能组合使用；文档中任何关于工具数量的数字指导都只属于当时支持的 Anthropic 产品与场景，不能移植成“超过某个数量就必须搜索”的通用政策。
Provider 灵活性也有机会成本
高缓存复用通常偏好稳定的模型、Provider、effort、区域、deployment、网关路径和 cache key。它们越稳定，既有 prefix epoch 越可能继续 warm；一旦为了降价频繁跨模型或跨 Provider 路由，下一轮即使 prompt 完全相同，也可能承担 cold prefill、缓存写入和更高 TTFT。这就是 Provider 灵活性的机会成本。
但缓存不应制造错误的 lock-in。主 Provider 限流或故障时需要 fallback；敏感任务可能因安全、数据驻留或质量要求必须切换；复杂根因也可能值得升级模型。此时 cold switch 是购买可用性、风险控制或质量，而不是单纯的缓存浪费。预算应记录切换原因、源与目标模型 / Provider、丢失的 cache read、额外写入、TTFT、重试与最终质量，把“发票上的增量成本”和“韧性带来的价值”分开。
一个可执行政策可以规定：正常路径保持模型与区域亲和；超过质量阈值、错误类型或可用性 SLO 时允许切换；为 fallback 预留 cold-start allowance；恢复后不为追求命中强行把任务切回。团队应比较“继续使用 warm 但不适合的模型”和“冷切换后更可能一次完成”的任务级结果，绝不能让 cache lock-in 覆盖质量与安全。
截至 2026-07-26，OpenAI Prompt Caching与 Claude API Pricing分别提供各自模型范围内的缓存行为、usage 和价格事实；Claude Code 缓存说明还列出该产品中模型、effort、compact 与升级等缓存边界。它们适合填写具体 Provider 的预算参数，不构成跨 Provider 共享缓存或统一价格保证。
一份可执行的 Context Budget
预算要能进入发布评审、告警和复盘，而不是只写“尽量省 token”。下面是一份针对交互式 coding agent 的示例；数值必须由团队用真实基线填写，不从别的产品照抄。
| 字段 | 示例预算与执行动作 |
|---|---|
| workload / owner | interactive-coding-v3；Owner 为 Agent Platform + Coding Experience |
| quality & success thresholds | 禁止修改清单零违反；目标测试与完整测试均通过；关键批准、命令、代码版本可追溯；task success 达到团队发布阈值 |
| max / p95 latency | 单轮 TTFT 与端到端 completion time 分别设 p95 SLO；慢工具时间单列，不用它掩盖模型延迟 |
| total task cost budget | 按“定位—修改—完整测试—交付”整任务设预算；超限必须关联 retry、review、cache write/read 与 fallback 原因 |
| prefix / tool epochs | system-vN / project-vN / core-tools-vN；稳定排序与 digest；schema 变更发布新 epoch 并预期冷启动 |
| TTL / auth | 按 Provider、模型、认证渠道记录实际选项；用人类与工具 idle-gap 分布复核；prewarm 仅在 break-even 实验通过时启用 |
| compaction / prune policy | 重复日志尾部可 prune；根因、补丁或测试阶段结束后可 compact；先写 evidence ledger，接近窗口上限前保留恢复 checkpoint |
| fallback / cold-start allowance | 为限流、故障、安全与质量升级预留一次或多次可审计 cold switch；记录增量成本，但不阻止必要切换 |
| observability fields | context length 与区块占比、prefix/tool epoch、first mismatch、cache read/write/uncached、cache-read ratio、TTFT、idle gap、task success、review/rework、tests、total cost、route/fallback |
| experiment / review cadence | 每次模型、工具、摘要或 TTL 版本变化做冷 / warm 回放；按固定节奏复盘分布和尾部，达到 decision rule 才推广，异常可回滚 |
落实时，每个请求携带 budget ID 和 epoch，任务结束生成一张任务级记录；告警同时检查质量阈值、p95、total cost 与冷启动异常，而不是只检查 token 上限。发布新工具或摘要版本时，评审人能看到它改变了哪一项预算、用什么实验验证、何时回滚。这样 Context Budget 才从文档变成运行契约。
上一篇：Append, Prune, or Compact：上下文不是越短越便宜
下一篇：Cache Observability：如何发现并解释缓存失效