oh-my-codex：给 Claude 和 Codex 的 Agent 编排层
嗨，我是 Lena。第一次通读 oh-my-codex 文档的时候，我其实不是在做评测。我只是想找个更简单的答案——Codex CLI 能不能像我见过的其他 agent 设置那样做任务委派。然后我发现自己在同一句话上看了两遍："Your codex is not alone."
把这句话放在工具 README 的最顶端，挺不寻常。但我觉得这可能是对 oh-my-codex（OMX）试图成为什么的最诚实描述。
oh-my-codex（OMX）到底做什么
给 Claude Code 和 Codex CLI 的编排层
OMX 是 OpenAI Codex CLI 的编排层，通过接入 Claude Code 的能力来突破它自身的执行限制。它用异步任务系统解决 tool call 超时等问题，让长时间运行的任务可以可靠完成。OMX 通过提供 autopilot 开发、TDD、代码审查和战略规划等任务的结构化工作流，教会 Codex 如何把复杂操作有效委派给 Claude Code，从而实现自主执行。
那段描述是 v1 的框架。目前活跃的是 OMX v2，架构上发生了明显的变化。OMX v2 是 Codex 原生的。 Codex 在 v2 里是头等的执行方，这个版本里没有 Claude 桥。早期版本里的 Claude → Codex 委派模型，被替换成了一种新的形态：Codex 原生运行 session，多 agent 工作通过 spawn 出来的 tmux worker 来完成——worker 可以是 Codex、Claude 或 Gemini 面板，并行运行。
这次架构调整我自己心里也还没完全定论。OMX 对很多人最初的吸引力，就是那套给长时间任务做异步委派到 Claude Code 的机制。从某种意义上说，v2 已经是另一个产品了。
核心能力——委派、autopilot、TDD 集成
OMX 的标准工作流走三个入口：$deep-interview 用来在任何开工之前做澄清，$ralplan 用于带 tradeoff review 的共识规划，$ralph 或 $team 用于执行。OMX 提供一组以 $skill-name 语法调用的标准 skill：$team 做协同并行执行、$ralph 是持续模式（持续运行直到目标被验证完成）、$ralplan 是共识规划（Planner → Architect → Critic），$autopilot 做从想法到 QA 的完整自主执行。
持久化状态这一层值得停一下。OMX 自带五个用于持久化状态和 memory 的 MCP server、一个监控 agent 活动的实时 HUD，以及一个可以在关键生命周期节点上扩展行为的 hook 系统。它支持混合 provider 的团队——Codex、Claude 和 Gemini 的 worker 并排运行，每个都在自己的 worktree 里。
我回头看了文档里描述的 .omx/ 目录结构：plans、logs、memory、sessions、state、team artifacts。在真正开始第一次运行之前，这是一堆需要先理解的脚手架。
OMX 改变了什么
任务委派——把工作拆成 agent 大小的块
这里 OMX 的设计哲学最明显。与其给 Codex 一个大任务、然后指望它在几十次文件编辑里保持连贯，OMX 把工作在执行开始之前分解成结构化、可审查的块。
官方 demo 里展示的核心流水线是这样的：从意图分类和 deep interview 开始，先把模糊性降下来再进入执行。多 agent 编排通过 tmux 在独立 git worktree（.omx/team/<n>/worktrees/worker-N）里 spawn 并行 worker，在同时编辑时防止写冲突。
worktree 隔离这个细节，实际效果比表面听起来重要得多。任何经历过并行 agent 运行互相覆盖对方修改的人——尤其是在大重构里——都会一眼认出这是真正的工程选择，不是营销点。
实践效果：不再是一个 Codex session 试图把整个代码库改动的上下文全部扛起来，你得到的是一批专职化的 worker，每个都在自己隔离的分支上，负责一个有边界的切片。leader agent 负责整合输出并处理冲突。
Autopilot 模式——什么时候该用，什么时候别用
Autopilot 会在清晰、低风险、可回滚的下一步上自动推进，只在下一步具有实质性分支、破坏性或依赖偏好时才停下来询问。
这段来自 autopilot SKILL.md 的策略描述，是我见过对这种模式应该怎么工作的、比较诚实的一种说法。它不是"autopilot 永远在跑"，而是"autopilot 一直跑，直到撞到需要人类判断的决策点"。
实际上这意味着 autopilot 最适合的是规格清晰、代码库熟悉的功能实现。它不太适合探索性工作、需求模糊，或者你从来没见过的代码库。如果 deep-interview 这一步抛出了很多未知，那就是一个信号——autopilot 现在还不是合适的入口。
我注意到——可能我想多了——这套工具设计上是把用户往 $deep-interview 推的，即使用户觉得自己已经知道要什么。意图分类发生在执行之前。那次强制的停顿是有意设计的。
TDD 作为 agent 护栏——先测试，后代码
OMX 里的 TDD 集成不是一个工作流建议，更接近一条硬约束。test-driven-development skill 强制执行经典的 RED-GREEN-REFACTOR 循环——写一个失败的测试、看它失败、写最小代码、看它通过、然后 commit。如果 Claude 试图在测试之前写代码，这个 skill 会让它把代码删掉、重头再来。没有例外。
这其实是我认真看 OMX 时最意外的一部分。大多数 agent 设置把测试当成实现之后才发生的事。OMX 把测试当成约束实现的那一层规格。 这是实打实的架构差异，不是工作流偏好。
实际含义：如果你在一个没有测试基建的代码库上工作，OMX 的 TDD 强制会造成摩擦。如果你已经有测试套件，这就从"事后补的东西"变成了一道真实的质量门。
OMX vs Superpowers
不同的范围——编排 vs 行为约束
这是我在开发者讨论里一直看到的问题，我觉得它值得一个直接的回答，而不是一句模糊的"它们是不同工具"。
Superpowers 是 Jesse Luehrs 做的 Claude Code 插件，重心在于在一个 session 内约束 agent 的 行为。Superpowers 插件在执行之前引入一个规划阶段——不是让模型立刻开始写代码，而是先产出一份结构化计划：它会碰哪些文件、做哪些改动、按什么顺序。你审阅并批准计划之后，才会开始写任何代码。
OMX 则完全相反，重心在 运行时基础设施。HUD、worktree 隔离、MCP 状态 server、多 provider 团队 spawn——这些都是执行环境的特性，不是行为约束的特性。
一个简单的区分方式：Superpowers 让单个 agent 在一个 session 内更聪明、更有纪律。OMX 让一个多 agent 系统在多个 session 之间可靠运行并保持持久化状态。
它们能一起用吗？
原则上大概可以。结构上没有不兼容。但老实说：把两个编排层叠在一起，会引入大多数工作流其实用不到的复杂度。如果你的痛点是单个 agent 跑偏，Superpowers 直接就对上了。如果你的痛点是在多个 agent 之间协调、带隔离状态的并行工作，OMX 对上了。同时用两个，意味着你要同时理解两个——这本身就是开销。
我还不想现在就下结论。在推荐组合使用之前，我想再看几个 session 里的行为表现。
编排没解决的问题
没有 memory 的委派——任务完成了，学习蒸发了
这部分让我注意到的程度，超出了我预期。
OMX 有持久化的状态——.omx/ 目录存任务图、session 产物、memory 文件。但 持久化状态不等于能力继承。状态记录的是发生了什么。它不会把一道难题被攻克的方式，打包成另一个 agent——或者同一个 agent 在另一个项目上——可以继承的东西。
一个 worker 完成了一次复杂的认证重构。任务被标记为完成。产物被记录。下一个 agent 在另一个项目里、或者在三个月后的同一个代码库里，面对一个类似的认证问题，起点基本上跟第一个 agent 当初一样。那条艰难赢来的推理路径，没有被保留成可复用的资产。它在日志里，如果还在的话。
被委派 agent 之间没有能力继承
这个缺口坐落在 OMX（以及当下大多数编排工具）尚未解决的位置上。编排控制的是 工作怎么跑。能力继承要解决的是 成功的解题过程怎么随时间累积。
EvoMap 的 GEP 协议文档 明确地描述了这个分野——把成功的执行路径打包成可验证、可共享的资产，让其他 agent 能直接采用，而不是让它们留在 session 日志里。这条路在实践中能不能撑住，对我来说还是一个开放问题。但它指向的问题是真实的。
OMX 对自己范围是诚实的：更好的任务路由、更好的工作流、更好的运行时。这段定位直接来自 oh-my-codex 的 GitHub 仓库，是准确的。它不声称解决学习迁移。它声称把执行做得更可靠、更协调。 那是不同的问题。
限制与取舍
装之前值得知道的几件事：
平台约束。 OMX 主要为带 Codex CLI 的 macOS 或 Linux 而设计并持续调校。原生 Windows 和 Codex App 不是默认体验，可能坏、可能行为不一致，目前得到的支持也较少。
学习曲线是真的。 tmux 依赖、.omx/ 目录结构、skill 语法、agent 角色——这不是一个十分钟能拿起就用的工具。文档详尽，但详尽不等于易上手。
上下文开销。 把 AGENTS.md、skill prompt 和 MCP server 上下文注入到每个 session，会在任何实际工作开始之前先吃掉一批 token。对简单、受控的任务，这层开销可能比编排带来的收益还贵。OMX 的价值在复杂、跨多文件的工作上才真正显现出来。
v1 vs v2 架构差异。 如果你读到的 OMX 早期材料把 Claude Code 描述成主要执行引擎、Codex 向它委派——那是 v1 模型。当前版本把这个关系反过来了。在投入时间搭环境之前，值得先看一下 官方 OMX 文档 里的当前架构。
FAQ
oh-my-codex（OMX）是什么？
OMX 是一个开源的 OpenAI Codex CLI 编排层。它在标准 Codex 之上加上了多 agent 团队协调、基于 MCP server 的持久化状态、结构化工作流（autopilot、TDD、规划）和一个实时监控 HUD。它把 Codex 保留为执行引擎，而不是替代它。
oh-my-codex 怎么和 Claude Code 一起工作？
在 v2 里，这个关系和 v1 不同。不再是通过异步任务系统把长时间任务从 Codex 委派到 Claude Code，OMX 现在支持混合 provider 的团队——Claude（或 Gemini）worker 在独立的 tmux 面板里、与 Codex worker 并排运行。每个 worker 都得到一个隔离的 git worktree。该架构通过姊妹项目 oh-my-claudecode 与 Claude Code 兼容，后者把相同的编排模式专门套用在 Claude Code 上。
oh-my-codex 和 Superpowers 有什么区别？
Superpowers 约束 agent 在 session 内的 行为——写代码前先规划、强制 TDD、结构化 review 循环。OMX 提供的是 运行时基础设施——worktree 隔离、多 agent 协调、持久化状态、HUD 监控。Superpowers 让一个 agent 更聪明。OMX 让一个 agent 系统稳定运行。两者的范围差别大到直接对比反而会错过重点。
oh-my-codex 支持 TDD 工作流吗？
支持。TDD skill 把 red-green-refactor 循环作为硬约束执行，不是建议。测试必须写在实现代码之前。如果 agent 试图先写实现，这个 skill 会强制删除并重来。这条规则专门适用于 $tdd 工作流路径。
oh-my-codex 的 agent 能记住学过的东西吗？
OMX 维护持久化状态——session 日志、任务产物、项目 memory 文件都在 .omx/ 里。同一个项目内，agent 可以从过去的 session 里取回上下文。它没做的是：把成功的解题路径打包成可转移能力，让它被不同项目上的不同 agent 继承。这个分野——状态持久化和能力继承之间——就是当前编排工具普遍停下来的地方。
我大概还会继续看 v2 架构怎么沉淀下来。说实话，远离 Claude 委派模型这件事到底是对的取舍、还是只是必要的取舍，我心里仍然没完全定。
Previous Posts:
👉 如果你想更清楚地知道编排在 agent 栈里的位置，请读：OpenHarness and GEP: The Three Layers of the Agent Stack
👉 想深入了解执行系统为什么不能解决学习迁移：ARC-AGI-3 and the Agent Learning Gap: What's Still Missing
👉 如果你在对比跨 agent 的持久化状态和真正的能力复用：Agent Skills vs GEP Assets: What Actually Transfers Between Agents
👉 想理解 memory 系统和真正跨 session 学习的区别：Hermes Agent vs EvoMap: Memory vs Capability Inheritance
👉 如果你在琢磨 agent 能不能超越编排层进化：EvoSkills: Can Agents Actually Improve Themselves Over Time?
