尧图精选

oh-my-codex 团队协作实战:3 步把 Codex 跑成一支开发小队

🕒 发布时间:2026/9/2 9:22:32 📁 来源:尧图网络
oh-my-codex 团队协作实战3 步把 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-codexoh-my-codexOMX是 OpenAI Codex CLI 的工作流增强层Codex 继续当执行引擎OMX 在它外面补上一层角色分工、并行编排和状态管理。它要解决的是三个具体的坑——需求聊着聊着就跑偏、单会话干活太慢、干到一半断了没法接着来。如果你已经在用 Codex CLI这篇文章把从装好到跑通团队并行执行的完整路径讲一遍。环境怎么配从安装到跑通的 5 分钟路径先说清楚边界OMX 主要面向 macOS 和 Linux 上的 Codex CLIWindows 原生环境不是默认体验。前置条件就三条——Node.js 20、一个已登录的codex命令、想跑团队模式的话装个tmux。安装和首次配置npm install -g oh-my-codex omx setup --scope project --merge-agents omx doctorsetup 这步别急着直接跑先想清楚作用域在你要让 Codex 编辑的那个 git 仓库里用--scope project让仓库自己拥有持久的AGENTS.md指导只是想做用户级 Codex 配置就用--scope user。--merge-agents表示保留你已有的AGENTS.md内容只在!-- OMX:AGENTS:START --标记之间刷新 OMX 生成的段落。装完别以为omx doctor全绿就万事大吉它只验证安装形状和钩子接线。真正的冒烟测试是让 Codex 实打实发一次请求codex login status omx exec --skip-git-repo-check -C . Reply with exactly OMX-EXEC-OK回到 git 仓库里用推荐姿势启动omx --worktreefeat/task --madmax --xhigh。--xhigh是推理强度的快捷开关--madmax等价于 Codex 的--dangerously-bypass-approvals-and-sandbox会拆掉审批和沙箱护栏只在你完全信任的仓库里用。--worktree把启动挪进一个独立的 git 工作树——这也是后文并行的基础。需求老跑偏deep-interview、ralplan、ultragoal 怎么串场景一需求本来就模糊你让模型直接开干产出和预期差十万八千里。OMX 把澄清、规划、执行拆成一条固定的主线三个技能各管一段$deep-interview ...只负责把意图、边界和非目标聊清楚不碰代码$ralplan ...把澄清结果变成一份被审批过的计划和架构取舍。注意它到规划产物就停手自己不写代码$ultragoal ...把批准的方案转成串行的持久化 Codex 目标检查点落在.omx/ultragoal这是默认的执行主干如果任务需要跨轮次对账的持久目标结构再补一句/goal如果你更想要一个单一负责人死磕到底的完成循环用$ralph替代 ultragoal 即可。这条链路的价值不在每个命令有多强而在顺序被固化了——先澄清、再审批、后执行想跳步得手动绕过。一个人干太慢$team 并行执行的正确姿势场景二任务能拆成互不干扰的几块单会话串行等不起。这时用omx team在 shell 里启动例如omx team 3:executor fix the failing tests with verification——冒号前面是数量后面是角色3 个执行者同时开工。背后的编排器是 团队编排器它按 team-plan、team-prd、team-exec、team-verify、team-fix 五阶段推进每个阶段的产物计划、需求、执行证据、验证结果、修复都有对应状态。角色目录在 代理定义 里超过 20 种专业角色executor、architect、planner、quality-reviewer、security-reviewer 都是现成的重设计一个子系统omx team 2:architect,1:planner,3:executor架构师画边界、规划师排依赖、执行者并行实施安全敏感的改动执行者加质量评审、安全评审并行盯两个容易忽略的细节。第一团队成员默认各自使用独立 worktree互不污染不需要你手动隔离。第二当 team 跑在一个 Ultragoal 故事里时状态仍然归主流程所有执行者只向上汇报检查点就绪的证据不会直接去改.omx/ultragoal避免多写者互相踩。另外别为了用而用很小的原子任务上团队运行会自己把隐式并行压到 1 个执行者并打印过度编排警告——协作本身有成本这点设计是对的。进度去哪了状态持久化与断点恢复场景三跑了半小时终端断了上下文被压缩了想接着干却只能从头再来。团队状态落在 团队状态类型 定义的结构里覆盖任务分配、工作进度、问题跟踪这些维度。日常操作就三个命令omx team status team-name看当前谁在干什么omx team resume team-name断点恢复omx team shutdown team-name收尾死团队加--force --confirm-issues启动阶段会往.omx/state/team/team-name/preflight-context.json写入原始任务、worker 拆分、Ultragoal 上下文和验证清单所以大团队跑完一轮上下文压缩后还能带着完整信息恢复。项目的.omx/目录同时存计划、日志、内存和模式跟踪进度不再只活在某次会话里。想看实时状态而不打扰主流程还有omx hud --watch这个监控面。环境别打架worktree 隔离与并发安全跑过两个以上长会话的人都知道同一份 checkout 里并发干活迟早出事。OMX 的隔离策略分三层代码隔离--worktreefeature/auth把每个任务挪进命名工作树。并发跑--madmax时每个会话必须各领一个独立命名的 worktree别在同一个目录里开多份状态隔离一次标准启动独占一个OMX_ROOT下可写的会话指针第二个普通启动会同 root 失败而不是偷偷共享。想开第二路会话给它显式 root比如OMX_ROOT$HOME/.omx/instances/second-conversation omx免管理启动--direct或OMX_LAUNCH_POLICYdirect可以跳过 tmux/HUD 托管一次性的快速启动够用隔离之外还有一层上下文卫生一个任务默认只加载 2-5 个相关 skills。README 里专门点了反模式——任务还没说清楚就以防万一加载 20 个 skills这会把会话上下文撑爆让模型的注意力分散在无关流程上。skills 目录里有三十来个现成的skills 参考按需取用即可。卡住了怎么办假绿诊断与常见坑omx doctor全绿但真跑不动这是典型的假绿排查路径见 故障排查。两层诊断要分清omx doctor管安装和接线omx exec的真实模型调用才暴露认证、profile、base-URL 的问题。几个高频坑依赖本地 OpenAI 兼容代理时确认当前生效的~/.codex/config.toml里openai_base_url是对的否则代理签发的 key 会被发去默认端点报 401自定义 HOME、容器或 CI 环境里别假设你个人用户的~/.codex就是 Codex 实际读的那份团队状态残留resume_blocker、tmux 会话没了确认团队已死后用omx team shutdown name --force --confirm-issues清干净再omx doctor --team复检Intel Mac 启动时syspolicyd/trustdCPU 飙高对 omx 二进制执行xattr -dr com.apple.quarantine或把终端加进开发者工具白名单Windows 场景WSL2 tmux 是比原生更稳的路径项目本身还在往更厚的运行时走crates/ 目录下的 Rust 运行体sparkshell、mux、runtime已经在做 shell 原生的检查和验证算是把工作流层往运行时层延伸的动向关注 changelog 即可不影响现在的使用。OMX 适合已经在用 Codex CLI、想让会话有结构、让任务能并行、让进度可恢复的开发者——下一步就从omx doctor加一次omx exec冒烟测试开始。【免费下载链接】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),仅供参考
上一篇/下一篇内容由系统自动关联 返回资讯列表 →