Function Calling 是什么？一文讲清它和 Agent 的关系

在大模型应用开发里，Function Calling 是一个非常核心的能力。很多人第一次接触它时，都会有几个典型疑问：

• Function Calling 是不是让 LLM 直接去调用函数？
• 模型支持 Function Calling 后，是不是会按固定格式返回？
• Agent 框架是不是就是靠解析这个响应，再去执行工具调用？
• Function Calling 和 Agent 到底是什么关系？

这篇文章就把这些问题一次讲清楚。

---

一、什么是 Function Calling

先说结论：

Function Calling 不是让 LLM 真的去执行函数，而是让 LLM 能够以结构化的方式表达“我想调用哪个函数，以及需要什么参数”。

真正执行函数的，不是模型本身，而是你的应用程序、后端服务，或者 Agent 框架。

也就是说，Function Calling 的本质是：

• LLM 负责理解用户意图
• LLM 决定是否需要调用某个工具
• LLM 生成结构化的调用请求
• 外部系统解析请求并执行真实函数
• 执行结果再返回给 LLM
• LLM 基于结果继续回答用户

所以它更像是一种：

“模型发起调用意图，系统负责真正执行”的机制。

---

二、为什么需要 Function Calling

普通对话模型虽然能回答很多问题，但它本身并不具备真实的外部操作能力，比如：

• 不能直接查数据库
• 不能直接访问内部系统
• 不能直接调用天气 API
• 不能直接执行支付、下单、发邮件等动作

如果只靠自然语言回答，模型最多只能“假装知道”。
但在真实业务里，我们希望模型不仅能“说”，还要能“做”。

这时候就需要 Function Calling。

它让模型具备了一种标准化的“调用外部能力”的方式，比如：

• 查询天气
• 搜索商品
• 获取订单信息
• 读写知识库
• 调用企业内部接口
• 控制代码执行工具

---

三、Function Calling 的工作流程

一个典型流程如下：

1. 开发者先定义可用函数

你会把一组工具告诉模型，例如：

• get_weather(city, date)
• query_order(order_id)
• search_docs(keyword)

同时还要描述每个函数的参数含义、类型、是否必填等信息。

2. 用户发起请求

例如用户说：

帮我查一下上海明天的天气

3. 模型判断是否需要调用函数

模型分析后发现，这个问题不是单靠语言能力就能回答，它需要访问天气服务。

于是它不会直接编造天气，而是返回一个结构化的调用意图，比如：

{
  "name": "get_weather",
  "arguments": {
    "city": "上海",
    "date": "2026-04-01"
  }
}

4. 外部系统解析响应

你的程序或 Agent 框架会检查模型响应：

• 是否请求了函数调用
• 要调用哪个函数
• 参数是否完整合法

5. 外部系统执行真实函数

然后由你的代码真正执行：

get_weather(city="上海", date="2026-04-01")

6. 将执行结果返回给模型

比如函数返回：

{
  "city": "上海",
  "date": "2026-04-01",
  "weather": "多云",
  "temperature": "18~24℃"
}

7. 模型组织最终回答

模型再基于工具结果回答用户：

上海明天多云，气温 18 到 24 摄氏度。

---

四、模型支持 Function Calling 后，会按固定格式响应吗？

答案是：

会按“结构化协议”响应，但具体字段格式不一定完全一样。

这是很多人容易混淆的地方。

1. 从本质上看，是固定格式

支持 Function Calling 的模型，一般不会只返回一段随意自然语言，而是会输出一段带有明确语义的结构化内容，例如：

• 调用的函数名
• 对应的参数
• 有时是一个工具调用列表
• 有时还会附带文本内容

所以从思想上说，它的确是“按规范格式响应”的。

2. 从具体 API 看，不同平台不完全一样

不同厂商、不同版本 API，格式字段可能不同，例如：

• 有的叫 function_call
• 有的叫 tool_calls
• 有的把参数放在 JSON 字符串里
• 有的框架会再封装成自己的中间对象

因此不能简单理解成：

“所有模型永远都返回同一个 JSON 结构”。

更准确地说是：

模型会按照当前平台约定的结构化协议，输出工具调用意图。

---

五、Function Calling 和普通 JSON 输出有什么区别

很多人会说：

“那我直接让模型输出 JSON 不就行了吗？”

表面上看很像，但其实差别很大。

普通 JSON 输出

只是提示模型：

请你按 JSON 格式回答

问题是：

• 模型可能格式不稳定
• JSON 可能不严格合法
• 系统并不知道这个 JSON 是“描述信息”还是“要求执行动作”
• 没有明确的工具调用语义

Function Calling

这是 API 层明确支持的能力，模型知道：

• 当前有哪些工具可用
• 何时应该调用工具
• 要以什么结构表达调用意图

因此 Function Calling 比“手搓 JSON”更可靠，优势在于：

• 结构更稳定
• 工具语义更明确
• 更方便框架自动解析
• 更适合多轮调用和 Agent 编排

---

六、谁来执行函数？LLM 还是 Agent？

这里必须明确：

不是 LLM 执行函数，而是外部系统执行。

LLM 的职责是：

• 理解问题
• 选择工具
• 生成参数
• 根据工具结果继续推理

真正执行函数的是：

• 你的后端代码
• 业务服务
• 工具运行时
• Agent 框架

所以可以把职责拆成三层：

1. LLM

负责“思考”和“决策”：

• 要不要调用工具
• 调哪个工具
• 参数应该是什么
• 工具结果怎么解释

2. Agent 系统 / Orchestrator

负责“调度”：

• 解析模型输出
• 找到对应工具
• 执行函数
• 处理错误、重试、状态
• 把结果回传给模型

3. Tool / Function

负责“真正干活”：

• 调 API
• 查数据库
• 搜索知识库
• 执行代码
• 调用企业内部服务

---

七、Agent 框架和 Function Calling 的关系

可以这么理解：

Function Calling 是 Agent 具备“行动能力”的基础接口之一。

Agent 框架本质上做的事情，大多就是围绕这个闭环展开：

1. 把可用工具注册给模型
2. 把用户问题发给模型
3. 判断模型是否请求调用工具
4. 解析函数名和参数
5. 执行对应工具
6. 把工具结果继续发回模型
7. 直到模型输出最终答案

所以很多 Agent 框架，例如 LangChain、LlamaIndex、AutoGen、Semantic Kernel 等，本质上都在做类似的事情：

• 工具注册
• 调用编排
• 上下文管理
• 多轮推理
• 错误处理
• 状态维护

换句话说：

Function Calling 解决的是“模型如何表达调用意图”，Agent 框架解决的是“系统如何把这个意图变成实际行动”。

---

八、一个简单示例帮你彻底理解

我们用一个最简单的例子说明。

用户输入

帮我查询订单 123456 的状态

模型已知工具

{
  "name": "query_order",
  "description": "查询订单状态",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单编号"
      }
    },
    "required": ["order_id"]
  }
}

模型返回的调用意图

{
  "name": "query_order",
  "arguments": {
    "order_id": "123456"
  }
}

系统执行真实函数

result = query_order(order_id="123456")

函数返回结果

{
  "order_id": "123456",
  "status": "已发货",
  "tracking_no": "SF987654321"
}

模型生成最终答案

订单 123456 当前状态为“已发货”，快递单号是 SF987654321。

从头到尾，模型都没有真的去数据库查订单。
它只是：

• 识别出需要工具
• 生成了调用参数
• 再根据工具结果组织回答

---

九、Function Calling 的价值在哪里

在工程实践里，Function Calling 的价值非常大，主要体现在下面几个方面。

1. 让模型从“会说”变成“能做”

没有工具能力的 LLM，只能停留在语言层面。
有了 Function Calling，模型就能驱动真实系统完成任务。

2. 降低幻觉

比如查天气、查订单、查价格这类问题，如果让模型直接回答，容易编造。
而通过工具调用，结果来自真实系统，可信度更高。

3. 便于系统集成

Function Calling 让 LLM 更容易接入现有业务系统，比如：

• CRM
• ERP
• 工单系统
• 数据分析平台
• 内部搜索平台

4. 是构建 Agent 的关键基础

很多所谓“智能体”，本质能力都来自：

• 推理
• 记忆
• 工具调用

其中工具调用最核心的技术承载形式之一就是 Function Calling。

---

十、Function Calling 的局限和注意点

虽然它很重要，但也不能神化。

1. 模型会选错工具

模型可能判断错误，调用不合适的函数。

2. 参数可能不准确

比如用户表达模糊，模型可能生成错误参数。

3. 需要外部系统做校验

不能因为模型给了参数，就直接无脑执行。通常要做：

• 参数校验
• 权限校验
• 风险控制
• 异常处理

4. 并不是所有场景都需要 Agent 框架

如果只是简单单工具调用，其实自己写一个循环就够了。
不一定非要上复杂框架。

---

十一、如何理解它和 Agent 的分工

如果用一句话概括：

Function Calling 负责“表达动作”，Agent 负责“执行动作并管理流程”。

再直白一点：

• Function Calling：告诉系统“我想做什么”
• Agent：真的把这件事做掉，并决定下一步怎么办

所以两者关系不是替代关系，而是协作关系。

---

十二、总结

最后做个总结。

Function Calling 的本质，不是让 LLM 直接执行函数，而是让 LLM 能够以结构化形式输出“工具调用意图”。模型会根据用户请求，决定是否需要调用工具，并生成对应的函数名和参数。随后，由外部程序、Agent runtime 或 Agent 框架去解析这个响应，执行真实函数，再把结果返回给模型，最后由模型生成自然语言答案。

因此：

• LLM 负责决策
• Function Calling 负责结构化表达
• Agent 系统负责解析、执行和编排

如果你要做大模型应用，尤其是工具型应用、企业智能助手、代码 Agent、工作流 Agent，那么 Function Calling 基本上是绕不过去的一层核心能力。

Function Calling 让 LLM 学会“开口下指令”，而 Agent 系统让这些指令真正落地执行。

---