两层画面如何形成。

2024 年年底，三种协议看起来都还有得一拼。Anthropic 的 Model Context Protocol 已在前一年 11 月出厂。Google 于 2025 年 4 月发布了 Agent-to-Agent（A2A），作为一种智能体向其他智能体委派的对等协议。IBM 的 Agent Communication Protocol（ACP）也在同一年春天亮相，瞄准的是那种"远程过程调用模型"显得过重的本地与边缘部署。每家厂商的路线图幻灯里都有一页，论证三种协议将因面向不同范围而共存。

互操作问题深入解析走一遍当时让三种协议看起来都合理的设计压力。真正发生的是其中两种合并了。2025 年 7 月 IBM 把 ACP 贡献给 Linux 基金会，到秋天，它的能力被并入 A2A 规范，作为"邻近智能体"模式。ACP 与后事是那份事后剖析——简版是：ACP 的差异化在于给共置智能体的一种更轻传输，A2A 通过加入一条 stdio 近邻绑定接下了这个用例，而不是逼所有部署走远程 HTTP。

MCP 走的是另一条收敛路径。它没有与 A2A 合并，而是划了一道界线：MCP 只处理一个智能体的模型如何调用一个工具。它守住了这份窄。2025-11-25 规范是 2026 年多数宿主与服务器锚定的版本，它把面冻结得足够稳，让生态代码停止震荡。到 2026 年年初，这个领域谈起 MCP 与 A2A 的口吻，一如当年谈起 HTTP 与 TCP——不同的活、叠起来、完整部署里都需要、彼此不吞并。

当前路线图把这条切分讲得更明。Q3 2026 的一份联合互操作规范由 MCP 与 A2A 的维护者小组共同起草，定义了一项通过 A2A 委派的任务如何携带 MCP 工具清单引用，好让接收方智能体用同一套工具、同一份鉴权。这份文档是"两层画面"不只是描述性的最强信号——维护者打算把这种组合做成一等公民。

作为工具层的 MCP。

MCP 在两层画面里的活儿窄而具体：某个智能体的模型要调用一件工具，MCP 就是那次调用的协议线形。MCP 架构深入解析细讲 JSON-RPC 生命周期、"客户端-服务器-宿主"的参与者模型，以及 initialize 握手。对两层画面而言，要紧的观察是：MCP 的参与者是有意不对称的——宿主跑客户端、工具跑服务器，不指望服务器彼此对话。这份不对称就是让 MCP 成为"下面那层"的原因：它终止在智能体图的叶子处，也就是真正与外部世界打交道的地方。

生态形态强化了这一点。MCP 注册表与分发一篇讲了公开注册表——它索引了成千上万个小而单一职责的服务器——文件系统、Postgres、Slack、Snowflake。中位数服务器只暴露少量工具，仅此而已。这就是"M"在真实部署里的样子：你的宿主接八到十台 MCP 服务器，每一台把一件事做好，每一台多半是你团队之外的人写的。MCP 不是一种被硬塞进"工具"角色的通用消息协议；它就是那个角色，被讲明了。

作为智能体层的 A2A。

A2A 的活儿是对等之间的委派。MCP 建模的是"一个模型伸手够一件工具"，A2A 建模的是"一个智能体伸手够另一个智能体"——一个有自己推理循环、自己工具层、对如何完成任务有自己主张的智能体。A2A v1 深入解析细讲这份规范；对两层画面而言，该协议的形状在三处上要紧。

第一，任务有生命周期。A2A 任务在九个状态之间流动——submitted、working、input-required、auth-required、completed、canceled、failed、rejected、unknown——两侧都能观察这些迁移。这份生命周期存在，是因为委派本质上是异步的：委派方把活儿发出去，被委派方要花上数秒到数分钟去做，两侧都需要一份关于进度与打断的共同词表。MCP 没有对应物，因为 MCP 里的工具调用是请求—响应。

第二，发现是一等公民面。Agent Cards 与发现一篇讲了 A2A 智能体发布的 JSON 文档，用来描述它能做什么、接受哪种鉴权、支持哪些流式模式。Agent Card 是"你可以把哪些事委派给我"的合约，也承载着委派方在承诺一次任务之前需要的元数据。MCP 的 tools/list 是工具层的对应物，但 Agent Card 住在对等层、更丰富——它描述的是一个智能体，而不是一次调用。

第三，A2A 把流式与反压当作常态处理。一项被委派的任务可以流出中间输出、在跑到一半时请求补充输入、把鉴权交还给委派方的用户。这些流之所以存在，是因为对等智能体的活儿不是原子的——它是被委派方为委派方跑的一个小工作流。A2A 是"上面那层"，因为它终止在智能体图的顶部，终止在"做决定的智能体之间"的边界，而不是"智能体与工具之间"的边界。

画面在哪里失灵。

两层画面对一种特定部署形态是诚实的：多厂商、网络连通、由多来源工具组成的智能体向住在别处的对等智能体委派。这种形态在 2026 年很常见，但并非普适；有两类部署会把这幅画面塌缩。

第一是单厂商栈。全 Anthropic、全 Google 或全 OpenAI 的部署，可以完全不动 A2A 就把智能体到智能体的交接接在厂商自家 SDK 原语上。委派依然真实，但厂商提供的是它自己的私有形状；只有在另一家厂商的智能体进入视野的外缘，才需要 A2A。困在一家厂商生态里的团队，往往可以在几个月里都不需要"上面那层"，在那个阶段把 A2A 当成必备就是过度设计。第二家厂商出现时再把 A2A 画进来，此前不必。

第二是本地或边缘部署。一台机器上跑一个智能体，通过 stdio 够到共置的工具，用不着 HTTP、OAuth，也用不着 Agent Card。这正是 ACP 曾经的主打场景；ACP 会并入的原因是 A2A 与 MCP 一起就能处理它，但前提是你接受两层画面塌进同一个进程边界。本地智能体跟本地工具讲话，是走 stdio 的 MCP，无需 A2A。本地智能体把活儿交给另一个本地智能体，是走 stdio 的 A2A，两者之间没有 MCP 一跳。运维上你就是让一个进程通过带帧消息与另一个进程讲话。

第三，一个更微妙的失灵：当那件"工具"本身就是一个带推理循环的智能体、为了方便被部署成 MCP 服务器时，画面反转。以 MCP 暴露的检索增强问答服务是一个常见例子——协议线上它是工具，语义上它是被委派的智能体。上这种形态的团队会在"该套哪一份可观测性原语"上犯迷糊，因为 MCP 工具链假设叶调用，A2A 工具链假设对等协调。选一种框架并守住它，直到联合互操作规范让这个选择更清爽。

按两层画面（或抛开它）做规划。

经得住真实部署检验的规划规则是：先画信任边界，再把协议映射到穿越边界的点上。在同一信任域内的两个组件——同一团队、同一鉴权、同一审计链——之间也许根本不需要协议；一次直接函数调用往往就是对的。跨越信任边界的两个组件才需要协议，MCP 与 A2A 的取舍则跟随边界两侧是什么。模型跨界够一件叶能力：MCP。智能体跨界够一个对等智能体：A2A。两处跨界、各在不同位置：两种协议。完整画面像下面这样。

┌─────────────────────────────────────────────────────────────┐
│ Team A trust domain                                         │
│                                                             │
│   User ──▶ Host (Claude Desktop)                            │
│              │                                              │
│              ├── Agent A (planner)                          │
│              │       │                                      │
│              │       ├─ MCP ──▶ fs-server (leaf tool)       │
│              │       ├─ MCP ──▶ db-server (leaf tool)       │
│              │       │                                      │
│              │       └─ A2A ══════════════════════════╗     │
│              │                                        ║     │
└───────────────────────────────────────────────────────║─────┘
                                                       ║
┌──────────────────────────────────────────────────────▼──────┐
│ Team B trust domain                                         │
│                                                             │
│   Agent B (research specialist)                             │
│       │                                                     │
│       ├─ MCP ──▶ arxiv-server (leaf tool)                   │
│       └─ MCP ──▶ web-search-server (leaf tool)              │
└─────────────────────────────────────────────────────────────┘

两个信任域，五处协议线穿越。每条 MCP 箭头都是某个智能体的模型伸手够一件叶能力。那唯一一条 A2A 箭头是两个各自持有工具的对等智能体之间的边界穿越。两种协议都各挣其位，因为这份部署两种形状都有。把 Team B 换成 Team A 域内的另一个智能体，那条 A2A 箭头就消失了——委派变成一次函数调用、或一条共享队列、或者同团队基础设施本就提供的任何原语。协议只在边界真实存在时才是必要的。

而当整个系统装进一台机器时，两层就塌进同一条通道。那样的部署长这样。

Local process boundary
┌──────────────────────────────────────┐
│  Host binary                         │
│    ├─ Agent (stdio) ─▶ fs-tool       │  (MCP over stdio)
│    └─ Agent (stdio) ─▶ sub-agent     │  (A2A over stdio)
└──────────────────────────────────────┘
Two protocols, one transport, one trust domain.

你要带走的框架是：按你实际拥有的边界来挑协议，而不是按你在某家厂商幻灯里看到的图。两层画面是真的，但它描述的是一种多厂商、跨网络的部署形态。在一家厂商内、在一台机器内、在一个信任域内，两层里通常有一层会塌掉——这不是画面失效，而是画面对范围的诚实。造你需要的那一层。等到一处要求另一层的边界出现时，再加进来。