Function Calling是什么？AI怎么调用外部工具
哈哈，这是经典误区。其实AI自己根本碰不到外网，它连你家WiFi密码都不知道。它之所以能“查天气”，靠的是一个叫 Function Calling 的机制，有时也叫工具调用或Tool Use。
简单说，AI就像你雇的一个聪明但没手的助理，你给它一个工具箱（比如一把写着“查天气”的扳手、一把“发邮件”的螺丝刀），然后它听你说话，自己决定该用哪个工具，并把参数（比如城市名）准备好，丢给外面的程序去执行，拿回结果后再用大白话告诉你。
比方说在GPT-5.5或Claude Opus 4.7里，开发者先注册一个叫 get_weather(city: string) 的函数，然后你问“北京今天热不热？”，AI就会回复程序一个结构化请求：{ "name": "get_weather", "arguments": { "city": "北京" } }。程序拿到这个，去真的气象网站查了返回“35°C”，AI再把它润色成“今天北京35度，挺热的”。
所以Function Calling的角色就是把聊天模型变成调度中心，它不干活，但知道谁会干、该怎么叫人干。
这个问题问到我踩过的坑了。AI不是靠关键词硬匹配，它会看函数的描述文本和你的意图。比如开发者注册函数时，除了参数，还要给一段说明：“获取指定城市的实时天气信息”。当你说“北京热不热”，模型就从语义上感受出“这跟天气有关”，然后把 city 填成“北京”。它不会去碰那个叫 order_food 的函数，因为后者描述里写着“订外卖需要食物类型和地址”，模型能判断出意图完全不同。
但确实有翻车的时候。要是函数描述写得模糊，或者两个函数语义太近，AI可能就犯糊涂。所以开发者得把函数描述当prompt写，清晰界定每个工具的用途，还得在提示词里约束“只能调用给定的工具，别自己瞎编”。
打个比方，你给助理的菜单上要是只写了“查东西”，它可能把查天气、查快递、查明星八卦全搅在一起。但如果你写清楚“查天气：输入城市名，返回天气信息”，它就不容易跑偏。现在一线的API比如DeepSeek V4的Function Calling，连复杂嵌套参数都能准确识别，但前提是你的函数说明书得够精细。
对，你抓到本质了。Function Calling是“怎么让AI说我要用这个工具”，但没规定工具长什么样。这时候MCP（Model Context Protocol）就出来了，它像是给这些工具定了一个标准的插座和插头。
来，用这张表看区别：
| Function Calling | MCP | |
|---|---|---|
| 角色 | 一次具体调用动作 | 一套工具连接规范 |
| 类比 | 你喊“拿个扳手来” | 插座标准，保证不同品牌的扳手都能插上去 |
| 谁在用 | 模型输出调用请求 | 程序与工具之间的通信层 |
| 举例 | “获取天气，城市=北京” | 告诉程序“去哪找天气工具、怎么传数据” |
举个实例：Claude Opus 4.7内置MCP支持，开发者不需要自己写工具适配代码，直接把各种第三方服务（日历、搜索、邮件）接上MCP服务器，Claude通过Function Calling去喊它们干活。而老一点的模型可能只支持自己家的Function Calling API，想集成别的工具就得手动封装。
所以，MCP是解决“工具太多、接口太乱”的标准化方案，Function Calling是让模型能开口要工具的机制，两者搭配才让AI真正变得“手多长”。
那我作为产品经理，怎么判断什么时候该让开发团队用Function Calling，啥时候直接接个MCP服务？
好问题，产品决策角度。如果你的需求是让模型在对话里灵活调用几个固定的内部函数（比如查订单、发通知），直接用模型自带的Function Calling API（像GPT-5.5、DeepSeek V4都支持得很好）就够，开发轻量、可控。
但如果你想让用户自由接入各种第三方工具（日历、邮箱、Notion、上百种外部API），那直接上MCP更省心，不用反复写适配代码。很多AI编程助手（如Claude Code、Cursor Composer）已经内置MCP，产品经理一勾选就能用，成本低很多。
纠结的话，可以去咱们小白学院的 大模型排行榜 看各模型对Function Calling和MCP的支持评分，或者翻翻 AI热点资讯 里最新的工具调用落地案例，心里就有数了。