Tool-Use工具调用设计
2026 字约 7 分钟
domain/aiai/agents
2026-07-24
Tool Use（工具使用）是 Agent 与外部世界交互的核心能力——让 Agent 不仅能"想"，还能"做"。通过工具调用，Agent 可以搜索信息、执行代码、查询数据库、调用 API，将语言推理转化为真实世界的行动。工具设计的质量直接决定 Agent 的能力边界。
一句话解释
工具调用让 Agent 从"只会说"变成"能做事"——搜索、计算、查数据库、调 API，全靠工具。
核心问题
为什么工具设计如此重要？
- 工具是 Agent 的"手脚"：LLM 再强，没有工具也只能生成文本
- 工具描述决定调用准确率：LLM 根据工具描述来决定用哪个工具、传什么参数——描述不清 = 调用错误
- 工具编排决定任务完成效率：顺序调用 vs 并行调用 vs 条件调用，效率差异巨大
- 错误处理决定系统可靠性：工具调用失败是常态，不是异常
工具定义规范
工具定义的三要素
每个工具需要清晰定义三个部分：
| 要素 | 说明 | 示例 |
|---|---|---|
| 名称（Name） | 工具的唯一标识，简洁有意义 | search_web, calculate, query_db |
| 描述（Description） | 告诉 LLM 这个工具做什么、什么时候用 | "搜索互联网获取最新信息，当需要实时数据时使用" |
| 参数（Parameters） | JSON Schema 定义输入参数的类型和约束 | {"query": {"type": "string", "description": "搜索关键词"}} |
三种工具描述方式
| 描述方式 | 格式 | 优势 | 劣势 |
|---|---|---|---|
| JSON Schema | 标准 JSON Schema 定义参数 | 结构化、可验证 | 对 LLM 不够直观 |
| OpenAPI Spec | OpenAPI/Swagger 规范 | 标准化、生态丰富 | 过于复杂，token 消耗大 |
| 自然语言描述 | 用自然语言描述工具功能和使用方式 | LLM 理解最直观 | 缺乏结构化约束 |
推荐实践：使用 JSON Schema 定义参数结构 + 自然语言写描述。两者结合效果最好。
工具描述的质量如何影响调用准确率
| 描述质量 | LLM 行为 | 调用准确率 |
|---|---|---|
| 清晰、具体、有使用场景 | 准确选择工具，参数正确 | >95% |
| 模糊、过于简短 | 工具选择犹豫，参数猜测 | 60-80% |
| 多个工具描述重叠 | 在相似工具间选择错误 | <60% |
| 缺少参数说明 | 参数缺失或类型错误 | 频繁调用失败 |
最佳实践：
- 描述中说明"什么时候用"和"什么时候不用"
- 参数描述要具体（
"max_results: 返回结果数量，默认 10，最大 50"而非"max_results: int"） - 工具之间的边界要清晰，避免功能重叠
工具编排策略
1. 顺序编排（Sequential）
Tool A → 结果 → Tool B → 结果 → Tool C → 最终结果适用场景：后一个工具依赖前一个工具的输出 示例：搜索 → 提取信息 → 生成报告
2. 并行编排（Parallel）
Tool A ─┐
Tool B ──┼→ 合并结果 → 最终输出
Tool C ─┘适用场景：多个工具之间无依赖关系 优势：显著降低延迟（总延迟 = max(各工具延迟)，而非 sum） 注意：部分模型/SDK 支持并行工具调用（如 OpenAI 的 parallel_tool_calls 参数），是否并行取决于模型能力与配置。务必在编排层做好幂等与竞态处理。
3. 条件编排（Conditional）
if 条件 A:
Tool A
elif 条件 B:
Tool B
else:
Tool C适用场景：根据不同情况选择不同的工具 实现：通常由 LLM 在 Thought 步骤中判断条件
4. 循环编排（Loop）
while 不满足终止条件:
Tool A → 检查结果
if 结果满意: break
Tool B（调整参数）适用场景：需要迭代优化的任务 注意：必须设置最大循环次数，防止无限循环
错误处理与降级
工具调用失败是常态，不是异常。健壮的错误处理是 Agent 可靠性的关键。
错误处理策略
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 重试（Retry） | 相同参数重新调用 | 网络超时、临时性错误 |
| 备用工具（Fallback） | 换一个功能相似的工具 | 首选工具不可用 |
| 参数修正 | 分析错误信息，修正参数后重试 | 参数格式错误 |
| 人工介入 | 请求人类帮助 | 高风险操作、无法自动恢复的错误 |
| 优雅降级 | 跳过该工具，用其他方式完成任务 | 非关键工具失败 |
错误处理流程
工具调用
├─ 成功 → 继续执行
└─ 失败
├─ 可重试错误（超时、限流）→ 重试（最多 3 次）
├─ 参数错误 → 分析错误信息 → 修正参数 → 重试
├─ 工具不可用 → 切换到备用工具
└─ 不可恢复错误 → 记录错误 → 优雅降级 / 人工介入Function Calling vs Tool Use 的概念辨析
| 维度 | Function Calling | Tool Use |
|---|---|---|
| 定义 | LLM 输出结构化的函数调用指令 | Agent 调用外部工具执行操作 |
| 范围 | LLM 层面的能力（模型原生支持） | Agent 层面的能力（系统设计） |
| 关系 | Function Calling 是 Tool Use 的实现方式之一 | Tool Use 包含 Function Calling + 工具执行 + 结果处理 |
| 代表 | OpenAI Function Calling, Anthropic Tool Use | LangChain Tools, LlamaIndex Tools |
关键区分：Function Calling 是"LLM 说它想调用什么"，Tool Use 是"整个工具调用的完整流程"。
MCP 协议对 Tool Use 的标准化影响
MCP 是什么
MCP（Model Context Protocol）是 Anthropic 于 2024 年 11 月发布的开放标准协议，被类比为"AI 应用的 USB-C 接口"。它标准化了 AI 模型与外部工具/数据源的连接方式。
MCP 解决了什么问题
在 MCP 之前，每个 AI 应用都要为每个工具单独写集成代码——N 个应用 × M 个工具 = N×M 个集成。MCP 通过标准化协议将其变为 N+M：
之前: App1 → Tool1, App1 → Tool2, App2 → Tool1, App2 → Tool2 (N×M)
之后: App1 → MCP, App2 → MCP, Tool1 → MCP, Tool2 → MCP (N+M)MCP 架构
Host（AI 应用）
└── Client（MCP 客户端）
└── Server（MCP 服务端）
├── Tools（工具）
├── Resources（数据资源）
└── Prompts（Prompt 模板）MCP 的影响
- 工具复用：一个 MCP Server 可以被任何支持 MCP 的 AI 应用使用
- 生态标准化：到 2026 年，MCP 正在快速形成 Agent 工具调用的标准化趋势（具体生态/框架支持情况以官方文档为准）
- 降低集成成本：工具提供者只需写一次 MCP Server
工具选择策略
当 Agent 有多个工具可用时，如何选择合适的工具？
| 策略 | 描述 | 适用场景 |
|---|---|---|
| LLM 选择 | LLM 根据工具描述自主选择 | 工具数量 <20，描述清晰 |
| 规则选择 | 基于规则预筛选工具 | 工具数量多，场景明确 |
| 两阶段选择 | 先用轻量模型筛选候选工具，再用 LLM 精确选择 | 工具数量 >20 |
| 动态加载 | 根据当前任务上下文动态加载相关工具子集 | 工具总量大，但每次只用一小部分 |
常见误区
- 工具描述太简短：
"search: 搜索"不是好的描述，应该说明搜索什么、什么时候用 - 工具功能重叠：两个工具做类似的事情，LLM 不知道该选哪个
- 不处理工具调用失败：假设工具一定会成功，没有错误处理
- 工具粒度过大：一个工具做太多事情，难以复用和调试
- 工具数量过多：一次给 LLM 太多工具选择，导致选择困难（推荐每次 <20 个）
可继续补充的方向
- 工具学习的自动化（Agent 自动创建新工具）
- 工具调用的安全沙箱设计
- 工具版本管理和兼容性
- 工具调用的可观测性和调试