Oh-My-ClaudeCode
多智能体编排的终极指南
作者: OXY
|
2026-02-05
#Claude Code
#多智能体
#AI编排
#自动化开发
0 核心摘要 (TL;DR)
一句话精髓: Oh-My-ClaudeCode (OMC) 是一个让 Claude Code 从"单兵作战"进化为"军团指挥官"的多智能体编排系统——你只需说出想法，它会自动调度 32 个专业 Agent 并行工作，直到任务彻底完成。
认知挂钩
想象你是一个餐厅老板。以前你得亲自切菜、炒菜、端盘子、收银。现在你雇了 32 个专业员工：有切墩的、有掌勺的、有服务员、有收银员。你只需要说"今晚要做满汉全席"，他们就自动分工协作，直到客人满意离开。OMC 就是你的"餐厅管理系统"。
真理锚点
"Don't learn Claude Code. Just use OMC."
— Oh-My-ClaudeCode 官方标语
1 概念破冰 (Concept Ice-breaking)
巧记卡片
┌─────────────────────────────────────────────────────┐
│ 🧠 OMC 五模式记忆口诀 │
│ │
│ 「自超群管省」 │
│ │
│ 自 = Autopilot (自动驾驶，全程托管) │
│ 超 = Ultrawork (超级并行，极速执行) │
│ 群 = Swarm (群体智能，协同作战) │
│ 管 = Pipeline (管道流水，依次处理) │
│ 省 = Ecomode (省钱模式，精打细算) │
│ │
│ 加上 Ralph (拉尔夫) = 不达目的誓不罢休！ │
└─────────────────────────────────────────────────────┘
故事引入：西西弗斯的逆袭
从前有个程序员叫西西弗斯，每天推着"需求巨石"上山。石头一次次滚下来——Bug 没修完、测试没通过、代码审查被打回。
有一天，他遇到了一位名叫 Ralph（拉尔夫） 的智者。Ralph 说："你的问题不是石头太重，而是你一个人在推。"
Ralph 给了他一支"智能体军团"：
- 探索者 负责先上山侦察地形
- 建造者 负责铺设轨道
- 测试员 确保轨道安全
- 审计官 最终验收
从此，西西弗斯只需说一句"把石头送到山顶"，军团就自动协作，不达目的誓不罢休。这就是 Ralph 模式——"巨石永不停歇"。
可视化：OMC 架构总览
┌─────────────────┐
│ 👤 用户输入 │
│ "build a todo │
│ app" │
└────────┬────────┘
│
▼
┌──────────────────────────────┐
│ 🎯 技能检测引擎 (Skills) │
│ ┌─────┬─────┬─────┬─────┐ │
│ │Auto │Ultra│Swarm│Eco │ │
│ │pilot│work │ │mode │ │
│ └─────┴─────┴─────┴─────┘ │
└──────────────┬───────────────┘
│
▼
┌────────────────────────────────────────────┐
│ 🤖 智能体调度中心 (32 Agents) │
│ ┌──────────┬──────────┬──────────┐ │
│ │ 🔍 探索 │ ⚙️ 执行 │ 🎨 设计 │ │
│ │ explore │ executor │ designer │ │
│ ├──────────┼──────────┼──────────┤ │
│ │ 🏗️ 架构 │ 📝 文档 │ 🔬 科研 │ │
│ │architect │ writer │scientist │ │
│ ├──────────┼──────────┼──────────┤ │
│ │ 🛡️ 安全 │ 🧪 测试 │ 📊 分析 │ │
│ │ security │ qa-tester│ analyst │ │
│ └──────────┴──────────┴──────────┘ │
└────────────────────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ ✅ 验证 & 交付 │
│ Architect Verification │
└──────────────────────────────┘
2 深度解析 (Deep Analysis)
2.1 为什么需要多智能体编排？
单 Agent 的困境
- • 上下文窗口有限：难以同时处理架构、实现、测试、文档
- • 串行执行瓶颈：一个任务接一个，效率低下
- • 容易半途而废：遇到复杂问题会"认输"
多智能体的优势
- • 分工专业化：32 个 Agent 各司其职
- • 并行加速：速度提升 3-5 倍
- • 自愈能力：一个卡住，其他继续
- • 验证闭环：Architect 强制验证
2.2 八大执行模式详解
flowchart TD
subgraph Modes["执行模式选择"]
A["用户输入任务"] --> B{"任务类型判断"}
B -->|"完全自主"| C["Autopilot"]
B -->|"极速并行"| D["Ultrawork"]
B -->|"协调多任务"| E["Swarm"]
B -->|"顺序依赖"| F["Pipeline"]
B -->|"预算有限"| G["Ecomode"]
end
Autopilot（自动驾驶）
触发：autopilot: build a todo app
流程：需求分析 → 自动规划 → 并行执行 → 持续验证 → 自我纠错
最佳场景：从零开始构建新功能
Ultrawork（超级并行）
触发：ulw fix all errors
特点：激进委派、独立任务并行、最大化资源利用
最佳场景：多个独立任务需要同时处理
Ralph（拉尔夫/持久模式）
触发：ralph: refactor the entire codebase
由来：源自 "Ralph Wiggum" 技术——Y Combinator 黑客马拉松一夜生成 6 个仓库
机制：Stop Hook 拦截退出、任务清零检查、自动包含 Ultrawork
最佳场景：大型重构、必须完成的关键任务
Swarm（群体智能）
触发：swarm: process these 10 independent tasks
原理：N 个 Agent 共享任务池、SQLite 原子认领、避免重复
最佳场景：大量相似但独立的任务
Ecomode（经济模式）
触发：eco: fix all linting errors
优化：只用 Haiku + Sonnet，避免昂贵的 Opus，节省 30-50% Token
最佳场景：预算有限或任务复杂度较低
Team（团队协作）
触发：/oh-my-claudecode:team 重构整个认证系统
特点：N 个 Agent 组成团队，有任务列表、任务分配、互相通信（SendMessage）
流程：team-plan → team-prd → team-exec → team-verify → team-fix(循环)
最佳场景：大型复杂任务，需要多人分工协作
Ultrapilot（并行驾驶）
触发：ultrapilot 并行实现前后端
特点：按文件所有权分区并行，避免多 Agent 修改同一文件冲突，速度更快（3-5x）
注意：现为 Team 的兼容性门面（compatibility facade）
Pipeline（管道流水）
触发：pipeline 分析 → 规划 → 实现
特点：顺序 Agent 链，前一 Agent 的输出作为下一 Agent 的输入
最佳场景：有严格依赖顺序的任务
模式对比总结
| Autopilot | Ultrawork | Team | |
|---|---|---|---|
| Agent 数量 | 1 个 | 多个（无状态） | N 个（有状态） |
| 执行方式 | 串行 | 并行 | 协作 |
| Agent 通信 | 无 | 无 | 有（SendMessage） |
| 任务管理 | 内置自动 | 无 | TaskList 共享 |
| 适合规模 | 小/中 | 中（多独立子任务） | 大/复杂 |
| 速度 | 基准 | 快（并行） | 中（协调开销） |
选择建议
- • "帮我做个页面" → autopilot
- • "同时修 10 个 bug" → ultrawork
- • "重构整个后端架构" → team
- • "必须完成，不能半途而废" → ralph
- • "预算有限" → ecomode
2.3 智能体三层架构
| 层级 | 模型 | 成本 | 适用任务 | 示例 Agent |
|---|---|---|---|---|
| Low | Haiku | 💰 | 简单查找、快速操作 | explore, executor-low |
| Medium | Sonnet | 💰💰 | 标准开发、一般分析 | executor, designer |
| High | Opus | 💰💰💰 | 复杂推理、架构决策 | architect, analyst |
2.4 生命周期 Hooks
sequenceDiagram
participant U as 用户
participant H as Hooks
participant C as Claude
participant A as Agents
U->>H: 发送消息
H->>H: SessionStart
H->>H: UserPromptSubmit
H-->>C: 注入上下文
C->>A: 委派任务
A->>A: PreToolUse
A->>A: 执行工具
A->>A: PostToolUse
A-->>C: 返回结果
C->>H: 尝试停止
H->>H: Stop Hook
H-->>C: 未完成则拦截
关键 Hook
- • SessionStart：注入优先上下文、恢复模式状态
- • UserPromptSubmit：检测魔法关键词、激活技能
- • Stop：在执行模式下阻止过早退出
- • PreToolUse/PostToolUse：工具执行前后的干预点
3 28+ Agent 完全手册
Agent 通过 Task(subagent_type="oh-my-claudecode:xxx") 调用。你不需要手动操作，OMC 会自动委派。也可以显式指定：
用 architect 分析一下这个模块的架构
用 executor 实现这个功能3.1 构建与分析（Build/Analysis Lane）
| Agent | 模型 | 职责说明 |
|---|---|---|
| explore | haiku | 内部代码库发现、符号/文件映射、快速搜索 |
| analyst | opus | 需求清晰化、验收标准、隐藏约束挖掘 |
| planner | opus | 任务排序、执行计划制定、风险标记 |
| architect | opus | 系统设计、边界划分、接口定义、长期技术权衡 |
| debugger | sonnet | 根因分析、回归隔离、堆栈追踪、故障诊断 |
| executor | sonnet | 代码实现、重构、功能开发（常规任务） |
| deep-executor | opus | 复杂自主目标导向任务（大规模改动） |
| verifier | sonnet | 完成度证据收集、声明验证、测试充分性检查 |
3.2 审查通道（Review Lane）
| Agent | 模型 | 职责说明 |
|---|---|---|
| style-reviewer | haiku | 格式化、命名规范、代码风格、lint 惯例 |
| quality-reviewer | sonnet | 逻辑缺陷、可维护性、反模式、SOLID 原则 |
| api-reviewer | sonnet | API 契约、版本管理、向后兼容性 |
| security-reviewer | sonnet | 漏洞检测、信任边界、认证/授权审查 |
| performance-reviewer | sonnet | 热点分析、算法复杂度、内存/延迟优化 |
| code-reviewer | opus | 跨关注点综合审查（最全面） |
3.3 领域专家（Domain Specialists）
| Agent | 模型 | 职责说明 |
|---|---|---|
| dependency-expert | sonnet | 外部 SDK/API/包评估与文档查询 |
| test-engineer | sonnet | 测试策略、覆盖率、脆弱测试加固、TDD 流程 |
| quality-strategist | sonnet | 质量策略、发布就绪评估、风险评估 |
| build-fixer | sonnet | 构建/工具链/类型错误修复（最小改动） |
| designer | sonnet | UX/UI 架构、交互设计、组件开发 |
| writer | haiku | 文档撰写、迁移说明、用户指南 |
| qa-tester | sonnet | 交互式 CLI/服务运行时验证 |
| scientist | sonnet | 数据/统计分析、研究执行 |
| git-master | sonnet | 提交策略、历史管理、原子提交、变基 |
3.4 产品通道（Product Lane）
| Agent | 模型 | 职责说明 |
|---|---|---|
| product-manager | sonnet | 问题框架、用户画像/JTBD、PRD 生成 |
| ux-researcher | sonnet | 启发式审计、可用性研究、无障碍评估 |
| information-architect | sonnet | 分类体系、导航模型、信息可发现性 |
| product-analyst | sonnet | 产品指标、漏斗分析、实验设计 |
3.5 协调角色（Coordination）
| Agent | 模型 | 职责说明 |
|---|---|---|
| critic | opus | 计划/设计的批判性挑战 |
| vision | sonnet | 图片/截图/图表分析 |
4 Skill 完全手册
4.1 执行模式 Skill
| Skill | 触发词 | 说明 |
|---|---|---|
| autopilot | autopilot、build me、I want a | 全自动：从想法到可运行代码 |
| ultrawork | ultrawork、ulw | 最大并行：多 Agent 同时工作 |
| ralph | ralph、don't stop、must complete | 死磕模式：含自我验证循环 |
| ecomode | eco、ecomode、budget | 省 Token：用低成本模型 |
| team | team、coordinated team | 团队协作：N 个 Agent 协同 |
| swarm | swarm | 群体智能：兼容门面 → Team |
| ultrapilot | ultrapilot、parallel build | 并行驾驶：文件所有权分区 |
| pipeline | pipeline、chain agents | 管道流水：顺序链式执行 |
| ultraqa | 由 autopilot 激活 | QA 循环：测试→验证→修复→重复 |
4.2 规划类 Skill
| Skill | 触发词 | 说明 |
|---|---|---|
| plan | plan this、plan the | 启动规划会话，支持 --consensus 和 --review |
| ralplan | ralplan、consensus plan | 多模型共识规划（Planner + Architect + Critic 迭代） |
| review | review plan、critique plan | 审查已有计划（/plan --review 的别名） |
4.3 分析类 Skill
| Skill | 触发词 | 说明 |
|---|---|---|
| analyze | analyze、debug、investigate | 深度分析/调试 → 底层调用 debugger |
| deepsearch | search、find in codebase | 多策略代码搜索 → 底层调用 explore |
| code-review | review code | 综合代码审查 |
| security-review | security review | 安全审查 |
| research | research、analyze data | 并行 scientist 做综合研究 |
4.4 Agent 快捷 Skill
| Skill | 底层 Agent | 触发词 |
|---|---|---|
| tdd | test-engineer | tdd、test first、red green |
| build-fix | build-fixer | fix build、type errors |
| frontend-ui-ux | designer | UI/组件/样式工作（自动检测） |
| git-master | git-master | git/commit 工作（自动检测） |
4.5 工具类 Skill
| Skill | 说明 |
|---|---|
| cancel | 取消当前运行的任何模式 |
| note | 保存笔记到 notepad.md（抗上下文压缩） |
| learner | 从当前对话中提取已学技能 |
| omc-setup | 设置/配置 OMC（安装后首要命令） |
| mcp-setup | 配置 MCP 服务器 |
| hud | 配置 HUD 显示（布局、预设、元素） |
| doctor | 诊断并修复安装问题 |
| help | 查看使用帮助 |
| trace | 查看 Agent 流程追踪时间线 |
| deepinit | 深度代码库初始化，生成层级 AGENTS.md |
| psm | 项目会话管理器（git worktree + tmux） |
| ralph-init | 初始化 PRD 用于结构化 ralph 执行 |
4.6 MCP 委托 Skill
| 短语 | 路由目标 |
|---|---|
| ask codex、use codex、delegate to codex | Codex (OpenAI) |
| ask gpt、use gpt、delegate to gpt | Codex (OpenAI) |
| ask gemini、use gemini、delegate to gemini | Gemini (Google) |
* 单独出现关键词（无意图短语）不触发委托。
5 深度裂变 (Deep Fission)
颠覆认知的技术真相
真相 1：Ralph 不是新发明
🔍 搜索内化：Ralph Wiggum 技术最早由社区开发者创造，本质是一个简单的 Bash 循环：
while :; do cat PROMPT.md | claude ; doneAnthropic 后来将这个模式产品化。规律：社区创新 → 官方吸收
真相 2：多智能体 ≠ 多模型
OMC 的 32 个 Agent 都是 Claude，只是携带不同的系统提示、使用不同的模型层级、专注不同的任务领域。
本质：一个 LLM + 多个角色扮演 + 智能路由
真相 3：Hooks 的双刃剑
正面：自动注入上下文、强制验证、防止过早退出
风险：可能"停不下来"、必须用 /cancel 清理、状态文件损坏
真相 4：Token 成本的隐藏陷阱
- • Ecomode 省钱，但牺牲了 Opus 的复杂推理能力
- • Ultrawork 并行执行，总 Token 可能更高（并行 ≠ 节省）
- • 真正的省钱来自智能路由：简单用 Haiku，复杂才用 Opus
6 外部 AI 集成（MCP 工具）
OMC 通过 MCP 工具集成了两个外部 AI：
| 提供商 | 模型 | 擅长领域 | 推荐角色 |
|---|---|---|---|
| Codex (OpenAI) | gpt-5.3-codex | 后端、架构、安全审查、批判性分析 | architect, planner, critic, code-reviewer, security-reviewer |
| Gemini (Google) | gemini-3-pro-preview | 前端、UI/UX、大上下文分析（1M token） | designer, writer, vision |
6.1 直接调用
# 基础调用
ask codex 审查这个 API 的安全性
ask gemini 审查这个组件的 UI 设计
# 指定角色调用
ask codex 以 security-reviewer 角色审查这段代码
ask gemini 以 designer 角色审查前端组件
ask codex 以 critic 角色审查这份规划方案6.2 多模型协作命令（CCG 系列）
| 命令 | 说明 |
|---|---|
| /ccg:analyze | 多模型技术分析：Codex 后端视角 + Gemini 前端视角 |
| /ccg:plan | 多模型协作规划：双模型分析 → Step-by-step 计划 |
| /ccg:execute | 多模型协作执行：获取原型 → Claude 重构 → 多模型审计 |
| /ccg:workflow | 完整工作流：研究→构思→计划→执行→优化→评审 |
| /ccg:backend | 后端专项工作流，Codex 主导 |
| /ccg:frontend | 前端专项工作流，Gemini 主导 |
| /ccg:review | 多模型代码审查：双模型交叉验证 |
| /ccg:test | 多模型测试生成：智能路由后端/前端测试 |
| /ccg:debug | 多模型调试：Codex 后端 + Gemini 前端交叉定位 |
| /ccg:optimize | 多模型性能优化：Codex 后端 + Gemini 前端 |
| /ccg:oxyccg | 完整一条龙：OMC + Codex + Gemini 全流程协作 |
| /all-plan | 所有挂载 CLI 共同参与规划 |
7 持久化与状态管理
7.1 文件结构
所有 OMC 状态存储在项目 git worktree 根目录下，不在 ~/.claude/：
{worktree}/
├── .omc/
│ ├── state/ # 模式状态文件
│ │ ├── autopilot-state.json
│ │ ├── ralph-state.json
│ │ ├── ultrawork-state.json
│ │ └── sessions/{sessionId}/ # 会话级状态
│ ├── notepad.md # 会话记事本
│ ├── project-memory.json # 项目记忆（持久）
│ ├── plans/ # 规划文档
│ ├── research/ # 研究输出
│ └── logs/ # 审计日志7.2 记事本系统（Notepad）
| 区段 | 说明 | 生命周期 |
|---|---|---|
| Priority | 优先上下文（≤500字），会话开始时自动加载 | 永久 |
| Working | 工作记忆，带时间戳 | 自动清理（7天） |
| Manual | 手动笔记 | 永不清理 |
使用方式：
- •
<remember>info</remember>— 持久化信息（7天） - •
<remember priority>info</remember>— 永久持久化
7.3 项目记忆（Project Memory）
持久存储在 .omc/project-memory.json，包含：
- • techStack — 技术栈信息
- • build — 构建配置
- • conventions — 编码约定
- • structure — 项目结构
- • notes — 分类笔记
- • directives — 用户指令（跨会话生效）
8 完整工作流指南
8.1 推荐三步法：分析 → 规划 → 执行
1. 分析阶段
# 常规分析（debugger 底层）
analyze 分析当前项目的认证模块，梳理现有架构和问题
# 架构级分析
用 architect 分析认证模块的架构边界和设计问题2. 规划阶段
# 普通规划（Planner 单独）
plan 规划认证模块的重构方案
# 共识规划（Planner + Architect + Critic 三方迭代）
ralplan 规划认证模块的重构方案
# 审查已有计划
/oh-my-claudecode:review .omc/plans/xxx.md3. 执行阶段
# 并行执行（快）
ultrawork 按照计划执行所有步骤
# 死磕模式（稳，不完成不停止）
ralph 按照计划执行，全部完成并通过验证
# 省 token
eco 按照计划执行
# 多 Agent 团队协作
/oh-my-claudecode:team 按照计划执行重构8.2 调试 Bug 流程
# 方式一：关键词触发
analyze 为什么登录接口返回 500 错误
# 方式二：显式命令
/oh-my-claudecode:analyze 登录接口 500 错误
# 分析完后修复
ultrawork 根据分析结果修复这个 bug8.3 完整示例：重构认证模块
# 1. 分析
analyze 分析认证模块的架构、安全隐患和技术债
# 2. 规划（多方共识）
ralplan 基于分析结果规划重构方案
# 3. 外部验证（可选）
ask codex 以 architect 角色审查这份规划
ask gemini 以 critic 角色挑战这份规划的薄弱点
# 4. 执行
ralph 按计划执行所有步骤，完成并验证
# 5. 审查（可选）
/oh-my-claudecode:code-review
/oh-my-claudecode:security-review8.4 多模型完整工作流
# 多模型分析
/ccg:analyze 分析当前认证模块的架构问题和安全隐患
# 多模型共识规划
/ccg:plan 基于分析结果，规划认证模块重构方案
# 多模型协作执行
/ccg:execute 按照计划执行重构
# 或者一条龙
/ccg:oxyccg 完整的认证模块重构9 实战指南 (Actionable Guide)
9.1 安装步骤
# 步骤 1：添加市场源
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
# 步骤 2：安装插件
/plugin install oh-my-claudecode
# 步骤 3：运行设置向导
/oh-my-claudecode:omc-setup
# 步骤 4：开始使用
autopilot: build a REST API for task management9.2 魔法关键词速查
| 关键词 | 效果 | 使用示例 |
|---|---|---|
| autopilot | 全自动执行 | autopilot: build a chat app |
| ralph | 持久模式 | ralph: refactor all tests |
| ulw | 极速并行 | ulw fix all TypeScript errors |
| eco | 省钱模式 | eco: add input validation |
| plan | 规划访谈 | plan the new payment system |
模式冲突优先级
- • 显式模式关键词（
ulw、eco）覆盖默认行为 - • 同时出现时：ecomode 优先
- • Ralph 自动包含 ultrawork
- • Autopilot 和 ultrapilot 互斥
9.3 日常使用建议
按任务复杂度选择
- 简单任务 → 直接提问，OMC 自动委派合适 Agent
- 中等任务 → 用
ultrawork或autopilot - 大型任务 → 先
plan规划，再ultrawork或team执行 - 要求完美 → 用
ralph，反复验证直到完全通过 - 省预算 → 用
eco
9.4 避坑指南
坑 1：忘记取消执行模式
症状：Claude 停不下来，一直说"继续工作"
解决：/oh-my-claudecode:cancel 或 /oh-my-claudecode:cancel --force
坑 2：状态文件损坏
症状：模式行为异常，Hook 报错
解决：rm -rf .omc/state/*.json
坑 3：过度并行导致混乱
症状：多个 Agent 同时修改同一文件
解决：使用 ultrapilot 而非 swarm——前者有文件所有权分区
坑 4：Ecomode 处理复杂任务
症状：Ecomode 下复杂推理任务效果差
解决：复杂任务用 ralph 或 autopilot
10 FAQ：8 个刁钻问题
原生 Claude Code 提供基础的 TeammateTool，OMC 在此之上添加了：5 种执行模式、32 个预配置专业 Agent、37+ 技能和 31 个生命周期 Hook、智能模型路由和成本优化、持久执行保障（Ralph）
理论上不会。Ralph 有多重保护：最大迭代次数限制、Architect 验证通过则允许退出、用户可随时用 /cancel 终止、状态文件清理机制。
部分可以：Ralph 自动包含 Ultrawork、Ecomode 可以叠加到其他模式。但不建议同时激活 Swarm + Pipeline（逻辑冲突）。
支持。OMC 支持 macOS、Linux 和 Windows。但部分高级功能（如 tmux 会话检测）在 Windows 上需要 WSL。
使用 HUD：
/oh-my-claudecode:hud，显示当前模式、活跃 Agent、任务进度、Token 消耗等。
建议重新运行：
/oh-my-claudecode:omc-setup。这会应用新版本的配置变更，同时保留你的个性化设置。
目前不支持完全自定义，但你可以：使用 /oh-my-claudecode:learner 从对话中提取技能、通过 CLAUDE.md 注入自定义指令、在
.claude/agents/ 定义自定义 Agent、贡献代码到官方仓库。
Swarm：N 个 Agent 抢占共享任务池，适合同质化任务。Ultrapilot：按文件所有权分区，适合多组件并行开发，速度更快（3-5x）。
11 速查总表
| 我想要... | 用什么 |
|---|---|
| 分析问题 | analyze / /ccg:analyze |
| 单人规划 | plan xxx |
| 共识规划 | ralplan xxx |
| 审查计划 | /oh-my-claudecode:review |
| 并行执行 | ultrawork / ulw xxx |
| 执行到底 | ralph xxx |
| 省 token | eco xxx |
| 团队协作 | /oh-my-claudecode:team xxx |
| 调试 Bug | analyze xxx |
| Codex 参与 | ask codex 以 xxx 角色做 yyy |
| Gemini 参与 | ask gemini 以 xxx 角色做 yyy |
| 代码审查 | /oh-my-claudecode:code-review |
| 安全审查 | /oh-my-claudecode:security-review |
| 全自动执行 | autopilot xxx |
| 多模型协作 | /ccg:workflow / /ccg:oxyccg |
| 一条龙全流程 | /ccg:oxyccg 需求描述 |
核心记住：analyze → plan/ralplan → ultrawork/ralph，三步覆盖绝大多数场景。
📝 自测题
- Q1: OMC 的五大执行模式分别是什么？各自的核心特点？
- Q2: Ralph 模式的名称来源于什么？它的核心机制是什么？
- Q3: 为什么说"Ralph 自动包含 Ultrawork"？
- Q4: OMC 的 32 个 Agent 分为哪三个层级？分别对应什么模型？
- Q5: Ecomode 如何实现 30-50% 的成本节省？有什么代价？
- Q6: 当 Claude 在 Ralph 模式下"停不下来"时，应该怎么做？
- Q7: Swarm 和 Ultrapilot 的主要区别是什么？
- Q8: Stop Hook 的作用是什么？它检查什么条件来决定是否允许退出？