OpenClaw 在年初公開後，社群裡常見的下一個問題是：「多 agent 真的有差嗎？拆開不是更難管嗎？」
下面整理一個實戰多 agent 架構：Opus 做策略、Sonnet 跑苦力、Codex 寫程式碼。包含分工邏輯、記憶共享、排程協作、踩坑紀錄。
為什麼一個不夠
一開始只有一個 agent，什麼都叫它做：寫文章、改 code、排程、掃新聞，全部塞在同一個 Claude Code session 裡。
跑一段時間後問題會出現：寫文章很好但改 code 偶爾出 bug，改完 code 再回來寫文章又忘了之前的語氣設定。
舉個實際發生的事：叫 Opus 改 cron/jobs.json 裡的一個時間欄位。它改了，但同時把另一個 JSON key 的引號格式弄壞了。排程那天晚上全部沒跑。
換成 Codex 來做同一件事，它改完格式一個字都不會多動。但叫 Codex 寫社群文案，出來的東西像在讀 README。
Sonnet 跑批次任務又快又便宜，但讓它決定文章標題，它選了 SEO 分數最高的那個，語氣完全不對。
一個 agent 做所有事，品質在角色切換之間會掉。拆開來之後，每個只做最穩的那件事，出錯率明顯下降。
四個 Agent 的分工
Opus：策略大腦
Opus 是整個系統的核心決策者。
它負責的事：
- 內容策略和文章寫作
- 記憶系統管理（決定什麼要記、什麼要忘）
- 跨 agent 協調（判斷任務該分給誰）
- 品質審核（Codex 寫完的 code、Sonnet 跑完的結果，Opus 來 review）
有一條硬規則：Opus 不直接改程式碼。Opus 偶爾改 code 會出問題，但做 code review 卻非常好。讓它看、讓它判斷、不讓它動手，手交給 Codex。
Opus 的 session 通常最長，因為策略類的對話需要大量上下文。它會讀最多的記憶檔案，專案檔案、MEMORY.md、當天的 journal 加起來，是其他 agent 的兩三倍。
Sonnet：快速執行
Sonnet 做的是不需要判斷力的事。判斷標準很簡單：能寫出 SOP 讓實習生照著做的任務，就給 Sonnet。
它的工作清單：
- 抓影片截圖和轉檔
- 批次格式化資料
- 範本化的社群貼文初稿
- 固定格式的資料整理
Sonnet 的優勢是速度快、token 成本低。一個 Opus 的價錢可以跑好幾個 Sonnet 任務。對於量大但不需要創造力的工作，成本差異很明顯。
踩過的坑：把需要判斷力的任務交給 Sonnet，結果它很認真地執行了一個錯誤的方向，後續花更多時間在修正上。穩定的原則是：要先想一下才能決定怎麼做的事，就不適合 Sonnet。
Codex：程式碼專家
所有 code 相關的工作走 Codex：功能開發、bug 修復、測試撰寫、重構。
模型版本固定用 ChatGPT 最新版。Codex 低版本的 code 品質不穩，這是血淚教訓。
Codex 的特點是很精準但不會主動想。給它明確的 spec，它寫出來的 code 品質很高；給它一個模糊的需求，它可能會選一個不想要的實作方式。所以 Opus 會先把需求寫清楚，再 handoff 給 Codex。
工作流程：Opus 做技術 planning，寫好 spec → Codex 實作 → Opus 或 Sonnet 做 code review。這個三步流程把 bug 率壓了下來。
記憶共享怎麼設定
4 個 agent 讀同一個 .openclaw/ 目錄，不需要額外串接。MEMORY.md 是共同索引，brain.md 是共同工作記憶。
要做的就是在 AGENTS.md 裡寫清楚每個 agent 的寫入範圍：
| Agent | 可讀 | 可寫 |
|---|---|---|
| Opus | 全部 | 記憶檔、策略檔、brain.md |
| Sonnet | 任務相關 | 任務輸出檔 |
| Codex | 程式碼 + spec | 程式碼檔案 |
為什麼要分？兩個 agent 同時改 brain.md，會改出衝突版本，後續手動合併花一小時都不奇怪。穩定的做法是只讓 Opus 寫 brain.md，其他 agent 只讀不寫。
排程協作
排程任務也有分工。
以每天的社群內容產出為例：
- 早上 6:00：Opus 讀新聞摘要，決定今天的社群主題
- 早上 7:00：Sonnet 根據 Opus 選好的主題，套範本生成初稿
- 早上 8:00：Opus 審核初稿，修改語氣和內容
- 排定時間：Buffer 安排社群發布
這個流程每天自動跑。只在審核階段偶爾介入，大部分時候 Opus 自己判斷就能過。
排程之間的依賴關係用 cron 的時間差來控制。7:00 的任務假設 6:00 的結果已經寫好了。如果 6:00 的任務延遲或失敗，7:00 那個也會出問題。
可以加一個 health check 排程，專門檢查前一個任務有沒有正常完成。這個機制能避免半夜排程爆掉、隔天才發現的窘境。
踩過的坑
坑 1：讓 Opus 直接改 Code
Opus 的 code review 能力很好，但直接動手偶爾會搞壞格式或邏輯。不是想太久就是來回改，自從分開工作之後，code 品質明顯穩定。（我認為 Opus 是有寫 code 能力，但如果同時決策又寫 code，出錯率會比較高）
坑 2：共享記憶沒有分權
兩個 agent 同時寫同一個檔案，改出衝突。解法就是上面那張寫入權限表。
坑 3：Sonnet 做了不該做的決策
讓 Sonnet 決定一篇文章的標題，它選了一個 SEO 分數最高但語氣完全不對的標題。從那之後，需要品味和判斷的事一律 Opus。
坑 4：Handoff 檔案太分散
一開始讓每個專案都有自己的 handoff 檔案。結果 Opus 要讀五六個地方才知道有什麼新任務。統一成一個 projects/handoff.md 之後，流程順很多。
怎麼從一個 Agent 開始
擴充路線建議：
第一步：Opus + Codex。最有感的分工。策略歸策略、程式歸程式。光這一步就能明顯感受到品質提升。
第二步：加 Sonnet。把 Opus 手上那些機械性的任務挑出來丟給 Sonnet，省 token、省時間。
每加一個 agent，先跑兩週確認穩定了再加下一個。急著全開只會花大量時間在處理系統問題上。
延伸閱讀
小企鵝的經驗
主力 stack 就是 OpenClaw 上的 Opus / Sonnet / Codex 三 agent，每天用這套管兩個品牌帳號、多個發布頻道、十幾個排程任務。實戰下來最有感的是 Opus 做 code review 比動手寫穩定太多，配 Codex 處理具體實作，分工很清楚。OpenClaw 不是適合所有人玩的工具，要確認自己有重複性的自動化任務再上，比較不會白工。
常見問題
Q: 為什麼需要多個 agent？一個不夠嗎？
一個也能用，但品質不穩定。寫文章用的模型跟寫程式用的模型，擅長的事差很多。拆開來讓每個 agent 做自己最強的事，整體品質會好很多。
Q: 多 agent 會不會很貴？
看怎麼分配。Opus 最貴但只用在策略和寫作，機械性任務交 Sonnet，成本低很多。實戰上月均費用大部分花在 Opus 的寫作上，Sonnet 佔比不高。
Q: agent 之間怎麼溝通？
靠檔案系統。agent 之間不會即時對話，而是透過共享的記憶檔案傳遞資訊。Opus 寫一個 handoff 檔案，Codex 讀到就知道要做什麼。簡單但有效。
Q: 4 個 agent 同時跑不會互相衝突嗎？
會。解法是分好寫入權限：每個 agent 只能寫自己負責的檔案範圍。Opus 寫策略和記憶，Codex 只動程式碼，不要讓兩個 agent 同時改同一個檔案。
Q: 我能不能只用 2 個 agent？
可以。建議從 Opus + Codex 開始，一個管策略一個管程式碼。確認運作穩定了，再考慮加 Sonnet。
Q: 怎麼知道一個任務該交給哪個 agent？
判斷原則：需要判斷力和創造力的交 Opus，純機械執行的交 Sonnet，跟程式碼有關的交 Codex。模糊地帶一律交 Opus，讓它自己判斷要不要再分派。
整理：Penna｜小企鵝 Penchan