OMC - 01 用 19 个 Agent 打造你的 Claude Code“工程团队”：oh-my-claudecode 深度解析与实战指南

在多 Agent 编排成为新一代 AI 开发基础设施的今天，如何把一个“聪明但孤立”的模型，变成一个“有分工、有流程、有记忆”的工程团队，是每一个开发者都会遇到的问题。

针对 Claude Code 生态，oh-my-claudecode（简称 OMC）给出了一套极具工程化气质的答案：在不要求你学习复杂指令和配置的前提下，把单一会话升级为由 19 个专用 Agent 组成的协同系统，并通过Hooks、Skills、Agents、State四大支柱，把“多 Agent 编排”做成可插拔、可扩展、可调试的基础层。

本文将从整体架构、Agent 设计、编排模式、使用方式和工程实践等维度，系统拆解 OMC 这套多 Agent 编排层，以工程视角理解其设计思路，并给出适合本地开发与团队协作的使用建议。

一、OMC 是什么：为 Claude Code 打造的“多 Agent 操作系统”

1.1 核心定位：为 Claude Code 构建多 Agent 编排层

OMC 的目标很明确：让开发者“无需学习 Claude Code 的复杂用法，只要直接使用 OMC”，由系统自动完成 Agent 选择、模型路由与任务执行闭环。

其核心能力包括：

• 将单个 Claude Code 会话升级为“由 19 个专用 Agent 组成的团队”，覆盖探索、设计、实现、调试、测试、安全审查、文档编写等完整生命周期。
• 自动检测用户意图（例如通过“魔法关键词”），将任务委派给合适的 Agent，并选择合适的模型层级（haiku / sonnet / opus），避免“全程用最贵模型”的粗暴做法。
• 持续执行任务直到通过自动验证，避免“看似完成、实则半拉子”的隐形失败。

在使用形态上，OMC 既是一个 npm 包oh-my-claude-sisyphus，也是一个可在 Claude Code 插件市场安装的插件，采用 MIT 许可证，由 Yeachan Heo 维护，并吸引了社区贡献。

1.2 目标用户：把 AI 当“开发基础设施”的人

从功能设计可以看出，OMC 不只是给“体验 AI 工具”的用户，而是给以下人群：

• 日常在 Claude Code 中开发，希望提升多文件重构、测试补全、架构评审等复杂任务效率的工程师。
• 需要长期维护大代码库，希望 AI 能具备“记忆”和“规范约束”的团队。
• 对多 Agent / 多模型编排感兴趣的研究者和爱好者，希望在一个可观测、可扩展的系统中做实验。

如果你已经习惯“一个 ChatGPT 打天下”的模式，OMC 会让你体验到：AI 可以变成一支有角色分工和质量流程的工程团队，而不仅仅是一个回答问题的助手。

二、整体架构：四大支柱构成的处理流水线

OMC 的架构围绕一个“按步骤处理每个用户提示词”的流水线展开，核心由四个子系统构成：

1. Hooks（钩子）
2. Skills（技能）
3. Agents（智能体）
4. State（状态与记忆）

理解这条流水线，是使用和扩展 OMC 的基础。

2.1 Hooks：把会话事件变成“可编程中断”

Hooks 是整个系统的第一层入口。

• 大约 20 个生命周期钩子，覆盖会话启动、工具调用、提示提交、上下文压缩等关键事件。
• 通过这些钩子，OMC 可以：
  • 检测“魔法关键词”（如ralph、ulw、autopilot）。
  • 强制执行某种模式（例如确保 Ralph 模式在长时间任务中保持持久）。
  • 注入质量门禁（比如所有提交必须经过某个验证 Agent）。
• 钩子以声明式写在hooks.json中，对应的逻辑以 Node.js 脚本执行，单个钩子有 5 秒的时间预算。

从工程角度看，Hooks 就像是对 Claude Code 事件流的“拦截层”，把原本黑盒的 IDE 交互，变成可以插入自定义逻辑的“中断处理程序”。

适合做什么？

• 在用户输入中检测关键模式（例如“重构整个模块”、“修复所有测试失败”），自动切换到更强的编排模式（如 Team / Ultrawork）。
• 在敏感操作前后插入安全审查或测试执行（例如重大重构后必跑test-engineer）。
• 实现团队级规范：强制 PR 描述生成、变更日志生成、文档同步更新等。

2.2 Skills：把行为抽象为可复用“技能模块”

Skills 是第二层，也是行为注入与路由决策的核心。

• 当 Hooks 检测到某个条件时，会“激活”一个或多个技能。
• 每个技能是一个自包含的行为模块，用来：
  • 注入系统指令（例如进入autopilot模式）。
  • 添加约束（例如“必须先生成计划再开始修改代码”）。
  • 定义路由逻辑（例如根据任务类型挑选 Agent 或模型）。

内置技能包括：

• 编排类：autopilot、ralph、ultrawork、team—— 定义整套多 Agent 工作流。
• 实用类：ask、trace、verify—— 面向问答、追踪、验证等场景。
• 学习 / 记忆类：learner、remember—— 把经验沉淀到 Notepad wisdom 中，支持跨会话复用。

更重要的是，用户可以：

• 在项目级.omc/skills/或用户级~/.omc/skills/目录中编写自定义技能，适配特定代码库、团队规范或工作流。

工程启示：

技能系统相当于一个“高层策略层”：Hooks 负责“何时触发”，Skills 负责“触发后如何行动”，而真正执行动作的是后面的 Agents。
这带来的好处是：

• 你可以针对不同项目定义完全不同的一套“工作方式”，而无需修改底层 Agent 逻辑。
• 团队可以把“经验和流程”固化成技能，在新成员加入时直接复用。

2.3 Agents：19 个专用角色构成的工程团队

Agents 是执行单元，也是多 Agent 系统中最直观的部分。

OMC 提供了 19 个专用 Agent，按“泳道”划分为四大类：

每个 Agent 都具备三类关键属性：

1. 模型层级：精心挑选 haiku / sonnet / opus 等不同模型，平衡成本与能力。
2. 工具集：只暴露与其职责相关的工具，避免任务“越权”。
3. 系统提示词：让 Agent 具备清晰的角色意识与行为边界。

调用方式上，这些 Agent 通过 Claude Code 的 Task 工具暴露，前缀统一为oh-my-claudecode:，方便在会话内或系统内部路由调用。

2.4 State：把“经验”和“进度”固化下来

在多轮、多 Agent 协作中，“状态管理”是最容易被忽视，却又最关键的部分。

OMC 为此设计了统一的状态系统，主要包含几类信息：

• boulder 状态：用于规划与进度追踪，可以理解为“任务石块”的状态机（未开始、进行中、已完成、阻塞等）。
• notepad wisdom：Agent 在执行任务时，会记录下经验、决策理由、坑点和 TODO，后续会话可以作为知识库复用。
• 会话摘要：用于在上下文压缩时保留关键信息，使长任务不会因为 token 限制而“失忆”。
• 回放日志：记录多 Agent 协作过程，支持调试和复盘。

这些状态在上下文压缩和会话恢复之间保持持续存在，让长时间运行的任务具备“工程级韧性”。

三、模型路由策略：用对模型，比“用最强模型”更重要

在多 Agent 系统中，“一个任务用哪种模型跑”直接决定成本和体验。

OMC 没有简单粗暴地用最高级模型，而是制定了一套分层路由策略：

• haiku：主打速度与成本，适合：
  • 快速代码探索（explore）。
  • 文本生成与轻量写作（writer）。
• sonnet：作为默认工作马，适合：
  • 日常代码实现与修改（executor）。
  • 调试与问题定位（debugger）。
  • 测试补全与生成（test-engineer）。
• opus：用于高价值的深度推理任务：
  • 架构与规划（architect、planner）。
  • 高要求评审（critic、code-reviewer）。

通过这种分层策略，相比“所有请求都走最贵模型”，预计可以节省 30–50% 的 token 成本，同时在绝大多数场景中保持甚至提升效果。

对开发者的启示：

• 不要只问“哪个模型更强”，而要问“哪个任务需要更强的模型”。OMC 把这套映射显式固化在路由层，你也可以在自定义技能中做类似的策略。
• 高级模型更适合“思考型任务”（规划、评审、设计），而不是“大量机械实现”；后者交给中阶模型更划算。

四、六大编排模式：从单兵作战到多模型协同

OMC 提供了一系列“编排模式”，本质上是对“Agent 组合 + 并行策略 + 持久化行为”的预设方案。
这些模式非常贴近实际开发中会遇到的任务类型。

4.1 模式总览

4.2 Team 模式：把“敏捷开发流水线”搬进 AI

Team 模式是 OMC 最推荐、也最具代表性的模式。

其典型流程包括：

1. planner/architect分析需求，拆解为任务列表（类似 backlog）。
2. writer/designer搭建 PRD、接口约定、UI 草图等交付物。
3. executor分阶段实现代码，debugger/test-engineer负责保障质量。
4. verifier、qa-tester和critic组成质量闭环，必要时触发修复循环。

从体验角度看，Team 模式让你感觉不再是“和一个模型聊天”，而是“在和一个 AI 团队协作做项目”。

使用注意：

• 需要在~/.claude/settings.json中启用CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS环境变量，否则 OMC 会降级为非团队模式，并给出警告。

4.3 Autopilot：给一个聪明的“主力工程师”开路

Autopilot 模式更接近很多人理想中的“全自动开发”：

• 由一个主导 Agent 负责端到端完成任务，从理解需求到输出代码。
• 适合业务逻辑较清晰、依赖关系简单的任务，例如“为现有接口增加一个字段，并同步前端页面显示”。

其优势是交互简单、上手快，但在任务拆分和质量把控上不如 Team 模式精细，更适合中小任务或个人项目。

4.4 Ultrawork：为“大规模并行改造”而生

Ultrawork 模式的设计目标很直接：去掉管理层开销，最大化并行度。

典型使用场景：

• 批量把某个旧 API 替换成新 API。
• 在上百个文件中统一改造日志系统或错误处理模式。
• 为大量缺失测试的模块补全基础用例。

在该模式下，Team 式的“计划—验收—修复”环节会减少或弱化，更关注在短时间内完成尽可能多的子任务，因此适合有一定人工复核能力的团队使用。

4.5 Ralph 与 Ralplan：让“没做完就别停”成为默认

Ralph 系列模式体现了 OMC 对“工程完备性”的偏执：

• Ralph：不以“模型觉得差不多了”为完成标准，而是要求通过明确的验证环节，否则继续修复、重试或调整策略。
• Ralplan：先用多轮规划迭代达成共识（通常由planner、architect、critic等 Agent 参与），在规划质量达到一定水平之前不会轻易进入执行阶段。

对于那些“必须做完”的任务（例如支付链路改造、安全加固、数据迁移），使用 Ralph 能显著减少“隐形未完成”的风险。

五、两种使用界面：IDE 插件 + 终端 CLI 双剑合璧

OMC 提供了两种入口形式：Claude Code 插件和终端 CLIomc。
二者设计为互补关系，很多用户会同时使用。

5.1 Claude Code 插件：无缝融入日常开发流

安装方式：

• 在 Claude Code 中通过/plugin marketplace add将插件源加入市场。
• 使用/plugin install安装 oh-my-claudecode 插件。

安装后可以获得：

• 会话内斜杠命令：/autopilot、/ralph、/team等，用来快速切换模式。
• 所有 Agent 和 Skills 能力，自动随对话上下文注入。
• Hooks 带来的“魔法关键词”行为，例如在对话中自然输入ralph启用特定模式。
• HUD 状态栏，在终端显示当前编排状态、token 用量和成本等实时指标。
• MCP 工具集成，包括对代码的 LSP 支持、AST 分析工具等。

非常适合：日常在 Claude Code 里写代码、调试与重构的开发者，把 OMC 当作“增强版 IDE 智能后端”。

5.2 终端 CLI：面向自动化与批处理的“脚本入口”

安装方式：

npmi-goh-my-claude-sisyphus@latest

安装后提供omc命令行工具，典型子命令包括：

• omc setup：引导进行基础配置（API Key、默认模型、通知渠道等）。
• omc team：以 Team 模式在终端发起多 Agent 任务。
• omc ask：针对某个问题进行一次性问答或分析。
• omc autoresearch：用于自动化调研和信息收集任务（常与多 Agent 协同）。
• omc wait：等待长任务执行完成，并在完成后进行后续处理或通知。

CLI 会自动检测 Claude Code 插件是否安装，以避免重复注入技能，两者共享：

• ~/.claude/omc.jsonc：统一配置文件。
• .omc/：统一的状态目录（包含状态、记忆、日志等）。

这让你可以在“本地开发 + CI/CD + 自动化脚本”之间复用同一套智能基础设施。

六、代码结构与扩展点：如何把 OMC 当成一个“二次开发平台”

对于有定制需求的团队和开发者，理解 OMC 的代码组织非常重要。

6.1 核心目录结构

OMC 采用模块化 TypeScript 架构，按照职责拆分为多个子模块：

• src/agents/：
  Agent 的定义、模型路由和委派逻辑是放在这里，适合扩展或定制某些角色的行为。
• src/features/：
  实现魔法关键词、后台任务（例如周期性扫描）、notepad wisdom 相关逻辑。
• src/hooks/：
  负责钩子编排与上下文注入，是事件流的第一入口。
• src/skills/：
  负责加载、扩展与管理技能生命周期，是策略层的关键。
• src/mcp/：
  MCP 工具服务器，提供扩展工具、LSP 支持和 AST 分析。
• src/team/：
  Team 流水线编排逻辑所在，定义多 Agent 协作的具体流程。
• src/config/：
  配置加载与校验，确保运行时行为与配置一致。
• src/tools/：
  自定义工具实现，可以在技能或 Agent 中调用。
• src/index.ts：
  暴露公共 API，如createOmcSession()、enhancePrompt()，方便在其他 Node.js 项目中嵌入使用。

在仓库根目录，还有与产品能力紧密相关的内容：

• agents/：19 个 Agent 对应的提示词文件（Markdown）。
• skills/：33 个内置技能，每个都附带一个SKILL.md作为说明。
• hooks/：hooks.json中定义了所有生命周期钩子。
• scripts/：钩子脚本及构建 / 安装相关工具。
• bridge/：CLI 与 MCP 服务器入口的桥接代码。
• templates/：交付物模板、规范模板、钩子模板等。
• docs/、benchmarks/、tests/、examples/：文档、性能基准、测试和使用示例。

6.2 典型扩展方式

从架构设计可以看出，OMC 为二次开发预留了多条通路：

1. 自定义技能（推荐起点）

   • 在.omc/skills/目录中新建自定义技能，针对你的项目规范和工作流编写。
   • 例如：
     • 公司内部统一的“代码风格 + 安全规范审查”技能。
     • 针对某个微服务仓库的“变更影响分析 + 下游通知”技能。

2. 扩展 Hooks

   • 在hooks.json中新增生命周期钩子或继承现有钩子逻辑。
   • 典型场景：
     • 当用户在提交信息中包含BREAKING CHANGE时，自动触发更严格的检验流水线。
     • 在注释中写入特定标记，自动关联到某个技能或 Agent。

3. 新增或调整 Agent

   • 在src/agents/中定义新的 Agent 类型，例如“性能分析专用 Agent”、“合规审查专用 Agent”。
   • 调整模型路由逻辑，使其更贴合你的预算和 SLA 要求。

4. 集成外部系统

   • 通过 MCP 工具服务器（src/mcp/）或src/tools/定义自定义工具，例如：
     • 访问内部 API 网关。
     • 调用 CI/CD 流水线。
     • 读写知识库或单点登录系统。

七、能力全景：从 Agent 到 HUD，再到通知集成

将前面的内容稍作汇总，可以得到 OMC 的能力全景图：

• 19 个专用 Agent：
  针对架构、调试、测试、安全、文档等场景定制的角色，形成覆盖完整开发链路的团队。
• 智能模型路由：
  根据任务复杂度和类型，自动在 haiku / sonnet / opus 之间选择合适的模型，降低成本同时保障质量。
• 魔法关键词检测：
  在自然对话中输入ralph、ulw、autopilot等关键词即可触发对应模式，无需记忆复杂命令。
• 自定义技能系统：
  支持从会话中抽取可复用模式，并在上下文相关时自动注入，形成“团队知识”。
• Notepad wisdom：
  把经验、决策、坑点与 TODO 记录为一种可跨会话复用的“工程记忆”。
• 多供应商团队：
  通过 tmux 方式同时运行 Codex、Gemini 和 Claude CLI，使 CCG 模式得以在多模型之间综合结果。
• HUD 状态栏：
  在终端中实时展示编排指标、token 消耗和成本，提升可观测性与可控性。
• 持久化执行（Ralph 模式）：
  坚持执行到验证通过为止，减少“默默停在 80% 完成”的情况。
• 通知与集成：
  支持与 Telegram、Discord 和 Slack 集成，在任务完成或异常时推送通知，并可配置 @ 提醒。

八、实践建议：如何在真实工程中引入 OMC

结合以上特性，给出几条将 OMC 引入实际工程的建议路线。

8.1 从个人试用到团队落地

1. 个人阶段（本地试验）
   • 安装 Claude Code 插件 + CLI。
   • 在一个中小型项目上尝试使用 Team 和 Autopilot 模式完成日常任务（修 Bug、写测试、重构小模块）。
2. 项目级应用
   • 在.omc/skills/中为项目编写特定技能，例如“生成模块设计文档”、“对某目录代码做安全审查”。
   • 使用 Ralph 模式完成几次重要重构，观察验证闭环对质量的提升。
3. 团队级推广
   • 把共识性的流程（代码 review 规范、安全基线、发布 checklist）固化为技能或 Hooks 规则。
   • 开启通知集成，把长任务的结果推送到团队常用的协作工具（如 Slack）。

8.2 如何选择合适模式

• 需要流程闭环、可追踪：优先使用Team + Ralph组合。
• 任务结构简单但代码量大：试试Autopilot。
• 批量修改、批量生成：考虑Ultrawork。
• 需要多模型观点：用CCG。
• 重视前期设计共识：启用Ralplan。

8.3 避坑与注意事项

• 不要把它当“聊天机器人”用
  最大发挥价值的方式，是把 OMC 当作“有规程、有职责”的工程协作系统，而不是问答工具。
• 尽量让任务“结构化”
  清晰的目标、边界和约束条件，会让多 Agent 协作事半功倍。
• 重视配置与状态目录
  .claude/omc.jsonc与.omc/目录不仅承载配置，还承载记忆和日志；在 CI/CD 或多机器环境下使用时，要考虑同步和权限问题。

九、总结：从单模型到工程团队，OMC 给 Claude Code 带来了什么？

OMC 做的事情可以概括为三点：

1. 把 Claude Code 从“一个模型”升级为“一个工程团队”
   通过 19 个专用 Agent + 多种编排模式，把 AI 的能力结构化为角色和流程。

2. 让“多 Agent + 多模型编排”成为一个可配置、可扩展、可观测的基础设施
   通过 Hooks、Skills、State 与 MCP 工具服务器，开发者可以像搭积木一样扩展、嵌入和集成整个系统。

3. 在成本、效果与可控性之间给出一个工程上可落地的平衡
   基于任务复杂度的模型路由策略，大幅降低成本；Ralph / Team 等模式则尽量保证“真正完成”的工程质量。

如果你已经在用 Claude Code 开发项目，或者正在探索如何在团队内落地多 Agent 编排，OMC 是一个值得认真研究和尝试的工程化方案。
下一步，可以从快速开始和安装指南入手，实际跑一遍 Autopilot 或 Team 模式，把你的日常开发任务交给这个“19 人的 AI 工程团队”，感受一下多 Agent 编排在真实工程环境里的表现。