AI Agent工具调用：让AI真正动手干活

模型不是一口气输出答案，而是：

1. 先**想**（Reasoning）：我该做什么？
2. 再**做**（Acting）：调用工具执行
3. 然后**看**（Observation）：工具返回了什么？

4. 继续想：下一步该干嘛？

这种模式的好处是透明可控——你能看到AI每一步在想什么、做了什么，出了问题可以精准定位。

ReAct的局限：

• 每一轮都需要模型推理，Token消耗大，速度慢
• 工具定义需要写进Prompt，模型上下文窗口有限
• 多工具协同复杂，容易"想偏"

2.2 Function Calling：原生工具调用能力

2023年6月，OpenAI在GPT-3.5/4中推出了Function Calling，这是目前最主流的工具调用方案。

和ReAct不同，Function Calling不是靠Prompt技巧实现的，而是模型原生支持的能力。

工作原理：

第一步：定义工具

你用JSON Schema告诉模型有哪些工具可用：

{
  "name": "get_weather",
  "description": "获取指定城市的天气信息",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称，如'北京'"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "温度单位"
      }
    },
    "required": ["city"]
  }
}

第二步：模型自动决定调用

用户问"北京天气怎么样"，模型不会瞎编一个答案，而是返回：

{
  "name": "get_weather",
  "arguments": {"city": "北京", "unit": "celsius"}
}

第三步：你的代码执行工具，把结果喂回模型

你的程序拿到这个调用请求，真正去调天气API，拿到结果后把结果作为tool角色消息传回模型，模型基于真实数据生成最终回答。

Function Calling的优势：

• 模型经过专门训练，工具调用准确率高
• 支持**并行调用**——一次可以调多个工具
• 参数提取精准，不容易出格式错误
• 各大模型厂商纷纷跟进（Claude、Gemini、通义千问都支持了）

Function Calling的局限：

• 每个工具都要写JSON Schema定义，开发成本高
• 工具数量多了（>20个），模型选择准确率下降
• 不同模型的Function Calling格式不统一，迁移成本大

2.3 MCP协议：工具调用的"USB接口"

2024年底，Anthropic推出了MCP（Model Context Protocol），试图解决工具调用的标准化问题。

痛点是什么？

现在每个AI应用要接入工具，都得自己写一套集成代码。接GitHub要写一套，接Slack要写一套，接数据库又要写一套。N个模型 × M个工具 = N×M个集成，维护成本爆炸。

MCP的思路：

定义一个统一协议，让工具提供方只需要实现一次MCP Server，任何支持MCP的AI应用（MCP Client）都能直接调用。

就像USB-C一样——你不需要为每个设备买不同的线，一根线通吃。

MCP的架构：

AI应用（MCP Client）
    ↕ MCP协议（JSON-RPC over stdio/SSE）
MCP Server（工具提供方）
    ↕ 
实际工具/API（GitHub、数据库、文件系统...）

MCP Server暴露三类能力：

• **Tools**：可执行的操作（创建文件、发消息、查询数据）
• **Resources**：可读取的数据（文件内容、数据库记录）
• **Prompts**：预定义的提示词模板

MCP的优势：

• 一次开发，到处使用——工具提供方不用为每个AI平台写适配
• AI应用即插即用——装个MCP Server就能用新工具
• 社区生态快速扩张（已有数百个开源MCP Server）

MCP的局限：

• 协议还在快速迭代，稳定性待验证
• 安全性挑战——MCP Server能执行任意代码，需要严格的权限控制
• 目前主要是本地部署场景，云端多租户方案还不成熟

---

三、三种方案怎么选？

维度	ReAct	Function Calling	MCP

适用场景	复杂推理链、多步任务	标准化API调用	多工具集成、跨平台

开发成本	低（纯Prompt）	中（需写Schema）	高（需实现Server）

调用准确率	中	高	高

生态成熟度	成熟	最成熟	快速发展中

Token消耗	高	中	低

实战建议：

• **快速验证想法**：用ReAct，写个Prompt就能跑
• **生产级应用**：用Function Calling，准确率和性能都有保障
• **需要接入大量外部工具**：考虑MCP，长期维护成本更低

---

四、工具调用的工程实践要点

4.1 工具描述是灵魂

模型选不选对工具，80%取决于你的工具描述写得好不好。

差的描述：

"get_data": "获取数据"

好的描述：

"get_sales_data": "查询指定时间段和区域的销售额数据。返回JSON格式，包含date、region、amount字段。当用户询问销售业绩、营收数据、月度对比时使用此工具。"

描述要包含：

• 这个工具**做什么**
• **什么时候**该用它（触发条件）
• 返回数据的**格式**
• 边界情况（什么情况下**不该**用）

4.2 错误处理不能少

工具调用失败是常态——API超时、参数错误、权限不足。你的代码必须：

1. 捕获工具执行异常
2. 把错误信息**作为Observation返回给模型**
3. 让模型决定重试还是换方案

千万不要工具报错了就整个Agent崩溃，那用户体验是灾难。

4.3 控制调用深度

不设限制的话，模型可能陷入死循环——反复调用同一个工具，或者在工具之间来回跳转。

必须设置：

• 最大调用轮次（建议5-10轮）
• 单轮最大工具数（建议3-5个）
• 超时机制（单次调用不超过30秒）

4.4 安全红线

工具调用意味着AI能执行真实操作，安全问题必须前置：

• **只读操作**可以自动执行（查询、搜索）
• **写入操作**必须人工确认（删除、发送、支付）
• **敏感操作**必须审计日志（涉及金额、权限变更）
• 永远不要把API密钥、数据库密码直接暴露给模型

---

五、实战案例：一个能查天气+搜新闻的Agent

来看一个完整的Function Calling实现（Python + OpenAI）：

import openai
import requests
import json

# 定义工具
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取城市天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名"}
                },
                "required": ["city"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "search_news",
            "description": "搜索指定主题的最新新闻",
            "parameters": {
                "type": "object",
                "properties": {
                    "topic": {"type": "string", "description": "搜索主题"},
                    "limit": {"type": "integer", "description": "返回条数，默认5"}
                },
                "required": ["topic"]
            }
        }
    }
]

def handle_tool_call(tool_call):
    """执行工具调用并返回结果"""
    name = tool_call.function.name
    args = json.loads(tool_call.function.arguments)
    
    if name == "get_weather":
        # 实际调用天气API
        return {"city": args["city"], "temp": "25°C", "condition": "晴"}
    elif name == "search_news":
        # 实际调用新闻API
        return {"topic": args["topic"], "results": ["新闻1", "新闻2"]}

def chat(user_message):
    messages = [{"role": "user", "content": user_message}]
    
    response = openai.chat.completions.create(
        model="gpt-4",
        messages=messages,
        tools=tools
    )
    
    # 检查模型是否要调用工具
    if response.choices[0].message.tool_calls:
        for tool_call in response.choices[0].message.tool_calls:
            result = handle_tool_call(tool_call)
            messages.append(response.choices[0].message)
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": json.dumps(result)
            })
        
        # 让模型基于工具结果生成最终回答
        final = openai.chat.completions.create(
            model="gpt-4",
            messages=messages
        )
        return final.choices[0].message.content
    
    return response.choices[0].message.content

# 测试
print(chat("北京今天天气怎么样？"))
# 输出：北京今天天气晴朗，气温25°C，适合户外活动。

这个例子展示了完整的工具调用流程：用户提问 → 模型决定调工具 → 执行工具 → 结果返回模型 → 生成最终回答。

---

六、工具调用的未来趋势

1. **多模态工具**：不只是文本API，还能调用图像生成、语音合成、视频处理工具
2. **自主工具发现**：模型自己搜索、安装、学习使用新工具，不需要人工预定义
3. **工具组合编排**：复杂任务自动拆解成多个工具调用的DAG（有向无环图）

4. 安全沙箱：工具执行在隔离环境中运行，防止恶意操作

---

写在最后

工具调用是AI Agent的核心能力，没有工具调用的Agent就像没有手的大脑——想得再好也干不了活。

ReAct给了AI"边想边做"的思维框架，Function Calling让工具调用变成模型的原生能力，MCP则在解决工具生态的标准化问题。三者不是替代关系，而是互补演进。

想真正上手实践？

我整理了一份AI Agent工具调用代码包，包含：

• ReAct Agent完整实现（Python）
• Function Calling最佳实践模板
• MCP Server开发脚手架
• 10个常用工具的Schema定义

👉 回复【工具调用】，免费获取代码包

觉得这篇文章有用？加入我的知识星球，每周分享AI Agent实战案例、提示词工程技巧、工具链评测。星球里还有：

• 完整的Agent开发教程（从0到1搭建你的第一个Agent）
• 独家工具调用Prompt模板库
• 一对一问题答疑

扫码加入，和1000+AI开发者一起成长。

---

*上一篇：[AI Agent记忆系统：让AI拥有长期记忆](05-agent-memory.md)*

*下一篇：[AI Agent多模态能力：让AI看懂图片、听懂声音](07-agent-multimodal.md)*

🎁 福利时间

回复关键词 【工具调用】 获取本文配套资料包

加入知识星球，获取更多AI实战内容

立即加入 →

典型框架	LangChain Agent	OpenAI API	Claude Desktop、Cursor