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周三下午群里扔过来一个任务“把认证模块重构一下顺带支持 token 刷新。”三个人加一组 AI 代理第一个问题不是“怎么写”而是“谁去摸代码、谁去写、谁来验收”——分错工并行就是互相踩。这个问题正是 OMX 团队协作要解决的。oh-my-codexOMX是套在 OpenAI Codex CLI 之上的工作流增强层它不替代模型而是把多个 AI 代理组织成有分工、能并行、共享状态的团队再把整段协作压进一个可复现的闭环。下面以这次认证改造为例把组队、派活、出错、恢复走一遍。 谁干什么先记住这张角色表OMX 内置 20 多种代理角色每个角色的提示词、推理强度和工具权限都不同定义集中在 src/agents/definitions.ts。常用角色直接查这张表角色职责一句话什么时候请它explore代码库快速探索、文件与符号定位进场前先搞清楚仓库里有什么analyst澄清需求、定验收标准、挖隐藏约束任务描述还含糊时planner拆任务、排顺序、标风险需求定稿之后architect系统边界、接口设计、长期权衡改动会动到结构时executor写代码、重构、落地功能真正动代码时verifier收集完成证据、检验测试够不够收口前debugger根因定位、隔离回归验证不过时quality-reviewer / security-reviewer质量与安全视角评审高风险改动原则只有一条只读角色explore、architect不碰代码执行角色executor不给自己验收verifier 只看证据。角色混用是大多数协作混乱的根源。 一次完整协作怎么跑通从澄清到验收整个闭环分五段team-plan → team-prd → team-exec → team-verify → team-fix规划→需求定义→执行→验证→修复。跳转规则写在 src/team/orchestrator.ts跳段会被直接拒绝比如想从规划直奔执行不行。每段还有推荐配置规划段 analyst planner需求段 product-manager analyst执行段 executor test-engineer验证段 verifier 评审修复段 executor debugger。落到操作就是三条命令$deep-interview 把认证改造的边界和验收标准问清楚它解决把“重构认证”一句话逼问成可测试的需求歧义挡在门口。$ralplan 审一下认证方案和取舍它解决Planner 出草案Architect 和 Critic 轮流挑刺达成一致才放行。$team 3:executor 并行执行已批准的方案它解决在 tmux一个能分屏的终端复用器里拉起 3 个 executor 工人共享同一份任务清单各自认领。注意N:role里的数字是工人数量、role 决定用哪份角色提示词实际跑哪个 CLI 还能单独指定甚至混编。验证阶段不通过会自动切到 team-fix 修复修完回到执行或重新验证默认最多修 3 轮超限直接判 failed不会无限打转。⚠️ 任务变大以后并行怎么不踩、状态怎么不丢工人从 3 个变 5 个麻烦跟着来改文件打架、状态不同步、一断线全丢。OMX 的解法是按问题逐个拆文件冲突omx team --worktree给每个工人单独建一个 git worktree同一仓库检出多个目录各改各的分支最后统一合并状态同步.omx/state/team/下维护任务文件、邮箱和分发锁实现在 src/team/state/工人走分发队列领任务而不是抢跨角色沟通走邮箱而不是盯屏进度可见每个工人上报心跳存活与否、跑了多少轮和状态working / blocked / donesrc/hud/ 里的 HUD 面板实时刷出来哪条车道卡住一眼看见跨团队协作主团队做核心改造辅助团队啃依赖模块评审团队守质量各自独立状态根靠任务接口对接上面这张对比截图来自仓库自己的基准记录两种协作配置并行产出结果好坏直接摆在同一屏里对照。 中断以后团队状态怎么恢复团队状态全部落盘当前阶段、任务清单、每次阶段跳转谁、何时、为什么切过去、已修复几轮都写在状态文件里。于是中断关掉终端不等于从头来状态在磁盘上不在内存里恢复再次启动时读回最后阶段接着跑且只有“激活且未进入终态”的团队才能续复盘阶段跳转记录本身就是一份审计日志扯皮时翻时间线就行更长的流水线还可以用 src/pipeline/orchestrator.ts 的阶段编排把“深度访谈→共识规划→代码评审→质量保障”串成 autopilot 流程每走完一段就持久化一次。 任务规模 → 推荐组队速查表任务规模推荐组队理由单文件小改$team 1:executor一条执行车道够用省掉仪式单模块新功能$team 2:executor,1:verifier多一条验收车道避免自己验收自己跨模块重构$team 2:architect,1:planner,3:executor设计先行定完顺序再并行写高风险改动认证、支付$team 2:executor,1:quality-reviewer,1:security-reviewer评审与编码并行不串行等待长线任务、多团队主团队 辅助团队 评审团队--worktree隔离状态互相隔离边界处合并角色细节和命令参数可查 官方入门文档 与 代理目录状态字段的完整约定见 docs/contracts/team-runtime-state-contract.md。【免费下载链接】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），仅供参考 OMX 团队协作：多代理怎么分工、并行怎么不踩？+ 按任务规模组队速查表
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周三下午群里扔过来一个任务“把认证模块重构一下顺带支持 token 刷新。”三个人加一组 AI 代理第一个问题不是“怎么写”而是“谁去摸代码、谁去写、谁来验收”——分错工并行就是互相踩。这个问题正是 OMX 团队协作要解决的。oh-my-codexOMX是套在 OpenAI Codex CLI 之上的工作流增强层它不替代模型而是把多个 AI 代理组织成有分工、能并行、共享状态的团队再把整段协作压进一个可复现的闭环。下面以这次认证改造为例把组队、派活、出错、恢复走一遍。 谁干什么先记住这张角色表OMX 内置 20 多种代理角色每个角色的提示词、推理强度和工具权限都不同定义集中在 src/agents/definitions.ts。常用角色直接查这张表角色职责一句话什么时候请它explore代码库快速探索、文件与符号定位进场前先搞清楚仓库里有什么analyst澄清需求、定验收标准、挖隐藏约束任务描述还含糊时planner拆任务、排顺序、标风险需求定稿之后architect系统边界、接口设计、长期权衡改动会动到结构时executor写代码、重构、落地功能真正动代码时verifier收集完成证据、检验测试够不够收口前debugger根因定位、隔离回归验证不过时quality-reviewer / security-reviewer质量与安全视角评审高风险改动原则只有一条只读角色explore、architect不碰代码执行角色executor不给自己验收verifier 只看证据。角色混用是大多数协作混乱的根源。 一次完整协作怎么跑通从澄清到验收整个闭环分五段team-plan → team-prd → team-exec → team-verify → team-fix规划→需求定义→执行→验证→修复。跳转规则写在 src/team/orchestrator.ts跳段会被直接拒绝比如想从规划直奔执行不行。每段还有推荐配置规划段 analyst planner需求段 product-manager analyst执行段 executor test-engineer验证段 verifier 评审修复段 executor debugger。落到操作就是三条命令$deep-interview 把认证改造的边界和验收标准问清楚它解决把“重构认证”一句话逼问成可测试的需求歧义挡在门口。$ralplan 审一下认证方案和取舍它解决Planner 出草案Architect 和 Critic 轮流挑刺达成一致才放行。$team 3:executor 并行执行已批准的方案它解决在 tmux一个能分屏的终端复用器里拉起 3 个 executor 工人共享同一份任务清单各自认领。注意N:role里的数字是工人数量、role 决定用哪份角色提示词实际跑哪个 CLI 还能单独指定甚至混编。验证阶段不通过会自动切到 team-fix 修复修完回到执行或重新验证默认最多修 3 轮超限直接判 failed不会无限打转。⚠️ 任务变大以后并行怎么不踩、状态怎么不丢工人从 3 个变 5 个麻烦跟着来改文件打架、状态不同步、一断线全丢。OMX 的解法是按问题逐个拆文件冲突omx team --worktree给每个工人单独建一个 git worktree同一仓库检出多个目录各改各的分支最后统一合并状态同步.omx/state/team/下维护任务文件、邮箱和分发锁实现在 src/team/state/工人走分发队列领任务而不是抢跨角色沟通走邮箱而不是盯屏进度可见每个工人上报心跳存活与否、跑了多少轮和状态working / blocked / donesrc/hud/ 里的 HUD 面板实时刷出来哪条车道卡住一眼看见跨团队协作主团队做核心改造辅助团队啃依赖模块评审团队守质量各自独立状态根靠任务接口对接上面这张对比截图来自仓库自己的基准记录两种协作配置并行产出结果好坏直接摆在同一屏里对照。 中断以后团队状态怎么恢复团队状态全部落盘当前阶段、任务清单、每次阶段跳转谁、何时、为什么切过去、已修复几轮都写在状态文件里。于是中断关掉终端不等于从头来状态在磁盘上不在内存里恢复再次启动时读回最后阶段接着跑且只有“激活且未进入终态”的团队才能续复盘阶段跳转记录本身就是一份审计日志扯皮时翻时间线就行更长的流水线还可以用 src/pipeline/orchestrator.ts 的阶段编排把“深度访谈→共识规划→代码评审→质量保障”串成 autopilot 流程每走完一段就持久化一次。 任务规模 → 推荐组队速查表任务规模推荐组队理由单文件小改$team 1:executor一条执行车道够用省掉仪式单模块新功能$team 2:executor,1:verifier多一条验收车道避免自己验收自己跨模块重构$team 2:architect,1:planner,3:executor设计先行定完顺序再并行写高风险改动认证、支付$team 2:executor,1:quality-reviewer,1:security-reviewer评审与编码并行不串行等待长线任务、多团队主团队 辅助团队 评审团队--worktree隔离状态互相隔离边界处合并角色细节和命令参数可查 官方入门文档 与 代理目录状态字段的完整约定见 docs/contracts/team-runtime-state-contract.md。【免费下载链接】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），仅供参考