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、代碼審查同戰略規劃等任務嘅結構化 workflow，教識 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 嘅標準 workflow 經過三個入口：$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 運行互相覆蓋對方改動嘅人——尤其係大型重構——都會一眼睇得出呢個係真嘅工程選擇，唔係營銷 point。
實踐效果：唔再係一個 Codex session 試圖將成個 codebase 改動嘅上下文扛起嚟，而係一批專職化嘅 worker，每個喺自己隔離嘅分支度工作，負責一個有邊界嘅切片。leader agent 負責整合輸出同處理衝突。
Autopilot 模式——幾時用，幾時唔好用
Autopilot 會喺清晰、低風險、可回滾嘅下一步上自動推進，只係喺下一步具有實質性分支、破壞性或者依賴偏好嘅時候，先至停低問。
嗰段嚟自 autopilot SKILL.md 嘅政策描述，係我見過對呢種模式應該點樣工作，比較誠實嘅其中一種講法。唔係"autopilot 永遠會跑"，而係"autopilot 一直跑，直到撞到需要人類判斷嘅決策點"。
實際上呢件事意味住 autopilot 最啱嘅係規格清楚、codebase 熟悉嘅功能實現。佢唔係太啱探索性工作、需求模糊，或者你從來未見過嘅 codebase。如果 deep-interview 呢步抛出咗好多未知，呢個就係個信號——autopilot 而家唔係啱嘅入口。
我留意到——可能係我諗多咗——呢套工具設計上會將用戶推向 $deep-interview，即使用戶覺得自己已經知道要咩。意圖分類發生喺執行之前。嗰次強制嘅停頓係有意設計嘅。
TDD 作為 agent 護欄——先測試，後代碼
OMX 入面嘅 TDD 整合唔係一個 workflow 建議，更接近一條硬約束。test-driven-development skill 強制執行經典嘅 RED-GREEN-REFACTOR 循環——寫一個會失敗嘅測試、睇佢失敗、寫最小程式碼、睇佢通過、然後 commit。如果 Claude 試圖喺測試之前寫 code，呢個 skill 會令佢將 code 刪咗，重頭嚟過。冇例外。
呢個其實係我認真睇 OMX 嗰陣最意外嘅部分。大部分 agent 設置將測試當成實現之後先至發生嘅嘢。OMX 將測試當成約束實現嗰層規格。 呢個係硬淨淨嘅架構差異，唔係 workflow 偏好。
實際意思：如果你喺一個冇測試基建嘅 codebase 度做嘢，OMX 嘅 TDD 強制會造成摩擦。如果你已經有測試套件，呢個就由"事後補嘅嘢"變成咗一道真實嘅品質關口。
OMX vs Superpowers
唔同嘅範圍——編排 vs 行為約束
呢條問題我喺開發者討論裡面一直見到，我覺得佢值得一個直接嘅回答，而唔係一句模糊嘅"佢哋係唔同嘅工具"。
Superpowers 係 Jesse Luehrs 整嘅 Claude Code 插件，重心喺一個 session 內約束 agent 嘅 行為。Superpowers 插件喺執行前引入一個規劃階段——唔係叫模型立即開始寫 code，而係先產出一份結構化計劃：佢會碰邊啲文件、做啲咩改動、按咩順序。你審閱同批准計劃之後，先至開始寫任何 code。
OMX 啱啱相反，重心喺 運行時基礎設施。HUD、worktree 隔離、MCP 狀態 server、多 provider 團隊 spawn——呢啲全部都係執行環境嘅特性，唔係行為約束嘅特性。
一個簡單嘅區分方法：Superpowers 令單個 agent 喺一個 session 內更聰明、更有紀律。OMX 令一個多 agent 系統喺多個 session 之間可靠運行並保持持久化狀態。
佢哋可以一齊用嘛？
原則上大概得。結構上冇不兼容嘅地方。但老實講：將兩層編排疊埋一齊，會引入大部分 workflow 用唔到嘅複雜度。如果你嘅痛點係單個 agent 跑偏，Superpowers 直接對得上。如果你嘅痛點係喺多個 agent 之間協調、帶隔離狀態嘅並行工作，OMX 對得上。同時用兩個，意味住你要同時理解兩個——呢樣嘢本身就係一筆 overhead。
我仲未想喺呢單嘢落結論。喺推薦組合用法之前，我想再睇多幾個 session 裡面嘅行為。
編排冇解決到嘅問題
冇 memory 嘅委派——任務完成咗，學習蒸發咗
呢部分引起我注意嘅程度，超出咗我預期。
OMX 有持久化嘅狀態——.omx/ 目錄存任務圖、session 產物、memory 文件。但 持久化狀態唔等於能力繼承。狀態記錄嘅係發生咗咩。佢唔會將一條難題被搞掂嘅方式，打包成另一個 agent——或者同一個 agent 喺另一個項目上——可以繼承嘅嘢。
一個 worker 完成咗一次複雜嘅認證重構。任務被標記為完成。產物被記錄。下一個 agent 喺另一個項目、或者三個月後同一個 codebase，面對類似嘅認證問題，起點基本上同第一個 agent 當初一樣。嗰條辛苦贏返嚟嘅推理路徑，冇被保留成可複用嘅資產。佢喺 log 度，如果仲喺度嘅話。
被委派 agent 之間冇能力繼承
呢條缺口坐喺 OMX（以及而家大部分編排工具）仲未解決嘅位置。編排控制嘅係 工作點樣跑。能力繼承要解決嘅係 成功嘅解題過程點樣隨住時間累積。
EvoMap 嘅 GEP 協議文檔 明確咁描述咗呢條分別——將成功嘅執行路徑打包成可驗證、可共享嘅資產，令其他 agent 可以直接採用，而唔係俾佢哋留喺 session log 入面。呢條路喺實踐中能唔能夠撐住，對我嚟講仲係一個開放問題。但佢指向嘅問題係真實嘅。
OMX 對自己嘅範圍好誠實：更好嘅任務路由、更好嘅 workflow、更好嘅運行時。呢段定位直接嚟自 oh-my-codex 嘅 GitHub 倉庫，係準確嘅。佢唔聲稱解決學習遷移。佢聲稱將執行做得更可靠、更協調。 呢啲係唔同嘅問題。
限制同取捨
裝之前值得知道嘅幾樣嘢：
平台限制。 OMX 主要係為帶 Codex CLI 嘅 macOS 或者 Linux 而設計同持續調校。原生 Windows 同 Codex App 唔係預設體驗，可能會壞、可能行為唔一致，而家得到嘅支援亦都比較少。
學習曲線係真嘅。 tmux 依賴、.omx/ 目錄結構、skill 語法、agent 角色——呢個唔係一件十分鐘拎起就用嘅工具。文檔夠詳盡，但詳盡唔等於易上手。
上下文 overhead。 將 AGENTS.md、skill prompt 同 MCP server 上下文注入到每個 session，會喺任何實際工作開始之前先食咗一批 token。對簡單、受控嘅任務，呢層 overhead 可能比編排帶嚟嘅收益仲貴。OMX 嘅價值喺複雜、跨多文件嘅工作上先至會真正顯現。
v1 vs v2 架構分別。 如果你睇過嘅 OMX 早期材料將 Claude Code 描述成主要執行引擎、Codex 向佢委派——嗰個係 v1 模型。而家嘅版本將呢個關係反轉咗。喺投入時間做環境設置之前，值得先睇下 官方 OMX 文檔 入面嘅當前架構。
FAQ
oh-my-codex（OMX）係咩？
OMX 係一個開源嘅 OpenAI Codex CLI 編排層。佢喺標準 Codex 之上加咗多 agent 團隊協調、基於 MCP server 嘅持久化狀態、結構化 workflow（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 內嘅 行為——寫 code 前先規劃、強制 TDD、結構化嘅 review 循環。OMX 提供嘅係 運行時基礎設施——worktree 隔離、多 agent 協調、持久化狀態、HUD 監控。Superpowers 令一個 agent 更聰明。OMX 令一個 agent 系統穩定運行。兩者嘅範圍差異大到直接比較反而會錯過重點。
oh-my-codex 支唔支援 TDD workflow？
支援。TDD skill 將 red-green-refactor 循環當成硬約束執行，唔係建議。測試必須寫喺實現 code 之前。如果 agent 試圖先寫實現，呢個 skill 會強制刪除同重頭嚟。呢條規則專門套用喺 $tdd workflow 路徑。
oh-my-codex 嘅 agent 記唔記得學過嘅嘢？
OMX 維護持久化狀態——session log、任務產物、項目 memory 文件全部都喺 .omx/ 裡面。同一個項目之內，agent 可以由過去嘅 session 拎返上下文。佢冇做嘅係：將成功嘅解題路徑打包成可轉移能力，俾佢可以被唔同項目上嘅唔同 agent 繼承。呢條分野——狀態持久化同能力繼承之間——就係而家編排工具普遍停低嘅地方。
我大概仲會繼續睇 v2 架構點樣沉澱落嚟。老實講，遠離 Claude 委派模型呢件事到底係啱嘅取捨、定係只係必要嘅取捨，我心入面都未完全諗通。
Previous Posts:
👉 如果你想更清楚咁知道編排喺 agent stack 裡面嘅位置，請睇：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?
