GitHub 8.6万Star，OpenAI、Google、微软全部接入——MCP凭什么成为AI的USB-C？

假设你是一个AI Agent的开发者。你的Agent需要访问GitHub、Slack、PostgreSQL、文件系统和Google Drive这5个工具。在MCP出现之前，你需要写5套完全不同的集成代码——不同的认证方式、不同的数据格式、不同的错误处理。如果你的Agent还要支持Claude、GPT、Gemini这3个模型，恭喜你，你需要写5×3=15套胶水代码。这就是AI工具集成的"N×M噩梦"。

2024年11月25日，Anthropic开源了一个协议，名叫MCP（Model Context Protocol）。

18个月后的今天：

• GitHub Star数：86,148
• SDK月下载量：9700万次
• 公开MCP Server数量：10,000+
• GitHub上标记mcp-server的仓库：15,926个
• 接入的公司：OpenAI、Google、微软、阿里、腾讯、蚂蚁——基本上你能叫得出名字的AI公司全接了

它被称为AI领域的"USB-C接口"。 一个协议统一了所有AI工具的接入标准。

今天这篇文章，把MCP的技术架构、生态格局和实战落地讲透。

一、一个类比搞懂MCP：AI界的USB-C

1.1 USB-C之前的痛苦

还记得2015年之前的手机充电线吗？

苹果用Lightning，三星用Micro-USB，诺基亚用圆口，索尼用自己的扁口。出门带一根线？不行，得带四根。买个新设备？又得买一根新线。

AI工具集成在MCP之前就是这个状态。

每个工具都有自己的API格式：

• GitHub用REST API + OAuth
• Slack用WebSocket + Bot Token
• PostgreSQL用TCP连接 + SQL协议
• 文件系统用操作系统API
• Google Drive用OAuth 2.0 + 私有SDK

你要让AI Agent调用这些工具？每个都得写一遍"翻译层"。5个工具5套代码，50个工具50套代码。

1.2 USB-C之后的世界

MCP做的事情就是：定义一个标准接口，让所有工具都用同一种方式暴露能力。

1  之前：N个模型 × M个工具 = N×M 套集成代码
2  之后：N个模型 + M个工具 = N+M 套集成代码

用人话说：以前每接一个工具都像是在装一个定制插座，现在只要插上标准USB-C就行。

二、MCP技术架构：三分钟看懂

2.1 三角色模型

MCP的架构非常清晰，只有三个角色：

• Host（宿主）：你的AI应用——Claude Desktop、Cursor、IDE插件等
• Client（客户端）：Host内部的组件，跟每个Server保持1:1连接
• Server（服务端）：暴露工具能力的外部进程——GitHub Server、PostgreSQL Server等

2.2 通信协议：JSON-RPC 2.0

MCP选择了JSON-RPC 2.0作为底层通信协议。为什么？因为它足够简单。

一个完整的工具调用只需要3步：

第1步：工具发现（tools/list）

 1  // Client → Server
 2  {"jsonrpc":"2.0","id":1,"method":"tools/list"}
 3  
 4  // Server → Client
 5  {"jsonrpc":"2.0","id":1,"result":{
 6  "tools":[{
 7  "name":"create_issue",
 8  "description":"在GitHub上创建Issue",
 9  "inputSchema":{
10  "type":"object",
11  "properties":{
12  "title":{"type":"string"},
13  "body":{"type":"string"}
14        }
15      }
16    }]
17  }}

第2步：AI决定调用工具 模型看到可用工具列表后，根据用户请求自主决定调哪个。

第3步：工具执行（tools/call）

1  // Client → Server
2  {"jsonrpc":"2.0","id":2,"method":"tools/call",
3  "params":{"name":"create_issue",
4  "arguments":{"title":"修复登录Bug","body":"详见日志..."}}}
5  
6  // Server → Client
7  {"jsonrpc":"2.0","id":2,"result":{
8  "content":[{"type":"text","text":"Issue #42 已创建"}]
9  }}

就这么简单。 不需要学新框架，不需要特殊的SDK，任何能发HTTP请求的语言都能实现。

2.3 三种传输方式

2.4 四大核心原语

其中Sampling最有意思——它允许MCP Server反向调用Host里的AI模型。比如一个"代码审查"Server可以请求Host的模型来分析代码质量，而不需要自己调用API。

这意味着MCP Server不只是被动提供工具，还能主动利用AI能力。

三、谁在用MCP？答案是：几乎所有人

3.1 全球接入时间线

AAIF（Agentic AI Foundation） 的联合创始成员：Anthropic、Block（Square母公司）、OpenAI。支持成员：AWS、Google、微软、Cloudflare、Bloomberg。

这意味着MCP已经不是Anthropic一家的协议了，而是由Linux Foundation治理的行业标准。

3.2 中国公司也全面跟进

用人话说：中国四大AI巨头全部接入了MCP。 这在AI协议标准化的历史上是罕见的共识——一个美国公司开源的协议，中国公司二话不说就全接了。

3.3 开发工具支持

2026年的状态：不支持MCP的AI工具，就像2020年不支持OAuth的API一样——你可以不接，但用户会用脚投票。

四、MCP Server生态：万物皆可MCP

4.1 数字说话

4.2 Star最多的MCP Server

4.3 官方参考Server

Anthropic提供了一系列"开箱即用"的参考Server：

4.4 MCP注册中心和市场

五、MCP vs A2A：两个协议不是竞争，是搭档

5.1 一句话区分

• MCP：Agent怎么用工具（Agent-to-Tool）
• A2A：Agent怎么找同事（Agent-to-Agent）

5.2 详细对比

5.3 它们怎么配合？

一个完整的多Agent系统可以同时使用两个协议：

1  用户 → Agent A（MCP调用数据库查数据）
2           ↓
3         Agent A（A2A委派给Agent B做分析）
4           ↓
5         Agent B（MCP调用可视化工具出图表）
6           ↓
7         结果返回给用户

MCP管"用什么工具"，A2A管"找谁帮忙"。 就像HTTP和SMTP不是竞争关系——HTTP用来浏览网页，SMTP用来发邮件，各司其职。

六、协议版本演进：MCP在快速进化

6.1 四个版本

6.2 安全演进：从裸奔到OAuth 2.1

初始版本的MCP没有内置认证机制。2025年3月版本引入了OAuth 2.1，要求远程Server必须实现：

• PKCE（RFC 7636）：防止授权码截获
• Resource Indicators（RFC 8707）：防止Token被跨Server滥用
• Protected Resource Metadata（RFC 9728）：Server自动广播认证服务器位置

这是MCP从"好用的玩具"变成"企业级基础设施"的关键一步。

6.3 已知的安全挑战

七、实战：怎么搭一个MCP Server？

7.1 最简Server（TypeScript）

一个暴露"获取天气"工具的MCP Server，核心代码不到30行：

 1  import { McpServer } from"@modelcontextprotocol/sdk/server/mcp.js";
 2  import { StdioServerTransport } from"@modelcontextprotocol/sdk/server/stdio.js";
 3  import { z } from"zod";
 4  
 5  const server = newMcpServer({ name: "weather", version: "1.0.0" });
 6  
 7  server.tool("get_weather",
 8    { city: z.string().describe("城市名") },
 9  async ({ city }) =>; {
10  const weather = awaitfetchWeather(city);
11  return { content: [{ type: "text", text: weather }] };
12    }
13  );
14  
15  const transport = newStdioServerTransport();
16  await server.connect(transport);

7.2 在Claude Desktop中使用

在claude_desktop_config.json中添加：

1  {
2  "mcpServers": {
3  "weather": {
4  "command": "node",
5  "args": ["weather-server.js"]
6      }
7    }
8  }

重启Claude Desktop，它会自动发现并注册get_weather工具。当用户问"北京今天天气怎么样？"时，Claude会自主调用这个工具。

从开发到可用，不到10分钟。 这就是MCP相比自己写Function Calling的优势——零胶水代码。

7.3 企业落地清单

八、2026下半年：MCP的三个挑战

8.1 有状态 vs 无状态

当前MCP的会话是有状态的——Client和Server之间维持长连接。这在本地使用（stdio）没问题，但在企业级部署中会碰到负载均衡的难题：有状态会话很难水平扩展。

2025年11月版本做了无状态改进，但还没有完全解决。2026年roadmap的第一优先级就是Transport Evolution & Scalability。

8.2 治理瓶颈

MCP的社区提案数量已经远超核心团队的审查能力。虽然AAIF提供了Linux Foundation级别的治理框架，但贡献者阶梯和权限委派模型还在建设中。

2026年4月的MCP Dev Summit North America（纽约）有约1200人参加，社区热度很高，但治理速度需要跟上。

8.3 企业合规

目前MCP缺少标准化的审计追踪（Audit Trail） 能力，这是金融、医疗等受监管行业的硬性要求。SSO集成和网关模式也在roadmap上，但尚未落地。

老周的判断：MCP的技术架构已经成熟，生态已经爆发。下一步的关键不是"能不能用"，而是"能不能在大企业里用"。

写在最后

回看技术史，真正改变行业的往往不是最复杂的技术，而是最简单的标准。

• HTTP不是最好的传输协议，但它统一了Web
• USB-C不是最快的接口，但它统一了充电
• JSON不是最高效的数据格式，但它统一了API

MCP大概率会成为AI工具生态的HTTP。 不是因为它技术最先进，而是因为它足够简单、足够开放，并且在关键时间窗口获得了关键玩家的共识。

18个月内，从Anthropic一家的实验项目，到OpenAI、Google、微软、阿里、腾讯全面接入，再到Linux Foundation托管——这个收敛速度比任何人预料的都快。

一句话总结：AI Agent的能力上限取决于模型，但能力下限取决于它能接多少工具。MCP把这个下限从"有多少胶水代码"变成了"有多少MCP Server"。

而现在，已经有10,000多个了。

我是老周，一个在架构领域摸爬滚打多年的技术人。如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。关注「老周聊架构」，每周深度解读AI和架构的最新趋势。