主题外部工具如何被大模型理解以及大模型如何学习 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:strcelsius):...大模型不能直接理解这个函数的运行环境、鉴权方式、网络请求方式或数据库连接方式。因此在 Agent 中通常需要把它包装成结构化工具说明{type:function,name:get_weather,description:查询指定城市的当前天气,parameters:{type:object,properties:{city:{type:string,description:要查询天气的城市名称},unit:{type:string,enum:[celsius,fahrenheit],description:温度单位}},required:[city]}}这份说明告诉模型四件事字段对模型的作用name工具叫什么便于模型生成调用目标description工具能做什么便于模型判断是否需要调用parameters调用工具需要哪些参数type / enum / required参数类型、可选范围和必填约束2.3 运行链路模型生成调用意图后端负责执行当用户输入今天上海天气怎么样模型不会真的去查天气而是可能输出一个结构化工具调用请求{name:get_weather,arguments:{city:上海,unit:celsius}}接下来Agent 框架或后端程序读取这段调用请求并执行真实函数resultget_weather(city上海,unitcelsius)如果工具返回{city:上海,temperature:29,weather:多云,humidity:72%}模型再根据工具结果组织最终回答上海今天多云气温约 29°C湿度 72%体感会有些闷热。2.4 Function-Calling 的六步机制用户自然语言请求模型读取工具列表判断是否需要工具选择合适工具生成结构化参数 JSONAgent 后端执行真实工具工具结果返回模型模型生成最终回答其中大模型主要负责理解用户意图判断是否需要工具选择合适的工具从用户输入中抽取参数按 Schema 输出合法结构将工具结果转化为自然语言回答。后端主要负责校验模型输出的函数名和参数执行真实外部工具处理权限、鉴权、网络请求和异常把工具返回结果重新传给模型。3. 问题二大模型如何学习到 Function-Calling 能力3.1 核心观点大模型学习 Function-Calling 能力本质上是学习一种“自然语言任务到结构化动作”的转换能力。它学到的不是某个工具内部如何运行而是什么情况下需要调用工具 应该调用哪个工具 参数应该从哪里来 输出格式应该是什么 工具结果回来后应该如何继续回答3.2 预训练获得结构化文本和代码理解基础在预训练阶段大模型会接触大量自然语言、代码、JSON、API 文档、配置文件、函数声明等内容。因此它天然具备一定的结构化文本理解能力。例如模型在预训练中可能见过大量类似内容{city:Shanghai,date:today}也见过大量类似函数说明defsearch_product(keyword,price_minNone,price_maxNone):...这让模型具备了 Function-Calling 的底层语言基础能理解函数名、参数名、JSON 结构和自然语言描述之间的关系。但是预训练只能提供基础能力不能保证模型稳定地按照某个平台的工具调用协议输出。3.3 监督微调 SFT学习标准工具调用样本监督微调会向模型展示大量“用户请求 → 正确工具调用”的样本。例如用户帮我查一下订单 12345 的物流状态。 可用工具get_order_status(order_id) 正确输出 { name: get_order_status, arguments: { order_id: 12345 } }经过大量类似样本训练后模型会逐渐学会训练目标具体能力意图识别判断用户是否需要外部工具工具选择从多个工具中选择最合适的一个参数抽取从自然语言中抽取订单号、城市、时间等参数格式遵循按照 JSON Schema 输出合法结构结果整合根据工具返回结果生成自然语言回答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. 综合架构图推理阶段在 Agent 中使用工具用户请求模型决策工具 Schema生成 function call后端执行工具工具结果返回最终回答训练阶段获得 Function-Calling 能力预训练代码、JSON、API 文档SFT用户请求到工具调用样本偏好优化奖励正确调用、惩罚错误调用轨迹数据多步工具使用合成数据自动生成并筛选工具调用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 不能被无条件信任。后端应当校验工具名是否在白名单中校验参数类型和必填字段控制权限和用户身份对高风险操作增加确认环节处理工具异常和超时避免把敏感信息直接暴露给模型或用户。5.4 工具结果要适度压缩工具返回的数据可能很长例如数据库查询结果、搜索结果、日志结果等。直接把大量原始数据塞回模型可能导致上下文浪费和错误理解。更好的做法是工具原始结果 → 后端过滤 / 排序 / 摘要 → 模型可读结果 → 最终回答6. 结论Function-Calling 是 AI-Agent 从“语言生成系统”走向“可执行任务系统”的关键机制。它解决了两个核心问题工具如何被模型理解通过工具名称、自然语言描述、参数 Schema 和约束把外部工具能力转化为模型可读的结构化接口。模型如何学会调用工具通过预训练、监督微调、偏好优化、工具轨迹数据和合成数据让模型学会从自然语言任务中判断工具需求、选择工具、生成参数并整合结果。最终Function-Calling 的本质可以概括为训练阶段模型学会“如何把语言任务转成结构化动作”。 推理阶段模型读取“当前有哪些工具”并生成可执行的调用请求。 执行阶段Agent 框架或后端真正运行工具并把结果回填给模型。换句话说大模型是“前台调度员”Function-Calling 是“派单系统”外部工具才是真正执行任务的“业务部门”。7. 参考阅读OpenAI DevelopersFunction Calling / Tool Calling 官方文档。Yao et al. (2022).ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.Schick et al. (2023).Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761.Patil et al. (2023).Gorilla: Large Language Model Connected with Massive APIs. arXiv:2305.15334.