🏠 总目录 📚 资料库工具与 MCP

Introducing Advanced Tool Use on the Claude Developer Platform(Claude 开发者平台的高级工具使用)

📄 来自 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
⚠️ 本页是原文的中文结构化整理笔记(保留架构、数据、案例、结论),并非逐字翻译。具体参数与功能名更新很快,落地前请点击上方链接核对原文。

12 分钟 | 🛠️ 工具设计的进阶细节

🎯 一句话

工具好不好用,决定了 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 工作流。


✅ 检查点

  1. 为什么说返回值设计和参数设计一样重要?
  2. 工具太多时会出什么问题?怎么办?
  3. 什么样的错误信息才是「好」的?
👀 答案
  1. 因为返回值直接进入模型的上下文,是它做下一步决策的全部依据。返回一个巨大的 JSON dump,既浪费上下文又淹没关键信息;⭐ 好的返回值应当只包含决策需要的字段,并对结果做必要的摘要
  2. 模型会选错工具,或者在相似工具之间犹豫——工具描述之间的重叠越多,选择越不稳定。解法:①合并功能相近的工具②描述里写清「什么时候不该用它」(边界比功能更能区分);③用工具搜索/按需加载,让模型每次只面对相关的那几个。
  3. ⭐ 四个要素:①说清哪里错了 ②说清为什么错 ③给出可执行的下一步 ④保留必要的原始信息。例:不要返回「400 Bad Request」,而要返回「参数 date 格式应为 YYYY-MM-DD,收到的是 2025/13/01;注意月份最大为 12」。好的错误信息能让模型自己修好,差的只能让它重试同样的错误。

🛑 可以停在这里

走神救援
最容易被忽略的一点:工具的返回值是给模型读的,不是给日志看的——它直接进入上下文,是下一步决策的全部依据;巨大的 JSON dump 既浪费上下文又淹没关键信息,好的返回值只包含决策需要的字段并做必要摘要工具太多时模型会选错或在相似工具间犹豫,解法:合并功能相近的、描述里写清「什么时候不该用它」(边界比功能更能区分)、按需加载。⭐好错误信息四要素:哪里错了、为什么错、可执行的下一步、保留必要原始信息——不要返回「400 Bad Request」,要返回「参数 date 格式应为 YYYY-MM-DD,收到 2025/13/01,月份最大为 12」;好的错误信息能让模型自己修好,差的只能让它重试同样的错误