MCP / A2A 之後，誰來解決傳輸層？

瀏覽次數: 5

過去十八個月，智能體（agent）生態一口氣冒出四個協定：Anthropic 的 MCP（2024 年底）、IBM Research 的 ACP（2025 年 3 月）、Google 的 A2A（2025 年 4 月），以及一個獨立工作組推出的 ANP。表面看像是又一場協定混戰，但若你真的把規格讀過一遍會發現：它們大多不是在搶同一個位置，而是各自蓋在堆疊（stack）的不同層。

MCP 解決了「工具呼叫」——模型怎麼發現一個 server 暴露哪些函式、怎麼呼叫、怎麼解讀回傳。A2A 解決了「協調」——不同廠商做的 agent 怎麼互相發現、委派任務、追蹤一個跑很久的工作。問題是，當你把這兩層攤平來看，會發現它們腳下踩的那層——傳輸層（transport）——其實還空著。

VentureBeat 那篇文章把問題講得很白：MCP 解決了 tool calling，A2A 解決了 coordination，那誰來解決 transport？這篇文章想把這個問題拆清楚：傳輸層到底缺什麼、為什麼 HTTP 那套不夠、現在有哪些候選方案，以及對一個正在把 agent 推上生產的工程團隊，這件事該怎麼權衡。

本文大綱

先把「層」分清楚

之所以說協定多不等於混亂，是因為這四個協定的職責本來就不一樣。MCP 本質上是「model client 與 tool server 之間的一份 typed RPC 合約」，跑在 HTTP 上（本地用 stdio、遠端用 Streamable HTTP）。A2A 則是 task 導向：以 Task 為核心，支援長時間的非同步工作流、human-in-the-loop、輪詢與推播通知，傳輸用 HTTP + Server-Sent Events（SSE）+ JSON-RPC 2.0。

關鍵在於：MCP 與 A2A 在訊息層都是 RPC。它們定義的是「一次呼叫長什麼樣、回應怎麼解讀」，而不是「這些位元組怎麼可靠地、跨多方地、在不可信網路上流動」。後者才是傳輸層的工作。MCP 與 A2A 預設用 HTTP/SSE 把這件事「湊合著做了」——能動，但那是借來的水管，不是為多智能體場景設計的。

順帶一提採用度：VentureBeat 報導引述 Linux Foundation 的數字，稱到 2026 年 4 月已有「超過 1 萬個公開可用的 MCP server、每月 1.64 億次 Python SDK 下載」。這兩個數字我無法獨立向第一手來源核實，這裡明確標註為報導引述，但方向上 MCP 已是事實標準這點，業界大致沒有爭議。正因為上層協定跑得這麼快，下面那層的缺口才更刺眼。

為什麼 RPC over HTTP 不夠

把 agent 系統從「一個模型呼叫幾個工具」放大到「幾十個 agent 跨組織協作」，HTTP/SSE 這套點對點、請求／回應的模型會在幾個地方繃斷：

點對點 vs. 多對多：HTTP 連線本質是兩端綁定。一個 agent 要把狀態廣播給一群動態加入／離開的 agent，HTTP 沒有原生的「發布到一個 topic，所有訂閱者都收到」這種語意。
同步耦合 vs. 解耦：請求／回應要求發送方與接收方此刻都在線。但 agent 工作常常是長時間、非同步的——送出去的任務，接收方可能幾分鐘後才處理。沒有中介的緩衝（buffering）與重試（retry），任一端短暫離線就掉訊息。
高吞吐串流：token 串流、大量中間結果的持續流動，SSE 是單向、且建立在 HTTP 之上的變通做法，不是為高吞吐雙向串流設計的。
動態群組成員：agent 群組會不斷有人加入、退出，傳輸層最好能在不重設整個系統的前提下處理成員變動——HTTP 對此沒有概念。
跨不可信中介的安全：多組織協作時，訊息常會經過你不完全信任的中介節點。只靠傳輸層 TLS（點對點加密、到中介就解密）不夠；你要的是端對端、即使中介被攻陷也讀不到內容的加密，最好還能做到前向／後向安全（post-compromise security，當前憑證外洩也無法解密過去的通訊）與抗量子。

舉個具體場景就清楚了：假設一家銀行的「風控 agent」要把一筆可疑交易，同時通知「合規 agent」「客服 agent」與外部「徵信機構 agent」，而這幾個 agent 分屬不同團隊甚至不同公司、且隨業務上下線。用 HTTP/SSE 你得對每個對象各開一條連線、各自重試、各自處理對方不在線；訊息還可能經過雲端閘道這類你不完全掌控的中介。這正是「一對多、需要緩衝、跨信任邊界」三件事一次撞上的時刻——而它在真實 agent 系統裡會愈來愈常見，不是邊角案例。

這些需求單獨看都不新鮮——它們正是過去二十年訊息系統（messaging）在解的事。所以真正的問題不是「要不要發明新東西」，而是「既有的訊息基建，哪些能直接拿來當 agent 的傳輸層，哪些還差一截」。

把候選方案攤開比

Cisco 的四位作者（L. Muscariello、M. Papalini、M. Sardara、S. Betts）在 IETF 提交的 Internet-Draft《An Overview of Messaging Systems and Their Applicability to Agentic AI》（draft-mpsb-agntcy-messaging-00，2025 年 10 月 16 日）做的正是這件事：系統性地把六種訊息取向放在 agent 場景下評比。摘其要點：

AMQP：企業級老牌，靠 exchange／queue 做複雜路由，支援 at-least-once 甚至 exactly-once，但功能豐富帶來較高開銷。
MQTT：IoT 導向，輕量 pub/sub、三級 QoS，開銷極低；代價是原生串流與訊息級安全較弱。
NATS：雲原生設計，pub/sub、request-reply、queue group 都有；核心是 at-most-once，要更強保證得搭 JetStream。
Apache Kafka：分散式 commit log，為大規模水平擴展與原生串流而生；代價是基建複雜，且常需自己補去重邏輯。
AMQP over WebSockets：讓瀏覽器端 agent 也能參與，但比原生 AMQP 多一層開銷。
SLIM：草案作者自家、為 agent 量身打造的方案，下面單獨講。

這份草案的結論很務實：這些系統各有強項，但在 agent 場景最關鍵的兩件事——為群組通訊設計的端對端安全，以及抗量子加密——上，傳統訊息系統普遍不足。它們多半仍把安全寄託在傳輸層 TLS，而非訊息層。

SLIM：把 gRPC 當細腰，把安全塞進訊息層

SLIM（Secure Low-Latency Interactive Messaging）是 Linux Foundation 旗下 AGNTCY 專案的傳輸方案，也有對應的 IETF 草案（draft-mpsb-agntcy-slim）與開源實作（github.com/agntcy/slim）。它的設計思路可以這樣理解：

傳輸用 gRPC over HTTP/2 當「細腰」（thin waist）。 整條路徑端到端走 HTTP/2，避免沿途做訊息轉碼，並沿用既有 gRPC 部署與 Protocol Buffers 的服務定義。它提供 SRPC（streaming RPC），讓你用熟悉的 gRPC 串流語意直接跑在 SLIM 的安全訊息網上。

核心通訊模型是 pub/sub，但安全做在訊息層而非傳輸層。 SLIM 用 MLS（Messaging Layer Security）做端對端、為群組通訊設計的加密：訊息即使經過中介節點、或在中介發生 TLS 終結，內容仍保持機密。MLS 群組成員身分與 channel 身分綁定——你得在同一個 MLS 群組裡才解得開訊息——並支援抗量子加密與被攻陷後的成員撤銷。草案還提到把 MLS 憑證與證明裝進 OAuth bearer token 裡傳遞，以兼顧互通與「立即撤銷」被攻陷的 agent。

架構上分三層：資料平面的路由節點（依 metadata 轉發訊息）、session 層（管理可靠交付、MLS 群組狀態與重連）、應用端點（發布／接收加密內容）。定址用階層式的 name-based routing（以去中心化識別碼 DID 組成 channel 名稱），而不是綁死 IP 或單一連線。一條 HTTP/2 連線可多工承載多個並行 agent 對話。

把它對回前面那個銀行場景：風控 agent 對一個 channel 發布一次，合規、客服、徵信三方只要在對應的 MLS 群組裡就各自收到、各自確認；某個 agent 暫時離線，session 層負責補送；訊息過雲端閘道時，閘道看得到 metadata 卻讀不到內容。一對多、緩衝、跨信任邊界這三件事，在這個模型裡是內建語意，而不是每個工程師各自硬刻的變通。

值得一提的另一條路線是 Google 為 MCP 引入的 gRPC 傳輸：保留 MCP 的高層協定不動，只把底下的傳輸從 HTTP 換成 gRPC。這說明「協定」與「傳輸」本來就該解耦——同一份 MCP 合約，可以跑在不同的水管上。SLIM 把這個想法推得更遠：連安全模型一起換掉。

限制與該保持的清醒

把話講白：到 2026 年中，傳輸層還沒有勝出者。需要誠實標註的幾點：

SLIM 與相關訊息草案都還是 IETF Internet-Draft，不是既定標準。Internet-Draft 有效期通常半年（draft-mpsb-agntcy-messaging-00 標註 2026 年 4 月到期），會改、會被取代、也可能停在草案階段。
這條線目前由 Cisco／AGNTCY 主導，標準化是政治也是工程，最後生態會不會收斂到它，現在斷言還太早。W3C 的 AI Agent Protocol Community Group 已開了標準軌，IETF 也在收 agent transport 的草案——多方都在動，這正是「proliferation（百花齊放）」階段的特徵。
不同來源對 SLIM 是否支援 HTTP/3 說法不一（官方描述多半只提 HTTP/2），這類細節以官方 spec repo 為準。
上面那組 MCP 採用度數字（1 萬 server／1.64 億次下載）來自報導引述 Linux Foundation，未經第一手核實，請當量級參考而非精確數字。

對工程團隊：現在該怎麼做

你不需要今天就賭一個傳輸標準。但你可以把架構擺成「之後能換」的姿勢：

把協定與傳輸解耦。 不要讓業務邏輯直接假設「底下一定是 HTTP/SSE」。MCP 換 gRPC、A2A 之外再接訊息中介，這些都在發生——保留一層傳輸抽象，未來換水管才不會傷筋動骨。
按場景選水管，別過度工程。 單機、低併發、請求／回應就夠的，HTTP/SSE 完全沒問題，別硬上 Kafka。需要解耦、緩衝、重試、多對多扇出時，Kafka／NATS 是成熟答案。要跨組織、訊息會過不可信中介、且需要群組層級的端對端與抗量子加密時，SLIM 是目前最對症的候選——但要接受它還在草案。
安全要往訊息層想，別只靠 TLS。 多智能體、多組織是趨勢，「中介可信」這個假設遲早會破。即使現在還不上 MLS，也先把「端對端加密」當成設計目標，而不是事後補丁。
盯住標準軌，但別被路線圖綁架。 IETF / W3C 的進展值得追，但在塵埃落定前，可移植性（portability）比押對寶更重要。

歷史會重演：分散式運算每一次都從協定百花齊放走向收斂（想想 CORBA、DCOM、SOAP 最後讓位給 REST）。agent 的傳輸層現在正站在那個百花齊放的起點。誰會贏還不知道，但問題已經被正確地提出來了——而把問題提對，往往就是收斂的開始。