AI-Agent 中 Function-Calling 机制技术报告

主题：外部工具如何被大模型理解，以及大模型如何学习 Function-Calling 能力
日期：2026-06-30
适用对象：AI-Agent 初学者、应用开发者、技术方案撰写者

1. 摘要

在 AI-Agent 中，Function-Calling 的核心作用是：把外部工具能力转换成大模型可以理解、可以选择、可以填参的结构化接口说明。大模型本身并不会直接运行外部 API、数据库或业务系统，它只是根据工具描述和用户意图，生成一段结构化的调用请求；真正执行工具的是 Agent 框架或后端程序。

大模型学习 Function-Calling 能力，也不是学习某个外部函数内部的业务代码，而是学习一种映射能力：

用户自然语言请求 + 工具说明 + 参数 Schema + 当前上下文 → 是否调用工具 + 调用哪个工具 + 参数如何填写 + 如何整合工具返回结果

因此，Function-Calling 可以被理解为 AI-Agent 的“动作接口层”：它让语言模型从“只会说话”扩展到“能够调用外部系统完成任务”。

2. 问题一：Function-Call 如何把外部工具变成大模型可以理解的方式？

2.1 核心观点

Function-Call 并不是把外部工具的代码直接塞进大模型，也不是让模型真正获得外部系统的执行权限。它做的是一件“翻译”工作：

外部工具 / API / 数据库 / 业务系统 → 工具名称 + 自然语言描述 + 参数结构 + 参数约束 → 大模型可读的工具说明

模型理解的是工具的“能力说明”和“参数格式”，不是工具内部实现。

2.2 工具注册：把外部工具写成模型可读的 Schema

例如，真实业务中可能有一个天气查询函数：

defget_weather(city:str,unit:str="celsius"):...

大模型不能直接理解这个函数的运行环境、鉴权方式、网络请求方式或数据库连接方式。因此，在 Agent 中通常需要把它包装成结构化工具说明：

{"type":"function","name":"get_weather","description":"查询指定城市的当前天气","parameters":{"type":"object","properties":{"city":{"type":"string","description":"要查询天气的城市名称"},"unit":{"type":"string","enum":["celsius","fahrenheit"],"description":"温度单位"}},"required":["city"]}}

这份说明告诉模型四件事：

2.3 运行链路：模型生成调用意图，后端负责执行

当用户输入：

今天上海天气怎么样？

模型不会真的去查天气，而是可能输出一个结构化工具调用请求：

{"name":"get_weather","arguments":{"city":"上海","unit":"celsius"}}

接下来，Agent 框架或后端程序读取这段调用请求，并执行真实函数：

result=get_weather(city="上海",unit="celsius")

如果工具返回：

{"city":"上海","temperature":29,"weather":"多云","humidity":"72%"}

模型再根据工具结果组织最终回答：

上海今天多云，气温约 29°C，湿度 72%，体感会有些闷热。

2.4 Function-Calling 的六步机制

其中，大模型主要负责：

1. 理解用户意图；
2. 判断是否需要工具；
3. 选择合适的工具；
4. 从用户输入中抽取参数；
5. 按 Schema 输出合法结构；
6. 将工具结果转化为自然语言回答。

后端主要负责：

1. 校验模型输出的函数名和参数；
2. 执行真实外部工具；
3. 处理权限、鉴权、网络请求和异常；
4. 把工具返回结果重新传给模型。

3. 问题二：大模型如何学习到 Function-Calling 能力？

3.1 核心观点

大模型学习 Function-Calling 能力，本质上是学习一种“自然语言任务到结构化动作”的转换能力。它学到的不是某个工具内部如何运行，而是：

什么情况下需要调用工具？ 应该调用哪个工具？ 参数应该从哪里来？ 输出格式应该是什么？ 工具结果回来后应该如何继续回答？

3.2 预训练：获得结构化文本和代码理解基础

在预训练阶段，大模型会接触大量自然语言、代码、JSON、API 文档、配置文件、函数声明等内容。因此，它天然具备一定的结构化文本理解能力。

例如，模型在预训练中可能见过大量类似内容：

{"city":"Shanghai","date":"today"}

也见过大量类似函数说明：

defsearch_product(keyword,price_min=None,price_max=None):...

这让模型具备了 Function-Calling 的底层语言基础：能理解函数名、参数名、JSON 结构和自然语言描述之间的关系。

但是，预训练只能提供基础能力，不能保证模型稳定地按照某个平台的工具调用协议输出。

3.3 监督微调 SFT：学习标准工具调用样本

监督微调会向模型展示大量“用户请求 → 正确工具调用”的样本。例如：

用户：帮我查一下订单 12345 的物流状态。 可用工具：get_order_status(order_id) 正确输出： { "name": "get_order_status", "arguments": { "order_id": "12345" } }

经过大量类似样本训练后，模型会逐渐学会：

3.4 强化学习与偏好优化：学习“该不该调工具”

只会生成 JSON 还不够，模型还必须学会“什么时候不要调用工具”。

例如：

用户：你是谁？

这个问题通常不需要工具。

而：

用户：查一下我这个订单到哪了。

这个问题通常需要调用订单查询工具。

训练系统可以对模型行为进行反馈：

通过这类训练，模型不仅学会“会不会写调用格式”，还会学会“何时行动、何时直接回答”。

3.5 工具使用轨迹数据：学习多步 Agent 行为

Agent 任务往往不是一次工具调用就能完成，而是多步流程。例如：

用户：帮我安排明天下午去上海的行程，并提醒我出发。

模型可能需要：

1. 查询日历是否有空； 2. 查询交通时间； 3. 创建提醒； 4. 汇总安排。

这类训练数据通常表现为“轨迹”：

用户问题 → 判断需要工具 → 调用工具 A → 读取结果 → 调用工具 B → 读取结果 → 生成最终回答

这种轨迹数据让模型学会把推理和行动交替进行，也就是 Agent 常见的“Reasoning + Acting”模式。

3.6 自监督和合成数据：扩展工具使用能力

除了人工标注，还可以通过模型自动生成候选工具调用，再用规则、执行结果或评价器筛选高质量样本。

基本流程是：

普通文本 → 模型尝试插入 API 调用 → 执行 API → 判断工具结果是否让后续预测更好 → 保留有效样本 → 继续训练模型

这种方法可以降低人工标注成本，让模型在更多工具场景下学习调用能力。

3.7 推理阶段：模型读取当前工具说明，而不是更新权重

当开发者在 Agent 中注册一个新工具时，例如：

{"name":"search_product","description":"根据关键词搜索商品","parameters":{"type":"object","properties":{"keyword":{"type":"string"},"price_min":{"type":"number"},"price_max":{"type":"number"}}}}

模型的参数权重并不会因此改变。它只是把这段工具说明作为上下文读取，然后临时判断：

这个工具是干什么的？ 用户问题是否需要它？ 需要填哪些参数？ 用户是否已经提供了这些参数？

因此需要区分：

4. 综合架构图

5. 开发实践建议

5.1 工具描述要清晰

工具的description不要只写“查询信息”，而应写清楚适用场景。例如：

{"name":"get_order_status","description":"根据订单号查询用户订单的物流状态、发货状态和预计送达时间"}

这样模型更容易判断什么时候该调用该工具。

5.2 参数设计要稳定

建议使用明确、可验证的参数类型：

{"order_id":{"type":"string"},"date":{"type":"string","description":"格式为 YYYY-MM-DD"},"unit":{"type":"string","enum":["celsius","fahrenheit"]}}

避免参数名过于模糊，例如value、info、data。

5.3 后端必须做校验和安全控制

模型输出的 function-call 不能被无条件信任。后端应当：

1. 校验工具名是否在白名单中；
2. 校验参数类型和必填字段；
3. 控制权限和用户身份；
4. 对高风险操作增加确认环节；
5. 处理工具异常和超时；
6. 避免把敏感信息直接暴露给模型或用户。

5.4 工具结果要适度压缩

工具返回的数据可能很长，例如数据库查询结果、搜索结果、日志结果等。直接把大量原始数据塞回模型可能导致上下文浪费和错误理解。

更好的做法是：

工具原始结果 → 后端过滤 / 排序 / 摘要 → 模型可读结果 → 最终回答

6. 结论

Function-Calling 是 AI-Agent 从“语言生成系统”走向“可执行任务系统”的关键机制。

它解决了两个核心问题：

1. 工具如何被模型理解：通过工具名称、自然语言描述、参数 Schema 和约束，把外部工具能力转化为模型可读的结构化接口。
2. 模型如何学会调用工具：通过预训练、监督微调、偏好优化、工具轨迹数据和合成数据，让模型学会从自然语言任务中判断工具需求、选择工具、生成参数并整合结果。

最终，Function-Calling 的本质可以概括为：

训练阶段：模型学会“如何把语言任务转成结构化动作”。 推理阶段：模型读取“当前有哪些工具”，并生成可执行的调用请求。 执行阶段：Agent 框架或后端真正运行工具，并把结果回填给模型。

换句话说，大模型是“前台调度员”，Function-Calling 是“派单系统”，外部工具才是真正执行任务的“业务部门”。

7. 参考阅读

1. OpenAI Developers：Function Calling / Tool Calling 官方文档。
2. Yao et al. (2022).ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.
3. Schick et al. (2023).Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761.
4. Patil et al. (2023).Gorilla: Large Language Model Connected with Massive APIs. arXiv:2305.15334.