Skip to content
Wen's Blog

Anthropic Advanced Tool Use 解读:让 Agent 在大规模工具系统中稳定工作

Mar 3, 2026 — Claude, Agents, Tool, Reading

结论先行

这篇文章最有价值的地方,不是又新增了三个 API 能力,而是把大规模工具系统里最常见的三个故障点拆开了:

  1. 找不到合适工具,用 Tool Search Tool 解决。
  2. 每次调用都太贵,用 Programmatic Tool Calling 解决。
  3. 参数经常填错,用 Tool Use Examples 解决。

推荐优先级也很明确:先解决上下文和准确率瓶颈,再优化执行路径,最后补齐参数语义。

背景:传统 Tool Calling 为什么会失效

当工具数量从 5 个增长到 50 个、500 个之后,传统模式会出现三个结构性问题:

本质上,问题不在“模型不会调用工具”,而在“系统没有给模型提供合适的工具工作方式”。

Tool Search Tool:从全量加载转向按需发现

Tool Search Tool 的核心价值是把工具目录和推理上下文解耦。

在 API 侧,你可以把大量工具标记为 defer_loading: true,默认不注入上下文;模型只有在需要某类能力时才搜索并加载对应工具定义。这一做法有三个直接收益:

工程建议:始终保留 3-5 个高频核心工具常驻,剩余工具走延迟加载。这样可以在首轮响应速度和长期扩展性之间取得较好平衡。

Programmatic Tool Calling:把流程控制从自然语言搬到代码

Programmatic Tool Calling(PTC)的重点,不是“能写 Python”,而是“把中间态留在执行环境,不污染模型上下文”。

传统方式下,模型会看到每个工具的原始返回,再在自然语言层做汇总、比较和筛选。数据量一大,模型既慢又容易丢重点。PTC 则把这部分工作放进代码:

这对日志分析、批量巡检、多实体对账等任务特别有效。推荐把“可并行、可重试、幂等”的工具优先接入 PTC,收益最大。

Tool Use Examples:用样例补齐 Schema 的语义空洞

JSON Schema 只能告诉模型“参数结构合法”,但无法告诉模型“在什么场景该怎么填”。

input_examples 的作用就是把团队内部约定显式化,例如:

建议每个复杂工具准备 1-5 个高质量样例,覆盖最小输入、常规输入和完整输入三类路径。样例要短、真实、可复用,避免“字段全填满”的演示式示例。

三层能力如何组合

推荐组合策略:

  1. 工具发现层:Tool Search Tool 负责缩小候选工具集合。
  2. 工具执行层:PTC 负责并发调用与中间数据处理。
  3. 工具调用层:Tool Use Examples 约束参数格式与调用习惯。

这三层分工清晰,能分别对冲“找不到”“调不动”“调不准”三个常见故障域。

在移动端团队里的实践建议

如果你的 Agent 要服务 iOS/Android 双端协作(CI、崩溃治理、发布流水线、工单流转),可以按下面方式拆分:

这样做的结果通常是:上下文压力更小,自动化流程更快,跨工具链路的可预期性更高。

边界与取舍

这三项能力并非总是必要:

推荐做法是先识别主要瓶颈,再按需开启,而不是一次性全部上齐。

参考链接