Function Call大模型从“聊天机器人”到“执行系统”的关键跃迁在大模型爆发之后很多人都有一个误解“AI 现在已经什么都能做了”但真实情况是大模型本身不会查数据库不会调用 API也不会操作业务系统它只是——会“说话”的大脑而真正让 AI 从“会说话”变成“会干活”的能力就是今天的主角⚙️ Function Call函数调用一、Function Call 到底是什么一句话讲清楚Function Call 让模型学会“选择工具 生成结构化调用指令”它不是执行代码而是输出“该调用哪个工具 参数是什么”举个最直观的例子用户说帮我查一下上海天气普通模型会回答上海今天晴28℃但 Function Call 模式下{function:get_weather,arguments:{city:上海,date:today}}然后系统去真正调用 API。二、Function Call 的本质如果只用一句话总结Function Call 大模型 外部系统的“连接协议”它解决了三件事✔ 1. 不再“编数据”减少幻觉✔ 2. 可以连接真实系统API/数据库✔ 3. 从回答问题 → 变成执行任务三、关键问题模型是怎么学会 Function Call 的答案是不是天生能力是训练出来的训练分为两个核心阶段SFT监督微调、RLHF用反馈简历边界感第一阶段SFTSupervised Fine-Tuning监督微调手把手教模型“怎么调用工具”用户输入查一下订单 12345标准答案{function:get_order_status,arguments:{order_id:12345}}模型在 SFT 学什么它学三件事✔ 1. 判断是否需要工具✔ 2. 选择正确工具✔ 3. 按 JSON 格式输出参数 SFT 本质一句话模仿学习“工具调用模板”第二阶段RLHFReinforcement Learning from Human Feedback人类反馈强化学习解决一个关键问题模型会“乱用工具”教会什么时候调用❌ 典型问题问“你好” → 调 API ❌问“11” → 查计算器 ❌RLHF 怎么修正流程是① 生成多个回答② 人类选择更好的③ 训练奖励模型Reward Model④ 优化模型行为 RLHF 本质一句话教模型“什么时候不该调用工具”四、训练完成后运行时发生了什么Function Call 真正的工作发生在“运行阶段”。⚙️ 标准运行流程用户输入 ↓ 大模型理解意图 ↓ 判断是否需要工具 ↓ 输出 Function CallJSON ↓ 系统执行 API / 数据库 ↓ 返回结果 ↓ 再次交给模型生成自然语言注意一个关键点模型只负责两件事判断要不要用工具生成调用结构真正执行的是系统API数据库搜索引擎业务系统五、完整闭环示例非常重要 用户输入帮我查订单 12345模型输出{function:get_order_status,arguments:{order_id:12345}}⚙️ 系统执行{status:运输中,location:上海仓,eta:2026-06-28}模型最终回答你的订单 12345 当前正在运输中已到达上海仓预计 6 月 28 日送达。六、Function Call 的工程价值它在真实系统中带来三个巨大变化1. 从“聊天”变成“系统入口”AI 不再只是回答问题而是成为所有系统的统一入口 2. 打通所有业务系统可以连接电商订单企业ERP数据库搜索引擎工单系统 3. 迈向 AI AgentFunction Call 是 Agent 的核心能力之一Agent 规划 决策 工具调用七、Function Call 的本质总结非常关键如果一定要用一句话总结Function Call 不是让 AI 更聪明而是让 AI “可执行”最终理解 SFT教会模型“怎么调用” RLHF教会模型“什么时候调用” Runtime系统负责“真正执行”八、模型是如何知道有哪些工具并且选择执行看完整篇文章肯定有人会问那么模型是如何知道有哪些工具并且进行调用的呢是每一次都将我们能够实现哪些接口api一起发送吗答案是❌ 不是每次都“完整携带工具说明书”✅ 但“工具信息一定会以某种形式参与每次请求”先纠正一个关键误解“工具说明书”本质是tools schema工具定义比如{name:get_weather,description:获取天气,parameters:{...}}误解是每次请求都把所有 tools 再发一遍实际上不是这么简单。真实工程中工具是“随请求注入的上下文”标准 API 调用结构是这样用户输入 工具列表 → 一起发给模型例如{messages:[{role:user,content:查一下上海天气}],tools:[{name:get_weather,description:获取城市天气},{name:get_order_status,description:查询订单}]}但是不是每一次都是全部发送一般有几种常见模式⚙️ 工程上有 3 种常见模式模式 1静态工具注入最常见每次请求都带完整 tools特点简单可靠适合小系统缺点tools 多了 token 爆炸性能浪费模式 2动态工具选择更高级系统会先做一步 Tool Retrieval工具检索只选“可能相关的工具”例如用户问天气只给get_weather不会给order APIdatabase APICRM API架构用户问题 ↓ 工具检索embedding / rules ↓ 筛选 Top-K tools ↓ 发送给 LLM模式 3Agent式工具管理最先进 tools 不直接全部传给模型而是模型先说我需要 weather 能力系统再补充好我给你 weather tool schema类似LLM我要用天气工具 系统好这里是天气工具说明 LLM输出 function call为什么必须“带工具信息”因为模型本身❌ 不知道这些 API 存在❌ 不知道参数结构❌ 不知道调用规则所以必须在上下文中告诉它 工具信息的作用是✔ 1. 告诉模型“你有哪些手可以用”✔ 2. 告诉模型“每只手怎么用”✔ 3. 限制输出结构JSON schema 九、一个完整真实流程工业级Step 1用户提问 Step 2系统选择 tools可能过滤 Step 3组装 prompt tools Step 4发送给 LLM Step 5LLM 输出 function call Step 6系统执行 API Step 7回填结果 Step 8LLM 输出最终答案再升级一个认知很重要tools 本质不是“固定配置”而是动态上下文的一部分Context Augmentation
