一句话定义:工具结果缓存(Tool Result Caching)是把一次工具调用的「输入 → 输出」保存下来,当相同的输入再次出现时直接返回旧结果,跳过真正的执行。
它省掉的到底是什么
工具调用有成本:延迟、配额、外部 API 的费用,以及 Agent 多轮循环里那些重复到令人心疼的调用——重试、子任务、多个 Agent 各查一遍同一个东西。
缓存的实现朴素得像同事留的便利贴:上次有人问过这个 SKU 的库存,把答案抄在便签上贴屏幕边,下次谁再问就直接念便签,不用再跑一趟仓库。
技术上,关键是缓存键(cache key):一般由「工具名 + 规范化后的参数 + 上下文」拼成。命中就返回,未命中就执行并写回。
缓存变成错误答案的六种情形
缓存的本质是替你做了一个假设:世界没有变。这个假设一旦不成立,缓存就从加速器变成错误信息源。
1. 状态在变,却没有过期时间(TTL, Time To Live)。上午查的库存,下午已经被买空。
2. 缓存键漏掉了隐式上下文。这是最危险的一种:「查我的订单」这样的工具,如果键里没有用户 ID、租户、权限范围,缓存就会让 A 看到 B 的数据。这不是性能问题,是安全事故。
3. 工具带副作用。下单、发邮件、写数据库、扣款——这类工具命中缓存等于「事情根本没做」,语义被悄悄改写了。是否可缓存,取决于它是否是幂等(idempotent)的只读操作。
4. 参数没做规范化(normalize)。JSON 键顺序、空白、大小写、分页游标、混进参数里的 trace id 和时间戳,都会让本该命中的没命中;反过来,规范化过头把真正有意义的字段(比如「第 2 页」)抹掉,就会错误命中。
5. 把失败也缓存了。超时、限流、空结果被写进缓存,一个临时故障被固化成长期错误答案。只缓存成功结果,是条便宜又好用的规矩。
6. 工具本身不确定。网页搜索、模型采样每次结果都不同,缓存下来的只是「某一次观测」,必须明确标注,而不是当成事实。
和几个近邻的区别
| 概念 | 缓存的是什么 | 风险点 |
|---|---|---|
| 工具结果缓存 | 工具的输出 | 输出可能已经过时或串号 |
| 提示缓存(AI 词典：Prompt Caching">Prompt Caching) | 模型输入前缀的中间计算结果 | 只影响成本与延迟,不改事实 |
| 记忆(Memory) | 跨会话的偏好与结论,靠语义检索 | 记错、记旧 |
| 幂等性 | 一种操作性质,不是缓存机制 | 混淆会导致重复副作用 |
记忆是「模糊地记住」,缓存是「精确地复用」;提示缓存省的是 token,工具结果缓存省的是真实世界的一次往返。
对做产品的人和用产品的人
给从业者:默认不缓存有副作用的工具;只读工具按数据变化速度分级,快变的给短 TTL 或不缓存;缓存键必须包含身份与权限维度;错误不写入;把命中率、命中后的抽样校验做成可观测指标。
给使用者:当你看到 Agent 秒回一个「昨天才成立」的答案,先怀疑缓存,而不是模型。要求它标明数据的时间戳,是最省事的自保方式。具体实现各平台差异不小,以官方文档为准。