多 agent 協作的真實規模和成本怎麼查
幾個月前我在《多 Agent 協作架構：怎麼讓 4 個 AI 不打架》裡，把整套六層協作機制寫成一群 agent 分工無間、自己接力的成功案例。這篇要回頭數清楚：對外我把它膨脹成六個 agent 並行，稽核一數真正活著的只有四個，而且今天我為了省錢，把那條傳話管線唯一會來收件的 agent 親手關掉了。
《Agentic Design Patterns》第 7 章講多代理協作。核心一句話：複雜的工作不該塞給一個全能 agent，而是拆給多個各有專職的 agent，讓它們互相傳遞成果、彼此接力。
我們讀完，很得意。我們有一整套：安全、內容、社群、財務四個角色各自發文，中間還鋪了一條內容傳話管線，A 發完文把線索丟給 B，B 醒來時就接得到。多代理協作，實作完成。然後我們對自己做了一次對抗式稽核。這一章的真相有三層，一層比一層難堪。
管線是真的，數字是灌水的，收件人今天被我們關了
先講好的：那條傳話管線不是擺設。relay-queue.json 裡躺著六筆訊息，安全 agent 發完「90% 的 LLM 應用有漏洞」就丟一筆給主 agent 提醒它接商業角度，財務 agent 發完就丟一筆策略線索。最後一筆被消費的時間是昨天中午 12:03。今天回頭看，這條管線確實還在流。
再講難堪的：我們對外講「六品牌 agent 並行」，稽核一數，真正活著的只有四個（安全、內容、社群、財務）。profile 目錄裡確實有六個資料夾，但其中兩個的最後修改時間停在三週前，是遷移後沒清掉的空殼。有趣的是，傳話管線自己的程式碼從頭到尾寫的都是 4-agent fleet。程式很誠實，是我們嘴上把四個講成了六個。
最狠的一層在今天。那六筆訊息，每一筆的收件人都是同一個：主 agent。而主 agent 的 gateway 一週燒 $17（這是第 16 章那筆帳的主角），今天我們為了省錢直接把它關了。於是管線還在，發件端還在往裡塞，但唯一會來收件的那個 agent，被我們自己親手關掉了。多代理協作最貴的部分，從來不是傳話，是養那些會回話的嘴。
先花幾分鐘查你自己的多 agent 協作
01 查實際幾個 agent 活著，對比你宣稱的 翻你放 agent 設定的目錄，看每個的最後修改時間。冷掉的那些，就是遷移或改版後沒清、你卻還算在並行數裡的空殼。
# 列出所有 agent profile，冷掉的（mtime 停在很久以前）就是空殼
ls -lt ~/hermes-bench/data/profiles/
# 或數真正還 active 的 gateway，別數設定檔
systemctl --user list-units --state=active | grep -i gateway
紅旗：目錄裡有六個 agent，但一半的修改時間停在幾週前。你宣稱的並行度，有一半是死的。
02 查 agent 間的傳話通道今天還在動嗎，還有誰在收 傳話管線最容易變成單向的死信箱：發件端還勤奮地塞，收件端早就沒人讀。看它最後一次被消費是什麼時候，再看所有訊息都流向誰。
# 傳話隊列最後一次被「消費」是什麼時候，不是最後被寫入
jq -r 'map(.consumedAt)|sort|last' ~/.openclaw/data/relay-queue.json
# 所有訊息都寄給誰？全塞給同一個 agent = 那個一關，整條線就斷
jq -r '.[].to' ~/.openclaw/data/relay-queue.json | sort | uniq -c
紅旗：通道還在動，但所有訊息都流向同一個收件人，而那個收件人正好是你最貴、最想關的 agent。你以為是網狀協作，其實是一個中心點在硬撐。
03 查每個 agent 花的比產出多嗎，該關就關 這一格直接呼應第 16 章。把每個 agent 這週燒的錢，跟它真正產出的東西擺一起。協作聽起來很美，但每多一個會回話的 agent，就多一份帳單。
# 對照每個 agent 這週的花費（從成本 log 分組加總）
grep '"agent"' ~/.openclaw/logs/llm-cost.log | jq -sr 'group_by(.agent)[]|"\(.[0].agent) $\(map(.cost)|add)"'
# 再看那個燒最兇的 gateway，它的產出配得上嗎
systemctl --user status hermes-gateway.service | grep Active
紅旗：有個 agent 一週燒的錢遠超它產出的價值，而你留著它，只因為架構圖上它是個節點。
我們今天實際怎麼做
沒有調參數，就是把主 agent 的 gateway 停掉、mask 起來。它一週 $17，產出裡幾乎全是一遍遍重讀對話歷史，配不上這個價。傳話管線我們沒動，讓它繼續躺著：一個安靜的 JSON 檔幾乎不花錢，等哪天真的需要一個中心 agent 來收斂，再把它打開。留著發件端、關掉最貴的收件端，這不是把協作做壞，是承認四個 agent 裡有一個現在不值得開著回話。多代理協作到最後，跟資源感知是同一件事：無情修剪。
多 agent 協作體檢清單
對你自己的系統跑一遍：
- 你設定裡的 agent 數，跟真正還在動的一致嗎，還是混了遷移後的空殼
- 對外講的並行度，跟程式碼裡寫的 agent 數對得上嗎
- agent 間的傳話通道，最後一次被消費是什麼時候，還是早變單向死信箱
- 所有訊息是不是都流向同一個中心 agent，那個一關整條線就斷
- 每個 agent 這週燒的錢，配得上它的產出嗎
- 有沒有一個只因為在架構圖上是節點、就被留著的貴 agent
這一章的四句話
- 傳話管線是真的，不代表協作是真的。要數真正活著、且真的在收件的 agent，別數架構圖上的節點。
- 對外的並行度會膨脹。程式碼寫四個，嘴上就別講六個，稽核一數就穿幫。
- 網狀協作常常是假的，底下是一個中心 agent 在硬撐。那個中心一關，整條線就斷。
- 多代理協作最貴的不是傳話，是養會回話的嘴。花的比產出多的 agent，關掉不丟臉，那才是協作該有的紀律。
原始碼位置：~/.openclaw/scripts/team-context.sh（把隊友線索注入發文 prompt，程式裡寫死 4-agent fleet）、content-relay.sh（跨 agent 傳話管線的 add/get/consume）；傳話隊列的實體檔在 ~/.openclaw/data/relay-queue.json（六筆訊息全寄給 main，最後消費於 2026-07-05）；被關掉的主 agent gateway 是 hermes-gateway.service（今天 mask 為 inactive，一週省下 $17）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。