拆解 OpenClaw 11 ｜ 龍蝦軍團：當多個 Agent 組成一家公司
整理版優先睇
多 Agent 系統點樣揀？三種架構比較同實戰建議
呢篇文章係技術開發者 Mike Kelly 發現 Claude Code 隱藏嘅多 Agent 系統之後，整合 ChatDev 論文同 OpenClaw 功能寫出嚟嘅。作者想解決嘅問題係：單個 Agent 因為上下文限制同注意力渙散，做唔到大規模任務，點樣用多個 Agent 協作先至高效又安全？
整體結論係：冇一套架構適合所有情況，要根據任務性質揀。文章詳細比較咗三條路線：ChatDev/MetaGPT 嘅公司模擬（固定角色、結構化文檔）、Claude Code Agent Teams 嘅項目組模式（動態組建、製片人制）、OpenClaw 嘅聲明式艦隊（永久隔離、按渠道路由）。
最後作者畀咗實戰建議：日常編程用 Subagent，大型重構用 Agent Teams（上限 3 個），日常助理用 OpenClaw。同時強調安全隔離好重要，唔好亂開 Agent 之間嘅通信。
- 多 Agent 係解決單 Agent 上下文限制嘅必要方向，但唔係萬能，要揀啱架構。
- 三種架構各有定位：公司模擬適合需求明確嘅小項目；項目組模式適合大型並行任務；聲明式艦隊適合長期運行嘅渠道助理。
- 核心差異：ChatDev 靠固定角色同對話鏈；MetaGPT 靠結構化文檔減低歧義；Claude Code Teams 靠製片人制動態協調；OpenClaw 靠聲明式配置同物理隔離。
- 多 Agent 最大風險係攻擊面放大，一個被攻陷嘅 Agent 可以向其他 Agent 橫向移動，權限一定要收緊。
- 實戰建議：3-4 個 Agent 係甜蜜點；用 Plan Mode 諗清楚先執行可以慳 Token；組長用 Opus，隊友用 Sonnet 性價比最高。
結構示例
# Linux 路徑 ~/.local/share/claude/versions/2.1.29# Mac 路徑 ~/Library/Application Support/Claude/claude-code/2.1.63/claudestrings <你的claude二進制路徑> | grep TeammateTool一個 Agent 唔夠使？多 Agent 崛起
今年一月底，開發者 Mike Kelly 對着 Claude Code 嘅二進制檔案 run 咗條 strings 指令，發現裏面藏住一套完整嘅多 Agent 編排系統，有成 13 個操作同目錄結構，只係未開放俾人用。同一時間，ChatDev 團隊出咗論文，用 7 個 AI 角色模擬軟件公司行曬成條 pipeline；OpenClaw 亦正式上線 Multi-Agent Routing，俾你一次過 declare 成班 Agent。
呢三條路線雖然哲學唔同，但都係為咗解決同一個問題：一個 Agent 嘅上下文同能力有物理上限，點樣先可以透過多 Agent 協作搞掂大型任務？
一個 Agent 幹活本質係 while 循環：收到指令 -> 思考 -> 調用工具 -> 觀察 -> 繼續思考，有兩個硬傷：上下文撐爆同注意力渙散（Lost in the Middle）。
多 Agent 嘅解法好直白：與其逼一個 Agent 做全棧，不如分拆俾幾個 Agent 各管一攤。
三種多 Agent 架構三種活法
第一種係公司模擬，代表作有 ChatDev 同 MetaGPT。ChatDev 行導演制，將軟件開發拆成設計、編碼、測試、文檔四個瀑布階段，角色寫死，Agent 之間靠 Chat Chain 通信，避免 N 個 Agent 自由講嘢搞到複雜度爆炸。
MetaGPT 嘅核心哲學係 Code = SOP(Team)，佢唔畀 Agent 亂傾，而係通過結構化文檔（PRD、系統設計文檔）交換資訊，文檔信息密度高、歧義少，可以顯著減少級聯幻覺。
第二種係項目組模式，即 Claude Code Agent Teams。佢係動態組建嘅，需要開環境變數 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。核心係製片人制：Lead 負責拆任務、分配工作、綜合結果，隊友之間可以 SendMessage 互相 challenge，任務有依賴鏈，按波次執行。實戰有人用 16 個 Agent 從零寫咗個可以編譯 Linux 內核嘅 Rust C 編譯器。
第三種係 OpenClaw Multi-Agent，行部門制，係聲明式嘅常駐 Agent 艦隊。喺 openclaw.json 定義多個 Agent，每個有獨立工作空間、記憶同模型，透過 Bindings 路由引擎將唔同渠道綁俾唔同 Agent。Agent 之間預設唔通信，除非你喺 tools.agentToAgent.allow 度顯式開通。仲可以將唔 trust 嘅 Agent 關入沙箱，只俾讀權限。
- 公司模擬：固定角色，適合需求明確嘅瀑布式小項目，但敏捷迭代就唔夠靈活。
- 項目組模式：動態組建，適合大型並行任務（例如重構、多維度檢查），但 Token 消耗高。
- 聲明式艦隊：永久隔離，適合長期運行嘅渠道助理，安全可控。
拉通對比：邊個適合你？
- 任務天然可並行（前端/後端/測試同時推）、需要多視角交叉驗證（安全/性能/規範）、探索空間大（多假設並行排查 Bug）—— 適合用多 Agent。
- 任務有強順序依賴（大部分時間喺度等）、頻繁修改同一個文件、任務太簡單 —— 唔適合用多 Agent，純粹浪費 Token。
從 Token 成本睇，單 Agent 會話大約用 200K tokens，3 個 Subagent 用 440K，但 3 人 Agent Team 就要 800K。所以一定要諗清楚先至執行：先用 Plan Mode（便宜）諗好方案，再交俾 Team 並行執行（貴但快）。組長用 Opus 做統籌，隊友用 Sonnet 做執行，性價比最高。
避坑指南：安全同成本要諗清楚
作為安全從業者，多 Agent 令我最擔心嘅唔係 Token，而係攻擊面放大。如果 Agent 之間可以通信，一個被 Prompt Injection 攻陷嘅 Agent 就可以向其他 Agent 發送惡意指令（橫向移動），共享文件系統仲有二次感染風險。
工程嘅本質從來唔係“能不能做到”，而係“喺限制條件下做到最好”。多 Agent 都係一樣，要喺成本、安全、效率之間取捨。
我嘅選擇：夠用、可控、安全
- 1 日常編程：用 Claude Code 嘅 Subagent（Task 工具）就夠，便宜又高效。
- 2 大型重構：用 Agent Teams，上限控 3 個，Sonnet 做隊友，Opus 做組長，先 Plan 後執行。
- 3 日常助理：用 OpenClaw 嘅 Multi-Agent，按渠道路由，嚴格物理隔離，關閉 Agent 間通信。
三種方案入面，OpenClaw 嘅聲明式隔離最啱我口味，因為佢預設就係隔離，安全意識內建喺設計入面。
總括嚟講，多 Agent 係工具，唔係目的。揀邊種，取決於你係想養一羣龍蝦，定係開一間公司。
💡 睇之前記得關注+星標，先可以收到更新推送
「拆解 OpenClaw」系列第十一篇，應用系列第二篇。上一篇講咗點樣養一隻龍蝦，呢篇講點樣養一羣。
今年一月尾，開發者 Mike Kelly 對住 Claude Code 嘅二進制檔案行咗一行指令：
# Linux 路徑 ~/.local/share/claude/versions/2.1.29
# Mac 路徑 ~/Library/Application Support/Claude/claude-code/2.1.63/claude
strings <你的claude二進制路徑> | grep TeammateTool佢發現入面收埋咗一套完整嘅多 Agent 編排系統 —— 13 個操作、完整嘅目錄結構全部寫好，只係未對外開放。呢個說明連 Anthropic 都認為「單個 Agent 唔夠用」係個真問題。
差唔多同一時間，ChatDev 團隊出咗論文，用 7 個 AI 角色模擬軟件公司行曬成個流程；OpenClaw 亦都正式上線咗 Multi-Agent Routing，容許喺一個配置入面聲明一支 Agent 艦隊。
三條路線，三種哲學，都係解決同一個問題：一個 Agent 嘅上下文同能力有物理上限，點樣令到多個 Agent 協作做大嘢？
點解一個 Agent 唔夠用
一個 Agent 做嘢本質係個 while 循環：收到指令 -> 思考 -> 調用工具 -> 觀察 -> 繼續思考。呢個循環有兩個硬傷：
1. 上下文爆煲：令一個 Agent 同時睇前端、後端、測試同埋部署腳本，上下文好快就會塞滿，必然導致資訊截斷或者壓縮。 2. 注意力渙散（Lost in the Middle）：上下文太長嘅時候，大模型對中間資訊嘅關注度會下降。又要效能又要安全又要規範，佢多數會顧此失彼。
多 Agent 嘅解法好直接：與其令一個 Agent 做全棧，不如令多個 Agent 各自負責一攤嘢。
三種多 Agent 架構，三種玩法
流派一：公司模擬 —— ChatDev 同 MetaGPT
ChatDev（導演制）：將軟件開發拆成設計、編碼、測試、文檔四個瀑布階段。CEO、CTO、程序員等角色寫死。Agent 之間靠預設嘅「Chat Chain」（對話鏈）通信，規定邊個同邊個講嘢，避免 N 個 Agent 自由通信導致 O(N²) 嘅複雜度爆炸。
MetaGPT（SOP制）：核心哲學係 Code = SOP(Team)。佢唔俾 Agent 亂傾，而係通過「結構化文檔」通信（例如 PRD、系統設計文檔）。文檔資訊密度高、歧義少，可以顯著減少級聯幻覺。
侷限：角色同流程都係預設嘅，適合需求明確嘅小項目，遇上敏捷迭代嘅真實場景就會力不從心。
流派二：項目組模式 —— Claude Code Agent Teams
如果 ChatDev 係固定班底嘅公司，Claude Code Agent Teams 就係動態組建嘅項目組。需要喺配置入面手動開啓 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。
佢嘅核心係製片人制：Lead（組長）負責拆任務、分配工作、綜合結果。隊友之間可以自由通信（SendMessage）、互相挑戰。任務有依賴鏈，按波次執行。
實戰入面，有人搭咗 5 個 Agent 並行做博客 QA（查狀態碼、死鏈、SEO等），3 分鐘搞掂；甚至有人用 16 個 Agent 從零寫咗個可以編譯 Linux 內核嘅 Rust C 編譯器。
隱形賬單（Token 成本）：
每個隊友都係完整嘅會話，多一個隊友就多一份消耗。
慳錢建議：先用 Plan Mode（平）諗清楚方案，再交俾 Team 並行執行（貴但快）。組長用 Opus（統籌強），隊友用 Sonnet（執行快）。
流派三：聲明式艦隊 —— OpenClaw Multi-Agent Routing
OpenClaw 行嘅係部門制 —— 聲明式嘅常駐 Agent 艦隊。喺 openclaw.json 入面定義多個 Agent：
{
"agents": {
"list": [
{ "id": "chat", "workspace": "~/.openclaw/workspace-chat", "model": "anthropic/claude-sonnet-4-5" },
{ "id": "opus", "workspace": "~/.openclaw/workspace-opus", "model": "anthropic/claude-opus-4-6" },
{ "id": "family", "workspace": "~/.openclaw/workspace-family", "model": "deepseek/deepseek-chat" }
]
}
}每個 Agent 係「完全隔離嘅大腦」（獨立工作空間、記憶、模型）。通過 Bindings 路由引擎，將微信個人號綁俾 Sonnet，Telegram 工作羣綁俾 Opus，家庭羣綁俾 DeepSeek。
Agent 之間默認唔通信，除非喺 tools.agentToAgent.allow 入面顯式配置。唔信任嘅 Agent 仲可以單獨關入沙箱（唯讀權限）。例如：
{
"agents": {
"list": [
{
"id": "family",
"sandbox": { "mode": "all", "scope": "agent" },
"tools": { "allow": ["read"], "deny": ["exec", "write"] }
}
]
},
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["chat", "opus"] // 允許 chat 和 opus 互相通信，family 被排除在外
}
}
}三種方案拉通對比
講真：多 Agent 避坑指南
作為安全從業者，多 Agent 令我最擔心嘅唔係 Token，而係攻擊面放大。如果 Agent 之間可以通信，一個被 Prompt Injection 攻陷嘅 Agent 就可以向其他 Agent 發送惡意指令（橫向移動）。共享檔案系統都有二次感染風險。
建議：權限收攏一定要比單 Agent 更嚴。唔需要通信就堅決唔開，唔需要寫權限就堅決唯讀。
幾時應該用？
• 任務天然可以並行（前端/後端/測試同時推進） • 需要多視角交叉驗證（安全/性能/規範多維代碼審查） • 探索空間大（多假設並行排查古怪 Bug）
幾時唔應該用？
• 任務有強順序依賴（大部分時間喺度等，白燒 Token） • 成日修改同一個檔案（檔案鎖防止唔到語義衝突） • 任務太簡單（建立團隊嘅開銷比做嘢仲大）
經驗法則：3-4 個 Agent 係甜蜜點。 再多，協調開銷就會超過並行收益。
我嘅選擇
唔追求最型，只係睇重夠用、可控、安全：
1. 日常編程：用 Claude Code 嘅 Subagent（Task 工具）就夠，平靚正。 2. 大型重構：用 Agent Teams。上限控制 3 個，Sonnet 做隊友，Opus 做組長。先 Plan 後執行。 3. 日常助手：用 OpenClaw 嘅 Multi-Agent。按渠道路由，嚴格物理隔離，關閉 Agent 之間嘅通信。
工程嘅本質從來都唔係「做唔做到」，而係「喺限制條件下做到最好」。
參考連結
• Paddo：Claude Code 隱藏嘅多 Agent 系統拆解 • kieranklaassen：TeammateTool 完整 schema • Mike Kelly：claude-sneakpeek • Claude Code Agent Teams 官方文檔
下一篇講啲輕鬆嘅 —— OpenClaw 十大野生應用場景，有人用佢砍咗 4200 美元車價，有人令佢自己打贏咗保險理賠。
💡 閲讀前記得關注+星標，及時獲取更新推送
「拆解 OpenClaw」系列第十一篇，應用系列第二篇。上一篇講了怎麼養一隻龍蝦，這篇講怎麼養一羣。
今年一月底，開發者 Mike Kelly 對着 Claude Code 的二進制文件跑了一行命令：
# Linux 路徑 ~/.local/share/claude/versions/2.1.29
# Mac 路徑 ~/Library/Application Support/Claude/claude-code/2.1.63/claude
strings <你的claude二進制路徑> | grep TeammateTool他發現裏面藏着一套完整的多 Agent 編排系統 —— 13 個操作、完整的目錄結構全部寫好，只是沒對外開放。這說明連 Anthropic 都認為“單個 Agent 不夠使”是個真問題。
差不多同時，ChatDev 團隊發了論文，用 7 個 AI 角色模擬軟件公司跑通了全流程；OpenClaw 也正式上線了 Multi-Agent Routing，允許在一個配置裏聲明一支 Agent 艦隊。
三條路線，三種哲學，都在解同一個問題：一個 Agent 的上下文和能力有物理上限，怎麼讓多個 Agent 協作幹大活？
為什麼一個 Agent 不夠使
一個 Agent 幹活本質是個 while 循環：收到指令 -> 思考 -> 調用工具 -> 觀察 -> 繼續思考。這個循環有兩個硬傷：
1. 上下文撐爆：讓一個 Agent 同時看前端、後端、測試和部署腳本，上下文很快塞滿，必然導致信息截斷或壓縮。 2. 注意力渙散（Lost in the Middle）：上下文太長時，大模型對中間信息的關注度會下降。既要性能又要安全還要規範，它大概率顧此失彼。
多 Agent 的解法很直白：與其讓一個 Agent 當全棧，不如讓多個 Agent 各管一攤。
三種多 Agent 架構，三種活法
流派一：公司模擬 —— ChatDev 和 MetaGPT
ChatDev（導演制）：把軟件開發拆成設計、編碼、測試、文檔四個瀑布階段。CEO、CTO、程序員等角色寫死。Agent 之間靠預設的“Chat Chain”（對話鏈）通信，規定誰跟誰說話，避免 N 個 Agent 自由通信導致 O(N²) 的複雜度爆炸。
MetaGPT（SOP制）：核心哲學是 Code = SOP(Team)。它不讓 Agent 瞎聊，而是通過“結構化文檔”通信（如 PRD、系統設計文檔）。文檔信息密度高、歧義少，能顯著減少級聯幻覺。
侷限：角色和流程都是預設的，適合需求明確的小項目，碰上敏捷迭代的真實場景就力不從心。
流派二：項目組模式 —— Claude Code Agent Teams
如果 ChatDev 是固定班底的公司，Claude Code Agent Teams 就是動態組建的項目組。需要在配置裏手動開啓 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。
它的核心是製片人制：Lead（組長）負責拆任務、分配工作、綜合結果。隊友之間可以自由通信（SendMessage）、互相挑戰。任務有依賴鏈，按波次執行。
實戰中，有人搭了 5 個 Agent 並行做博客 QA（查狀態碼、死鏈、SEO等），3 分鐘跑完；甚至有人用 16 個 Agent 從零寫了個能編譯 Linux 內核的 Rust C 編譯器。
隱形賬單（Token 成本）：
每個隊友都是完整的會話，多一個隊友多一份消耗。
省錢建議：先用 Plan Mode（便宜）想清楚方案，再交給 Team 並行執行（貴但快）。組長用 Opus（統籌強），隊友用 Sonnet（執行快）。
流派三：聲明式艦隊 —— OpenClaw Multi-Agent Routing
OpenClaw 走的是部門制 —— 聲明式的常駐 Agent 艦隊。在 openclaw.json 裏定義多個 Agent：
{
"agents": {
"list": [
{ "id": "chat", "workspace": "~/.openclaw/workspace-chat", "model": "anthropic/claude-sonnet-4-5" },
{ "id": "opus", "workspace": "~/.openclaw/workspace-opus", "model": "anthropic/claude-opus-4-6" },
{ "id": "family", "workspace": "~/.openclaw/workspace-family", "model": "deepseek/deepseek-chat" }
]
}
}每個 Agent 是“完全隔離的大腦”（獨立工作空間、記憶、模型）。通過 Bindings 路由引擎，把微信個人號綁給 Sonnet，Telegram 工作羣綁給 Opus，家庭羣綁給 DeepSeek。
Agent 間默認不通信，除非在 tools.agentToAgent.allow 裏顯式配置。不信任的 Agent 還可以單獨關進沙箱（只讀權限）。例如：
{
"agents": {
"list": [
{
"id": "family",
"sandbox": { "mode": "all", "scope": "agent" },
"tools": { "allow": ["read"], "deny": ["exec", "write"] }
}
]
},
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["chat", "opus"] // 允許 chat 和 opus 互相通信，family 被排除在外
}
}
}三種方案拉通對比
實話實說：多 Agent 避坑指南
作為安全從業者，多 Agent 讓我最擔心的不是 Token，而是攻擊面放大。如果 Agent 之間能通信，一個被 Prompt Injection 攻陷的 Agent 就能向其他 Agent 發送惡意指令（橫向移動）。共享文件系統也有二次感染風險。
建議：權限收斂必須比單 Agent 更嚴。不需要通信堅決不開，不需要寫權限堅決只讀。
什麼時候該用？
• 任務天然可並行（前端/後端/測試同時推進） • 需要多視角交叉驗證（安全/性能/規範多維代碼審查） • 探索空間大（多假設並行排查詭異 Bug）
什麼時候不該用？
• 任務有強順序依賴（大部分時間在乾等，白燒 Token） • 頻繁修改同一個文件（文件鎖防不了語義衝突） • 任務太簡單（建團隊的開銷比干活還大）
經驗法則：3-4 個 Agent 是甜蜜點。 再多，協調開銷就會超過並行收益。
我的選擇
不追求最酷炫，只看重夠用、可控、安全：
1. 日常編程：用 Claude Code 的 Subagent（Task 工具）足矣，便宜高效。 2. 大型重構：用 Agent Teams。上限控 3 個，Sonnet 跑隊友，Opus 當組長。先 Plan 後執行。 3. 日常助理：用 OpenClaw 的 Multi-Agent。按渠道路由，嚴格物理隔離，關閉 Agent 間通信。
工程的本質從來不是“能不能做到”，而是“在約束條件下做到最好”。
參考連結
• Paddo：Claude Code 隱藏的多 Agent 系統拆解 • kieranklaassen：TeammateTool 完整 schema • Mike Kelly：claude-sneakpeek • Claude Code Agent Teams 官方文檔
下一篇聊點輕鬆的 —— OpenClaw 十大野生應用場景，有人用它砍了 4200 美元車價，有人讓它自己打贏了保險理賠。