如果您已经在使用 Codex，安装 oh-my-codex 之前，有一个关键点需要先厘清：它并非另一个 coding agent。

更准确地说，它像是包裹在 Codex 外部的一层工作流与运行时，弥补了原本需要您自行维护的几项能力：何时先澄清需求，何时先将方案敲定，何时该单人持续推进，何时该拆成多个 worker 并行执行，以及计划、日志、状态分别应该存放的位置。

项目首页的定位写得很直白：它并非在替 Codex 再造一个 agent，而是在 Codex 外部补充了一层更完整的工作流与运行时。

OMX 到底是什么

README 给出的定义是：Codex 仍是执行引擎，OMX 不会取代它。 它额外增加了三层内容：一套固定的工作流，一批可复用的 prompts / skills / agent roles，以及一层更完善的本地运行时。

仓库中反复出现的 4 个关键词是：$deep-interview、$ralplan、$ralph、$team。这 4 个入口，正是 OMX 试图固定下来的默认动作顺序。

它补的不是“更多命令”，而是默认工作顺序

README、Getting Started 和 Skills 文档都在强调同一主线：

1. 先用 $deep-interview 把需求、边界和非目标问清楚
2. 再用 $ralplan 把方案、tradeoff 和执行计划收稳
3. 然后在执行阶段二选一：$ralph（一个 owner 持续推进到完成）或 $team（多 worker 并行执行）

翻译成更接地气的话，大概就是：别一上来就写，先把需求问明白，再把方案定下来，最后再决定是一个 agent 持续推，还是开并行团队。

这和很多人直接开 Codex 会话、边聊边改代码的习惯不一样。OMX 主要补的就是这层顺序。

第一次先试这 4 个入口

第一次上手不用先研究完全部命令，先把这 4 个摸一遍就够了。

1. $deep-interview

这是澄清入口。适合需求还模糊、您只知“要做什么”却说不清“不做什么”、或者您担心直接开写会带偏的情况。

例如：$deep-interview "clarify the authentication change"。它想解决的不是实现，而是边界。

2. $ralplan

这是方案确认入口。适合需求已经清楚，但还没有落成可执行的计划，或者您想先把实现路径和 tradeoff 定下来。

例如：$ralplan "approve the auth plan and review tradeoffs"。这一步放在执行前。OMX 这套设计里，计划不是顺手补一下，而是一个明确的关口。

3. $ralph

这是持续推进入口。README 里的原话是：persistent completion 和 persistent completion loop。可以理解为一个 agent 持续拿着同一个目标往前推，直到完成和验证。

例如：$ralph "carry the approved plan to completion"。如果您不想一层层拆 worker，而是想让一个 owner 把事情收完，这个入口更贴切。

4. $team

这是并行执行入口。例如：$team 3:executor "execute the approved plan in parallel"。从 README 到 DEMO 文档，$team 都被定位成“协同并行执行”，不是默认上来就开。它更像是在计划已经清楚以后，才启动的一层团队运行时。

第一天怎么装，装完先怎么试

按文档给的最短路径，先做 3 步：

npm install -g @openai/codex oh-my-codex
omx setup
omx doctor

要求也不复杂：Node.js 20，Codex CLI 已安装，Codex 已完成认证。

第一步是全局安装 @openai/codex 和 oh-my-codex。装完以后，先确认两个命令都在：

codex --version
omx version

第二步是跑 omx setup：

omx setup

这一步不是简单写几个配置。按仓库的 demo，它至少会做这些事：安装 agent prompts、安装 skills、更新 Codex 的配置、生成项目里的 AGENTS.md、配置 notification hook、配置 HUD。

如果您是第一次装，最值得确认的是这几类结果：~/.codex/prompts/ 里有 OMX 的 prompts，~/.codex/skills/ 里有 OMX 安装进去的 skills，当前项目根目录出现 AGENTS.md。

第三步是跑 omx doctor：

omx doctor

这一步相当于验收。README 和 demo 里给的检查项主要有这些：Codex CLI 是否安装，Node.js 版本是否符合要求，~/.codex 是否存在，config.toml 里有没有 OMX 配置，prompts 和 skills 有没有装进去，项目里的 AGENTS.md 是否生成，.omx/state 这类状态目录是否可用，MCP 配置是不是完整。

如果只是第一轮体验，接下来直接这样开 omx，或者在信任环境里按它推荐的高强度参数开 omx --madmax --high。然后不要去试一堆命令，直接按这条顺序走一遍：

$deep-interview "clarify the authentication change"
$ralplan "approve the safest implementation path"
$ralph "carry the approved plan to completion"

等您对这条单线程流程有感觉了，再去试 $team 3:executor "execute the approved plan in parallel"。这样第一轮体验会更直接。

如果您后面想试 team runtime，再补平台依赖：macOS / Linux 装 tmux，Windows 装 psmux。

如果安装过程里一开始就不顺，先查这几项：omx 命令是不是在 PATH 里，omx setup 跑完后 ~/.codex/prompts/ 和 ~/.codex/skills/ 里有没有内容，omx doctor 报的是配置问题还是安装问题，项目根目录下有没有生成 AGENTS.md。

.omx/ 和 AGENTS.md，才是它和普通命令集合的区别

只看首页命令，很容易把 OMX 误解成“帮 Codex 多装一些 prompt”。但它和单纯 prompt 包的区别，主要在两块：

1. AGENTS.md：Getting Started 文档写得很清楚，OMX 默认会把项目里的 AGENTS.md 接进 Codex 会话。这意味着它不是单纯装全局 prompt，而是在项目目录里生成一层面向当前仓库的指导文件。

2. .omx/：README 直接把 .omx/ 定义成了 plans、logs、memory、runtime state。也就是说，OMX 不只是在提供命令，还在提供一块稳定的本地状态目录。这和纯 prompt/skill 集的差别在于：它开始关心运行时。

团队模式不是口号，仓库里已经把运行时铺开了

如果只看首页，您会以为 $team 只是“多开几个 agent”。但 DEMO 文档展开以后，团队模式其实是一套更重的东西：tmux session、leader pane、worker pane、shared task queue、mailbox communication、claim-safe task lifecycle，以及完整的 status / resume / shutdown。

文档里甚至给出了完整的 omx team api 命令矩阵，包括 create-task、claim-task、transition-task-status、send-message、broadcast、mailbox-list、mailbox-mark-delivered。这说明它的团队模式不是口头上的并行，而是把任务领取、状态迁移、消息收发、恢复和清理都写进了 CLI。

这也是为什么它要求 macOS/Linux 用 tmux，Windows 用 psmux。这部分更接近一个本地编排运行时，不只是普通命令助手。

HUD、doctor、explore、sparkshell 这些东西，说明它已经不只是 workflow

首页把这些都归为 operator surfaces：omx setup、omx doctor、omx hud --watch、omx explore --prompt "..."、omx sparkshell ...。

这里能看出另一层意思：OMX 不只是想规范您“怎么想、怎么计划、怎么执行”，还想把观测和辅助操作一起包进去。doctor 负责查安装状态，hud 负责状态观察，explore 负责只读检索，sparkshell 负责 shell-native inspection 和有边界的验证。做到这一步，它已经不太像“工作流模板”，而更像一层本地开发 runtime。

OpenClaw 集成也说明了一件事：它在往通知和外部协同扩

仓库里还有一份单独的 openclaw-integration 指南，讲的是 notification hooks、webhook / CLI gateway，以及 session-start、session-idle、ask-user-question、session-end。而且不只是消息推送，还支持通过 clawdbot agent command 做后续跟进。

这一层不是每个人第一天都会用到，但能看出 OMX 的方向：它不满足于把 Codex 包起来，还想把会话事件往外抛，把外部协同也接进来。

这套东西适合谁

更适合下面这几类人：已经在长期用 Codex，觉得自己每次会话都在重复做澄清、规划、收尾，开始需要并行 worker 或团队模式，愿意接受一套固定工作顺序。

如果您现在有明确痛点，像是需求总是没问清就开写、计划经常是边做边补、想把并行执行拉进终端工作流、想把计划、日志、状态和消息都留在本地运行时里，OMX 会更对路。

哪些人先别急着装

如果您现在的使用习惯是：就想开一个干净的 Codex，不想多一层 workflow，不想接受固定的命令顺序，也暂时不需要 team runtime、HUD、doctor、通知和状态目录，那么您可能并不需要 OMX。

README 其实也说得很直：不一定适合所有人。

最后一句

如果只用一句话概括这个项目：oh-my-codex 不是在替 Codex 再造一个 agent，而是在 Codex 外面补了一层更完整的工作流和运行时。

它真正要解决的，不是“模型会不会写”，而是当工作变大以后，澄清、规划、并行、状态和协同怎么收进一套默认动作里。

项目名：Yeachan-Heo/oh-my-codex