缓存命中率到了 97%，AI 代码审查就应该便宜了吗？Cloudflare 在北京时间 2026 年 10 月 20 日凌晨发布的工程报告里，给出了一个反例：命中率上升的同时，每次审查处理的 token 数量增加了两倍多，账单照样变厚。
随后一轮优化把平均单次审查的推理费用从 2.43 美元降到了 0.77 美元，降幅约 68%。其中既有缓存布局和工具调用的调整，也有模型与推理强度的变化。但报告同样承认，部分审查角色找出的重要问题变少了。理解这两部分，才能判断哪些做法值得迁移到自己的系统。
先看账单的分母
Cloudflare 的审查系统由协调者分派工作，再交给代码质量、安全、性能和内部标准等专门的审查角色。不同风险档位使用不同的审查力度，同一个合并请求在后续推送时也可能再次接受审查。
原文给出的 68%，以优化前最贵的两个星期平均每次 2.43 美元为基线，比较优化后的 0.77 美元。这是其特定工作负载的推理费用，不是整套平台的总拥有成本，也不保证其他团队能得到相同降幅。
报告用固定的审查档位组合观察每日成本，减少“大改动突然变多”对趋势的干扰。不过，各次优化的贡献主要按照发布前后的工作日时段估算，作者明确说这不是严格受控实验。文中有些模型和推理强度比较采用了随机分流，不能因此把所有前后变化都当成同等强度的因果证据。
费用上涨也不只因为缓存。此前切换模型就曾提高单次成本。到了九月，缓存命中率从四月的 85.7% 升到约 97%，每次审查的 token 量却从 91 万增到 299 万。命中比例更高，处理总量仍可能更贵。
同一段上下文，会在每一轮重新计费
多轮智能体的开销容易被低估。模型读完一个文件、决定再读另一个文件时，下一次请求通常还要带上已有会话。前几轮积累的内容会反复进入后续请求。
Cloudflare 在优化前发现，代码质量审查者平均每次审查调用模型 16.6 次，累计写入缓存约 7.2 万 token，读取缓存约 108 万 token。其整体审查推理费用中，输出约占 23%，缓存写入约占 43%，缓存读取约占 34%。
缓存读取有折扣，但不会变成免费。以报告采用的五分钟缓存计费为例，写入价格为普通输入的 1.25 倍，读取为 0.1 倍；具体费率仍要核对所用模型和平台的当前文档。反复读取上百万 token，即使打了折，也值得单独优化。
因此，实际排查应同时看请求次数、上下文长度、缓存写入量和读取量。只盯命中率，会把“反复做同一件多余的事”误认为系统运行得很好。
第一条请求为什么没有命中缓存
这次最有用的发现，来自对每个审查会话首个请求的记录。
不同仓库明明共用约 1.1 万到 2.1 万 token 的工具定义和智能体提示，首次请求命中缓存的比例却只有 14% 到 26%。原因藏在实际发给服务商的内容里。
当时使用的 OpenCode v1 把通用提示、工作目录和日期放在同一个系统内容块中，只在整个块的末尾设置缓存断点。工作目录一变，断点覆盖的前缀就不同；跨仓库共享的那部分内容没有被单独存下来。
前缀缓存不是在长文本里寻找任意相同片段。按照 Anthropic 的文档，缓存命中要求截至相应断点的提示片段完全一致。断点之前混入动态路径、时间戳或变化的工具描述，都会影响复用。
Cloudflare 在通用提示末尾加入标记，用插件把系统内容拆成两块，并给稳定部分单独设置断点。调整后，各审查者首个请求读取缓存的比例升到了 91% 至 99.5%。
迁移这个思路时，可以把请求组织为稳定工具定义、通用规则、明确的缓存断点，再接仓库环境与本次改动。不过，实际 API 对内容块、顺序和断点都有约束，应检查序列化后的请求，而不只看代码里几段提示词是否相同。
原文还提到，为保持前缀一致，他们调整了技能列表和工具描述。普通项目不应照搬成“关闭仓库指导文件”。必要规则仍要保留，只是应明确哪些规则共用、哪些属于仓库上下文，并避免把秘密、个人信息或不必要的业务数据塞进提示。
省掉没有产出的调用
另一些改动很朴素，却能解释智能体系统为什么越来越贵。
子审查者能看到发布最终评论的工具，却没有调用权限。在 57% 至 76% 的相关会话中，它们尝试调用、被服务端拒绝，然后再用一次模型调用处理失败。把不可用的工具从子角色中移除，既减少了错误路径，也让每次请求少带约 2900 token 的工具定义。
最终评论发出后，框架还会把执行结果交回模型，让它读取整个会话，写一段无人使用的总结。停止这一步，报告估算每次任务可省约 0.07 美元。
还有已经取消但仍在后台运行的任务。在其抽样的 446 个取消任务中，358 个继续运行直到审查完成。后来任务每 15 秒检查自身状态，确认取消就退出。这里的收益与模型能力无关，是任务生命周期管理的问题。
重复审查也值得单独处理。报告称约三分之二的任务是同一个合并请求的第二次或后续审查；如果某个角色没有新增内容可查，就跳过它。迁移时必须把跨文件依赖、共享规则和基线变化纳入失效条件，不能只凭“这个文件没改”就判断相关检查一定可以省略。
多个角色复用缓存，还涉及并发时序
代码质量、安全和性能审查者后来共享同一段初始内容，包括工具、通用规则和本次合并请求的补丁，各自的专属指令放在后面。
但三个角色同时发请求，不代表它们能同时读到同一个新缓存。原文说明，写入缓存的请求开始返回流式响应后，其他请求才能复用它。
他们因此让其中一个角色先发出请求，另外两个等待它开始返回，最多等待 20 秒，再提交各自请求。报告估算这为后两个角色各省约 0.09 美元，代价是略增启动等待。
这是成本与延迟的明确交换。低流量系统可能没有足够复用机会，短任务也可能不适合等待；如果实现类似编排，还要考虑首个请求失败、缓存过期和等待超时后的回退路径。
便宜了，也要确认有没有漏查
Cloudflare 报告整体审查的中位耗时从 4 分 9 秒降到 1 分 32 秒。更少调用确实让系统更快，但速度无法替代质量评估。
他们用了两种检查。一种观察审查指出的行是否在作者下一次推送中被修改。代码质量角色的严重问题“被采取行动”比例从 34% 升到了 59%。这个指标能反映建议是否促成改动，却不能证明建议正确，附近无关行也存在约 15% 的自然修改比例。
另一种是抽取 657 条发现，交给两家服务商的模型在不知道来源时段的情况下评判，意见不一致再交第三个模型。总体每次审查的重要发现从 0.28 变成 0.30，区间重叠，不能据此宣称质量显著提升。评判者仍然是模型，分组样本有限，最新观察窗口也只有一天。
分角色看，结果更值得警惕。代码质量角色采用中等推理强度时确实丢失了真实发现，因此团队决定改用高强度。在随机分流中，高强度每次运行贵 61%，但给出多 58% 的 critical 和 warning 发现；结合后续质量检查，他们认为这笔开销值得保留。
性能角色仍用中等强度，评判结果显示每次审查的重要性能发现约少了 64%，折合约每 24 次完整档位审查少发现一个重要问题。安全角色的重要发现也下降约四分之一，但没有统计显著性。两者后续仍需测试更高推理强度。
因此，这不是一份“无损降本 68%”的证明。比较可靠的实践顺序是先消除无意义调用和重复上下文，再分别评估各角色的模型与推理强度。把所有角色统一调低，很容易把真正需要深查的部分一起削掉。
结语
这份报告最值得复用的，是从一次真实请求开始查账的方法。记录首轮是否读取缓存、哪些工具调用被拒绝、任务取消后是否停止，再把费用、耗时和有效发现放在一起比较。
缓存命中率能说明一部分效率，却不能说明整笔账是否合理。对于代码审查，最终要回答的仍是：省下这些钱之后，团队有没有少发现本该修掉的问题。
参考来源
- Cloudflare：Cutting our inference bill by 68% by being obsessive about optimization，发布于 UTC 2026 年 10 月 19 日 19:12，北京时间 10 月 20 日 03:12；本文的成本、延迟和评估数据均来自该团队报告。
- Anthropic：Prompt caching，用于核对缓存断点、前缀精确匹配和计费机制；文档与费率可能随模型及平台调整，访问日期为 2026 年 10 月 20 日。