一个终端里并行跑三个AI智能体oh-my-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当你一个人盯着AI助手一行行改代码、改到第三个小时才发现它还在跑第一个任务时问题的根源不是模型不够快而是只有一个人在干活。oh-my-codexOMX作为 Codex CLI 的工作流增强层提供基于 tmux 的智能体团队并行执行一条命令拉起多个 AI 工作者各占一个分屏通过共享状态文件互相认领任务、汇报进度。本文带你从第一条命令开始走完组队—监控—收队的完整流程。快速上手3分钟跑通你的第一个AI团队前置条件就两条tmux已安装且你的主会话运行在 tmux 里$TMUX有值。满足后最小可行配置就三行omx team 3:executor 重构 auth 模块并跑通测试套件 omx team status auth-refactor omx team shutdown auth-refactor执行后发生了什么OMX 把当前 tmux 窗口切成三个分屏每个分屏启动一个独立的executor角色工作者把任务写入各自的inbox.md然后通过.omx/state/team/team/下的状态文件协调分工。你会看到工作者陆续回传 ACK、认领任务、提交代码。status命令读取团队快照shutdown在任务全部到达终态后优雅清理状态目录。三个数字3:executor的含义是3 个工作者 角色提示。角色的完整目录executor、planner、verifier、architect 等 20 多个定义在 src/agents/definitions.ts每个角色绑定不同的推理强度档位和工具权限这是 OMX 智能体分工的底层依据。实战场景三种最常见的组队方式下面三个场景覆盖了日常使用 90% 的需求。判断标准只有一条任务之间是否有依赖、是否碰同一批文件。需求还没想清楚先访谈后组队适用条件需求描述里还有大概差不多优化一下这类词。直接上团队只会把模糊并行放大。$deep-interview clarify the authentication change $ralplan approve the auth plan and review tradeoffs $team 3:executor execute the approved plan in paralleldeep-interview用苏格拉底式追问把模糊度压到阈值以下ralplan让 Planner、Architect、Critic 三方对方案投票并记录否决理由最后才放行给执行团队。预期效果工作者拿到的是一份被挑战过三遍的计划而不是你的一句口头需求。两个模块各写各的交付与验证分道适用条件改动横跨两个以上互不干扰的模块比如支付和通知。用2:executor,1:verifier的混搭omx team 2:executor,1:verifier 并行实现支付和通知模块两个 executor 领各自的模块verifier 全程不写代码只盯测试覆盖和回归证据。当任务图出现共享文件、跨边界交接时OMX 会自动启用更严的协调协议握手确认、边界互查规则写在工作者协议里参考 skills/team/SKILL.md。预期效果不会出现两个人改同一个文件互相覆盖的经典事故。上线前的最后关隘把安全评审变成一条固定车道适用条件涉及认证、密钥、权限的改动。执行团队里固定塞一个评审角色omx team 2:executor,1:security-reviewer 实现安全认证并同步评审安全评审员和执行者共用同一套任务状态代码一提交就能看到 diff 级别的质疑。预期效果安全审查从上线前想起来才做变成和编码同时发生。上图就是团队并行执行的一次产物对比同一任务由不同执行配置完成界面完成度和结构清晰可见地分出差距——并行不自动等于更快角色搭配才是变量。从配置到监控团队跑起来之后的一条时间线配置好团队后剩下的事是等对地方。整条时间线是这样的启动终端打印Team started: name分屏就位工作者就绪轮询通过。运行中状态全部落在.omx/state/team/team/目录——任务在tasks/消息在mailbox/心跳在workers/。你可以随时cat这些文件但更推荐走omx team status。轮询领导会话保持最低监控循环sleep 30 omx team status team-name若希望事件驱动而非定时轮询用omx team await team --timeout-ms 30000 --json。工作者之间的消息走邮箱文件实现见 src/team/state/mailbox.tsACK 写入mailbox/leader-fixed.json不是靠人肉盯分屏。 4.收尾完成门槛是pending0、in_progress0、failed0。三个数字全绿才能shutdown它会请求优雅停机并删除状态目录。 5.通知兜底生命周期事件全部空闲、领导者状态过期会推 leader nudge由 src/notifications/ 下的通知系统分发避免你漏掉其实早就干完了的时刻。效率进阶4个立竿见影的技巧用工作树隔离实验性改动团队直接在主分支上跑时失败的实验会污染你的工作区。启动时就指定工作树omx --worktreefeat/task让工作者落在独立的 git worktree 分支里合不合由你决定。混搭两种CLI按任务特长分工omx team的工作者不一定是同一个 CLI。用环境变量OMX_TEAM_WORKER_CLI_MAPcodex,claude给不同工号指定不同后端一个队里可以同时有 Codex 和 Claude 两种工作者。用 await 替代人肉轮询定时sleep 30只适合短任务。长任务换成omx team await team --timeout-ms 30000 --json它按事件返回退出码和 JSON方便接进你自己的脚本。把完成门槛写进习惯status里只要还有一个in_progress就执行shutdownworker 后续写入会报 ENOENT且状态被删得干干净净。口诀数字不全绿手不碰 shutdown。避坑速查表你看到的问题一句话解决方案去哪里看团队跑一半worker 日志刷omx team api ... ENOENT有人在任务进行中执行了 shutdown 或手动删了状态目录先保任务再谈清理skills/team/SKILL.mdshutdown 报成功但终端里还挂着旧的分屏上次失败运行留下的残留 pane手动tmux kill-pane清掉再重跑src/team/tmux-session.ts给 worker 发消息没反应想狂按回车先查 mailbox 和status盲目回车会在 pane 空闲时制造重复提交src/team/state/mailbox.ts收尾一支会分工的团队比一个更快的单体更可靠。打开 tmux敲下你的第一个omx team 3:executor。官方文档Getting Started · 代理目录【免费下载链接】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），仅供参考
