oh-my-claudecode 多智能体编排实战全解析：执行模式、Agent 体系与上手路径

2026-09-08 14:53:36作者：段琳惟

本文基于 seminar/slides.md（一场 60 分钟的 oh-my-claudecode 技术研讨演示稿）整理成篇，并对照当前仓库（package.json 版本 5.0.2）的源码与文档逐条核验。文章聚焦 OMC 的核心命题：如何把 Claude Code 从"单打独斗的执行者"改造成"指挥专家 Agent 乐团的指挥家"，重点讲解其执行模式体系（Autopilot、并行模式、Team、Pipeline/Execute、Ecomode 成本模式）、Agent 体系（四车道专业 Agent + 三层模型路由）、开发者体验（Magic Keywords、HUD、Notepad）与从安装到配置的完整上手路径。读完你会掌握 OMC 的模式选型思路、触发词体系与配置方法，并能把这些能力映射到具体项目场景中。

⚠️ 版本演进提示：研讨稿记录的是 v3.x 时代的模式图景（其中 Ultrapilot、Swarm、Pipeline 等概念在当时以 ultrapilot、/swarm、/pipeline 形式存在）。当前仓库已演进到 v5.0.2，docs/CLAUDE.md 明确记录了这些旧表面的去向，本文在讲解每个模式时都会给出"现在对应什么"的结论，避免读者照抄已过时的命令。

一、OMC 是什么：从"执行者"到"指挥家"的思维转变

oh-my-claudecode（简称 OMC）是一套运行在 Claude Code 之上的多智能体编排系统（multi-agent orchestration system）。它的定位不是"另一个 AI 编程工具"，而是把 Claude Code 的能力放大成一支可编排的专家团队。

研讨稿用一句话概括其设计哲学：

"You are a CONDUCTOR, not a performer."（你是指挥家，不是演奏者。）

对比两种工作方式：

传统 AI 工作流：
User -> Claude -> [自己完成所有事情]

OMC 工作流：
User -> Claude (指挥家) -> [将任务委派给专业 Agent]
                               |
               +---------------+---------------+
               |               |               |
          architect        executor        designer
         (架构分析)       (代码实现)      (UI/UX)

研讨稿还给出了"Before vs After"对照表，这些诉求正是当前仓库能力清单的雏形：

方面	Before OMC	After OMC
任务执行	单线程	并行 Agent
复杂任务	手工拆分	自动分解
模型选择	永远同一个模型	智能路由（Haiku/Sonnet/Opus 三档）
持久性	容易放弃	验证通过才停止
成本	昂贵	智能路由显著节省
学习曲线	记忆命令	自然语言

三层架构：Keyword → Skill → Agent

研讨稿给出了一张关键的架构图，OMC 的运行时本质是一条三级流水线：用户输入经过关键字检测，命中某个 Skill，Skill 再去编排一组 Agent：

USER INPUT: "autopilot: build a REST API"
        v
CLAUDE CODE (CONDUCTOR)
  + 关键字检测 Keyword Detection
  + Skill 解析 Skill Resolution
  + Agent 委派 Agent Delegation
        v
SKILL LAYER: autopilot | ultrawork | ralph ...
        v
AGENT LAYER: analyst | executor | architect | critic ...

这一点可以在当前仓库的 docs/ARCHITECTURE.md 中找到正式描述：OMC 建立在四个相互咬合的系统上——Hooks 捕获生命周期事件、Skills 注入行为、Agents 执行专项工作、State 在上下文被重置后跟踪进度，数据流为 User Input → Hooks → Skills → Agents → State。

其中 Magic Keywords 的检测逻辑落在 keyword-detector Hook 上（触发于 UserPromptSubmit 事件），它会判断用户输入中的关键词上下文，命中后向 Claude 注入 <system-reminder> 提示以激活对应 Skill。示例（见 docs/ARCHITECTURE.md）：

{
  "UserPromptSubmit": [
    {
      "matcher": "*",
      "hooks": [
        {
          "type": "command",
          "command": "node scripts/keyword-detector.mjs",
          "timeout": 5
        }
      ]
    }
  ]
}

Skill 的三层叠加模型

Skills 是行为注入而不是 Agent 替换，它们按三层叠加（见 docs/ARCHITECTURE.md 的 "Skill Layers"）：

┌─────────────────────────────────────────────┐
│ GUARANTEE LAYER（可选保证层）                   │
│ ralph: "验证完成之前不允许停止"                 │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ ENHANCEMENT LAYER（增强层，0~N 个）            │
│ ultrawork(并行) | git-master(提交) | frontend-ui-ux │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ EXECUTION LAYER（主执行 Skill）               │
│ default(构建) | orchestrate(协调) | planner(规划) │
└─────────────────────────────────────────────┘

组合公式：[执行 Skill] + [0~N 个增强] + [可选保证]。例如输入 ultrawork: refactor API with proper commits，实际激活的是 ultrawork + default + git-master。

二、执行模式体系：从研讨稿的"5 大模式"到当前仓库的规范面

研讨稿以 "5 Key Execution Modes" 组织内容，展示了 OMC 在不同任务形态下的策略差异。这些概念在当前仓库中多数保留为 Skill 或已收敛为新的规范面，下面逐项讲解（每节同时标注其"当前仓库中的对应物"）。

1. Autopilot：全自主执行（当前仍为核心 Skill）

Autopilot 是 OMC 的旗舰体验：从一句想法到可运行代码全程无人值守。

研讨稿给出的触发示例与当前仓库一致：

autopilot: build a REST API for a bookstore with CRUD operations
/oh-my-claudecode:autopilot Add OAuth2 authentication

五阶段流水线（研讨稿描述与 docs/GETTING-STARTED.md 的 "What happens" 一致）：

阶段	参与者	内容
1. Expansion	analyst + architect	把模糊想法提炼为需求与技术规格
2. Planning	planner + critic	生成执行计划，Critic 校验有无缺口
3. Execution	executor 等	编写代码，必要时多 Agent 并行
4. QA	—	反复 build → lint → test → fix，最多若干轮，直到全绿
5. Validation	architect / security-reviewer / code-reviewer	功能完整性、安全性、代码质量三重终审

当前仓库中，Autopilot 是 skills/autopilot/ 中的正式 Skill，README 给出的最简用法：

# 会话内
/autopilot "build a REST API for managing tasks"
# 自然语言快捷键
autopilot: build a REST API for managing tasks

其 Magic Keyword 触发词（含组合形式）见 docs/ARCHITECTURE.md 的关键词表：autopilot、build me、I want a、handle it all、end to end、e2e this 等。注意：autopilot、ralph 等触发词在 Hook 中是硬编码的，不能通过配置文件修改（见 docs/ARCHITECTURE.md "Keyword Detection Sources"）。

典型使用场景：从零新建项目、完整功能实现、端到端工作流。

2. 并行执行：从 Ultrapilot / Ultrawork 到 Team 与 swarm 语义

研讨稿的 "Mode 2: Ultrapilot" 提出了**文件所有权分区（file ownership partitioning）**的并行思路：协调器把任务分解后为每个 Worker 划分互不重叠的文件集，共享文件（如 package.json、tsconfig.json）交给协调器在集成阶段统一处理：

[ULTRAPILOT COORDINATOR]
  任务分解 + 文件分区
  Worker-1 (backend  src/api/)   Worker-2 (frontend  src/ui/)
  Worker-3 (database src/db/)    Worker-4 (api-docs  docs/)
  Worker-5 (tests    tests/)
              └── [INTEGRATION PHASE] → [VALIDATION PHASE]

研讨稿的 "Mode 3: Swarm" 则提出**原子任务认领（atomic task claiming）**的另一种并行语义：N 个同类 Agent 共享一个任务池，任何空闲者都能认领下一个任务：

/swarm 5:executor "fix all TypeScript errors"
        └─ SWARM ORCHESTRATOR → E1 E2 E3 E4 E5
             └─ SQLITE DATABASE: tasks 表（pending/claimed/done/failed）

认领协议为：Agent 调 claimTask() → SQLite 事务原子更新状态 → 工作 → 调 completeTask() / failTask()，从而保证两个 Agent 永远不可能领到同一个任务。

当前仓库的对应物：上述两个概念在 v5 中统一收敛到了 Team。README 明确指出："Starting in v4.1.7, Team is the canonical orchestration surface in OMC. The legacy swarm keyword/skill has been removed; use team directly." docs/CLAUDE.md 亦记录：ultrawork、ultrapilot、swarm、pipeline 等已在 5.0.0 被移除（不是别名保留），改用 execute、verify、review、team 等。docs/MIGRATION.md 给出了精确映射表：ultrapilot → /oh-my-claudecode:team、swarm → /oh-my-claudecode:team。

Team 的规范形态是一个五段流水线（README 与 docs/ARCHITECTURE.md 均确认）：

team-plan → team-prd → team-exec → team-verify → team-fix (循环)

会话内用法：

/team 3:executor "fix all TypeScript errors"

如需启用 Claude Code 原生团队能力，在 ~/.claude/settings.json 配置：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

此外还有终端侧的 omc team N:<provider>，可拉起真实的 tmux CLI 面板运行 claude / codex / gemini / antigravity 等 worker（按需拉起、任务结束即退出，无空闲资源占用）。

选型建议：并行 Agent 适合三类任务——多组件系统（前端+后端+数据库）、具有清晰模块边界的大规模重构、以及大批量相互独立的批量修复任务（如"修复所有 TypeScript 错误"）。若任务含 3 个以上相互独立的组件，并行模式通常显著快于单线程 Autopilot。

3. Pipeline：顺序链式编排（当前对应 Execute / review 类 Skill）

研讨稿 "Mode 4: Pipeline" 的核心理念是 "像 Unix 管道一样连接 Agent"——上一个 Agent 的输出成为下一个 Agent 的输入：

/pipeline explore -> architect -> executor "add authentication"
[explore 发现] -> [architect 分析] -> [executor 实现]

研讨稿还给出了若干内置预设（presets），代表常见工作流的最佳实践编码：

Preset	阶段链	用途
`review`	explore → architect → critic → executor	大功能、重构
`implement`	planner → executor → tdd-guide	带测试的新功能
`debug`	explore → architect → build-fixer	Bug、构建错误
`research`	parallel(researcher, explore) → architect → writer	技术选型
`refactor`	explore → architect-medium → executor-high → qa-tester	安全重构
`security`	explore → security-reviewer → executor → security-reviewer-low	安全修复

自定义管道还支持在阶段上显式指定模型档位与并行段：

/pipeline explore:haiku -> architect:opus -> executor:sonnet "task"
/pipeline [explore, researcher] -> architect -> executor "task"

当前仓库的对应物：Pipeline 表面已退役，顺序数据处理工作流收敛到 execute Skill（见 docs/MIGRATION.md 中 pipeline → /oh-my-claudecode:execute）。同时 review、security 这类"评审/加固"语义仍以独立 Skill 形式存在（仓库 skills/ 下有 review、verify、research）。跨 Agent 传递上下文的数据协议理念，如今由 .omc/handoffs/ 等状态文件承载（见 docs/REFERENCE.md）。

选型建议：多阶段处理流程、代码评审流程、"调研→实现"转化类任务，应优先使用顺序链式编排；注意只有后一阶段强依赖前一阶段上下文时才需要 Pipeline/Execute，否则并行更划算。

4. Ecomode / 成本模式：Token 敏感的模型路由

研讨稿 "Mode 5: Ecomode" 是 OMC 成本治理思路的直接体现：优先用最便宜的模型（Haiku），只有在必要时才升级到 Sonnet，除非万不得已绝不使用 Opus。

研讨稿给出一张路由对照表（Ecomode 下同一任务会尝试低档 Agent，失败才升级）：

任务类型	Standard 模式	Ecomode
简单查询	architect-low	architect-low
标准实现	executor	executor-low（先试）
复杂分析	architect	architect-medium
规划	planner (Opus)	尽量避免

研讨稿强调其成本论据是"约 80% 的任务其实 Haiku 就能完成"——这一点对应当前仓库的三层模型成本结构（见下文"三层模型路由"）：Haiku 按 token 计费远低于 Opus，因此"能省则省"对高频迭代场景影响巨大。

当前仓库的对应物：成本治理已成为贯穿系统的设计主线，而非单一模式。证据包括：

docs/agents/model-compatibility.md 提供"模型 × Agent 兼容矩阵"，按 premium / balanced / budget 预设给出配模建议；
docs/PERFORMANCE-MONITORING.md 在成本优化章节直接建议 eco 式 token 高效执行；
README 将 "Cost optimization - Smart model routing saves 30-50% on tokens" 列为项目核心卖点。

选型建议：预算敏感项目、大量小改动组成的迭代式开发、探索性原型、个人项目，都应默认走低成本档位；把高成本模型留给真正的复杂推理。

三、Agent 体系：19 个基础专业 Agent + 三档模型路由

四车道 Agent 分工

当前仓库正式记录为 19 个专业 Agent，按 4 条"车道"组织（见 docs/ARCHITECTURE.md 与 agents/ 目录），每个 Agent 以 oh-my-claudecode:<agent-name> 形式被调用，并挂载默认模型档位：

构建/分析车道（Build/Analysis Lane）——覆盖从探索到验证的完整生命周期：

Agent	默认模型	职责
explore	haiku	代码库发现、文件/符号映射
analyst	opus	需求分析、隐藏约束发现
planner	opus	任务排序、执行计划创建
architect	opus	系统设计、接口定义、权衡分析
debugger	sonnet	根因分析、构建错误解决
executor	sonnet	代码实现、重构
verifier	sonnet	完成度验证、测试充分性确认
tracer	sonnet	证据驱动的因果追踪、竞争假设分析

评审车道（Review Lane）——交接前的质量门禁：

Agent	默认模型	职责
security-reviewer	sonnet	安全漏洞、信任边界、认证/授权审查
code-reviewer	opus	综合代码评审、API 契约、向后兼容

领域车道（Domain Lane）——需要时召入的领域专家：

Agent	默认模型	职责
test-engineer	sonnet	测试策略、覆盖率、防 flaky 测试
designer	sonnet	UI/UX 架构、交互设计
writer	haiku	文档、迁移说明
qa-tester	sonnet	通过 tmux 对交互式 CLI/服务做运行时验证
scientist	sonnet	数据分析、统计研究
git-master	sonnet	Git 操作、提交、rebase、历史管理
document-specialist	sonnet	外部文档、API/SDK 参考查询
code-simplifier	opus	代码清晰度、简化、可维护性改进

协调车道（Coordination Lane）：

Agent	默认模型	职责
critic	opus	对计划与设计做缺口分析、多角度评审

研讨稿中附录 A 提到的 architect-medium / executor-low 等带后缀变体，是"同职责 × 不同模型档位"的分层变体概念。在源码层，src/agents/definitions.ts 明确指出它"Re-exports base agents … Tiered agent variants with dynamically loaded prompts from /agents/*.md"——即基础 Agent 定义 + 按模型档位动态生成的变体，这与三档模型路由一一对应。每个 Agent 的 prompt 由 src/agents/utils.ts 中的 loadAgentPrompt 从 agents/ 目录下的同名 .md 文件动态加载，因此修改 Agent 行为的最直接方式就是编辑或新增这些 markdown 文件。

三层模型路由（3-Tier Model Routing）

研讨稿与当前仓库 docs/ARCHITECTURE.md 一致地定义了三档模型：

档位	模型	特征	相对成本
LOW	haiku	快而便宜	低
MEDIUM	sonnet	性能与成本均衡	中
HIGH	opus	最强推理	高

默认分配策略：

haiku：快速查找与简单任务（explore、writer）
sonnet：代码实现、调试、测试（executor、debugger、test-engineer、security-reviewer）
opus：架构、战略分析、评审（architect、planner、critic、code-reviewer）

分层设计的核心思想正如研讨稿所言："Always start low and escalate only when needed"（从低档起步，仅在必要时升级）。这也是 Ecomode/成本模式的底层依据。

智能委派与代码形态

委派通过 Claude Code 的 Task 工具完成，且模型参数总是显式传入（Claude Code 不会自动从 Agent 定义中推断模型，这是研讨稿特别提醒的实现细节）：

Task(
  subagent_type="oh-my-claudecode:executor",
  model="sonnet",
  prompt="Implement feature..."
)

src/features/delegation-categories/ 目录展示了"语义任务分类 + 自动检测"的实现：系统从任务文本中识别语义（如 "debug" → ultrabrain 分类），再据此自动调优档位、温度与思考强度。研讨稿给出了这种分类映射的示例：

分类	档位	Temp	Thinking	自动检测来源
visual-engineering	HIGH	0.7	high	"UI"、"component"、"style"
ultrabrain	HIGH	0.3	max	"debug"、"architecture"
artistry	MEDIUM	0.9	medium	"creative"、"brainstorm"
quick	LOW	0.1	low	"find"、"what is"、"where"
writing	MEDIUM	0.5	medium	"document"、"explain"

Agent 组合：Skill × Agent 的复合工作流

研讨稿强调"组合才是 OMC 真正发光的时刻"——把多个 Skill 叠加在 Agent 之上，就能得到恰好符合需求的行为组合：

ralph git-master: refactor authentication
  |       └──────────> Git 专长（原子提交）
  └──────────────────> 验证完成前不停止

结果：持久、并行、且具备 Git 意识的组合式重构。

典型 Agent 工作链（docs/ARCHITECTURE.md）：

explore --> analyst --> planner --> critic --> executor --> verifier
(发现)     (分析)     (排序)      (评审)    (实现)     (确认)

四、开发者体验：关键词、HUD、Notepad 与成本分析

Magic Keywords：零学习曲线的入口

研讨稿给出的关键词体系在当前仓库中大部分仍有效（准确清单以 docs/ARCHITECTURE.md 的 Magic Keyword Reference 为准）。核心思想是：关键词是可选的，自然语言同样工作，关键词只是给你显式控制权。

关键词	效果	示例
`autopilot` / `build me` / `I want a`	全自主执行流水线	`autopilot: build todo app`
`ralph` / `don't stop` / `must complete`	验证完成前持续循环	`ralph: fix auth bugs`
`ultrawork` / `ulw` / `uw`	最大并行编排	`ulw fix all errors`
`ralplan`	迭代式规划共识（Planner/Architect/Critic 循环）	`ralplan new feature`
`deepsearch` / `search the codebase`	代码库搜索模式	`deepsearch for auth middleware`
`deepanalyze` / `analyze`	深度分析模式	`analyze why test fails`
`ultrathink` / `think hard`	深度推理模式	`ultrathink about architecture`
`cancelomc` / `stopomc`	停止任何活动模式	`stopomc`

关键词可组合（研讨稿附录 C）：

ralph ulw: task        # 持久 + 并行
ralph eco: task        # 持久 + 省 token
autopilot eco: task    # 自动 + 省 token（更严格的模式获胜）

注：ralph 模式依赖 persistent-mode Hook（触发于 Stop 事件）——只要 ralph/持久类模式处于活动状态，Hook 会阻止 Claude 在验证完成前停下（docs/ARCHITECTURE.md）。这也是"boulder never stops（巨石永不停止）"注入提示的由来。

HUD：实时编排可视化

HUD 借助 Claude Code 的 statusLine API 把编排状态实时渲染到状态栏：

[OMC] autopilot:execution | agents:3 | todos:2/5 | ctx:45%

字段	含义
`autopilot:execution`	Autopilot 流水线中的当前阶段
`agents:3`	当前活动 Agent 数
`todos:2/5`	已完成任务 / 总任务
`ctx:45%`	上下文窗口占用百分比

配置方法：会话内运行

/oh-my-claudecode:hud setup

HUD 提供若干预设（研讨稿列 minimal/focused/full；docs/REFERENCE.md 的完整预设清单还包含 dense、analytics、opencode），默认值为 focused。配置文件中的形态为：

{
  "omcHud": {
    "preset": "focused"
  }
}

Notepad 智慧系统：跨会话的知识沉淀

研讨稿与当前仓库 docs/ARCHITECTURE.md 的状态管理章节高度一致：OMC 提供**按计划隔离（plan-scoped）**的知识捕获，存储在 .omc/notepads/{plan-name}/ 下：

文件	用途	示例
`learnings.md`	技术发现	"Redis 的限流键必须显式设置 TTL"
`decisions.md`	设计决策	"为了无状态扩展选择 JWT 而非 session"
`issues.md`	已知问题	"生产环境 OAuth 回调必须走 HTTPS"
`problems.md`	阻塞项	"限流需要一台 Redis 实例"

所有条目自动带时间戳。研讨稿展示的 API 形态（addLearning / getWisdomSummary 等）对应仓库中的 notepad 能力；同时仓库还维护一个全局压缩免疫备忘录 .omc/notepad.md，在 PreCompact 事件发生时写入、压缩后重新注入，保证关键上下文跨上下文窗口重置存活（相关 MCP 工具见 docs/ARCHITECTURE.md）。

成本与用量跟踪

README 将 "Analytics & cost tracking - Understand token usage across all sessions" 列为开发者体验特性。研讨稿示例给出了按模型、按模式汇总 token 用量与成本的报表形态（如下为示意）：

Session Summary (last 7 days)
Total sessions: 23   Total tokens: 1,234,567   Total cost: $18.45
By Model: Haiku ... / Sonnet ... / Opus ...
By Mode:  autopilot 45% / parallel 30% / other 15%

实际可观测的数据资产包括：会话摘要 .omc/sessions/*.json、回放日志 .omc/state/agent-replay-*.jsonl，以及 omc hud 的实时渲染（见 README "Monitoring & Observability"）。

五、上手路径：安装、首个任务与配置

安装（三种方式）

仓库 README 提供三种安装路径，npm 包名与仓库名不同，务必注意：

方式一：Claude Code Plugin Marketplace（会话内逐条执行，不能一次粘贴两行）

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode

方式二：npm 全局安装（仓库名是 oh-my-claudecode，但 npm 发布名是 oh-my-claude-sisyphus，安装后同时暴露 oh-my-claudecode 与短别名 omc）：

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

方式三：本地源码构建（开发或自定义场景）：

git clone https://github.com/Yeachan-Heo/oh-my-claudecode.git
cd oh-my-claudecode
npm install && npm run build

环境要求：Claude Code CLI；Claude Max/Pro 订阅或 Anthropic API key；Node.js 20+（package.json 的 engines 声明支持 20.x–26.x）。需要说明的是，OMC 面向 Claude Code 构建；它可以通过 omc team / omc ask 可选编排 Codex、Gemini、Antigravity 等外部 CLI 做交叉验证，但编排核心是 Claude Code（README "Optional: Multi-AI Orchestration" 明确这些外部提供方"不是必需"）。

三步走：第一个任务

Step 1 — 安装（见上）。Step 2 — 运行安装向导：

# Claude Code / OMC 会话内
/omc-setup

# 或从终端
omc setup

Step 3 — 用一句话构建：

/autopilot "build a REST API for managing tasks"

即可。若觉得 Autopilot 过重，可以先从单 Agent 关键词开始（docs/GETTING-STARTED.md）：

analyze why this test is failing          # 代码分析
deepsearch for files that handle auth     # 文件搜索
ultrawork add a health check endpoint     # 简单实现

这些关键词会直接调用单个合适的 Agent，而不跑完整流水线。

配置体系

OMC 支持两层配置文件（见 docs/GETTING-STARTED.md）：

作用域	路径	用途
项目级	项目根 `CLAUDE.md`、`.claude/omc.jsonc`	项目专属偏好与功能配置
用户全局	`~/.claude/CLAUDE.md`、`~/.claude/settings.json`	跨项目默认与 HUD/环境配置

关键配置点举例：

// ~/.claude/settings.json —— 启用 Claude Code 原生团队 + HUD
{
  "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" },
  "omcHud": { "preset": "focused" }
}

// .claude/omc.jsonc —— Autopilot 命名阶段配置（项目级）
{
  "autopilot": {
    "workflows": {
      "plan-build-qa": { "version": 1, "stages": ["ralplan", "execution", "qa"] }
    }
  }
}

（Autopilot 命名阶段配置的合法序列与约束，详见 docs/adr/03487-named-autopilot-stage-profiles.md 与 docs/REFERENCE.md。）

Agent 定制：编辑 agents/ 目录下同名 .md 即可修改 Agent prompt；新增 .md 文件即可创建自定义 Agent（研讨稿 Q&A 亦确认此机制）。

六、模式选型速查与常见问题

场景 → 模式对照（结合研讨稿与当前仓库能力）

使用场景	推荐模式/技能	原因
后端 API 开发	autopilot	完整端到端工作流
前端组件库	team（并行 agent）	大量相互独立的组件
数据库迁移	ralph	需要在错误中持续迭代直到验证通过
安全审计	security review / verify	结构化审查流程
Bug 分类与修复	team:executor	大量相互独立的修复
文档批量生成	team:writer	可并行写作
探索性原型	低成本档/Ecomode 思路	预算敏感的迭代

常见问题（研讨稿 Q&A 结合当前仓库校正）

Q：OMC 只支持 Claude Code 吗？能配合其他模型吗？ A：OMC 是为 Claude Code 构建的编排层，核心 Agent 均跑在 Claude 三档模型上；但可通过 omc team / omc ask 可选调用 Codex、Gemini、Antigravity、Grok、Cursor 等外部 CLI 做交叉验证与设计一致性检查，这些外部提供方并非必需。

Q：如何停止一个失控的 Autopilot？ A：直接说 "stop"、"cancel"，或运行 /oh-my-claudecode:cancel。

Q：HUD 不显示怎么办？ A：运行 /oh-my-claudecode:hud setup；若通过 claude --plugin-dir 启动，需导出 OMC_PLUGIN_ROOT=<path> 让 HUD 解析到与插件一致的代码路径（见 docs/REFERENCE.md 的 Plugin directory flags 一节）。

Q：能创建自定义 Agent 吗？ A：可以，在 agents/ 目录新增 .md 文件即可（每个 Agent 的 prompt 由 src/agents/utils.ts 的 loadAgentPrompt 动态加载）。

Q：有内置成本上限吗？ A：没有内置上限，但可通过低成本档位路由、Ecomode 思想与模型兼容矩阵（docs/agents/model-compatibility.md）主动控制成本。

Q：旧教程里的 /swarm、/pipeline、ultrapilot 怎么用？ A：它们在 v5.0.0 已移除而非别名保留，请使用映射后的规范命令：swarm/ultrapilot → /oh-my-claudecode:team、pipeline → /oh-my-claudecode:execute（见 docs/MIGRATION.md）。

七、结语：进一步阅读入口

oh-my-claudecode 的核心主张始终是 "Zero learning curve. Maximum power."（零学习曲线，最大能力）：不要求用户记忆复杂命令，而是通过自然语言 + Magic Keywords 触发编排，让 Claude 扮演指挥家、让专业 Agent 各司其职，再用 HUD、Notepad 与状态系统保证过程透明、经验可沉淀、成果可验证。

想继续深入，可直接阅读仓库内一手资料：