OMX Oh My Codex 文档中文版 官方 `docs.html` 的中文单页整理

Release v0.14.2 · 中文翻译版

把 Oh My Codex 的英文文档,整理成可直接阅读的中文站点

Oh My Codex 是一层构建在 Codex CLI 之上的协调操作层:增加自治研究、编排包装器、意图优先的深度访谈、团队 worktree、更多命令与技能,以及更顺手的默认工作流。

当前文档对应版本为 v0.14.2。这一版本重点补上了 `ultrawork` 的安全防护、加强团队识别、修复 UI 回归,并让超大上下文场景下的性能和自动安装体验更稳定。

33 个 Agent 提示词 36 个技能 5 个 MCP 服务器 Conductor 团队编排

当前命令面

/team         启动固定并行团队
/autopilot    低摩擦代理协作
/ultrawork    大规模自动化工作流
/ralph        带访谈与兜底的高强度执行
/plan         深度规划模式
/wip          查看进行中的工作
/mt           多智能体编排与状态管理
  • 保留 Codex CLI 的终端工作方式,而不是替换它。
  • 把多代理、技能、工作树、通知与记忆做成默认可用的能力。
  • 适合“读仓库 → 定位问题 → 分派执行 → 汇总结果”的真实工程流程。

Changelog

发布说明

v0.14.2 · 2026-05-05
  • 为 `ultrawork` 增加额外的安全防护。
  • 强化团队识别逻辑。
  • 修复 UI 回归问题。
  • 让 `ultrawork` 在超大上下文下更稳定。
  • 修复 Worktree API 的会话传递。
  • 优化自动安装流程。
v0.14.1 · 2026-05-02
  • 新增工作目录 API。
  • 把 `ultrawork` 连接到 Worktree API。
  • 用共享团队文件替换环境变量方案。
  • 在 CLI 上更新团队面板。
  • 支持“子代理再开子代理”的 subsub-agent 工作流。
v0.14.0 · 2026-05-01
  • 统一团队与 worktree 的创建机制。
  • 改进 թիմ切换体验。
  • 新增共享 Worktree API。
  • 改进团队列表与会话清理。
  • 让工作目录会话可被恢复。
v0.13.1 · 2026-04-26
  • 加入显示组件用于突出真实世界影响。
  • 改进 UI 与层次结构。
  • 修复语义化版本计算中的边界问题。
v0.12.0 · 2026-04-26
  • 增强团队创建与恢复逻辑。
  • 提升团队索引能力。
  • 改善子代理结果注入。
  • 降低团队生成的回显噪音。
v0.11.13 · 2026-04-23
  • 记录完整的团队元数据。
  • 增加对 `ultrawork` 的模型预检。
  • 为 `ultrawork` 提供更好的注入与上下文传递。
v0.11.12 · 2026-04-23
  • 新增工作树级索引。
  • 为大型 `ultrawork` 团队自动分配工作目录。
v0.10.0 · 2026-04-23
  • 默认使用 worktree 团队。
  • 用永久目录替换临时目录模式。
  • 记录团队元数据。
  • 让 `ultrawork` 支持工作树隔离。
  • 改进启动性能与缓存。
v0.9.0 · 2026-04-22
  • 新增 `/init` 页面与 Yarn 安装支持。
  • 改进释放清理逻辑。
  • 加入深度聊天能力。
  • 更新提示词目录并扩充技能。
v0.8.1 · 2026-04-22
  • 使用孤儿分支进行历史隔离。
  • 改进临时工作区与清理。
  • 为团队恢复保留用户上下文。
v0.8.0 · 2026-04-22
  • 让 `/team` 默认启用 worktree 工作流。
  • 加入 `/wip` 用于检查进行中的任务。
  • 允许 `/ultrawork` 使用共享日志文件。
  • 记录额外的团队元数据。
v0.7.6 · 2026-04-21
  • 新增 `omx doctor`、消息日志与队列。
  • 扩展 Resume、Explore 和 MCP 集成。
  • 为多代理团队提供更强的可观测性。
v0.7.5 · 2026-04-20
  • 补充更多 Agent、命令与上下文优化。
  • 增强拉取请求与变更审查工作流。
v0.7.3 · 2026-04-18
  • 加入并行变更队列。
  • 整理 Explore、Advisor、Sparkshell 等交互模式。
v0.7.2 · 2026-04-16
  • 扩展 `autopilot`、`ralph` 与 `ultrawork` 协作逻辑。
  • 提升多模型路由的一致性。
v0.7.0 · 2026-04-16
  • 引入“四车道”团队模型。
  • 让提示词目录与技能目录可组合。
  • 改进多代理调度。
v0.6.x
  • 开始加入更深的面试式意图澄清。
  • 把 Orchestra/Team 思路推到默认工作流里。
v0.5.x
  • 新增 `planned` 模式与团队命令。
  • 加强上下文压缩与检索。
v0.5.0
  • 推出 `ralph` 作为高强度协作入口。
  • 增加更严格的任务界定与兜底策略。
v0.4.x
  • 早期版本开始把 Codex CLI 包装成更完整的工程工具箱。
  • 逐步形成 skills、commands、MCP 与 prompt packs 的组合方式。

Feature Guides

特性指南

动态缩放团队

为 `autopilot` 引入随上下文增长而扩展的“智能团队规模”。

  • 轻量任务:以单代理起步,减少切换成本。
  • 中等任务:自动进入小队协作,把研究、实现和验证拆开。
  • 重型任务:升级到多 lane 编排,支持更高吞吐与更强隔离。

RALPLAN-DR 双路径路由

让 `ralph` 在执行前先判断是“需要计划”,还是“可以直接编码”。

  • 简单、明确的任务:直接进入产出路径。
  • 模糊、依赖多、风险高的任务:转入规划与问题澄清。
  • 目标是减少“先写后推翻”的返工。

OpenClaw 集成

文档中把 OpenClaw 作为通知与自动化桥接层,负责把 CLI 事件转到桌面或 webhook。

  • 接收任务完成、失败、人工介入等事件。
  • 允许对通知内容使用模板。
  • 支持基于 `.toml` 与 `.json` 的配置方式。

原文还提供了一个单独的 OpenClaw Guide 链接,用于展开通知配置细节。

Gemini 驱动团队

团队模式支持将不同 lane 路由到不同模型,Gemini 主要用于更便宜的大规模探索与思路发散。

  • 用便宜模型做扫描、归纳、索引与资料收集。
  • 让更强模型保留给最终判断和关键落地步骤。
  • 可与 OpenAI、Claude、Qwen 等混编。

Worktree 编排

文档将工作树视为多代理协作的默认隔离层,每个 worker 在自己的目录中执行,降低互相覆盖与上下文污染。

工作方式

  • 为每个 worker 创建独立 worktree。
  • 共享团队元数据,而不是依赖临时环境变量。
  • 会话可恢复,工作目录可复用。

增量合并策略

  • 优先按文件或模块切分写入责任。
  • 先集成低风险改动,再处理交叉区域。
  • 必要时由 conductor 重新切分任务边界。

Worker 提交协议

  • 子代理只对自己负责的范围写入。
  • 不回退别人已经存在的改动。
  • 返回时明确列出改动文件与验证结果。

跨 worktree 状态解析

  • 通过共享团队文件记录上下文与输出。
  • 恢复时优先读取团队元数据与日志。
  • 避免把状态只留在终端会话里。

Getting Started

开始使用

安装

npm install -g oh-my-codex

安装后可直接运行 `omx`。原文强调:它不是替代 Codex CLI,而是把 Codex CLI 包装成更完整的工程执行器。

快速启动

最短路径是直接输入 `omx`,然后用命令切换执行风格。

  • `/autopilot`:低摩擦协作,适合常规改动。
  • `/ralph`:先澄清,再高强度执行。
  • `/ultrawork`:需要大规模自动化与编排时使用。
  • `/team`:显式启动并行团队。
  • `/plan`:先做深度规划,不急着改代码。

为什么是 OMX

  • 保留 CLI 工作节奏,而不是强迫进入聊天机器人 UI。
  • 把多代理团队、MCP、技能、通知和 worktree 做成默认能力。
  • 把“先理解仓库再下手”变成提示词和流程层的硬约束。
  • 允许不同模型在不同 lane 上各司其职。

常见意图示例

/autopilot 修复登录页的表单提交错误
/ralph 帮我先厘清这个后端 500 的根因,再决定改哪一层
/team 用并行代理梳理支付模块的风险点
/plan 先写一个迁移方案,不要立刻改代码
/ultrawork 对这个 monorepo 做一次多模块升级

Architecture

架构与调度

Conductor 哲学

文档的核心思想是:把最强模型留给判断,把更便宜的模型留给搜集、整理与并行推进。 Conductor 自己更像协调层,负责拆分任务、分配 lane、追踪状态,再把结果汇总给主执行者。

Agent 分层目录

  • Tier 1:主执行者与 conductor。
  • Tier 2:默认 worker、reviewer、explorer 等角色。
  • Tier 3:更便宜的 lane 专用模型,用于大批量探索。
  • Lane 划分:研究、实现、验证、整合四条主线。

Delegation 规则

  • 不要把当前关键路径上的阻塞工作直接丢给子代理。
  • 优先委派边界清晰、结果可直接集成的并行子任务。
  • 为每个 worker 指定明确的文件或职责归属。
  • 返回时必须说明改了什么、验证了什么、风险还剩什么。

团队架构

  1. 主代理读取用户目标,判断要不要进入计划、直接执行或大规模编排。
  2. Conductor 根据任务复杂度决定团队规模和 lane 划分。
  3. 各 worker 在独立上下文或 worktree 中推进各自任务。
  4. 验证与审查结果回流给 conductor,再汇总为最终输出。

模型路由

场景 推荐模型职责 目标
最终判断、复杂集成 更强的旗舰模型 保证正确性和整合质量
仓库扫描、广域检索 便宜模型或 Gemini lane 压低成本、提高并行度
快速验证与二次确认 中档模型 补足回归风险检查
规划与意图访谈 推理能力更强的模型 减少方向性失误

Modes

执行模式

Autopilot

默认的低摩擦模式。任务不复杂时单代理即可,复杂度上升时再自动扩容团队。

Ralph

强调先问清楚再动手。适合问题边界不清、依赖多、改错代价高的场景。

Ultrawork

面向大规模自动化和重编排任务。文档多次强调它需要额外安全防护与更强的状态管理。

团队组合

  • 轻量团队:主代理 + 少量辅助探索。
  • 标准团队:研究、实现、验证三个 lane。
  • 重型团队:Conductor + 多 worker + 审查 / 汇总角色 + worktree 隔离。
  • 默认趋势:从 v0.8.0 到 v0.10.0,团队模式逐步默认化,worktree 成为标准隔离手段。

Tools & Config

工具与配置

MCP 工具

  • 浏览器、文档检索、索引与通知这类能力都可以通过 MCP 接入。
  • 文档页给出的计数是 5 个 MCP 服务器。
  • 原则是:把外部能力做成可复用组件,而不是写死在提示词里。

Skills 与 Commands

  • Skills 负责封装特定工作流或领域操作。
  • Commands 负责快速切换模式,如 `/team`、`/plan`、`/wip`。
  • Prompt packs 负责给不同 agent 角色提供稳定行为边界。

状态与记忆

近期版本持续把团队状态从“只在终端里存在”迁移到共享文件与元数据系统:包括团队索引、消息日志、队列、恢复上下文和工作目录映射。 这样做的目的是让会话可以恢复,让多代理协作可以回放,也让 conductor 能在不同 worker 之间传递结构化状态。

配置示例

# 示例:团队 / 工作树目录
worktrees_root = "~/.omx/worktrees"
teams_root = "~/.omx/teams"
logs_root = "~/.omx/logs"

# 示例:通知
notifications.enabled = true
notifications.provider = "openclaw"

原文没有给出唯一固定配置文件,但整体思路是:把 worktree、团队元数据、通知和 resume 数据都持久化。

CLI Reference

CLI 参考

启动与基础命令

omx
omx /autopilot
omx /ralph
omx /team
omx /ultrawork
omx /plan

核心命令

命令 中文说明
`/autopilot` 默认执行模式,必要时自动扩容团队。
`/ralph` 面试式澄清 + 执行,适合高风险任务。
`/ultrawork` 大规模自动化编排。
`/team` 显式启动并行团队。
`/plan` 先做深度规划,不急于落地。
`/wip` 查看进行中的任务或团队状态。
`/mt` 多智能体编排与状态管理入口。

Launch Flags

文档原意是:除了命令切换外,还可以通过启动参数进入不同模式、恢复会话或附带额外上下文。

  • 为当前命令注入上下文文件或初始提示。
  • 显式恢复之前的会话或团队状态。
  • 为特定运行指定不同模型、工作目录或执行目标。

Explore

只做侦察,不直接改代码。适合问“这个系统怎么工作”“哪些文件最相关”。

Sparkshell

更偏实验性和脚本型的快速互动入口,用于临时探索、命令组合或快速产出草稿。

Resume

恢复之前的任务、团队或工作目录。新版文档多次提到持久化元数据就是为此服务。

Advisor

当你不想马上执行,而是要先拿到方向建议、风险评估、方案比较时使用。

Advisor / Explore 示例

omx /plan “比较把搜索服务迁到新索引方案的三种路线”
omx /team “并行梳理 monorepo 中支付、鉴权和缓存的耦合点”
omx /autopilot “先读仓库,再告诉我这个 bug 最可能在哪一层”

Hooks、扩展与构建辅助

  • 文档强调可以通过命令、skills、prompt packs 和 MCP 组合扩展行为。
  • 构建辅助更偏向“把常用工程动作标准化”,而不是引入庞大的框架。
  • 如果要加自定义工具,优先做成可声明、可复用、可被团队模式消费的入口。

Notifications

通知系统

概览

通知系统负责把 CLI 中的重要生命周期事件推到桌面、Webhook 或 OpenClaw 集成端,避免长任务只能盯着终端看。

快速配置

[notifications]
enabled = true
provider = "openclaw"
verbosity = "normal"

支持的平台

通道 用途
桌面通知 任务完成、失败、等待用户输入时提醒。
Webhook 把事件送进聊天机器人、自动化平台或团队服务。
OpenClaw 作为集中式通知网关,支持模板和更丰富的事件载荷。

OpenClaw 配置示例

[notifications.openclaw]
endpoint = "http://127.0.0.1:4590/events"
channel = "desktop"
template = "task-complete"

事件类型

  • 任务开始
  • 任务完成
  • 任务失败
  • 等待用户输入
  • 团队 / worker 状态变化

详细级别

  • `quiet`:只报关键事件。
  • `normal`:适合作为默认值。
  • `verbose`:适合调试团队与编排行为。

环境变量

  • `OMX_NOTIFICATIONS_ENABLED`
  • `OMX_NOTIFICATION_PROVIDER`
  • `OMX_NOTIFICATION_ENDPOINT`
  • `OMX_NOTIFICATION_VERBOSITY`

模板与回复注入

  • 模板可控制标题、正文和附带上下文。
  • 回复注入允许把外部通道回执重新送回 CLI 流程。
  • 适合“任务完成后需要人工批复”的闭环。

示例配置(TOML / JSON)

[notifications]
enabled = true
provider = "openclaw"
verbosity = "verbose"

[notifications.openclaw]
endpoint = "http://127.0.0.1:4590/events"
channel = "desktop"
template = "team-update"
{
  "notifications": {
    "enabled": true,
    "provider": "openclaw",
    "verbosity": "verbose",
    "openclaw": {
      "endpoint": "http://127.0.0.1:4590/events",
      "channel": "desktop",
      "template": "team-update"
    }
  }
}

高级团队通知配置

[notifications]
enabled = true
provider = "openclaw"
verbosity = "verbose"

[notifications.filters]
events = ["task_completed", "task_failed", "awaiting_input", "team_status"]

[notifications.templates]
task_completed = "{{task}} 完成:{{summary}}"
awaiting_input = "需要人工确认:{{question}}"

Recommended Workflows

推荐工作流

1. 单点修复

入口:`/autopilot`

  1. 先扫目录与已有改动。
  2. 只改与问题直接相关的文件。
  3. 跑校验并说明仍需人工验证的边界。

2. 高风险问题诊断

入口:`/ralph`

  1. 先面试式澄清业务目标与容错范围。
  2. 决定先规划还是直接读代码。
  3. 把“已验证 / 未验证”明确分开。

3. 并行仓库勘察

入口:`/team`

  1. 用不同 worker 扫不同模块。
  2. 返回时要求每个 worker 只交自己范围的结论。
  3. 由 conductor 汇总相互印证或冲突的发现。

4. 大规模升级与迁移

入口:`/ultrawork`

  1. 先划分模块与 worktree。
  2. 把共享状态写入团队元数据。
  3. 按增量策略合并,避免一次性收敛所有冲突。

Advanced Orchestration

高级编排

混合 CLI 团队

# 示例思路:
# GPT-级模型负责最终整合
# Gemini lane 负责大规模扫描
# 便宜模型负责验证与二次检查
omx /team "搭一个混合模型团队来审查这次重构"

Team CLI API 思路

# 伪命令示意
omx team create
omx team status
omx team resume
omx team cleanup

原文传达的重点不是固定命令字,而是“团队”应该像一等对象那样被创建、恢复、查询和清理。

Worktree 隔离原则

1. 每个 worker 有自己的目录与任务边界
2. 不回退其他 worker 或用户已有改动
3. 通过共享元数据同步状态,不依赖手工口头传递
4. 合并时先解决边界,再解决冲突

架构洞察

这份文档真正想表达的不是“又多了几个命令”,而是把 Codex CLI 升级为一个可恢复、可并行、可观察、可多模型混编的工程执行环境。 如果你要在自己的团队里落地,优先复用它的三件事:明确的模式切换、可恢复的团队状态、以及 worktree 隔离。