多智能體系統正在從學界走向業界。

在 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 指導完成，團隊致力于深入挖掘多智能體系統的合作范式，提升多智能體的合作性能。