1. MCP 生态演进
MCP 从 2024 年底发布至今,已经走完了「概念验证 → 广泛采用 → 生态治理」三步。如今工具侧的接入几乎成了 AI 产品的标配:桌面端有 Claude Desktop / Claude Code,编程工具有 VS Code / Cursor,云端有各大模型平台的托管网关。
一句话:如果说 2024 年是 MCP 的「元年」,2025-2026 就是它的「春秋战国」——协议跑通了,接下来就是标准、托管与互操作性的争夺。
1.1 生态全景图
┌───────────────────────────────┐
│ 客户端 / Host │
│ Claude · VS Code · 云 Agent │
└───────────────┬───────────────┘
│ MCP
┌───────────────┬───────┴───────┬─────────────────┐
▼ ▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 官方服务器 │ │ 社区服务器 │ │ 云托管服务 │ │ A2A 互联 │
│ GitHub 参考实现│ │ 各种 SDK/场景 │ │ AWS/Google │ │ Agent↔Agent │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
2. 官方与社区服务器盘点
2.1 官方参考服务器(modelcontextprotocol/servers)
官方仓库维护了一批高质量参考实现,适合直接使用与学习:
| 服务器 | 能力 | 典型场景 |
|---|---|---|
| Filesystem | 本地文件读写 | 代码仓库操作 |
| Git | Git 操作封装 | 版本控制自动化 |
| PostgreSQL / SQLite | 数据库查询 | 数据访问 |
| Memory | 键值长期记忆 | 跨会话记忆 |
| Fetch | URL 抓取与内容提取 | 网页读取 |
| Brave Search | Web 搜索 | 信息检索 |
| Puppeteer | 浏览器自动化 | 网页截图/交互 |
| Slack / Google Drive | 办公协作 | 团队工具集成 |
| Everything | 全能力大杂烩(示例) | 学习协议细节 |
// 在 Claude Desktop 中挂载官方文件服务器
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/me/projects"
]
}
}
}
2.2 社区生态
社区服务器以 npm 包 @xxx/mcp-server-*、Python 的 mcp-server-* 为分发主流,覆盖监控(Sentry)、通知(Slack)、支付、CRM、云平台操作等。选用社区服务器的关键检查项:
- 发布频率与维护活跃度(近 3 个月是否有 commit);
- 权限模型是否最小化(是否硬编码了高危能力);
- 是否经过安全审计或使用人数足够多。
一句话:官方服务器教你「怎么写规范」,社区服务器帮你「免造轮子」——但轮子的安全性必须自己验。
2.3 生态规模与分发渠道
社区生态已经形成明显的头部效应,接入渠道也趋于统一:
| 渠道 | 内容 | 适合受众 |
|---|---|---|
| npm(TypeScript SDK) | 官方 + 社区服务器包 | Node 技术栈 |
| PyPI(Python SDK) | mcp-server-* 系列 | Python / ML 技术栈 |
| GitHub 官方仓库 | 参考实现 + 示例 | 协议学习者 |
| 云市场 | AWS / Google / Azure 的托管目录 | 企业采购 |
评估一个社区服务器是否「够成熟」,可以量化打分:
成熟度 = 0.3 × 最近3个月commit数 / 12
+ 0.3 × 周下载量 / 10000
+ 0.2 × 文档完整度(0-1)
+ 0.2 × 安全实践(0-1:是否最小权限/无硬编码密钥)
得分低于 0.4 的建议只用在自己的沙箱环境,而不是接入生产 Agent。
3. 云厂商托管方案
三大云厂商都推出了 MCP 相关托管方案,核心诉求一致:让 MCP 服务器从「本地子进程」升级为「可伸缩的云端服务」。
| 厂商 | 托管入口 | 特点 | 适合场景 |
|---|---|---|---|
| AWS | Amazon Bedrock Agent 挂载 MCP / aws-samples MCP 服务器 | 与 IAM、CloudWatch 深度集成 | 企业 AWS 原生栈 |
| Gemini API MCP 支持 / Vertex AI Agent Builder | 与 GCP IAM、Logging 集成 | GCP 用户、多模态 Agent | |
| Azure | Azure AI Foundry / Azure OpenAI MCP | 与 Entra ID、App Insights 集成 | 微软生态企业 |
3.1 AWS 侧接入示例
// Bedrock Agent 的 action group 通过 MCP 连接外部服务器
{
"agent": {
"actionGroups": [
{
"name": "mcp-tools",
"type": "MCP",
"mcpConfig": {
"url": "https://mcp-internal.example.com/mcp",
"auth": {
"type": "IAM",
"role": "arn:aws:iam::123456789012:role/mcp-gateway-role"
}
}
}
]
}
}
3.2 Google Cloud 侧:Python 调用云托管 MCP
# 使用 Google Cloud 托管的 MCP 端点(示例模式)
from google.cloud.aiplatform import AgentSession
from mcp import ClientSession
# 通过云 SDK 获取短期令牌,再走 Streamable HTTP 传输
transport = StreamableHttpTransport(
"https://vertex-agent.example.googleapis.com/mcp",
headers={"Authorization": f"Bearer {gcp_oauth_token()}"},
)
async with ClientSession(transport) as session:
await session.initialize()
tools = await session.list_tools()
result = await session.call_tool(
tools[0].name, {"query": "检索订单明细"}
)
一句话:云托管的本质是把 MCP 服务器的「进程生命周期」换成「平台托管」,鉴权、伸缩、监控全部交给云厂商的既有能力。
4. MCP 与 A2A 协议对比
MCP 解决的是「Agent ↔ 工具/数据」,而 A2A(Agent2Agent,Google 于 2025 年提出的开放协议)解决的是「Agent ↔ Agent」。两者经常被混为一谈,其实定位完全不同。
4.1 协议定位对比
| 维度 | MCP | A2A |
|---|---|---|
| 定位 | 模型上下文与工具接入 | 智能体之间协作 |
| 核心实体 | Tool / Resource / Prompt | AgentCard、Task |
| 消息模型 | JSON-RPC 2.0(请求/响应) | 面向任务的异步消息 |
| 交互模式 | 客户端发起、服务器执行 | 双方对等、协商分工 |
| 状态管理 | 会话 + 握手协商 | 任务生命周期(长期运行) |
| 典型场景 | 让 Agent 能调数据库、能发邮件 | 让两个 Agent 协同完成复杂任务 |
4.2 A2A 的 AgentCard 示例
{
"name": "research-agent",
"description": "负责资料检索与综述",
"url": "https://agents.example.com/research/a2a",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{ "id": "web-search", "name": "网络搜索" },
{ "id": "summarize", "name": "内容摘要" }
]
}
一句话:MCP 是「给 Agent 装手」,A2A 是「给 Agent 介绍同事」——两者可以共存:一个 Agent 通过 MCP 拿数据,再通过 A2A 把结论交接给另一个 Agent。
4.3 A2A 的消息流示例
A2A 的任务不是一次请求/响应就能完成的,而是通过任务(Task)状态推进。下面是一次「A2A 委托任务」的典型消息流:
// 客户端向远端 Agent 创建任务
{
"jsonrpc": "2.0",
"id": 1,
"method": "tasks/send",
"params": {
"agentId": "research-agent",
"task": {
"id": "task-2026-0001",
"message": {
"role": "user",
"parts": [
{ "text": "调研 2026 年 MCP 生态的最新托管方案,输出 500 字综述" }
]
}
}
}
}
// 远端 Agent 的最终响应(含执行状态与产物)
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"task": {
"id": "task-2026-0001",
"status": {
"state": "completed",
"message": {
"role": "agent",
"parts": [{ "text": "已完成调研……(综述内容省略)" }]
}
},
"artifacts": [
{ "id": "art-1", "name": "survey.md", "kind": "file", "url": "https://…/survey.md" }
]
}
}
}
对比 MCP 的同步 tools/call,A2A 的任务是异步、有状态、可产生产物的——这就是两者在抽象层次上的根本差异。
5. 标准化进展
生态成熟的关键是从「一家主导」走向「多方共建」:
- 协议规范开源:MCP 规范与 SDK 采用开放治理,社区 PR 活跃,协议版本稳定演进。
- 贡献给中立基金会:Anthropic 已提议将 MCP 贡献给 Linux 基金会旗下的 Agentic AI 项目,意图摆脱单一厂商色彩,推动跨供应商兼容。
- 认证与合规:云厂商陆续推出 MCP 服务器的安全基线、审计与托管认证,降低企业采纳门槛。
5.1 协议版本演进时间线
| 版本 | 主要变化 | 影响 |
|---|---|---|
2024-11-05 | 首版规范,stdio + SSE | 奠定框架 |
2025-03-26 | 支持 Streamable HTTP、鉴权草案 | 远程部署门槛下降 |
2025-06-18 | 能力协商细化、OAuth 完善 | 公网托管成为可能 |
# 检查本地 SDK 与规范版本的兼容性
npx @modelcontextprotocol/sdk --version
# 输出形如:1.x.y(遵循 2025-06-18 规范)
6. 演进趋势与选型建议
6.1 三个值得关注的趋势
- 传输收敛:Streamable HTTP 正取代双端点 SSE,远程部署的配置成本显著下降。
- 托管成主流:企业级 MCP 服务器从自建进程转向云托管,鉴权与审计由平台兜底。
- MCP + A2A 分工:MCP 继续深耕工具接入,A2A 补齐智能体间协作,两者在 Agent 平台里形成互补而非竞争。
6.2 选型建议
| 你的处境 | 建议 |
|---|---|
| 个人/原型 | 官方服务器 + stdio 即可,先用起来 |
| 中小企业 | 社区服务器 + 代理聚合,控制服务器数量 |
| 大厂/合规敏感 | 云托管 MCP + 自建网关,纳入审计体系 |
| 多 Agent 协作 | 引入 A2A,MCP 继续负责工具接入 |
6.3 组合架构:一个 MCP + A2A 的网关
成熟的 Agent 平台往往同时扮演两种角色:对内通过 MCP 消费工具,对外通过 A2A 响应其他 Agent 的委托。
// 网关同时挂载 MCP 工具源与 A2A 任务端点
class AgentGateway {
private mcpTools: Map<string, McpToolHandle> = new Map();
private a2aTasks: Map<string, A2aTask> = new Map();
// MCP 侧:接入工具服务器
async mountMcpServer(name: string, params: StdioServerParameters) {
const client = await connectMcp(params);
const { tools } = await client.listTools();
for (const t of tools) {
this.mcpTools.set(`${name}__${t.name}`, {
client, schema: t.inputSchema, description: t.description,
});
}
}
// A2A 侧:响应远端 Agent 的委托
async handleA2aTask(agentId: string, message: string): Promise<string> {
// 把委托任务翻译成内部工具编排
const plan = await this.planWithTools(message, [...this.mcpTools.keys()]);
const result = await this.executePlan(plan);
return result;
}
}
6.4 生态落地检查清单
接入任何 MCP 服务器前,逐项打勾:
- 服务器来源可信(官方 / 高星社区 / 已审计)
- 权限模型最小化,无多余高危能力
- 传输与鉴权符合部署边界(本地 stdio / 远程 Bearer)
- 工具 schema 与描述质量达标(模型能看懂、能用对)
- 有日志与指标接入,可观测性闭环
- 版本与规范对齐,避免锁定到过期 API
- 若需多 Agent 协作,A2A 端点已纳入同一网关
7. 总结
MCP 生态已经从「单点协议」成长为「协议 + 服务器 + 托管 + 协作标准」的完整体系:
| 生态层 | 代表 | 你的行动 |
|---|---|---|
| 协议 | MCP(工具接入)、A2A(Agent 协作) | 理解分工,组合使用 |
| 服务器 | 官方参考 + 社区包 | 优先官方,社区严选 |
| 托管 | AWS / Google / Azure | 按云栈选型,关注鉴权 |
| 标准化 | Linux 基金会治理、版本演进 | 跟踪版本,避免锁定 |
至此,本专题从协议理解、服务端实现、客户端集成、多服务器编排、上下文工程、可观测性到生态全景,覆盖了 MCP 工程化的完整路径。下一步的实践,就是把本文的选型表做成你团队的第一份 MCP 落地清单。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。