大概因为，不知道缓存怎么算，以为缓存高是 Agent 甚至 LLM 的功劳。 下面对话，都是 3 轮，输入 token 都是 40K，（其中 A、B、C、D 都代表 10K token，用｜分割轮次）： 缓存率 44%： 按照 A|BC|D ，缓存率就是(AA+B+C)/(AAA+BB+CC+D)=40K/80K=50% 缓存率 55%： 按照 AB|C|D ，缓存率就是(AA+BB+C)/(AAA+BBB+CC+D)=50K/90K=55%
缓存命中率高意味着特定情况下（现在为普遍）的低成本，高 prompt 复用，高工具工作流优化 如果你觉得缓存不好，那你怎么看 claude code 和其他 agent 明显不同的缓存行为？ https:///t/1233222 我在使用其他工具，如 dsh/hermes/codex/opencode 都没有观察到这种异常的出缓 在工具本身没有拉开性能差距的情况下产生了成本浪费，那我只能认为你不论是主观恶意还是客观优化不足，都存在问题
举个例子, agent/harness 每次都是完全不同的独立上下文协同工作. 和每次会共享一部分 context 避免重复劳动. 这两种方式都能达到目的. 但机制上来说,1 消耗的算力通常会比 2 高. 一个东西从能用就行发展到需要精细工程化的时候就需要有指标去评价实现方式好和不好.
缓存命中率高说明该请求读取了足够多的上下文的情况下帮你省钱了啊。 benchmark 长程任务时，缓存命中越高说明这家服务商给你的缓存时间也长。 针对一个 agent 的性能衡量有很多细节，确实不是一句缓存命中率高能概括的，但是它确实概括某一方面的某些综合能力表征。
