在 Codex 上安装并试用 dev-orchestra

前言

上一篇，我在只有 Claude Code 的环境中用了 dev-orchestra。 这次把它装到 Codex 上试试。

先说结论：只有 Codex 也能运行。不过我最推荐的做法是同时安装 Claude Code 和 Codex。这样会自动变成由不同公司的 AI 来审查代码的配置。

关于 dev-orchestra 是做什么的，我写在了介绍文章里。

dev-orchestra 已在 GitHub 上公开（MIT 许可证）。如果觉得有用，希望你能给它点个 Star。

→ github.com/istb16/dev-orchestra

所需环境

项目	备注
Codex CLI	需要先完成登录
Python 3.11 或更高版本	只用标准库就能运行
git	用来获取要审查的差异

不需要 API 密钥。直接使用 Codex 的登录状态。

步骤

1. 安装

在终端里输入两行命令。

codex plugin marketplace add istb16/dev-orchestra
codex plugin add dev-orchestra@dev-orchestra

可以用 codex plugin list 确认是否已安装。

2. 首次使用时选择预设

刚开始的流程和 Claude Code 时一样。第一次提出使用 dev-orchestra 的请求时，它会问你要用哪个预设。 拿不准就选 standard 就行。各个预设的内容，我会在本系列的后半部分详细介绍。

3. 查看只有 Codex 时的配置

在没有安装 Claude Code 的机器上选择 standard，得到的配置如下（摘自 dev-orchestra 1.0.0 的 config show）。

Preset: standard (implicit; fitted to codex)
  note: claude not found on PATH: reviewer seat 2 (general) was not added; it would repeat codex-general
  note: claude not found on PATH: reviewer seat 4 (test) was not added; codex has no cheap model named offline

  Architect
    codex / recommended-coding / latest
  Implementer
    codex / recommended-coding / latest
  Reviews
    1. codex / recommended-coding / latest / general / codex-general
    2. codex / recommended-coding / latest / security / codex-security

设计、实现和审查，全部都分配给了 Codex。

和只有 Claude Code 时相比有一点不同：审查者是 2 个，而不是 4 个。

• 第 2 个 general 席位会和第 1 个完全相同，都是 Codex，所以不添加
• test 席位是留给“便宜的模型”的，而 Codex 无法按名称指定便宜的模型，所以不添加

让同一个 AI 以同样的角色出现两次没有意义，所以它的做法是一开始就不创建无用的席位。

4. 再装上 Claude Code，就是推荐配置

接下来是我推荐的用法。如果同一台机器上也装了 Claude Code，配置就会变成这样。

Preset: standard (implicit; fitted to claude, codex)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. codex / recommended-coding / latest / general / codex-general
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

第 2 个审查者变成了 Codex。

• 由 Claude 实现，审查则有 Claude 和 Codex 两方参与
• 不同公司的 AI，先入为主的想法也不同。针对同一份差异意见出现分歧的地方，往往就是真正的 bug 所在

不用修改任何设置，它会根据已安装的 CLI 自动变成这种形态。

如果想让 Codex 负责设计或实现，也可以按角色更换 AI。怎么调整，我会在本系列的后半部分介绍。

5. 确认是否准备就绪

对智能体说“运行 dev-orchestra 的 doctor”。Codex 部分的输出如下（节选）。

Codex CLI (codex)
  Installed: yes
  Model selection: supported
  Read-only runs: enforced by -s read-only (CLI sandbox); filesystem writes are blocked by the sandbox (measured); MCP servers were not examined, so external side effects are not covered

设计和审查角色在 Codex 的只读沙箱中运行。文件写入会被沙箱拦下。 不过，它也如实写明了没有检查 MCP 服务器（下面的表格里也会提到）。

最后如果显示 No problems found.，就准备好了。

6. 用一句话提出请求

接下来和 Claude Code 时一样，像平常那样对它说话就行。

用已配置的工作流实现这个 issue

从询问是否批准计划，到最终报告的流程，和上一篇文章里写的一样。

因为要运行多个审查者，消耗的 token 会比只用一个 AI 更多。建议先从小的请求开始尝试。

只有 Codex 才有的功能与限制

这些是在 Codex 上使用时值得了解的要点（截至 dev-orchestra 1.0.0，详情见 providers.md）。

	内容
优点：只读由沙箱强制执行	设计和审查以 -s read-only 运行，从 shell 发起的写入也会被拦下
优点：直接使用“推荐”的模型	默认是 recommended-coding。其他模型只能指定 dev-orchestra model list 中列出的那些
优点：可以从之前的设计接着继续	可以沿用之前的设计对话，并保持只读（在已验证的 Codex 版本中）
注意：没有检查 MCP 服务器和 hook	对于通过 Slack 等 MCP 工具产生的外部影响，dev-orchestra 不做保证
注意：可以读取工作目录之外	不像 Claude 那样限制读取范围。无论在仓库内还是仓库外，都能读取 .env 等机密文件，读到的内容会被发送给 OpenAI
注意：只有 Codex 时审查者是 2 个（standard 的情况）	因为不创建与 Codex 重复的席位和便宜模型的席位。quality 是 4 个，fast 通常是 1 个（高风险变更时再加 1 个）
注意：使用自定义 model_provider 时无法恢复设计	如果在 config.toml 中使用了自定义提供方，恢复会失败，转而重新执行
注意：实现角色的沙箱设置来自全局配置	如果把 sandbox / approve 写在项目的配置文件里，实现的执行会被拒绝

为了安心，把机密文件放在审查者够不到的地方。对于绝对不想外传的代码，也可以用本地 LLM 来审查（介绍文章里提到过）。

更新插件时，只运行 codex plugin marketplace upgrade 并不会装上新版本。接着还要运行 codex plugin add dev-orchestra@dev-orchestra。

总结

• 安装到 Codex 也只要两行。不需要 API 密钥
• 只有 Codex 也能运行。设计、实现和审查全部由 Codex 承担，审查者是 2 个（standard 的情况）
• 再装上 Claude Code 就是推荐配置。审查中同时有 Claude 和 Codex，由不同公司的 AI 独立审查
• 设计和审查在 Codex 的只读沙箱中运行。不过没有检查 MCP 和 hook
• 更新时，在 marketplace upgrade 之后要再运行一次 plugin add

更详细的用法见 README。 下一次，我会在 Antigravity 上试用。

新版本发布时的更新方法，写在了更新 dev-orchestra里。

本系列的文章可以在“dev-orchestra”文章列表里一并阅读。

GitHub: istb16/dev-orchestra（欢迎点个 Star，这会给我很大鼓励）