企业官网建设流程全解析

如何配置OMX团队协作：多人开发中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

oh-my-codex（OMX）是 Codex CLI 的工作流增强层，核心能力就是 OMX 团队协作：让多个 AI 助手按角色分工、拆任务、并行开发。它解决多人开发里两个常见痛点：单个助手顾不过来的任务面，以及人之间进度难对齐。

先把"协作"是什么搞清楚 🍳

想象一家餐厅后厨的饭点：主厨接单一拆菜（规划），每个灶台各管一摊（执行），出菜前有人检查装盘（验证），点单系统让所有人看着同一份任务清单（共享状态）。OMX 的团队协作就是这间后厨——没有哪个 AI 是单打独斗，人人有工位，系统保证大家步调一致。

也可以理解成乐队：鼓手不弹独奏，但没有节奏，谁也进不了拍。OMX 里 leader 会话就是鼓手，它不写代码，负责定节奏、分活、看进度。

这套协作有具体落点：项目下的.omx/state/team/目录。任务清单、邮箱、worker 心跳文件都在这里。你可以先翻一眼这个目录，看看"协作"实际长什么样。

你的 AI 团队里都有谁

OMX 内置 20 多个专业角色，统一在 src/agents/definitions.ts 里注册。最常用的是这几位：

手把手：第一次组建团队的 3 个步骤 🚀

第 1 步：确认环境

团队模式靠 tmux 分屏跑 worker，leader 会话必须在 tmux 里。先跑：

tmux -V echo $TMUX

两条都要有输出。$TMUX 为空就先进 tmux。团队的完整调度逻辑在 src/team/orchestrator.ts 里，会走"规划→需求→执行→验证→修复"五阶段流程。

第 2 步：启动团队

格式是omx team N:角色 "任务"，N 是人数，角色决定 worker 用什么提示词。

omx team 3:executor "加一个登录限流，并跑完所有测试"

跑起来后窗口会分成 3 格，每个 worker 独立干活。

第 3 步：看状态，收尾

任务终态后再关，别中途 shutdown：

omx team status my-team omx team shutdown my-team

status 读到的数据结构在 src/team/state/types.ts，能看出 pending、in_progress、failed 的数量和 worker 是否活着。

按场景选 AI 协作配置：3 个典型开发场景

场景一：需求模糊——认证模块改造

什么时候用：任务边界不清、验收标准多、怕 worker 先跑偏。

$deep-interview "改造登录限流策略" $ralplan "审一下 auth 计划和取舍" omx team 3:executor "并行执行已批准的计划"

前两条对齐认知，第三条才开干。先跑一下看看效果，访谈质量直接决定后面的返工量。

场景二：大重构要设计先行——支付系统

什么时候用：跨模块边界、接口要动、多人得对同一份契约。

omx team 2:architect,1:planner,3:executor "重构支付系统"

architect 定边界，planner 排顺序，executor 铺量实现。

场景三：高质量交付——安全加固

什么时候用：产出涉安全、马上要上线，需要有人实时盯质量。

omx team 2:executor,1:security-reviewer,1:quality-reviewer "实现并审查认证流程"

executor 管功能，两个 reviewer 跟进度查问题。

团队跑起来之后：盯状态、调节奏

团队在跑的时候，别放羊。三个盯法：

omx team status my-team omx hud --watch omx team await my-team --timeout-ms 30000 --json

status 看任务快照，hud 实时刷团队模式与活跃度，await 是事件式等待，适合写进脚本。

任务的流转靠 src/team/state/dispatch.ts 里的分发队列。任务被认领、执行、标记完成，逐个走，不会让两个 worker 抢同一单。

调节奏按阶段来：

• plan/prd 阶段：worker 等计划，就先跑 deep-interview 补上下文；
• exec 阶段：pending 堆积就加大 executor 数量；in_progress 卡住，查心跳文件，用omx team resume my-team接回；
• verify/fix 阶段：来回多轮，多半是验收标准太松，回计划里改清楚。

下面是团队基准运行的产出对比，能直观看出并行执行和单 worker 的差距：

让团队协作效率再翻一倍的 5 个实操技巧 ⚡

1. worktree 隔离并行：omx team --worktree feat-a "开发特性 A"，每人一棵独立工作树，互不踩文件。
2. 混合模型分工：OMX_TEAM_WORKER_CLI_MAP=codex,claude omx team 2:executor "拆文档和代码任务"，不同 lane 用不同模型。
3. 事件式等待：用omx team await my-team --timeout-ms 30000 --json代替手动轮询，脚本里最稳。
4. HUD 常驻：leader 窗口跑omx hud --watch，加--preset=full看全量状态。
5. 断线可恢复：状态持久化在.omx/state/下，离开后随时omx team resume my-team接回现场。

团队协作不顺利时，3 个高频问题的排查路径 🔍

现象一：omx team起不来，报 tmux 相关错误原因：leader 会话不在 tmux 里，或 tmux 没装。 解法：tmux -V验证安装，先进 tmux 再启动；分屏前查一下窗口里有没有重复的hud --watchpane，有就先清掉。

现象二：status 里有 dead worker，没人响应原因：worker 进程挂了状态没恢复，或 leader 离开太久丢了上下文。 解法：先omx team status my-team看快照，再omx team resume my-team接回；看mailbox/leader-fixed.json里有没有 ACK，没有就是 worker 没被正常触发。

现象三：verify 和 fix 来回弹，最后 failed原因：验收标准模糊，verifier 和 executor 对完成度的定义不一致，修复次数打到上限（默认 3 次）。 解法：别硬推。先$deep-interview把标准说死，或把任务拆小，再重新omx team启动。

OMX 接下来会往哪走

团队运行时还在持续演进：角色路由更聪明，修复循环更细粒度，跨团队、跨项目的协调也在路线上。扩展与扩容策略可以看 src/team/scaling.ts，有变化会先落在这里。

流程就这些：查环境、定角色、起团队、盯状态、干净收尾。OMX 团队协作没有加什么玄学，它只是把多个 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