多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并非零和博弈，而是分属协议栈的不同层级。这一分层模型正在被业界快速接受。

这个分层模型的核心逻辑是：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 代码示例

# 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关键差异

3.3 代码示例

# 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）是该方向的代表性工作。其核心结构：

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 消息传递：实测对比

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

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

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 六模式深度对比

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）。

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

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

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）

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

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

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

9.1 变现潜力矩阵

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 — arxiv综述论文，提出协议分层模型与分阶段采用路线图
2. Agent2Agent (A2A) Protocol Official Documentation — Google A2A协议官方文档，定义Agent Card、Task生命周期等核心概念
3. Multi-Agent Memory from a Computer Architecture Perspective — arxiv论文，提出三层内存层次模型，映射多Agent内存挑战到计算机体系结构
4. Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture — 中科院LbMAS论文，将黑板架构引入LLM多Agent系统
5. MASEval: Extending Multi-Agent Evaluation from Models to Systems — 多Agent评测基准，定义任务完成度、协作效率、鲁棒性、可扩展性四维评测框架
6. Agent Interoperability Protocols 2026: 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 等场景全覆盖。