OpenRig：多智能体编程缺的那层控制平面
如果你同时开 Claude Code 和 Codex 干活，大概率见过这种场面：一个终端在重构，另一个在写测试，还口口声声说“基于最新代码”。二十分钟后，第一个智能体把文件挪走了，第二个还在 import 旧路径。两边都说自己成功了，代码库却开始散架。
它的卖点很朴素：让 Claude Code 和 Codex 像一个系统一样跑，而不是两个互相不知道对方存在的进程。
OpenRig 到底是什么
- 很多多智能体项目管自己叫框架。OpenRig 管自己叫 harness，外壳或者夹具。
- 框架让你按它的世界观搭东西。harness 包在已经能用的智能体外面，只改协作方式。
- 它分三层：
- harness：包住单个智能体，管工具边界和上下文。
- rig：用 YAML 定义多个 harness 组成的团队。
- session：用 tmux 维持持久状态，重启也能续上。
- 上手很具体：写一个
rig.yaml，指定 seats，也就是具名智能体实例，分配模型和角色，然后一条命令启动。 - 每个智能体有稳定地址，比如
dev-owner@first-project。 - 本地 daemon 用 SQLite 存状态。TUI 和 MCP server 提供检查、快照、智能体间消息等工具。
最妙的设计：默认双座，跨厂商互审
- 启动模板默认两个 seat：一个 owner，一个 checker，默认都跑 Codex。
- owner 拿到有边界的任务目标，排进队列，再让 checker 独立审查同一个候选输出，然后才回报。
- 这背后是很成熟的软件工程经验：不共享作者盲区的审查者，比作者自审更容易抓出缺陷。
- OpenRig 把这个原则扩展到模型家族之间。Claude Code 的输出可以交给 Codex 审，反过来也行。
- 训练数据不同，失败模式不同，自己跟自己串通作弊的难度更高。
- 协调原语也很克制：
delegate：把任务路由给专家，带上有边界的上下文。requestDecision：把需要人类拍板的岔路口抛出来。- task queue：每次交接都持久化到 SQLite。
- 智能体崩了或撞到限流，rig 通过 tmux pane 退出状态发现，按同一 seat 配置重启 harness，从最后一次提交状态继续。
它到底解决什么痛点
诚实说，OpenRig 解决的是“系统层”问题。当你让不止一个编程智能体操作同一个仓库，这层问题就冒出来了。
- 共享上下文漂移：两个智能体基于过期快照干活。
- 文件写入冲突：你改你的，我改我的，最后合不上。
- 会话间交接丢失：上一个 session 的决策，下一个 session 不知道。
- 出事后没有审计线索：谁在什么时候改了什么，为什么改，查不到。
- 单智能体只有一个上下文、一条写入流、一份决策历史。两个智能体共享文件系统，本质是并发问题，只不过冲突实体是不同训练、不同温度的语言模型。
- OpenRig 把这种临时协调变成声明式对象。YAML 团队规格记录 pods、members、edges、continuity policies。SQLite 记录每个 rig、seat、edge。
rig down --snapshot抓取整个拓扑，重启时按名字恢复。
功能效率怎么样
- 状态持久化做得比较实在。不是靠内存里那点上下文，而是 SQLite 加 tmux session。
- 任务交接有队列，不靠复制粘贴。每个 handoff 都能查。
- 快照和恢复让实验成本变低。拓扑搞坏了，按名字恢复。
- 跨 runtime 是效率关键。Claude Code 和 Codex 各自跑，但共享任务队列和审查流程。
- 它不追求全自动。
requestDecision明确留了人类拍板的口子，这点反而更适合真实项目。 - 安装会动真实配置，比如
~/.tmux.conf、~/.claude.json和 Codex 配置。README 要求先 dry run 再备份，这点算透明。
谁该用它
- 已经在终端里跑 Claude Code 或 Codex 的开发者。
- 通常是单人或小团队，在一个仓库上干活。
- 需要熟悉 tmux，Node.js 20、22 或 24。
- 原生支持 macOS 和 Linux。
- 最适合那种已经试过双终端工作流，觉得有戏但太乱，想要结构又不想上更重编排框架的人。
- OpenRig 卡在中间：比终端复用器多一点，比完整智能体开发平台少一点。
目标市场与价值
- 目标市场不是“所有写代码的人”，而是“已经在用多个编程智能体的人”。
- 这批人现在不多，但增长很快。AI 原生开发工具链、本地优先团队、对隐私敏感的团队，都更愿意自己托管协调层。
- 价值在于控制平面。单个智能体的能力由模型厂商决定，多智能体能不能稳定协作，取决于你用什么方式管住它们。
- OpenRig 不生产智能，它生产秩序。
- 发展潜力在于跨 runtime。Anthropic 和 OpenAI 都不会原生支持把自家智能体交给对方审查。OpenRig 可以。
- 风险也明显：项目很年轻，迭代很快，几天内从 v0.5.15 到 v0.5.17。
- 它的价值依赖你已经跑多个编程智能体，并且感受到协调开销。如果你只用一个智能体，OpenRig 暂时帮不上太多。
一个具体案例
假设你有一个 Node.js 项目，要做一次跨目录重构，同时补测试。
不用 OpenRig 的常见做法：
- 终端 A 开 Claude Code，让它把
src/old移到src/new，顺手改 import。 - 终端 B 开 Codex，让它给“最新代码”写测试。
- 二十分钟后，Claude Code 移了文件，Codex 还在从旧路径 import。
- 两边都报告成功。你手动收拾。
用 OpenRig 可以这样：
- 写一个
rig.yaml，定义两个 seat：dev-owner和dev-checker。 dev-owner跑 Claude Code，负责重构。dev-checker跑 Codex，负责审查候选输出和测试。- owner 通过
delegate把测试任务交给 checker，checker 从 SQLite 队列拿到有边界的上下文。 - checker 发现旧 import 路径，通过 task queue 回报，owner 修正后再提交。
- 如果 owner 撞到限流，rig 检测到 pane 退出，重启同一个 seat，从最后状态继续。
- 整个过程有快照，有审计，有交接记录。
这不是让模型变聪明，而是让它们别互相踩脚。
和同类工具比
- CrewAI：Python 优先，用来以编程方式构建智能体系统。你要在它的框架里造智能体。OpenRig 不造智能体，它安排已经存在的智能体。
- AutoGen：把智能体组织成共享群聊的参与者。2025 年底进入维护模式。OpenRig 更轻，更偏终端和真实 coding session。
- Claude Managed Agents：Anthropic 托管方案，容器和事件循环跑在它们基础设施上。OpenRig 是自托管替代，tmux 做传输，你的文件系统做共享状态。
- Shepherd：跨项目管理智能体。OpenRig 多了声明式拓扑和跨 runtime 协调。
- AgEnD Terminal：终端层面的智能体管理。OpenRig 把它们变成有角色、有共享任务队列的团队。
- Claude Agent Teams：结构上最接近。两者都跑真实 coding session 并协调。关键区别是 OpenRig 跨 runtime，可以把 Claude Code seat 放在 Codex seat 旁边，做跨厂商互审。Anthropic 和 OpenAI 原生都做不到这点。
- 结论：OpenRig 的定位不是“更强的智能体”，而是“多智能体编程的控制平面”。
快速上手长什么样
# rig.yaml 示意name:first-projectseats:-id:dev-ownerruntime:claude-coderole:owner-id:dev-checkerruntime:codexrole:checker# 启动rig up first-project# 看状态rig status# 快照并关停rig down--snapshot总结
OpenRig 是那种解决真实摩擦的工具，不是炫技。它假设你已经有一堆能干的编程智能体，只是缺一层让它们别打架的控制面。项目还年轻，安装会动配置，生态也依赖 Claude Code 和 Codex 的稳定性。但默认跨厂商互审、声明式拓扑、SQLite 持久队列、tmux 会话恢复，这些选择都很实在。
如果你已经在双终端工作流里挣扎过，OpenRig 值得认真看。它不会让你的智能体更聪明，但会让它们停止互相踩脚。
