Function Calling是大模型与外部工具交互的关键机制如同为模型配备钥匙使其能够执行特定任务并返回结果。文章通过实例详细解析了Function Calling的工作流程强调了模型仅负责决策调用哪个函数及参数实际执行由应用程序完成。此外文章还介绍了JSON Schema在定义工具中的作用以及新手在使用Function Calling时容易遇到的问题和解决方法。通过学习Function Calling程序员可以更好地利用大模型的能力实现更复杂的应用场景。Function Calling—让大模型调用外部工具的机制。你可以把大模型想象成一个只会在房间里走来走去的聪明人它智商很高但出不了门、碰不到东西。Function Calling 就是给他的一把把钥匙。每把钥匙对应一扇门门后是一个真实世界的服务。模型学会判断现在该用哪把钥匙然后交给外面的人去开门、拿东西、再回来汇报。从一个最朴素的例子开始你问模型“北京今天天气怎么样”如果大模型没有工具它会怎么答大概率是“我查不到实时天气建议你打开天气 App 看看。”这回答没错但没用。现在给模型配一个get_weather工具再问同样的问题事情就不一样了。模型看到问题后会想“用户问的是北京今天天气。我有一个get_weather工具可以查实时天气需要传入城市名。我应该调用它。”于是它不直接回答你而是输出一段类似这样的东西{ name:get_weather, arguments:{city:北京} }你的程序拿到这段请求真的去调用天气 API得到结果{city:北京,weather:晴,temperature:28°C}然后再把这个结果喂回给模型。模型这时才给出最终回答“北京今天晴天气温 28°C适合出门。”整个过程分成了两步先调用工具再基于工具结果回答。Function Calling 就是连接这两步的协议。Function Calling 不是模型在执行代码这一点很多人会误解。看到模型输出一个函数调用就以为模型自己跑到服务器上去执行了。不是的。模型只负责决定调用哪个函数、传什么参数。真正执行函数的是你的应用程序。模型输出的那段 JSON只是一个调用请求你的代码负责解析这个请求、执行真实逻辑、把结果返回。这个设计很巧妙因为它把决策和执行分开了模型做它擅长的事理解意图、判断该用什么工具、组织参数你的程序做它擅长的事访问数据库、调 API、执行本地命令、保证安全如果让模型自己执行代码安全和可控性都是灾难。Function Calling 在让模型更强大和保持系统可控之间找了个平衡点。JSON Schema工具说明书要让模型知道有哪些工具可用你得给它一份说明书每个工具一份。行业里基本都用 JSON Schema 来描述。以天气工具为例说明书长这样{ type:function, function:{ name:get_weather, description:查询指定城市的实时天气, parameters:{ type:object, properties:{ city:{ type:string, description:城市名称例如北京、上海 }, date:{ type:string, description:日期格式 YYYY-MM-DD例如2026-08-28 } }, required:[city] } } }这里面的每个字段都有用name函数名要唯一、好懂。description自然语言描述模型就是靠这个判断什么时候该用这个函数。写得越清楚模型判断越准。parameters参数列表包括类型、含义、是否必填。required哪些参数必须传。description 是最容易被忽视的也是最重要的。 你如果写得太模糊模型会乱调用写得太具体它该调的时候又可能不敢调。举个例子你有两个函数search_company_info(company_name)查公司工商信息search_news(query)查新闻如果用户问小米最近有什么新闻模型看到search_news的描述就会调用它如果问小米公司注册资本是多少它应该调用search_company_info。描述写准了模型不会张冠李戴。一次真实交互长什么样把上面讲的东西串起来一次 Function Calling 的完整交互如下第 1 步系统提示里注册工具你把所有工具的 JSON Schema 一次性告诉模型。注意是告诉不是让它记——每次请求都要带因为模型无状态。第 2 步用户提问用户“北京今天天气怎么样”第 3 步模型判断需要调用工具模型发现用户问的是天气自己手里有get_weather于是输出{ name:get_weather, arguments:{city:北京,date:2026-08-28} }第 4 步程序执行函数你的代码解析这个 JSON调用真实的天气 API拿到结果。第 5 步把结果回灌给模型你把函数执行结果包装成一条工具返回消息放进新的请求里{ role:tool, tool_call_id:call_001, content:北京今天晴28°C }第 6 步模型给出最终回答模型看到结果后用自然语言回答用户“北京今天晴天28°C。”这就是标准流程。Function Calling 本质上是一个模型请求 → 程序执行 → 结果回灌 → 模型再回答的协议。新手最容易栽的几个地方Function Calling 看似简单但实际落地时坑不少。我列几个最常见的坑一description 写得太潦草我见过有人把工具描述写成“用于查询”。模型看了根本不知道查什么结果该调不调、不该调乱调。描述要回答三个问题这个工具是干什么的、什么时候用、参数是什么意思。坑二参数类型对不上Schema 里写date是 string模型却可能给你传今天而不是2026-08-28。你不做校验直接传进 API大概率报错。Function Calling 不是银弹模型也会猜错参数值尤其是时间、数字这种需要格式化的东西。坑三函数返回 unstructured 文本工具返回的内容如果是一段乱七八糟的字符串模型很难从中提取有效信息。建议返回结构化数据JSON模型处理起来稳定得多。坑四不处理函数调用失败真实世界里 API 会超时、会限流、会返回 500。你不处理模型下一轮就会基于错误信息继续瞎跑。每次执行函数后都要给模型一个明确的成功/失败结果。失败了可以让模型重试或者告诉用户查询失败。坑五工具太多导致模型选择困难一次性给模型注册二三十个工具它可能选错。工具数量多的时候要做好分类或者在 prompt 里明确告诉它先选哪一个类别的工具。Function Calling 跟 Agent 是什么关系很多人把这两个概念混在一起其实关系很清楚Function Calling 是一种能力Agent 是一种架构。Function Calling 让大模型可以伸出一只手去调用外部工具。Agent 则是在这个能力之上加上循环、记忆、规划让模型能完成多步任务。你可以这么理解单个 Function Calling模型决定调用一次工具然后回答。像问天气这种一轮就结束的场景。Agent模型决定调用一次工具看到结果再决定第二次调用再看到结果……直到任务完成。像订餐厅、做旅行规划这种多轮场景。所以上一篇讲的 ReAct 循环每一轮循环里都会发生一次或多次 Function Calling。Function Calling 是 Agent 这台机器里的传动轴负责把模型的决策翻译成实际动作。一个最小可运行示例为了让你有体感下面给一个 Python 伪代码示例展示 Function Calling 的主循环骨架import json defget_weather(city): # 真实项目里这里调天气 API return {city: city, weather: 晴, temperature: 28°C} tools [{ type: function, function: { name: get_weather, description: 查询指定城市实时天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } }] messages [ {role: system, content: 你可以调用工具帮助用户。}, {role: user, content: 北京今天天气怎么样} ] # 第一次调用模型 response model.chat(messages, toolstools) # 如果模型要求调用工具 if response.tool_calls: tool_call response.tool_calls[0] fn_name tool_call.function.name args json.loads(tool_call.function.arguments) # 执行本地函数 result globals()[fn_name](args) # 把结果塞回 messages messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 第二次调用模型让它基于结果回答 final model.chat(messages, toolstools) print(final.content)这个骨架抓住了 Function Calling 的核心模型判断、程序执行、结果回灌、再生成回答。真实项目里会在这个骨架上加入错误处理、多工具管理、重试机制、日志追踪但万变不离其宗。一次要调多个工具以及工具之间要传话真实业务里模型经常需要一次调用多个工具。比如用户问帮我对比北京和上海今天谁更热顺便看看这两个城市未来三天的机票哪个便宜这背后至少涉及两个工具查天气、查机票。模型可以并行决定两个都调你的程序拿到两个结果后一起喂回去模型再做综合回答。在协议层面模型返回的tool_calls可以是一个数组而不是单个对象——它一次说我要调这两个{ tool_calls:[ {function:{name:get_weather,arguments:{/city/: /北京/}}}, {function:{name:get_weather,arguments:{/city/: /上海/}}} ] }你的程序拿到这个数组可以并行跑两个工具各起一个请求再把两个结果都塞回对话。这比调完一个再调下一个快得多。更复杂的情况是工具之间要传话工具 A 的返回结果是工具 B 的输入。比如查订单 → 拿到订单里的商品 ID → 用商品 ID 查库存。这种链式调用模型自己会处理它先调 A看到结果里有商品 ID下一轮决策时就拿着这个 ID 去调 B。你的程序要做的还是那套执行 → 回灌 → 再决策的循环只不过循环里会出现一连串工具调用。这也是 Agent 能完成复杂任务的根本机制——Function Calling 是单步的把单步串成链就成了 Agent。写好 Function Calling 的五个要点讲了这么多给你一份我自己写工具时常对照的清单照着做能避开大部分新手坑一、description 写给模型看不是写给人看。 模型没有你的业务背景它只会读你写的字。把这个工具干啥的、什么时候该用、输入是什么、输出是什么用模型能听懂的大白话写清楚。宁可啰嗦别含蓄。二、参数 schema 越严越好。 能用枚举enum就别用自由字符串能用数字范围约束就别开放区间required 字段列全。约束越死模型乱填的概率越低你后端解析越省心。三、永远校验参数再执行。 模型给的 arguments 可能是非法 JSON、可能是类型不对、可能是你业务里不存在的值。执行工具前必须做一层校验和兜底别把模型的随口一说直接丢进你的数据库查询。四、工具失败要返回结构化错误。 工具执行失败时别只回一句失败了。返回清晰的错误信息哪一步错、为什么错、能不能重试模型才能据此调整参数再试一次。返回调用失败四个字模型大概率会原地重试同样的错误。五、控制工具数量和粒度。 一次性塞给模型二三十个工具它会选择困难调用准确率下降。按场景分批给工具每个工具职责单一、边界清晰比堆一大坨杂糅工具效果好得多。把这五条记牢你搭出来的 Function Calling 就具备了上生产的基本素质。剩下的都是在具体业务里打磨参数、调提示词、加监控。从调不通到调得稳讲完设计最后给一套我实际排错时用的套路。Function Calling 第一次接不通八成是卡在这几个地方第一模型压根不调工具。 现象是你明明给了工具它却每次都直接回答、不动手。先查三件事工具的description是不是写得太模糊模型没意识到这工具能解决这个问题tools 参数有没有真的传进 API 调用很多人代码里忘了把 tools 带上去还有是不是你在系统提示词里下了不要使用任何工具之类的反指令。第二调了工具但参数填错。 比如该传数字的地方传了字符串该传城市名的地方传了北京市多了个市字你的接口只认北京。这种最隐蔽。对策是把参数 schema 写严并在执行前做一层类型转换和归一化。比如城市名统一 trim、统一去掉市字再查表。第三工具返回了模型却看不见。 你明明把结果塞回了 messages它下一轮却像没收到。常见原因是回灌的格式不对——Function Calling 要求工具结果用固定的 roletool和tool_call_id挂回去你如果随手塞进一条普通 user 消息模型就识别不出这是上一步工具的执行结果。第四反复调同一个工具死循环。 模型调了工具 A拿到结果又调 A又拿结果转了五六圈不出循环。这通常是提示词没给它什么时候算完成的明确标准。加一句如果已经拿到足够信息就直接回答用户不要再调用工具能解决大部分。调试时有个很实用的小技巧把每次的 tools 定义、模型返回的 tool_calls、你实际执行的参数、工具的返回结果全部打印成日志。Function Calling 是个多步协议任何一步出错都会表现为答非所问光看最终输出是定位不到的。日志拉出来哪一步歪了一目了然。把这十节看完你对 Function Calling 的理解已经从听说过走到了能独立接上线、调通、排错。它是 Agent 的钥匙也是你迈入更复杂 AI 应用的门把手。什么时候不该用 Function Calling前面一直在讲它多好用这节泼点冷水——有些场景硬上 Function Calling 反而是给自己找麻烦。第一流程是死的就别让它决策。 如果你的业务逻辑是固定的用户下单 → 查库存 → 扣款 → 发通知每一步都是写死的那直接用普通代码串起来就行又快又稳又便宜。让模型来决定调哪个工具等于把确定的事交给一个概率系统徒增不确定性和成本。第二工具很少且每次必用也不用走模型判断这一步。 比如你就是想每次都先查一次天气再回答那直接在代码里固定调用天气接口、把结果拼进提示词即可没必要让模型去决定要不要调——它每次都会调这个决策是多余的。Function Calling 真正的价值在多工具、按需选择工具少到没得选时它的优势体现不出来。第三对延迟极度敏感的场景。 每次 Function Calling 至少多一轮模型调用模型先判断 → 你执行 → 模型再回答比普通问答慢几百毫秒到几秒。做实时性要求高的服务比如高频交易的即时报价这个延迟可能不可接受得换成预编译好的确定性逻辑。一句话总结Function Calling 是把不确定交给模型、把确定留给自己的桥梁。当你的场景里不确定的部分很少这座桥反而是累赘。 用对地方它是钥匙用错地方它是枷锁。Function Calling 的价值在于它让大模型从会说话进化到能动手。但动手的是你的程序不是模型本身。模型只负责决定拿什么钥匙开哪最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】