agent 通訊機制哪些還活著：怎麼逐一驗
幾個月前我在《多 Agent 協作架構：怎麼讓 4 個 AI 不打架》裡，把 agent 之間的傳話管線寫成會自己長出協作的漂亮機制。這篇要逐一驗我宣稱的兩套通訊到底通不通：檔案 relay 那套是真的還在流，另一套 gateway IPC 的 port 18789 早就 0 連線，卻還好端端寫在活的設定檔和一整排備份裡，看起來跟活的一樣可信。
《Agentic Design Patterns》第 15 章講代理間通訊（Inter-Agent Communication，A2A）。核心一句話：多 agent 系統的價值，不在於各自多聰明，而在於它們之間傳的訊息真的送得到。通道斷了，一群 agent 就退化成一群各說各話的獨立腳本。
我們讀完，很篤定：這塊我們有兩套。一套是檔案 relay，agent 發完文把摘要丟進佇列，其他 agent 下次醒來讀走。一套是 gateway IPC，跑在本機 port 18789，讓艦隊透過同一個 gateway 互相路由。兩套通道，A2A 實作完成。然後我們對自己做了一次對抗式稽核。這一章的真相是：兩套裡有一套，早就 0 連線了。
一套還在流，一套是死管子
先看檔案 relay。翻它的佇列檔 relay-queue.json，裡面是活的：mindthread 把「6,500 追蹤、零手動發文」的互動數丟給 main 當案例素材，probe 把「90% 的 LLM 應用有漏洞」的發現丟給 main 接商業角度，advisor 把理財貼文丟過去要業務視角。最新一筆的 consumedAt 是昨天，四個 agent（main、mindthread、probe、advisor）確實在互相接棒。這套是真的。
再看 gateway IPC。稽核一查，port 18789 沒有任何程序在 listen，established 連線數是 0。原因不難懂：遷移到 OpenRouter 之後，每支腳本都直接呼叫 OpenRouter，沒有一條路由再經過那個本機 gateway。那條 bus 上一次載過訊息，是遷移之前的事。
最刺眼的不是它死了，是它死了還被到處宣稱。port: 18789 現在還好端端寫在活的 openclaw.json 的 gateway 區塊，allowedOrigins 還列著 http://localhost:18789。往備份看更慘，一整排 openclaw.json.bak.* 每一份都複讀著同一個 18789。任何人打開設定檔，或任何 agent 讀進這段 context，都會理所當然地以為艦隊有一條 IPC 匯流排在跑。真相是那是一根 0 連線的死管子。你宣稱的通訊機制，有一半是死的，而且死得無聲無息。
先花幾分鐘把你宣稱的通道逐一驗活
01 把架構圖上每個 port，逐一問「還有人在聽嗎」 你在文件或口頭上宣稱的每一條 IPC / gateway 通道，攤開來一條一條驗。listen 沒了、established 是 0，這條就是死的，不管設定檔寫得多完整。
# 有沒有程序在這個 port listen（沒輸出 = 沒人聽）
ss -ltnp | grep 18789
# 這個 port 上的已建立連線數（0 = 沒人在用）
ss -tnp | grep -c 18789
# 沒有 ss 就用 netstat：netstat -ltnp | grep 18789
紅旗：你在架構裡點名的通訊 port，ss 一查沒人 listen、established 是 0，而你上一次「確認它活著」已經想不起來是哪天。
02 relay 檔存在，不等於 relay 還在流 佇列檔還躺在那裡，只證明它曾經被建立，不證明今天還有東西進出。看最後一次被消費是什麼時候、有沒有一堆項目卡著沒人取。
# 最後一次被消費的時間，該是新鮮的
jq -r 'map(select(.consumed))|max_by(.consumedAt)|.consumedAt' relay-queue.json
# 還沒被消費、堆積中的項目數
jq '[.[]|select(.consumed==false)]|length' relay-queue.json
紅旗：檔在，但最後一筆 consumedAt 是好幾天前；或未消費的項目一直堆積、從沒被讀走。relay 名義上在，實際上斷流了。
03 遷移或改架構後，死掉的機制有沒有從設定和宣稱裡清乾淨 一條通道退役，不是關掉就結束。它的名字和 port 會賴在設定檔、文件、備份裡，讓你日後一次次口頭宣稱一個早就沒人連的機制。撈出來看它還散在幾個地方。
# 死掉的 port 還留在活的設定檔裡嗎（排除備份）
grep -rn 18789 ~/.openclaw --include='*.json' | grep -v '\.bak'
# 幾份備份還在複讀它
grep -rl 18789 ~/.openclaw/*.bak* | wc -l
紅旗：一個已經 0 連線的機制，還寫在活設定檔的 gateway.port，還在一整排 .bak 裡回音。設定檔說它在，現實說它死了，兩邊對不上。
我們稽核翻出來的
兩套通道，一套經得起驗，一套經不起。檔案 relay 有 relay-queue.json 的真實時間戳背書，四個 agent 昨天還在接棒。gateway IPC 只剩設定檔裡的一個數字，port 18789 沒人 listen、0 連線，遷移到 OpenRouter 之後就沒再載過一則訊息。它不是壞了，是整條路由被繞過之後沒人回頭把它從宣稱裡刪掉。
值得講清楚它「不是」什麼：不是 relay 也跟著死、不是 agent 之間完全不通訊。真相更微妙也更常見，宣稱的兩套裡一套真、一套假，而假的那套因為還印在設定檔上，看起來跟真的一樣可信。多 agent 系統最容易騙過自己的地方就在這裡：通道的「宣稱」和通道的「連線數」是兩回事，你以為在講一個活的匯流排，其實在講一根三個月沒人連的管子。
代理間通訊體檢清單
對你自己的多 agent 系統跑一遍：
- 你宣稱的每一條 A2A 通道，都能一條一條講出「它今天怎麼驗活」嗎
- 每個 IPC / gateway port，ss 查得到有人 listen 嗎，established 連線是幾
- relay / 佇列檔的最後一次
consumedAt是新鮮的嗎，還是斷流好幾天了 - 遷移或改架構後退役的舊通道，有沒有從活設定檔裡刪掉
- 那個死掉的機制的名字 / port，還散在幾份文件和備份裡等著被你再次宣稱
- 你答得出每條通道「上一次真的傳過訊息」是什麼時候嗎
這一章的四句話
- 多 agent 的價值在通道，不在數量。宣稱有幾套通訊，先驗每一套今天還通不通。
- 通道的「宣稱」和「連線數」是兩回事。設定檔寫著 port，不代表有人在那個 port 上聽。
- relay 檔存在不等於 relay 在流。看最後一次
consumedAt，斷流好幾天的佇列跟死了沒兩樣。 - 退役一條通道，要連同設定、文件、口頭宣稱一起清掉。不然你會一直宣稱一個 0 連線的死機制，而它看起來跟活的一樣可信。
原始碼位置：~/.openclaw/scripts/team-context.sh（把 relay 注入 prompt）、content-relay.sh（relay 的 add/get/consume/clean），佇列落在 ~/.openclaw/data/relay-queue.json（四 agent，最後消費 2026-07-05）；已廢的 gateway IPC port 18789 仍寫在 ~/.openclaw/openclaw.json 的 gateway 區塊與一整排 openclaw.json.bak.*，實測 0 連線。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。