引言
2023 年初，ChatGPT 风靡全球。但如果你认真用过它，你会发现一个令人沮丧的体验——你问它「今天天气怎么样」，它回答「我无法访问实时信息」。你问它「帮我算一下 1234 × 5678」，它可能给你一个错误的答案。你问它「帮我发一封邮件」，它说「我无法执行实际操作」。
一个无所不知的 AI，却什么都做不了。
这就像雇了一个博学多才但被锁在地下室里的助手——他什么都知道，但哪儿也去不了、什么也碰不着。他能告诉你天气怎么看，但不能帮你查天气；他能告诉你邮件怎么写，但不能帮你发邮件。
2023 年 6 月，OpenAI 发布了 Function Calling（后来演变为 Tool Calling）。这是一次从「AI 只能说话」到「AI 能做事」的根本性转变。
LK1993-
Logan Kilpatrick
OpenAI 前开发者关系负责人，推动了 Function Calling 的开发者生态
"Function Calling 是让 AI 从纯粹的文本生成走向真正有用的应用的关键一步。"
大模型的根本局限
Text-in, Text-out
大模型的本质：
输入：文本 → 处理 → 输出：文本
能做：
写文章、翻译、回答问题、分析文本...
不能做：
✗ 获取实时信息（天气、股票、新闻）
✗ 精确计算（大数乘法、复杂公式）
✗ 操作外部系统（发邮件、建数据库）
✗ 访问私有数据（公司内部文档）
✗ 执行代码（在沙箱里运行）为什么模型会「一本正经地胡说」？
你问：「2024 年诺贝尔物理学奖颁给了谁？」
模型的做法：
如果在训练数据里见过 → 可答对
如果没见过 → 仍然会生成一段「看起来像答案」的文字
但内容可能是错的
本质原因：模型不知道「自己不知道什么」
它只是在预测下一个 token，不是在检索事实Function Calling 的诞生
2023 年 6 月：一个里程碑
OpenAI 在 GPT-4 的更新中引入了 Function Calling。核心思想很简单：
不让模型直接做事情，
而是让模型告诉你的代码它想做什么，
然后你的代码去做。
流程：
用户提问 → 模型分析 → 「我想调用 get_weather 函数」
→ 你的代码调用天气 API
→ 把结果返回给模型
→ 模型基于结果回答用户设计哲学：为什么用 JSON Schema？
为什么 OpenAI 选择 JSON Schema 来定义工具？
选项 A：用自然语言描述工具
"有一个工具可以查天气，输入城市名和日期"
→ 模型可能理解错参数格式
→ 不确定性太高
选项 B：用 JSON Schema 定义工具
{
"name": "get_weather",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string"},
"date": {"type": "string", "format": "date"}
},
"required": ["city"]
}
}
→ 结构化、无歧义、可验证
→ 模型生成的参数可以被代码直接使用
设计决策的核心：让模型输出结构化指令，让代码可靠执行。第一个 Function Calling 示例
python
from openai import OpenAI
import json
client = OpenAI()
# Step 1: 定义工具
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称"
}
},
"required": ["city"]
}
}
}]
# Step 2: 发送消息（带工具定义）
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "user", "content": "北京今天天气怎么样？"}
],
tools=tools
)
# Step 3: 检查模型是否想调用工具
message = response.choices[0].message
if message.tool_calls:
for tool_call in message.tool_calls:
print(f"模型想调用: {tool_call.function.name}")
print(f"参数: {tool_call.function.arguments}")
# 输出：
# 模型想调用: get_weather
# 参数: {"city": "北京"}从 Function Calling 到 Tool Calling
名称演变的背后
术语变化：
2023.6 Function Calling → 只能调用函数
2023.11 Parallel Function Calling → 可以同时调多个
2024 Tool Calling → 统一术语，工具不只是函数
为什么改名？
「函数」暗示了编程概念，限制了想象力
「工具」更通用：可以是函数、API、搜索引擎、数据库查询...Tool 的类型
Tool Calling 的广义理解：
Tool = 模型可以调用的任何外部能力
常见工具类型：
├── 信息获取：天气 API、股票 API、搜索引擎
├── 数据操作：数据库查询、文件读写
├── 代码执行：Python 沙箱、浏览器
├── 通信：发邮件、发消息
└── 系统操作：创建日程、管理任务为什么 Tool Calling 如此重要？
没有 Tool Calling 的 AI：
→ 只能基于训练数据回答
→ 无法获取实时信息
→ 无法执行精确计算
→ 无法操作外部系统
→ 本质上是一个「高级搜索引擎」
有 Tool Calling 的 AI：
→ 可以查实时天气
→ 可以调计算器做精确运算
→ 可以读写数据库
→ 可以发邮件、建日程
→ 本质上是一个「能做事的助手」
Tool Calling 让 AI 从「只会说话」进化为「能与世界交互」。
这是从 Chatbot 到 Agent 的关键一步。本节小结
| 概念 | 要点 |
|---|---|
| 根本局限 | 大模型是 text-in/text-out，无法直接获取实时信息或执行操作 |
| Function Calling | 2023.6 发布，让模型输出结构化的工具调用指令 |
| 设计哲学 | JSON Schema 定义工具 → 模型输出结构化参数 → 代码执行 |
| Tool Calling | 统一术语，工具可以是任何外部能力 |
| 核心意义 | 从 Chatbot 到 Agent 的关键一步——AI 能做事了 |
思考题
- 为什么不让模型直接调用 API，而是让模型输出调用意图，由代码来执行？这种间接设计有什么好处？
- 如果模型可以调用任何工具，会有什么安全风险？应该如何防护？
- 想象你要做一个「AI 助手」，它应该有哪些工具？这些工具分别解决了什么问题？