尧图网站建设 
AI 助手团队协作怎么落地OMX 用 5 个阶段把并行开发管住【免费下载链接】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-codex3 个 AI 同时改同一个仓库最常见的结局是互相覆盖这边刚写完鉴权那边已经改了模块名测试全挂。多人开发分工本身不难难的是没人记下谁在做什么、按什么顺序。oh-my-codexOMX就是加在 Codex CLI 之上的一层 AI 助手团队协作机制它把这类任务拆成阶段、面板和可恢复的磁盘状态。 一分钟定位一场排练不是一起即兴把 OMX 想成乐队排练的指挥系统而不是几个乐手各弹各的指挥是团队编排器决定现在进入哪个乐章谁先谁后分声部乐手是 20 多个专业代理executor 负责主旋律verifier 负责听错音architect 负责看总谱五段流程是节拍器没人能抢拍磁盘状态是曲谱副本中途走音或停场回来能接着弹Codex 仍然是实际演奏的引擎OMX 负责排谱、分声部和控场。核心机制拆解五阶段流水线任务不许跳拍一句话定位一个团队任务只能沿固定路线前进想跳步会直接报错。export type TeamPhase team-plan | team-prd | team-exec | team-verify | team-fix; const TRANSITIONS: RecordTeamPhase, ArrayTeamPhase | TerminalPhase { team-plan: [team-prd], team-exec: [team-verify], team-verify: [team-fix, complete, failed], // ... };为什么这么设计验证不过时任务可以退回 fix 再回 exec但 fix 循环默认最多 3 次max_fix_attempts超了就标记 failed。与其让一群代理互相修到天亮不如让它停下来交还给人。规则写死在 src/team/orchestrator.ts 里每次转场都会带时间戳记入phase_transitions出问题能回放。角色花名册什么人上什么台一句话定位代理不是一个模型套 N 份提示词而是按职责分了工具权限和推理档位。export interface AgentDefinition { name: string; // 如 executor、verifier、architect reasoningEffort: low | medium | high | xhigh; modelClass: frontier | standard | fast; tools: read-only | analysis | execution | data; }为什么这么设计explore 只读、低开销适合快速扫代码库architect 用 xhigh 档位但同样只读保证设计阶段不动手。角色定义集中在 src/agents/definitions.ts提示词本体放在prompts/目录改行为不用动代码。状态落在磁盘断线能续场一句话定位代理之间不靠聊天同步靠共享的状态文件同步。团队配置、任务清单、每个 worker 的状态都写在.omx/state/team/下mailbox.ts管代理间留言dispatch.ts管任务分派locks.ts防止两个 worker 同时写同一份状态配置结构见 src/team/state/types.tsworker_count和max_workers直接控制并行度为什么这么设计tmux 面板随时可能挂掉但文件还在canResumeTeamState能判断一个团队是否值得恢复。状态共享不依赖任何进程活着这是它敢让多个长任务并行执行的底氣。三种配置按任务重量选轻任务单角色并行就够omx team 2:executor fix all endpoint docs and report gaps适用边界任务之间互不依赖比如逐文件修文档、批量改错字。2 个 worker 起步再多只会互相排队等状态。中任务先对齐再并行$deep-interview clarify the authentication change $ralplan approve the auth plan and review tradeoffs $team 3:executor execute the approved plan in parallel适用边界有依赖关系但范围清楚的改动。前两步花的时间买的是后面 3 个 executor 不跑偏需求没对齐就并行等于让乐队没看谱就开演。重任务混声部大编制omx team 2:architect,1:planner,3:executor redesign the payment system适用边界跨模块的大改动架构和排期需要专人把关。涉及安全或合规时把 1 个 executor 换成 quality-reviewer 或 security-reviewer让评审和实现同时走。最小上手路径5 步跑通确认引擎可用codex --version且已登录安装 OMXnpm install -g oh-my-codex在项目根目录做项目级配置omx setup --scope project先进 tmux 再干活用tmux -V确认已安装启动首个团队omx team 2:executor task description随后观察分屏面板状态文件都在.omx/state/team/里可查 先解争用再谈上限最最常见的瓶颈是共享文件争用。多个 worker 改同一片代码时用 worktree 模式给每个 worker 独立工作区TeamConfig里的workspace_mode: single | worktree就是控制这个的worker 数量不合适再谈扩缩scaling 支持会话中增删 workerscale_up加人、scale_down让空闲 worker 排空后离场由OMX_TEAM_SCALING_ENABLED开关控制想混用不同 CLIOMX_TEAM_WORKER_CLI_MAPcodex,claude可以让 2 个 worker 分别跑 Codex 和 Claude注意N:agent-type选的是角色提示词不是 CLI看性能参照仓库自带的基准测试对比了单线程与团队协作路径的耗时差异方向上后续的重心是自动按任务特征推荐角色、按团队表现自适应调整流程现在这些还靠人判断。 踩坑后如何处理面板没起来命令直接报错→ 根因当前会话不在 tmux 里$TMUX未设置或根本没装 tmux。处理先进 tmux 再执行omx teamCodex App 内也起不了$team回到 shell 终端操作。HUD 面板混进了 worker 栈→ 根因分屏前已有重复的hud --watch面板。处理tmux list-panes -F #{pane_id} #{pane_start_command}查出重复项删掉再启动团队。两个 worker 互相覆盖同一文件→ 根因任务之间没有依赖边界也没启用协调协议。处理换成 worktree 模式隔离工作区或者在任务描述里明确各 worker 负责独立文件集。团队跑了一会儿直接变 failed→ 根因fix 阶段超过 3 次上限编排器按规则终止。处理别硬扛把任务拆小后重新组队一次只让团队修一个问题。收尾OMX 的价值不是多雇几个 AI而是给 AI 助手团队协作一套曲谱阶段固定、角色分权、状态落盘。下一步就从最轻的omx team 2:executor起步跑顺后再按任务重量加人。延伸阅读Getting Started · Agents【免费下载链接】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），仅供参考 AI 助手团队协作怎么落地：OMX 用 5 个阶段把并行开发管住
AI 助手团队协作怎么落地OMX 用 5 个阶段把并行开发管住【免费下载链接】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-codex3 个 AI 同时改同一个仓库最常见的结局是互相覆盖这边刚写完鉴权那边已经改了模块名测试全挂。多人开发分工本身不难难的是没人记下谁在做什么、按什么顺序。oh-my-codexOMX就是加在 Codex CLI 之上的一层 AI 助手团队协作机制它把这类任务拆成阶段、面板和可恢复的磁盘状态。 一分钟定位一场排练不是一起即兴把 OMX 想成乐队排练的指挥系统而不是几个乐手各弹各的指挥是团队编排器决定现在进入哪个乐章谁先谁后分声部乐手是 20 多个专业代理executor 负责主旋律verifier 负责听错音architect 负责看总谱五段流程是节拍器没人能抢拍磁盘状态是曲谱副本中途走音或停场回来能接着弹Codex 仍然是实际演奏的引擎OMX 负责排谱、分声部和控场。核心机制拆解五阶段流水线任务不许跳拍一句话定位一个团队任务只能沿固定路线前进想跳步会直接报错。export type TeamPhase team-plan | team-prd | team-exec | team-verify | team-fix; const TRANSITIONS: RecordTeamPhase, ArrayTeamPhase | TerminalPhase { team-plan: [team-prd], team-exec: [team-verify], team-verify: [team-fix, complete, failed], // ... };为什么这么设计验证不过时任务可以退回 fix 再回 exec但 fix 循环默认最多 3 次max_fix_attempts超了就标记 failed。与其让一群代理互相修到天亮不如让它停下来交还给人。规则写死在 src/team/orchestrator.ts 里每次转场都会带时间戳记入phase_transitions出问题能回放。角色花名册什么人上什么台一句话定位代理不是一个模型套 N 份提示词而是按职责分了工具权限和推理档位。export interface AgentDefinition { name: string; // 如 executor、verifier、architect reasoningEffort: low | medium | high | xhigh; modelClass: frontier | standard | fast; tools: read-only | analysis | execution | data; }为什么这么设计explore 只读、低开销适合快速扫代码库architect 用 xhigh 档位但同样只读保证设计阶段不动手。角色定义集中在 src/agents/definitions.ts提示词本体放在prompts/目录改行为不用动代码。状态落在磁盘断线能续场一句话定位代理之间不靠聊天同步靠共享的状态文件同步。团队配置、任务清单、每个 worker 的状态都写在.omx/state/team/下mailbox.ts管代理间留言dispatch.ts管任务分派locks.ts防止两个 worker 同时写同一份状态配置结构见 src/team/state/types.tsworker_count和max_workers直接控制并行度为什么这么设计tmux 面板随时可能挂掉但文件还在canResumeTeamState能判断一个团队是否值得恢复。状态共享不依赖任何进程活着这是它敢让多个长任务并行执行的底氣。三种配置按任务重量选轻任务单角色并行就够omx team 2:executor fix all endpoint docs and report gaps适用边界任务之间互不依赖比如逐文件修文档、批量改错字。2 个 worker 起步再多只会互相排队等状态。中任务先对齐再并行$deep-interview clarify the authentication change $ralplan approve the auth plan and review tradeoffs $team 3:executor execute the approved plan in parallel适用边界有依赖关系但范围清楚的改动。前两步花的时间买的是后面 3 个 executor 不跑偏需求没对齐就并行等于让乐队没看谱就开演。重任务混声部大编制omx team 2:architect,1:planner,3:executor redesign the payment system适用边界跨模块的大改动架构和排期需要专人把关。涉及安全或合规时把 1 个 executor 换成 quality-reviewer 或 security-reviewer让评审和实现同时走。最小上手路径5 步跑通确认引擎可用codex --version且已登录安装 OMXnpm install -g oh-my-codex在项目根目录做项目级配置omx setup --scope project先进 tmux 再干活用tmux -V确认已安装启动首个团队omx team 2:executor task description随后观察分屏面板状态文件都在.omx/state/team/里可查 先解争用再谈上限最最常见的瓶颈是共享文件争用。多个 worker 改同一片代码时用 worktree 模式给每个 worker 独立工作区TeamConfig里的workspace_mode: single | worktree就是控制这个的worker 数量不合适再谈扩缩scaling 支持会话中增删 workerscale_up加人、scale_down让空闲 worker 排空后离场由OMX_TEAM_SCALING_ENABLED开关控制想混用不同 CLIOMX_TEAM_WORKER_CLI_MAPcodex,claude可以让 2 个 worker 分别跑 Codex 和 Claude注意N:agent-type选的是角色提示词不是 CLI看性能参照仓库自带的基准测试对比了单线程与团队协作路径的耗时差异方向上后续的重心是自动按任务特征推荐角色、按团队表现自适应调整流程现在这些还靠人判断。 踩坑后如何处理面板没起来命令直接报错→ 根因当前会话不在 tmux 里$TMUX未设置或根本没装 tmux。处理先进 tmux 再执行omx teamCodex App 内也起不了$team回到 shell 终端操作。HUD 面板混进了 worker 栈→ 根因分屏前已有重复的hud --watch面板。处理tmux list-panes -F #{pane_id} #{pane_start_command}查出重复项删掉再启动团队。两个 worker 互相覆盖同一文件→ 根因任务之间没有依赖边界也没启用协调协议。处理换成 worktree 模式隔离工作区或者在任务描述里明确各 worker 负责独立文件集。团队跑了一会儿直接变 failed→ 根因fix 阶段超过 3 次上限编排器按规则终止。处理别硬扛把任务拆小后重新组队一次只让团队修一个问题。收尾OMX 的价值不是多雇几个 AI而是给 AI 助手团队协作一套曲谱阶段固定、角色分权、状态落盘。下一步就从最轻的omx team 2:executor起步跑顺后再按任务重量加人。延伸阅读Getting Started · Agents【免费下载链接】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），仅供参考