一个 rig 包住两个 harness：OpenRig 把 Claude Code 和 Codex 编进同一支队伍

你手上有 Claude Code，也有 Codex。两个都能干代码活，但你每次切换窗口就像在两个公司之间跑合同——一个写完，另一个审，你自己在中间当项目经理。OpenRig 想把这种"两个工具来回切"的状态彻底干掉。

一句话定义：rig 是 harness 的 harness

OpenRig 的核心抽象藏在 README 的第一句里：

A harness wraps a model. A rig wraps your harnesses.

这句话值得拆开看。harness（驾驭具）是当下 AI 编码圈已经成型的概念——Claude Code 是一个 harness，Codex 是一个 harness，它们各自把一个模型包起来，给它文件访问、工具调用、终端执行的能力。但 harness 之间是平级的、互不认识的。你在 Claude Code 里问"刚才 Codex 改的那个文件对不对"，它不知道。

rig 在 harness 之上加了一层：用 YAML 定义一支队伍，每个座位（seat）绑定一个 harness，一个 lead agent 负责协调，specialist agents 分头干活。你不再跟单个 harness 对话，你跟 lead 说"我要这个仓库做某个改动"，lead 自己决定派谁、怎么审、什么时候找你确认。

这和 AutoGen、MetaGPT、CrewAI 这些多智能体框架有什么不同？关键区别：OpenRig 不模拟智能体，它调度真实的、已经存在的编码 agent。每个 seat 里跑的是真正的 Claude Code 或真正的 Codex，不是"一个 LLM 调用包装成 agent"。这意味着每个 seat 都有完整的文件系统访问、终端执行、工具链——它们是"重型 worker"，不是"轻量 API 调用"。

tmux 作为运行时：为什么不是又一个 Docker

OpenRig 的运行时选型很反直觉：它用 tmux。

不是 Docker，不是 Kubernetes，不是某种新的容器技术。就是 tmux——那个你在服务器上用来防 SSH 断线的老伙计。每个 seat 是一个 tmux session，lead agent 通过 rig send 发消息，通过 rig queue list 看任务状态。

这个选择背后的逻辑值得想。Docker 假设工作负载是无状态的、可重建的——容器挂了重启就行。但编码 agent 是有状态的：它记得自己刚改了哪个文件、刚才跑测试为什么失败、它和 reviewer 之间达成了什么共识。这种状态不能随便重建。

tmux 的优势恰恰是：它是一个持久化的终端会话管理器。session 挂了可以 attach 回去，终端里的一切都还在。这和编码 agent 的状态模型完美匹配——agent 的"记忆"就是它所在的终端环境，tmux 保证这个环境不消失。

rig tui --shared 打开共享 dashboard，多个 seat 的状态一览无余。Ctrl-b d 退出但不停 dashboard。这种"view 和 runtime 分离"的设计，和 K8s 的 pod vs service 模式异曲同工，但轻量得多。

队伍拓扑：owner + checker 的最小单元

OpenRig 的 starter 配置是两个 Codex seat：一个 owner，一个 checker。owner 负责实现，checker 负责审查。这个设计看似简单，但它解决了一个真实问题：AI 编码 agent 最大的弱点不是写代码，是自己审自己。

一个人写完自己审，等于没审。一个 agent 写完自己审，也是。OpenRig 的 owner-checker 拓扑把"写"和"审"强制分离到两个独立的 agent 实例，每个有自己的上下文窗口和工具权限。checker 看到的不是 owner 的"思考过程"，而是 owner 产出的代码——这更接近真实 code review 的场景。

README 里描述的流程是这样的：

1. 你给 owner 一个 bounded outcome（"实现某个有用的改动"） 2. owner 在 queue 里记录任务，返回 task ID 3. owner 实现完，请 checker 审查"exact candidate"（精确的候选提交） 4. checker 审完记录结果和你怎么验证 5. 你看最终产物和审查报告，决定下一步

注意"exact candidate"这个词。不是"大概看看代码"，是针对一个具体的、可测试的提交候选做审查。这把"AI 审查"从模糊的"这段代码好不好"变成了"这个具体的提交能不能合并"——问题定义清楚了，答案才有意义。

权限模型：OpenRig 改了你机器上的什么

OpenRig 的 setup 会改你机器上的东西，而且 README 毫不掩饰地列出来了：

• 在 ~/.tmux.conf 里加 OpenRig 块（鼠标支持、scrollback）
• 在 ~/.claude/skills 和 ~/.agents/skills 里种入 discovery skill
• 写 Codex hook 配置和 trust records
• 创建 ~/.openrig 实例状态目录（含数据库）

这比"一键安装脚本"诚实得多。大多数工具的 setup 是黑箱，你不知道它改了什么直到出问题。OpenRig 把 setup 当成一个需要 review 的 PR 来对待。

这一层为什么重要

回到 rig 的定位。AI 编码工具的栈现在大概是这样的：

模型层    →  GPT-5.6, Claude Opus, Gemini
harness 层 →  Claude Code, Codex, Cursor, Aider
rig 层    →  OpenRig（新）
应用层    →  你的代码仓库

每一层的抽象不同。模型层管"能不能想出来"，harness 层管"能不能执行"，rig 层管"能不能协作"。前两层已经成熟，第三层刚刚出现。

OpenRig 不是唯一做这层的。Anthropic 自己的 Claude Code 也在往这个方向走（multi-session），Cursor 也在加 agent 协作能力。但 OpenRig 的独特之处是：它不绑定单一 harness。你可以混搭 Claude Code 和 Codex，未来如果出现新的 harness，理论上也能加进来。

这种"跨厂商编排"的价值在于：不同模型的强项不同。Claude 可能在架构设计上更强，Codex 可能在实现细节上更稳。如果你只能用一个，你得在"设计好"和"实现稳"之间做取舍。rig 层让你不用取舍——设计阶段派 Claude，实现阶段派 Codex，审查阶段两个都参与。

当前状态和风险

README 没有回避项目还很早期的事实。rig setup 会改 trust settings，--dry-run 是强烈建议的第一步。Bun 安装可能被 block postinstall script。Codex 需要预先 login。这些前置条件意味着 OpenRig 目前面向的是"已经用熟了 Claude Code 和 Codex、想试试两个一起跑"的重度用户，不是"装个工具就能用"的普通开发者。

另一个风险是成本。两个 agent 同时跑意味着两份 API 调用。owner 写一遍，checker 审一遍，一个改动消耗的 token 是单 agent 的两到三倍。这种成本换来的收益是"审查质量更高"——但这个收益很难量化，取决于你的代码库对"未审查合并"的容错度。

我的看法

OpenRig 做的事情方向是对的：AI 编码的下一站不是"更强的单 agent"，而是"更好的 agent 协作"。但它的实现路径——tmux + YAML + 跨厂商 harness——意味着它走的是"重编排、轻抽象"路线。这种路线的好处是落地快、不发明新概念；坏处是扩展性依赖 harness 之间的兼容性，一旦某个 harness 的 API 大改，rig 层就得跟着改。

"rig"这个抽象本身值得记住。harness 之上需要一层"队伍管理层"，这几乎是一个确定性的需求。OpenRig 能不能成为这一层的标准实现不好说，但这一层一定会存在。当它存在时，你跟 AI 编码的交互方式会从"跟一个 agent 对话"变成"跟一个 lead 说目标，lead 自己调度队伍"——你不再写代码，你管理写代码的团队。

项目地址：https://github.com/mvschwarz/openrig 安装：npm install -g @openrig/cli 要求：Node.js 20/22/24 + tmux + 已认证的 Codex