一句话解释

Function Calling，也常被称为 Tool Use，是让大模型根据用户意图生成结构化的工具调用请求，由应用程序执行真实函数或 API，再把结果返回给模型继续生成答案的机制。

最重要的一点是：模型通常并不亲自执行函数。它只是决定“应该调用哪个工具、传入什么参数”；真正执行代码、访问数据库、调用 API、写文件、发邮件的是模型外部的应用层。

为什么最近变火

大模型最早给人的印象是“会聊天、会写作、会生成代码”。但真实应用很快遇到一个边界：只会生成文本远远不够。用户不仅想问“今天北京天气怎么样”，还希望模型能查实时天气；不仅想让模型写一封邮件，还希望它能读取通讯录、生成草稿、必要时发出；不仅想让模型解释 bug，还希望它能运行测试、修改代码、验证结果。

这就需要模型连接外部世界。Function Calling / Tool Use 正是这条连接通道。

几个关键节点推动它变成热词：

• 2022 年，ReAct 提出把推理和行动结合，让模型在回答中交替进行 reasoning 和 acting。
• 2023 年，Toolformer 展示语言模型可以学习何时调用外部工具。
• 2023 年 3 月，ChatGPT Plugins 让 ChatGPT 通过插件连接第三方服务，展示了“语言模型 + 工具生态”的产品形态。
• 2023 年 6 月，OpenAI 在 API 中推出 function calling，让开发者能用 JSON Schema 描述函数，并让模型生成结构化函数参数。
• 2024 年，Structured Outputs 让模型输出更严格符合开发者指定的 JSON Schema，提高结构化调用可靠性。
• 2025 年，Responses API、Agents SDK、内置 web search、file search、computer use 等工具让 tool use 更接近 Agent 平台能力。
• Anthropic Claude、Google Gemini、Mistral 等模型平台也都提供了类似的 tool use / function calling 能力。

这背后的趋势很清楚：大模型正在从“语言生成器”变成“自然语言控制层”。它通过工具调用，把用户的自然语言目标转成软件系统可以执行的结构化操作。

它解决了什么问题

• 实时信息问题：模型训练数据有截止时间，工具可以查询最新天气、价格、新闻、库存、日程。
• 私有系统问题：模型不知道企业数据库、CRM、工单、代码仓库，工具可以连接这些系统。
• 计算可靠性问题：模型心算和复杂计算容易错，工具可以调用计算器、Python、SQL。
• 动作执行问题：模型不能只回答，还需要创建日程、发送请求、生成文件、执行测试。
• 结构化输出问题：工具调用要求参数格式明确，比让模型自由写自然语言更容易接入程序。
• Agent 行动问题：Agent 要完成多步任务，必须能稳定使用工具。
• 安全边界问题：工具 schema、权限和确认流程可以限制模型能做什么。

Function Calling 的价值不是让模型“更会说”，而是让模型“能接入可执行系统”。

核心概念

1. 工具

工具是模型可以请求外部系统执行的能力。它可以是一个本地函数，也可以是远程 API、数据库查询、搜索服务、代码解释器、文件操作、浏览器控制或企业业务系统。

例如：

工具	输入参数	返回结果
get_weather	城市、日期	天气、温度、降雨概率
search_docs	查询词、过滤条件	相关文档片段
run_sql	SQL 查询	表格结果
create_calendar_event	标题、时间、参会人	日程 ID
run_tests	测试命令	测试输出和状态码
send_email	收件人、主题、正文	发送状态

工具越强，风险也越高。读取天气风险很低，发送邮件、付款、删除文件、修改数据库则需要严格确认和权限控制。

2. Tool Schema

Tool schema 是工具说明书。它告诉模型：

• 工具叫什么；
• 什么时候适合使用；
• 需要哪些参数；
• 参数类型是什么；
• 哪些字段必填；
• 返回值大概是什么。

一个简化的工具描述可能是：

{
  "name": "get_weather",
  "description": "查询指定城市和日期的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "date": { "type": "string" }
    },
    "required": ["city", "date"]
  }
}

工具描述写得好不好，会直接影响模型是否正确调用。描述模糊、参数命名混乱、返回值不稳定，都会让模型更容易出错。

各家 Provider 的 schema 差异

虽然主流厂商都用 JSON Schema 描述工具参数，但包装结构和字段命名差别不小。如果你的应用要同时支持多家模型，必须做一层适配。

维度	OpenAI	Anthropic Claude	Google Gemini	Mistral
顶层字段	tools: [{ type: "function", function: {...} }]	tools: [{ name, description, input_schema }]	tools: [{ function_declarations: [{...}] }]	tools: [{ type: "function", function: {...} }]
参数 schema 字段	parameters	input_schema	parameters	parameters
严格模式	strict: true（启用 Structured Outputs）	无独立字段，靠 prompt 约束	response_schema 用于响应而非工具	tool_choice: "any" 等
Tool 选择控制	tool_choice: "auto" / "none" / {"type":"function","function":{"name":"X"}}	tool_choice: {"type": "auto" / "any" / "tool", "name": "X"}	tool_config.function_calling_config.mode: "AUTO"/"ANY"/"NONE"	tool_choice: "auto" / "any" / "none"
并行调用	默认支持，可用 parallel_tool_calls: false 关掉	默认支持，可用 disable_parallel_tool_use 关掉	默认支持	部分模型支持
模型返回字段	tool_calls: [{ id, type, function: { name, arguments } }]（arguments 是 JSON 字符串）	content: [{ type: "tool_use", id, name, input }]（input 是结构化对象）	function_call: { name, args }	tool_calls: [...]（类似 OpenAI）
工具结果回传	role: “tool”，tool_call_id	role: “user”，content: [{ type: "tool_result", tool_use_id, content }]	role: “function”，function_response: { name, response }	role: “tool”

几个常见的"坑"：

• OpenAI 的 arguments 是 JSON 字符串而不是对象，必须 JSON.parse 才能用；Anthropic 直接给结构化对象。
• Anthropic 用 input_schema，不是 parameters。早期把 OpenAI schema 直接喂给 Claude 经常会失败。
• Gemini 的工具响应回传 role 是 function，和 OpenAI/Mistral 的 tool 都不一样。
• 并行调用语义微妙：OpenAI 倾向一次返回多个 tool_calls；Anthropic 在 Claude 3.5+ 上更常见；Gemini 也支持但分布依模型而定。强制串行往往让多步任务变慢。
• 严格模式（strict mode）：只有 OpenAI 提供"schema 100% 强约束"的开关。Anthropic 要靠 prompt + 重试，Gemini 用 response_schema 做生成端约束。

如果团队希望写一遍工具定义跑多家模型，常见做法是用一个统一的 IR（中间表示，通常就是纯 JSON Schema），在调用前根据 provider 翻译成对应格式。LangChain、LlamaIndex、Vercel AI SDK、OpenAI Agents SDK 都内置了这层适配。

3. Tool Call

Tool call 是模型生成的结构化调用请求。例如用户问：

明天上海会下雨吗？

模型可能不直接回答，而是生成：

{
  "tool": "get_weather",
  "arguments": {
    "city": "上海",
    "date": "2026-05-17"
  }
}

应用程序收到这个请求后，调用真实天气 API。API 返回结果后，再把结果交回模型，让模型生成面向用户的自然语言回答。

4. Tool Result

Tool result 是工具执行后的结果。它可能是 JSON、文本、表格、文件路径、错误信息或状态码。

模型需要读取 tool result，再决定下一步：

• 直接回答用户；
• 再调用另一个工具；
• 请求用户补充信息；
• 发现工具失败后重试；
• 判断任务无法完成。

5. Tool Choice

Tool choice 指系统如何决定模型是否调用工具。常见策略有：

策略	含义	适用场景
自动选择	模型自己判断是否调用工具	普通问答和开放任务
强制调用	要求模型必须调用某个工具	数据提取、固定流程
禁止调用	只允许模型回答，不许用工具	离线回答、安全模式
人工确认	模型提出工具调用，由用户批准	高风险操作

生产系统通常不会对所有工具完全自动放行。越有真实后果的工具，越需要人工确认或业务规则审批。

6. Structured Outputs

Structured Outputs 是结构化输出能力的一种增强。它要求模型输出严格符合开发者指定的 JSON Schema。

它和 function calling 关系密切：函数调用需要模型生成结构化参数，而 Structured Outputs 可以提高参数符合 schema 的可靠性。

简单理解：

• 普通自然语言输出：适合给人读。
• JSON mode：适合让模型输出 JSON，但不一定严格满足复杂 schema。
• Structured Outputs：要求输出匹配指定 JSON Schema，更适合程序处理。
• Function Calling：模型生成某个工具的结构化参数，由应用执行工具。

工作原理

Function Calling 的基本循环是：

1. 开发者把可用工具和 schema 提供给模型。
2. 用户提出问题或目标。
3. 模型判断是否需要工具。
4. 如果需要，模型生成工具名称和参数。
5. 应用程序执行工具。
6. 工具结果返回给模型。
7. 模型基于结果回答用户，或继续调用其他工具。

这个循环有两个非常重要的边界：

第一，模型不应该被当作可信执行环境。它生成的是请求，不是最终执行权。应用层必须验证参数、检查权限、处理异常。

第二，工具结果也不应该被无条件信任。工具可能失败、返回空值、返回过多噪声，甚至被恶意内容污染。模型需要被要求基于可信结果回答，系统也需要做过滤和校验。

多工具调用

复杂任务可能需要多个工具。比如用户说：

帮我查一下明天下午我有没有空，如果有空，就给王明发封邮件约 3 点会议。

系统可能需要：

1. 查询日历；
2. 判断是否有空；
3. 查询联系人邮箱；
4. 生成邮件草稿；
5. 请求用户确认；
6. 发送邮件。

这已经接近 Agent 工作流。Function Calling 是 Agent 能行动的基础机制，但 Agent 还需要规划、记忆、状态管理和错误恢复。

典型应用场景

1. 查询实时信息

模型可以调用天气、股票、航班、物流、汇率、新闻、库存等 API，再用自然语言解释结果。

这类工具通常风险较低，因为它们主要是读取信息。但仍要注意来源质量和时间戳。

2. 企业系统集成

企业可以把 CRM、ERP、工单、知识库、数据库、日历、审批系统封装成工具，让模型作为自然语言入口。

例如用户问：“帮我查一下客户 A 最近 3 个工单的状态，并总结主要问题。”模型可以调用客户系统和工单系统，再生成总结。

3. 结构化数据抽取

Function Calling 也常用于从自然语言中抽取结构化字段。例如从邮件中抽取发票金额、供应商、日期、合同编号。

相比让模型自由输出一段文字，schema 可以强制模型给出程序更容易消费的结构。

4. 代码执行和数据分析

模型可以调用 Python、SQL、Shell 或专门的数据分析工具。这样它不需要心算，也不需要猜测数据结果，而是运行代码得到真实输出。

典型任务包括：

• 读取 CSV；
• 生成统计摘要；
• 画图；
• 写 SQL；
• 运行测试；
• 分析日志。

这类工具要特别注意沙箱。不能让模型随意执行危险命令或访问敏感文件。

5. RAG 检索工具

RAG 系统中的检索器也可以被看作一种工具。用户提问后，模型调用 search_docs 检索知识库，再基于结果回答。

这让 RAG 和 Function Calling 很自然地结合：RAG 提供知识，Function Calling 提供连接方式。

6. 高风险动作前的人类确认

发送邮件、下单、付款、删除文件、修改数据库、发布内容、提交代码等操作，应该要求用户确认。

一个合理流程是：

模型：我准备调用 send_email，收件人是 xxx，主题是 xxx，正文如下。是否发送？
用户：确认发送。
系统：执行 send_email。

这样模型可以帮助准备动作，但最终授权仍由用户控制。

和其他概念的区别

概念	解决的问题	和 Function Calling / Tool Use 的关系
Function Calling	让模型生成结构化函数调用参数	更偏 API 机制和结构化调用
Tool Use	让模型使用外部能力完成任务	更宽泛，包括搜索、代码、浏览器、文件等
Structured Outputs	让模型输出符合 schema 的结构化数据	可用于函数参数或普通结构化输出
RAG	检索外部知识增强回答	检索器常作为工具被调用
Agent	多步规划、行动和反馈循环	Function Calling 是 Agent 行动的底层能力
MCP	标准化模型连接工具和数据源	可承载或组织多个工具接口
Plugin	面向产品或平台的工具扩展	比 function 更偏生态和分发
Workflow	固定流程编排	可以在某些步骤中使用工具调用

Function Calling 和 API 调用有什么区别

传统 API 调用是程序员明确写代码：

如果用户点击天气按钮，就调用 get_weather(city)

Function Calling 是模型根据自然语言判断：

用户问“明天上海下雨吗？”
模型决定调用 get_weather(city="上海", date="明天")

也就是说，传统 API 调用的控制逻辑主要由程序员写死；Function Calling 把一部分“何时调用、如何填参数”的判断交给模型。

Function Calling 和 Agent 的区别

Function Calling 是能力，Agent 是系统形态。

一个模型调用一次天气 API，这是 function calling。一个系统为了完成“安排会议”这个目标，查询日历、找参会人、生成议程、发邮件、处理冲突，这更接近 Agent。

一个简单例子

用户问：

明天北京适合跑步吗？

系统提供了一个工具：

{
  "name": "get_weather",
  "description": "查询城市天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "date": { "type": "string" }
    },
    "required": ["city", "date"]
  }
}

模型生成工具调用：

{
  "name": "get_weather",
  "arguments": {
    "city": "北京",
    "date": "2026-05-17"
  }
}

应用层执行天气 API，得到：

{
  "city": "北京",
  "date": "2026-05-17",
  "weather": "小雨",
  "temperature": "16-22C",
  "air_quality": "良",
  "wind": "3级"
}

模型再回答：

明天北京有小雨，气温 16-22C，空气质量良，风力 3 级。可以跑步，但建议选择雨停时段，穿防滑鞋，路线尽量避开积水路面。如果你只是想轻松慢跑，室内跑步机可能更稳妥。

这个流程里，模型没有自己查询天气。它只是根据问题生成了工具调用请求，应用程序执行工具，再让模型解释结果。

常见误解

误解 1：模型会直接执行函数

通常不会。模型生成的是结构化调用意图，真正执行由应用程序完成。这个边界非常重要，因为执行层必须做权限、验证、日志和错误处理。

误解 2：函数调用一定可靠

不一定。模型可能选错工具、漏填参数、填错参数、误解用户意图，或者在工具失败后错误解释结果。

Structured Outputs 和更好的 schema 能提高可靠性，但不能替代业务校验。

误解 3：工具越多越好

工具太多会增加模型选择难度，也增加安全风险。工具应该按任务场景精简，命名清楚，描述具体，参数少而明确。

一个工具库不是越大越强，而是越清晰越可靠。

误解 4：工具调用可以无条件自动执行

读取类工具可以相对自动，写入类和高风险工具应该谨慎。例如：

操作	建议
查询天气	可自动执行
检索文档	可自动执行，但要做权限过滤
运行只读 SQL	可在沙箱或只读权限下执行
发送邮件	执行前确认
删除文件	强确认或禁止
转账付款	多重确认和审计
修改生产数据库	严格审批，通常不应自动执行

误解 5：有 Function Calling 就不需要 prompt

仍然需要。系统提示词要说明工具使用原则、何时拒绝、何时询问用户、如何处理工具错误、如何引用工具结果。

工具 schema 也可以看作一种 prompt，只不过它是结构化的 prompt。

未来趋势

1. 从函数调用到工具生态

早期 function calling 更像“让模型调用我写的几个函数”。未来会发展成更完整的工具生态：搜索、文件、浏览器、数据库、企业系统、代码执行、图像处理、音频处理都可以作为工具接入。

模型不只是调用单个函数，而是组合工具完成任务。

2. 更严格的结构化输出

结构化可靠性会越来越重要。生产系统需要模型输出能被程序稳定解析的结果，而不是偶尔格式漂移。

Structured Outputs、JSON Schema、类型系统、返回值 schema、自动校验和重试机制都会更常见。

3. 工具权限和安全策略

工具使用会带来新的安全问题：

• prompt injection 诱导模型调用危险工具；
• 恶意网页或文档污染工具结果；
• 工具参数被构造为攻击 payload；
• 模型越权访问数据；
• 多个低风险工具组合出高风险行为。

未来工具平台会更重视权限分级、沙箱、审计、用户确认、速率限制和安全策略。

4. MCP 与标准化接口

不同模型、不同应用、不同工具之间需要通用协议。MCP 这类协议的出现，正是为了减少“每个工具都要为每个平台单独接一遍”的成本。

Function Calling 解决单个模型如何请求工具；MCP 更关注模型应用如何标准化连接许多外部工具和数据源。

5. Tool Use 成为 Agent 基础设施

Agent 要完成长期任务，必须能可靠使用工具。未来 Agent 平台会把 tool use、状态管理、工作流、人类确认、日志追踪、评估和安全合在一起。

Function Calling 会从一个 API 特性，逐渐变成 AI 应用基础设施的一部分。

小结

• Function Calling / Tool Use 让模型把自然语言意图转成结构化工具调用。
• 模型通常不亲自执行函数，而是生成调用请求，由应用层执行。
• 工具 schema 是模型使用工具的说明书，设计质量直接影响可靠性。
• 工具调用循环包括：用户问题、模型选择工具、生成参数、应用执行、返回结果、模型继续回答。
• Function Calling 适合实时查询、企业系统集成、结构化抽取、代码执行、RAG 检索和 Agent 行动。
• Structured Outputs 提高了模型输出符合 JSON Schema 的可靠性。
• Function Calling 是 Agent 的底层能力之一，但不等于 Agent。
• 工具越强，越需要权限控制、人工确认、日志审计和沙箱。
• 未来趋势是工具生态、标准化接口、结构化可靠性、安全策略和 Agent 基础设施。

参考资料

• OpenAI, ChatGPT plugins, 2023: https://openai.com/blog/chatgpt-plugins
• OpenAI, Function calling and other API updates, 2023: https://openai.com/index/function-calling-and-other-api-updates/
• OpenAI Docs, Function calling: https://platform.openai.com/docs/guides/function-calling
• OpenAI, Introducing Structured Outputs in the API, 2024: https://openai.com/index/introducing-structured-outputs-in-the-api/
• OpenAI, New tools for building agents, 2025: https://openai.com/index/new-tools-for-building-agents/
• OpenAI API Reference, Responses: https://platform.openai.com/docs/api-reference/responses/create
• Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022: https://arxiv.org/abs/2210.03629
• Timo Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools, 2023: https://arxiv.org/abs/2302.04761
• Anthropic Docs, Tool use with Claude: https://docs.claude.com/en/docs/tool-use
• Anthropic, Claude can now use tools, 2024: https://claude.com/blog/tool-use-ga
• Google AI for Developers, Function calling with the Gemini API: https://ai.google.dev/gemini-api/docs/function-calling
• Mistral AI Docs, Function Calling: https://docs.mistral.ai/capabilities/function_calling