缓存该放在哪一层，答案跟大多数人的第一反应是反的。前缀缓存便宜、几乎必命中；工具结果缓存省真金白银，但得处理失效；完整回答缓存听着最省事，实际命中率低到让你怀疑人生。多数团队偏偏从第三层开始做——因为那一层最好写，也最像"缓存"。这周翻了几篇 agent 论文，越看越觉得顺序应该倒过来。
收益排序是前缀 > 工具 > 回答，工作量排序正好相反
道理不复杂。前缀缓存是模型服务方帮你做的 KV 复用，只要 prompt 前若干 token 完全一致，它自动省。工具结果缓存省的是外部调用和 token 两笔钱，代价是你得想清楚什么算"同一个调用"。完整回答缓存省得最多——一次都不用调模型——但要求用户原话或者语义几乎一致，这在真实业务里很难。
难的地方在于，三层里最好实现的恰好是收益最低的，最难命中的恰好是大家最想做的。
前缀缓存：不动业务逻辑，只动 prompt 的顺序
这层最划算。系统提示、工具 schema、few-shot 示例全部固定排在最前面，易变的东西——当前时间、用户 ID、检索回来的文档、session 上下文——统统往后放。
坑主要在两个地方。一是有人习惯把时间戳或者 trace id 塞进 system prompt 第一行，那前缀每次都不同，缓存等于没开。二是不管工具 schema 的序列化顺序，JSON 里字段顺序一变，前缀的 hash 就变了。这两个坑我都踩过，排查起来还挺费劲，因为模型照样能跑，你只是账单变贵了。
这周 Jev-Mobile 那篇的思路值得借鉴：把 VLM 规划降频、轻量执行提频，本质上跟缓存是一回事——把贵的东西尽量少算，把便宜的东西多算几次。
工具结果缓存：省的是钱，赌的是世界没变
工具缓存的难点从来不是命中率，是失效。查天气、查股价、查库存，缓存五分钟和缓存一小时是完全不同的两件事。
HN 上这周 Amazon 封掉 Meta 的 Muse agent 那条挺应景——你的工具结果是别人家的实时状态，缓存得越狠，越容易在关键时刻甩给用户一个过期答案。我的筛法是：只读、幂等、外部变更慢的工具才值得缓存，带写操作的坚决不缓。参数里带用户身份、带时间窗的，缓存的 key 得把这些都算进去，否则就是串号事故。
还有一类更稳的做法，是别缓存结果，而是把结果固化下来。HEXIS 把 agent 技能编译成扩展有限状态机，让 agent 不用每次重新推断该走哪一步。这比缓存结果强的地方在于它不会过期——因为它不是记住答案，是记住流程。
完整回答缓存：语义命中是门玄学
用户问"怎么退款"和"退款要多久"，向量空间里贴得很近，答案却完全不是一回事。阈值调高就漏，调低就错，而且错的那次通常最贵。
真要做，只在意图空间有限的入口做，比如结构化 FAQ、客服固定话术。Screen Before You Serve 讲 CX agent 的仿真，说明这个领域确实存在大量重复意图可挖——但人家是先在生产仿真环境里把意图分布摸清楚了才动手的，不是上来就缓存。
命中率得自己测，别抄别人的经验值
每层分开埋点，分开统计。前缀缓存的命中率、工具缓存的命中率和失效比例、回答缓存的命中率和误命中率，是四个不同的数，混在一起看没有意义。而且这些数跟你的 prompt 结构、用户分布强相关，别人贴出来的数字基本没有参考价值。
这里有个提醒。LLM Agents Can Easily Tamper With Their Own Traces 这周刚出来，说的是 agent 能改自己的执行轨迹。如果你的缓存命中率是从 agent 自己写的 trace 里捞出来的，那这个数先别全信。让缓存层自己打日志，别经过 agent 的手。
按我现在看，动手顺序就是：先把系统提示和工具 schema 挪到最前面，一周能上线，几乎零成本；然后把工具按幂等性筛一遍，能缓的缓；完整回答缓存先别碰。也许半年后推理便宜到没人关心这些——但现在的账单还是得看。