一文講透 OpenClaw 裏到底該用 Multi-Agent，還是主 Agent + Sub-Agent
整理版優先睇
一文講透 OpenClaw 內 Multi-Agent 同主 Agent+Sub-Agent 點揀：長期分工定任務拆解？
呢篇文章係作者結合 OpenClaw 官方文檔，釐清 Multi-Agent 同主 Agent+Sub-Agent 嘅本質分別。佢發現好多人撈亂咗呢兩個概念，唔知點樣選擇。作者先定義咗兩者：Multi-Agent 係多個完全隔離嘅獨立大腦，各自有獨立 workspace、auth 同 session，透過路由將唔同入口嘅消息分派俾對應 agent；主 Agent+Sub-Agent 就係由一個總控 agent 臨時拉出 sub-agent 去執行具體任務，完成後回收結果。
整體結論好簡單：Multi-Agent 解決嘅係長期分工同隔離，而主 Agent+Sub-Agent 解決嘅係任務拆解同調度。用錯架構嘅話，一係過度設計，一係就搞到上下文混亂。作者建議由實際場景出發：如果你有多個長期角色、需要不同 workspace 或入口路由、又或者要認證隔離，就優先揀 Multi-Agent；如果你主要得一個統一入口、做複雜任務拆解、又唔想維護太多長期 agent，就主+sub。佢仲提供咗具體實操路線同常見陷阱，提醒唔好一開始就拆太多長期 agent。
- 結論：Multi-Agent 負責長期分工與隔離，主 Agent+Sub-Agent 負責任務拆解與調度，兩者設計目的根本不同。
- 方法：Multi-Agent 需配置獨立 workspace、auth、路由綁定；主+sub 透過 /subagents spawn 臨時委派子任務，完成後自動回收。
- 差異：Multi-Agent 係「組織結構」，強調邊界與路由；主+sub 係「任務編排」，強調委派與並行。
- 啟發：唔好一開始就拆太多長期 agent，穩妥路線係先主 agent，遇到複雜任務先用 sub-agent，等某類任務穩定後先升級做獨立 agent。
- 可行動點：按場景二選一：多長期角色、多入口、需隔離 → 行 Multi-Agent 路線；單一入口、複雜任務、想保持對話統一 → 行主+sub 路線。
Multi-Agent Routing 官方文檔
解釋 OpenClaw 中多 agent 路由嘅概念同配置方法。
Agent Workspace 官方文檔
說明每個 agent 嘅 workspace 係佢嘅 home，包括 AGENTS.md、SOUL.md 等設定。
Slash Commands 官方文檔
列出 TUI 中 sub-agent 相關嘅斜槓命令，例如 spawn、kill、list 等。
CLI: agents 官方文檔
開源 CLI 指令 agents 嘅用法，包括加 agent、睇綁定等。
釐清概念：Multi-Agent vs 主 Agent+Sub-Agent
OpenClaw 官方文檔對 agent 嘅定義好明確：一個 agent 唔係一句 prompt，而係一個完全隔離嘅大腦，擁有獨立嘅 workspace、agentDir、auth profiles、session store 同 persona 規則。
Multi-Agent 係多個獨立工作單元並存，唔係「一個 agent 換幾套 prompt」
主 Agent+Sub-Agent 就唔同：sub-agent 係由當前會話拉起身嘅一次性委託執行器，做完就收工，唔係長期崗位。
Multi-Agent 點運作？
Multi-Agent 嘅目標係喺一個 Gateway 進程入面運行多個隔離 agent，每個 agent 有獨立 workspace、auth 同 sessions，透過 bindings 將唔同入口嘅消息路由到對應 agent。
路由係十字路口，決定條消息派俾邊個 agent
路由可以按 channel（例如飛書俾 work-agent）、按 accountId（同平台多賬號）、按 peer/group/DM/guild/thread 等條件分流。綁定規則係 deterministic，most-specific wins。
- 1 按 channel：飛書→work-agent，Telegram→personal-agent
- 2 按 accountId：同一個平台多個 bot 賬號，各自流向不同 agent
- 3 按聊天對象：某個特定羣、私聊、服務器、討論串，都可以精確路由
實用 Tip：創建多個 IM 羣，每個羣對應一個 agent，係最常用做法
主 Agent+Sub-Agent 點運作？
主 agent 係總控，接收用戶需求，判斷係咪適合拆解，然後拉起一個或多個 sub-agent。Sub-agent 各自執行完，主 agent 回收結果並匯總。
Sub-agent 似臨時工、分包線程、一次性委託執行器，唔係長期角色
典型使用方式：研究任務拆成查資料、整理結構、校對反查，每個 sub-agent 專注一件事，避免上下文混亂同步驟幹擾。
點樣揀？場景決定選擇
官方文檔推薦，如果你有以下特徵，優先 Multi-Agent：多個長期角色（writer、ops）、需要唔同 workspace、唔同入口直接進入唔同 agent、要認證權限隔離。
Multi-Agent 強項係長期邊界清晰、入口直接路由、權限分離
如果你主要得一個統一入口（例如自己喺 TUI 用）、更多係複雜任務拆解而唔係長期角色、暫時唔想維護好多長期 agent、想保留統一對話體驗，咁優先主+sub。
主+sub 輕量、靈活，先唔使設計成個組織結構
一個實用搭法係：長期層用 Multi-Agent（main、writer、ops），執行層喺 writer 或 ops 內部再拉 sub-agent。咁樣純多 agent 或純主+sub 都更實用。
實操路線同常見陷阱
路線 A（Multi-Agent）：先用 openclaw agents add 加 agent，再用 bindings 將入口綁俾對應 agent，最後補齊每個 workspace 嘅 AGENTS.md、SOUL.md 等。路線 B（主+sub）：先保留一個主 agent，喺複雜任務用 /subagents spawn 命令，唔好一開始就做大規模組織設計。
記住 workspace 係默認 cwd，唔係強沙箱；真正隔離要睇 sandbox 配置
- 陷阱1：以為 workspace 係強沙箱，其實要另外配 sandbox
- 陷阱2：一嚟就拆好多長期 agent，搞到碎片化
- 陷阱3：唔分清路由綁定規則，導致消息去向混亂
越來越多人開始整多Agent系統，又見到sub-agent嘅用法，諗唔明：
• 應唔應該直接配幾個長期嘅agent？ • 定係保留一個主agent，再用sub-agent去做任務拆解？ • 呢兩種模式到底有咩分別？ • 邊種更加適合個人用，邊種更加適合長期體系化？
呢篇文章會結合OpenClaw官方文檔嚟分享：
1. Multi-Agent到底係乜嘢 2. 主agent + sub-agent到底係乜嘢 3. 實際上應該點樣揀、點樣落地
先畀結論：
Multi-Agent解決嘅係「長期分工同隔離」。
主agent + sub-agent解決嘅係「任務拆解同調度」。
只要分清呢兩個問題，好多架構選擇就唔會難。
一、Multi-Agent：幾個獨立Agent
OpenClaw官方文檔對agent嘅定義好清楚：一個agent唔係一句prompt，亦唔係一個會話皮膚，而係一個完全隔離嘅大腦。佢自己有：
• workspace • agentDir• auth profiles • session store • persona / SOUL / AGENTS規則 • skills
一個agent係fully scoped brain。
佢有獨立嘅workspace、狀態目錄、認證同會話儲存。
即係話，多agent並唔係「一個agent換幾套prompt」，而係幾個獨立工作單元並存。
根據官方文檔，Multi-Agent Routing嘅目標係：
• 喺一個Gateway進程入面，執行幾個隔離嘅agent • 每個agent有獨立workspace + auth + sessions • 通過bindings，將唔同入口嘅消息路由到唔同agent
講到路由，好多人唔明。路由嘅意思就係十字路口、分發規則：將一條消息分配畀邊個agent處理。可以將OpenClaw諗成一個總機。消息入咗嚟之後，佢唔會急住答，而係先判斷：呢條消息嚟自邊度、邊個發嘅、喺邊個羣組/私訊/討論串入面、應該交畀邊個agent，呢一步判斷過程，就叫做routing。
• 可以按channel路由，例如飛書嚟嘅交畀work-agent，Telegram嚟嘅交畀personal-agent； • 可以按accountId路由，同一個平台入面，你可以連接多個帳號，例如兩個飛書bot，唔同bot收到嘅消息交畀唔同agent； • 可以按peer / group / DM / guild / thread路由，即係按傾偈對象或傾偈場景分流：peer：某個具體嘅人；group：某個具體羣組；DM：私訊呢種會話模式，相對羣組傾偈嚟講；guild：伺服器/組織空間，常見於Discord呢類；thread：某個具體討論串（同一個平台、同一個帳號之下，唔同傾偈上下文仲可以繼續分配畀唔同agent）； • 綁定規則係deterministic，而且most-specific wins。意思係路由結果係確定嘅，唔會一時一樣，同樣嘅輸入條件，一定會命中同一條規則；當規則衝突時，更具體嘅嗰條優先，例如你同時set咗：「所有飛書消息 -> agent A」、「飛書入面某個羣 -> agent B」，咁呢個羣入面嘅消息就會行agent B，因為「某個羣」比「所有飛書消息」更具體。
實用Tips： OpenClaw可以將唔同來源嘅消息，自動送入唔同agent。 例如：飛書接文檔處理agent、discord接營運agent...或者喺飛書入面開幾個唔同嘅羣，分別對應唔同嘅agent，呢個係更加常用嘅做法，畢竟我哋常用嘅IM得一兩個。
二、主agent + sub-agent：一個總控 + 幾個任務執行器
OpenClaw入面對sub-agent嘅定位，同多agent好唔同。喺slash commands（TUI入面嘅斜槓命令）入面，官方支援：
• /subagents list|kill|log|info|send|steer|spawn
喺ACP文檔入面，官方仲專登對比咗：
• ACP session • OpenClaw native sub-agent run
呢個說明sub-agent唔係「長期存在嘅agent」，而係：
由當前會話拉起嘅delegated run（臨時委派辦一件事）。
• 主agent：總控、接需求、做判斷 • sub-agent：臨時被拉起身去做一件具體嘅事
典型嘅工作方式係：
1. 主agent接收用戶需求 2. 判斷呢件事適唔適合拆開 3. 拉起一個或多個sub-agent 4. sub-agent各自執行 5. 主agent回收結果並匯總
所以sub-agent更加似：
• 臨時工 • 分包線程 • 並行執行單位 • 一次性委託執行器
而唔係長期角色。
三、最核心嘅分別：組織方式唔同
好多人誤以為：
• 多agent = 多個agent • 主 + sub-agent = 都係多個agent
只係叫法唔同。
其實唔係。
官方文檔可以睇得出，呢兩者喺設計目的上已經唔同。
1）Multi-Agent係「組織結構」
佢強調：
• 獨立workspace • 獨立auth • 獨立sessions • 獨立identity • 獨立routing
所以Multi-Agent更加似：
你喺一部OpenClaw入面養咗幾個長期崗位。
佢解決嘅係：
• 邊個負責邊類事 • 邊個接收邊個入口嘅消息 • 邊個用咩模型同權限 • 邊個應該同邊個隔離
2）主agent + sub-agent係「任務編排」
佢強調：
• 委派 • 並行 • 臨時執行 • 當前會話入面調度 • 執行完再回收
所以佢更加似：
一個項目經理，臨時叫幾個人去做子任務。
佢解決嘅係：
• 一個複雜任務點樣拆 • 邊啲事適合並行做 • 主會話點樣保持清爽 • 重嘢點樣外判出去做
四、Multi-Agent嘅優勢同代價
優勢1：長期邊界清晰
Multi-Agent最強嘅一點，就係邊界清晰，好適合長期分工。例如：
• 寫作agent永遠只處理內容 • 運維agent永遠只處理系統 • 某個agent只服務某個Telegram帳號 • 某個agent只綁定某個Discord bot
呢個就係結構化隔離。
優勢2：入口可以直接路由
你可以直接將入口級流量路由畀唔同agent，而唔係所有消息都先經過一個總控再分發。呢個好適合：
• 多個帳號 • 多個bot • 多個團隊 • 多個角色 • 多個頻道/羣組傾偈
優勢3：適合權限同認證分離
官方文檔反覆強調auth係per-agent嘅，唔會自動共享。呢個對長期生產環境特別重要。因為呢個意味住你可以做到：
• A agent用呢套auth • B agent用另一套auth • 唔同agent嘅模型、密鑰、服務邊界自然分開
代價1：配置同維護成本更高
你要維護嘅嘢會明顯增加：
• agent列表 • workspace • identity • bindings • accountId • auth複製或隔離 • 會話歸屬
如果你拆得太細，好容易會出現：
• 自己都記唔起邊個做啲乜 • agent太多導致碎片化 • 除錯同維護變得複雜
代價2：唔適合一開始就過度設計
如果你當前其實仲得一個穩定入口、一個主要嘅使用者、一個主要嘅任務類型，咁一下子整咁多長期agent，通常會過度設計。
五、主agent + sub-agent嘅優勢同代價
呢套模式嘅優點，主要嚟自「靈活」。
優勢1：可以先唔使設計一整套組織結構
你可以一開始只得一個主agent。等遇到複雜任務時，再決定：
• 要不要 spawn sub-agent • 要不要並行 • 要不要長時間後台執行
呢個比一開始就set好多長期agent輕便好多。
優勢2：複雜任務更容易拆解
例如你要做一篇複雜嘅內容：
• 子代理A：查資料 • 子代理B：整理結構 • 子代理C：校對同反查
主agent只負責：
• 理解目標 • 分配任務 • 最終匯總
呢類模式特別適合：
• 研究 • 批量整理 • 重型執行任務 • 長上下文拆解 • 並行處理
優勢3：主對話體驗更統一
對於用戶嚟講，入口通常只得一個。
呢個意味住體驗上更加自然：
• 你永遠都係同一個主agent講嘢 • 複雜性都被隱藏喺後面
代價1：主agent會變成總控中心
所有任務都先入主agent，再分發畀sub-agent。
呢個會導致：
• 主agent變成單點中樞 • 複雜任務多嘅時候，調度邏輯容易變重
代價2：唔天然適合長期角色分工
sub-agent嘅強項係執行，唔係長期身份。如果你將所有長期角色都硬塞成sub-agent，最後會比較彆扭。因為：
• 佢哋唔係入口級角色 • 唔係天然長期駐場 • 唔適合承接多渠道長期綁定
六、官方文檔推薦：到底應該揀邊種？
適合優先Multi-Agent嘅情況
如果你符合下面呢啲特徵，優先多agent：
1）你有多個長期角色
比如：
• writer • ops • research • assistant
2）你需要唔同嘅workspace
官方文檔明確話workspace係agent嘅home。所以當唔同角色需要長期維護自己嘅檔案、記憶、persona同技能時，自然適合拆agent。
3）你需要唔同入口直接入唔同agent
比如：
• 某個Telegram帳號永遠入writer • 某個Discord bot永遠入coding • 某啲WhatsApp DM永遠入某個agent
4）你需要認證同權限隔離
唔同agent各自有唔同嘅auth profiles，呢個就係多agent嘅強項。
適合優先主agent + sub-agent嘅情況
如果你更加似下面呢樣，優先主 + sub：
1）你目前主要得一個統一入口
例如你主要就自己喺TUI入面用，或者一個主要嘅傾偈入口。
2）你更加多係複雜任務拆解，而唔係長期角色拆分
比如：
• 研究任務拆成幾路並行 • 寫作任務拆成資料/大綱/校對 • 編碼任務拆成檢查/修改/驗證
3）你暫時唔想維護好多長期agent
呢種情況下，sub-agent嘅靈活性更好。
4）你更加想保持一個統一嘅對話體驗
即係永遠同一個主agent交流，後面嘅複雜性由佢內部消化。
另外，我以前諗過，咩場景下一定要用多個sub-agent，用一個agent唔夠咩？因為「一個agent全包」喺簡單任務入面可以，但任務一複雜，就會同時出現四個問題：上下文混亂、步驟互相干擾、速度慢、結果唔穩定。一個agent做曬嘅時候，常見情況係：一邊叫佢查資料，一邊搭結構，一邊改措辭，目標容易走偏；唔同子任務共用同一個上下文，垃圾資訊越堆越多，前面查到嘅弱結論，會污染後面嘅寫作同判斷；所有事串行做，慢。而且好難局部重做，例如「只重做校對，唔重做檢索」。而拆成多個子agent之後，每個只做一件事，會更加穩定：
• 查資料agent：只負責蒐集同篩選資訊，優化目標係覆蓋率同證據質量； • 結構agent：唔會被檢索噪音幹擾，只負責組織邏輯； • 校對/反查agent：企喺「審核者」嘅角度，專挑漏洞，而唔係順住原答案一直寫落去。
實際操作落嚟，多sub-agent真係好好用。
• Multi-Agent負責長期隔離同路由 • sub-agent負責當前任務嘅拆解同執行
一個好實用嘅搭配方法係：
長期層
• main：總控 / 默認入口• writer：內容創作• ops：系統同運維
執行層
在 writer 或 ops 內部，需要做重嘢嘅時候，再拉sub-agent。例如：
writer內部
• sub-agent A：蒐集資料 • sub-agent B：整理大綱 • sub-agent C：做事實核查
ops內部
• sub-agent A：查日誌 • sub-agent B：做配置對比 • sub-agent C：生成修復建議
呢個通常比「純多agent」或「純主+sub」都更加實用。
七、實際操作
路線A：Multi-Agent
第一步：先加長期agent
openclaw agents add writer
openclaw agents add ops第二步：睇綁定情況
openclaw agents list --bindings
openclaw agents bindings第三步：將入口綁定畀對應嘅agent
openclaw agents bind --agent writer --bind telegram:writer
openclaw agents bind --agent ops --bind discord:ops第四步：幫各自嘅workspace補番人格同規則
每個agent嘅workspace入面都應該有自己嘅：
• AGENTS.md• SOUL.md• USER.md• IDENTITY.md
呢個係官方workspace文檔入面最值得重視嘅部分。
第五步：重啟並驗證
openclaw gateway restart
openclaw channels status --probe
openclaw agents list --bindings路線B：主agent + sub-agent
第一步：先保留一個主agent
即係暫時唔好拆咁多長期agent。
第二步：喺複雜任務入面用sub-agent命令
TUI入面官方支援：
• /subagents list• /subagents spawn• /subagents steer• /subagents kill
呢個意味住你可以先從任務拆解入手，而唔係先做大規模組織設計。
第三步：區分是否用ACP外部harness
• ACP session：係通過ACP呢個協議去對接外部agent/harness，例如接Codex、Claude Code、Gemini CLI，呢個時候OpenClaw唔再只係內部自己轉，而係同外部執行器通訊； • OpenClaw native sub-agent runtime：係OpenClaw自己內部嘅「子代理執行機制」，主agent喺當前會話入面臨時委派一個子任務畀另一個執行單位，呢個係OpenClaw內部原生能力。
如果你想要「OpenClaw內部自己拆任務、自己派工人」，用sub-agent；如果你想要「將任務交畀外部agent系統嚟執行」，用ACP。sub-agent係OpenClaw自己嘅內部員工，生命週期、上下文、權限、調度都由OpenClaw內部控制；ACP外部harness係外判接口/協議適配層，有自己一套執行方式、會話模型、工具能力。
最後，幾個好容易中招嘅陷阱
陷阱1：將workspace當成強沙箱
官方文檔明確提醒：workspace係默認cwd，唔係硬沙箱。
如果你需要真正隔離，要睇sandbox配置，而唔係誤以為「唔同workspace就自然安全隔離」。
陷阱2：一開始就拆太多長期agent
呢個通常會令系統提早碎片化。更穩陣嘅路線通常係：
1. 先主agent 2. 再用sub-agent處理複雜任務 3. 當某類任務長期穩定之後，再升級做獨立長期agent
少即是多。簡單至上策。
以上，如果覺得有幫助，歡迎三連。歡迎星標，第一時間收到我嘅實戰分享。下次見。
參考官方文檔
• Multi-Agent Routing
https://docs.openclaw.ai/concepts/multi-agent• Agent Workspace
https://docs.openclaw.ai/concepts/agent-workspace• Slash Commands
https://docs.openclaw.ai/tools/slash-commands• CLI: agents
https://docs.openclaw.ai/cli/agents• ACP Agents
https://docs.openclaw.ai/tools/acp-agents
越來越多人開始搭建多Agent系統，也看到sub-agent的用法，困惑於：
• 要不要直接配多個長期 agent？ • 還是保留一個主 agent，再用 sub-agent 做任務拆解？ • 這兩種模式到底差在哪？ • 哪種更適合個人使用，哪種更適合長期體系化？
這篇文章結合 OpenClaw 官方文檔來分享：
1. Multi-Agent 到底是什麼 2. 主 agent + sub-agent 到底是什麼 3. 實際該怎麼選、怎麼落地
先給結論：
Multi-Agent 解決的是“長期分工與隔離”。
主 agent + sub-agent 解決的是“任務拆解與調度”。
如果把這兩個問題分清，很多架構選擇就不難了。
一、Multi-Agent：多個獨立 Agent
OpenClaw 官方文檔對 agent 的定義非常明確：一個 agent 不是一句 prompt，也不是一個會話皮膚，而是一個完整隔離的大腦。它有自己的：
• workspace • agentDir• auth profiles • session store • persona / SOUL / AGENTS 規則 • skills
一個 agent 是 fully scoped brain。
它有獨立的 workspace、狀態目錄、認證和會話存儲。
也就是說，多 agent 並不是“一個 agent 換幾套 prompt”，而是多個獨立工作單元並存。
按官方文檔，Multi-Agent Routing 的目標是：
• 在一個 Gateway 進程裏，運行多個隔離 agent • 每個 agent 有獨立 workspace + auth + sessions • 通過 bindings，把不同入口的消息路由到不同 agent
關於路由，很多人不理解。路由的意思就是十字路口、分發規則：把一條消息分配給哪個 agent 來處理。可以把 OpenClaw 想成一個總機。消息進來之後，它先不急着回答，而是先判斷：這條消息來自哪裏、是誰發的、在哪個羣/私聊/線程裏、應該交給哪個 agent，這一步判斷過程，就叫 routing。
• 可以按 channel 路由，比如飛書來的交給 work-agent，Telegram 來的交給 personal-agent； • 可以按 accountId 路由，同一個平台裏，你可以接多個賬號，例如兩個飛書 bot，不同 bot 收到的消息交給不同 agent； • 可以按 peer / group / DM / guild / thread 路由，也就是說按聊天對象或聊天場景分流：peer：某個具體的人；group：某個具體羣；DM：私聊這種會話形態，相對於羣聊而言；guild：服務器/組織空間，常見於 Discord 一類；thread：某個具體討論串（同一個平台、同一個賬號下，不同聊天上下文還能繼續分配給不同 agent）； • 綁定規則是 deterministic，且 most-specific wins。意思是路由結果是確定的，不會一會兒這樣一會兒那樣，同樣的輸入條件，永遠命中同一條規則；當規則衝突時，更具體的那條優先，例如你同時配了：“所有飛書消息 -> agent A”、“飛書裏某個羣 -> agent B”，那麼這個羣裏的消息會走 agent B，因為“某個羣”比“所有飛書消息”更具體。
實用Tips: OpenClaw 可以把不同來源的消息，自動送進不同 agent。 比如：飛書接文檔處理agent、discord接運營agent...或者飛書裏創建多個不同的羣，分別對應不同的agent，這是更常用的做法，畢竟我們常用的 IM 只有一兩個。
二、主 agent + sub-agent：一個總控 + 多個任務執行器
OpenClaw 裏對 sub-agent 的定位，和多 agent 很不一樣。在 slash commands（TUI中的斜槓命令）裏，官方支持：
• /subagents list|kill|log|info|send|steer|spawn
在 ACP 文檔裏，官方還專門對比了：
• ACP session • OpenClaw native sub-agent run
這說明 sub-agent 不是“長期存在的 agent”，而是：
由當前會話拉起的 delegated run（臨時委派辦個事）。
• 主 agent：總控、接需求、做判斷 • sub-agent：臨時被拉起來去幹一件具體的事
典型工作方式是：
1. 主 agent 接收用戶需求 2. 判斷這件事是否適合拆分 3. 拉起一個或多個 sub-agent 4. sub-agent 各自執行 5. 主 agent 回收結果並彙總
所以 sub-agent 更像：
• 臨時工 • 分包線程 • 並行執行單元 • 一次性委託執行器
而不是長期角色。
三、最核心的區別：組織方式不同
很多人誤以為：
• 多 agent = 多個 agent • 主 + sub-agent = 也是多個 agent
只是叫法不同。
其實不是。
官方文檔能看出來，這兩者在設計目的上就不同。
1）Multi-Agent 是“組織結構”
它強調：
• 獨立 workspace • 獨立 auth • 獨立 sessions • 獨立 identity • 獨立 routing
所以 Multi-Agent 更像：
你在一台 OpenClaw 裏養了多個長期崗位。
它解決的是：
• 誰負責哪類事 • 誰接收哪個入口的消息 • 誰用什麼模型與權限 • 誰該跟誰隔離
2）主 agent + sub-agent 是“任務編排”
它強調：
• 委派 • 並行 • 臨時運行 • 當前會話內調度 • 執行完再回收
所以它更像：
一個項目經理，臨時叫幾個人去做子任務。
它解決的是：
• 一個複雜任務怎麼拆 • 哪些事適合並行做 • 主會話如何保持清爽 • 重活怎麼外包出去跑
四、Multi-Agent 的優勢與代價
優勢 1：長期邊界清晰
Multi-Agent 最強的一點，就是邊界清晰，很適合長期分工。比如：
• 寫作 agent 永遠只處理內容 • 運維 agent 永遠只處理系統 • 某個 agent 只服務某個 Telegram 賬號 • 某個 agent 只綁定某個 Discord bot
這就是結構化隔離。
優勢 2：入口可直接路由
你可以直接把入口級流量路由給不同 agent，而不是所有消息都先流經一個總控再分發。這很適合：
• 多個賬號 • 多個 bot • 多個團隊 • 多個角色 • 多個頻道/羣聊
優勢 3：適合權限和認證分離
官方文檔反覆強調 auth 是 per-agent 的，不自動共享。這對長期生產環境特別重要。因為這意味着你可以做到：
• A agent 用這套 auth • B agent 用另一套 auth • 不同 agent 的模型、密鑰、服務邊界天然分開
代價 1：配置和維護成本更高
你要維護的東西會明顯增加：
• agent 列表 • workspace • identity • bindings • accountId • auth 複製或隔離 • 會話歸屬
如果你拆得太細，很容易出現：
• 自己都記不住誰幹什麼 • agent 太多導致碎片化 • 調試和維護變複雜
代價 2：不適合一開始就過度設計
如果你當前其實還只有一個穩定入口、一個主要使用者、一個主要任務類型，那一下子上很多長期 agent，通常會過度設計。
五、主 agent + sub-agent 的優勢與代價
這套模式的優點，主要來自“靈活”。
優勢 1：先不用設計一整套組織結構
你可以先只有一個主 agent。等遇到複雜任務時，再決定：
• 要不要 spawn sub-agent • 要不要並行 • 要不要長時間後台執行
這比一開始就配很多長期 agent 輕得多。
優勢 2：複雜任務更容易拆解
比如你要做一篇複雜內容：
• 子代理 A：查資料 • 子代理 B：整理結構 • 子代理 C：校對和反查
主 agent 只負責：
• 理解目標 • 分配任務 • 最終彙總
這類模式特別適合：
• 研究 • 批量整理 • 重型執行任務 • 長上下文拆解 • 並行處理
優勢 3：主對話體驗更統一
對於用戶來說，入口通常只有一個。
這意味着體驗上更自然：
• 你永遠只是在跟一個主 agent 說話 • 複雜性都被隱藏在後面
代價 1：主 agent 會變成總控中心
所有任務都先進主 agent，再分發給 sub-agent。
這會導致：
• 主 agent 變成單點中樞 • 複雜任務多時，調度邏輯容易變重
代價 2：不天然適合長期角色分工
sub-agent 的強項是執行，不是長期身份。如果你把所有長期角色都硬塞成 sub-agent，最後會比較彆扭。因為：
• 它們不是入口級角色 • 不是天然長期駐場 • 不適合承接多渠道長期綁定
六、官方文檔推薦：到底該選哪種？
適合優先 Multi-Agent 的情況
如果你符合下面這些特徵，優先多 agent：
1）你有多個長期角色
比如：
• writer • ops • research • assistant
2）你需要不同 workspace
官方文檔明確說 workspace 是 agent 的 home。所以當不同角色需要長期維護自己的文件、記憶、persona 和技能時，天然適合拆 agent。
3）你需要不同入口直接進不同 agent
比如：
• 某個 Telegram 賬號永遠進 writer • 某個 Discord bot 永遠進 coding • 某些 WhatsApp DM 永遠進某個 agent
4）你需要認證與權限隔離
不同 agent 各自持有不同 auth profiles，這就是多 agent 的強項。
適合優先主 agent + sub-agent 的情況
如果你更像下面這樣，優先主 + sub：
1）你目前主要只有一個統一入口
比如你主要就自己在 TUI 裏用，或者一個主聊天入口。
2）你更多是複雜任務拆解，而不是長期角色拆分
比如：
• 研究任務拆成幾路並行 • 寫作任務拆成資料/提綱/校對 • 編碼任務拆成檢查/修改/驗證
3）你暫時不想維護很多長期 agent
這種情況下，sub-agent 的靈活性更好。
4）你更想保留一個統一對話體驗
也就是永遠跟一個主 agent 交流，後面的複雜性由它內部消化。
另外，我曾經想過，什麼場景下非要使用多個 sub-agent，用一個 agent 不夠嗎？因為“一個 agent 全包”在簡單任務裏可以，但任務一複雜，就會同時出現四個問題：上下文混亂、步驟互相干擾、速度慢、結果不穩。一個 agent 全做時，常見情況是：一邊讓它查資料，一邊搭結構，一邊改措辭，目標容易漂移；不同子任務共用同一上下文，垃圾信息越堆越多，前面查到的弱結論，會污染後面的寫作和判斷；所有事串行做，慢。以及很難局部重跑，例如“只重做校對，不重做檢索”。而拆成多個子 agent 後，每個只做一件事，會更穩：
• 查資料 agent：只負責蒐集和篩選信息，優化目標是覆蓋率和證據質量； • 結構 agent：不被檢索噪音干擾，只負責組織邏輯； • 校對/反查 agent：站在“審核者”視角，專門挑漏洞，而不是順着原答案一路往下寫。
實操下來，多 sub-agent 真得很好用。
• Multi-Agent 負責長期隔離與路由 • sub-agent 負責當前任務的拆解與執行
一個很實用的搭法是：
長期層
• main：總控 / 默認入口• writer：內容創作• ops：系統與運維
執行層
在 writer 或 ops 內部，需要做重活時，再拉 sub-agent。例如：
writer 內部
• sub-agent A：蒐集資料 • sub-agent B：整理提綱 • sub-agent C：做事實核查
ops 內部
• sub-agent A：查日誌 • sub-agent B：做配置對比 • sub-agent C：生成修復建議
這通常比“純多 agent”或“純主+sub”都更實用。
七、實操
路線 A：Multi-Agent
第一步：先加長期 agent
openclaw agents add writer
openclaw agents add ops第二步：看綁定情況
openclaw agents list --bindings
openclaw agents bindings第三步：把入口綁給對應 agent
openclaw agents bind --agent writer --bind telegram:writer
openclaw agents bind --agent ops --bind discord:ops第四步：給各自 workspace 補齊人格和規則
每個 agent 的 workspace 裏都應該有自己的：
• AGENTS.md• SOUL.md• USER.md• IDENTITY.md
這是官方 workspace 文檔裏最值得重視的部分。
第五步：重啓並驗證
openclaw gateway restart
openclaw channels status --probe
openclaw agents list --bindings路線 B：主 agent + sub-agent
第一步：先保留一個主 agent
也就是先不要拆太多長期 agent。
第二步：在複雜任務裏使用 sub-agent 命令
TUI 裏官方支持：
• /subagents list• /subagents spawn• /subagents steer• /subagents kill
這意味着你可以先從任務拆解入手，而不是先做大規模組織設計。
第三步：區分是否用 ACP 外部 harness
• ACP session：是通過 ACP 這個協議去對接外部 agent/harness，比如接 Codex、Claude Code、Gemini CLI，這時 OpenClaw 不再只是內部自轉，而是在跟外部執行器通信； • OpenClaw native sub-agent runtime：是 OpenClaw 自己內部的“子代理執行機制”，主 agent 在當前會話裏臨時委派一個子任務給另一個執行單元，這是 OpenClaw 內部原生能力。
如果你要“OpenClaw 內部自己拆任務、自己派工人”，用 sub-agent；如果你要“把任務交給外部 agent 系統來跑”，用 ACP。sub-agent 是 OpenClaw 自己家的內部員工，生命週期、上下文、權限、調度都由 OpenClaw 內部控制；ACP 外部 harness 是外包接口 / 協議適配層，有自己的一套運行方式、會話模型、工具能力。
最後，幾個很容易踩的坑
坑 1：把 workspace 當成強沙箱
官方文檔明確提醒：workspace 是默認 cwd，不是硬沙箱。
如果你需要真正隔離，要看 sandbox 配置，而不是誤以為“不同 workspace 就天然安全隔離”。
坑 2：一開始就拆太多長期 agent
這通常會讓系統提前碎片化。更穩的路線一般是：
1. 先主 agent 2. 再用 sub-agent 處理複雜任務 3. 當某類任務長期穩定後，再升級成獨立長期 agent
少即是多。簡單為上策。
以上，如果覺得有幫助，歡迎三連。歡迎星標，第一時間收到我的實操分享。下次見。
參考官方文檔
• Multi-Agent Routing
https://docs.openclaw.ai/concepts/multi-agent• Agent Workspace
https://docs.openclaw.ai/concepts/agent-workspace• Slash Commands
https://docs.openclaw.ai/tools/slash-commands• CLI: agents
https://docs.openclaw.ai/cli/agents• ACP Agents
https://docs.openclaw.ai/tools/acp-agents