Agent 的核心能力：工具调用（Function Calling）

课程概述

工具调用（Function Calling / Tool Use）是 AI Agent 从"嘴炮"变成"实干家"的核心能力。

没有工具调用的 AI：你问"今天天气怎么样？"，它回答"抱歉，我的知识截止到……"

有工具调用的 AI：它默默调用了一个天气 API，然后告诉你："今天上海多云，18-25℃，下午 3 点有 60% 概率下雨。建议带伞。"

这门课用通俗的方式解释工具调用的原理、工作流程和常见模式。如果你是非技术背景，你会理解这个能力为什么如此重要。如果你是开发者，你会掌握实现工具调用的核心逻辑。

学习目标

• 理解 Function Calling 是什么以及为什么它是 Agent 的核心
• 了解工具调用的完整工作流：意图识别 → 参数提取 → 执行 → 结果整合
• 掌握设计和描述工具的要点
• 了解工具调用的安全考量
• 能判断什么任务应该"做成工具"而不是"写在提示词里"

课程内容

1. 工具调用——给 AI 一双"能干活的手"

没有工具的 AI 能做什么？

它只能"说"。它拥有知识，但无法获取新信息，无法对外部世界产生任何影响。就像一个被困在图书馆里的人——博览群书，但哪里都去不了。

有工具的 AI 能做什么？

它拥有"手"：

• 查询实时天气 → 调用天气 API
• 发送邮件 → 调用邮件服务 API
• 创建日程 → 调用日历 API
• 分析数据 → 调用数据库或 Python 解释器
• 搜索最新信息 → 调用搜索引擎 API
• 控制设备 → 调用 IoT 接口

工具调用本质上是什么？

本质上是一次"翻译 + 执行"：

用户说的话（自然语言）
  → LLM 翻译成：需要调用哪个函数 + 参数是什么
  → 系统执行这个函数
  → 返回结构化结果
  → LLM 把结果翻译回人话

就像你在国外旅行，有一个翻译帮你：你跟翻译说"帮我订一张去上海的机票"→ 翻译把这句话翻译成当地语言告诉航空公司 → 航空公司返回航班信息 → 翻译把结果翻译成中文告诉你。

2. 工具调用的完整流程——逐步拆解

假设你问一个带工具调用的 Agent："明天上海会下雨吗？"

Step 1：意图识别

LLM 首先判断：这个问题我能直接回答吗？

• 知识截止到去年的某个日期 → 明天的天气不在知识范围内
• 有一个可用的工具叫 get_weather → 匹配！

Step 2：工具选择 + 参数提取

LLM 判断应该调用 get_weather 函数，并提取参数：

{
  "function": "get_weather",
  "parameters": {
    "city": "上海",
    "date": "2026-05-30"
  }
}

LLM 不需要被"训练"来做这件事。现代的 LLM 天然具备这个能力——只要你在提示词中描述了有哪些工具可用、每个工具的参数格式是什么。

Step 3：系统执行

系统（不是 LLM）执行这个函数——调用天气 API，拿到数据：

{
  "city": "上海",
  "date": "2026-05-30",
  "weather": "阵雨转多云",
  "temperature": "22-28℃",
  "precipitation_chance": "70%"
}

Step 4：结果整合

LLM 读取这个结构化结果，翻译成人话：

"明天（5 月 30 日）上海是阵雨转多云，气温 22 到 28 度，降雨概率 70%。建议带伞，尤其是下午出门的话。"

3. 工具描述的艺术——让 AI 准确地"选对工具"

AI 能不能选对工具、填对参数，取决于你怎么描述它。

一个糟糕的工具描述：

工具名称：search
描述：搜索东西
参数：q — 搜索关键词

AI 完全不知道这个工具和"另一个叫 search 的工具"有什么区别，什么时候该用它。

一个好的工具描述：

工具名称：search_products
描述：在公司产品数据库中搜索产品信息。当你需要查找产品价格、库存、规格时使用。不支持搜索客户信息或订单信息。
参数：
  - keyword: 产品名称或关键词（必填）
  - category: 产品类别过滤（选填，可选值：硬件/软件/服务）
  - min_price / max_price: 价格区间过滤（选填）
  - in_stock_only: 是否只显示有库存的（选填，默认 false）
返回：产品列表（名称、价格、库存、SKU）

差别在于：

1. 说明了什么时候该用这个工具（产品信息查询），什么时候不该用（不支持搜索客户和订单）
2. 参数的类型、是否必填、可选值都很明确
3. 说明了返回值包含什么，让 LLM 知道拿到结果后怎么处理

工具描述的核心要素：

• 用途说明： 用一两句话说明这个工具是做什么的。注意加上"不用在XX场景"的排除
• 触发场景： 用户说了什么话时应该触发这个工具？比如"当用户询问'价格''多少钱''怎么卖'时使用"
• 参数约束： 类型、是否必填、默认值、可选范围、格式要求
• 返回说明： 返回值包含什么字段、什么类型

4. 工具调用的三种模式

模式 1：单工具单次调用（最简单）

用户问题 → 选一个工具 → 调用 → 返回结果。

"今天天气怎么样？" → get_weather(city="北京") → 返回天气 → 回答用户。

模式 2：单工具 + 多轮调用

调用一次不够，需要基于第一次的结果做进一步查询。

"帮我查一下我们公司的产品 A 和产品 B，哪个销量更好？"

• 第一轮：get_product(product="A") → 拿到 A 的销量数据
• 第二轮：get_product(product="B") → 拿到 B 的销量数据
• LLM 对比两个结果 → "产品 B 的销量比 A 高 35%"

模式 3：多工具组合调用（Agent 的核心能力）

一个任务需要调用多个不同的工具，而且有先后依赖。

"帮我安排明天下午跟客户张总开个会，讨论他们公司的财务报表，然后发给张总确认。"

• get_calendar(customer="张总") → 查张总的公司和联系方式
• get_financial_report(company="XX公司") → 拉财报数据
• create_meeting(date="明天", time="下午", attendees=["张总"]) → 创建会议
• send_email(to="张总", subject="会议确认", content="明天下午X点见面讨论财报") → 发确认邮件

这是 Agent 真正强大的地方——不是做一件事，是完成一个"需要多步骤、多工具"的完整任务。

5. 安全考量——给 AI 工具戴上"安全带"

当 AI 能"做事"而不仅是"说话"时，安全问题就变得尤为重要。

原则 1：最小权限——只给必要的工具和权限

如果 Agent 只需要"查"产品信息，不要给它"改"产品信息的工具。"只读"永远比"读写"安全。

原则 2：人类在回路（Human-in-the-loop）——关键操作要人确认

以下操作不应该让 AI 自动执行：

• 涉及付款和财务的操作
• 对外发送消息（邮件、短信、社交媒体）
• 修改数据库和生产环境
• 删除任何数据

在这些操作之前设置"确认关口"。

原则 3：输入验证——不要信任 LLM 给你的参数

LLM 可能"幻觉"出危险的参数。比如它可能给 send_email(to="XXX") 填入一个从对话中"编造"的邮箱地址。你的系统应该验证：

• 邮箱格式是否正确
• 收件人是否在通讯录中
• 金额是否在合理范围内

原则 4：可追溯——记录每一次工具调用

谁在什么时候调用了什么工具、传了什么参数、返回了什么结果——全部记录在案。出了问题时，你能回溯到底发生了什么。

6. 什么应该做成"工具"vs"提示词"？

判断标准：这个任务是否需要"外界信息"或"产生外界影响"？

• 纯文本输入 → 纯文本输出 = 提示词搞定
• 需要访问外部系统/数据/API = 做成工具
• 会产生外部影响（发邮件、修改数据、下单）= 做成工具 + 人确认

实操练习

1. 工具盘点（10 分钟）： 列出你日常工作中用的 5 个最重要的软件/系统。想象 AI 如果能"操作"它们，能帮你完成哪些任务？这些系统有没有 API？

2. 设计你的第一个工具（10 分钟）： 选上面任务中最简单的一个，按本课的规范写一份工具描述（用途、触发场景、参数、返回说明）。如果你不是开发者，你会怎么向一个开发者描述你需要的这个工具？

3. 安全性检查（5 分钟）： 对你设计的工具，列出至少 2 个"如果 AI 调用出错了会有什么后果"的场景，以及对应的防御措施。

总结

工具调用是 Agent 从"能说"跨越到"能做"的关键。三个核心理解：

1. 工具调用本质是翻译—— 自然语言 → 函数调用，结果 → 自然语言
2. 工具描述决定工具使用质量—— 描述得越清楚，AI 选得越准确
3. 给工具系上安全带—— 最小权限、人类确认、输入验证、全程记录

下一课，我们动手搭建你的第一个 AI Agent——零代码入门。