企业官网建设流程全解析

oh-my-codex 团队协作实战：3 步把 Codex 跑成一支开发小队

【免费下载链接】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

oh-my-codex（OMX）是 OpenAI Codex CLI 的工作流增强层：Codex 继续当执行引擎，OMX 在它外面补上一层角色分工、并行编排和状态管理。它要解决的是三个具体的坑——需求聊着聊着就跑偏、单会话干活太慢、干到一半断了没法接着来。如果你已经在用 Codex CLI，这篇文章把从装好到跑通团队并行执行的完整路径讲一遍。

环境怎么配：从安装到跑通的 5 分钟路径

先说清楚边界：OMX 主要面向 macOS 和 Linux 上的 Codex CLI，Windows 原生环境不是默认体验。前置条件就三条——Node.js 20+、一个已登录的codex命令、想跑团队模式的话装个tmux。

安装和首次配置：

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

setup 这步别急着直接跑，先想清楚作用域：在你要让 Codex 编辑的那个 git 仓库里用--scope project，让仓库自己拥有持久的AGENTS.md指导；只是想做用户级 Codex 配置就用--scope user。--merge-agents表示保留你已有的AGENTS.md内容，只在<!-- OMX:AGENTS:START -->标记之间刷新 OMX 生成的段落。

装完别以为omx doctor全绿就万事大吉，它只验证安装形状和钩子接线。真正的冒烟测试是让 Codex 实打实发一次请求：

codex login status omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"

回到 git 仓库里，用推荐姿势启动：omx --worktree=feat/task --madmax --xhigh。--xhigh是推理强度的快捷开关；--madmax等价于 Codex 的--dangerously-bypass-approvals-and-sandbox，会拆掉审批和沙箱护栏，只在你完全信任的仓库里用。--worktree把启动挪进一个独立的 git 工作树——这也是后文并行的基础。

需求老跑偏：deep-interview、ralplan、ultragoal 怎么串

场景一：需求本来就模糊，你让模型直接开干，产出和预期差十万八千里。OMX 把澄清、规划、执行拆成一条固定的主线，三个技能各管一段：

• $deep-interview "..."：只负责把意图、边界和非目标聊清楚，不碰代码
• $ralplan "..."：把澄清结果变成一份被审批过的计划和架构取舍。注意它到规划产物就停手，自己不写代码
• $ultragoal "..."：把批准的方案转成串行的持久化 Codex 目标，检查点落在.omx/ultragoal，这是默认的执行主干

如果任务需要跨轮次对账的持久目标结构，再补一句/goal；如果你更想要一个单一负责人死磕到底的完成循环，用$ralph替代 ultragoal 即可。这条链路的价值不在每个命令有多强，而在顺序被固化了——先澄清、再审批、后执行，想跳步得手动绕过。

一个人干太慢：$team 并行执行的正确姿势

场景二：任务能拆成互不干扰的几块，单会话串行等不起。这时用omx team，在 shell 里启动，例如omx team 3:executor "fix the failing tests with verification"——冒号前面是数量，后面是角色，3 个执行者同时开工。

背后的编排器是 团队编排器，它按 team-plan、team-prd、team-exec、team-verify、team-fix 五阶段推进，每个阶段的产物（计划、需求、执行证据、验证结果、修复）都有对应状态。角色目录在 代理定义 里，超过 20 种专业角色，executor、architect、planner、quality-reviewer、security-reviewer 都是现成的：

• 重设计一个子系统：omx team 2:architect,1:planner,3:executor，架构师画边界、规划师排依赖、执行者并行实施
• 安全敏感的改动：执行者加质量评审、安全评审并行盯

两个容易忽略的细节。第一，团队成员默认各自使用独立 worktree，互不污染，不需要你手动隔离。第二，当 team 跑在一个 Ultragoal 故事里时，状态仍然归主流程所有，执行者只向上汇报"检查点就绪"的证据，不会直接去改.omx/ultragoal，避免多写者互相踩。

另外别为了用而用：很小的原子任务上，团队运行会自己把隐式并行压到 1 个执行者并打印过度编排警告——协作本身有成本，这点设计是对的。

进度去哪了：状态持久化与断点恢复

场景三：跑了半小时，终端断了，上下文被压缩了，想接着干却只能从头再来。

团队状态落在 团队状态类型 定义的结构里，覆盖任务分配、工作进度、问题跟踪这些维度。日常操作就三个命令：

• omx team status <team-name>：看当前谁在干什么
• omx team resume <team-name>：断点恢复
• omx team shutdown <team-name>：收尾，死团队加--force --confirm-issues

启动阶段会往.omx/state/team/<team-name>/preflight-context.json写入原始任务、worker 拆分、Ultragoal 上下文和验证清单，所以大团队跑完一轮上下文压缩后还能带着完整信息恢复。项目的.omx/目录同时存计划、日志、内存和模式跟踪，进度不再只活在某次会话里。想看实时状态而不打扰主流程，还有omx hud --watch这个监控面。

环境别打架：worktree 隔离与并发安全

跑过两个以上长会话的人都知道，同一份 checkout 里并发干活迟早出事。OMX 的隔离策略分三层：

• 代码隔离：--worktree=feature/auth把每个任务挪进命名工作树。并发跑--madmax时，每个会话必须各领一个独立命名的 worktree，别在同一个目录里开多份
• 状态隔离：一次标准启动独占一个OMX_ROOT下可写的会话指针；第二个普通启动会同 root 失败而不是偷偷共享。想开第二路会话，给它显式 root，比如OMX_ROOT="$HOME/.omx/instances/second-conversation" omx
• 免管理启动：--direct或OMX_LAUNCH_POLICY=direct可以跳过 tmux/HUD 托管，一次性的快速启动够用

隔离之外还有一层上下文卫生：一个任务默认只加载 2-5 个相关 skills。README 里专门点了反模式——任务还没说清楚就"以防万一"加载 20 个 skills，这会把会话上下文撑爆，让模型的注意力分散在无关流程上。skills 目录里有三十来个现成的（skills 参考），按需取用即可。

卡住了怎么办：假绿诊断与常见坑

omx doctor全绿但真跑不动，这是典型的"假绿"，排查路径见 故障排查。两层诊断要分清：omx doctor管安装和接线，omx exec的真实模型调用才暴露认证、profile、base-URL 的问题。几个高频坑：

• 依赖本地 OpenAI 兼容代理时，确认当前生效的~/.codex/config.toml里openai_base_url是对的，否则代理签发的 key 会被发去默认端点，报 401
• 自定义 HOME、容器或 CI 环境里，别假设你个人用户的~/.codex就是 Codex 实际读的那份
• 团队状态残留（resume_blocker、tmux 会话没了）：确认团队已死后用omx team shutdown <name> --force --confirm-issues清干净，再omx doctor --team复检
• Intel Mac 启动时syspolicyd/trustdCPU 飙高：对 omx 二进制执行xattr -dr com.apple.quarantine，或把终端加进开发者工具白名单
• Windows 场景：WSL2 + tmux 是比原生更稳的路径

项目本身还在往更厚的运行时走：crates/ 目录下的 Rust 运行体（sparkshell、mux、runtime）已经在做 shell 原生的检查和验证，算是把"工作流层"往"运行时层"延伸的动向，关注 changelog 即可，不影响现在的使用。

OMX 适合已经在用 Codex CLI、想让会话有结构、让任务能并行、让进度可恢复的开发者——下一步就从omx doctor加一次omx exec冒烟测试开始。

【免费下载链接】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