每一段都上鎖，不等於一路都上鎖：AGNTCY 的 SLIM 什麼時候值得用

你的 agent 用 MCP 呼叫了另一家公司的工具，那段對話在路上經過了誰的機器？

直覺的回答是：有 TLS 啊。這答案沒錯，只是回答了另一個問題。TLS 管的是「這一段線路」。訊息從你的 agent 出發、抵達對方的 agent 之前，如果中間隔著一個訊息代理、一個雲端路由、一個第三方閘道，每一段各自上鎖，每個停靠點卻都會把它解開，看一眼要往哪送，再鎖上送出去。

MCP 和 A2A 規定的是 agent 之間說什麼。這些話經過中繼時，中繼拿不拿得到明文，要看底下那層傳輸怎麼做。

SLIM 想補的就是這一格。全名 Secure Low-Latency Interactive Messaging，規格作者都來自 Cisco，現在放在 Linux Foundation 旗下的 AGNTCY 專案裡。送進 IETF 的草案 draft-mpsb-agntcy-slim-02，摘要是這樣開頭的：

“This document specifies the Secure Low-Latency Interactive Messaging (SLIM), a protocol designed to support real-time interactive AI applications at scale. SLIM provides the transport layer for agent protocols (for example, A2A and MCP), combining gRPC over HTTP/2 and HTTP/3 with secure messaging, group communication, and native RPC semantics.”

它設計得漂不漂亮可以慢慢評。比較實際的問題是：你用不用得到。

車上有鎖，轉運站照樣拆箱

拿寄貨來比。貨運公司每台車都上了鎖，路上沒人偷得走。可是貨到了轉運站，得開箱看標籤、分揀、再裝上下一台車。TLS 是車上的鎖。

端到端加密是箱子本身上鎖，鑰匙只在寄件人跟收件人手上。轉運站看得到箱子外面貼的地址，打不開箱子。

SLIM 用來鎖箱子的是 MLS（Message Layer Security）。這是 IETF 已經標準化的協定，編號 RFC 9420，SLIM 在自己的 session layer 裡使用它，沒有另外發明加密演算法。官方文件站的說法是：

“MLS (RFC 9420) encrypts data at the session layer — even a compromised routing node cannot read message content”

就算路由節點被入侵，也讀不到內容。整個協定最值錢的就是這一句。

同一批作者另外寫了一份姊妹草案 draft-mpsb-agntcy-messaging-02，專門論證為什麼要做新協定。它拿 AMQP、MQTT、NATS、Kafka，還有跑在 WebSocket 上的 AMQP 來比，看的是串流效能、傳遞保證、安全模型、維運複雜度四件事，點出的共同弱點是：這些系統主要靠傳輸層加密，訊息本身沒有內建端到端加密。文件接著給了 agent 需要不一樣東西的理由，我換成自己的話講。第一，agent 可能一跑就很久，要防的不只是金鑰被偷的那一刻，還有被偷之後的事（post-compromise security）。第二，agent 常常跨組織、跨安全域工作。第三，agent 群組的成員進進出出很頻繁。

三個理由裡，第二個最能拿來做判斷。

中間沒有停靠站，TLS 就夠了

如果你的兩個 agent 直接連線，中間沒有任何代理或路由，那條 TLS 連線的兩端就是這兩個 agent 本身。這種情況下 TLS 已經是端到端，SLIM 最值錢的那一句對你沒有增加任何東西。

如果中間有停靠站，但停靠站是你自己的，例如同一個 Kubernetes 叢集、同一家公司維運的 broker，那「路由節點被入侵也讀不到」的邊際價值就很小。你的 broker 真被打穿了，要擔心的通常不只訊息內容。為了這點邊際價值，你要多扛一套 MLS 群組金鑰管理，外加一組新的元件。在同一個信任域裡，我不會導入 SLIM。

真正輪到它上場的，是訊息得經過一台你跟對方都不擁有的機器。A 公司的 agent 要跟 B 公司的 agent 談事情，中間走的是雲端供應商或某個第三方的路由。這時候逐段 TLS 的意思就是：那台中繼機器，按照設計就拿得到明文。姊妹草案說的「跨組織、跨安全域」，我讀來就是這個位置。

第三個理由是加分題。兩方固定對談，群組金鑰不太會換；一個頻道裡的 agent 今天加三個、明天走兩個，MLS 本來就是為群組成員變動時更新金鑰而設計的，姊妹草案也把成員動態變更時仍維持安全特性，列為 SLIM 的主張之一。成員變動越頻繁，自己用 TLS 硬湊出同等效果就越痛。

路由節點還是得讀一樣東西

讀 GitHub README 的架構段落時，有一行讓我停下來。它把 SLIM 拆成三層，最底下那層是這樣寫的：

“Data Plane: Pure message routing layer that forwards packets based on hierarchical names without inspecting application content”

不檢查應用內容，這點跟前面對得上。可是它依照「階層式名稱」轉送封包，要照名字轉送，路由節點就得讀得到名字。這是我從架構描述推出來的，我讀過的文件裡沒有一段講清楚路由節點到底看得到哪些中繼資料。

所以要把話講準一點：SLIM 宣稱的是中繼讀不到你們講了什麼。「中繼知不知道誰在跟誰講話」，我讀過的文件裡沒有這樣的宣稱。如果你的威脅模型連「對方知道我們在跟哪家公司談」都算在內，別指望 SLIM 替你處理，至少文件沒有這樣承諾。

另外兩層是 Session Layer（”Handles reliable delivery, end-to-end MLS encryption, and group membership management”）和 Control Plane（”Manages configuration, monitoring, and orchestration of SLIM routing nodes”）。README 講這個分層的好處是：路由節點只要跑輕量的 data plane，完整的 stack 掛在應用端，用各語言的 binding 接上去。

兩份官方文件，講的不是同一套話

我想把 README 的三層跟官方文件站的說法對起來，結果只對得上一半。

文件站的 Controller，描述是 “manages route tables, node registration, and group membership across clusters”，跟 README 的 Control Plane 很接近。Channel Manager 是另外單獨列出來的，一個由營運方管理、用來建立與管理群組頻道的服務，README 沒有把它拉成獨立一層。兩套分法怎麼對應，我手上的文件沒有一份交代，我也不打算替它們硬湊成一套。

HTTP/3 那一格更實際。草案寫支援，文件站只講 HTTP/2。是版本新舊落差，還是文件還沒同步，我手上的資料沒有答案。如果你的網路環境剛好需要 HTTP/3，別拿任何一份文件當依據，拿你要裝的那個版本實際確認。

什麼時候它反而拖累你

第一個卡點是規格本身。draft-mpsb-agntcy-slim-02 是 IETF 的 individual submission，還沒進任何工作小組的正式軌道。它 2026 年 7 月 7 日發布、7 月 18 日最後更新。四位作者 Luca Muscariello、Michele Papalini、Mauro Sardara、Sam Betts 都掛 Cisco，作者欄上沒有其他公司的名字。個人草案在 IETF 裡什麼背書都還不算，它可能改名、可能被合併、也可能就停在這裡。

第二個卡點在維運。SLIM 不是一個套件，是好幾個會分別長大的構件。SLIM Node（也就是 data plane）可以用 Docker、Cargo 或 Helm 裝；Control Plane 用 Docker 或 Helm；命令列工具 slimctl 從 GitHub releases 下載；語言 binding 走各自的套件管理器，Python 就是 pip。2026 年 9 月 17 日那一輪發版，slimctl-v2.3.3、slim-version-v2.3.3、slim-v2.3.3 三個標籤同一天出現。版號目前同步，但它們在 repo 裡是各自獨立的發版單位，你升級時要盯的是三個東西。

核心用 Rust 寫，README 直接寫 “SLIM is implemented in Rust. Install with rustup”，建置用 Taskfile。照這個分工推，只用 binding 的話應該碰不太到 Rust，要改核心或追問題就躲不掉。

語言也是一道門檻。binding 放在另一個 repo agntcy/slim-bindings，支援 Python、Go、Dotnet、Java、Kotlin 五種。你的 agent 如果是用這五種以外的語言寫的，這份名單上沒有你。協定整合那邊，README 列的是 agntcy/slim-a2a-python、agntcy/slim-mcp-python、agntcy/slim-otel 三個 repo，A2A 跟 MCP 兩個的名字後面都帶著 -python。

這幾條我都是讀文件得來的。我沒有實際架過 SLIM node，也沒量過任何延遲，所以說不出它比直接走 gRPC 慢多少，也說不出幾十個成員的群組換一輪金鑰要花多久。名字裡那個 Low-Latency 我沒辦法替它背書。

寫規格的、掛名的、在用的，不是同一份名單

SLIM 周邊掛著好幾份公司名單，疊在一起讀，很像一大票公司都在用它。拆開來是這樣：

我最在意的就是空著的最後一列。Google Cloud 出現在 AGNTCY 的創始會員裡，不代表 Google Cloud 在跑 SLIM。

還有一個容易搞混的名字。Linux Foundation 在 2025 年 12 月 9 日另外成立了 Agentic AI Foundation（AAIF），錨定的是 OpenAI 的 AGENTS.md、Anthropic 的 Model Context Protocol 和 goose 等專案。它跟 AGNTCY 是 Linux Foundation 底下兩個不同的組織。SLIM 說自己能承載 MCP 的流量，MCP 現在錨定在 AAIF 底下。兩邊之間有沒有正式合作，我讀到的資料都沒寫。

AGNTCY 底下另一個子專案 OASF 負責描述 agent 會做什麼，這個站之前寫過一篇。SLIM 管的是另一層：那些描述跟對話，要怎麼送到對方手上。

專案本身倒是看得出有人在認真維護。依 GitHub API 在 2026 年 9 月 27 日的資料，agntcy/slim 採 Apache-2.0 授權，2025 年 2 月 5 日建立，220 顆星、49 個 fork、25 個 open issue，最後一次 push 在 9 月 26 日。README 上掛著 OpenSSF Scorecard、OpenSSF Best Practices、CI 和 Codecov 的徽章。這些數字說明它活著，不能說明誰在生產環境用它。

我的選擇

會讓我改變看法的條件有三個：這份草案被 IETF 某個工作小組採納，作者欄出現 Cisco 以外的名字，或是有人公開說自己在生產環境跑 SLIM。三個之中出現任何一個，我會把它從觀望名單移到認真評估。

在那之前，我的建議很窄。agent 訊息不經過任何你不擁有的中繼，就別導入 SLIM，TLS 已經替你做完它要做的事。會經過，而且那台中繼既不是你的也不是對方的，SLIM 把「中繼讀不到內容」寫進了協定層，還送進 IETF 走流程，值得拉一條不影響營運的跨組織流量去試。主要流量，等那份草案走出個人提案再說。