Agent通讯的「运营商」哪家强？UIUC团队发布ProtocolBench

多智能体系统正在从学界走向业界。

在 Coding、Research 等真实场景里，越来越多系统不再只依赖单个 agent，而是由多个 Agent 分工协作：有人负责规划，有人负责检索，有人调用工具，有人汇总答案。

Agent 的智能化程度越来越高，Agent 网络的规模也越来越大。Agent 从最开始的在本地部署，“面对面” 的协作，逐渐变成了在局域网乃至互联网中进行的 “线上” 合作。当 agent 数量变多，越来越多的 agent 在线部署时，本地直连的通信方式将越来越局限。像互联网的 https 协议一样，agent 也需要有自己的网络通信协议。

Agent 通信协议，

用什么好？

在过去的多智能体研究中，人们更关心 agent 会不会规划、会不会调用工具、能不能协作完成任务。通信协议往往被当作底层工程细节：系统能跑起来就行。

但当多智能体系统进入更接近生产的环境后，协议层会直接影响很多关键指标。

比如，一个协议的消息封装是否足够轻，会影响多跳协作的开销；是否支持稳定的流式响应，会影响高吞吐服务的延迟；是否依赖长连接和复杂会话状态，会影响故障恢复；是否原生支持身份认证、端到端加密和元数据保护，则会影响安全边界。

也就是说，协议不是简单的「数据传输方式」，而是在塑造整个多智能体系统的性能、可靠性和安全性。

MCP 让 agent 连上了在线工具，而 A2A、ACP、ANP、Agora 等多智能体通信协议则在尝试让 agent 连上其他在线 agent。它们各有各的侧重点，有的强调企业级 agent 协作，有的强调跨系统集成，有的强调身份与端到端安全，有的强调去中心化工作流。但在真实系统里，具体选择哪一种协议，长期以来更多依赖工程经验，而不是系统的评测和研究。

关于协议的一系列问题也随之而来：智能体之间到底该怎么通信？什么样的通信协议才算一个好的协议？一个网络中的所有 agent 是否必须使用同一种通信协议？有没有万能的通信协议？

为了填补这一空白，来自 University of Illinois Urbana–Champaign 的研究者提出 ProtocolBench，首次系统比较了四类多智能体通信协议的优劣区间，并进一步提出 ProtocolRouter，让系统能够根据任务场景、约束条件和运行信号自动选择合适协议。

• 论文标题：Which LLM Multi-Agent Protocol to Choose?（大语言模型多智能体协议该怎么选？）
• 论文链接：https://arxiv.org/abs/2510.17149
• 代码仓库：https://github.com/ulab-uiuc/AgentProtocols
• 作者：Hongyi Du、Jiaqi Su、Jisen Li、Lijie Ding、Yingxuan Yang、Peixuan Han、Xiangru Tang、Kunlun Zhu、Jiaxuan You
• 单位：University of Illinois Urbana–Champaign

该成果近日被机器学习顶级会议 ICML 2026 正式接收。

ProtocolBench 测试框架：把协议单独拎出来

ProtocolBench 的设计思路很直接：尽量固定所有非协议因素，只替换通信边界上的协议实现。

具体来说，实验会固定模型、prompt、硬件环境、容器镜像、工作负载、rate limit 和 agent 拓扑。每个场景里的 agent workflow 只实现一次，然后在 A2A、ACP、ANP、Agora 之间切换通信协议。

这样做的目的，是尽量避免把模型能力差异，prompt 差异，工具实现差异误认为是协议差异。

ProtocolBench 主要评估四个维度：

为了覆盖不同类型的通信压力，论文设计了四个场景：GAIA Document QA、Safety Tech、Streaming Queue、Fail-Storm Recovery。

这四个场景对应的测试指标各不相同。

GAIA Document QA 更像 planner 驱动的多跳协作任务。一个 planner 会创建多个有不同角色和工具的 agent，让它们共同抽取、总结、判断证据，并最终回答文档中心的问题。

Safety Tech 被设计成医疗问答场景，包括注册网关、协调器和两个 LLM doctor。系统会被注入 TLS 降级、弱加密套件、证书异常、重放攻击、隧道嗅探、会话劫持等 probe，用来测试协议栈的安全能力。

Streaming Queue 则更接近高吞吐 API 服务。一个 coordinator 和四个 worker 需要处理 1000 条 MS MARCO 数据，重点评估平均延迟、总耗时、方差和成功率。

Fail-Storm Recovery 关注故障恢复。系统由 8 个 agent 构成 Shard-QA 环形网络，每 120 秒杀掉其中 3 个 agent，随后让它们重新加入，观察通信链路能否恢复。

ProtocolBench 评测结果：

各有优劣，无人通吃

在 ProtocolBench 中测试的四种协议，定位各不相同。

A2A 更强调结构化的 agent-to-agent 协作，适合企业级任务编排和大规模 mission-critical 场景。ACP 更偏向 REST /async 风格的跨框架集成，适合将不同服务包装成可交互的 agent endpoint。ANP 更强调身份、安全路由和端到端通信，更适合跨边界、隐私敏感的任务。Agora 则更偏向去中心化 workflow 和 P2P 网络，适合动态网络和异构 routine 协商。

ProtocolBench 的实验结果显示，协议选择会显著影响系统行为，但不存在一个在所有场景里都最优的协议。

A2A：更适合层级协作和故障恢复

在 GAIA Document QA 中，A2A 的任务效用最高：Quality avg 达到 2.51，Success avg 达到 9.29。相比之下，ACP 的 Quality avg 为 2.27、Success avg 为 5.25；ANP 为 2.14 和 7.28；Agora 为 2.33 和 6.27。

这说明在层级化、planner 驱动、多跳协作的任务里，A2A 的轻量 HTTP + JSON-RPC envelope、agent card 机制和 turn-based 协作方式更容易匹配 agent 工作流。

在 Fail-Storm Recovery 中，A2A 也表现最好。它在故障前的 answer discovery 为 14.74，故障后仍有 14.57，保留比例约为 98.85%。

这类场景考验的是节点挂掉、重启、重新加入网络时，协议能不能快速恢复通信。A2A 的优势在于传输层相对无状态，节点重启后只要重新暴露 endpoint，就能比较快地恢复通信。

ACP：更适合高吞吐、低延迟服务

Streaming Queue 场景下，ACP 的平均端到端延迟最低，为 9.66 秒，总耗时为 40.28 分钟，标准差也最小。

A2A 的表现非常接近，平均延迟为 9.70 秒，总耗时 40.45 分钟；但 ANP 和 Agora 的延迟开销更高，平均延迟分别为 11.36 秒和 13.14 秒。

这说明在高吞吐、浅层 request-response 服务里，ACP 这类 REST / SSE 风格协议可以减少每次请求的协商成本，也更方便 coordinator 将请求分发给多个 worker。

对实际系统来说，这类差异并不只是论文表格里的数字。ProtocolBench 中，Streaming Queue 的整体完成时间在不同协议之间最多相差 36.5%。当系统每天处理大量请求时，协议层开销会被持续放大。

ANP / Agora：更适合安全和跨边界通信

Safety Tech 场景给出了另一种结论。

在 TLS transport、session hijack protection、E2E encryption、tunnel sniffing resistance、metadata leakage prevention 五个维度上，ANP 和 Agora 在实验中都覆盖了全部能力。

相比之下，A2A 和 ACP 在部分安全维度上需要额外安全层补足。也就是说，如果系统运行在隐私敏感、跨组织、跨安全边界的场景里，安全能力可能比平均延迟更重要。

这也是多智能体协议选择最现实的地方：更轻的协议通常更快，但更强的身份和隐私机制往往会带来额外开销。选择协议，本质上是在任务成功率、延迟、恢复能力和安全边界之间做取舍。

这也解释了为什么论文并没有把四种协议做成一个简单排行榜。它们服务的是不同系统目标：有的追求轻量协作，有的追求低延迟服务，有的追求安全边界，有的追求去中心化适配。

真正的问题不是哪个协议最好，而是在某个具体场景下该用哪个协议。

ProtocolRouter：既然没有万能协议，

那就让系统自己选

既然没有一个协议能通吃所有场景，论文进一步提出 ProtocolRouter。

ProtocolRouter 并不是一个新通信协议，而是一个约束感知的协议路由器。它会根据场景描述、模块需求、协议能力表和可选的运行时信号，为整个场景或每个模块选择协议。

它遵循一个核心原则：先满足硬约束，再做性能优化。

举例来说，如果某个模块明确要求端到端加密，那么不满足安全约束的协议会先被过滤掉；如果多个协议都满足硬约束，ProtocolRouter 再根据 streaming、request-response、恢复能力、历史性能先验等因素进行选择。

ProtocolRouter 的输出可以是单协议，也可以是 per-module 的异构协议组合。例如：

需要注意的是，ProtocolRouter 不会改变应用语义，也不会让一个更轻的下游协议自动继承上游更强的安全保证。

当两个 endpoint 使用不同协议时，系统会通过 adapter 做无状态的 encode /decode 映射，也就是把一种 wire format 转成另一种 wire format。这个过程只做 envelope 和字段级映射，不改变业务内容。如果跨越安全域，最终安全保证仍取决于两端协议和 bridge 实际执行的能力。

这让 ProtocolRouter 更像一个低频 planner：它帮助系统在部署或场景切换时做协议选择，而不是在每条消息上随意改协议。

ProtocolRouterBench：

Router 本身也要被评估

为了评估 ProtocolRouter 会不会选协议，论文还提出 ProtocolRouterBench。

ProtocolRouterBench 包含 60 个测试场景、180 个通信模块，并按照 L1 到 L5 分为五个难度等级。难度越高，每个场景里的独立通信模块越多。

评估设置分成两种：

• Spec-only：只基于协议能力表做选择。
• Spec+Perf：先满足硬约束，再加入 ProtocolBench 中的性能先验用于打破平局。

结果显示，Spec-only 模式下，ProtocolRouter 的场景准确率为 53.5%，模块准确率为 71.2%；加入性能先验后，场景准确率提升到 63.3%，模块准确率提升到 81.7%，macro-F1 从 0.721 提升到 0.824。

这组结果说明，协议选择不只依赖协议说明书，也依赖实际 benchmark 中观察到的性能信号。尤其在 L4、L5 这类更复杂场景中，性能先验能帮助 Router 更好地区分 A2A 和 ACP 等容易混淆的协议。

Router 回网，集各家之长

论文进一步把 ProtocolRouter 放回真实 ProtocolBench 场景中做端到端验证。Router 可以在不同的模块间选择最适合的通信协议，也可以在一个网络中对不同的 agent 选择不同的协议，把各家之长统一到一张网中。

结果显示，ProtocolRouter 在多个目标指标上超过了对应场景的最佳单协议 baseline：

其中，Fail-Storm 的恢复时间从 8.00 秒降到 6.55 秒，提升幅度达到 18.1%；GAIA 的成功平均值从 9.29 提升到 9.90。

但论文也强调，这并不意味着 ProtocolRouter 在所有指标上都优于最佳单协议。更准确的说法是：在明确约束下，受控的 per-scenario 或 per-module 协议组合是有价值的。

换句话说，ProtocolRouter 证明的是「按场景选择协议」这件事本身值得做，而不是证明某个路由器已经可以在所有系统里自动取得最优解。

结语：多智能体系统的下一层竞争，

可能在协议层

随着 LLM agent 从研究原型走向生产系统，多智能体协作不再只是 prompt 和工具调用的问题。

当多个 agent 需要长期通信、分工协作、共享状态、处理失败、跨越安全边界时，通信协议就会成为系统性能和可靠性的关键层。

ProtocolBench 的价值在于，它把过去靠工程直觉判断的协议选择问题，变成了可以评测、比较和复现的系统问题。ProtocolRouter 的价值则在于，它进一步把「选哪个协议」变成了一个可以被约束、被路由、被验证的决策过程。

这篇论文给多智能体系统工程化提供了一个很实用的提醒：不要把协议当成透明管道。协议会影响系统能不能跑得快、能不能恢复、能不能保护隐私，也会影响多智能体协作能走多远。

当 agent 系统变得越来越复杂，真正重要的问题可能不再是「哪个协议最强」，而是：系统是否知道自己在什么场景下，需要什么样的通信能力。

作者团队介绍

本文第一作者为伊利诺伊大学厄巴纳–香槟分校本科生 Hongyi Du, 主要研究方向为多智能体系统，自进化智能体和智能体相关的测试基准。研究由 Jiaxuan You 教授和 UIUC 的 CS Phd Kunlun Zhu 指导完成，团队致力于深入挖掘多智能体系统的合作范式，提升多智能体的合作性能。