第26章 工具调用（Function Calling）原理与实战

26.1 为什么工具调用是Agent的核心能力？

大模型本身很强大，能写文章、写代码、回答问题，但它有一个根本局限：它只能生成文本，不能直接和外部世界交互。

具体来说，大模型不能：

• 查询实时信息（今天的天气、最新的新闻、实时股价）
• 操作外部系统（发邮件、订机票、查数据库、操作软件）
• 执行计算（复杂数学计算、数据分析、代码运行）
• 访问私有数据（企业内部文档、用户个人数据）

如果大模型只能生成文本，那它就只是一个"高级聊天机器人"，无法真正"做事"。工具调用（Function Calling）就是让大模型能调用外部工具、和外部世界交互的能力，是Agent从"能说"到"能做"的关键。

26.2 工具调用的基本原理

大模型本身不能直接调用工具，它只能生成文本。工具调用的原理是：大模型生成特定格式的文本（工具名+参数），外部程序解析这个文本，真正调用工具，然后把结果返回给大模型。

这是一个"大模型生成请求→外部程序执行→结果返回大模型"的协作过程。

26.2.1 工具调用的完整流程

┌─────────────────────────────────────────────────────┐
│ 1. 系统初始化：把所有可用工具的描述（名称、功能、    │
│    参数格式）告诉大模型                                │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 2. 用户输入目标，如"帮我查一下北京今天的天气"        │
└──────────────────────┬───────────���──────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 3. 大模型理解目标，决定需要调用哪个工具，生成工具    │
│    调用请求（特定格式的JSON：工具名+参数）           │
│    例如：{"name":"get_weather","arguments":         │
│    {"city":"北京","date":"今天"}}                    │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 4. 外部程序解析大模型的输出，识别出工具调用请求      │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 5. 外部程序真正调用工具（API/数据库/文件系统），     │
│    获取结果，例如：北京今天晴，15-25°C              │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 6. 外部程序把工具返回结果传给大模型                   │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│ 7. 大模型根据工具返回结果，决定下一步：              │
│    - 如果信息足够，生成最终答案给用户                 │
│    - 如果还需要其他信息，继续调用其他工具（回到第3步）│
└─────────────────────────────────────────────────────┘

这个过程可能循环多次，直到大模型认为信息足够，生成最终答案。

26.2.2 一个真实的执行过程示例

用户："帮我查一下北京今天的天气，然后根据天气推荐穿搭。"

第1轮（大模型决定调用工具）：
大模型思考：用户需要北京今天的天气，我需要调用天气查询工具。
大模型输出：{"name":"get_weather","arguments":{"city":"北京","date":"2024-10-15"}}

外部程序执行：
解析输出，调用天气API，获取结果："北京今天晴，气温15-25°C，东南风3级，空气质量优。"
把结果传给大模型。

第2轮（大模型根据结果生成答案）：
大模型思考：天气信息已经获取了，气温15-25°C，温差较大，晴天。我可以根据这个天气推荐穿搭了，不需要再调用工具。
大模型输出最终答案："北京今天晴，气温15-25°C，温差较大。推荐穿搭：薄外套（风衣/牛仔外套）+ 长袖T恤/衬衫 + 长裤。早晚穿外套，中午热了可以脱。鞋子穿休闲鞋或运动鞋即可。"

整个过程中，大模型调用了1次工具，然后生成了最终答案。如果用户的问题更复杂（比如"帮我安排下周去北京的出差"），可能需要调用多次工具（查天气、查日程、订机票、订酒店、发邮件等），循环多次。

26.3 Function Calling：标准化的工具调用

Function Calling（函数调用）是OpenAI在2023年6月推出的标准化工具调用方式，现在已成为行业标准，几乎所有主流大模型（GPT、Claude、Gemini、通义千问、文心一言、智谱、DeepSeek等）都支持。

26.3.1 Function Calling的工作方式

在Function Calling出现之前，开发者需要用Prompt引导大模型生成特定格式的工具调用请求，然后用正则表达式解析。这种方式不稳定，大模型经常不按格式输出，解析容易出错。

Function Calling把工具调用标准化了：

1. 开发者用JSON Schema定义工具：包括工具名称、功能描述、参数名称、参数类型、参数描述、是否必填等
2. 大模型经过专门微调，能识别工具定义，在需要调用工具时输出特定格式的JSON（工具名+参数），而不是自由文本
3. API层面支持：大模型API会识别工具调用请求，返回结构化的调用信息，开发者不需要自己用正则解析
4. 多轮对话支持：工具返回结果可以作为对话历史的一部分，传给大模型继续处理

26.3.2 工具定义的示例

一个完整的工具定义（JSON Schema格式）：

{
  "name": "search_flight",
  "description": "搜索航班信息，根据出发地、目的地、日期查询可用航班。用于用户需要查询或预订机票时。",
  "parameters": {
    "type": "object",
    "properties": {
      "origin": {
        "type": "string",
        "description": "出发城市，如北京、上海、广州。支持中文城市名。"
      },
      "destination": {
        "type": "string",
        "description": "目的城市，如深圳、成都、杭州。支持中文城市名。"
      },
      "date": {
        "type": "string",
        "description": "出发日期，格式为YYYY-MM-DD，如2024-10-15。"
      },
      "cabin_class": {
        "type": "string",
        "description": "舱位等级，可选值：经济舱、商务舱、头等舱。默认为经济舱。",
        "enum": ["经济舱", "商务舱", "头等舱"]
      }
    },
    "required": ["origin", "destination", "date"]
  }
}

这个定义告诉大模型：

• 有一个叫search_flight的工具
• 它的功能是搜索航班信息，用于查询或预订机票时
• 它需要4个参数：origin（出发地）、destination（目的地）、date（日期）、cabin_class（舱位等级，可选）
• 其中origin、destination、date是必填的，cabin_class是可选的
• cabin_class只能是"经济舱"、"商务舱"、"头等舱"三个值之一

大模型看到这个定义后，在用户需要查航班时，就会生成符合这个格式的调用请求，例如：

{
  "name": "search_flight",
  "arguments": {
    "origin": "北京",
    "destination": "上海",
    "date": "2024-10-15",
    "cabin_class": "经济舱"
  }
}

26.3.3 工具定义的最佳实践

工具定义的质量直接影响工具调用的准确率。以下是最佳实践：

1. 名称（name）要清晰、简洁、有意义

• 用动词+名词的格式，如search_flight、send_email、get_weather
• 不要用模糊的名称，如tool1、function_a、do_something
• 不要太长，控制在2-3个单词
• 用英文，下划线分隔（大多数模型对英文名称识别更准确）

2. 描述（description）要准确、具体、有场景

• 说清楚工具是做什么的，什么时候应该用它
• 包含使用场景，如"用于用户需要查询或预订机票时"，帮助大模型判断什么时候调用
• 不要太简短（如"查天气"），也不要太长（超过200字），控制在50-100字
• 如果工具和其他工具有相似之处，要说明区别，如"这个工具用于查询未来天气，历史天气用get_historical_weather"

3. 参数（parameters）要完整、精确

• 每个参数都要有清晰的描述，说明参数的含义、格式、取值范围
• 明确标注哪些是必填的（required），哪些是可选的
• 有固定取值范围的参数用enum枚举，如舱位等级、订单状态
• 参数类型要正确（string、integer、number、boolean、array、object）
• 日期、时间等格式要明确说明，如"格式为YYYY-MM-DD"
• 嵌套参数用object类型，数组参数用array类型，并说明数组元素的格式

4. 工具粒度要适中

• 不要把多个功能塞进一个工具，如travel_booking（既查机票又订酒店又发邮件），应该拆成多个工具
• 也不要拆得太细，如get_weather_temperature、get_weather_humidity，应该合并成一个get_weather
• 一个工具做一件事，单一职责原则
• 工具数量控制在10-20个比较合适，太多会让大模型选择困难，准确率下降

5. 提供调用示例（Few-shot）

• 在系统Prompt中提供1-2个工具调用的示例，展示什么时候调用、怎么传参
• 示例要覆盖典型场景和边界情况
• 示例能大幅提升工具调用的准确率，尤其是复杂参数的情况

26.4 工具选择与参数生成

工具调用有两个关键步骤：工具选择（决定调用哪个工具）和参数生成（生成正确的参数）。这两步的准确率直接决定了工具调用的整体效果。

26.4.1 工具选择

当有多个可用工具时，大模型需要根据用户的当前任务选择最合适的工具。

影响工具选择准确率的因素：

• 工具描述质量：描述越清晰、越有场景，大模型越容易判断什么时候用
• 工具数量：工具越多，选择越困难，准确率越低。建议控制在20个以内
• 工具区分度：工具之间功能越相似，越容易选错。相似工具要在描述中说明区别
• 用户意图清晰度：用户意图越明确，越容易选对工具。模糊的意图可能需要先澄清
• 上下文信息：结合对话历史和当前状态，能更准确地判断用户意图

提升工具选择准确率的方法：

• 优化工具描述，包含使用场景和与其他工具的区别
• 控制工具数量，合并相似工具，拆分多功能工具
• 提供工具选择的示例（Few-shot）
• 对模糊意图先澄清再调用工具，避免猜错
• 用工具分类/分组，先选大类再选具体工具（适合工具很多的场景）

26.4.2 参数生成

选对工具后，还需要生成正确的参数。参数生成是工具调用中更容易出错的环节。

常见的参数错误：

• 漏填必填参数：大模型可能漏掉必填参数，导致工具调用失败
• 参数格式错误：日期格式不对（用了"2024年10月15日"而不是"2024-10-15"）、数字传成了字符串等
• 参数值错误：城市名不标准（用了"京城"而不是"北京"）、枚举值不在范围内、参数值超出范围等
• 参数理解错误：大模型误解了参数含义，传了错误的值
• 多余参数：传了工具不支持的参数

提升参数生成准确率的方法：

• 参数描述要清晰：每个参数都说明含义、格式、取值范围、示例
• 用enum限制取值：有固定取值范围的参数用枚举，避免生成无效值
• 必填参数明确标注：在required数组中列出必填参数
• 提供参数示例：在参数描述中给出示例，如"如2024-10-15"、"如北京、上海"
• 参数校验：外部程序调用工具前做参数校验，发现错误让大模型重新生成
• 参数补全：对于用户没明确说的参数，根据上下文和常识合理推断，或询问用户
• 标准化处理：对城市名、日期等做标准化处理，把非标准值转换成标准值

26.5 工具调用的错误处理与重试

工具调用不是每次都成功，可能会遇到各种错误。好的Agent必须有完善的错误处理和重试机制。

26.5.1 常见错误类型

26.5.2 错误处理策略

1. 感知错误
外部程序调用工具后，检查返回结果，识别错误类型和错误信息。包括：

• HTTP状态码检查（200成功，4xx客户端错误，5xx服务端错误）
• 返回格式检查（是否是预期的JSON格式）
• 业务错误检查（返回的error字段、code字段）
• 空结果检查（返回的数据为空）

2. 分析原因
把错误信息传给大模型，让大模型分析错误原因，决定下一步怎么做。错误信息要具体、可理解，不要只说"调用失败"，要说"调用search_flight失败：日期格式错误，请使用YYYY-MM-DD格式"。

3. 调整重试
根据错误原因调整后重试：

• 参数错误 → 修正参数后重试
• 工具不存在 → 换一个合适的工具
• 网络超时 → 等待后重试
• API限流 → 等待后重试，或换备用API
• 资源不存在 → 换查询条件，或告知用户无法找到

4. 上限控制
设置重试次数上限（通常3次），避免无限循环。超过上限后，停止重试，进入降级处理。
同时设置最大工具调用次数（通常10-20次），避免Agent陷入死循环，消耗大量token。

5. 降级处理
多次失败后，向用户说明情况，提供替代方案：

• 说明遇到了什么问题（如"航班查询系统暂时不可用"）
• 提供替代方案（如"您可以稍后再试，或直接访问航空公司官网查询"）
• 请求人工介入（如"我已记录您的需求，客服人员会尽快联系您"）
• 不要编造结果，不要假装成功

26.5.3 错误处理的Prompt设计

在系统Prompt中明确告诉大模型如何处理错误：

工具调用错误处理规则：
1. 如果工具调用返回错误，仔细阅读错误信息，分析原因
2. 如果是参数错误，修正参数后重试，最多重试3次
3. 如果是工具不存在，换一个合适的工具，或告知用户该功能暂不支持
4. 如果是网络或系统错误，等待后重试，最多重试3次
5. 如果3次重试仍然失败，停止重试，向用户说明情况并提供替代方案
6. 不要编造工具返回结果，不要假装调用成功
7. 每次工具调用失败都要记录错误信息，便于后续排查

26.6 实战：构建一个能查天气、订机票、发邮件的Agent

让我们通过一个完整的实战案例，看看如何设计和实现一个具备工具调用能力的Agent。

26.6.1 场景定义

目标：构建一个旅行助手Agent，能帮用户：

• 查询目的地天气
• 查询和预订机票
• 查询和预订酒店
• 发送邮件通知相关人员

26.6.2 工具设计

根据场景，设计4个工具：

工具1：get_weather（查询天气）

{
  "name": "get_weather",
  "description": "查询指定城市指定日期的天气信息，包括温度、天气状况、风力、空气质量。用于用户需要了解目的地天气、安排出行时。",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名称，如北京、上海、广州"},
      "date": {"type": "string", "description": "查询日期，格式YYYY-MM-DD"}
    },
    "required": ["city", "date"]
  }
}

工具2：search_flight（查询航班）

{
  "name": "search_flight",
  "description": "查询符合条件的航班信息，包括航班号、起降时间、价格、舱位。用于用户需要查询或预订机票时。注意：这只是查询，预订需要用book_flight工具。",
  "parameters": {
    "type": "object",
    "properties": {
      "origin": {"type": "string", "description": "出发城市"},
      "destination": {"type": "string", "description": "目的城市"},
      "date": {"type": "string", "description": "出发日期，格式YYYY-MM-DD"},
      "cabin_class": {"type": "string", "enum": ["经济舱", "商务舱", "头等舱"], "description": "舱位等级，默认经济舱"}
    },
    "required": ["origin", "destination", "date"]
  }
}

工具3：book_flight（预订机票）

{
  "name": "book_flight",
  "description": "预订指定航班的机票。必须先调用search_flight查询到可用航班，然后用航班号预订。预订前需要确认用户信息和航班信息。",
  "parameters": {
    "type": "object",
    "properties": {
      "flight_number": {"type": "string", "description": "航班号，如CA1234"},
      "passenger_name": {"type": "string", "description": "乘客姓名"},
      "id_number": {"type": "string", "description": "身份证号"},
      "cabin_class": {"type": "string", "enum": ["经济舱", "商务舱", "头等舱"]},
      "contact_phone": {"type": "string", "description": "联系电话"}
    },
    "required": ["flight_number", "passenger_name", "id_number", "cabin_class", "contact_phone"]
  }
}

工具4：send_email（发送邮件）

{
  "name": "send_email",
  "description": "发送邮件给指定收件人。用于通知相关人员行程安排、会议信息等。发送前需要确认收件人、主题和正文内容。",
  "parameters": {
    "type": "object",
    "properties": {
      "to": {"type": "string", "description": "收件人邮箱地址"},
      "subject": {"type": "string", "description": "邮件主题"},
      "body": {"type": "string", "description": "邮件正文，支持纯文本"}
    },
    "required": ["to", "subject", "body"]
  }
}

26.6.3 系统Prompt设计

你是一个专业的旅行助手，帮用户安排出差和旅行。你可以调用以下工具：
- get_weather：查询天气
- search_flight：查询航班
- book_flight：预订机票
- send_email：发送邮件

工作流程：
1. 理解用户的出行需求（目的地、时间、目的、相关人员）
2. 查询目的地天气，作为行程安排参考
3. 查询可用航班，向用户展示选项，确认后预订
4. 预订完成后，发送邮件通知相关人员
5. 最后生成完整的行程表给用户

注意事项：
- 预订机票前必须先查询航班，并向用户确认航班信息
- 涉及乘客身份证号、电话等敏感信息，必须向用户确认，不要编造
- 发送邮件前必须确认收件人、主题和正文
- 工具调用失败时，阅读错误信息，修正后重试，最多3次
- 3次失败后，向用户说明情况，提供替代方案
- 不要编造工具返回结果，不要假装调用成功

26.6.4 完整执行过程示例

用户："帮我安排下周三去北京的出差，要见客户A，我叫张三，电话138xxxx1234。"

Agent执行过程：

步骤1：理解需求
Agent理解：用户张三，下周三（假设是2024-10-16）从当前城市（假设是上海）去北京出差，要见客户A，需要安排行程。

步骤2：查询天气
Agent调用get_weather(city="北京", date="2024-10-16")
返回：北京2024-10-16晴，12-22°C，北风3级。

步骤3：查询航班
Agent调用search_flight(origin="上海", destination="北京", date="2024-10-16", cabin_class="经济舱")
返回：3个可用航班：
1. CA1234，08:00-10:15，¥850
2. MU5678，10:30-12:45，¥780
3. CZ9012，14:00-16:15，¥720

步骤4：向用户确认
Agent："查询到3个可用航班：
1. CA1234，08:00-10:15，¥850
2. MU5678，10:30-12:45，¥780
3. CZ9012，14:00-16:15，¥720
北京当天晴，12-22°C，建议带薄外套。
请问您想预订哪个航班？另外请提供您的身份证号用于预订。"

用户："订第二个，身份证号310xxxxxxxxxxxx1234。"

步骤5：预订机票
Agent调用book_flight(flight_number="MU5678", passenger_name="张三", id_number="310xxxxxxxxxxxx1234", cabin_class="经济舱", contact_phone="138xxxx1234")
返回：预订成功，订单号：ORD20241016001，电子票号：781-1234567890。

步骤6：发送邮件通知
Agent："机票已预订成功。请问客户A的邮箱是什么？我需要发送行程通知邮件。"
用户："客户A的邮箱是customera@example.com。"
Agent调用send_email(to="customera@example.com", subject="张三拜访行程确认", body="尊敬的客户A：您好！张三先生将于2024年10月16日（周三）乘坐MU5678航班（10:30-12:45）前往北京拜访您。抵达后希望能与您会面，具体时间请您安排。如有变动请及时联系。张三 138xxxx1234")
返回：邮件发送成功。

步骤7：生成行程表
Agent："出差安排已完成，行程如下：
📅 日期：2024年10月16日（周三）
🌤️ 天气：北京晴，12-22°C，建议带薄外套
✈️ 航班：MU5678，上海→北京，10:30-12:45，经济舱，¥780
🎫 订单号：ORD20241016001
📧 已通知客户A（customera@example.com）
祝您出差顺利！"

整个过程中，Agent调用了4次工具（查天气、查航班、订机票、发邮件），中间和用户交互确认了2次（航班选择、身份证号、客户邮箱），最终完成了整个出差安排。

26.7 工具调用的安全与权限控制

Agent能调用工具执行操作，这带来了便利，也带来了安全风险。必须有严格的安全和权限控制机制。

26.7.1 安全风险

• 误操作：Agent理解错误或参数错误，导致误删文件、误发邮件、错误转账等
• 恶意诱导：用户通过Prompt注入，诱导Agent执行恶意操作（如删除数据、发送敏感信息）
• 权限滥用：Agent权限过大，能访问或操作不该访问的资源
• 数据泄露：工具返回的敏感信息被大模型泄露给未授权用户
• 越权操作：低权限用户通过Agent执行高权限操作

26.7.2 安全控制措施

1. 权限最小化

• Agent只拥有完成任务所需的最小权限，不要给管理员权限
• 不同用户角色对应不同的工具权限，普通用户不能调用管理工具
• 敏感操作（删除、转账、发送）需要单独授权

2. 操作确认机制

• 高风险操作（删除数据、转账、发送邮件、修改配置）执行前必须向用户确认，用户明确同意后才执行
• 确认信息要清晰：要做什么、影响是什么、是否可逆
• 提供"取消"选项，用户可以随时终止

3. 操作审计日志

• 记录所有工具调用：调用时间、调用者、工具名、参数、返回结果、耗时
• 日志不可篡改，定期备份
• 异常操作自动告警（如频繁删除、大额转账、访问敏感数据）
• 支持操作追溯和回滚

4. 输入校验与过滤

• 对用户输入做安全过滤，防止Prompt注入攻击
• 对工具参数做校验，防止注入攻击（如SQL注入、命令注入）
• 对工具返回结果做过滤，防止敏感信息泄露
• 限制单次操作的范围和数量，防止批量误操作

5. 沙箱环境

• 代码执行、文件操作等在沙箱环境中运行，隔离主系统
• 限制沙箱的资源访问（网络、文件系统、系统调用）
• 敏感数据不进入沙箱

6. 人工兜底

• 高风险操作必须有人工审核，不能完全自动执行
• 设置紧急停止按钮，发现异常可以立即终止Agent
• 重要操作有回滚机制，出问题可以恢复

26.8 常见问题与优化技巧

问题1：大模型经常不调用工具，直接用自己的知识回答
原因：工具描述不够清晰，大模型不知道什么时候该用工具；或者大模型觉得自己的知识足够。
解决：

• 优化工具描述，明确使用场景，如"当用户需要查询实时天气时必须调用此工具，不要用自己的知识回答，因为你的知识有截止日期"
• 在系统Prompt中强调："涉及实时信息、外部数据、操作执行的问题，必须调用工具，不要用自己的知识回答"
• 提供调用工具的示例（Few-shot）

问题2：大模型调用了错误的工具
原因：工具之间功能相似，描述区分度不够；工具数量太多。
解决：

• 优化工具描述，说明和其他工具的区别
• 合并相似工具，控制工具数量在20个以内
• 用工具分类，先选大类再选具体工具
• 提供工具选择的示例

问题3：参数经常出错（漏填、格式错、值错）
原因：参数描述不够清晰；大模型对参数理解不准确。
解决：

• 每个参数都有清晰的描述、格式说明、示例
• 有固定取值的用enum枚举
• 必填参数明确标注
• 外部程序做参数校验，错误时让大模型重新生成
• 对城市名、日期等做标准化处理

问题4：工具调用陷入死循环，反复调用同一个工具
原因：大模型没有正确理解工具返回结果，或者工具返回结果没有解决问题。
解决：

• 设置最大工具调用次数（如10次），超过后强制停止
• 设置同一个工具的连续调用上限（如3次），超过后换方式或询问用户
• 工具返回结果要清晰、结构化，方便大模型理解
• 在系统Prompt中说明："如果同一个工具调用3次仍然没有得到有效结果，停止调用，向用户说明情况并寻求帮助"

问题5：工具调用太慢，用户等待时间长
原因：工具调用次数多，每次都要等大模型生成和工具执行。
解决：

• 优化工具，减少调用次数（如合并多个查询为一个批量查询）
• 并行调用无依赖的工具（如同时查天气和查航班）
• 用更快的大模型做工具调用（如用GPT-4o-mini而不是GPT-4o）
• 给用户展示进度（"正在查询天气...正在查询航班..."），提升等待体验
• 缓存常用查询结果，减少重复调用

问题6：工具调用成本太高
原因：每次工具调用都需要大模型生成，多轮调用token消耗大。
解决：

• 用更小、更便宜的模型做工具调用
• 减少不必要的工具调用，能一次解决的不要分多次
• 设置工具调用上限，避免无限循环
• 优化Prompt，减少token消耗
• 对简单任务用规则判断，不需要每次都调用大模型

26.9 产品经理视角：工具设计的注意事项

作为AI产品经理，在设计Agent的工具系统时，需要关注以下几点：

1. 工具设计要从用户需求出发，不是从技术出发
不要先想"我有哪些API可以封装成工具"，而是先想"用户需要完成什么任务，需要哪些能力"。工具是为用户需求服务的，不是为了展示技术能力。

2. 工具粒度要适中，单一职责
一个工具做一件事，不要把多个功能塞进一个工具。太粗的工具灵活性差，太细的工具调用复杂。要根据用户的任务流程设计工具粒度。

3. 工具数量要控制，避免选择困难
工具不是越多越好，太多工具会让大模型选择困难，准确率下降，也会增加用户的认知负担。控制在10-20个核心工具，覆盖主要场景即可。长尾场景可以后续迭代补充。

4. 高风险操作必须有确认和审计
涉及删除、转账、发送、修改等不可逆或高风险的操作，必须有用户确认机制和审计日志。不能让Agent完全自动执行，要有人工兜底。产品经理要明确哪些操作需要确认，确认的流程是什么。

5. 错误处理和降级体验要设计好
工具调用一定会失败，产品经理要设计好失败时的用户体验：怎么告诉用户失败了、失败原因是什么、有什么替代方案、怎么重试。不要让用户看到一堆技术错误信息，要用用户能理解的语言说明。

6. 工具调用过程要透明
让用户看到Agent在做什么（"正在查询天气...正在预订机票..."），而不是黑盒等待。透明性能提升用户信任感，也方便用户在出错时干预。

7. 持续迭代优化工具
工具上线后不是一成不变的，要根据用户使用数据和反馈持续优化：哪些工具使用率高、哪些经常出错、哪些用户想要但没有。定期分析工具调用日志，发现问题和机会，迭代优化。

26.8 MCP协议：工具调用的新标准

26.8.1 从Function Calling到MCP

前面我们学习的Function Calling是大模型厂商提供的工具调用能力，每个AI应用都需要为每个工具单独编写适配代码。���种方式在工具数量少的时候没问题，但当工具数量增多、需要跨应用复用时，就会出现严重的碎片化问题。

2024年11月，Anthropic推出了MCP（Model Context Protocol，模型上下文协议），2025年捐赠给Linux Foundation，目前已成为AI工具调用的事实标准。截至2026年8月，全球已有超过200个MCP服务器实现，覆盖数据库、API、文件系统、SaaS工具等各类场景。

26.8.2 MCP的核心架构

MCP采用客户端-主机-服务器三层架构：

1. MCP Client（客户端）：集成在AI应用（如Claude、Cursor、Agent框架）中，负责向主机发送请求，接收响应
2. MCP Host（主机）：管理客户端与服务器之间的连接，负责安全认证、权限控制、请求路由。这是MCP安全机制的核心
3. MCP Server（服务器）：封装具体的工具和数据源，如数据库MCP服务器、GitHub MCP服务器、文件系统MCP服务器等

MCP定义了三大原语：

26.8.3 MCP vs 传统Function Calling

26.8.4 MCP的产品设计意义

对AI产品经理来说，MCP的出现具有深远的产品设计意义：

1. 工具生态标准化：不需要为每个工具单独开发集成，只要支持MCP协议就能接入整个生态，大幅降低开发成本。产品设计时要优先考虑MCP兼容性
2. 安全可控：MCP Host层可以统一管理权限，企业可以精确控制Agent能访问哪些工具、哪些数据，满足合规要求。设计企业级产品时，MCP的权限控制是核心卖点
3. 能力封装与商业化：企业可以将自己的核心能力封装为MCP服务器，对外提供服务，形成新的商业模式。例如：法律事务所提供合同审查MCP工具、会计师事务所提供财务分析MCP工具
4. 企业级集成：企业内部系统（ERP、CRM、数据库等）只要封装成MCP服务器，就能被任何支持MCP的Agent调用，实现企业知识和能力的AI化。这是企业AI转型的关键基础设施
5. 用户体验一致：用户在不同AI应用中使用相同的MCP工具，体验一致，学习成本低

26.8.5 工具调用技术选型建议

26.10 本章小结

工具调用（Function Calling）是Agent最核心的能力之一，是大模型从"能说"到"能做"的关键。

核心原理：大模型生成特定格式的文本（工具名+参数），外部程序解析后真正调用工具，把结果返回给大模型。这是一个"大模型生成请求→外部程序执行→结果返回大模型"的协作过程，可能循环多次。

Function Calling：OpenAI推出的标准化工具调用方式，用JSON Schema定义工具，大模型经过微调能输出结构化的调用请求，API层面支持，现在是行业标准。

工具定义最佳实践：名称清晰简洁、描述准确有场景、参数完整精确、工具粒度适中（单一职责）、控制工具数量（10-20个）、提供调用示例。

工具选择与参数生成：工具选择准确率取决于描述质量、工具数量、区分度；参数生成常见错误有漏填、格式错、值错，通过清晰描述、enum枚举、参数校验、标准化处理来提升。

错误处理与重试：感知错误→分析原因→调整重试（有上限）→降级处理。不要编造结果，不要假装成功，要向用户说明情况并提供替代方案。

安全与权限控制：权限最小化、操作确认机制、操作审计日志、输入校验过滤、沙箱环境、人工兜底。Agent能操作外部系统，安全是第一位的。

产品经理视角：工具设计从用户需求出发、粒度适中、数量控制、高风险操作有确认和审计、错误处理体验好、过程透明、持续迭代优化。

工具调用是Agent的基础能力，掌握它的原理、最佳实践、常见问题，是AI产品经理设计Agent产品的核心技能。下一批我们会继续深入Agent的规划能力、记忆系统、多Agent协作等更高级的主题。

📝 本章练习（9题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任