<!-- title: 多Agent协议栈收敛：四协议分层共存实测 -->

# 多Agent协议栈收敛：四协议分层共存实测

2026年，多智能体系统的核心战场已从"谁的框架更强"转向"谁定义了Agent之间的通信协议"。Google的A2A、IBM的ACP、社区驱动的ANP与Anthropic的MCP，四条协议线路正从各自为战走向分层共存。本文从协议栈视角解剖四大协议的设计哲学、传输层差异与生产落地方案，并结合Blackboard架构复兴、MASEval评测基准和六种编排模式，给出可复制的多Agent协作架构选型方案。

## 一、四协议分层定位：不是竞争，是栈

2026年Q1，arxiv论文《A Survey of Agent Interoperability Protocols》明确提出一个关键洞察：**MCP、A2A、ACP、ANP并非零和博弈，而是分属协议栈的不同层级**。这一分层模型正在被业界快速接受。

| 层级 | 职责 | 协议 | 类比 |
|------|------|------|------|
| L4 发现层 | Agent发现、身份、去中心化注册 | ANP | DNS + 服务发现 |
| L3 协作层 | Agent间任务委托、状态同步、长时任务 | A2A | HTTP + REST |
| L2 通信层 | 消息格式、流式传输、多模态载荷 | ACP | WebSocket + gRPC |
| L1 工具层 | 单Agent与工具/数据源的连接 | MCP | USB/驱动层 |

这个分层模型的核心逻辑是：**MCP解决"一个Agent怎么用工具"，A2A解决"Agent之间怎么委托任务"，ACP解决"Agent之间怎么传消息"，ANP解决"Agent怎么找到彼此"**。

实际生产系统中，这四层协议往往同时存在。一个典型的多Agent客服系统可能：用MCP让每个Agent连接知识库和CRM，用A2A在Agent之间传递工单，用ACP进行实时消息流式传输，用ANP实现动态Agent注册发现。

## 二、A2A协议深度解析：Google的Agent间HTTP

### 2.1 核心设计

Google于2025年提出、2026年持续迭代的Agent2Agent（A2A）协议，定位为Agent间的任务委托协议。其核心设计原则是**Agent作为不透明实体**——调用方不需要知道被调用Agent的内部实现，只需要知道它的Agent Card（能力描述）。

A2A协议的关键概念：

- **Agent Card**：JSON格式的Agent能力描述文件，包含名称、描述、支持的技能、认证方式、端点URL。类似OpenAPI规范，但描述的是Agent能力而非API端点。
- **Task**：A2A的核心交互单元。Client Agent向Remote Agent发送一个Task，Task有生命周期（submitted → working → completed/failed/canceled）。
- **Message与Artifact**：Task执行过程中，Agent通过Message返回中间状态，通过Artifact返回最终产物。Message支持多模态（文本、图片、文件）。
- **Push Notification**：支持长时任务的通知机制，Remote Agent可以通过Webhook主动推送状态变更。

### 2.2 代码示例

```python
# A2A协议：发送任务给远程Agent
import httpx

async def delegate_to_research_agent(query: str):
    """通过A2A协议将研究任务委托给远程Agent"""
    
    # Step 1: 获取Agent Card（发现能力）
    agent_card = await httpx.get(
        "https://research-agent.example.com/.well-known/agent.json"
    )
    capabilities = agent_card.json()
    print(f"Agent能力: {capabilities['skills']}")
    
    # Step 2: 创建Task
    task_request = {
        "jsonrpc": "2.0",
        "method": "tasks/send",
        "id": "task-001",
        "params": {
            "task": {
                "id": "research-20260604",
                "message": {
                    "role": "user",
                    "parts": [{"type": "text", "text": query}]
                }
            }
        }
    }
    
    # Step 3: 发送并获取结果
    response = await httpx.post(
        "https://research-agent.example.com/a2a",
        json=task_request,
        headers={"Content-Type": "application/json"}
    )
    
    result = response.json()
    # 提取Artifact（最终产物）
    artifacts = result.get("result", {}).get("artifacts", [])
    return artifacts
```

### 2.3 A2A的优势与局限

**优势**：不透明设计降低了Agent间的耦合度；Task生命周期管理天然支持长时任务；Google Cloud和超过50家合作伙伴的企业背书。

**局限**：仅定义了Client-Remote的交互模式，缺乏对等（Peer-to-Peer）协作的原生支持；每层JSON-RPC调用增加约50ms延迟；Agent Card的标准化仍在演进中，不同实现之间兼容性参差不齐。

## 三、ACP协议：IBM的REST风格Agent通信

IBM的Agent Communication Protocol（ACP）走了一条截然不同的路线——**用REST的简洁性解决Agent间通信问题**。

### 3.1 设计哲学

ACP的核心思想是"Agent即微服务"。每个Agent暴露REST端点，通过标准HTTP方法进行同步/异步交互。与A2A的"Task委托"模型不同，ACP更像是"消息传递"模型。

ACP的三个关键特性：

- **同步与异步双模式**：简单查询走同步REST，长时任务走异步polling + notification。
- **流式输出**：支持SSE（Server-Sent Events）流式返回Agent的推理过程，这对用户体验至关重要。
- **Agent发现**：内置Agent注册中心，支持在线/离线Agent发现。

### 3.2 ACP vs A2A关键差异

| 维度 | A2A | ACP |
|------|-----|-----|
| 提出方 | Google | IBM (BeeAI) |
| 交互模型 | Task委托（Job Queue） | 消息传递（Messaging） |
| 传输协议 | JSON-RPC over HTTP | REST + SSE |
| Agent可见性 | 不透明（Opaque） | 可协商（Negotiable） |
| 流式支持 | 通过Message分片 | 原生SSE流 |
| 生态背书 | Google Cloud + 50+伙伴 | IBM + BeeAI社区 |
| 典型场景 | 跨组织Agent协作 | 同框架内Agent编排 |

### 3.3 代码示例

```python
# ACP协议：Agent间消息传递
from beeai_sdk import AgentClient, Message

async def collaborate_via_acp():
    """通过ACP协议进行Agent间协作"""
    
    # 发现可用的Agent
    registry = AgentClient("http://agent-registry:8080")
    agents = await registry.discover(capability="code-review")
    
    # 发送消息（同步模式）
    response = await agents[0].send_message(
        Message(
            role="user",
            content="Review this PR for security issues",
            metadata={"pr_url": "https://github.com/org/repo/pull/123"}
        ),
        mode="sync"  # 或 "async" + callback
    )
    
    # 流式获取推理过程
    async for chunk in agents[0].stream_thinking(
        Message(content="Explain your review decision")
    ):
        print(chunk.text, end="", flush=True)
    
    return response
```

## 四、ANP协议：去中心化Agent网络

如果说A2A是"Agent间的HTTP"，那么ANP（Agent Network Protocol）就是"Agent间的互联网"。

### 4.1 核心架构

ANP由W3C社区组推动，设计目标是在完全去中心化的环境中实现Agent的自主发现、认证和协作。其核心创新是三层架构：

- **身份层**：基于DID（Decentralized Identifier）的Agent身份系统。每个Agent拥有全局唯一的DID，通过可验证凭证（Verifiable Credential）证明自己的能力。
- **发现层**：去中心化的Agent注册与发现机制。不依赖中心化注册中心，通过P2P网络广播Agent能力。
- **协作层**：基于意图（Intent）的协作协议。Agent发布"我能做什么"（Intent Advertisement），其他Agent匹配"我需要什么"（Intent Request）。

### 4.2 ANP的独特价值

ANP解决的是前三个协议都没解决的问题——**当你不知道你的Agent需要和谁协作时，怎么找到对方？**

在跨组织场景中，这个问题尤为突出。例如：一个医疗机构的研究Agent需要调用全球各地的临床试验数据Agent。没有中心化的注册中心，Agent需要一种去中心化的方式找到彼此并建立信任。ANP的DID + Intent模式正是为此设计。

### 4.3 ANP的挑战

ANP目前仍处于早期阶段（W3C社区组草案），面临三大挑战：

1. **性能**：去中心化发现的延迟远高于中心化注册中心，首次发现可能需要数秒。
2. **安全**：DID验证链的开销使每次交互增加约200ms的认证延迟。
3. **采用率**：截至2026年Q2，ANP的企业采用率远低于A2A和MCP，主要活跃在学术和开源社区。

## 五、Blackboard架构复兴：共享状态的新范式

2026年，一个1980年代的AI经典模式正在多Agent领域强势回归——**Blackboard Architecture（黑板架构）**。

### 5.1 为什么Blackboard回来了？

多Agent系统面临的核心难题之一是**共享状态管理**。当多个Agent需要协同完成一个复杂任务时，如何让所有Agent看到一致的、最新的工作状态？

现有方案各有痛点：
- **消息传递**（A2A/ACP风格）：每个Agent维护自己的状态，通过消息同步。但消息丢失、乱序、重复导致状态不一致。
- **中心化存储**：所有Agent读写同一个数据库。但缺乏对"谁改了什么"的结构化管理。
- **层级传递**（Supervisor风格）：通过管理者传递状态。但管理者成为瓶颈，且中间传递引入延迟。

Blackboard架构提供了一个优雅的解法：**一个共享的结构化工作空间，所有Agent可以向其读写信息，一个控制器决定谁在什么时候行动**。

### 5.2 LbMAS：基于LLM的Blackboard多Agent系统

中科院团队在2025年提出的LbMAS（Large Language Model-based Multi-Agent System with Blackboard Architecture）是该方向的代表性工作。其核心结构：

```mermaid
graph TB
    subgraph Blackboard["黑板（共享工作空间）"]
        DS[数据层 - 原始输入与中间结果]
        KH[知识层 - 推理规则与领域知识]
        CH[控制层 - 任务分解与调度策略]
    end

    subgraph Agents["知识源（Agent集群）"]
        A1[研究Agent]
        A2[分析Agent]
        A3[写作Agent]
        A4[审核Agent]
    end

    CTRL[控制器 - 调度与冲突解决]

    A1 -->|写入发现| DS
    A2 -->|读取数据<br>写入分析| KH
    A3 -->|读取知识<br>写入草稿| DS
    A4 -->|读取草稿<br>写入反馈| CH

    CTRL -->|激活条件<br>满足的Agent| Agents
    CTRL -->|读写| Blackboard

    style Blackboard fill:#f0f4ff,stroke:#4a6fa5
    style CTRL fill:#fff4e0,stroke:#c5a04e
    style Agents fill:#f0fff4,stroke:#4caf50
```

LbMAS的黑板分为三个层次：

- **数据层**：存储原始输入、中间计算结果、最终产出物。每个Agent的输出都会被结构化地写入数据层。
- **知识层**：存储推理规则、领域约束、质量标准。这些知识可以被所有Agent共享引用。
- **控制层**：存储任务分解策略、Agent调度策略、冲突解决规则。控制器根据控制层的信息决定下一步激活哪个Agent。

### 5.3 Blackboard vs 消息传递：实测对比

| 维度 | Blackboard | 消息传递（A2A/ACP） |
|------|-----------|-------------------|
| 状态一致性 | 强（单点真相） | 弱（最终一致） |
| 调试可观测性 | 高（所有状态集中可见） | 低（需追踪消息链） |
| 扩展性 | 受限于黑板吞吐量 | 天然水平扩展 |
| Agent耦合度 | 低（通过黑板间接交互） | 中（需要知道对方接口） |
| 实现复杂度 | 中（需实现控制器） | 低（直接发送消息） |
| 适用场景 | 复杂推理、共享上下文 | 任务委托、流水线处理 |

## 六、六种编排模式选型图谱

多Agent编排模式（Orchestration Pattern）决定了Agent之间的协作拓扑。2026年的生产实践已收敛为六种主流模式：

```mermaid
graph LR
    subgraph 编排模式选型决策树
        Q1{任务是否<br>有明确阶段?}
        Q1 -->|是| Q2{阶段间<br>有无依赖?}
        Q1 -->|否| Q3{Agent是否<br>需要协调?}
        Q2 -->|线性依赖| P1[Pipeline<br>流水线模式]
        Q2 -->|树形依赖| P2[Hierarchical<br>层级模式]
        Q3 -->|需要| Q4{是否需要<br>中心决策?}
        Q3 -->|不需要| P5[Swarm<br>群智模式]
        Q4 -->|需要| P3[Supervisor<br>主管模式]
        Q4 -->|不需要| P4[Blackboard<br>黑板模式]
        P1 --> P6[Mesh<br>网状模式]
    end

    style P1 fill:#e3f2fd
    style P2 fill:#f3e5f5
    style P3 fill:#e8f5e9
    style P4 fill:#fff3e0
    style P5 fill:#fce4ec
    style P6 fill:#f5f5f5
```

### 6.1 六模式深度对比

| 模式 | 拓扑 | 适用场景 | 延迟 | 容错 | 实现复杂度 |
|------|------|---------|------|------|-----------|
| **Pipeline** | 线性链 | 文档处理、ETL | 低（顺序） | 差（单点断裂） | ★☆☆☆☆ |
| **Supervisor** | 星形 | 客服路由、任务分配 | 中（中心转发） | 中（主管备份） | ★★☆☆☆ |
| **Hierarchical** | 树形 | 企业决策、组织模拟 | 中高（多层转发） | 中（子树独立） | ★★★☆☆ |
| **Blackboard** | 星形+黑板 | 科研推理、共享上下文 | 中（黑板竞争） | 好（Agent可替换） | ★★★★☆ |
| **Swarm** | 全连接 | 头脑风暴、方案探索 | 高（协调开销） | 极好（无中心） | ★★★☆☆ |
| **Mesh** | 按需连接 | P2P协作、去中心化场景 | 可变 | 极好 | ★★★★★ |

### 6.2 生产场景映射

**代码审查系统** → Supervisor模式。主管Agent接收PR，分配给安全审查Agent、风格检查Agent、测试覆盖Agent，汇总后给出结论。

**科研论文生成** → Blackboard模式。研究Agent、分析Agent、写作Agent、审核Agent共享黑板上的论文状态，控制器根据进度激活对应Agent。

**客户支持中心** → Hierarchical模式。一级客服Agent处理常见问题，升级到二级专家Agent，再升级到三级人工客服。

**去中心化数据市场** → Mesh + ANP协议。Agent通过ANP发现数据提供者，直接P2P协商和交易。

## 七、MASEval：多Agent评测的新基准

评估单个Agent已经很难，评估多Agent协作系统更是量级跳跃。2026年出现的MASEval基准试图系统化解决这个问题。

### 7.1 MASEval评测维度

MASEval从四个维度评估多Agent系统：

- **任务完成度**（Task Completion）：系统是否正确完成了输入任务？用精确匹配和LLM-as-Judge两种方式评估。
- **协作效率**（Collaboration Efficiency）：Agent之间的通信次数、Token消耗、冗余交互比例。
- **鲁棒性**（Robustness）：当某个Agent失败或返回错误结果时，系统的恢复能力。
- **可扩展性**（Scalability）：Agent数量从3个增加到10个、50个时，系统性能的衰减曲线。

### 7.2 Multi-Agent-as-Judge（MAJ-Eval）

MAJ-Eval框架提出了一个递归的评估思路——**用多个Agent来评估多个Agent**。具体做法：

1. 三个评审Agent独立评估同一个多Agent系统的输出。
2. 评审Agent之间互不知晓对方的评分。
3. 取中位数作为最终评分，离散度作为置信度指标。

这种方法比单一LLM-as-Judge的准确率提高了23%，与人类评审的一致性从0.61提升到0.78（Cohen's Kappa）。

## 八、协议栈组合方案：三层架构实战

基于以上分析，推荐以下协议栈组合方案：

```mermaid
graph TB
    subgraph 应用层["应用层 - 编排模式"]
        ORC[编排器<br>Supervisor/Hierarchical/Swarm]
    end

    subgraph 协作层["协作协议层"]
        A2A[A2A - 跨Agent任务委托]
        ACP[ACP - Agent间消息传递]
    end

    subgraph 基础层["基础设施层"]
        MCP[MCP - Agent→工具连接]
        ANP[ANP - Agent发现与身份]
        BB[Blackboard - 共享状态]
    end

    ORC -->|任务分配| A2A
    ORC -->|消息传递| ACP
    A2A -->|调用工具| MCP
    ACP -->|调用工具| MCP
    A2A -->|Agent发现| ANP
    BB <-->|状态读写| A2A
    BB <-->|状态读写| ACP

    style 应用层 fill:#e8f5e9,stroke:#388e3c
    style 协作层 fill:#e3f2fd,stroke:#1976d2
    style 基础层 fill:#fff3e0,stroke:#f57c00
```

### 8.1 小团队快速启动方案（3-5个Agent）

| 组件 | 推荐 | 理由 |
|------|------|------|
| 编排模式 | Supervisor | 实现简单，LangGraph原生支持 |
| Agent间通信 | ACP（同框架内） | REST风格，上手快 |
| 工具连接 | MCP | 生态最成熟，工具库最丰富 |
| 状态管理 | 内存Blackboard | 无需额外基础设施 |
| 评测 | MASEval本地运行 | pip install maseval |

### 8.2 中型企业方案（10-30个Agent）

| 组件 | 推荐 | 理由 |
|------|------|------|
| 编排模式 | Hierarchical + Blackboard | 层级管理 + 共享上下文 |
| Agent间通信 | A2A（跨团队） + ACP（团队内） | 混合协议覆盖不同场景 |
| 工具连接 | MCP + 自定义Tool Server | 兼顾生态和定制需求 |
| 状态管理 | Redis-backed Blackboard | 持久化 + 高性能 |
| 评测 | MAJ-Eval + CI集成 | 自动化质量门控 |

### 8.3 大规模去中心化方案（50+Agent）

| 组件 | 推荐 | 理由 |
|------|------|------|
| 编排模式 | Mesh + Swarm混合 | 弹性拓扑适应动态环境 |
| Agent发现 | ANP | 去中心化发现 + DID身份 |
| Agent间通信 | A2A（正式委托） + P2P（实时协作） | 按需选择通信方式 |
| 状态管理 | 分布式Blackboard + CRDT | 最终一致性 + 无冲突合并 |
| 评测 | 持续MASEval + 生产监控 | 全生命周期质量保障 |

## 九、变现评估与训练营设计

### 9.1 变现潜力矩阵

| 方向 | 市场规模 | 技术门槛 | 竞争强度 | 推荐度 |
|------|---------|---------|---------|--------|
| MCP工具开发培训 | ★★★★ | ★★ | ★★ | ★★★★★ |
| A2A协议集成服务 | ★★★ | ★★★★ | ★★ | ★★★★ |
| Blackboard架构咨询 | ★★★ | ★★★★ | ★ | ★★★★ |
| 多Agent评测SaaS | ★★★★ | ★★★ | ★★★ | ★★★ |
| ANP去中心化Agent市场 | ★★ | ★★★★★ | ★ | ★★★ |

### 9.2 训练营课程设计

**"多Agent协议栈工程师"训练营**（建议定价：¥2999-4999）

模块一：协议基础（2天）
- MCP工具接入实战
- A2A Task生命周期管理
- ACP消息传递模式

模块二：架构设计（2天）
- 六种编排模式对比与选型
- Blackboard架构实现
- 共享状态管理策略

模块三：生产部署（2天）
- 协议栈组合方案设计
- MASEval评测集成
- 监控与故障排除

模块四：项目实战（2天）
- 从零构建一个多Agent客服系统
- A2A + MCP + Blackboard完整集成
- 评测与优化迭代

## 十、关键趋势与结论

2026年多Agent协作领域的三个确定性趋势：

**趋势一：协议栈标准化加速。** MCP已成为事实上的工具连接标准（Anthropic开源 + OpenAI采用）；A2A正在成为Agent间协作的事实标准（Google Cloud + 50+合作伙伴）。ANP在去中心化场景中有独特价值，但企业采用仍需时间。

**趋势二：Blackboard架构成为共享状态的主流解法。** 从中科院的LbMAS到多个开源实现（agent-blackboard、bMAS），Blackboard模式在需要强一致性共享上下文的场景中展现出明显优势。与消息传递方案相比，Blackboard在可观测性和调试效率上的优势尤为突出。

**趋势三：评测从"功能测试"走向"系统评测"。** MASEval和MAJ-Eval代表了多Agent评测的新范式——不只测单个Agent的能力，更测整个系统的协作效率、鲁棒性和可扩展性。将评测嵌入CI/CD管道（Eval-in-Loop）正在成为最佳实践。

**选型建议**：对于大多数团队，2026年的最佳起步组合是 **MCP（工具） + A2A（协作） + Supervisor/Blackboard（编排） + MASEval（评测）**。这个组合覆盖了协议栈的四个层级，社区支持完善，生产验证充分。在业务规模增长后，按需引入ACP（高性能消息传递）和ANP（去中心化发现）。

---

## 参考来源

1. [A Survey of Agent Interoperability Protocols: MCP, A2A, ACP and Beyond](https://arxiv.org/abs/2505.02279) — arxiv综述论文，提出协议分层模型与分阶段采用路线图
2. [Agent2Agent (A2A) Protocol Official Documentation](https://a2a-protocol.org/latest/) — Google A2A协议官方文档，定义Agent Card、Task生命周期等核心概念
3. [Multi-Agent Memory from a Computer Architecture Perspective](https://arxiv.org/html/2603.10062v1) — arxiv论文，提出三层内存层次模型，映射多Agent内存挑战到计算机体系结构
4. [Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture](https://arxiv.org/abs/2507.01701) — 中科院LbMAS论文，将黑板架构引入LLM多Agent系统
5. [MASEval: Extending Multi-Agent Evaluation from Models to Systems](https://arxiv.org/html/2603.08835v1) — 多Agent评测基准，定义任务完成度、协作效率、鲁棒性、可扩展性四维评测框架
6. [Agent Interoperability Protocols 2026: MCP, A2A, ACP Convergence](https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/) — Zylos Research深度分析，协议收敛趋势与生产采用数据

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)