通信协议：MCP 深入 + A2A
智能体怎么标准化地连「工具」和连「别的智能体」
a3.1 你认识了 MCP——智能体接工具的"USB-C"。这一节我们做两件事:把 MCP 的架构拆开看清,再认识一个新角色 A2A。
一句话先记住它俩的分工:MCP 让智能体连"工具",A2A 让智能体连"别的智能体"。 当智能体越来越多,这两条标准化管道,就是它们协作的地基。
MCP 的架构:Host / Client / Server
MCP 不是一个东西,而是三个角色在用统一规矩(JSON-RPC)对话:
- Host:你用的那个 AI 应用,智能体在这里跑。
- Client:Host 内部为"每个外部能力"建的一条连接。
- Server:真正提供能力的服务——它向外暴露三样东西:
tools(可调用的工具)、resources(可读的数据)、prompts(预设提示)。
所以你给 Claude Code "加一个 MCP server",就是接上了一个能力源;之后它用统一方式调用,换任何支持 MCP 的 Host 都能复用——这就是 a3.1 说的"一次接好、处处可用"的底层机制。
再认识 A2A:智能体之间的"通用语"
MCP 解决"智能体↔工具"。但当你有多个独立的智能体(可能来自不同团队、不同框架),它们怎么互相发现、对话、派活?——这就是 A2A(Agent-to-Agent) 要解决的:一套让智能体之间标准化协作的协议(Google 2025 提出,后并入 Linux 基金会的智能体生态;以官方为准)。
| MCP | A2A | |
|---|---|---|
| 连接谁 | 智能体 ↔ 工具/数据 | 智能体 ↔ 别的智能体 |
| 类比 | 给智能体配"外设接口"(USB-C) | 智能体之间的"通用语/对讲机" |
| 解决 | 一次接好工具,处处可用 | 跨团队/跨框架的智能体互相协作 |
趋势:MCP 已是事实标准、生态庞大;A2A 较新、生态在建。先吃透 MCP,A2A 了解概念、关注进展即可。
MCP、A2A 很重要,但它们只是标准化的连接管道——让"接工具""接智能体"这件事不用每次重造。
它们不会让你的智能体变聪明。真正决定好不好用的,还是前面那些:会不会想(ReAct)、有没有好工具和资料、评估到不到位。别为追新协议而追,尤其 A2A 还新、生态在建,按需了解、别过早 all-in。
我的场景是:『___』(我来描述)。请帮我判断:我需要的是把智能体接到某些工具/数据(MCP),还是让多个智能体互相协作(A2A),还是都要?简单说明理由。
现在你看清了智能体"对外连接"的两条标准管道:MCP 连工具、A2A 连智能体,以及 MCP 的 Host/Client/Server 架构。连接这块,你有了体系化的认知。
但目前的小雅,本事是"固定"的——它不会因为用得多就变得更好。下一节,我们聊一个前沿又有意思的方向:智能体自进化——让它从自己的经验里总结、改进,越用越顺手。
