Function Calling，让AI学会动手干活的技术

你有没有发现一个很奇怪的事情。

我们天天在用的这些AI，ChatGPT也好，Claude也好，Gemini也好，它们能写诗、能写代码、能帮你分析财报、能跟你辩论哲学。但如果你让它帮你订一张明天下午三点北京飞上海的机票，它只能说「好的，我建议你打开携程APP搜索一下」。

它什么都知道，但什么都做不了。

这个矛盾感你细品一下，其实挺荒诞的。就像你雇了一个学识渊博的顾问，他能给你讲三个小时的投资理论，但你让他帮你登录一下券商APP下个单，他说「不好意思这个我没法操作，建议你自己来」。

脑子很好使，手是残的。

直到Function Calling出现。

前面几篇文章里，我聊了RAG、embedding、Fine-tuning，它们解决的都是「AI怎么想」和「AI怎么说」的问题。但Function Calling解决的是一个完全不同层面的问题，AI怎么做。

这个技术做的事情，就是让AI从一个只能说话的嘴，变成一个能动手干活的人。

这是一个质变。

让我从一个最直观的例子开始讲。

你跟AI说，「帮我查一下北京今天的天气」。在没有Function Calling的时代，模型只能从它训练数据里找一个可能已经过期半年的天气信息，或者老老实实告诉你「我没法获取实时信息」。

有了Function Calling之后呢？模型会做一件很聪明的事。它不会试图自己「知道」天气，而是说，「我需要调用一个天气查询的工具，参数是城市=北京，日期=今天」。然后你的应用程序拿到这个请求，去调真正的天气API，拿到结果，再把结果喂回给模型，模型再用自然语言告诉你，「北京今天晴，28度，适合出门」。

模型没有获取天气的能力，但它知道应该用什么工具、传什么参数来获取天气。

你想想看，这就像那个学识渊博的顾问，他虽然不能亲手帮你下单买股票，但他能精确地告诉你的助理，「帮他在XX券商买入500股腾讯，限价380」。指令明确、参数清晰，助理照着执行就行。

模型负责决策，应用程序负责执行。各司其职。

这就是Function Calling的核心逻辑。

但等等，这玩意到底是怎么工作的？模型怎么知道有哪些「工具」可以用？怎么知道每个工具需要什么参数？

答案是，你告诉它的。

当你调用大模型的API时，你可以在请求里附带一份「工具清单」。这份清单用JSON格式描述了每一个可用的工具，名字叫什么、干什么用的、需要哪些参数、每个参数是什么类型。就像给新员工发了一份公司所有系统的操作手册，告诉他「你有这些工具可以用，每个工具的使用方法是这样的」。

模型拿到用户的问题之后，会先判断，这个问题我自己能答吗？如果能，直接答。如果不能，或者需要实时数据、需要执行某个操作，它就会从工具清单里挑一个合适的工具，按照规定的格式生成一段JSON，意思是「我需要调用这个工具，参数是这些」。

然后呢？然后就没模型什么事了。你的应用程序接收到这段JSON，解析出来要调哪个函数、参数是什么，去真正执行这个操作，拿到结果，再把结果传回给模型。模型看了结果之后，再组织自然语言回复给用户。

整个过程可以用一句话概括，模型出主意，程序跑腿。

这里面有一个特别关键的设计选择，我觉得值得单独拿出来说。

模型永远不会直接执行任何操作。

它只是生成一段「我想调用XX函数」的结构化数据。真正的执行权在你的应用程序手里。那结果会怎样呢？你可以在中间加任何你想加的安全检查。模型说「我要转账10万块」，你的程序可以说「等等，金额超过5万需要二次确认」，然后弹一个确认框给用户。

这个设计太重要了。如果模型可以直接执行操作，那出了事谁负责？模型幻觉一下，直接把你银行账户清空了怎么办？所以Function Calling的架构天然就把「决策」和「执行」分开了，中间永远有一个人类可以干预的环节。

坦率的讲，我觉得这是这个技术设计中最优雅的部分。

好了，理解了基本原理，我们来聊聊它到底能干什么。

第一个最直接的用途，就是让AI能查实时信息。 天气、股价、新闻、航班信息、外卖价格，所有需要「此时此刻」数据的场景，都可以通过Function Calling来搞定。模型本身的知识是有截止日期的（前面RAG那篇聊过这个问题），但通过调用外部API，它就能获取到最新的信息。

第二个，让AI能操作外部系统。 发邮件、创建日程、在Notion里建一个页面、给某个Slack频道发消息、在Jira里创建一个ticket。这些都是「动作」而不是「回答」，只靠嘴是做不到的，必须有手。

第三个，让AI能执行多步骤的复杂任务。 这个是最有意思的。用户说「帮我把上周的销售数据整理成表格发到我邮箱里」。模型会怎么做？它先调用一个函数查销售数据，再调用一个函数生成表格，最后调用一个函数发邮件。一个用户请求，触发了三次工具调用，中间还有推理和决策。

这种模式有个业内的名字，叫Agentic Loop，智能体循环。

模型不是调一次工具就完事了。它是「想一步、做一步、看结果、再想下一步」。就像一个真正在干活的人，不是接到任务就闷头干完，而是边做边看进展，根据中间结果调整下一步的行动。

2025到2026年整个AI Agent的浪潮，底层驱动力就是这个。所有人都在说Agent，什么自主Agent、多Agent协作、Agent编排，听着很玄，但你扒开来看，核心技术能力就两个，一个是模型的推理能力够强，一个是Function Calling让模型能调用外部工具。

没有Function Calling，Agent就是个空中楼阁。

说到这里，回顾一下历史可能有助于理解这个东西的来龙去脉。

2023年3月，OpenAI搞了一个叫ChatGPT Plugins的东西。那时候的idea很激进，让第三方开发者可以给ChatGPT写插件，AI可以直接调用这些插件来完成任务。浏览网页、订餐厅、查机票，什么都想做。

结果呢？三个月不到就凉了。

为啥？原因挺多的。安全问题一大堆（第三方插件可能泄露用户数据），用户体验也不好（你得手动选要用哪个插件），更要命的是模型经常用错插件或者传错参数，搞出来的结果一塌糊涂。

但这个方向本身没有错。OpenAI很快就调整了策略，2023年6月推出了Function Calling API。不再搞那种面向终端用户的「插件商店」，而是提供一个面向开发者的标准接口。你自己定义函数、自己执行、自己控制安全边界，模型只负责决定「什么时候该调什么函数、参数是什么」。

这个策略调整非常聪明。把风险控制权交还给开发者，同时保留了核心能力。

从那之后，所有的大模型厂商都跟进了。Claude、Gemini、Llama、Mistral，几乎每一个主流模型都支持Function Calling。接口细节略有不同，但核心思路完全一样。

这也引出了一个2025年到2026年这个领域最热门的话题之一。

碎片化。

每家的Function Calling接口都不太一样。OpenAI的叫functions，Claude的叫tools，Gemini又是另一套格式。如果你是一个开发者，你想让你的应用同时支持多个模型，你就得为每个模型写一套适配代码。

更惨的是另一边。如果你是一个工具提供方，比如你做了一个很好用的数据库查询服务，你想让所有AI都能调用你的工具。那你就得给OpenAI写一个适配、给Claude写一个适配、给Gemini写一个适配。。。

这就是经典的N×M问题。N个模型，M个工具，要写N×M个适配。

听着就头疼对吧？

这个问题，就是我下一篇要聊的MCP（Model Context Protocol）要解决的。 Anthropic在2024年底提出了MCP这个开放协议，思路很简单，在模型和工具之间加一个标准化的中间层，让N×M变成N+M。就像USB接口统一了所有外设和电脑之间的连接方式一样。

但MCP的故事比较长，涉及到整个生态的重构，我打算下一篇单独展开聊。今天先把Function Calling本身讲透。

回到实际层面。

如果你现在想在自己的项目里用Function Calling，2026年的体验已经非常丝滑了。我简单描述一下一个典型的开发流程。

第一步，定义你的工具。用JSON Schema描述每个函数的名称、功能说明、参数列表。比如一个「查天气」的工具，你需要告诉模型，这个工具叫get_weather，功能是查询指定城市的实时天气，参数有一个city，类型是字符串，必填。

第二步，把工具清单和用户消息一起发给模型。模型返回的时候，如果它觉得需要调用工具，就会在回复里包含一个tool_calls字段，里面写明要调哪个函数、参数是什么。

第三步，你的程序解析这个tool_calls，去执行对应的操作（比如调天气API），拿到结果。

第四步，把执行结果作为一条新消息发回给模型，模型综合用户的原始问题和工具返回的结果，生成最终的自然语言回复。

就这四步。技术上并不复杂。

但「不复杂」和「做好」之间，同样隔着一个太平洋。

我在研究过程中发现，Function Calling在实际使用中有几个很容易踩的坑。

第一个坑，工具描述的质量。 模型选哪个工具、传什么参数，完全依赖你对工具的文字描述。如果你的描述含糊不清，模型就会选错工具或者传错参数。这跟写prompt是一个道理，你给的信息越精准、越无歧义，模型的表现就越好。我看到有团队光优化工具描述就花了两三周，最终把工具选择准确率从75%拉到了96%。

第二个坑，token成本。 每次API调用都会把整个工具清单塞进上下文。如果你定义了几十个工具，光是工具描述就可能占掉几千个token。在对话轮次多的场景下，这个成本会累积得很快。所以实际工程中经常要做工具的「动态加载」，根据对话主题只加载相关的工具子集，而不是每次都把全部工具都塞进去。

第三个坑，错误处理。 模型调了一个工具，工具执行失败了怎么办？网络超时了怎么办？返回的数据格式不对怎么办？这些在demo里看不出来的问题，到了生产环境全都会冒出来。健壮的Function Calling系统需要有完善的异常处理、重试机制和降级策略。

第四个坑，安全边界。 前面说过模型不直接执行操作，但如果你的应用程序没有做好权限控制，模型说什么你就执行什么，那风险其实还是很大的。尤其是在多用户场景下，你得确保A用户的AI助手不能操作B用户的数据。

这些坑每一个都能展开写一大段，但核心建议就一个，永远不要信任模型的输出，永远要在执行层做校验。

聊到这里，我想说一个我觉得很多人可能还没意识到的事情。

Function Calling正在重新定义「软件」这个概念。

你想想看，传统软件的交互方式是什么？是按钮、菜单、表单。你想发邮件，你得打开邮箱APP，点「写邮件」，填收件人、写标题、写正文、点发送。每一步都是你在操作界面。

有了Function Calling之后呢？你跟AI说一句「给张三发封邮件问他明天有没有空吃饭」，AI调用发邮件的函数，一步搞定。

界面消失了。或者说，自然语言本身变成了界面。

这不是科幻，这就是2026年正在发生的事情。越来越多的软件开始提供AI原生的接口，不是给人类用的GUI，而是给AI调用的API。未来可能每一个SaaS产品都会有两套入口，一套给人点的按钮，一套给AI调的函数。

我自己觉得这个趋势是不可逆的。当AI能够理解意图并正确调用工具的能力越来越强，很多我们现在习以为常的「操作」会变得不必要。你不需要学会用一个复杂的CRM系统，你只需要用自然语言告诉AI你想做什么，AI去帮你操作CRM。

这也是为什么MCP这个协议那么重要。如果每个AI和每个工具之间都是私有接口，这个未来永远不会到来。只有建立一个通用标准，让任何AI都能调用任何工具，这个生态才能真正繁荣起来。

但这个话题，留到下一篇再说。

最后把Function Calling放到我们整个系列的图景里看一看。

前面几篇文章，我聊了embedding（让AI理解语言的含义）、RAG（让AI学会翻书查资料）、Fine-tuning（让AI学会成为某个特定角色）。它们解决的都是AI「认知」层面的问题，怎么理解、怎么记忆、怎么表达。

Function Calling解决的是AI「行动」层面的问题。

如果说前面那些技术让AI变成了一个有知识、有记忆、有性格的人，那Function Calling就是给这个人装上了手和脚。从此它不只是一个对话伙伴，而是一个能帮你干活的助手。

一个完整的AI系统，既要能想，也要能做。 Function Calling就是连接「想」和「做」的那根线。

好了，这就是我对Function Calling的完整理解。下一篇，我们来聊MCP，那个试图统一所有AI和所有工具之间连接方式的开放协议。如果说Function Calling是让AI学会了「动手」，那MCP就是在给这双手制定一个通用的操作规范，让它能伸到任何地方去。

永远对世界保持好奇。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。

延伸阅读

• Fine-tuning，让AI学会「成为某个人」的技术：微调到底是什么？跟RAG和prompt有什么区别？LoRA和QLoRA又是什么？这篇文章用大白话聊透Fine-tuning，从概念到成本到实际应用场景。
• RAG，一个让AI学会翻书的技术：之前一直听说过RAG但没有深入了解过，今天花了一整天时间研究，用大白话聊透它的概念、原理、使用场景和最新进展。如果你跟我一样对RAG只停留在听说过的阶段，这篇应该能帮到你。
• Embedding，AI世界的隐形地基：之前一直知道embedding这个概念但没深入了解过，这次认真研究了一下。从one-hot编码的致命缺陷到Word2Vec的惊人发现，从当前主流模型选型到五大应用场景，用大白话聊透向量嵌入这个AI世界的底层基建。
• AI Agent，当AI学会自己搞定一整件事：AI Agent是Fine-tuning、Function Calling、MCP三大技术的集大成者。这篇文章从聊天机器人和Agent的本质区别讲起，拆解Agentic Loop的工作机制，坦诚讨论复合错误率的现实挑战，最终回答一个问题：当AI学会独立完成任务，什么能力变得更重要了？