工具太多、上下文先爆？Anthropic「高级工具使用」三件套在解决什么Agent 侧的未来很可能是成百上千个工具同时在

Agent 侧的未来很可能是成百上千个工具同时在线：IDE 一串、运维又一串 MCP。麻烦在于：若把工具定义全塞进首轮上下文，用户话还没读完，token 先烧光，选错工具、乱填参数的概率也跟着上去。[1]

2025 年 11 月，Claude 开发者平台上线三项 Beta：Tool Search Tool、Programmatic Tool Calling、Tool Use Examples——分别对应「按需发现」「代码里编排」「示例教惯例」。目标是把「无限工具库」从口号变成可工程化的组合拳。[1]

结构速写

主线：上下文矛盾 → 三项 Beta 是什么 → 内测数字与边界 → 对你栈 意味着什么。
深度：文内 ### 深度解析 与 官方叙事与可核对事实；文末 结论与讨论 与 延伸阅读。

一、先把矛盾说清楚：工具多 ≠ 能帮上忙

1.1 图书馆 vs 背包（比喻）

传统做法：去图书馆前，把可能用到的几百本书全文复印背在背上——还没开始读书，背包（上下文）满了。
理想状态：身上只带目录卡 + 检索，进到相关书架再抽出当下要用的几本——这就是「按需发现工具」的精神。[1]

Anthropic 在此前 code execution with MCP 等文章里也讨论过：工具定义与结果有时一开聊就吃掉 50,000+ token；企业内部甚至出现过优化前工具定义约占 134K token 量级的案例叙述。[1][2]

1.2 另外两个「隐形税」

自然语言一步步调工具：每次调用往往伴随一整轮推理；中间结果无论有用没用，都可能堆进上下文。[1]
只靠 Schema：能说明「结构上合法」，却很难说明惯例——可选字段何时填、日期格式、嵌套对象何时展开、相似工具该选谁。[1]

二、Tool Search Tool：按需搜工具，别把全村搬进 prompt

2.1 原文里的「五台 MCP」算账（帮助你建立数量级直觉）

示例配置（节选意译）：GitHub 约 35 个工具 ~26K tokens；Slack 11 个 ~21K；再加 Sentry、Grafana、Splunk……58 个工具约 55K tokens，对话还没开始就出去了；若再加 Jira 等，十万级 overhead 很快到。[1]

官方对比（数字来自原文）：

方式	大致效果（原文）
传统：全部定义预加载	50+ MCP 工具约 72K 仅定义；合计开工前约 ~77K token
Tool Search Tool	预载仅搜索工具约 ~500 token；按需加载 3–5 个相关工具约 ~3K；开工前合计约 ~8.7K
小结	宣称约 85% token 节省；并提到「相对传统方式保留约 191,300 vs 122,800 tokens 可用上下文」一类对比（以官网图表/更新为准）。[1]

准确率（内部 MCP 评测叙述）：Opus 4 约 49% → 74%；Opus 4.5 约 79.5% → 88.1%（启用 Tool Search Tool）。[1]

2.2 机制（人话）

你把「全量工具」仍交给 API，但对工具打 defer_loading: true：延迟加载，不进首轮上下文。
首轮里模型先看到 Tool Search Tool 本身 + 你设为 不延迟 的「高频核心工具」。
需要能力时，模型先搜索，命中后再把少量完整定义展开进上下文。[1]
Prompt caching：延迟工具根本不在初始 prompt，核心 system / 常驻工具仍可缓存——原文强调这与缓存不打架。[1]

MCP 整伺服器 defer：可对某个 MCP default_config 设 defer_loading: true，但对个别高频工具单独 defer_loading: false（例如 Drive 里只常搜文件）。[1]

搜索实现：平台提供 regex、BM25 等开箱；也可自定义（如 embedding 检索）。[1]

2.3 何时用 / 不太值得（原文 trade-off）

更适合：工具定义 >10K tokens；选工具经常错；多 MCP；10+ 工具。[1]
ROI 较低：工具库很小（<10）；几乎每个会话都会用到全部工具；定义本身很瘦。[1]

代价：多了一步搜索，latency 与复杂度换上下文与准确率——要自己算账。[1]

深度解析：Tool Search 与缓存、P99 延迟

事实：defer_loading 与 Tool Search 为平台能力；原文给出 token 与准确率对比叙述。原文观点：显著省上下文、改善选工具准确率。本文解读：生产上要同时盯 P99 延迟（多一次检索步）与 缓存命中——若高频工具被误 defer，可能反而抖动；「常驻 3～5 个高频工具」是运维决策，不是纯默认。

三、Programmatic Tool Calling：用代码当「搅拌机」，别让每滴汁都进模型嘴里

3.1 两大传统痛点（原文）

中间结果污染上下文：例如分析 10MB 日志，整文件可能涌进窗口；跨表拉客户数据，每条记录都可能堆积——真正要的可能只是一张汇总表。[1]
推理与「肉眼拼结果」开销：五步工具流 ≈ 五次完整推理加模型逐段阅读理解、对齐、综合——慢且易错。[1]

3.2 方案：在代码执行沙箱里编排

模型写 Python（异步） 去 await 多个工具、循环、过滤、聚合；工具返回先进沙箱里的脚本，由脚本加工；只有最终结果（如 print(json.dumps(...))）回到模型上下文。[1]

中文业务故事（改编自原文差旅预算例）：

问：「三季度哪些工程师差旅超标？」

传统：拉 20 人名单 → 每人拉一堆报销行 → 预算档位再查 → 上千行明细塞满上下文，模型还要心算汇总。
PTC：同逻辑用一段 asyncio.gather 并行拉数、循环判断，stdout 只吐出 2～3 个超标人；中间 2000+ 行不进模型——原文写可从约 200KB raw 数据压到约 1KB 结果量级叙述。[1]

3.3 原文披露的「硬指标」（内部测试叙述）

Token：复杂研究任务平均 43,588 → 27,297，约 37% 下降。[1]
准确率：内部知识检索约 25.6% → 28.5%；GIA 基准约 46.5% → 51.2%。[1][3]
延迟：很多工具可在同一代码块编排，减少「每步回模型」的推理往返。[1]

3.4 配置要点（概念）

启用 code execution 工具；对允许被代码调用的业务工具设 allowed_callers 指向代码执行工具类型。[1]
API 把工具定义映射成 Python 可调用形式；工具请求里带 caller 标明来自哪次 code execution。[1]

3.5 何时用 / 不太值得

更适合：大数据只要聚合/摘要；≥3 步且有依赖的工具链；要先过滤、排序、变换再给模型看；并行扫很多对象（如 50 个 endpoint）；中间细节不应影响模型推理。[1]
不太适合：单次简单调用；模型本应看到并利用全部中间结果；小响应快速查询。[1]

产品案例（原文）：Claude for Excel 用 PTC 处理成千上万行表格读写而不撑爆上下文。[1]

四、Tool Use Examples：Schema 说「合法」，Example 说「像真人那样用」

4.1 Schema 答不上来的问题（原文精神）

日期到底是 YYYY-MM-DD 还是别的？
reporter.id 是 UUID 还是 USR-12345？
嵌套 contact、escalation 什么时候该填？
priority 与 escalation.sla 的组合惯例？[1]

4.2 做法：在工具上挂 `input_examples`

提供 1～5 个高质量示例：真实风格的标题、标签、联系人；覆盖 最小必填、部分字段、全套严肃工单等模式。[1]

内部测试叙述：复杂参数处理准确率约 72% → 90%。[1]

4.3 何时用

更适合：深嵌套、多可选参数、域内惯例重、多工具易混淆。[1]
不太适合：单参数直给；URL/邮箱等模型已熟的标准格式；用 Schema 约束就能封死的情况。[1]

注意：示例会吃掉一些 token——要衡量准确率收益 vs 成本。[1]

五、组合拳：官方 Best practices 压缩版

原文建议 按最大瓶颈单点突破，再叠加：[1]

你的痛点	先上哪张牌
工具定义把上下文撑爆	Tool Search Tool
中间结果太大、步骤太多	Programmatic Tool Calling
参数老错、调用形态不稳	Tool Use Examples

Tool Search 配套：name / description 要像检索关键字一样写清楚；system prompt 里告诉模型有哪些大类能力、鼓励先搜索；保留 3～5 个最高频工具常驻，其余 defer。[1]

PTC 配套：在 description 里写清返回结构（字段名、类型、枚举），方便生成解析代码；优先把可并行、可幂等的操作放进代码编排。[1]

Examples 配套：示例要真实感；少而精；专门覆盖 歧义点。[1]

六、技术硬核小结（给架构师扫一眼）

flowchart TB
  subgraph prob [Problems]
    P1[Tool_defs_bloat]
    P2[Intermediate_results_bloat]
    P3[Schema_vs_conventions]
  end
  subgraph sol [BetaFeatures]
    S1[Tool_Search defer_loading]
    S2[PTC_code_execution allowed_callers]
    S3[input_examples]
  end
  P1 --> S1
  P2 --> S2
  P3 --> S3

defer_loading：控制「谁先出现在上下文中」。
Tool Search：「发现层」；PTC：「执行与归约层」；Examples：「调用规范层」——三层互补。[1]

接入（概念）：请求带 beta 头例如 advanced-tool-use-2025-11-20（以当前官方文档为准）；具体字段名、类型版本号以 Claude 开发者文档为准。[1]

七、重要指标与验收思路（把「官方内测叙述」变成你的检查表）

以下内容来自 Anthropic 文章中的内部测试叙述，非对你业务的承诺；上线请以自测为准。

维度	可关注的量（原文或引申）
上下文	工具定义开工前 token：是否从十万级压到万级/千级 [1]
选工具准确率	大型工具库场景下 MCP eval 是否改善（文中有 Opus 系列数字）。[1]
PTC token	复杂任务平均 token 是否明显下降（文中 ~37% 叙述）。[1]
任务准确率	检索类、GIA 等是否略升（文中给出区间）。[1]
Examples	复杂参数错误率是否下降（文中 72→90 叙述）。[1]
工程侧	增加搜索/代码执行步后的 P99 延迟、失败重试、沙箱安全是否可接受（延伸）

八、思辨延伸（非 Anthropic 结论）

「defer」本质是产品治理：谁配常驻、谁该被搜出来，是业务优先级问题，不是纯技术开关。
PTC 把 bug 从 prompt 搬到代码：要写清返回 schema、监控沙箱、防危险的批量副作用（权限与幂等仍要你拍板）。
示例会固化偏见：坏示例比没示例更糟——要当时效性版本化的「活文档」。
与 MCP 生态：工具爆炸主要来自多服务器；Tool Search + 按伺服器 defer 是企业落地时最该先画的一张图。

官方叙事与可核对事实：内测数字与「你的业务」

事实：文内准确率、token 降幅等多为 Anthropic 内部测试叙述。原文观点：三能力可组合，beta 头与字段以文档为准。本文解读（推断）：勿把文中百分比直接当成你的 SLA——需用自家工具库、自家延迟分布复测；GIA 等基准与 arXiv 论文相关，见参考文献。

九、延伸阅读与官方入口

文内 Getting started 指向平台文档与 cookbook（Tool Search、PTC、Tool Use Examples 分册）；实现细节与 beta 头以线上文档为准。[1]

致谢段提到的业界启发（原文列举）：LLMVM、Cloudflare Code Mode、Code Execution as MCP 等——此处不展开，有兴趣请读原文 Acknowledgements。[1]

结论与讨论

技术坐标

三项 Beta（Tool Search、Programmatic Tool Calling、Tool Use Examples）把「工具调用」从 schema 合法 推进到 可发现、可编排、可对齐惯例——在平台工程上接近 「工具层的编译器与链接器」 分工。

批判性问题

内测数字是否已在你的 MCP 组合与数据规模上复现？
PTC 把逻辑放进沙箱代码——副作用与审计是否已建模？
示例库是否会 固化错误惯例——谁维护版本与负例？

独立判断（事实 / 原文观点 / 本文解读）

类型	内容
事实	原文 URL；与 code-execution-with-mcp 的关联；beta 头以文档为准。
原文观点	三能力解决定义膨胀、中间结果膨胀、惯例缺失。
本文解读	最大工程决策是 defer 策略（谁常驻、谁被搜）与 allowed_callers 安全边界——比多写一个 example 更敏感。

若与 Claude 平台最新文档冲突，以官方文档为准。

参考文献与延伸阅读

[1] Introducing advanced tool use — 原文
[2] Code execution with MCP
[3] GIA 基准（arXiv）
Claude 工具文档 — Tool Search（路径以官网为准）
若还不熟 MCP：可先读 MCP 介绍，再读本篇三项 Beta。

工具太多、上下文先爆？Anthropic「高级工具使用」三件套在解决什么