Function Calling:AI 是怎么学会「动手做事」的

「帮我查一下客户陈总的订单状态,再给他写封跟进邮件。」这句话发给两年前的 AI,你会得到一封措辞得体的邮件草稿,外加一句抱歉:它查不了订单,也发不了邮件。同样的话发给今天某些接好了系统的 AI 助手,几十秒后订单信息查到了,邮件也躺进了待发送列表。

从「会说」到「会做」,中间隔着的机制叫 function calling(函数调用)。名字很工程,原理其实一张纸就能讲完。

模型从头到尾没碰你的系统

很多人以为「AI 会操作系统了」是模型长出了手。恰恰相反,function calling 的设计核心是:模型不直接操作任何系统。它只做一件事——输出一张结构化的「操作申请单」,写明要调用哪个工具、参数是什么,比如「查订单,客户编号 C1024」。

申请单交给谁?交给模型外面的普通程序。真正连数据库、调接口、发邮件的,是这些常规软件;执行完,它们把结果交回给模型,模型再根据结果决定下一步——继续查、开始写,或者向人求助。整个过程像公司里的新员工:他不能自己进仓库拿货,只能填领料单,由仓管员核对后执行,再把货交到他手上。

一个例子,走完整个来回

回到开头那句指令。拆开看,它是两次独立的工具调用,中间夹着一段模型的「老本行」:

1. 模型读懂意图,发现自己缺订单信息,填出第一张申请单:调用「订单查询」,参数是客户编号。
2. 外部系统执行查询,把结果交回:最近一单三天前已发货,物流预计明天送达。
3. 模型拿着结果起草跟进邮件——这一步不需要任何工具,是它最擅长的部分。
4. 起草完,填第二张申请单:调用「发送邮件」,参数是收件人、主题、正文。至于要不要真的自动发出,取决于你给这个工具设的权限——不少企业会把这一步设计成「人点一下确认才发送」。

看清这个来回,就拿到了评估一切「AI 干活」产品的钥匙:所谓能力,是模型加上它被允许使用的工具。同一个模型,接了订单系统才查得了订单;工具越多,能办的事越多,风险敞口也越大。

为什么说它是 Agent 的地基

把「填单—执行—看结果—决定下一步」连续循环起来,让模型自主安排调用顺序、自己纠错,就是 AI Agent 的基本形态;企业里的自动化工作流同理,所谓「咨询自动分派」「报表自动汇总」,底层都是一串编排好的工具调用。没有 function calling,「AI 自动化」就无从谈起。

顺带一提:当要接的工具多起来,「工具怎么统一接入」会成为新问题,这正是 MCP 协议想解决的事,这里先按下不表。

边界设计:哪些申请单可以自动批

申请单机制给了企业一个天然抓手:权限不设在模型上,而设在工具上。从我们接触到的企业场景看,比较稳妥的做法是分三档管理。

只读操作——查订单、查库存、读文档——可以放开,答错了顶多是信息有误,不会改变任何数据;写操作和对外发送——改记录、发邮件、回复客户——要过审批,人确认后再执行;涉及资金的操作——退款、打款、改价——必须人工执行,AI 最多做到把单子填好、把依据附上。

一档操作能不能自动批,看两件事:错误可不可逆,错误能不能被及时发现。两个答案都是「否」,就把人放回环节里。

给管理者的一把尺

下次看一个号称「能干活」的 AI 产品演示,可以不问技术细节,只问两个问题:它接了哪些工具?每个工具的权限怎么管?前者决定它能干什么活,后者决定它闯祸的上限。两个问题都答得清楚的产品,才值得往下谈;答不清楚的,演示再流畅,也还停留在「会说」。