Tool Use 工具调用：Agent 与外部世界交互的核心机制#

📌 今日速览#

模型只是”大脑”，工具才是”手脚”——这是过去 30 天学完架构、记忆、Skill、Context、Multi-Agent、评估后，第一次系统地把”Agent 如何行动”这件事讲清楚。今天从 4 篇文章里梳理出工具调用的协议层（Function Call / MCP）、形态层（Tool / Skill / Plugin）、模式层（ReAct / Plan-Execute / LATS）、防护层（Guardrails / 风险分级）四个维度。最核心的反共识观点是：工具调用不是”写个 function_call 就完事”，而是要按”用户意图”重新组织 Schema；工具描述三要素（何时调、参数怎么填、结果怎么用）决定了一个工具能不能被模型用对。

一、为什么今天聊这个？#

过去 30 天我们学完的脉络是：

• 7-23 架构演进：从 Prompt 到 Graph
• 7-24 记忆系统：Memory 分层与复用
• 7-27 Skill 技能系统：流程、约束、验收标准
• 7-28 Context Engineering：上下文决定单次决策
• 7-29 Multi-Agent：多智能体协作模式
• 7-30 / 7-31 评估与可观测性：怎么判断 Agent “能信”

但始终有一个底层问题没正面回答：模型怎么”动手”？

所有的架构、记忆、Context、Multi-Agent，最终都要靠模型”调一个外部动作”来落地——查数据库、读写文件、发邮件、调用 API。这个”动手”的能力，就是 Tool Use。它是 Agent 与外部世界交互的核心机制，是”想”到”做”的桥梁。

今天 4 篇文章从 4 个不同视角把这件事讲透了：

1. WorkBuddy 产品视角：Function Call / MCP / Skill / Plugin 共同构成能力层
2. OpenAI 官方指南：标准化工具定义、编排模式、风险分级
3. 架构对比视角：ReAct / Plan-and-Execute / LLM Compiler 工具调用机制差异
4. 设计模式视角：ReAct / Reflection / Reflexion / LATS 反思与验证机制

二、核心内容#

1
┌─────────────────────────────────────────────────┐
2
│  防护层：Guardrails / 风险分级 / max_iterations │
3
├─────────────────────────────────────────────────┤
4
│  模式层：ReAct / Plan-Execute / LATS / Reflection│
5
├─────────────────────────────────────────────────┤
6
│  形态层：Tool / MCP / Skill / Plugin            │
7
├─────────────────────────────────────────────────┤
8
│  协议层：Function Call / MCP Protocol            │
9
└─────────────────────────────────────────────────┘

1
1. 通用场景 → ReAct（基础但灵活）
2
   │
3
   ├── 想加速但保持灵活性？
4
   │   └── Plan & Execute / LLM Compiler（工具并行）
5
   │       └── 工具间需传数据？→ ReWOO
6
   │
7
   ├── 无法获取真实环境反馈？（如写文章）
8
   │   └── Basic Reflection（单次内迭代）
9
   │       └── 需跨试验学习？→ Reflexion
10
   │
11
   └── 需探索性决策？
12
       └── LATS（多路径搜索+反思+回溯）

三、4 篇文章的共同观点#

读完 4 篇，有 6 个观点是高度共识的：

1. 模型只是大脑，工具是手脚——四篇文章都强调”模型不能自己动手，必须通过工具与外部世界交互”。
2. 工具设计比工具数量更重要——WorkBuddy 强调”按用户意图组织 Schema”，OpenAI 强调”15+ 个定义清晰工具 OK，重叠的 10 个就不行”。
3. 从单 Agent 起步，按需升级——OpenAI 明确”maximize a single agent’s capabilities first”，架构对比文也警告”如果单 Agent 能解决，不要强上多 Agent”。
4. ReAct 的 Observation 是核心——即使在推崇 Plan-Execute、LLM Compiler 的作者眼里，ReAct 的”每步与现实反馈核对”仍是不可替代的。
5. 必须设置 max_iterations 和 timeout——所有文章都强调这个是”踩过的坑”。
6. 风险分级和 Guardrails 是工业级落地的必要条件——OpenAI、WorkBuddy、ANOLISA 都反复强调。

四、4 篇文章的不同视角#

最有趣的分歧：

• WorkBuddy 把 Skill 当成与 Tool 并列的形态，而 OpenAI 指南里 Skill 这个概念几乎不存在（更强调”Agent as Tool”）
• 架构对比文和设计模式文都认为 ReWOO 牺牲反馈换效率得不偿失，而 LLM Compiler 论文（DAG 并行）则被认为 3.6x 提速有效
• WorkBuddy 强调 MCP 解决”接入”但解决不了”安全”，OpenAI 则更强调用 Tool safeguards 解决安全

五、对你（产品/工程师）的行动建议#

1
            ┌─ 简单任务 ─────────→ ReAct（默认）
2
   起步 ────┤
3
            └─ 简单但要加速 ─→ Plan & Execute / LLM Compiler
4

5
            ┌─ 工具爆炸 ────→ 工具分组 + Tool Retrieval
6
   进阶 ────┤
7
            └─ 跨领域 ──────→ 多 Agent（慎重评估）
8

9
            ┌─ 写文章等无外部反馈 ─→ Basic Reflection
10
   反思 ────┤
11
            └─ 需跨试验学习 ─→ Reflexion

六、一句话总结#

工具调用不是”写个 function_call 就行”——它是一个四层体系：协议层（Function Call / MCP）解决”怎么动”，形态层（Tool / Skill / Plugin）解决”按什么形式组织”，模式层（ReAct / Plan-Execute）解决”在循环中怎么决策”，防护层（Guardrails / 风险分级）解决”动到什么程度要停下来”。

ReAct 的 Observation 是不可替代的核心范式，其他模式是它的变体或替代。 工具爆炸是真实挑战，但答案不是堆多 Agent，而是渐进式加载 + 路由分发。模型决定 Agent 的上限，工具决定 Agent 的边界。

📚 参考资料#

1. 《从模型到 Harness：WorkBuddy 如何把 Agent 做成可用产品》—— 工具调用四层抽象、MCP 三原语、Skill/Plugin 形态选择
2. OpenAI《A Practical Guide to Building Agents》—— 标准化工具定义、风险分级、Guardrails 层次化防御
3. 《AI Agent 架构设计模式：ReAct vs Plan-and-Execute vs Multi-Agent 深度对比》—— 工具爆炸、架构升级路径、五种编排模式
4. 《AI Agent 主流的设计模式（ReAct, Reflection, LATS）其实没有很复杂》—— 7 种模式工具调用机制对比、反思与验证

生成时间：2026-08-03 13<44主题>：Tool Use 工具调用覆盖文章：4 篇