翻了翻电脑里的旧代码发现2023年刚开始做AI应用的时候我写过一堆插件相关的东西。那时候OpenAI刚推出Plugins觉得挺新鲜照着文档接了几个。现在回头看就像看石器时代的代码。这三年AI接工具这件事基本上是三年三大步OpenAI Plugins → Function Calling → MCP协议。每一代都是对上一代问题的修正每一代都有一堆人踩坑。今天这篇就按时间线捋一遍看看我们是怎么从手写插件走到MCP标准化的以及每一代到底解决了什么、留下了什么坑。第一代OpenAI Plugins2023年3月——看起来很美实际上很坑2023年3月OpenAI发布了ChatGPT Plugins。当时整个AI圈都激动坏了——终于能让ChatGPT联网查数据、调外部API了我还记得当时连夜写了个天气查询插件部署上去觉得自己在做前沿技术。现在回头看Plugins的设计思路其实很简单你在自己的服务器上放一个/.well-known/ai-plugin.json文件描述你这个插件有什么功能、怎么调。ChatGPT发现之后就知道怎么调用了。听起来是不是很像现在的MCP确实像。但为什么Plugins最后死了第一个问题被OpenAI绑死了。Plugins是OpenAI的私有协议只有ChatGPT能用。你写一个插件只能给ChatGPT用别的AI平台不认。这对开发者来说太不友好了——我为什么要为一个平台单独写一套第二个问题体验很割裂。用户在ChatGPT里用插件就像突然跳转到另一个页面体验很不一致。而且插件的触发逻辑很模糊有时候ChatGPT该调插件不调不该调瞎调。第三个问题生态没起来。大家热情了一阵子发现Plugins的开发者量根本上不去。为什么因为投入产出比太低——你花时间写个插件只能在ChatGPT里用用户量有限变现更没戏。我自己当时写的那个天气插件上线之后总共没几个人用。后来OpenAI自己都不怎么推Plugins了这事就慢慢凉了。第二代Function Calling2023年6月——实用但不够标准Plugins凉了之后OpenAI很快推出了Function Calling。这个东西就实在多了。Function Calling的思路是你在调大模型的时候把你支持的函数工具以JSON Schema的形式传进去。大模型判断需要调用工具的时候会返回一个函数名和参数你自己拿着这个去调真正的API再把结果喂回给大模型。代码大概长这样importopenai tools[{type:function,function:{name:search_hotels,description:搜索酒店,parameters:{type:object,properties:{city:{type:string,description:城市名},check_in:{type:string,description:入住日期},check_out:{type:string,description:退房日期}},required:[city,check_in,check_out]}}}]# 第一次调用让大模型决定要不要调工具responseopenai.chat.completions.create(modelgpt-4,messages[{role:user,content:帮我找上海的酒店}],toolstools)# 大模型返回要调search_hotelstool_callresponse.choices[0].message.tool_calls[0]print(tool_call.function.name)# search_hotelsprint(tool_call.function.arguments)# {city: 上海, ...}# 你自己去调真正的APIresultcall_real_hotel_api(tool_call.function.arguments)# 第二次调用把结果喂回去response2openai.chat.completions.create(modelgpt-4,messages[{role:user,content:帮我找上海的酒店},response.choices[0].message,{role:tool,tool_call_id:tool_call.id,content:result}],toolstools)# 大模型把结果组织成自然语言回复Function Calling确实比Plugins实用多了对吧至少它是一个开放的技术范式不是某个平台的私有插件。OpenAI推出之后Anthropic、Google很快都跟进了大家都支持类似的工具调用机制。但Function Calling有个根本问题它只是大模型层面的一个能力不是一个真正的工具调用协议。什么意思就是说你还是得自己写一堆胶水代码——你自己定义函数、自己写参数schema、自己处理鉴权、自己调API、自己把结果喂回去。每个AI应用都在重复造这些轮子。而且每个大模型平台的Function Calling格式还不一样。OpenAI的格式和Anthropic的不一样和Google的又不一样。你想同时支持多家大模型你得写多套适配层。我们做酒店MCP之前最早就是用Function Calling做的。那时候写了一大堆适配代码——定义工具schema、处理参数校验、调后端API、格式化返回结果。换个大模型这套代码就得改一遍。现在想想那时候写的1000多行适配代码现在用MCP只需要几十行配置就搞定了。第三代MCP协议2024年11月——终于有了行业标准2024年11月Anthropic推出了MCPModel Context Protocol。一开始我没太当回事觉得又是一个新协议。后来越用越觉得——这玩意儿才是真正的解决方案。MCP和前两代最大的区别是什么它是一个真正的、开放的、跨平台的工具调用协议。具体来说开放标准不是某家公司私有的是开源协议。Anthropic推出来之后OpenAI、Google、Cursor、Windsurf这些主流玩家都支持了。Server-Client架构工具提供方实现MCP ServerAI应用作为MCP Client连接上来。一次实现所有支持MCP的客户端都能用。标准化能力发现Client连上Server之后自动发现有哪些工具、每个工具要什么参数、返回什么格式。不用手写schema了。跨平台不管你用的是Claude、GPT还是国产大模型只要支持MCP就能连同一个MCP Server。这就像什么就像当年从各家自定义的API格式走到了RESTful标准。以前每个系统都有自己的接口风格现在有了统一标准大家都省事儿。而且MCP生态起来得很快。现在整个生态里已经有上万个MCP Server了覆盖了数据库、云服务、开发工具、行业数据等等各个领域。我们做的RollingGo酒店MCP也是其中一个——GitHub上已经攒了近300个star既有MCP Server也有旅游Skill支持Cursor、Claude Code、Codex、Windsurf等40多种主流大模型代理直接接入。背后整合了500全球供应商和200万酒店资源涵盖各类酒店品牌不管你要找连锁酒店还是小众民宿都能覆盖11万直签酒店库存直连加实时价格确认查出来的价格和房态都是准的直接就能下单。完全免费、没有调用量限制开发者接入后还能按国家设置加价比例赚返佣订单和收益实时可查。从Plugins到Function Calling再到MCP我最大的感受就是——终于不用再手写那一堆适配代码了。想体验一下MCP时代的开发效率去rollinggo.store申请个Key试试。说个最实际的现在接入真的超级简单比如在Qoder里配置只需要这样写{mcpServers:{RollingGo-Hotel:{type:sse,url:https://mcp.rollinggo.cn/mcp,headers:{Authorization:Bearer YOUR_API_KEY}}}}就这几行配置重启Qoder之后你就能直接在对话里调用酒店搜索、房型查询、价格确认这些工具了。从Plugins到Function Calling再到MCP开发效率真的是数量级的提升。三代对比一张表看清楚维度OpenAI PluginsFunction CallingMCP协议推出时间2023年3月2023年6月2024年11月本质平台私有插件体系大模型API的工具调用能力开放的工具调用协议标准开放性OpenAI私有只能ChatGPT用各平台格式不统一开源协议跨平台支持开发者工作量写插件manifest后端实现自己写schema胶水代码实现一次MCP Server到处能用工具发现ChatGPT自动发现你自己把schema传给模型Client自动从Server发现现状基本被淘汰还在用但正在被MCP替代生态快速增长成为新标准为什么MCP最终赢了从Plugins到Function Calling再到MCP为什么MCP成了最终的赢家我觉得核心原因就一个它解决了重复造轮子的问题。Plugins失败是因为它是封闭的开发者不愿意为一个平台单独投入。Function Calling能用但不够好——每个AI应用都要自己写工具适配层重复劳动太多。而且跨平台兼容是个大问题你用OpenAI的格式写的工具换到Anthropic那边就得改一遍。MCP为什么能赢因为它把工具适配这件事标准化了。工具提供方只需要实现一次MCP Server所有支持MCP的AI客户端自动就能用。AI应用开发者不用关心每个工具怎么调连上MCP Server就行。这就是标准化的力量。就像USB-C统一了充电接口就像HTTP统一了Web通信MCP统一了AI调用工具的方式。一旦标准成立生态就会滚起来——工具提供方愿意做MCP Server因为能触达所有MCP客户端AI应用开发者愿意用MCP因为工具现成的不用自己写。对开发者意味着什么如果你是做AI应用的现在还在用纯Function Calling手写工具适配我建议你认真考虑一下MCP。不是说Function Calling不能用而是MCP能帮你省掉大量重复劳动。如果你是做数据服务或者SaaS产品的那更应该关注MCP。实现一个MCP Server的成本很低但你能直接触达所有MCP生态里的AI应用这相当于一个全新的分发渠道。以前你要一个个去对接AI公司现在你把MCP Server挂出去AI应用自己会来找你。当然MCP也不是万能的我之前写过一篇专门讲它的边界和坑这里就不展开了。但至少在工具调用标准化这件事上MCP确实是目前最好的方案。写在最后回头看这三年AI接工具这件事的演进路线其实很清晰从封闭到开放从碎片化到标准化从每个应用自己写胶水代码到整个生态共享同一套协议。这个过程和Web技术的发展史几乎一模一样——从自定义接口到RESTful标准从私有插件到开放API。技术的发展就是这样一开始各种方案百花齐放最后总会收敛到一个大家都认可的标准上。MCP就是AI工具调用这个领域的那个标准。你是从哪一代开始做AI应用的是Plugins时代就开始了还是Function Calling时代入的坑或者是MCP时代才进来的评论区聊聊。