摘要：你们有没有发现，好多企业用AI都卡在一个地方，聊天气氛挺好，一到办实事就掉链子，用户问上周买的衣服能不能退，AI要么查不了订单状态，要么忘了用户说过衣服洗过一次，最后还得转人工。

你们有没有发现，好多企业用AI都卡在一个地方，聊天气氛挺好，一到办实事就掉链子，用户问上周买的衣服能不能退，AI要么查不了订单状态，要么忘了用户说过衣服洗过一次，最后还得转人工。

这事儿说穿了，就是AI缺了两样本事，能动手做事，还能记住事儿。 为啥会这样呢？

举个例子，零售行业的智能客服，要答好退换货问题，得先调用户的订单数据（这得对接外部系统），还得记得之前的对话细节（比如是否穿过）。

少一样都给不出准信儿。其实解决这问题，就靠两个技术，Function Calling和MCP。

今天咱就唠唠这俩，到底咋帮AI脱虚向实的。

先说说Function Calling，它就是AI的手，专门帮着做具体事儿。比如你让AI查上海今天的温度，它不是自己知道答案，而是走了一套流程，首先得有开发者提前设好查天气的函数，比如叫get_weather，还得说清楚要填地点这种参数。

等你提需求，AI先判断这得要实时数据，我没有，得叫工具，然后就挑这个函数，填好上海，生成一段JSON请求。平台拿着请求去调用天气API，拿到28℃的结果，AI再转成大白话告诉你。

但这手有个毛病，不同AI厂商的规矩不一样。就像不同牌子的遥控器，按钮布局差老远，换个牌子就用不惯。

还有些老模型，比如早期的deepseek r1，连这手都没有，更别说做事了。你们想想，要是企业用了A厂商的AI，后来想换B厂商，之前设的函数全得重弄，多折腾？

这时候就需要MCP来补漏了，它相当于AI的脑子+接线板，既能记事儿，还能统一对接各种工具。

MCP是Anthropic在2024年11月底推出的开放协议，就像现在快递行业的统一查询系统，不管顺丰还是中通，都能在一个系统里查进度。有了它，不同厂商的AI不用再搞各自为政，对接工具时按一个标准来就行。

而且MCP还能帮AI记事儿。比如你之前问过北京的天气，下次再提上次查的城市，AI能立刻反应过来是北京；智能导购用Function Calling查库存时，MCP能记住用户要XL码、黑色，不用用户重复说。

更方便的是，后续要对接支付系统，也不用改代码，靠MCP的标准就能接上，这俩配合起来，AI才算真正能连贯做事。

不过有了手和脑子，还得管好工具才行。毕竟企业要对接的工具不止一个，查库存、算优惠、发物流，要是每个都单独管，迟早乱成一锅粥。

其实这些工具，本质都是封装好的API，现在主流平台就两种管法， 中小企业工具少、需求简单，适合用openapi协议，比如就想查库存，把库存系统的API按OpenAPI Schema代码接进去，简单直接；

要是大企业，要同时对接库存、支付、物流好几个系统，就适合用MCP协议，它能统一管调用规则，还能同步上下文，避免查完库存忘优惠的情况。

我接触过不少中小企业做AI落地，好多团队一开始只盯着AI聊得顺不顺，忽略了工具能力。

结果对话体验再好，用户要办实事还是得转人工，白扔了钱。其实对企业来说，能做事比会聊天重要多了；而且工具管理也不是看数量，是看能不能凑一块儿干活，有些企业接了十几二十个工具，没管好，AI要么调错，要么记混，反而添乱。

说到底，Function Calling和MCP的作用，就是把AI从实验室里的花架子变成企业能用的工具。

少了它们，AI再聪明也只是纸上谈兵；有了它们，再普通的AI也能帮着查数据、办业务。

来源：成倚贤