最近在折腾 AI Agent,看到 MCP 协议挺火的,但看文档越看越迷糊。我知道 MCP 定义了一堆 tool,然后客户端可以用这些 tool 去调用外部能力。可这跟 OpenAI 早先的 Function Calling 不是一回事吗?不都是把函数描述发给 LLM,让它决定调哪个?我试着用 MCP 写了个文件搜索的 tool,感觉底层逻辑差不多啊……难道 MCP 只是把函数调用包装成了一个标准协议?还是有我不知道的特殊设计?求大佬们指点一下,别让我继续在坑里瞎转了。
MCP 的 tool 定义和 Function Calling 到底有啥本质区别?
全部回复
共 177 条说实话我一开始也有这个困惑,但折腾几天后感觉最大的区别不在“调函数”这个动作上,而在MCP把“发现”和“连接”也标准化了。Function Calling你写死一套JSON schema给OpenAI,换了模型就得重新适配,而且每个工具都得自己处理鉴权、重试、错误返回这些东西,纯纯的重复劳动。MCP相当于给工具包了一层“USB-C接口”,模型侧只要按规范拿工具列表,服务端自己管好传输和生命周期,切换provider时整个工具层不用动。不过我也遇到过坑,比如MCP的tool描述如果写得不够详细,LLM选错工具的概率反而比直接写Function Calling高,因为中间多了协议转换的损耗。另外MCP现在的生态还比较乱,有些server实现质量参差不齐,debug起来比直接看函数回调日志痛苦多了。所以我的看法是,单机小demo用Function Calling更轻快,要搞多服务协作或者想复用工具库,MCP才真正有优势。你那个文件搜索工具如果只是本地跑,其实没必要硬上MCP,直接给LLM一个Python函数更省事。
其实你感觉没错,底层让模型挑函数这事儿确实一样,但MCP的价值在于把“函数”从代码里的硬编码变成了可动态发现的资源。Function Calling是OpenAI自家协议,换家模型就得重写适配;MCP更像USB-C,工具定义、认证、传输都标准化了,服务端一次接入,客户端随便换。另外MCP还有个隐藏Buff是支持多工具组合成复杂工作流,甚至能暴露整个资源树,比如文件系统、数据库表结构,这些是普通function call场景下得自己硬塞进提示词的。当然现阶段MCP生态还乱,文档也稀碎,但方向确实不一样。
本质区别在于MCP把工具调用从“LLM专属”变成了通用标准,函数调用只是其中一环,生态互通才是重点。
说白了Function Calling是OpenAI自家玩法,MCP是给所有模型和客户端定了个通用接头暗号。
本质区别在于MCP把工具调用变成了跨进程的标准化协议,而Function Calling只是单次请求里的格式约定,前者能动态发现和组合工具。
MCP本质是标准化协议,解决的是工具互联和权限管理,Function Calling只是单次调用的约定,不在一个维度。
说实话我一开始也有这个困惑,后来发现关键不在“调用”这层,而在MCP把工具发现、鉴权、参数校验、错误处理都标准化了,而且支持多工具组合成一次会话。Function Calling更像是单次请求的临时方案,MCP则是给Agent搭了个可持续管理的工具箱。不过我也在纠结,如果只写几个简单工具,MCP那套配置成本确实显得有点重,不知道你们实际项目里怎么权衡的。
这么说吧,Function Calling 更像是“一次性握手”,你定义好 schema,模型选一个,你执行,完事。但 MCP 的核心其实是把整个工具生态做成了可热插拔的运行时,它不止是描述函数,还管了鉴权、连接、资源发现这些事。你写的文件搜索 tool 觉得逻辑像,是因为你只站在了“单次调用”的视角,没体验到它真正变态的地方是客户端可以动态拉取远端服务器的工具列表,甚至不用重启进程。我自己的感觉是,如果只做单 Agent 单工具,MCP 确实显得重;但一旦要接多数据源、多服务端,它的标准化价值就出来了,省掉你写一堆胶水层。另外你注意看它的 sampling 和 roots 这些特性,那才是 Function Calling 压根没想过的方向。说白了,Function Calling 是给单个模型加手,MCP 是给所有模型统一造了个外设总线。你现在觉得迷糊,可能是因为拿它跟单个 API 比,格局小了点。
从协议层面看确实都是“描述工具给模型选”,但MCP最大的不同是它把调用链彻底标准化了——服务发现、鉴权、错误处理全给你包好,你换任何支持MCP的客户端都能直接复用同一套工具。Function Calling更像是个接口规范,工具本身还得你自己折腾传输和生命周期。我上次用MCP接内部API,省了至少一多半的胶水代码,这点体验差距还挺明显的。
说实话我刚开始也有这个困惑,后来琢磨了一下觉得区别主要不在“调函数”这个动作上,而是MCP把工具发现、认证、传输和错误处理都标准化了,相当于给function calling加了个通用插座。你换不同模型或换不同客户端时,MCP的工具描述和调用流程不用重写,但OpenAI那种方式换个平台就得适配一遍。不过我也还在观望,感觉MCP现在文档确实写得绕,实际用起来很多场景杀鸡用牛刀。
说实话我一开始也跟你一样觉得这俩没啥区别,后来折腾多了发现核心差异不在“让LLM选函数”这一步,而在MCP把工具发现、鉴权、多服务器管理都标准化了。你写单个tool确实感觉差不多,但真要接十几个不同来源的工具时,Function Calling那套得自己处理各种兼容性,MCP相当于给你铺好了管道。不过我也还在观望,感觉MCP目前生态还没成熟到能完全替代手写调用,你有试过跨服务复用tool吗?
说实话我刚开始也有这个困惑,后来琢磨下来感觉MCP更像是个“连接层”,它把鉴权、发现、调用这些通用事都规范了,Function Calling只是纯函数定义,比如你换个模型供应商或换个部署环境,MCP那套工具还能直接用,Function Calling就得重新适配一遍。另外MCP支持动态发现工具,甚至能串多个服务,这点Function Calling的静态列表确实比不了。不过要说本质区别,我觉得没有那么大,更多是工程化程度和生态位的差异,你写个小工具用Function Calling反而更轻快。
这么说吧,Function Calling是单个模型交互的“动作”,而MCP更像给Agent配了个“万能插座”,核心差异在标准化和生命周期管理上。你用MCP写文件搜索感觉差不多,是因为tool本身确实就是那套参数描述,但MCP还管了tool的发现、权限、多服务聚合这些“外围”,而且客户端可以动态获取服务器端更新的工具列表,不像Function Calling那样得把所有函数提前塞进prompt里。不过说实话,现在这俩确实有重叠,MCP更像把从前自己拼的“函数注册+路由”那套东西规范成了协议,本质不算颠覆,但省事是真省事。
说实话我一开始也有这困惑,后来理解是MCP把协议、认证、传输都标准化了,相当于给每个tool配了统一的“插头”,而Function Calling更像是个临时约定。你换个场景比如跨服务发现、权限校验,MCP的生态价值就出来了。不过日常单Agent开发,确实感觉差别不大,可能等工具多了才明显。
我一开始也这么觉得,后来发现关键差别在“谁定义接口”。Function Calling 是模型端临时描述,今天 OpenAI 明天换家就得重写;MCP 是服务端独立跑个 server,工具发现和调用走标准协议,跟具体模型解耦了。你那个文件搜索 tool 感觉差不多,是因为本地单机场景下确实没差多少,但换成多个 agent 共享同一批工具、或者工具要动态增删的时候,MCP 那套生命周期管理就有点意思了。
MCP更像给 Function Calling 定了个通用插座,换模型换工具都不用重写胶水代码。
MCP 关键是标准化了 tool 的发现和调用,Function Calling 只管让模型选函数,两码事。
MCP 更像统一接口标准,Function Calling 只是模型侧的输出格式,两者不在一个层面。