OMC 實戰：19 個 Agent 打造更智能、更可靠、更高效的 Claude Code 工作流

作者：術哥無界

日期：2026年5月21日上午8:30

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

oh-my-claudecode (OMC) 通過四層編排架構，將 Claude Code 從手動指揮單 Agent 升級為自動協調 19 個 Agent 嘅多 Agent 工作流

整理版摘要

呢篇文章出自術哥（Shuge），一位專注 AI 編程同 Agent Skills 嘅技術實踐者。佢基於 oh-my-claudecode（OMC）源碼同 Anthropic 官方文檔，整理出呢套系統嘅核心邏輯。作者想解決嘅問題係：當任務複雜到需要多文件重構、批量修復或者端到端自動化流程時，Claude Code 原生嘅單 Agent 模式顯得好狼狽，每次都要手動拆 prompt、重新交代上下文，效率好低。

文章嘅整體結論係：OMC 通過 Hooks → Skills → Agents → State 四層架構，喺 Claude Code 基礎上搭建咗一套自動編排系統，將手動指揮一個 Agent 變成自動協調 19 個專業 Agent。呢套系統嘅設計紮實，19 個 Agent 按泳道分工明確，三層模型路由喺成本同質量之間做到合理平衡，State 系統嘅 notepad 抗壓縮機制解決咗一個實際痛點。

不過文章都指出，OMC 更適合已經在用 Claude Code、對多 Agent 協作有實際需求嘅開發者；如果日常任務簡單，就可能覺得太重。建議從 autopilot 模式開始上手，再嘗試 team 同 ultrawork。

OMC 嘅核心係四層編排：Hooks（零上下文成本嘅事件攔截）→ Skills（行為注入）→ Agents（19 個專業 Agent 按泳道分工）→ State（進度追蹤同持久化）。
佢嘅模型路由策略好實際：Haiku 做簡單任務、Sonnet 做實現調試、Opus 做架構設計，可以節省 30-50% token。
三種執行模式各有特色：autopilot 適合一句話端到端，ralph 適合嚴格驗證循環，ultrawork 適合最大並行批量修復。
與原生 Claude Code 相比，OMC 最大優勢係自動化解決多 Agent 協調、上下文管理同狀態持久化，但關鍵詞硬編碼限制咗自定義靈活性。
你可以從 autopilot 模式開始試用，用 /omc-setup 一鍵初始化，遇到問題跑 /omc-doctor 診斷，再逐步探索 ultrawork 同 team 模式。

值得記低

連結 github.com

OMC GitHub 倉庫

oh-my-claudecode 源碼倉庫，版本 v4.14.1，包含完整嘅 Hooks、Skills、Agents 實現。

流程

OMC 配置模板（JSONC）

雙層配置：用戶全局 ~/.config/claude-omc/config.jsonc 同項目 .claude/omc.jsonc。支援按 Agent 分配模型（explore: haiku, executor: sonnet, architect: opus）、功能開關（parallelExecution、lspTools、astTools）、路由策略（enabled、defaultTier、forceInherit）。

整理重點

點解要用 OMC？Claude Code 單 Agent 嘅限制

用 Claude Code 寫 code 嘅開發者，應該都試過呢啲情況：一個涉及 20 多個文件嘅重構任務，要手動拆成十幾次 prompt，每次重新交代上下文；調試跨模塊 Bug，單 Agent 來回翻檔案，效率仲差過自己開 IDE 搜；想自動跑完規劃→實現→測試→驗證嘅完整流程，結果每一步都要人工介入。

Anthropic 官方博客一句話講得清楚：能用單次調用解決就不要用 Workflow，能用 Workflow 就不要上 Agent。

Claude Code 原生嘅單 Agent 模式每次都要手動拆 prompt、重新交代上下文，效率好低。

但當任務真係複雜到需要多 Agent 協作時，原生嘅單 Agent 模式就捉襟見肘喇。OMC 就係喺呢個邊界上做文章——佢透過 Hooks → Skills → Agents → State 四層架構，將 Claude Code 從手動指揮一個 Agent 升級為自動協調 19 個專業 Agent。

整理重點

四層架構點樣運作：Hooks、Skills、Agents、State

OMC 嘅核心唔係堆功能數量，而係喺四個系統之間建立一條清晰嘅管線：用戶輸入 → Hooks（事件檢測）→ Skills（行為注入）→ Agents（任務執行）→ State（進度追蹤）。成個過程喺 Agent 循環外完成，零上下文消耗。

Hooks 喺 Agent 循環外運行，唔佔用上下文窗口，係個被嚴重低估嘅能力。

notepad.md 抗上下文壓縮，係 State 層嘅核心設計。

1 Hooks 層：20 個 Hook 腳本攔截 11 個生命週期事件，例如 keyword-detector 檢測魔法關鍵詞，persistent-mode 阻止 ralph 模式提前停止，pre-compact 壓縮前保存 notepad。
2 Skills 層：31 個 Skill 按三層組合：執行 Skill + 0-N 個增強 Skill + 可選保證層。例如 default + git-master 做普通開發帶自動提交，autopilot + ralph 做強力端到端。
3 Agents 層：19 個專業 Agent 分四個泳道——Build/Analysis（explore、analyst、planner 等）、Review（security-reviewer、code-reviewer）、Domain（test-engineer、designer 等）、Coordination（critic 做差距分析）。
4 State 層：.omc/ 目錄下存放狀態文件、執行計劃、知識便箋同日誌。notepad.md 抗壓縮，project-memory.json 跨會話持久化。

模型路由策略好實際：Haiku 做簡單任務（explore、writer），Sonnet 做實現調試（executor、debugger），Opus 做架構設計（architect、planner、critic），可以節省 30-50% token。

温度參數嘅區分好有講究：ultrabrain 用 0.3 保證推理確定性，artistry 用 0.9 鼓勵創意發散。

critic 角色專門喺執行前挑毛病，相當於內置紅藍對抗機制。

整理重點

三個高頻工程場景實戰

OMC 提供三種核心執行模式，分別對應唔同場景。以下從簡到繁，畀你具體命令同交互流程。

場景一：遺留代碼重構（autopilot / ralph 模式）。autopilot: refactor the auth module, improve error handling and add input validation — 一句話觸發五階段管線：Explore → Analysis → Planning → Execution → Verification。ralph 模式更嚴格，循環直到所有測試同 lint 通過，背後係 persistent-mode Hook 阻止提前停止。
場景二：批量修復（ultrawork 模式）。ultrawork fix all TypeScript errors in the project — 同時啟動多個 executor Agent 並行修復，subagent-tracker Hook 追蹤每個 Agent 狀態，完成後彙總結果。可以結合 deepsearch 先搜再修。
場景三：多模塊 Bug 修復（team 模式）。/team 3:executor "fix the payment timeout bug affecting checkout flow" — 啟動 3 個 executor Agent，透過共享任務列表同訊息系統協作，Leader Agent 負責協調。仲可以混合 Claude、Codex、Gemini 三個模型一齊做。

subagent-tracker Hook 喺後台追蹤每個 Agent 嘅狀態，完成後彙總結果。

Team 模式嘅每個 Agent 有獨立嘅上下文窗口，Leader Agent 負責協調同選擇性共享資訊。

team 模式需要啓用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS，係 Anthropic 嘅實驗性功能，唔啓用就用唔到 /team 命令。

魔法關鍵詞 autopilot、ralph、ccg 係硬編碼嘅，唔可以通過配置文件修改；自定義觸發詞只支援 ultrawork、search、analyze、ultrathink 幾類，可喺 omc.jsonc 嘅 magicKeywords 字段配置。

整理重點

點樣揀執行模式同實用建議

日常開發由 autopilot 開始上手，需要並行處理用 ultrawork，複雜多模塊任務上 team，有嚴格完成標準嘅用 ralph。以下係常用命令速查。

常用命令速查 bash

# 自動執行
autopilot: build a REST API with authentication
# 持久執行（不完成不停止）
ralph: refactor the auth module
# 並行執行
ultrawork fix all TypeScript errors
# 多 Agent 協作
/team 3:executor "implement todo app"
# 三模型協作
ccg: review this PR
# 深度搜索
deepsearch find all database queries without indexes
# 深度推理
ultrathink about the best caching strategy for this API
# 取消活躍模式
stop

/skillify 命令可以將會話中嘅解決方案提取成可複用嘅 Skill 檔案，分項目級同用戶級。

/deep-interview 用蘇格拉底式問答幫你澄清需求，適合動手前諗清楚。

🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃第 118 篇，AI 編程最佳實戰「2026」系列第 36 篇
大家好，歡迎嚟到 術哥無界 | ShugeX ｜運維有術。
我是術哥，一個專門搞 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫嘅技術實踐者同開源佈道者！

Talk is cheap, let's explore。無界探索，有術而行。

圖 1：oh-my-claudecode 核心架構概覽

用 Claude Code 寫 Code 嘅開發者，大概都遇過呢幾個情況：一個涉及成 20 幾個文件嘅重構任務，要手動拆成十幾次提示，每次都要重新交代上下文；除錯一個跨模塊嘅 Bug，單 Agent 來來回回睇文件，效率仲衰過自己開 IDE 搜；想叫 Claude Code 自動跑完規劃→實現→測試→驗證嘅成個流程，點知每一步都要人手介入。

呢啲問題嘅根源唔係 Claude Code 能力唔得。Anthropic 官方博客有一句話講得好清楚：用得着單次調用解決就唔好用 Workflow，用得着 Workflow 就唔好用 Agent。 反轉嚟睇，當任務複雜到真係需要多 Agent 協作嗰陣，原生嘅單 Agent 模式就唔夠用喇。

oh-my-claudecode（簡稱 OMC）就係喺呢個邊界上做文章。佢透過 Hooks → Skills → Agents → State 四層架構，將 Claude Code 由手動叫一個 Agent 做嘢 升級為自動協調 19 個專業 Agent。睇勻官方文檔同源碼之後，我將呢套系統嘅核心邏輯整理成呢篇文章——由底層機制到架構設計，再到三個高頻場景嘅實戰演示。

說明：本文內容係根據 oh-my-claudecode（Yeachan-Heo/oh-my-claudecode）源碼（v4.14.1）同 Anthropic 官方文檔分析整理出嚟，源碼分析係基於我本地倉庫版本，未喺生產環境完成曬所有場景嘅驗證。文入面嘅配置模板同參數建議只係參考，實際效果請以你嘅業務數據同環境測試結果為準。如果有實際使用經驗，歡迎喺評論區分享交流。

1. Claude Code 嘅底層運行機制

圖 2：Claude Code 四層架構

要理解 OMC 做咗啲乜，首先要搞清楚 Claude Code 本身係點樣運作嘅。

Agentic 工作流

Claude Code 採用工具強化嘅 Agent 架構，核心係一個多輪推理循環：思考 → 調用工具 → 處理結果 → 繼續思考。每一輪循環入面，模型會根據當前上下文決定係繼續調用工具定係直接輸出結果。

根據 CSDN 上面嘅架構分析文章（整理自 Anthropic 官方博客），成個系統分四層：用戶界面層（CLI/IDE）→ Claude Code Core（會話管理、權限控制、上下文管理）→ Agent Loop（多輪推理循環）→ LLM 模型層 + 工具系統。

工具系統又分兩部分：本地工具（Read/Write/Bash/Grep 等）同 MCP Servers（Context7、Lark Doc 等外部工具伺服器）。模型喺每一輪循環入面可以揀調用邊個工具，Claude Code Core 負責權限檢查同工具調度。

簡單任務用單 Agent 模式，一次對話搞掂。複雜任務嘅時候，主 Agent 可以生啲子 Agent 出嚟並行處理——呢個就係 Anthropic 喺 2026 年 2 月推出嘅實驗性功能 Agent Teams，採用星形拓撲結構（Star Topology），Leader Agent 協調多個 Expert Agent。

但呢度有個關鍵限制：派生係要手動做嘅。你要自己同 Claude Code 講用子 Agent 做某個任務，而且每個子 Agent 嘅模型、職責、上下文都要自己管。更唔好講子 Agent 之間嘅協調、狀態追蹤、錯誤恢復——呢啲全部靠人肉。

Hooks：零上下文成本嘅自動化

Hooks 係 Claude Code 一個俾人嚴重低估嘅能力。騰訊雲開發者社區有篇文章講得好到位：Hooks 喺 Agent 循環外之外運行，唔會佔用上下文窗口。

呢個代表咩？你可以唔消耗任何 token 嘅情況下，令系統自動回應生命週期事件。例如文件保存之後自動行 linter、危險命令執行之前攔截、任務完成嗰陣發 Slack 通知。呢啲操作完全繞過咗 Agent Loop，唔會霸住本來就緊張嘅上下文空間。

Claude Code 原生支援 11-13 個 Hook 生命週期事件，覆蓋由 SessionStart（會話開始）到 PreToolUse/PostToolUse（工具使用前後）再到 Stop（Agent 就快停）同 SessionEnd（會話結束）嘅完整鏈路。每個事件都有對應嘅 JSON 有效負載，帶埋上下文資訊俾 Hook 腳本用。

OMC 正正係基於呢套 Hook 機制，整咗 20 個 Hook 腳本攔截呢啲生命週期事件，實現咗智能路由同自動化編排。之後會詳細講。

配置體系

Claude Code 嘅設定檔分三層：

項目級CLAUDE.md — 透過 /init 產生，放喺項目根目錄，建議加入版本控制
個人級CLAUDE.local.md — 個人定製設定，加入 .gitignore
全局級~/.claude/CLAUDE.md — 對所有項目生效

疊加順序：項目級 > 父目錄 > 子目錄 > 全域。Anthropic 官方仲提供咗工具許可管理嘅四種方式：會話入面永遠允許、/permissions 命令、編輯 settings.json、--allowedTools CLI 標誌。

呢套多層配置同靈活嘅權限管理，為 OMC 嘅雙層配置同 Agent 委派系統打咗基礎。

2. OMC 嘅架構設計

圖 3：OMC 四大系統互聯流程

OMC 嘅核心唔係鬥多功能，而係喺四個系統之間建立咗一條清晰嘅管線：

用戶輸入 → Hooks（事件檢測）→ Skills（行為注入）→ Agents（任務執行）→ State（進度追蹤）

四大系統各司其職

Hooks 層係入口。OMC 嘅 20 個 Hook 腳本攔截 Claude Code 嘅 11 個生命週期事件。幾個關鍵 Hook 嘅職責：

Hook	觸發事件	做咗啲乜
`keyword-detector`	`UserPromptSubmit`	偵測魔法關鍵詞，激活對應 Skill
`persistent-mode`	`Stop`	ralph/ultrawork 活躍嗰陣阻止提早停止
`pre-compact`	`PreCompact`	壓縮上下文前儲存關鍵資訊到 notepad
`subagent-tracker`	`SubagentStart` /`SubagentStop`	追蹤運行中嘅 Agent 狀態

成個過程喺 Agent 循環之外完成，零上下文消耗。你輸入 ultrawork fix the API，keyword-detector 偵測到關鍵詞之後自動激活 ultrawork Skill，然後 Skills 層接管決定執行策略。

Skills 層決定怎麼做。31 個 Skill（28 個用戶可以叫 + 3 個內部管線）按三層組合：

[執行 Skill] + [0-N 個增強技能] + [可選保證層]

執行層負責主任務（default、orchestrate、planner），增強層疊加能力（ultrawork 並行、git-master 自動提交、frontend-ui-ux 前端增強），保證層確保完成（ralph 唔驗證完唔停）。呢個組合公式嘅設計好靈活——你可以用 default + git-master 做普通開發兼自動提交，亦可以用 autopilot + ralph 做強力端到端。

Agents 層決定誰來做。19 個專業 Agent 分四個泳道：

泳道	Agent	職責	預設模型
Build/Analysis	`explore`	探索程式碼庫、建立文件/符號映射	haiku
	`analyst`	需求分析、揾出隱藏限制	opus
	`planner`	任務排序、執行計劃	opus
	`architect`	系統設計、介面定義	opus
	`debugger`	根因分析、解決編譯錯誤	sonnet
	`executor`	程式碼實現、重構	sonnet
	`verifier`	完成驗證、確認測試足夠	sonnet
	`tracer`	因果追蹤、競爭假設分析	sonnet
Review	`security-reviewer`	安全漏洞、信任邊界審查	sonnet
	`code-reviewer`	綜合程式碼審查、API 契約	opus
Domain	`test-engineer` 、`designer`、`writer`、`git-master` 等	各領域專業任務	按職責
Coordination	`critic`	計劃差距分析、多角度審查	opus

critic 呢個角色值得提一提——佢專門喺執行之前挑剔，對計劃同設計做差距分析。相當於內置咗一套紅藍對抗機制：planner 出方案，critic 揾漏洞，反覆迭代直到方案夠穩陣。

State 層負責記住啲乜。.omc/ 目錄下按模式存放狀態文件、執行計劃、知識便條同日誌：

.omc/
├── state/                    # 按模式的狀態文件
│   ├── autopilot-state.json  # autopilot 進度
│   ├── ralph-state.json      # ralph 循環狀態
│   └── team/                 # team 任務狀態
├── notepad.md                # 抗壓縮的記憶便箋
├── project-memory.json       # 跨會話項目知識
├── plans/                    # 執行計劃
└── notepads/                 # 按計劃的知識捕獲
    └── {plan-name}/
        ├── learnings.md      # 模式和成功方法
        ├── decisions.md      # 架構決策
        └── issues.md         # 問題和阻礙

notepad.md 嘅設計值得講多句——佢頂得住上下文壓縮。Claude Code 喺上下文窗口就快滿嗰陣會自動壓縮歷史對話，普通資訊會冇咗。但 notepad 嘅內容會喺壓縮前俾 pre-compact Hook 保存，新會話開始嗰陣自動恢復。配合 project-memory.json 實現咗跨會話嘅項目知識持久化。

模型路由：唔係所有任務都需要 Opus

OMC 嘅模型路由策略好實際，分三層：

層級	模型	分配策略	成本
LOW	claude-haiku-4-5	快速揾嘢、簡單任務（`explore`、`writer`）	低
MEDIUM	claude-sonnet-4-6	程式碼實現、除錯、測試（`executor`、`debugger`）	中
HIGH	claude-opus-4-7	架構設計、策略分析（`architect`、`planner`、`critic`）	高

邏輯好簡單：叫 explore Agent 用 Haiku 去掃文件結構，比用 Opus 平好多，效果都唔差。架構決策呢啲需要深度推理嘅任務，先至值得用 Opus 俾錢。社區文章引用咗一個數據：呢套路由策略可以慳返 30-50% 嘅 token（來源：OMC README 同多篇社區文章，未揾到獨立基準測試）。

OMC 仲提供咗委派類別（Delegation Categories），用語義化嘅任務分類自動決定模型層級、温度同思考預算：

類別	層級	温度	適用場景
`visual-engineering`	HIGH	0.7	UI/UX、前端、設計系統
`ultrabrain`	HIGH	0.3	複雜推理、架構、除錯
`artistry`	MEDIUM	0.9	創意方案、腦震盪
`quick`	LOW	0.1	簡單揾嘢、基本操作
`writing`	MEDIUM	0.5	文檔、技術寫作

温度參數嘅區分都好有學問：ultrabrain 用 0.3 確保推理嘅確定性，artistry 用 0.9 鼓勵創意發散。呢啲參數喺 Agent 委派嗰陣自動應用，唔使手動指定。

一個完整嘅 Agent 協作鏈路係咁樣：

explore → analyst → planner → critic → executor → verifier
（發現）  （分析）  （排序）  （審查）  （實現）  （確認）

3. 由安裝到配置嘅完整實戰

安裝流程

OMC 提供兩種安裝途徑，可以並存。一種係做 Claude Code Plugin 用（透過 slash 命令互動），另一種係做 Terminal CLI 用（透過 shell 命令）。

方式一：Marketplace 插件安裝（推薦）

# 添加 marketplace 源
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode

# 安裝插件
/plugin install oh-my-claudecode

方式二：npm CLI 安裝

npm i -g oh-my-claude-sisyphus@latest

有啲細節好易踩坑：項目品牌名係 oh-my-claudecode，但 npm 包名係 oh-my-claude-sisyphus。呢個命名嚟自西西弗斯（Sisyphus）——OMC 嘅 ralph 模式就係推石頭上山嘅循環，任務唔完成唔停。安裝嗰陣出現 deprecated prebuild-install@7.1.3 警告可以 ignore，呢個係上游 better-sqlite3 依賴嘅已知問題。

平台支援方面，macOS 同 Linux 用 Bash Hook 腳本（.sh），Windows 建議用 WSL2，原生支援仲係實驗性（用 Node.js Hook 腳本 .mjs）。

初始化配置

三種方式是但揀一個：

# 自然語言觸發
setup omc

# Skill 命令
/oh-my-claudecode:omc-setup

# CLI 命令
omc setup

作用域選擇上，推薦項目級（/omc-setup --local），配置保存喺 .claude/CLAUDE.md。全域配置保存喺 ~/.claude/CLAUDE.md，對所有項目生效。

/omc-setup 會自動完成幾件事：生成 CLAUDE.md 設定檔、安裝 Hook 腳本到 .claude/hooks.json、註冊 MCP 工具伺服器。官方文檔話呢個係零配置——實際上唔需要手動編輯任何設定檔就可以用得到。

雙層配置詳解

當你需要個性化訂製嗰陣，OMC 嘅設定檔用 JSONC 格式（支援註釋嘅 JSON），分兩層：

作用域	文件路徑	用途
用戶（全域）	`~/.config/claude-omc/config.jsonc`	所有項目通用
項目	`.claude/omc.jsonc`	當前項目專屬

優先級由低到高：預設值 → 用戶配置 → 項目配置 → 環境變量。

{
  // 按 Agent 分配模型
  "agents": {
    "explore": { "model": "haiku" },
    "executor": { "model": "sonnet" },
    "architect": { "model": "opus" }
  },

  // 功能開關
  "features": {
    "parallelExecution": true,
    "lspTools": true,
    "astTools": true
  },

  // 模型路由配置
  "routing": {
    "enabled": true,
    "defaultTier": "MEDIUM",
    "forceInherit": false
  }
}

環境變量覆蓋：OMC_MODEL_LOW、OMC_MODEL_MEDIUM、OMC_MODEL_HIGH 分別控制三層模型。例如項目預算有限，可以將 OMC_MODEL_HIGH 設成 sonnet 而不是 opus，喺成本同質量之間取捨。

診斷工具

裝完之後行一次診斷，確認所有組件就緒：

/oh-my-claudecode:omc-doctor

檢查項目包括：依賴安裝狀態、設定檔語法、Hook 安裝狀態、Agent 可用性、Skill 註冊狀態。邊個環節有問題一眼睇到。

CLI 仲提供咗幾個分析工具：

omc stats — token 使用同成本分析
omc agents — 各 Agent 使用情況細分
omc tui — 互動式儀錶板，即時睇 OMC 運行狀態

4. 高頻工程場景實戰演練

圖 4：三種核心執行模式對比

三個場景，由簡單到複雜，覆蓋日常開發嘅典型需求。每個場景都會俾具體嘅命令同互動流程。

場景一：遺留代碼重構（autopilot / ralph 模式）

場景：接手一個舊項目，auth 模塊代碼亂糟糟，錯誤處理又冇，要重構。

用 autopilot 模式：

autopilot: refactor the auth module, improve error handling and add input validation

OMC 收到呢條指令之後，keyword-detector Hook 偵測到 autopilot 關鍵詞，激活 autopilot Skill，自動行五階段管線：

Explore 階段 — explore Agent（Haiku 模型）掃描 auth 模塊相關文件，建立依賴關係圖
Analysis 階段 — analyst Agent（Opus 模型）分析現有代碼嘅問題同約束
Planning 階段 — planner Agent（Opus 模型）制定重構計劃，critic Agent 審查方案
Execution 階段 — executor Agent（Sonnet 模型）按計劃改代碼
Verification 階段 — verifier Agent（Sonnet 模型）驗證重構結果

成個過程唔需要手動指定用邊個 Agent，OMC 自動編排。autopilot 適合一句說話就開工嘅端到端需求。

用 ralph 模式（更加強力）：

ralph: refactor the auth module, ensure all existing tests still pass

ralph 嘅核心分別在於：佢會循環執行直到所有驗證通過。測試肥佬？自動修復再行。Lint 報錯？自動處理再檢查。

背後嘅原理係 persistent-mode Hook——當 ralph 模式活躍嗰陣，呢個 Hook 喺 Stop 事件觸發嗰陣注入阻止停止嘅訊息，確保 Claude 唔會提早收工。狀態追蹤透過 ralph-state.json 記錄循環次數同每次嘅結果，就算壓縮咗上下文都可以靠狀態文件恢復進度。

幾時用 autopilot，幾時用 ralph？ 如果任務比較肯定（明確知道要做咩），autopilot 就夠。如果任務有嚴格嘅完成標準（測試一定要全部過、build 一定要成功），ralph 更合適。

場景二：批量修復（ultrawork 模式）

場景：一個 TypeScript 項目入面有 50 幾個類型錯誤，分散喺 20 幾個文件入面。

ultrawork fix all TypeScript errors in the project

ultrawork 嘅核心能力係最大並行度。keyword-detector Hook 偵測到關鍵詞之後，OMC 同時起動多個 executor Agent，每個負責一組文件，並行修復。

比較下效果嘅分別：

單 Agent 模式：逐個文件修復，每個文件排隊等上一個完成，50 個錯誤可能要 50 輪循環
ultrawork 模式：多個 Agent 同時開工，每個 Agent 獨立處理自己負責嘅文件，互相唔影響

subagent-tracker Hook 喺後台追蹤每個 Agent 嘅狀態。完成之後自動彙總結果，報告邊啲文件修復成功、邊啲仲有問題。

觸發方式都好靈活——ultrawork、ulw、uw 入面任何一個關鍵詞都可以激活並行模式。

想加多層深度搜索再修復：

deepsearch find all usages of deprecated API calls, then ultrawork fix them

deepsearch 先用 explore Agent 喺程式碼庫入面定位曬所有過時 API 調用，彙總結果之後交俾 ultrawork 並行修復。

場景三：多模塊 Bug 修復（team 模式）

場景：生產環境出咗一個支付超時嘅 Bug，涉及後端支付服務、前端結賬流程同數據庫交易，需要多模塊協作排查修復。

Team 模式係 OMC 推薦嘅執行方式，行一個五階段流水線：

team-plan → team-prd → team-exec → team-verify → team-fix

起動命令：

/team 3:executor "fix the payment timeout bug affecting checkout flow"

呢條命令起動 3 個 executor Agent，透過共享任務列表同訊息系統協作。每個 Agent 有獨立嘅上下文窗口（上下文隔離），Leader Agent 負責協調同揀選性共享資訊。

tmux CLI 工作者（v4.4.0+）更進一步——可以起動真實嘅 Codex 或 Gemini CLI 進程：

# Claude 負責調查根因
omc team 1:claude "investigate the payment timeout root cause"

# Codex 負責安全審查
omc team 1:codex "review the fix for security issues"

# Gemini 負責設計 UI 錯誤狀態
omc team 1:gemini "design UI error state for payment failure"

管理任務都好直觀：

omc team status payment-fix    # 查看狀態
omc team shutdown payment-fix  # 完成後關停

一個提醒：Team 模式需要喺 ~/.claude/settings.json 中啓用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS，呢個係 Anthropic 嘅實驗性功能，唔開通 /team 命令就用唔到。另外 tmux CLI 工作者需要額外安裝 tmux（macOS：brew install tmux，Linux：apt install tmux）。

你喺項目入面用過類似嘅多 Agent 協作方案未？體驗點樣，歡迎喺評論區傾嚇。

5. 效率對比同使用建議

執行模式選擇指南

唔知用邊種模式？參考呢張決策表：

模式	適用場景	關鍵特點	觸發方式
Team	多模塊協作、複雜 Bug	五階段流水線，多 Agent 共享任務列表	`/team N:agent`
Autopilot	端到端功能開發	全自主五階段，配置少	`autopilot:` 前綴
Ultrawork	批量修復、並行重構	最大並行度	`ultrawork` 關鍵詞
Ralph	必須完整完成嘅任務	循環直到驗證通過	`ralph:` 前綴
ccg	混合後端 + UI 工作	三模型協作：Codex + Gemini + Claude	`ccg:` 前綴
ralplan	需要共識嘅複雜規劃	Planner、Architect、Critic 循環至共識	`ralplan` 關鍵詞
UltraQA	質量門檢查	QA 循環直到測試/lint/類型檢查通過	UltraQA 模式

選擇建議：日常開發由 autopilot 開始上手，需要並行處理用 ultrawork，複雜多模塊任務上 team，有嚴格完成標準嘅用 ralph。

常用命令速查

# 自動執行
autopilot: build a REST API with authentication

# 持久執行（不完成不停止）
ralph: refactor the auth module

# 並行執行
ultrawork fix all TypeScript errors

# 多 Agent 協作
/team 3:executor "implement todo app"

# 三模型協作
ccg: review this PR

# 深度搜索
deepsearch find all database queries without indexes

# 深度推理
ultrathink about the best caching strategy for this API

# 取消活躍模式
stopomc

實際使用嘅注意事項

魔法關鍵詞硬編碼：autopilot、ralph、ccg 等核心關鍵詞喺 Hook 腳本入面寫死咗，唔可以透過設定檔修改。自訂觸發詞只支援 ultrawork、search、analyze、ultrathink 呢幾類，可以喺 omc.jsonc 的 magicKeywords 字段入面配置
模型降級策略：預算有限嗰陣，透過 OMC_MODEL_HIGH=sonnet 將 HIGH 層由 opus 降到 sonnet 係一個務實嘅選擇。或者直接喺設定檔入面俾特定 Agent 指定模型："architect": { "model": "sonnet" }
Windows 支援：原生 Windows 支援仲係實驗性，建議用 WSL2。Hook 腳本喺 macOS/Linux 用 Bash（.sh），喺 Windows 用 Node.js（.mjs）
swarm 兼容：如果你之前用開 swarm 命令，留意呢個兼容別名已經移除咗，要轉用 /team 語法

自訂 Skill：一次學習，永久重用

/skillify 命令可以將會話入面嘅解決方案提取成可重用嘅 Skill 文件：

# .omc/skills/fix-proxy-crash.md
---
name:FixProxyCrash
description:aiohttpproxycrashesonClientDisconnectedError
triggers:["proxy","aiohttp","disconnected"]
source:extracted
---
Wraphandleratserver.py:42intry/exceptClientDisconnectedError...

Skill 分兩個作用域：項目級 .omc/skills/ 提交到版本控制俾團隊共享；用戶級 ~/.omc/skills/ 對所有項目通用。項目級優先級更高，會覆蓋用戶級同名 Skill。

仲有一個 /deep-interview 命令值得提——佢用蘇格拉底式問答嚟幫你澄清需求，適合喺動手寫代碼之前諗清楚需求。

總結

oh-my-claudecode 嘅核心思路好清楚：Claude Code 提供咗強大嘅單 Agent 能力同靈活嘅 Hooks 機制，OMC 喺呢個基礎上整咗 Hooks → Skills → Agents → State 四層編排架構，將手動叫一個 Agent 做嘢 變成自動協調多個 Agent。

由源碼分析睇，呢套架構設計係紮實嘅：19 個 Agent 按泳道分工明確，三層模型路由喺成本同質量之間做咗合理取捨，State 系統嘅 notepad 抗壓縮機制解決咗一個實際痛點，三層 Skill 組合公式提供咗靈活嘅執行策略。

不過講真，OMC 目前更適合已經用緊 Claude Code、對多 Agent 協作有實際需要嘅開發者。如果你嘅日常任務比較簡單——改一個文件、短對話搞得掂——OMC 嘅 19 個 Agent 同 31 個 Skill 可能太重手。而且一啲關鍵魔法關鍵詞（autopilot、ralph）係寫死咗嘅，訂製靈活性有限。

如果你嘅項目經常涉及多文件重構、批量修復或者需要端到端自動化流程，OMC 值得認真試嚇。建議由 autopilot 模式開始上手，熟咗之後再試 team 和 ultrawork。遇到問題行一次 /omc-doctor 診斷，基本上解決到大部份安裝同配置問題。

關於 OMC 嘅多 Agent 協作，你最想了解邊方面？留言話俾我知。

好啦，多謝你睇我呢篇文章，如果鍾意可以點讃轉發俾有需要嘅朋友，我哋下一期再見！記得留意！

🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃第 118 篇，AI 編程最佳實戰「2026」系列第 36 篇
大家好，歡迎來到 術哥無界 | ShugeX ｜運維有術。
我是術哥，一名專注於 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫的技術實踐者與開源佈道者！

Talk is cheap, let's explore。無界探索，有術而行。

圖 1：oh-my-claudecode 核心架構概覽

用 Claude Code 寫代碼的開發者，大概率都撞上過這幾個場景：一個涉及 20 多個文件的重構任務，得手動拆成十幾次提示，每次都要重新交代上下文；調試一個跨模塊的 Bug，單 Agent 來回翻文件，效率還不如自己開 IDE 搜；想讓 Claude Code 自動跑完規劃→實現→測試→驗證的完整流程，結果每一步都要人工介入。

這些問題的根源不是 Claude Code 能力不行。Anthropic 官方博客有一句話把邊界說得很清楚：能用單次調用解決就不要用 Workflow，能用 Workflow 就不要上 Agent。 反過來看，當任務複雜到確實需要多 Agent 協作時，原生的單 Agent 模式就捉襟見肘了。

oh-my-claudecode（簡稱 OMC）就是在這個邊界上做文章的。它通過 Hooks → Skills → Agents → State 四層架構，把 Claude Code 從手動指揮一個 Agent 升級為自動協調 19 個專業 Agent。翻了一圈官方文檔和源碼後，我把這套系統的核心邏輯整理成了這篇文章——從底層機制到架構設計，再到三個高頻場景的實戰演示。

說明：本文內容基於 oh-my-claudecode（Yeachan-Heo/oh-my-claudecode）源碼（v4.14.1）和 Anthropic 官方文檔分析整理而成，源碼分析基於筆者本地倉庫版本，尚未在生產環境中完成全場景驗證。文中的配置模板和參數建議僅供參考，實際效果請以你的業務數據和環境測試結果為準。如果有實際使用經驗，歡迎在評論區分享交流。

1. Claude Code 的底層運行機制

圖 2：Claude Code 四層架構

要理解 OMC 做了什麼，先得搞清楚 Claude Code 本身是怎麼跑的。

Agentic 工作流

Claude Code 採用工具增強的 Agent 架構，核心是一個多輪推理循環：思考 → 調用工具 → 處理結果 → 繼續思考。每一輪循環裏，模型會根據當前上下文決定是繼續調用工具還是直接輸出結果。

根據 CSDN 上的架構分析文章（整理自 Anthropic 官方博客），整個系統分四層：用戶界面層（CLI/IDE）→ Claude Code Core（會話管理、權限控制、上下文管理）→ Agent Loop（多輪推理循環）→ LLM 模型層 + 工具系統。

工具系統又分兩部分：本地工具（Read/Write/Bash/Grep 等）和 MCP Servers（Context7、Lark Doc 等外部工具服務器）。模型在每一輪循環中可以選擇調用哪個工具，Claude Code Core 負責權限檢查和工具調度。

簡單任務走單 Agent 模式，一次對話搞定。複雜任務時，主 Agent 可以派生子 Agent 來並行處理——這就是 Anthropic 在 2026 年 2 月推出的實驗性功能 Agent Teams，採用星形拓撲結構（Star Topology），Leader Agent 協調多個 Expert Agent。

但這裏有個關鍵限制：派生是手動的。你得自己告訴 Claude Code 用子 Agent 做某個任務，而且每個子 Agent 的模型、職責、上下文都得自己管理。更別說子 Agent 之間的協調、狀態追蹤、錯誤恢復——這些全靠人肉。

Hooks：零上下文成本的自動化

Hooks 是 Claude Code 一個被嚴重低估的能力。騰訊雲開發者社區有一篇分析文章說得很到位：Hooks 在 Agent 循環外運行，不佔用上下文窗口。

這意味着什麼？你可以在不消耗任何 token 的情況下，讓系統自動響應生命週期事件。比如文件保存後自動跑 linter、危險命令執行前攔截、任務完成時發 Slack 通知。這些操作完全繞過了 Agent Loop，不擠佔本就緊張的上下文空間。

Claude Code 原生支持 11-13 個 Hook 生命週期事件，覆蓋從 SessionStart（會話開始）到 PreToolUse/PostToolUse（工具使用前後）再到 Stop（Agent 即將停止）和 SessionEnd（會話結束）的完整鏈路。每個事件都有對應的 JSON 有效負載，攜帶上下文信息供 Hook 腳本使用。

OMC 正是基於這套 Hook 機制，搭建了 20 個 Hook 腳本攔截這些生命週期事件，實現了智能路由和自動化編排。後面會詳細展開。

配置體系

Claude Code 的配置文件分三層：

項目級CLAUDE.md — 通過 /init 生成，放在項目根目錄，推薦加入版本控制
個人級CLAUDE.local.md — 個人定製配置，加入 .gitignore
全局級~/.claude/CLAUDE.md — 對所有項目生效

疊加順序：項目級 > 父目錄 > 子目錄 > 全局。Anthropic 官方還提供了工具許可管理的四種方式：會話中始終允許、/permissions 命令、編輯 settings.json、--allowedTools CLI 標誌。

這套多層配置和靈活的權限管理，為 OMC 的雙層配置和 Agent 委派系統提供了基礎。

2. OMC 的架構設計

圖 3：OMC 四大系統互聯流程

OMC 的核心不是堆功能數量，而是在四個系統之間建立了一條清晰的管線：

用戶輸入 → Hooks（事件檢測）→ Skills（行為注入）→ Agents（任務執行）→ State（進度追蹤）

四大系統各司其職

Hooks 層是入口。OMC 的 20 個 Hook 腳本攔截 Claude Code 的 11 個生命週期事件。幾個關鍵 Hook 的職責：

Hook	觸發事件	做了什麼
`keyword-detector`	`UserPromptSubmit`	檢測魔法關鍵詞，激活對應 Skill
`persistent-mode`	`Stop`	ralph/ultrawork 活躍時阻止提前停止
`pre-compact`	`PreCompact`	上下文壓縮前保存關鍵信息到 notepad
`subagent-tracker`	`SubagentStart` /`SubagentStop`	追蹤運行中的 Agent 狀態

整個過程在 Agent 循環外完成，零上下文消耗。你輸入 ultrawork fix the API，keyword-detector 檢測到關鍵詞後自動激活 ultrawork Skill，然後 Skills 層接管決定執行策略。

Skills 層決定怎麼做。31 個 Skill（28 個用戶可調用 + 3 個內部管線）按三層組合：

[執行 Skill] + [0-N 個增強技能] + [可選保證層]

執行層負責主任務（default、orchestrate、planner），增強層疊加能力（ultrawork 並行、git-master 自動提交、frontend-ui-ux 前端增強），保證層確保完成（ralph 不驗證完不停止）。這個組合公式的設計很靈活——你可以用 default + git-master 做普通開發帶自動提交，也可以用 autopilot + ralph 做強力端到端。

Agents 層決定誰來做。19 個專業 Agent 分四個泳道：

泳道	Agent	職責	默認模型
Build/Analysis	`explore`	代碼庫發現、文件/符號映射	haiku
	`analyst`	需求分析、隱藏約束髮現	opus
	`planner`	任務排序、執行計劃	opus
	`architect`	系統設計、接口定義	opus
	`debugger`	根因分析、編譯錯誤解決	sonnet
	`executor`	代碼實現、重構	sonnet
	`verifier`	完成驗證、測試充分性確認	sonnet
	`tracer`	因果追蹤、競爭假設分析	sonnet
Review	`security-reviewer`	安全漏洞、信任邊界審查	sonnet
	`code-reviewer`	綜合代碼審查、API 契約	opus
Domain	`test-engineer` 、`designer`、`writer`、`git-master` 等	各領域專業任務	按職責
Coordination	`critic`	計劃差距分析、多角度審查	opus

critic 這個角色值得一提——它專門在執行前挑毛病，對計劃和設計做差距分析。相當於內置了一套紅藍對抗機制：planner 出方案，critic 找漏洞，反覆迭代直到方案足夠健壯。

State 層負責記住什麼。.omc/ 目錄下按模式存放狀態文件、執行計劃、知識便箋和日誌：

.omc/
├── state/                    # 按模式的狀態文件
│   ├── autopilot-state.json  # autopilot 進度
│   ├── ralph-state.json      # ralph 循環狀態
│   └── team/                 # team 任務狀態
├── notepad.md                # 抗壓縮的記憶便箋
├── project-memory.json       # 跨會話項目知識
├── plans/                    # 執行計劃
└── notepads/                 # 按計劃的知識捕獲
    └── {plan-name}/
        ├── learnings.md      # 模式和成功方法
        ├── decisions.md      # 架構決策
        └── issues.md         # 問題和阻礙

notepad.md 的設計值得多說一句——它抗上下文壓縮。Claude Code 在上下文窗口接近上限時會自動壓縮歷史對話，普通信息會丟失。但 notepad 的內容會在壓縮前被 pre-compact Hook 保存，新會話開始時自動恢復。配合 project-memory.json 實現了跨會話的項目知識持久化。

模型路由：不是所有任務都需要 Opus

OMC 的模型路由策略很實際，分三層：

層級	模型	分配策略	成本
LOW	claude-haiku-4-5	快速查找、簡單任務（`explore`、`writer`）	低
MEDIUM	claude-sonnet-4-6	代碼實現、調試、測試（`executor`、`debugger`）	中
HIGH	claude-opus-4-7	架構設計、戰略分析（`architect`、`planner`、`critic`）	高

邏輯很直白：讓 explore Agent 用 Haiku 去掃描文件結構，比用 Opus 便宜得多，效果也不差。架構決策這種需要深度推理的任務，才值得花 Opus 的錢。社區文章引用了一個數據：這套路由策略能節省 30-50% 的 token（來源：OMC README 及多篇社區文章，未找到獨立基準測試）。

OMC 還提供了委派類別（Delegation Categories），用語義化的任務分類自動確定模型層級、温度和思考預算：

類別	層級	温度	適用場景
`visual-engineering`	HIGH	0.7	UI/UX、前端、設計系統
`ultrabrain`	HIGH	0.3	複雜推理、架構、調試
`artistry`	MEDIUM	0.9	創意方案、頭腦風暴
`quick`	LOW	0.1	簡單查找、基本操作
`writing`	MEDIUM	0.5	文檔、技術寫作

温度參數的區分也很有講究：ultrabrain 用 0.3 保證推理的確定性，artistry 用 0.9 鼓勵創意發散。這些參數在 Agent 委派時自動應用，不需要手動指定。

一個完整的 Agent 協作鏈路長這樣：

explore → analyst → planner → critic → executor → verifier
（發現）  （分析）  （排序）  （審查）  （實現）  （確認）

3. 從安裝到配置的完整實戰

安裝流程

OMC 提供兩種安裝途徑，可以共存。一種作為 Claude Code Plugin 使用（通過 slash 命令交互），另一種作為 Terminal CLI 使用（通過 shell 命令）。

方式一：Marketplace 插件安裝（推薦）

# 添加 marketplace 源
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode

# 安裝插件
/plugin install oh-my-claudecode

方式二：npm CLI 安裝

npm i -g oh-my-claude-sisyphus@latest

有個細節容易踩坑：項目品牌名是 oh-my-claudecode，但 npm 包名是 oh-my-claude-sisyphus。這個命名來自西西弗斯（Sisyphus）——OMC 的 ralph 模式就是推石頭上山的循環，任務不完成不停止。安裝時出現 deprecated prebuild-install@7.1.3 警告可以忽略，這是上游 better-sqlite3 依賴的已知問題。

平台支持方面，macOS 和 Linux 用 Bash Hook 腳本（.sh），Windows 建議用 WSL2，原生支持仍為實驗性（用 Node.js Hook 腳本 .mjs）。

初始化配置

三種方式任選其一：

# 自然語言觸發
setup omc

# Skill 命令
/oh-my-claudecode:omc-setup

# CLI 命令
omc setup

作用域選擇上，推薦項目級（/omc-setup --local），配置保存在 .claude/CLAUDE.md。全局配置保存在 ~/.claude/CLAUDE.md，對所有項目生效。

/omc-setup 會自動完成幾件事：生成 CLAUDE.md 配置文件、安裝 Hook 腳本到 .claude/hooks.json、註冊 MCP 工具服務器。官方文檔說這是零配置——實際上不需要手動編輯任何配置文件就能跑起來。

雙層配置詳解

當你需要個性化定製時，OMC 的配置文件使用 JSONC 格式（支持註釋的 JSON），分兩層：

作用域	文件路徑	用途
用戶（全局）	`~/.config/claude-omc/config.jsonc`	所有項目通用
項目	`.claude/omc.jsonc`	當前項目專屬

優先級從低到高：默認值 → 用戶配置 → 項目配置 → 環境變量。

{
  // 按 Agent 分配模型
  "agents": {
    "explore": { "model": "haiku" },
    "executor": { "model": "sonnet" },
    "architect": { "model": "opus" }
  },

  // 功能開關
  "features": {
    "parallelExecution": true,
    "lspTools": true,
    "astTools": true
  },

  // 模型路由配置
  "routing": {
    "enabled": true,
    "defaultTier": "MEDIUM",
    "forceInherit": false
  }
}

環境變量覆蓋：OMC_MODEL_LOW、OMC_MODEL_MEDIUM、OMC_MODEL_HIGH 分別控制三層模型。比如項目預算有限，可以把 OMC_MODEL_HIGH 設成 sonnet 而不是 opus，在成本和質量之間做取捨。

診斷工具

裝完跑一下診斷，確認所有組件就緒：

/oh-my-claudecode:omc-doctor

檢查項包括：依賴安裝狀態、配置文件語法、Hook 安裝狀態、Agent 可用性、Skill 註冊狀態。哪個環節有問題一目瞭然。

CLI 還提供了幾個分析工具：

omc stats — token 使用和成本分析
omc agents — 各 Agent 使用情況細分
omc tui — 交互式儀表板，實時查看 OMC 運行狀態

4. 高頻工程場景實戰演練

圖 4：三種核心執行模式對比

三個場景，從簡到繁，覆蓋日常開發中的典型需求。每個場景都給出具體的命令和交互流程。

場景一：遺留代碼重構（autopilot / ralph 模式）

場景：接手一個老項目，auth 模塊代碼混亂，錯誤處理缺失，需要重構。

用 autopilot 模式：

autopilot: refactor the auth module, improve error handling and add input validation

OMC 收到這條指令後，keyword-detector Hook 檢測到 autopilot 關鍵詞，激活 autopilot Skill，自動走五階段管線：

Explore 階段 — explore Agent（Haiku 模型）掃描 auth 模塊相關文件，建立依賴關係圖
Analysis 階段 — analyst Agent（Opus 模型）分析現有代碼的問題和約束
Planning 階段 — planner Agent（Opus 模型）制定重構計劃，critic Agent 審查方案
Execution 階段 — executor Agent（Sonnet 模型）按計劃修改代碼
Verification 階段 — verifier Agent（Sonnet 模型）驗證重構結果

整個過程不需要手動指定用哪個 Agent，OMC 自動編排。autopilot 適合說一句話就開工的端到端需求。

用 ralph 模式（更強力）：

ralph: refactor the auth module, ensure all existing tests still pass

ralph 的核心區別在於：它循環執行直到所有驗證通過。測試掛了？自動修復再跑。Lint 報錯？自動處理再檢查。

背後的原理是 persistent-mode Hook——當 ralph 模式活躍時，這個 Hook 在 Stop 事件觸發時注入阻止停止的消息，確保 Claude 不會提前收工。狀態追蹤通過 ralph-state.json 記錄循環次數和每次的結果，即使上下文被壓縮也能從狀態文件恢復進度。

什麼時候用 autopilot，什麼時候用 ralph？ 如果任務比較確定（明確知道要做什麼），autopilot 就夠了。如果任務有嚴格的完成標準（測試必須全過、build 必須成功），ralph 更合適。

場景二：批量修復（ultrawork 模式）

場景：一個 TypeScript 項目裏有 50 多個類型錯誤，分散在 20 多個文件中。

ultrawork fix all TypeScript errors in the project

ultrawork 的核心能力是最大並行度。keyword-detector Hook 檢測到關鍵詞後，OMC 同時啓動多個 executor Agent，每個負責一組文件，並行修復。

對比一下效果差異：

單 Agent 模式：逐個文件修復，每個文件排隊等上一個完成，50 個錯誤可能需要 50 輪循環
ultrawork 模式：多個 Agent 同時開工，每個 Agent 獨立處理自己負責的文件，互不干擾

subagent-tracker Hook 在後台追蹤每個 Agent 的狀態。完成後自動彙總結果，報告哪些文件修復成功、哪些還有問題。

觸發方式也很靈活——ultrawork、ulw、uw 中任何一個關鍵詞都能激活並行模式。

想加一層深度搜索再修復：

deepsearch find all usages of deprecated API calls, then ultrawork fix them

deepsearch 先用 explore Agent 在代碼庫中定位所有過時 API 調用，彙總結果後交給 ultrawork 並行修復。

場景三：多模塊 Bug 修復（team 模式）

場景：生產環境出了一個支付超時的 Bug，涉及後端支付服務、前端結賬流程和數據庫事務，需要多模塊協作排查修復。

Team 模式是 OMC 推薦的執行方式，走一個五階段流水線：

team-plan → team-prd → team-exec → team-verify → team-fix

啓動命令：

/team 3:executor "fix the payment timeout bug affecting checkout flow"

這條命令啓動 3 個 executor Agent，通過共享任務列表和消息系統協作。每個 Agent 有獨立的上下文窗口（上下文隔離），Leader Agent 負責協調和選擇性共享信息。

tmux CLI 工作者（v4.4.0+）更進一步——可以啓動真實的 Codex 或 Gemini CLI 進程：

# Claude 負責調查根因
omc team 1:claude "investigate the payment timeout root cause"

# Codex 負責安全審查
omc team 1:codex "review the fix for security issues"

# Gemini 負責設計 UI 錯誤狀態
omc team 1:gemini "design UI error state for payment failure"

管理任務也很直觀：

omc team status payment-fix    # 查看狀態
omc team shutdown payment-fix  # 完成後關停

一個提醒：Team 模式需要在 ~/.claude/settings.json 中啓用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS，這是 Anthropic 的實驗性功能，不啓用 /team 命令不可用。另外 tmux CLI 工作者需要額外安裝 tmux（macOS：brew install tmux，Linux：apt install tmux）。

你在項目中用過類似的多 Agent 協作方案嗎？體驗怎麼樣，歡迎在評論區聊聊。

5. 效率對比與使用建議

執行模式選擇指南

不知道該用哪種模式？參考這張決策表：

模式	適用場景	關鍵特點	觸發方式
Team	多模塊協作、複雜 Bug	五階段流水線，多 Agent 共享任務列表	`/team N:agent`
Autopilot	端到端功能開發	全自主五階段，配置少	`autopilot:` 前綴
Ultrawork	批量修復、並行重構	最大並行度	`ultrawork` 關鍵詞
Ralph	必須完整完成的任務	循環直到驗證通過	`ralph:` 前綴
ccg	混合後端 + UI 工作	三模型協作：Codex + Gemini + Claude	`ccg:` 前綴
ralplan	需要共識的複雜規劃	Planner、Architect、Critic 循環至共識	`ralplan` 關鍵詞
UltraQA	質量門檢查	QA 循環直到測試/lint/類型檢查通過	UltraQA 模式

選擇建議：日常開發從 autopilot 開始上手，需要並行處理用 ultrawork，複雜多模塊任務上 team，有嚴格完成標準的用 ralph。

常用命令速查

# 自動執行
autopilot: build a REST API with authentication

# 持久執行（不完成不停止）
ralph: refactor the auth module

# 並行執行
ultrawork fix all TypeScript errors

# 多 Agent 協作
/team 3:executor "implement todo app"

# 三模型協作
ccg: review this PR

# 深度搜索
deepsearch find all database queries without indexes

# 深度推理
ultrathink about the best caching strategy for this API

# 取消活躍模式
stopomc

實際使用中的注意事項

魔法關鍵詞硬編碼：autopilot、ralph、ccg 等核心關鍵詞在 Hook 腳本中硬編碼，不能通過配置文件修改。自定義觸發詞只支持 ultrawork、search、analyze、ultrathink 這幾類，可以在 omc.jsonc 的 magicKeywords 字段中配置
模型降級策略：預算有限時，通過 OMC_MODEL_HIGH=sonnet 把 HIGH 層從 opus 降到 sonnet 是個務實的選擇。或者直接在配置文件中給特定 Agent 指定模型："architect": { "model": "sonnet" }
Windows 支持：原生 Windows 支持仍為實驗性，建議用 WSL2。Hook 腳本在 macOS/Linux 上用 Bash（.sh），在 Windows 上用 Node.js（.mjs）
swarm 兼容：如果你之前用的是 swarm 命令，注意這個兼容別名已經移除，需要遷移到 /team 語法

自定義 Skill：一次學習，永久複用

/skillify 命令可以把會話中的解決方案提取成可複用的 Skill 文件：

# .omc/skills/fix-proxy-crash.md
---
name:FixProxyCrash
description:aiohttpproxycrashesonClientDisconnectedError
triggers:["proxy","aiohttp","disconnected"]
source:extracted
---
Wraphandleratserver.py:42intry/exceptClientDisconnectedError...

Skill 分兩個作用域：項目級 .omc/skills/ 提交到版本控制供團隊共享；用戶級 ~/.omc/skills/ 對所有項目通用。項目級優先級更高，會覆蓋用戶級同名 Skill。

還有一個 /deep-interview 命令值得一提——它用蘇格拉底式問答來幫你澄清需求，適合在動手寫代碼前把需求想清楚。

總結

oh-my-claudecode 的核心思路很清晰：Claude Code 提供了強大的單 Agent 能力和靈活的 Hooks 機制，OMC 在這個基礎上搭建了 Hooks → Skills → Agents → State 四層編排架構，把手動指揮一個 Agent 變成自動協調多個 Agent。

從源碼分析來看，這套架構設計是紮實的：19 個 Agent 按泳道分工明確，三層模型路由在成本和質量之間做了合理權衡，State 系統的 notepad 抗壓縮機制解決了一個實際痛點，三層 Skill 組合公式提供了靈活的執行策略。

不過說實話，OMC 目前更適合已經在用 Claude Code、對多 Agent 協作有實際需求的開發者。如果你的日常任務比較簡單——單文件修改、短對話能搞定——OMC 的 19 個 Agent 和 31 個 Skill 可能有點重了。而且一些關鍵魔法關鍵詞（autopilot、ralph）是硬編碼的，定製靈活性有限。

如果你的項目經常涉及多文件重構、批量修復或需要端到端自動化流程，OMC 值得認真試試。建議從 autopilot 模式開始上手，熟悉後再嘗試 team 和 ultrawork。遇到問題跑一下 /omc-doctor 診斷，基本能解決大部分安裝和配置問題。

關於 OMC 的多 Agent 協作，你最想了解哪個方面？留言告訴我。

好啦，謝謝你觀看我的文章，如果喜歡可以點贊轉發給需要的朋友，我們下一期再見！敬請期待！