35.7K Stars 嘅 oh-my-claudecode：Claude Code 多 Agent 編排深度實測

今年一月先喺 GitHub 開源，半年推咗 235 個 release、累積超過 37,000 粒星、120 位 contributor——oh-my-claudecode（OMC）嘅增長速度，唔係一般 open source project 做得到嘅。但真正令我留意佢嘅，唔係 star count，而係佢解決嘅問題：Claude Code 本身係一個好勁嘅單一 agent，但現實世界嘅軟件開發好少係一個人搞掂。你寫 code 嗰陣需要 architect 諗設計、需要 debugger 追 bug、需要 reviewer 睇質量、需要 QA 跑測試——正常 team 係咁運作，但 AI coding tool 一路以嚟都係「一個 agent 做晒」，結果就係寫到一半迷失方向、做漏野、或者產生大量垃圾 code。

OMC 嘅核心 insight 好簡單：與其逼一個萬能 agent 做晒所有野，不如學 human engineering team 嘅分工模式。佢哋將呢個叫做 “teams-first orchestration”。

唔係 plugin 咁簡單——係成個 orchestration layer

OMC 嘅特別之處，係佢唔係一個「加少少功能」嘅 plugin。佢係一個完整嘅 orchestration layer，建基於 Claude Code 嘅 hooks 同 plugin system 之上。成個架構分四層：Hooks 負責 detect 生命周期事件（你用咩 command、發生咩錯誤），Skills 注入行為（唔係換 agent，而係喺現有 agent 上面疊加能力），Agents 執行專業工作，State 跨 context reset 追蹤進度。

最關鍵嘅設計決策係點樣令 agent 之間溝通。OMC 冇自己整一套 protocol 或者 API——佢用 Claude Code 原生嘅 shell script hooks 做 agent 通訊。呢個決定好聰明：唔使違反 Anthropic 嘅 ToS、唔使搞複雜嘅 infrastructure、而且 Claude Code 每次更新都唔會 break 到佢。比起好多 AI orchestration framework 鍾意自己整一套 MCP protocol 或者 message bus，OMC 嘅 approach 明顯更 pragmatic——用最簡單可行嘅方式達到目的。

佢嘅 agent 分工都好仔細。32 個 agent 分做唔同 tier：explore、writer 呢啲簡單任務行 Haiku（快、平），executor、debugger、test-engineer 行 Sonnet（主流 coding 工作），architect、planner、critic 行 Opus（複雜 reasoning）。呢種 model routing 唔單止改善成本效益（慳 30-50% tokens），更重要嘅係確保每個 task 由最適合嘅 agent 處理，而唔係一刀切用最貴嘅 model。

Team mode 點樣改變開發 workflow

OMC 嘅 canonical orchestration surface 係 Team mode。佢嘅 pipeline 係：team-plan → team-prd → team-exec → team-verify → team-fix。睇落好似只係五個步驟，但實際運作上好大分別。

傳統嘅 AI coding workflow 係你出一句 prompt，AI 就開始寫 code。問題係佢寫完你發現方向錯咗，𢳂錢又𢳂時間。OMC 嘅 pipeline 強制咗一個紀律：先 plan（architect agent 做系統設計）、再寫 PRD（product requirements document）、先好 exec（executor agent 寫 code）、然後 verify（verifier agent 檢查）、最後 fix。聽落好似多咗步驟好麻煩，但實際上對於複雜 task 係節省時間——因為你唔會再出現「寫咗 500 行 code 先發現根本 design 錯咗」嘅情況。

我特別欣賞佢哋嘅 “deep-interview” workflow。當需求唔清晰嘅時候，analyst agent 會好似一個 senior engineer 咁追問你問題，直至需求夠 concrete 先開始做。呢個機制唔係得啖笑——好多 AI coding tool 嘅問題就係佢哋唔會 ask for clarification，一味靠估，結果 output 永遠差少少。OMC 呢個設計逼佢哋「唔明就問」，反而大幅提高 deliverable 嘅準確度。

成本控制同 execution modes：幾時用咩 mode 好重要

OMC 提供咗成 8 種 execution mode，但其實最常用嘅得幾個。除咗 Team mode 之外，Ultrawork 係 burst parallel fix/refactor 專用——對於「成個 project 要改一個 pattern」呢類 task 特別有效，因為佢可以同時 spawn 幾個 agent 做唔同 file 嘅改動。Ralph mode 係 persistent verify/fix loop，適合啲一定要完全搞掂嘅 task（唔會 silent partial completion）。Ecomode 就係 token-efficient routing，適合 budget-conscious 嘅 iteration。

成本方面，佢嘅 smart model routing 確實 work。簡單嘅 codebase exploration 用 Haiku，每條 query 唔使 1 仙美金；複雜嘅 architecture design 先用 Opus。佢仲有個 learning mechanism 會自動 extract 同 reuse 之前解決過嘅 problem-solving pattern——呢個對於長期用嘅 project 特別有用，因為 OMC 會愈用愈了解你個 codebase。

不過要講返缺點。OMC 呢半年嘅 breaking changes 都算多——由初期嘅 MCP integration 轉去 tmux-based worker model，autoresearch 被 deprecate，swarm keyword 成個被 team 取代。對於追求 stability 嘅 production team 嚟講，呢啲變動係有痛嘅。另一個問題係佢太依賴 Claude Code 嘅 experimental feature（例如 agent teams 要靠 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1），如果 Anthropic 改咗呢啲 experimental API，OMC 隨時要跟住改。

作為 indie developer，我揀唔揀佢？

如果你係做 small project、single-file edit、或者 prototyping，OMC 係 overkill。一個 Claude Code 原生 session 已經夠用。但如果你係做 multi-file feature、有複雜嘅 business logic、或者需要 consistent code quality，OMC 嘅 team pipeline 同自動 delegate 真係慳到時間。

對於香港嘅 indie developer 嚟講，OMC 嘅價值尤其明顯——我哋冇咁多資源請成個 engineering team，但 OMC 用 32 個 AI agent 模擬咗一個 team 嘅運作。當然佢唔係真正嘅 senior engineer，佢唔會同你傾 business requirement、唔會同 stakeholder 開會。但對於 coding execution 層面嘅嘢——寫 code、refactor、寫 test、debug——OMC 做到嘅嘢已經遠超一個 single AI agent。

如果你打算試，建議直接從 Team mode 開始，用 /team ... 嘅自然語言 interface，唔使記 command。記住一個原則：簡單 task 用簡單 mode（Autopilot 已經夠），複雜 task 先用 Team。咁樣平衡到成本同 productivity。