【Anthropic】Claude 代理工具高级特性：工具搜索、编程调用、使用示例

1. 问题背景
2. 特性一：工具搜索（Tool Search）
   1. 工作机制
   2. 性能收益
3. 特性二：编程工具调用（Programmatic Tool Calling）
   1. 工作机制
   2. 性能收益
   3. 典型场景
4. 特性三：工具使用示例（Tool Use Examples）
   1. 解决的问题
   2. 性能收益
5. 使用策略
6. 接入方式
7. 核心
8. 评价

原文：Advanced Tool Use on Claude Developer Platform

问题背景

构建规模化 AI（AI）代理系统时，工具定义的 token 消耗是个显著瓶颈。传统「全量加载所有工具」模式下，工具定义可能在代理处理实际请求前就消耗 50,000+ token，导致三个问题：

• 上下文窗口被浪费，留给响应的空间缩小
• 推理成本和延迟上升，每轮对话都要费力读取大量工具定义
• 模型在复杂任务中的表现下降，噪声干扰决策

Anthropic 发布三项测试版特性，针对性解决这些瓶颈。

特性一：工具搜索（Tool Search）

传统模式要在请求中塞入所有工具定义，工具数量增加会线性放大 token 消耗。工具搜索允许 Claude 按需发现工具，定义页面和调用面分离开来。

工作机制

在工具定义中标记 defer_loading: true，该工具只在代理真正需要时才被加载。Claude 通过搜索接口查询可用工具池，而不是一次性遍历所有定义。

本质是「惰性加载（lazy loading）」模式：定义层只保留索引，具体定义延迟到调用点才展开。

性能收益

• Token 消耗减少 85%：测试场景从约 77K token 降到 8.7K token
• 准确率提升：Claude Opus 4.5 在知识检索任务中从 79.5% 提升到 88.1%
• 与缓存兼容：可与提示缓存（prompt caching）叠加使用，成本效率再增一层

关键收益在于「上下文噪声减少」——工具定义不再挤占模型推理空间，更干净的上下文窗口让模型专注于决策本身。

特性二：编程工具调用（Programmatic Tool Calling）

传统工具使用是多轮对话模式：模型返回工具调用，服务端执行，结果再塞回模型，如此反复。编程调用让 Claude 通过代码执行编排工具，中间结果留在执行环境，不进入上下文窗口。

工作机制

代理在执行环境中直接编排多个工具调用，控制流程和条件分支，类似编写脚本。模型只输出「调用哪个工具、怎么传参」，执行逻辑在代码层完成。

这把「控制流」从模型推理剥离出去，模型退化成执行器的指挥官，而非行军层面的审批官。

性能收益

• Token 消耗减少 37%：复杂研究任务中的实测数据
• 消除多轮推理：多步骤工作流变成单次规划+批量执行
• 准确率改进：知识检索准确率从 25.6% 提升到 28.5%
• 支持并行执行：多个工具可并行调用，而不是串行等待

典型场景

预算合规性检查要处理数千条支出项。传统方法将所有行项塞入上下文，噪声导致推理质量下滑。编程调用把循环逻辑留在执行环境，模型只关注「读哪些字段、按什么规则判断」，执行环境负责批量处理数千条记录。

本质是「能力下沉」——把代码擅长的事（批量循环、条件分支）执行掉，模型只做价值最高的决策和规划。

特性三：工具使用示例（Tool Use Examples）

JSON Schema 只能定义数据结构，但无法描述「实际调用模式」。工具使用示例提供具体样板，让模型理解真实世界中的调用方式。

解决的问题

JSON Schema 在以下场景会引发歧义：

• 格式约定：字段是蛇形命名还是驼峰命名
• 参数关联：某个字段出现时，另一个字段怎么取值
• 可选字段包含：在什么场景下包含可选字段
• 边界情况：参数为空数组、特殊字符时怎么处理

仅靠 Schema 无法回答这些问题，模型只能「猜测」，猜测成本折算成准确率损失。

性能收益

• 准确率从 72% 提升到 90%：复杂参数处理任务的内部测试

看似简单的示例子，实际能显著减少模型在「字段组合」和「边情况处理」上的猜测成本。对复杂工具尤其重要——字段越多、约束越多，抽象定义和真实使用的差距越大。

使用策略

三项特性的最佳实践是分层应用，而非全量启用：

1. 诊断性能瓶颈：是 token 消耗、推理轮数，还是格式理解问题？
2. 针对最严重的瓶颈优先应用：工具众多则用工具搜索，任务复杂则用编程调用，格式复杂则补充使用示例
3. 按实际效果补充其他特性

避免一刀切组合。不同代理的瓶颈不同，盲目优化错误的维度比不优化还糟。

接入方式

• 发布状态：测试版（Beta）
• 接入接口：在 Claude Developer Platform API 请求中添加请求头 betas=["advanced-tool-use-2025-11-20"]
• 文档资源：Developer Platform 官方文档和 GitHub cookbook 提供代码示例

---

核心

三个特性的本质是突破「agent 工具使用的根本瓶颈」：

• 工具搜索解决「定义爆炸」——用惰性加载替代全量加载，削弱工具数量的诅咒
• 编程调用解决「推理碎片化」——把复杂协调从模型推理迁移到确定性执行环境
• 工具使用示例解决「理解歧义」——用具体样板替代抽象定义，消除格式猜测

关键洞察是三个瓶颈相互独立但都很关键。不是「选一个」，而是「依症状组合」。真实场景中工具多、任务复杂、格式复杂三者往往同时存在，需要三个特性协同发力。

Anthropic 特意强调「分层策略」，反映对工程现实的务实态度：不同 agent 的主要瓶颈不同，诊断优先于优化。这套思路对设计复杂系统有普适价值——先找最痛点，再打针对性补丁，而非全盘重构或全量引入。

评价

文章结构清晰，按问题→特性→实施→核心洞察展开，逻辑链条完整。性能数据量化具体（如 85%、37% token 减少），可信度高。

说得好：

• 准确定位「工具定义」是规模化瓶颈，而非泛泛而谈「性能问题」
• 每个特性都给出「工作机制」和「性能收益」双重视角，适合工程师按场景选型
• 强调「分层策略」而非全量启用，避免一刀切误用

有待补充：

• 缺少「适用边界」的讨论：工具搜索在多少数量级以上才有明显收益？编程调用的执行环境如何隔离、如何编写？
• 示例代码过少：虽然文中提到几个典型场景，但没有具体代码片段，开发者难以直观对比传统调用和编程调用的差异
• 三特性组合的「优先级矩阵」缺失：什么组合序列是推荐的？什么组合会冲突？这是开发者最关心的问题

隐含假设：

• 假设用户已经熟悉 Claude API 的基础工具使用，未解释 minimun viable setup
• 假设执行环境由开发者提供，未提及平台的「沙箱能力」「安全性保证」——这对企业部署很关键
• 性能数据基于内部测试，未公开「测试场景」细节（工具数量、任务复杂度），外部难以复现验证

整体是篇清晰的特性推介文章，但距离「实操指南」还有距离——适合了解特性，但要落地还需要去找 cookbook 或实验代码。