Agent 工具结果缓存：被忽视的成本优化杠杆与语义缓存模式

Agent 成本优化的常见杠杆是模型路由、上下文压缩和 prompt 优化——但工具结果缓存是被忽视的第四个杠杆。 当团队讨论 Agent 成本时，注意力通常集中在三个方向：用更便宜的模型处理简单步骤（模型路由，可节省 40-70%）、压缩上下文窗口（可减少 50-70% 输入 token）、以及优化 prompt 结构减少冗余。这三项都有成熟的工具和方法论，但第四个杠杆——缓存工具调用的结果——几乎不在讨论范围内。

这不是边缘优化，而是 Agent 平台进入生产必须考虑的基础能力。 一个客服 Agent 可能在同一会话中重复查询同一订单的物流状态；一个数据分析 Agent 可能对同一张表执行多次相似的 SQL 查询；一个研究 Agent 可能对相似关键词发起多次搜索 API 调用。模型本身只是「决定调用哪个工具」，真正的时间、费用、限流和不稳定性来自工具背后的外部系统。OpenAI 的 Function Calling 文档将工具调用描述为多步流程：提供可调用工具→模型返回工具调用→应用执行代码→工具结果反馈给模型。Anthropic 的工具使用文档同样强调，工具可以在应用侧或服务端执行，服务端工具可能产生额外费用。

一个具体的成本信号： 根据 Kunal Ganglani 的 per-task cost model 分析，Agent 工作流中工具调用的实际成本远不止 token 定价。工具 schema 定义占用输入 token（一个 200 行的 JSON schema 在每次调用中都被计费）、工具结果被重新注入上下文成为后续步骤的输入 token（tool_result_reinjection_rate 通常为 0.6）、而且某些工具本身有按次计费的非 token 成本（如搜索 API、知识库查询）。当一个 Agent 任务包含 5 个步骤、每步平均 3 次工具调用、每次工具结果约 1200 token 时，仅工具结果注入就贡献了 18000 token 的输入成本——这还没有计算外部 API 的按次费用。如果其中 40% 的工具调用是重复的（同一会话中多次查询同一订单状态），缓存命中可以直接消除这部分成本。

工具结果缓存（Tool Result Cache）与 Prompt Cache、KV Cache 和 LoRA 适配器缓存都不同。 Prompt Cache（如 OpenAI 的 prompt caching）缓存的是模型前缀的 KV 计算结果，适用于 system prompt 复用；KV Cache 是推理引擎内部的注意力计算缓存；LoRA 适配器缓存是模型权重切换的优化。而工具结果缓存位于 Agent Runtime 和外部工具之间，缓存的是工具返回的结构化数据（如 JSON 响应），目标是减少重复调用、降低尾延迟、缓解第三方 API 限流，并保持结果可审计、可失效、可回放。理解这个边界，是避免「把所有缓存混为一谈」导致生产事故的第一步。

最常见的工具缓存事故不是缓存失效太慢，而是缓存键设计太粗。 一个看似相同的查询，在不同租户、用户、权限、语言、时间窗口或工具版本下，可能返回完全不同的结果。如果缓存键只包含工具名和原始参数，就会发生跨用户数据泄露——这是生产环境中最严重的缓存 bug 之一。

推荐的缓存键结构至少包含六个组成部分： tool_result:v1:{tenant_id}:{user_scope}:{tool_name}:{tool_version}:{normalized_args_hash}:{policy_scope}。其中 normalized_args_hash 必须来自排序后的 JSON 参数，而不是模型生成的原始字符串。例如 {"city":"Paris","unit":"celsius"} 和 {"unit":"celsius","city":"Paris"} 应该命中同一个键——这要求对参数做 key-sort + 去除 volatile 字段（如 trace_id、request_id、timestamp）后再做哈希。

user_scope 是防止跨用户泄露的关键。 对于公共天气查询，可以使用 public；但对于订单、账户、报告等权限相关工具，必须绑定到用户、角色或授权范围。一个简单规则：如果工具的输出因用户身份不同而不同，缓存键就必须包含用户级隔离。

工具版本（tool_version）经常被忽略，但它是安全失效的保险丝。 当工具后端升级了 API 版本或修改了返回结构，旧缓存应该自动失效。把版本号编入缓存键，意味着每次工具升级后，旧键自然过期，不需要手动清理缓存——这是「版本即失效策略」的工程实现。

缓存系统（如 Redis）支持写入时设置过期时间，但 Agent 工具结果不能简单设为「10 分钟后过期」。 每种工具的新鲜度语义不同：商品详情可以缓存较长时间，订单状态可能只允许 30 秒，而支付、退款、邮件、下单等副作用工具的执行结果根本不应该被缓存——缓存命中不能替代实际执行。

TTL 应该来自业务语义，而不是缓存系统的默认值。 推荐的做法是让每个工具在注册时声明自己的缓存契约：是否可缓存、TTL 秒数、失效触发事件。例如商品详情工具声明 cacheable: true, ttl_seconds: 3600, invalidation: product_updated_event；天气工具声明 cacheable: true, ttl_seconds: 600, invalidation: ttl_only；订单状态工具声明 cacheable: true, ttl_seconds: 30, invalidation: order_status_changed_event；退款工具声明 cacheable: false, reason: side_effect。

事件驱动失效（event-driven invalidation）比纯 TTL 更精确，但实现成本更高。 当后端系统可以发布领域事件（如「订单状态变更」「商品详情更新」）时，缓存层可以订阅这些事件并主动失效相关键。这避免了「TTL 太长导致用户看到过期数据」和「TTL 太短导致缓存命中率低」的两难。对于无法提供事件的第三方 API，只能退回到纯 TTL 策略——此时 TTL 应该保守设置，宁可多调用一次 API 也不要返回过期结果。

一个常见的错误是用「缓存系统支持的最大 TTL」作为默认值。 Redis 的默认 TTL 可能是 1 小时或 1 天，但这对于订单状态工具来说太长——用户下单后 30 秒内查询物流，如果返回的是 1 小时前的缓存结果（显示「已发货」但实际已签收），会引发严重的用户体验问题。正确的做法是：每个工具在注册时强制声明 TTL，没有声明的工具默认不可缓存。这迫使工具开发者思考「我的数据多久会过期」，而不是把责任推给缓存系统。

幂等键（idempotency key）用于防止同一副作用请求被重复执行——如重复退款、重复发短信、重复创建工单。缓存键（cache key）用于复用只读结果。 两者可以共享归一化参数逻辑，但语义完全不同。混淆两者是生产环境中最常见的缓存 bug 之一。

一个典型错误是：看到模型再次调用 create_ticket，就直接返回上一次的结果。 正确做法是：如果业务请求携带了相同的幂等键，返回同一笔交易结果；如果没有幂等键，写操作不应该被视为缓存命中。一个简单的经验法则：读操作可以缓存，写操作必须幂等——但幂等不等于缓存。

幂等键的生命周期与缓存键也不同。 幂等键通常有较短的有效期（如 24 小时），用于去重同一笔交易的重试；缓存键的有效期由工具的新鲜度语义决定，可能从 30 秒到 1 小时不等。把幂等键当缓存键用，会导致写操作结果被无限期复用；把缓存键当幂等键用，会导致同一笔交易在不同时间被重复执行。

从工程实现上看，幂等键和缓存键应该存储在不同的存储层。 幂等键通常需要持久化存储（如数据库），因为它需要跨服务重启保持去重能力；缓存键通常存储在内存或 Redis 中，可以容忍丢失。当服务重启后，幂等键应该仍然有效（防止重启后重试导致重复执行），而缓存键可以安全清空（重启后重新获取数据即可）。这个存储层的差异，是区分两者的另一个重要维度。

精确匹配缓存（exact-match cache）要求输入完全一致才能命中——但 Agent 场景中，模型可能对同一信息用不同的自然语言描述发起工具调用。 语义缓存（semantic cache）通过嵌入向量相似度来判断两次调用是否「语义等价」，从而在参数不完全一致时也能命中缓存。例如「北京今天天气」和「北京市今日气温」在精确匹配下是不同键，但在语义缓存中可能命中同一条结果。

语义缓存的核心工程挑战是阈值设定和上下文边界感知。 相似度阈值设得太低（如 0.8），会把语义不同但表面相似的查询错误合并——「上海明天天气」和「北京明天天气」的嵌入相似度可能超过 0.85，但返回结果完全不同。阈值设得太高（如 0.98），则退化为精确匹配，失去语义缓存的意义。经验值是 0.92-0.95，但必须按工具类型调优。

上下文边界感知（context boundary awareness）是语义缓存进入生产的关键。 同一个问题「我的订单状态」，对于用户 A 和用户 B 返回完全不同的结果——语义缓存必须在隔离边界内做相似度匹配，而不是全局匹配。实现方式是：先按 tenant_id + user_scope 分桶，在桶内做向量相似度检索。这保证了跨用户数据不会泄露，同时让同一用户的相似查询能命中缓存。

语义缓存的成本结构也需要考虑。 每次缓存写入需要计算嵌入向量（额外 API 调用或本地模型推理），每次缓存读取需要做向量相似度检索（需要向量数据库或内存索引）。只有当工具调用成本高、延迟敏感、且查询模式存在语义重复时，语义缓存的 ROI 才为正。对于低成本、低延迟的工具，精确匹配缓存已经足够。

一个实际案例：电商客服 Agent 的语义缓存部署。 某电商平台的客服 Agent 每天处理约 50,000 次工具调用，其中「查询订单状态」占 35%。精确匹配缓存的命中率为 42%（因为模型会用不同的参数顺序和表述调用同一工具）。引入语义缓存后，命中率提升到 68%，但带来了新的挑战：(1) 嵌入计算延迟约 50ms，对于原本 200ms 的工具调用来说占比 25%；(2) 向量数据库的存储成本约为 Redis 的 3 倍；(3) 需要每两周重新校准相似度阈值，因为模型的表述模式会随版本更新而变化。最终该团队采用的混合策略是：对「订单状态」「物流查询」等高成本工具使用语义缓存，对「商品详情」「用户信息」等结构化查询继续使用精确匹配缓存。

Agent 的 per-task 成本模型不是简单的「单次 API 调用价格 × 调用次数」。 当 Agent 包含重试、工具扇出（fanout）、上下文增长和缓存时，单次调用成本模型完全失效。Kunal Ganglani 的 per-task cost model 给出了一个 spreadsheet-ready 的预期成本方程：

expected_step_cost = expected_attempts × (llm_cost + tool_provider_cost)

其中 expected_attempts = 1 + (retry_prob × avg_retry_count)，llm_cost 需要包含三个「隐藏乘数」：tool_schema_tokens（工具定义占用的输入 token）、tool_result_tokens（工具输出被重新注入上下文的 token）、以及 context_compaction_factor（压缩后的上下文比例）。

工具缓存改变这个方程的方式是：降低 tool_result_tokens 的重复计算，以及降低 tool_provider_cost 中的非 token 成本。 当一个工具被缓存命中时，tool_provider_cost（如搜索 API 的按次计费）降为零；tool_result_tokens 仍然被注入上下文（模型需要看到结果），但不再产生外部 API 调用费用。这意味着缓存命中的边际成本几乎为零——只有缓存存储和检索的开销。

缓存命中率（cache hit rate）应该成为 per-task cost ledger 的一行。 就像追踪 input_tokens 和 output_tokens 一样，团队应该追踪 cached_tool_calls、cache_misses 和 cache_hit_rate。当缓存命中率低于预期时，需要排查：缓存键是否太细（隔离过度）、TTL 是否太短、或者查询模式确实缺乏重复性。

一个关键的洞察：缓存改变了「重试成本」的方程。 当工具调用失败时，Agent 通常会重试。如果第一次调用失败但结果被缓存（例如部分响应或错误状态），重试时可以直接使用缓存结果而不必再次调用外部 API。这在高成本工具（如付费搜索 API、数据库查询）场景下尤为重要——重试的边际成本从「全额 API 费用」降低到「缓存检索费用」。

生产环境的工具结果缓存不是「在工具调用前加一个 if-else」，而是一个完整的审计链路。 推荐的生产 pipeline 分为五步：(1) 模型返回工具调用；(2) Tool Runtime 执行权限检查、参数校验和幂等检查；(3) Cache Policy 判断是否允许读缓存；(4) 命中则返回缓存结果，未命中则调用真实工具；(5) 无论命中与否，将结果作为标准工具输出反馈给模型，并写入 trace。

关键点在于：缓存层不应该让模型感知到「工具没有被执行」。 对模型来说，它仍然收到一个工具输出；在工程侧，trace 必须显式标记 cache_hit=true、cache_key、ttl_remaining、source_fetched_at 和 tool_version。这保证了审计回放时能区分「哪些结果是实时获取的，哪些来自缓存」，也保证了当缓存结果过期或出错时，能快速定位受影响的会话。

上线前的检查清单包括： 缓存键是否包含租户和用户隔离？副作用工具是否被标记为不可缓存？TTL 是否与业务语义一致而非缓存系统默认值？缓存命中时 trace 是否完整标记？缓存失效事件是否能正确触发？跨用户泄露的回归测试是否通过？这些检查的缺失不会在开发环境暴露，但会在生产环境以数据泄露或过期结果的形式爆发。

一个常见的部署错误是「缓存层对模型透明但 trace 不完整」。 当模型收到缓存结果时，它无法区分这是实时获取还是缓存命中——这是正确的设计。但如果 trace 中没有标记 cache_hit=true，当用户投诉「数据过期」时，运维团队无法快速定位哪些会话受到了影响。完整的 trace 应该包含：cache_key（用于排查键设计问题）、ttl_remaining（判断是否 TTL 设置过短）、source_fetched_at（判断数据新鲜度）和 tool_version（判断是否工具升级导致结构变化）。这些信息在开发环境中看似多余，但在生产事故排查时是不可或缺的线索。

工具结果缓存不是「有缓存总比没缓存好」的简单决策。 它需要精确的缓存键设计（工具名 + 归一化参数 + 隔离边界）、按工具声明的 TTL 策略、幂等键与缓存键的语义区分、语义缓存的阈值与桶内检索，以及与 per-task cost model 的结合。忽略任何一项，都会在生产环境以数据泄露、过期结果或成本失控的形式暴露。

对 Agent 团队的实践建议是： 从精确匹配缓存开始，先覆盖高频、高成本、低变化的读操作工具（如商品详情、用户权限、配置查询）；为每个工具声明缓存契约而非使用全局 TTL；把缓存命中率纳入 per-task cost ledger 的常规追踪；只有当精确匹配缓存的命中率遇到瓶颈时，再引入语义缓存并严格设定桶内检索的相似度阈值。工具结果缓存是 Agent 成本优化的第四个杠杆——但它需要工程精度，而不是简单的「加个 Redis」。

最后一个容易被忽略的点：缓存层不应该让模型感知到工具没有被执行。 对模型来说，它收到的始终是标准工具输出；但在工程侧，trace 必须完整标记缓存命中、键值、剩余 TTL、数据来源时间和工具版本。这保证了审计回放、问题定位和合规审查的完整性——也是工具结果缓存从「性能优化」升级为「生产基础能力」的标志。

工具结果缓存的工程本质是在「减少重复调用」和「保证数据新鲜度」之间找到平衡点。 这个平衡点因工具类型、业务场景和成本结构而异——没有放之四海而皆准的 TTL，也没有适用于所有工具的缓存策略。但有一点是确定的：当 Agent 系统进入生产环境，工具结果缓存不再是可选项，而是必须面对的工程挑战。

• LLM Tool Result Caching in Production — oh-bug.com, 2026-07-07. 涵盖缓存键设计、TTL 语义、事件驱动失效、状态隔离、审计回放和上线检查清单。
• Agent Per-Task Cost Calculation [2026]: Retries, Tools, Caching — Kunal Ganglani, 2026-07-18. 给出 spreadsheet-ready 的预期成本方程，拆解 tool_schema_tokens、tool_result_tokens 和 context_compaction_factor 三个隐藏乘数。
• Cache Strategies for AI Agents: Avoiding Redundant LLM Calls — CallSphere AI, 2026-03-16. 讨论 Agent 场景下的缓存策略与冗余调用避免。
• OpenAI Function Calling Guide — OpenAI Platform Documentation. 描述工具调用为多步流程：提供可调用工具→模型返回工具调用→应用执行代码→工具结果反馈给模型。
• Anthropic Tool Use Documentation — Anthropic Claude API Documentation. 强调工具可以在应用侧或服务端执行，服务端工具可能产生额外费用。