Anthropic 工具执行架构系统解读：从 Think Tool 到动态发现与程序化编排

原文一：The “think” tool: Enabling Claude to stop and think in complex tool use situations

原文二：Code execution with MCP: Building more efficient agents

原文三：Introducing advanced tool use on the Claude Developer Platform

实践项目：PPT Master

前置阅读：《Writing effective tools for agents》系统解读 · 《Agent Skills》系统解读 · 《Effective context engineering》系统解读

上一篇工具解读关注的是接口契约：工具应该如何命名、描述、返回结果和提供错误信息。这里继续追问运行时问题：当 Agent 面对越来越多的工具、越来越长的调用链和越来越大的中间结果时，这些工具应该如何进入上下文，又应该由谁编排。

Anthropic 的三篇文章形成了一条清晰演进线：

工具结果出现后暂停检查
    ↓
工具定义按需发现
    ↓
用代码编排调用与处理结果
    ↓
只让决策所需信息进入模型上下文

这条线索的核心不是 MCP 本身，也不是增加一个新的工具类型，而是把工具执行拆成四个独立问题：

1. 发现：Agent 如何知道有什么工具；
2. 判断：何时需要停下来检查新信息；
3. 编排：循环、条件、并行和数据转换由模型逐轮处理，还是由代码执行；
4. 过滤：哪些中间结果需要进入模型上下文。

本文聚焦这四个问题，并严格区分 Anthropic Developer Platform 的具体能力与 PPT Master 当前采用的仓库级工作流。

一、Think Tool 的历史位置：结果后的推理检查点

Anthropic 在 2025 年 3 月发布 Think Tool 时，解决的是复杂工具链中的一个具体失败：模型已经开始执行，但从工具结果获得新信息后，没有停下来重新检查规则、缺失条件和下一步动作。

Think Tool 本身不获取新数据，也不修改外部状态。它只是让模型在工具调用过程中增加一个显式推理步骤。

原文把它与当时的 extended thinking 区分开：

机制	主要时机	解决的问题
Extended thinking	开始生成响应之前	形成完整计划和整体推理
Think Tool	已经开始执行、收到工具结果之后	检查新信息、政策约束和顺序决策

它最适合三类任务：

• 需要仔细分析前序工具输出；
• 规则密集，需要逐项验证合规性；
• 每一步依赖前一步，错误代价较高。

相反，简单单次调用、彼此独立的并行调用和普通指令执行通常不会从它获得收益，还会增加 prompt 和输出 token。

不能忽略 2025 年 12 月的更新

原文顶部后来增加了一项重要更新：随着 extended thinking 改进，Anthropic 建议 大多数情况优先使用 extended thinking，而不是专用 Think Tool。原因是两者提供类似的思考空间，但 extended thinking 的集成和性能更好。

因此，Think Tool 今天更适合作为一个历史架构样本：它证明复杂工具链需要“在结果后重新判断”的能力，但不再代表 Anthropic 对多数新系统的默认实现建议。

这条时间边界必须保留。只读文章初始实验而忽略后续更新，会把一个阶段性技术重新包装成当前最佳实践。

二、工具规模扩大后，问题从调用变成发现

直接工具调用通常把所有工具定义放进模型上下文。工具只有几个时，这很简单；连接多个 MCP server 后，定义本身可能在用户提出问题前就占据大量 token。

Anthropic 在 Advanced Tool Use 文章中给出一个五服务器示例：58 个工具约占 55K token；加上更多服务后很快接近 100K，内部观察到的优化前定义规模甚至达到 134K token。

上下文成本之外还有选择问题。名称接近的工具越多，模型越容易选错工具或传错参数。

Tool Search Tool：把完整定义延迟到需要时

Anthropic 的 Tool Search Tool 允许把工具标记为 defer_loading: true。启动时只加载搜索工具和少量高频核心工具；当 Claude 需要某项能力时，先检索匹配工具，再把对应完整定义展开进上下文。

其设计原则是：

• 常用的三到五个工具可以始终加载；
• 大多数工具按需发现；
• 工具名称和描述必须足够清晰，因为搜索依赖这些字段；
• 小工具集不一定值得多一次搜索延迟。

官方示例中，传统方式预先加载约 72K token 的工具定义，Tool Search 只加载约 500 token 的搜索工具和少量匹配定义；总初始占用从约 77K 降到 8.7K。

这些数字来自特定内部配置，不能当作任何工具库都能复现的固定比例，但它们清楚说明了优化对象：没有被本次任务使用的工具，不应该先占据本次任务的注意力预算。

三、文件系统发现：Code Execution with MCP 的另一条路径

在 Advanced Tool Use 发布前，Anthropic 已在 Code Execution with MCP 中提出另一种按需发现方式：把 MCP server 暴露为代码 API，并为工具生成文件树。

Agent 可以先列出 server 目录，再只读取当前需要的函数文件和接口定义。例如它只加载 Google Drive 的 getDocument 与 Salesforce 的 updateRecord，而不是读取两个 server 的所有工具定义。

这是一种文件系统上的渐进式披露：

服务器目录
    ↓
相关工具文件名
    ↓
必要工具的签名与返回结构
    ↓
执行代码

原文示例称，这种方式把工具定义相关消耗从 150K token 降至 2K。它与后来的 Tool Search Tool 解决同一个问题，但位置不同：

• Tool Search Tool 是 Developer Platform 提供的动态工具发现能力；
• 文件树方案是 Agent 在代码执行环境中导航工具接口；
• 两者都避免把完整工具库一次性装入上下文。

这种“只读目录，再读具体文件”的方法，也与 Agent Skills 的渐进式披露相呼应。但 Skill 发现的是任务知识与工作流，Tool Search 发现的是可调用接口，不能把二者混称为同一个平台能力。

四、Programmatic Tool Calling：让代码承担确定性编排

传统工具调用每执行一次工具，就把结果返回模型；模型阅读结果、决定下一步，再发起下一次调用。复杂工作流由此产生两个成本：

1. 每次工具调用都触发新的模型推理往返；
2. 所有中间结果都不断堆积在上下文中。

Programmatic Tool Calling 让 Claude 编写一段代码，在 sandbox 中调用多个已授权工具。循环、条件、并行请求、聚合、过滤和错误处理由代码显式执行，只有代码最终输出进入 Claude 上下文。

为什么代码比自然语言更适合编排

假设需要检查一个团队谁超出差旅预算。自然语言调用会依次获取人员、每个人的费用明细和各级预算，再让模型手工求和比较。程序化方式则可以：

• 并行获取预算与费用；
• 用字典建立级别到预算的映射；
• 在代码中求和和筛选；
• 最后只输出超额人员。

Anthropic 的示例让 200KB 原始明细在执行环境中完成处理，只把约 1KB 最终结果交给模型。其内部复杂研究任务的平均 token 使用从 43,588 降到 27,297，约下降 37%。

Programmatic Tool Calling 最适合：

• 大数据集只需要聚合或摘要；
• 存在三个以上相关工具调用；
• 结果需要过滤、排序、连接或转换；
• 大量同构操作可以并行；
• 中间数据本来就不应影响模型的语义判断。

它不适合简单查询，也不适合模型必须看到全部中间证据并作语义判断的任务。

关键边界

代码适合执行已经确定的控制流，模型适合决定控制流应该是什么。

如果“过滤什么”本身就是研究结论，把过滤交给代码可能会提前删除重要证据。

五、中间结果不是越少越好，而是要分流

后两篇关于代码执行与高级工具使用的文章反对无差别地把中间结果全部送入模型上下文；Think Tool 则补充了另一条边界：会改变后续判断的工具结果仍应由模型重新审视。因此，目标不是只保留最终答案，而是按决策需要分流。

更准确的做法是把结果分成三类。

1. 必须进入上下文的结果

会改变下一步语义决策的信息应当进入模型，例如：

• 来源之间的实质冲突；
• 一项检查失败的完整原因；
• 需要模型权衡的异常样本；
• 用户要求保留的证据与限定条件。

2. 应留在执行环境的结果

只参与确定性运算的数据不必进入模型，例如：

• 数千行明细中的求和过程；
• 对大量端点执行相同健康检查的原始响应；
• 文件复制、格式转换和哈希比较的内部步骤；
• 已明确规则下的筛选、排序和连接。

3. 应持久化为制品的结果

后续阶段可能需要追溯，但当前决策不必全部读取的信息适合写入文件，例如：

• 完整报告；
• 结构化 JSON；
• 运行日志；
• 可恢复的中间状态；
• 后续工具需要直接消费的数据文件。

模型收到的可以只是状态、摘要与路径。需要追溯时，再定向读取拥有该事实的制品。

这三分法比统一的“简洁输出”更准确，因为压缩的目标不是让信息消失，而是让信息进入正确通道。

六、Tool Use Examples：结构合法不等于调用正确

Advanced Tool Use 还包括 Tool Use Examples。JSON Schema 可以约束字段类型、必填项和枚举，却无法完整表达日期格式、ID 约定、可选字段组合和不同参数之间的业务关系。

input_examples 通过少量真实样例补足这部分行为语义。Anthropic 建议：

• 每个工具只保留一到五个高信号例子；
• 覆盖最小、部分和完整参数组合；
• 只示范 schema 无法表达的歧义；
• 简单单参数工具不必增加样例。

这与工具发现和程序化编排是互补关系：发现解决“选哪个”，示例解决“怎么传”，代码编排解决“多个调用如何组合”。

本文不继续展开参数设计，因为这属于上一篇《Writing effective tools》的接口契约主题。

七、代码执行也引入新的成本

把工具变成代码 API 并不自动更安全。

Code Execution with MCP 明确要求安全执行环境，包括 sandbox、资源限制和监控；它还展示了通过 harness 对敏感数据做 tokenization 和确定性流向约束。Advanced Tool Use 则通过 allowed_callers 让工具显式选择是否允许被程序化调用。

程序化调用还扩大了单次执行的影响范围。一段循环可以高效处理一万行，也可以高效地执行一万次错误写操作。因此，高效编排必须与幂等性、重试边界和最小权限一起设计。

文件持久化同样有双面性：它支持恢复和复用，也会产生过期状态、隐私边界和清理责任。

所以直接工具调用、Tool Search 和代码执行不是能力高低关系，而是不同成本模型。

八、PPT Master 的工具发现：文档路由，不是 Tool Search API

PPT Master 当前采用项目级 Skill 和确定性路由：

1. SKILL.md 提供全局纪律与入口；
2. workflows/routing.md 选择一个顶层制品路线；
3. 只读取该路线的 runtime authority；
4. 根据明确触发条件继续加载 supporting documents；
5. 不读取未选路线、未触发样式或无关工具文档。

例如，在 Default Generate 中，只有实际存在 web / ai 资源行时才加载 image search / image generation 文档；Executor 再按 lock 中的 mode、visual style 和条件模块加载执行说明。Quick 不创建这些规划行或 lock，而是依据当前活动上下文中已经决定的资源类型与设计方向加载所需文档。

这个机制与 Tool Search 的共同目标是控制定义和说明的上下文成本，但实现层次不同：

• PPT Master 使用静态文件路由和明确触发器；
• Anthropic Tool Search 使用 API 中的 deferred tool definitions；
• PPT Master 当前没有实现 defer_loading、BM25 Tool Search 或 Programmatic Tool Calling beta。

因此可以说 PPT Master 采用了 按需加载思想，不能说它已经使用 Anthropic 的 Advanced Tool Use 功能。

九、PPT Master 的程序化编排：确定性脚本拥有机械步骤

PPT Master 并不是 MCP 客户端教程中的代码 API 架构，但已经把许多确定性控制流交给 Python 脚本。

source_to_md.py 统一分派

Agent 把文件、URL 或目录交给统一入口。脚本检测类型，再路由到 PDF、DOCX、XLSX、PPTX 或网页后端。常规路径不需要模型先逐个判断应该调用哪个转换器。

project_manager.py 管理项目生命周期

项目初始化、源文件导入、验证与 page-context 诊断通过稳定子命令暴露。目录创建、复制边界、分析制品和 schema 验证由代码完成，而不是让模型手写一连串文件操作。

质量检查器一次返回完整问题集

svg_quality_checker.py 扫描全部目标页面并生成结构化报告。模型负责选择如何修复，检查器负责确定性发现事实。在 Default Generate 中，成功时只使用退出状态与终端摘要；失败时先审阅该次未过滤的完整终端问题集，只有终端输出被截断时才从同一次 JSON 报告中定向读取 blocking，并按需读取 introduced。Quick 同样写入结构化报告，但当前合同只明确要求修复全部 blocking error 后重跑。

这些都符合“代码执行确定性流程，模型处理开放判断”的原则，但与 Programmatic Tool Calling 仍有区别：它们是仓库内预先设计的 CLI，并不是 Claude 在 Developer Platform sandbox 中动态编写代码调用一组 API 工具。

十、PPT Master 如何控制中间结果进入上下文

当前工作流存在多处明确分流。

中间结果	当前处理方式	上下文目的
PPTX 身份与受支持的原生结构事实	每个 deck 写独立 identity/slide-library JSON，并生成紧凑 source_profile.json 索引	先读摘要，需要时再打开具体 deck
图片事实	images/ 为真实源，analysis/image_analysis.csv 为可再生视图	从元数据决策，只检查有歧义的具体图片
SVG 质量报告	完整 JSON 写入 validation/	Default 成功只用摘要，失败先审阅终端完整问题集、截断时才读 JSON 字段；Quick 明确要求修复全部 blocking error 后重跑
page-context	只在明确诊断或遥测时投影	不成为每页例行加载门
工作流记录	validation/workflow.log 只保留命令信封、有限结果和重要事件	冷审计证据，正常生成不读取
Design Spec 与 lock	Default Generate 持久化规划与执行锚点；Quick 不创建这两份规划制品	Default 的跨阶段、跨会话恢复不依赖聊天转述；Quick 不保存可恢复的内容与设计决策

这里最重要的不是“所有输出都简短”，而是每份信息都有拥有它的通道：事实摘要、完整报告、执行锁和审计记录不能互相替代。

十一、PPT Master 没有专用 Think Tool

当前 PPT Master 没有定义一个名为 think 的外部工具，也没有把内部推理写入日志。

它使用的是另一类机制：

• 路由前检查输入形态；
• 阶段入口验证 prerequisites；
• 高风险或用户决策处设置 gate；
• P01 后先识别方法级偏差；
• 工具失败时回到 owning artifact 修复；
• 通过 schema、检查器和 postflight 接收环境反馈。

这些机制会迫使执行过程在关键节点重新判断，但它们是工作流门与环境验证，不是 Think Tool，也不是 extended thinking 的实现。

这个区别值得保留：显式检查点可以约束行为，却不能声称拥有某种模型推理能力。

十二、官方机制与 PPT Master 的准确对照

Anthropic 概念	PPT Master 当前对应	状态边界
Think Tool	关键阶段 gate、失败回源和环境检查	目标相邻，但没有专用 Think Tool
Tool Search Tool	Skill 路由、索引与条件式 reference load	静态文件路由，不是 API deferred tool search
Filesystem tool discovery	Agent 读取 Skill、workflow、script docs	面向仓库能力，不是 MCP server 函数树
Programmatic Tool Calling	统一 CLI 与确定性 Python 脚本	预建工具编排，不是运行时动态 PTC
中间结果留在执行环境	报告落盘；Default 成功使用摘要、失败审阅终端完整问题集，截断时定向读取报告字段；Quick 修复全部 blocking error 后重跑	各 profile 的输出纪律不同
文件化状态	Default 的 Design Spec/lock，以及各路线按合同产生的分析 JSON/CSV、validation 报告	路线间制品覆盖不同；Quick 没有可恢复的规划状态
Tool Use Examples	CLI 文档、schema、模板与用法示例	不使用 Developer Platform input_examples 字段

这张表避免两种错误：一是因为目标相似就声称功能等同；二是因为没有使用同一个 API，就忽略仓库已经建立的架构原则。

十三、选择执行方式的最小判断框架

直接工具调用

适合：

• 工具数量少；
• 单次查询；
• 返回值很小；
• 模型需要完整阅读结果。

按需工具发现

适合：

• 工具定义已明显占用上下文；
• 存在十个以上工具或多个 MCP server；
• 工具选择错误开始成为主要失败来源；
• 大部分工具在单次任务中不会被使用。

程序化工具编排

适合：

• 三个以上相关调用；
• 大量同构操作；
• 需要循环、条件、聚合和过滤；
• 中间数据不需要模型逐项理解；
• 执行环境有可靠 sandbox 和权限边界。

推理检查点

适合：

• 新工具结果可能改变原计划；
• 规则密集；
• 顺序错误代价高。

在当前 Claude 能力下，应先考虑 extended thinking 或工作流中的明确检查节点；只有特定旧模型或经过评估的应用才有理由重新引入专用 Think Tool。

十四、我的理解：上下文应该承载决策，不应承载搬运

把三篇文章放在一起看，工具执行架构可以概括为三层：

第一层：只发现当前需要的能力

完整工具库保留在外部。上下文先得到足够选择工具的元数据，需要时再读取完整定义。

第二层：让代码处理确定性控制流

循环、条件、并行请求、求和、筛选和格式转换不必逐轮经过模型。模型决定目标和边界，代码执行已确定的过程。

第三层：让模型只看到会改变判断的信息

原始数据可以留在 sandbox，完整报告可以落盘，路径和摘要可以进入上下文；当异常需要语义判断时，再读取拥有该事实的部分。

核心观点

工具执行优化的目标不是减少信息，而是减少无须由模型搬运的信息。

PPT Master 当前最接近这条原则的地方，不是某一个脚本，而是其整体分工：Skill 决定读取什么，workflow 决定何时调用，Python 负责机械执行，各路线按合同保留派生制品与报告。Default 另以 Design Spec 和 lock 保存可恢复的规划状态；Quick 的内容与设计决策仍依赖活动上下文。模型只在选择、设计、异常和权衡处参与。

它尚未采用 Anthropic 的 Tool Search Tool 或 Programmatic Tool Calling，也不需要为了概念对齐而立即引入。只有当真实运行出现工具定义膨胀、错误选择或大规模中间结果污染时，才应该根据具体瓶颈选择对应机制。

参考来源

• Anthropic，2025-03-20，2025-12-15 更新：The “think” tool
• Anthropic，2025-11-04：Code execution with MCP: Building more efficient agents
• Anthropic，2025-11-24：Introducing advanced tool use on the Claude Developer Platform
• PPT Master 当前实现快照（4e6ecbc）：Skill 入口、路由规则、Generate 工作流

← 返回 Anthropic 学习地图