从插件到 MCP:AI 是怎么一步步长出＂手＂的?

2022 年 12 月，ChatGPT 刚火那阵，很多人做过同样的测试。

1. 问它"今天几号"，它答不上来。2. 让它算"8734 × 2916"，它给你一个看起来很合理的错数。3. 说"帮我订一张明天去杭州的票"，它说它做不到。

不是它笨，是它被关在一个盒子里：盒子里只有训练数据，没有时钟、没有计算器、没有网络、没有你的日程表。

大模型的本质，是对"下一个 token"做概率预测。这件事让它会写诗、会翻译、会解释概念，但也注定了三个死穴：

1. 知识有截止日期
   ——训练完成那天，它的世界观就冻结了；
2. 算术不可靠
   ——它是"猜"出一个像答案的数字，不是"算"出来的；
3. 不能改变世界
   ——它只能输出文字，不能真的下单、发邮件、改数据库。

这三件事，靠"把模型做得更大"是解决不了的。行业最后给出的答案，不是让模型更聪明，而是给它装上"手"——工具调用（Tool Use）。

这篇文章讲的就是这只手是怎么长出来的：

2023 年 3 月的插件 → 2023 年 6 月的 Function Calling → 2023 年 11 月的 GPTs → 2024 年 11 月的 MCP。不到两年，四个台阶。

一、先看一眼全景：AI 能力的四层台阶

在讲细节之前，先给一张地图。过去这几年冒出来的名词，基本都落在这四层上：

第一层：会说话。 预训练 + 指令微调 + 人类反馈强化学习（RLHF）。模型学会了听懂指令、说人话。这是 2022 年底 ChatGPT 让所有人震惊的那一层。

第二层：会看资料。 Prompt、Context Window、RAG、记忆（Memory）。模型不再只依赖"脑子里的记忆"，而是能把你的文档、你的对话历史临时读进上下文。这一层解决的是"知识不够"。

第三层：会动手。 插件（Plugins）、Function Calling、GPTs / Actions、Assistants API。模型不再只输出文字，而是能输出"我要调用哪个函数、传什么参数"，由程序去执行。这一层解决的是"能力不够"。

第四层：会插拔、会协作。 MCP（模型上下文协议）、A2A（Agent 间协议）。工具不再绑死在某一个应用里，而是变成可以即插即用的标准件；Agent 之间也开始有统一的通信方式。这一层解决的是"集成成本"。

前面几篇讲的是第一、二层。这篇讲第三、四层——也是最近两年最容易被讲混的两层。

二、前史：在"插件"出现之前，学术界已经在想同一件事

很多人以为"工具调用"是 2023 年产品经理拍脑袋想出来的功能。不是。它有一条清晰的学术脉络，名字叫**增强语言模型（Augmented Language Models）**。

• 2021 年 12 月
  ，OpenAI 发 WebGPT：让模型调用浏览器检索网页，再基于网页内容回答。这是"模型 + 外部信息源"的早期原型。
• 2022 年 5 月
  ，AI21 Labs 提出 MRKL 系统（Modular Reasoning, Knowledge and Language）：把语言模型当成"路由器"，把计算器、数据库、知识库当成外部模块，由模型决定把哪个子问题交给哪个模块。这是"神经符号混合"的经典思路。
• 2022 年 10 月
  ，ReAct 提出推理与行动交替：模型先想一步（Reason），再做一步（Act），看结果再想下一步。这个"思考—行动—观察"的循环，今天所有 Agent 框架都还在用。
• 2023 年 2 月
  ，Meta 的 Toolformer 更进一步：让模型自己学会"什么时候该调 API、调哪个、传什么参数"，而且是自监督学出来的。
• 2023 年 3 月
  ，HuggingGPT 让模型调度一堆专家模型；Gorilla 专攻 API 调用准确率。

所以，2023 年 3 月 OpenAI 上插件，本质上是把学术界的"增强语言模型"路线，第一次做成了普通用户能点开就用的产品。

这里有个很关键的理论视角： 工具调用不是为了"让模型变强"，而是为了让模型承认自己不强。它把"我不擅长算术"这件事，转包给计算器；把"我不知道今天发生了什么"转包给搜索引擎。这是一种能力边界的诚实。

三、阶段 3 的三小步

3.1 第一步：2023 年 3 月 23 日，ChatGPT 插件

那天 OpenAI 给 ChatGPT 开了插件系统，媒体当时的说法是"ChatGPT 的 App Store 时刻"。

首发是三样东西：

• Browsing（浏览）：
  让 ChatGPT 能上网查实时信息；
• Code Interpreter（代码解释器）：
  给它一个 Python 沙盒，能跑代码、算数、处理文件；
• 第三方插件：
  Expedia、KAYAK、OpenTable、Instacart、Shopify、Klarna、Slack、Zapier、Wolfram、Speak 等一批服务接进来，能查航班、订餐厅、下单、查股价。

技术上它其实很朴素：每个插件提供一个清单文件（ai-plugin.json）加一份 OpenAPI 规范，描述"我有哪些接口、参数是什么"。ChatGPT 读这份说明书，然后扮演一个 API 调度者——判断该调谁、传什么参数。

一句话概括：插件 = 模型 + 工具 + OpenAPI 规范。

但这段历史里最值得讲的，不是它多惊艳，而是它为什么没成。

插件在 2023 年下半年基本就淡出了，2024 年被 GPTs 全面取代。原因是多方面的：

• 体验割裂：
  每个插件是独立下拉菜单，用户得先手动勾选，模型不一定会用；
• 延迟和可靠性：
  一次插件调用要串好几次网络请求，经常超时、经常选错；
• 安全：
  第三方插件能读网页内容，也就意味着能被网页里的恶意文本"注入"，这在当时没有好办法防；
• 商业闭环缺失：
  只有 Plus 用户能用，开发者赚不到钱，没有分发和变现机制。

这是一个非常典型的案例：产品形态失败了，但机制赢了。 插件这套"用 OpenAPI 描述工具"的思路，几乎原封不动活到了今天。

3.2 第二步：2023 年 6 月 13 日，Function Calling

如果只能选一个时间点作为"AI 工具调用"的真正起点，我选这一天。

OpenAI 在 Chat Completions API 里加了 Function Calling。用法很直白：

1. 你在请求里传一份 tools 列表，每个工具带名字、描述、参数的 JSON Schema；
2. 模型如果觉得该调工具，就返回一个结构化的 tool_calls（函数名 + 参数 JSON）；
3. 你的代码
   去执行这个函数；
4. 你把执行结果作为一条新消息喂回模型；
5. 模型基于真实结果，生成最终回答。

在它之前，大家是怎么干的？——在提示词里写"请用 JSON 格式输出"，然后祈祷模型别多说一句"好的，以下是 JSON"，再用正则去抠。格式一崩，整条链路就断。

Function Calling 把这件事从"祈祷"变成了"契约"：参数有 schema，输出可校验，调用可枚举，错误可重试。

为什么说这是分水岭？因为它一次性解决了四个工程问题：

• 可靠性：
  结构化输出，不再靠字符串解析；
• 可并行：
  一次可以返回多个 tool_calls，同时查天气和查机票；
• 可组合：
  工具可以串起来，形成多步任务；
• 可观测：
  每次调用都有明确的入参出参，方便日志、评测、审计。

而且它很快变成了行业标准。2023 年下半年开始，几乎所有主流模型厂商都兼容了类似的接口。今天你看到的所有 Agent 框架——不管叫什么名字——底层跑的基本都是这个循环。

这里必须强调一个常被忽略的点：模型不执行函数，它只是"提议"。 真正按下执行键的是你的代码。这不是实现细节，这是安全边界：权限、白名单、人工确认，全都要放在"代码执行"这一侧，而不是指望模型自觉。

3.3 第三步：2023 年 11 月 6 日，GPTs 和 Assistants API

OpenAI 首届 DevDay，除了 GPT-4 Turbo，真正改变格局的是两个东西。

GPTs：零代码自定义 ChatGPT。你写一段指令（Instructions）、传几个文件当知识库、再加几个 Actions——而 Actions 的本质，就是把一份 OpenAPI 规范接上去，让模型能调外部 API。也就是说，Function Calling 被包装成了普通人能配置的表单。

Assistants API：官方 Agent 框架。它把"线程（Thread）— 运行（Run）— 工具（Tools）"这套状态管理做好了，内置代码解释器、检索、函数调用。开发者不用自己维护对话状态和工具循环了。

2024 年 1 月，GPT Store 上线。

这一步的意义，是工具调用从"手工作坊"变成"标准件"：

以前：每个团队自己写调度逻辑、自己管状态、自己解析输出。以后：用官方框架 + 标准工具接口，拼装就行。

3.4 阶段小结：解决了什么，没解决什么

到 2023 年底，模型已经能调工具了。但一个新的、更麻烦的问题浮出来了——工具怎么复用？

假设你有一堆工具：GitHub、Notion、飞书、Postgres、你的内部工单系统。又有一堆客户端：Claude Desktop、Cursor、VS Code、你自研的 Agent 应用、公司内部的知识库助手。

每接一个工具，你就要为每个客户端单独写一遍连接器。

N 个客户端 × M 个工具 = N × M 条定制管道。

而且每条管道都要各自处理鉴权、权限、审计、日志、错误重试。这不是"多写点代码"的问题，这是复杂度按乘法增长的问题。

行业里把这个叫 N×M 集成陷阱。MCP 就是冲着它来的。

四、阶段 4：MCP，把"接口"从应用里抽出来

4.1 2024 年 11 月 25 日，Anthropic 开源 MCP

MCP 全称 Model Context Protocol（模型上下文协议）。官方给它的比喻是"AI 领域的 USB-C"。

在 USB-C 之前，每个设备一个接口：圆孔、方口、Mini-USB、Micro-USB、各种专用口。有了 USB-C，一个口解决充电、传输、视频。

MCP 干的是同一件事：把"AI 连工具"这件事，从每家自己定接口，变成一套公共插口。

它的架构只有三个角色：

• Host（宿主）：
  跑 AI 的那个应用，比如 Claude Desktop、IDE、你自己的 Agent 产品。它负责安全策略、用户授权、上下文聚合。
• Client（客户端）：
  嵌在 Host 里，跟一个 Server 一对一通信。
• Server（服务端）：
  一个轻量服务，把某个系统的能力暴露出来。

Server 能暴露三类东西，也就是 MCP 的"三原语"：

通信走 JSON-RPC 2.0，支持两种传输：本地 stdio（进程间管道），远程 Streamable HTTP（早期是 SSE）。

发布时它不只是发了个规范，还一起给了：SDK、Claude Desktop 的本地 Server 支持、一个开源 Server 仓库（Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 等现成的）。早期采用的包括 Block、Apollo，以及 Zed、Replit、Codeium、Sourcegraph 这些开发工具。

这个"发布即带生态"的动作，是 MCP 和此前各种"AI 插件协议"最大的区别。

4.2 它为什么能成：三个设计选择

第一，它不属于任何一家模型厂商。

MCP 由 Anthropic 提出，但它是开放协议，不是某家的私有功能。2025 年 12 月 9 日，Anthropic 把 MCP 捐给了 Linux 基金会下新成立的 **Agentic AI Foundation（AAIF）**，与 Block 的 goose、OpenAI 的 AGENTS.md 一起成为创始项目。这个基金会的支持方包括 Google、微软、AWS、Cloudflare、Bloomberg。

这个动作的意义在于：把"事实标准"变成"制度标准"。跟 Kubernetes、PyTorch、Node.js 归 Linux 基金会管是同一个逻辑——中立治理，才能让竞争对手也敢用。

第二，它刻意让服务端"极简"。

MCP 的设计原则里有一条：Server 应该极其容易构建。安全策略、用户授权、上下文怎么拼，全都交给 Host 去管；Server 只负责"暴露明确的能力"。

这个取舍很聪明。因为工具方（比如你的 CRM 厂商）最不想干的就是理解每个 AI 应用的授权模型；而应用方（比如 IDE）最不想干的是为每个数据源写连接器。MCP 把两边各自最烦的那部分，切给了对方最擅长的角色。

第三，它有复利。

工具写一次，所有兼容 MCP 的客户端都能用。工具方有动力写，因为写完就有全网的 AI 应用能用；客户端有动力接，因为接完就有全网的工具可用。供给和需求互相拉动，这是典型的双边网络效应。

数据能说明问题。据 Anthropic 2025 年 12 月的统计：MCP 一年内月均 SDK 下载量超过 9700 万次，公开活跃 Server 超过 1 万个，ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Code 等主流产品均已支持。

4.3 一条时间线，看清 MCP 是怎么变成"事实标准"的

• 2024.11.25：
  Anthropic 开源 MCP，规范版本 2024-11-05。
• 2025.03.26：
  OpenAI 宣布 Agents SDK 支持 MCP，ChatGPT 桌面端与 API 随后跟进。
• 2025.04.09：
  阿里云百炼上线全生命周期 MCP 服务；同日 Google 发布 A2A 协议。
• 2025.04.10：
  Google DeepMind CEO 表态，Gemini 模型与 SDK 将支持 MCP。
• 2025.04.14：
  腾讯云大模型知识引擎宣布支持 MCP。
• 2025.06.23：
  Google 把 A2A 捐给 Linux 基金会。
• 2025.11.25：
  MCP 新版规范发布，引入异步操作、无状态化、Server 身份、官方扩展等能力。
• 2025.12.09：
  MCP 捐赠给 Linux 基金会 AAIF。
• 2026.01.26：
  MCP Apps 发布（把交互式界面也纳入协议）。
• 2026.04.09：
  A2A 发布 v1.0 稳定版。

从开源到被所有大厂接受，MCP 用了大约四个月；从开源到中立治理，用了一年。

4.4 但 MCP 不是万能的

写到这里必须泼点冷水，否则就成了吹捧文。

第一，MCP 不提升模型智力。 它降低的是集成成本，不是认知成本。模型该理解错的，接上 100 个 MCP Server 也还是会理解错。

第二，它带来了新的攻击面。 有状态连接、第三方 Server、工具描述本身可能被投毒——"工具投毒""越权调用""提示注入"这些词，2025 年之后在安全圈越来越常见。一个不可信的 MCP Server，本质上就是一段你看不见源码的代码，在你的授权下操作你的数据。

第三，简单场景不需要它。 如果你就一个应用、三个工具，Function Calling 直接写死更省事。为了架构而架构，是另一种浪费。

4.5 再往前一步：A2A

MCP 解决的是"Agent 连工具"。那"Agent 连 Agent"呢？

2025 年 4 月，Google 发布 A2A（Agent2Agent） 协议，同年 6 月捐给 Linux 基金会，2026 年 4 月发布 v1.0 稳定版。它解决的是不同厂商、不同框架的 Agent 之间怎么互相发现、委派任务、交换结果。

两者是互补的双栈：

• MCP：agent → tool
  （我的工具怎么给你用）
• A2A：agent → agent
  （我的 Agent 怎么跟你的 Agent 协作）

这也印证了一个规律：每一层协议成熟之后，行业就会立刻去解决再上一层的问题。

五、把整条历史串成一句话

回头看这四个台阶，会发现它们在做同一件事——把"硬编码的耦合"，换成"标准化的接口"。

所以如果要给这段历史一句总结，我会这么写：

AI 工程的进化史，就是不断把"耦合"换成"接口"的历史。每一次标准化的胜利，都让生态规模上一个量级——这和 HTTP 统一了网页、USB 统一了外设、集装箱统一了货运，是同一个故事。

模型变强，决定的是上限；接口变标准，决定的是规模。 过去三年你感觉"AI 越来越能干"，其中很大一部分，其实不是模型变聪明了，而是它能碰到的东西变多了。

六、五个必须纠正的误区

这部分是本文最想留下的东西。因为这几个误区，在技术群和公众号里几乎天天出现。

误区一：Function Calling 就是插件。

❌ 错。✅ Function Calling 是模型侧的结构化输出能力——模型学会"用 JSON 说出我想调什么"。✅ 插件 / GPTs / Actions 是产品侧的工具生态封装，底层往往就是用 Function Calling 实现的。

一个是能力，一个是货架。混在一起讲，后面所有概念都会乱。

误区二：MCP 是 OpenAI 的。

❌ 错。MCP 由 Anthropic 在 2024 年 11 月提出并开源，现在是 Linux 基金会下的中立项目。✅ OpenAI 是 2025 年 3 月跟进支持的，还是 AAIF 的联合创始方之一。这恰恰说明它已经成了行业公共品，而不是某家的护城河。

误区三：MCP 要替代 Function Calling。

❌ 错。两者根本不在一个层面。✅ Function Calling 是"模型怎么表达调用意图"；MCP 是"工具怎么被标准化地暴露和发现"。✅ 关系是互补：MCP 负责把工具接进来，Function Calling 负责让模型把话说清楚。底层依然是 Function Calling。

用一句话记：MCP 是插座，Function Calling 是插头。 误区四：会调工具就是 Agent。

❌ 错。工具调用只是 Agent 的一个零件。✅ 一个能被称为 Agent 的系统，至少要凑齐五件东西：模型（判断）+ 工具（行动）+ 循环（多步执行、看结果再决定）+ 状态/记忆（跨轮次记住进展）+ 权限边界（什么能做什么不能做）。✅ 缺了"循环"和"权限"，那只是一个"会调 API 的聊天框"。

误区五：插件失败了，说明工具调用这条路走错了。

❌ 错。失败的是产品形态（强制勾选、没有分发、没有变现），不是机制。✅ 插件那套"OpenAPI 描述 + 模型调度"的思路，活到了 GPTs 的 Actions，又活到了 MCP 的 Tools。机制赢了，外壳换了。

七、写在最后：为什么这段历史值得普通人看

如果你不是开发者，可能会觉得这些都是工程师的事。但其实有三个判断，对你同样有用：

第一，看一个 AI 新名词值不值得学，看它在解决哪一层的问题。落在"模型能力"层的，会随模型升级被吃掉；落在"接口/协议"层的，往往能活很久。RAG 火到今天，不是因为它多聪明，是因为"把资料喂进去"这个需求永远在。

第二，判断一个产品是不是真 Agent，别听它怎么宣传，看它有没有"循环"和"权限"。只会一问一答的，都是聊天框；能自己决定下一步、并且知道哪些事不能做的，才是 Agent。

第三，技术史的价值不在记住日期，而在认出模式。插件 → Function Calling → GPTs → MCP，四步走的是同一条路：先有人做出一个能跑的东西，然后大家发现互相不通，最后用一个协议把接口统一。 这个模式在数据库、在浏览器、在云原生都上演过。你下次看到某个领域开始吵"协议标准"，基本就能判断：这个领域要开始规模化了。

参考资料

1. Anthropic，《Introducing the Model Context Protocol》，2024-11-25—https://www.anthropic.com/news/model-context-protocol
2. OpenAI，《ChatGPT plugins》2023-03-23 — https://openai.com/index/chatgpt-plugins/
3. OpenAI，《Function calling and other API updates》，2023-06-13 — https://openai.com/index/function-calling-and-other-api-updates/
4. OpenAI，《New models and developer products announced at DevDay》，2023-11-06 — https://openai.com/index/new-models-and-developer-products-announced-at-devday/
5. MCP 官方规范与文档 — https://modelcontextprotocol.io
6. MCP Blog，《MCP joins the Agentic AI Foundation》，2025-12-09 — https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
7. Anthropic，《Donating the Model Context Protocol and establishing the Agentic AI Foundation》，2025-12-09 — https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
8. Linux Foundation，《Linux Foundation Launches the Agent2Agent Protocol Project》，2025-06-23 — https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
9. Google Cloud Blog，《Announcing MCP support for Google services》，2025-12-10
10. Yao et al.，《ReAct: Synergizing Reasoning and Acting in Language Models》，arXiv:2210.03629
11. Schick et al.，《Toolformer: Language Models Can Teach Themselves to Use Tools》，arXiv:2302.04761
12. Karpas et al.，《MRKL Systems》，arXiv:2205.00445
13. Shen et al.，《HuggingGPT》，arXiv:2303.17580
14. OpenAI Agents SDK 文档（MCP 集成）— https://openai.github.io/openai-agents-python/mcp/