企业官网建设流程全解析

OmX 快速上手指南：把 Codex CLI 扩展为多代理协作、可观察的 AI 编码工作流

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex

OmX（oh-my-codex）是一个为 Codex CLI 构建的开源工作流编排层。它不替换你的 AI 编码助手，而是把 Codex 从单一会话窗口扩展为可插件化、可协作、可观察的开发工作流：用钩子（hooks）挂载自动化逻辑，用多代理（agent teams）并行分工，用状态面板随时看清任务进展。本文给出三步快速上手路径和典型适用场景，帮你判断 OmX 值不值得引入。

它解决什么问题

用 AI 编码助手做真实开发，通常会遇到两个麻烦：

• 长任务过程不可见。一个重构任务可能跑几十分钟，会话一中断或你切了终端，就说不清计划进行到哪一步、当前卡在哪里、还剩哪些验证没做。
• 复杂任务无法拆分。一个较大的需求同时涉及改代码、跑测试、做审查，但单个代理只能顺序完成，通知、检查这类重复动作也只能靠你手动触发。

OmX 的思路是在 Codex 之上加一层编排：Codex 继续担任执行引擎，OmX 负责任务路由、工作流模板和运行时状态。计划、日志、进度统一写入项目内的.omx/目录，中断后可以接得上；需要时可以一条命令启动多个代理并行执行。

先跑起来

前置条件：Node.js 20+，已安装并登录 Codex CLI（用codex --version验证）；打算用团队模式的话，macOS/Linux 上先装好 tmux。

最小上手路径就三步：

npm install -g oh-my-codex omx setup --scope project --merge-agents omx doctor

• omx setup把提示词、技能与 AGENTS 引导写入项目。请在你要让 OmX 操作的 git 仓库目录下执行；如果只做用户级配置，用omx setup --scope user。
• omx doctor检查安装、钩子和运行时依赖是否就绪。

体检通过后做一次真实请求的冒烟测试，确认 Codex 认证与网络链路正常：omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"。然后在 git 项目里用推荐方式启动会话：omx --worktree=feat/task --madmax --xhigh，它会为任务单独建一个 worktree，隔离更安全。需要阅读源码时，把仓库克隆到本地即可：git clone https://gitcode.com/GitHub_Trending/oh/oh-my-codex。

完整的引导流程建议从 Getting Started 和 Demo 指南 开始看。

能力拆解

自动化钩子：如何配置 omx hooks

钩子让你把自动化逻辑写成.omx/hooks/下的.mjs插件文件。会话开始、工具调用前后、会话停止等生命周期事件发生时，运行时会自动分发给对应插件：

omx hooks init omx hooks status omx hooks validate omx hooks test

omx hooks init会生成一个样例插件脚手架，你可以在它上面写自己的逻辑，例如会话停止时发通知、工具执行前做检查。事件模型和负载字段详见 钩子扩展说明，Codex 原生钩子与回退路径的对应关系见 Codex 原生钩子映射。

多代理协作：Codex CLI 多代理协作怎么配置

需要拆分的大任务用omx team启动多个工作代理。每个 worker 拥有独立的 tmux 窗格和独立的 git worktree，通过.omx/state/team/下的共享状态协调：

omx team 3:executor "fix the failing tests with verification" omx team status <team-name> omx team resume <team-name>

代理的角色定义来自仓库的prompts/与skills/目录，完整目录见 Agent 目录 和 Skills 参考。仓库 docs/benchmarks/ 目录还附带一张基准对比截图，同一任务下两种方式的浏览器游戏（Tetris）产出并排呈现，可以用来直观对比多代理工作流的输出差异：

状态观察：OmX 状态面板适合什么场景

针对"看不见 AI 编码助手在做什么"的问题，OmX 给了两个观察面：一是.omx/下的状态文件（计划、日志、目标账本），随时可读可查；二是omx hud --watch，一个面向运行时与任务状态的实时监控面板。配合/goal持久目标与$ralph单负责人完成循环，长任务可以按"一组有账本的检查点"来推进，而不是一问一答式的单次对话。

适合谁用，什么时候值得用

• 日常使用 Codex CLI 的开发者：需要更稳的会话管理、项目级引导和可恢复状态。
• 多步骤任务较多时：需要持久目标与检查点，担心中途丢失进度。
• 长期、可拆分的大任务：需要多个代理并行、各自独立 worktree，避免互相踩踏。
• 重复操作多：希望把检查、通知、记录类流程沉淀成钩子插件。

两个边界要说清楚：如果你只想要纯粹的 Codex、不需要额外工作流层，大概率用不上 OmX；另外 OmX 主要面向 macOS/Linux + Codex CLI 调优，原生 Windows 不是默认支持路径。

下一步看哪里

按优先级排列的主要入口：

1. Getting Started：官方快速上手流程；
2. 钩子扩展说明：自定义自动化的事件模型；
3. 排障指南：环境、认证与执行就绪问题怎么查；
4. 模型与环境路由：改~/.codex/config.toml，参考 模型/环境路由参考。

建议的行动路径：先在一个测试项目里跑通omx setup和omx doctor，确认链路没问题；再用omx hooks init初始化一个钩子，熟悉自动化扩展点；等单会话流程用顺手了，再尝试omx team跑一次并行任务。

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex