oh-my-codex：Codex CLI 之上的多智能体工作流操作系统
最近看 oh-my-codex，我最强烈的感觉是：它并不是想再做一个“更会写代码的 AI 助手”。
它真正想补的，是 Codex CLI 之上的那层工程组织能力。
如果说原生 Codex CLI 更像一个能力很强的单兵开发者，那么 oh-my-codex 更像是在它外面套了一层工作流操作系统：负责拆任务、派角色、保留状态、运行命令、恢复中断、管理多智能体协作，并尽量把一次性的 AI 对话变成可以反复使用的工程流程。
这件事很重要。
因为 AI Coding 发展到现在，很多人的问题已经不是“模型会不会写代码”，而是另一组更工程化的问题：
- 它能不能先理解项目，而不是上来就改？
- 它能不能把复杂任务拆成可执行步骤？
- 它能不能在失败后恢复，而不是从头再来？
- 它能不能跑测试、读结果、继续修？
- 它能不能让多个 agent 并行工作，但又不互相踩文件？
- 它能不能把项目里的经验沉淀下来，而不是每次重新解释？
oh-my-codex 的价值，就落在这些问题上。
它到底是什么
oh-my-codex 是一个面向 OpenAI Codex CLI 的增强层。它不是替代 Codex CLI，而是把 Codex CLI 变成一个更适合复杂工程任务的多智能体运行环境。
它提供的东西大致可以分成几类：
- 工作流技能，例如
$deep-interview、$ralplan、$ralph、$team - 多智能体团队模式，用多个 worker 并行推进任务
- 自动研究模式，用来探索陌生代码库或复杂问题
- 命令执行包装器，让 shell 执行结果进入工作流上下文
- MCP 状态与记忆服务，用来保存项目状态、任务轨迹和上下文
- hooks 与恢复机制，用来处理执行前后、停止、恢复、重入等运行时问题
这些能力单独看并不神秘。真正值得关注的是，它们被组织成了一套完整的 AI Coding 运行方式。
也就是说，它不只是告诉模型“你要更谨慎一点”，而是试图在工具层面规定：什么时候该研究，什么时候该计划，什么时候该执行，什么时候该验证，什么时候该恢复。
这就是它和普通 Prompt 仓库最大的区别。
为什么 Codex CLI 需要这一层
Codex CLI 本身已经足够强。对于很多简单任务，比如解释一个函数、修一个明显 bug、补一个测试用例，直接让 Codex 做就可以。
但真实工程里的任务往往不是这样的。
例如你可能会说：
重构认证模块，保持兼容性，补齐测试，并确保现有登录流程不受影响。
这句话看起来简单，其实里面至少包含几层工作：
- 读懂当前认证流程
- 找到入口、中间件、会话、token、权限判断之间的关系
- 确认哪些行为必须兼容
- 制定重构计划
- 小步修改代码
- 补测试或调整测试
- 跑测试
- 根据失败结果继续修
- 检查是否引入了多余抽象
- 最后总结变更和风险
如果把这些都塞进一次普通对话里，很容易出现几个问题。
模型可能还没真正理解项目就开始改；改完以后忘了跑测试；测试失败后只修表面错误；上下文变长以后开始丢细节；中途断掉以后很难恢复到原来的任务状态。
这不是某个模型特有的问题，而是“聊天式编程助手”天然会遇到的问题。
oh-my-codex 的思路是：不要只指望模型在一次对话里保持完美纪律，而是把纪律沉到工作流里。
Workflow Skills：把临场发挥变成固定流程
oh-my-codex 里很有代表性的设计，是 $name 风格的 workflow skills。
比如：
$deep-interview
$ralplan
$ralph
$team
这些不是普通快捷短语，而是对一套流程的封装。
$deep-interview 更像需求澄清器。当目标还模糊时，它不会急着写代码，而是通过连续问题把意图、约束和成功标准问清楚。
$ralplan 偏向计划生成。它适合在动手前先形成可审查的实现路线，避免 AI 一上来就在代码里乱冲。
$ralph 更像持续执行模式。它强调把任务推进到完成，而不是只给一段建议。
$team 则是团队模式入口，用来调度多个 worker 并行处理更复杂的目标。
这类设计的意义在于：开发者不需要每次都重新写一长串“请你先分析、再计划、再执行、再验证”的提示词。流程被命名、封装、复用以后，AI Coding 才开始从个人经验变成系统能力。
Team Mode：多智能体不是炫技，而是分工机制
oh-my-codex 最吸引人的能力之一，是 team mode。
例如：
omx team 3 "refactor auth module with full test coverage"
这类命令表达的是：启动 3 个 worker，共同处理一个复杂任务。
多智能体听起来很容易被包装成噱头，但在工程场景里，它真正有用的地方不是“人多力量大”，而是可以形成不同方向的并行探索。
比如同一个重构任务，可以让不同 worker 分别关注：
- 当前模块结构和依赖关系
- 测试缺口和边界用例
- 最小改动实现方案
- 潜在兼容性风险
- 文档和迁移说明
如果这些 worker 都在同一个工作目录里直接改文件，结果会非常危险：冲突、覆盖、状态混乱都会出现。
所以 oh-my-codex 强调隔离的 git worktree。这个细节很关键。
worktree 让每个 worker 可以在独立目录里探索、修改、验证。这样做的好处是：
- 不同方案互不污染
- 可以比较多个实现路径
- 失败尝试容易丢弃
- 成功方案可以再合并
- 冲突暴露在 git 层，而不是悄悄覆盖文件
这说明 oh-my-codex 不是简单地“多开几个 AI”，而是在考虑多智能体协作的工程底座。
Autoresearch：先研究，再判断
另一个值得关注的能力是 autoresearch。
它适合用来回答这类问题：
omx autoresearch "how does the auth middleware work?"
很多 AI Coding 失败，根源不是写代码能力不够，而是前置研究太少。
模型看到几个文件后，很容易做出一个看似合理、实际片面的判断。尤其是在大型项目里，真正执行的代码可能和看起来最显眼的源码不是一回事：有构建产物、有配置覆盖、有中间件顺序、有运行时注入，还有各种历史兼容路径。
自动研究模式的价值，是把“理解项目”单独变成一个任务阶段。
它不急着改，而是先找入口、追调用、读配置、看测试、整理结论。最终产出的不是代码，而是一份可以支持后续决策的研究结果。
这很像真实开发里的第一步：不要急着下手，先弄清楚系统现在到底怎么工作。
Exec Wrapper：让命令结果进入循环
AI 编程不能只停留在“生成代码”。
一个靠谱的 AI Coding 流程，必须能处理命令结果：测试失败、lint 报错、类型检查失败、构建失败、脚本输出异常，都应该反馈到下一轮决策里。
oh-my-codex 提供 omx exec 这样的包装器，例如：
omx exec npm test -- --coverage
它的意义不只是换一种方式跑命令，而是让命令执行成为工作流的一部分。
普通终端输出看完就过去了；但在 agent 系统里，测试结果应该被记录、分析、归因，并驱动下一次修改。
如果一个 AI 工具不能把“执行结果”稳定地接回“下一步计划”，那它就很难从聊天助手进化成工程代理。
MCP 状态与记忆：跨会话的项目上下文
oh-my-codex 还集成了 MCP 相关能力，用来处理状态、记忆、代码智能和 trace。
这背后其实是在解决一个很现实的问题：AI 编程助手经常会“这次知道，下次忘记”。
你告诉它项目里的命名约定、测试策略、模块边界，它这轮可能记住了；但下次打开新会话，又要重新解释。
如果任务更长，比如持续几天的重构、分阶段迁移、跨模块测试补全，这种遗忘会非常影响效率。
持久化状态的意义，就是把一些上下文从对话里拿出来，沉淀到工具层：
- 当前任务进行到哪一步
- 已经尝试过哪些方案
- 哪些测试失败过
- 哪些路径是关键入口
- 项目偏好和约束是什么
- 哪些结论已经被验证过
这类记忆如果管理得好，AI Coding 就不再只是“一次性问答”，而会更接近长期协作。
它真正像“工作流操作系统”的地方
我觉得 oh-my-codex 最有意思的地方，不是某个单点功能，而是它把 AI Coding 分成了几个层次。
底层是 Codex CLI，负责理解、生成、调用工具、修改代码。
中间是工作流，负责规定任务应该怎样推进。
再上面是团队编排，负责多 agent 分工、隔离和汇总。
旁边还有状态、记忆、hooks、命令包装和恢复机制，负责让整个系统更可控。
这就很像一个小型操作系统：
- agent 是进程
- worktree 是隔离环境
- workflow 是调度策略
- MCP 是状态存储
- hooks 是系统调用前后的拦截点
- exec wrapper 是受控的命令执行层
当然，这只是一个类比，但它能解释为什么 oh-my-codex 比普通 prompt 集合更值得关注。
Prompt 解决的是“这一次怎么说”。
工作流系统解决的是“以后每次怎么做”。
适合什么场景
我觉得 oh-my-codex 最适合几类任务。
第一，陌生代码库探索
当你刚接手一个项目时，不应该马上让 AI 改代码。更合理的方式是先让它研究系统结构，例如请求生命周期、认证链路、数据写入路径、构建流程等。
这时 autoresearch 会比直接问答更合适。
第二，模块级重构
重构不是简单替换代码，而是要理解边界、保持行为、补齐测试、处理兼容。
这类任务非常适合先计划，再分 worker 探索，再选择方案合并。
第三，测试补全和回归修复
测试任务往往包含大量重复验证。AI 很擅长生成测试，但也容易漏掉边界。
如果能让多个 agent 分别关注不同测试层次，再通过命令执行循环持续修正，效率会更高。
第四，长任务自动推进
有些任务不是一两轮能完成的，比如依赖升级、API 迁移、类型修复、lint 清理。它们需要持续执行、观察失败、继续调整。
这正是 $ralph 这类持续执行工作流适合处理的场景。
也不是所有任务都需要它
不过，oh-my-codex 并不是越多越好。
如果只是改一个错别字、加一行配置、解释一个函数，直接用 Codex CLI 可能更快。
多智能体和工作流都会带来额外成本。它需要你理解任务边界，也需要你知道什么时候该让系统继续推进，什么时候该停下来人工判断。
尤其是团队模式，如果目标不清楚，多个 worker 可能只是在并行制造混乱。
所以我更愿意把它看作复杂任务工具，而不是日常所有小改动的默认入口。
简单任务用单兵，复杂任务上编排。
这可能是更合理的使用方式。
它反映的趋势
oh-my-codex 背后真正重要的趋势，是 AI Coding 正在从“对话能力”转向“运行能力”。
过去我们更关心模型一次回答得好不好：
- 代码写得对不对
- 解释清不清楚
- Prompt 怎么写更有效
现在更关键的问题正在变成：
- 任务能不能被稳定拆解
- 执行过程能不能被追踪
- 状态能不能跨会话保存
- 失败能不能恢复
- 多个 agent 能不能协作
- 验证结果能不能进入下一轮
- 人类能不能在关键节点审核和接管
这其实是从“聪明的大脑”走向“可靠的系统”。
模型仍然重要，但模型之外的控制层、状态层、验证层、协作层，会越来越决定工具能不能真的进入复杂工程流程。
总结
oh-my-codex 最值得关注的，不是它给 Codex CLI 多加了几个命令，而是它试图回答一个更大的问题：
当 AI 编程助手不再只是一个聊天窗口，而是一组可以协作、恢复、验证和长期运行的 agent 时，我们应该怎样组织它们？
它的答案是：用工作流技能约束过程，用 team mode 组织分工，用 worktree 做隔离，用 autoresearch 做前置理解，用 exec wrapper 接住验证结果，用 MCP 保存状态和记忆。
这套组合让 Codex CLI 从一个强大的单点工具，开始接近一个多智能体工程系统。
如果说 Codex CLI 解决的是“AI 怎么帮我写代码”，那么 oh-my-codex 进一步解决的是：
AI 怎么像一个有流程、有记忆、有分工、有验证机制的工程团队一样工作。
技能全景：oh-my-codex 内置了哪些能力
如果只把 oh-my-codex 理解成“Codex CLI 的增强工具”，其实还不够准确。它真正的能力，是通过一组 skills 把 AI Coding 拆成可复用的工作流：有些负责规划，有些负责研究，有些负责执行，有些负责团队协作，有些负责验证、审查、记忆和环境维护。
下面按照使用场景，把官方 skills/ 目录里的技能完整梳理一遍。
1. 安装、帮助与运行状态
这组技能负责让 OMX 本身可安装、可诊断、可理解、可观察。
help
help 是 oh-my-codex 的使用指南入口。
当你不确定某个模式怎么启动、某个命令该怎么用，或者想快速了解 OMX 的能力边界时，help 是最直接的入口。它的价值不是执行任务，而是降低学习成本。
omx-setup
omx-setup 用于按照当前 CLI 行为安装和配置 oh-my-codex。
它适合第一次接入 OMX，或者升级后需要刷新配置时使用。对于这类工具来说，安装脚本和运行时配置经常会随版本变化，所以把 setup 变成一个独立 skill 很有必要。
doctor
doctor 用来诊断和修复 oh-my-codex 安装问题。
如果遇到命令不可用、hook 没生效、路径异常、状态文件异常、某个模式无法启动，doctor 就是优先使用的排障入口。它解决的是“工具自己是否健康”的问题。
configure-notifications
configure-notifications 是通知配置入口。
长任务、团队任务、自动修复任务往往不会几秒钟结束。如果没有通知机制，用户只能一直盯着终端。这个 skill 的作用，是把任务完成、失败、需要人工介入等事件接到通知渠道上。
hud
hud 用来展示或配置 OMX 的双层 statusline HUD。
多智能体系统最怕黑盒运行。HUD 的价值，是让你知道当前处于什么模式、任务状态如何、是否有 worker 在执行、是否需要你介入。它解决的是可观察性问题。
cancel
cancel 用于取消当前活跃的 OMX 模式，包括 autopilot、ralph、ultrawork、ecomode、ultraqa、swarm、ultrapilot、pipeline、team 等。
自动化越强，刹车越重要。cancel 的存在说明 OMX 并不是只追求“让 AI 一直跑”，也考虑了用户随时中断和接管的需求。
2. 规划、澄清与任务收敛
这组技能负责在动手之前把目标想清楚，避免 AI 过早进入代码修改。
deep-interview
deep-interview 是苏格拉底式深度访谈技能，会在执行前用数学化的模糊度门控来判断需求是否足够清楚。
它适合需求不明确、边界模糊、成功标准不清楚的任务。相比直接让 AI 编码，它更像一个需求澄清器：先问清楚，再执行。
plan
plan 是战略规划技能，并支持可选 interview workflow。
它适合在复杂任务前形成路线图：要改哪些部分、为什么这么改、顺序是什么、怎么验证、风险在哪里。对于重构、迁移、架构调整，plan 往往比直接执行更稳。
ralplan
ralplan 是 $plan --consensus 的别名，本质上是共识规划入口。
它适合在进入 Ralph、Autopilot 或 Team 这类执行模式前，先形成一个经过多角度审视的计划。它的重点是降低“单一模型拍脑袋开改”的风险。
ralph-init
ralph-init 用于初始化 PRD，也就是产品需求文档，为结构化 Ralph 循环做准备。
如果一个任务比较大，直接进入 Ralph 可能会让执行过程缺少边界。先用 ralph-init 写出 PRD，可以明确目标、约束、验收标准和执行范围，让后续自动执行更可控。
3. 研究、分析与代码库理解
这组技能负责“先看清事实”，再决定是否修改。
analyze
analyze 是只读深度仓库分析技能，会输出带置信度、文件引用、证据与推断边界的综合结论。
它适合用户说“分析一下”“为什么会这样”“是什么导致的”这类场景。它强调只读，不先改代码；强调证据，不靠直觉猜。
autoresearch
autoresearch 是带状态、验证器门控和 native-hook 持久化的研究循环。
它适合围绕单一研究目标持续探索。比如研究某个模块如何工作、某个 bug 的可能根因、某个方案是否适合当前项目。它不是简单搜索，而是有状态、有验证、有停止条件的研究流程。
deepsearch
deepsearch 是彻底的代码库搜索技能。
普通搜索往往只能找到关键词，而复杂项目里真正重要的信息可能分散在路由、配置、测试、生成文件、文档、脚本里。deepsearch 的价值是系统性地找线索，不漏掉关键路径。
trace
trace 用来展示 agent flow trace 时间线和摘要。
它适合回看一次 agent 执行过程：做了哪些事、走过哪些阶段、哪里失败、哪里切换了模式。对于调试复杂自动化流程来说，trace 是非常重要的证据链。
ask-claude
ask-claude 会通过本地 CLI 向 Claude 提问，并捕获可复用 artifact。
它适合把 Claude 当成外部专家来咨询，并把结果保存下来。和临时聊天不同，它强调 artifact capture，方便后续引用、比较和审查。
ask-gemini
ask-gemini 会通过本地 CLI 向 Gemini 提问，并捕获可复用 artifact。
它的意义类似 ask-claude，但面向 Gemini。多模型咨询的好处是可以利用不同模型的视角，尤其适合方案比较、长上下文分析或交叉验证。
4. 自动执行与高吞吐推进
这组技能负责从计划进入行动，把任务持续推进到可验证结果。
autopilot
autopilot 是从 idea 到 working code 的全自动执行模式。
它适合目标明确、验证方式清楚、风险可控的任务。比如修一个已知 bug、实现一个小功能、补一组测试。它的优势是减少人工来回指挥，但不适合模糊或高风险任务直接启动。
ralph
ralph 是自引用循环，会持续执行直到任务完成，并带 architect verification。
它适合需要多轮尝试的任务：测试失败就修，构建失败就查，修完再验证。相比一次性生成代码，Ralph 更像一个会持续推进的执行 agent。
ultrawork
ultrawork 是高吞吐并行执行引擎。
它适合任务数量多、可并行度高的场景，比如批量迁移、批量修复、批量清理、多个独立 issue 同时推进。它的重点是吞吐和并行，而不是单点深度思考。
pipeline
pipeline 是可配置的流水线编排器，用来按阶段串联任务。
很多复杂工作都不是一个模式能完成的，而是要按顺序走：研究、计划、执行、验证、审查、总结。pipeline 的价值就是把这些阶段稳定编排起来。
ecomode
ecomode 是节省 token 的模型路由修饰器。
在长任务或大仓库里，token 成本和上下文管理都很重要。ecomode 的价值是让系统更克制地使用模型能力，把高成本模型调用留给真正需要的环节。
5. 团队、多 agent 与 worker 协作
这组技能体现了 oh-my-codex 的多智能体编排能力。
team
team 使用基于 tmux 的编排方式，让 N 个 agent 在共享任务列表上协作。
它适合复杂任务拆分，比如一个 worker 负责研究，一个负责实现，一个负责测试，一个负责 review。重点不是“开更多 AI”，而是让每个 worker 有明确角色和交付物。
swarm
swarm 是团队模式的兼容外观，本质上也是 N 个 agent 在共享任务列表上协调工作。
可以把它理解成面向旧接口或不同使用习惯的 team 入口。它的价值是保持兼容，让用户仍然可以用 swarm 的心智调用多 agent 工作流。
worker
worker 是 tmux-based OMX teams 的团队 worker 协议，包含 ACK、mailbox、task lifecycle 等约定。
这是多 agent 协作里非常底层但关键的部分。没有协议，worker 之间就很难确认任务接收、状态变化、产出提交和生命周期结束。worker 让团队协作更像一个工程系统，而不是几个 agent 各说各话。
6. 构建、测试、审查与质量控制
这组技能负责让 AI 的输出真的可用，而不是只看起来完成了。
build-fix
build-fix 专门用于用最小改动修复 build 和 TypeScript 错误。
它非常适合前端或 TS 项目里的构建失败场景。它强调 minimal changes，避免 AI 为了修一个类型错误顺手重构半个项目。
tdd
tdd 是测试驱动开发 enforcement skill，要求始终先写测试。
它适合需求明确、行为可描述的功能开发。先写测试可以迫使 AI 明确预期行为，也能减少“写完代码才想怎么验证”的问题。
ultraqa
ultraqa 是 QA 循环：test、verify、fix、repeat，直到目标达成。
它适合“让测试通过”“修复回归”“确保构建稳定”这类任务。它的核心价值是闭环：不是改完就结束，而是验证失败就继续修。
review
review 是 reviewer-only pass，用于 /plan --review 和 cleanup artifact review。
它只做审查，不负责执行。这个分工很重要：有时你需要一个不参与写代码的 reviewer，从更冷静的视角检查方案或产物。
code-review
code-review 用于全面代码审查。
它适合在较大 diff、PR 或关键模块变更后使用，关注逻辑正确性、可维护性、边界条件、测试覆盖、潜在回归等问题。
security-review
security-review 用于全面安全审查。
它适合认证、权限、输入校验、依赖、敏感数据、命令执行、文件上传、网络请求等高风险代码。相比普通 review，它会更关注攻击面和安全边界。
verify
verify 用来在声称完成前确认改动真的有效。
它是 AI Coding 里非常关键的收尾技能。模型很容易在“看起来没问题”时宣布完成，而 verify 强迫它回到事实：测试跑了吗？复现过了吗？构建过了吗？输出对了吗？
ai-slop-cleaner
ai-slop-cleaner 用来执行 anti-slop cleanup、refactor、deslop 工作流。
AI 生成代码常见问题不是完全错误，而是多余：过度抽象、重复 helper、无用兼容层、臃肿注释、没必要的配置。这个技能的价值是删除优先，让代码回到简单、直接、可维护。
7. 前端、视觉 QA 与网页复刻
这组技能面向 UI、视觉还原和前端体验。
frontend-ui-ux
frontend-ui-ux 是面向 UI/UX 工作的 designer-developer。
它适合页面设计、交互优化、组件美化、布局调整、视觉一致性改进。和普通代码执行不同，它需要同时考虑工程实现和用户体验。
visual-verdict
visual-verdict 用于截图和参考图之间的结构化视觉 QA 判断。
它适合前端验收、设计稿还原、视觉回归。相比“差不多”，它会输出结构化判断，指出布局、颜色、间距、字体、对齐等差异。
visual-ralph
visual-ralph 是面向前端 UI 的 Visual Ralph 编排流程，可以基于生成参考图、静态参考图或 live URL target，用 $ralph、$visual-verdict 和 pixel-diff 证据循环修复，直到实现接近参考并留下可复现设计系统。
它适合高质量 UI 还原任务。它不是简单“看图写页面”，而是把视觉比对、差异修复、循环验证串成工作流。
web-clone
web-clone 是已废弃的 URL-driven website cloning 技能，官方建议改用 visual-ralph 处理 live-URL 视觉实现工作流。
它仍然出现在技能清单里，说明项目保留了兼容入口，但实际使用时应该优先选择 visual-ralph。
8. Git、记忆、知识库与技能管理
这组技能负责把工程过程沉淀下来，或者处理项目协作里的基础设施问题。
git-master
git-master 是 Git 专家技能，负责 atomic commits、rebase 和历史管理。
AI 修改代码后，如何拆 commit、如何写提交信息、如何 rebase、如何保持历史干净，都是工程质量的一部分。git-master 适合在变更完成后整理提交历史。
note
note 会把笔记保存到 notepad.md，增强上下文压缩后的韧性。
长对话里，上下文可能被压缩或丢失。note 的价值是把关键临时信息写下来，避免重要结论只存在于会话上下文里。
wiki
wiki 是持久化 markdown 项目知识库，存储在 .omx/wiki 下，并支持关键词搜索和生命周期捕获。
它适合保存项目架构、约定、踩坑记录、长期决策和可复用知识。和 note 相比，wiki 更长期、更结构化。
skill
skill 是本地技能管理器，支持 list、add、remove、search、edit 和 setup wizard。
当你开始把自己的工作流沉淀成技能时，skill 就变成维护入口。它让 OMC 不只是使用官方技能，也能扩展本地团队自己的技能。
这些技能应该怎么组合
真正使用 OMX 时，很少是单独调用一个 skill 就结束。更常见的是把它们组合成流程。
比如一个复杂重构任务，可以这样走：
deep-interview澄清目标和边界analyze或autoresearch做只读分析deepsearch找全相关调用点ralplan形成共识计划team分配多个 workerralph或autopilot推进实现ultraqa反复测试、验证、修复code-review和security-review做审查verify做最终确认git-master整理提交wiki或note沉淀关键结论
再比如一个前端视觉实现任务，可以这样走：
frontend-ui-ux设计页面体验visual-ralph根据参考图或 live URL 循环实现visual-verdict输出结构化视觉判断ultraqa跑测试和构建ai-slop-cleaner清理多余实现verify做最终确认
这也是 oh-my-codex 真正有意思的地方：它不是一堆零散命令，而是一套可以自由组合的 AI Coding 工作流积木。