oh-my-claudecode：Claude Code 多智能体编排

在 Claude Code 里做一次仓库级别的改造，一份会话窗口很容易被铺开的上下文撑满。任务只能一条线往下推：读代码、改代码、跑测试、修错，全挤在同一段对话里。oh-my-claudecode（下称 OmC 或 OMC）的做法是把这份活拆开，拉起一支并行干活的智能体队伍，各自负责一段，结果再汇总回主会话。

oh-my-claudecode 是 Claude Code 的多智能体编排插件，用 TypeScript 写成，接收一句自然语言任务或一条斜杠命令，派出多个并行智能体分工执行，产出代码改动、会话记录与运行状态。

它出现的场景多半是这几类：一次清掉仓库里成百上千条 TypeScript 报错、给一个陌生项目补一套 REST API、把认证流程单独拉出来让另一个模型交叉评审。这些活一次对话也能做完，只是慢。OmC 把并行执行、评审、收尾几个环节压进一条命令，README 里的说法是「其余都自动」。仓库最近一次提交在 2026-09-29。

主要功能

autopilot 主流程：把一句任务描述直接交给自动流程。会话内写 /autopilot "build a REST API for managing tasks"，也可以省略斜杠写成 autopilot: build a REST API for managing tasks。这是 README 给出的默认入口，用户不需要先学会 Claude Code 的用法。

具名 autopilot 阶段档案：用 /autopilot --workflow plan-build-qa "...任务..." 指定一套预设阶段。档案写在 .claude/omc.jsonc（项目级）或 ~/.config/claude-omc/config.jsonc（用户级）的 autopilot.workflows 下面，v1 档案只认 version 和 stages 两个字段：

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

可用的阶段序列只有四种：[ralplan, execution]、[ralplan, execution, ralph]、[ralplan, execution, qa]、[ralplan, execution, ralph, qa]。同名的项目档案会整体覆盖用户档案，不同名的两份可以共存；环境变量不能用来定义档案。这个功能目前要求 Linux 并且系统里装了 flock，不满足的环境会在创建或改变 autopilot 状态之前就拒绝显式的 --workflow 调用，不带该参数的旧写法仍然可用。

跨模型问询：omc ask codex "review this patch" 或会话内 /ask codex "review this patch"，两条路走的是同一套 advisor 流程。可选的 provider 有 claude、codex、gemini、antigravity、grok、cursor。

团队编排：终端里 omc team 2:codex "review auth flow" 会用 tmux 拉起 CLI worker；会话内 /team 3:executor "fix all TypeScript errors" 走的是原生团队工作流。README 明确说这两个是不同的运行时，命令形式相近，执行路径不一样。

任务预检扫描：omc lookout scan --brief "..." [--json] [--strict] 在动手前扫一遍任务简报。这项能力只在终端 CLI 上提供，会话内没有对应命令；README 把它标为 advisory，只给提示，不拦截执行。

HUD 用量显示：v5.4.0 起，HUD 读取用量时会尊重 CLAUDE_CODE_OAUTH_TOKEN 环境变量。v5.3.0 的发布说明把远程审批、Shipyard 导航和 Windows 可靠性列为主要内容。

插件目录模式：用 omc --plugin-dir <path> 或 claude --plugin-dir <path> 启动时，要给 omc setup 加上 --plugin-dir-mode，或者提前导出 OMC_PLUGIN_ROOT，否则安装器会重复安装插件运行时已经提供的 skill 和 agent。

多语言文档：README 有德语、西班牙语、法语、意大利语、日语、韩语、葡萄牙语、俄语、土耳其语、越南语和中文多个版本，中文版是 README.zh.md。

安装与依赖

仓库地址是 https://github.com/Yeachan-Heo/oh-my-claudecode ，许可证为 MIT License，主要语言 TypeScript（占 58.9%，另有 JavaScript 40.0%）。插件方式是 README 推荐给大多数 Claude Code 用户的路径，两条都是 Claude Code 的斜杠命令，要一次一行地敲，两行一起粘贴会失败：

/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 安装，之后可以在终端直接跑 omc ...，也可以从本地 checkout 运行。npm 安装过程中可能出现 deprecated [email protected] 警告，它来自上游 better-sqlite3 的原生扩展依赖链，目前没有安全的依赖升级或 override 能消掉，警告本身不代表 CLI 安装失败，相关跟踪在 issue #2913。

仓库里没有写明最低 Node 版本要求。Node 版本的兼容问题在 issue 里出现过一次，见「实际使用中的坑」。

最短能跑通的用法

装完之后先做一次 setup，会话内用 /omc-setup，终端用 omc setup，两个都是真实入口。

/omc-setup
omc setup

然后用 autopilot 跑第一个任务：

/autopilot "build a REST API for managing tasks"

README 对这一步的说明是「其余都自动」。要指定阶段就换成 /autopilot --workflow plan-build-qa "build a REST API for managing tasks"。

关键参数

• --workflow <name>：选择一套具名 autopilot 阶段档案，需要 Linux 且系统有 flock，档案定义在配置文件的 autopilot.workflows 下。
• autopilot.workflows.<name>.version 固定为 1，.stages 只接受前面那四种序列。
• --plugin-dir-mode 与 OMC_PLUGIN_ROOT：在插件目录模式下避免重复安装 skill 与 agent。
• omc ask <provider> "<prompt>"：provider 取 claude、codex、gemini、antigravity、grok、cursor。
• omc team <n>:<provider> "<task>" 与 /team <n>:<role> "<task>"：两套不同运行时，省略 provider 时的默认值仓库里没有说明。
• omc lookout scan --brief "..." [--json] [--strict]：危险扫描的三个开关。
• CLAUDE_CODE_OAUTH_TOKEN：HUD 读用量时会用到。

v1 的具名档案明确不支持模型字段与路由（stageModels）、内联执行、动态命令/模式/状态、任意阶段或插件，以及独立的 custom-skill frontmatter 解析器。

结果在哪里看

• 会话内的 HUD 与终端输出：autopilot 的状态、取消、恢复、Stop 都在同一套生命周期里。
• 状态目录 .omc/：在 git 仓库内，状态根锚定在仓库顶层，所有子目录共用一个。
• 代码本身：改动落在当前工作目录的仓库里，由 git 记录。

仓库里没有说明一个统一的报告目录或导出格式。

实际使用中的坑

下面这些来自 GitHub Issue，都是用户实际跑出来的问题，括号里是当前状态。

• Node 26 装不上：提交的 package-lock.json 曾把 better-sqlite3 钉在 12.6.2，该版本没有 Node 26 的预编译产物，也没法在 Node 26 上编译。（已解决，88 条评论）
• 原生 Windows 的 tmux 依赖：/ask-codex 和 /ask-gemini 在 win32 上会因为 tmux 依赖直接失败。同一时期还集中出现 Windows + PowerShell 7 下状态行不显示、SessionStart 启动超时两个问题。（已解决）
• 状态被打散：在 git 仓库之外运行时，状态根跟随 cwd，.omc/ 会在整台机器上散成好几份。（已解决，61 条评论）
• macOS 上的 graph runtime：omc graph run <descriptor.json> 在 macOS 上会立刻报 graph runtime is unavailable on darwin，后来补上了 darwin 支持。（已解决）
• 文档与代码脱节：5.0.0 里 skills/omc-setup/phases/* 仍在指示配置 5.0.0 已移除的 skill；5.3.0 的文档一度把 Ralph 写成依赖 Ruby，而依赖树里从来没有 Ruby。（已解决）
• 插件市场滞后：main 长期没有提升，插件市场用户停在 4.15.7，HUD 一直提示更新。（已解决）
• 仓库里唯一还开着的 issue 是一个 epic，方向是轻量化工作流、skill 整合，以及 prompt 与 hook 的单一事实来源（SSOT），有 62 条评论。（待解决）

同类项目对比

OmC 的前提是你已经在用 Claude Code，宿主换了它就不适用；作者自己在 README 里给 Codex CLI 用户指向了另一个项目 oh-my-codex。团队编排里终端那条路径依赖 tmux，原生 Windows 上相关命令曾经直接失败；具名阶段档案还额外要求 Linux 加 flock，其他系统只能退回不带 --workflow 的旧写法。如果你要的是跨设备调度，Paseo 更对路。这几种情况下不该硬上 OmC。

适合谁

OmC 适合已经在用 Claude Code、手头常有一整个仓库级别改造任务的开发者：清类型错误、补接口、批量重构这类活，多智能体并行确实能省时间。也适合想让第二个模型交叉评审改动的团队，omc ask 一条命令就能把补丁递给 codex 或 gemini。

只在单个文件里改几行、习惯手动控制每一步执行、或者主力工具不是 Claude Code 的人，用不上这套编排。它是一层加在 Claude Code 之上的东西，宿主换了就得换方案。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。