如何安排 3 个 AI 代理同时写代码：OMX 团队协作完整教程

如何安排 3 个 AI 代理同时写代码OMX 团队协作完整教程【免费下载链接】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多人开发时单人 AI 助手往往顾不过来得这么细需求没人澄清改动没人对账进度全靠口头同步。oh-my-codexOMX是 OpenAI Codex CLI 的工作流增强层它的 OMX 团队协作模式把 AI 助手拆成一支有分工、有阶段、有共享状态的班组多人开发场景下可以直接用。一、先看现场为什么单人助手不够用想象这样一个画面你让一个助手同时改鉴权、补测试、更新文档。它只能串行做做完一件才能碰下一件。更麻烦的是旁边另一个同事也在用 AI 改同一个模块两边的改动互相看不见。单人助手缺的就是四样东西分工谁擅长什么、并行能不能同时开工、状态共享干到哪一步了、依赖协调谁必须等谁。这套团队模式就是补这四块的。它基于 tmux 把每个 worker 放进独立窗格共享一份落在.omx/state/team/下的状态文件所以即使你关掉终端重开任务、进度、问题清单都还在。二、团队的两个坐标角色和阶段 五个阶段从计划到修复的闭环整个团队流程由 src/team/orchestrator.ts 定义共五个阶段team-plan产出任务清单和依赖关系。team-prd写清范围和验收标准。team-exec动手写代码、补测试。team-verify拿证据说话判过或不过。team-fix定位根因、修复后回到验证。阶段之间是单向推进的fix 超过次数上限会直接标记失败不会死循环。20 多个角色按职责分泳道角色定义在 src/agents/definitions.ts共 30 余个每个都指定了推理强度、模型档位和工具权限。常用的几个explore只读快速搜代码库和符号。analyst澄清需求、挖隐藏约束。planner排任务顺序、标风险。architect定系统边界和接口用最高推理档。executor写实现、做重构。verifier收集完成证据验证声明是否成立。每个阶段还会推荐配套角色plan 阶段给 analyst plannerexec 阶段给 executor test-engineerverify 阶段给 verifier quality-reviewerfix 阶段给 debugger 顶上。三、按任务复杂度选协作模式模式选择先看任务再定人数一个简单的经验值单文件改动 1 个 executor 就够跨 2~3 个模块用 3 个 executor 并行涉及安全、架构的才加评审角色。任务越大越该把想和做分开。三种典型配置标准工作流先访谈澄清再评审计划最后并行执行。这是复杂任务推荐走的路。$deep-interview clarify the authentication change $ralplan approve the auth plan and review tradeoffs $team 3:executor execute the approved plan in parallel专家协同和质量保证两种混搭一条命令即可$team 2:architect,1:planner,3:executor redesign the payment system $team 2:executor,1:quality-reviewer,1:security-reviewer implement secure authentication注意N:agent-type里的 N 是人数agent-type 选的是角色提示词不是 CLI。想混用 Codex 和 Claude 作为 worker通过OMX_TEAM_WORKER_CLI环境变量指定即可。四、配置四步从评估到监控 ⚙️第一步评估复杂度定规模先估改动面。只碰一个文件用 1~2 个执行者中等任务 2~3 个执行者加 1 个评审大改 3~5 个执行者并引入专业角色。第二步配置团队启动后团队配置落在config.json核心字段含义agent_type是 worker 角色worker_count与max_workers控制当前和上限人数worker_launch_mode决定交互式还是纯提示启动workspace_mode为worktree时每个 worker 各占一个 git 工作树。这些结构见 src/team/state/types.ts 和 src/team/state/config.ts。第三步设置流程与检查点阶段转换规则、验证检查点、自动修复上限都在编排器里配置。流程编排层在 src/pipeline/orchestrator.ts它决定什么条件下进入下一阶段。第四步盯住状态按需干预团队状态文件跟踪四类信息任务分配谁拿着哪个任务、进度pending/in_progress/completed 计数、问题跟踪failed 及原因、性能指标worker 心跳和回合数。监控用omx team status team轮询或挂 src/hud/ 的 HUD 面板看实时视图。五、排障三板斧协调、同步、瓶颈 协调效率低先查 src/team/state/dispatch.ts 的分发记录。常见原因是任务粒度太粗多个 worker 抢同一文件。把任务切到一文件一任务冲突基本消失。状态同步困难代理之间通信走邮箱文件mailbox/*.json实现见 src/team/state/mailbox.ts。查同步问题先看leader-fixed.json有没有 ACK再对 worker 的status.json。性能瓶颈扩容策略在 src/team/scaling.ts思路是按负载动态调 worker 数而不是固定堆人。锁机制src/team/state/locks.ts防止多个代理同时写同一状态文件IO 层src/team/state/io.ts用文件快照降低读放大。告警接 src/notifications/给关键阈值设通知即可。六、进阶与 FAQ四个进阶用法动态调角色前期多放 explore 和 analyst中期加 executor 和 architect收尾引入评审。工作树隔离$team --worktree-mode让每个 worker 在独立 worktree 干活共享同一份团队状态。状态持久化支持暂停恢复、状态快照和历史追踪中断后omx team resume可接上。跨团队协作主团队做核心功能辅助团队处理依赖评审团队最后把关。什么时候该停下来worker 报错 ENOENT多半是状态目录已被 shutdown 清掉先查任务是否还在 in_progress。启动后收不到 ACK检查 worker 窗格是否卡在信任提示上。团队在途任务未清零时不要 shutdown等pending0且in_progress0再收工。这套编排的方向也很清楚角色自动推荐、按表现自适应调流程、跨项目协作、混合更多模型。完整上手见 docs/getting-started.html角色全目录见 docs/agents.html。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考