Introducing Advanced Tool Use on the Claude Developer Platform(Claude 开发者平台的高级工具使用)
- 原文标题
- Introducing Advanced Tool Use on the Claude Developer Platform(Claude 开发者平台的高级工具使用)
- 原文链接
- https://www.anthropic.com/engineering/advanced-tool-use
- 作者
- Bin Wu 等(Anthropic)
- 发布日期
- 2025-11-24
🎯 一句话
工具好不好用,决定了 Agent 的能力上限。⭐ 最容易被忽略的一点:工具的返回值是给模型读的,不是给日志看的——它的格式和信息密度直接影响下一步决策质量。
📑 本页目录
有效的 Agent 需要三种传统工具调用模式给不了的能力:不耗上下文的动态工具发现、用代码而非逐次 API 调用的高效编排、从用法示例(而非仅 schema)学习。Anthropic 为此发布三个 beta 特性。
特性一:Tool Search Tool(工具搜索)
解决的问题: 工具定义吞噬 token 预算。示例:GitHub+Slack+Sentry+Grafana+Splunk 五个服务器共 58 个工具,对话还没开始就消耗约 55K token;再加 Jira 逼近 100K+。
工作方式:
- 工具标记 defer_loading: true 延迟加载
- 初始只加载搜索工具本身(约 500 token)
- Claude 需要时搜索相关工具,只有匹配的工具才展开进上下文
效果: - token 用量减少 85%,同时保有完整工具库访问 - 准确率提升:Opus 4 从 49% → 74%;Opus 4.5 从 79.5% → 88.1% - 与 prompt caching 兼容(延迟加载的工具不在初始提示词中)
适用: 10+ 工具的大型库、多 MCP server、工具定义超 10K token 时。
特性二:Programmatic Tool Calling(程序化工具调用)
解决的问题: 中间结果污染上下文 + 推理开销。处理 10MB 日志会把整个文件挤进上下文;跨表查询会累积每一条记录。
工作方式:
1. 工具标记 allowed_callers: ["code_execution_20250825"]
2. Claude 生成 Python 代码编排多个工具调用
3. 工具结果在代码执行环境中处理,不进 Claude 上下文
4. 只有最终输出进入上下文窗口
例子——差旅预算核查: - 传统方式:20+ 次工具调用,2,000+ 条报销明细(约 50KB)全进上下文 - 程序化:脚本处理全部数据,Claude 只看到 3-5 个超预算的人
效果: - token 平均减少 37%(43,588 → 27,297) - 并行执行 + 减少推理轮次带来延迟改善 - 准确率:知识检索 25.6% → 28.5%;GIA 基准 46.5% → 51.2%
适用: 有依赖关系的多步流程、并行操作、大数据集摘要、条件逻辑。实际应用:Claude for Excel 用它处理数千行表格而不压垮上下文。
特性三:Tool Use Examples(工具使用示例)
解决的问题: JSON Schema 只定义结构合法性,表达不了使用惯例——日期格式("2024-11-06" 还是 "Nov 6, 2024"?)、ID 惯例(UUID 还是 "USR-12345"?)、嵌套结构何时填、参数之间的关联(升级级别与 SLA 小时数如何随优先级变化)。
工作方式: 在工具定义中加入 input_examples 数组,展示最小、部分、完整三类调用示例。Claude 从少量示例中学会格式惯例、嵌套模式和参数关联。
效果: 复杂参数处理的准确率从 72% → 90%。
适用: 复杂嵌套结构、有领域惯例的 API、大量可选参数、区分相似工具。
组合策略
按最大瓶颈选择切入点,而非同时全上: - 工具定义撑爆上下文 → Tool Search Tool - 中间结果太大 → Programmatic Tool Calling - 参数错误频发 → Tool Use Examples
配置要点: 常用的 3-5 个工具保持常载,其余延迟加载;文档写清返回格式;示例用真实数据而非泛型占位符,每个工具 1-5 个。
API 启用:betas=["advanced-tool-use-2025-11-20"]。
结论
三个特性共同让 Agent 突破基础限制:动态发现代替预载全部定义、代码编排代替逐次推理调用、示例学习补足 schema 校验。按瓶颈分层采用,支撑跨数十个工具和大数据集的复杂 Agent 工作流。
✅ 检查点
- 为什么说返回值设计和参数设计一样重要?
- 工具太多时会出什么问题?怎么办?
- 什么样的错误信息才是「好」的?
👀 答案
- 因为返回值直接进入模型的上下文,是它做下一步决策的全部依据。返回一个巨大的 JSON dump,既浪费上下文又淹没关键信息;⭐ 好的返回值应当只包含决策需要的字段,并对结果做必要的摘要。
- ⭐ 模型会选错工具,或者在相似工具之间犹豫——工具描述之间的重叠越多,选择越不稳定。解法:①合并功能相近的工具;②描述里写清「什么时候不该用它」(边界比功能更能区分);③用工具搜索/按需加载,让模型每次只面对相关的那几个。
- ⭐ 四个要素:①说清哪里错了 ②说清为什么错 ③给出可执行的下一步 ④保留必要的原始信息。例:不要返回「400 Bad Request」,而要返回「参数 date 格式应为 YYYY-MM-DD,收到的是 2025/13/01;注意月份最大为 12」。好的错误信息能让模型自己修好,差的只能让它重试同样的错误。
🛑 可以停在这里
⚡ 走神救援
⭐最容易被忽略的一点:工具的返回值是给模型读的,不是给日志看的——它直接进入上下文,是下一步决策的全部依据;巨大的 JSON dump 既浪费上下文又淹没关键信息,好的返回值只包含决策需要的字段并做必要摘要。工具太多时模型会选错或在相似工具间犹豫,解法:合并功能相近的、描述里写清「什么时候不该用它」(边界比功能更能区分)、按需加载。⭐好错误信息四要素:哪里错了、为什么错、可执行的下一步、保留必要原始信息——不要返回「400 Bad Request」,要返回「参数 date 格式应为 YYYY-MM-DD,收到 2025/13/01,月份最大为 12」;好的错误信息能让模型自己修好,差的只能让它重试同样的错误。