★ FEATURED ARTICLE OpenRig多智能体编程缺的那层控制平面如果你同时开 Claude Code 和 Codex 干活大概率见过这种场面一个终端在重构另一个在写测试还口口声声说“基于最新代码”。二十分钟后第一个智能体把文件挪走了第二个还在 import 旧路径。两边都说自己成功了代码库却开始散架。它的卖点很朴素让 Claude Code 和 Codex 像一个系统一样跑而不是两个互相不知道对方存在的进程。OpenRig 到底是什么很多多智能体项目管自己叫框架。OpenRig 管自己叫 harness外壳或者夹具。框架让你按它的世界观搭东西。harness 包在已经能用的智能体外面只改协作方式。它分三层harness包住单个智能体管工具边界和上下文。rig用 YAML 定义多个 harness 组成的团队。session用 tmux 维持持久状态重启也能续上。上手很具体写一个rig.yaml指定 seats也就是具名智能体实例分配模型和角色然后一条命令启动。每个智能体有稳定地址比如dev-ownerfirst-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 的开发者。通常是单人或小团队在一个仓库上干活。需要熟悉 tmuxNode.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定义两个 seatdev-owner和dev-checker。dev-owner跑 Claude Code负责重构。dev-checker跑 Codex负责审查候选输出和测试。owner 通过delegate把测试任务交给 checkerchecker 从 SQLite 队列拿到有边界的上下文。checker 发现旧 import 路径通过 task queue 回报owner 修正后再提交。如果 owner 撞到限流rig 检测到 pane 退出重启同一个 seat从最后状态继续。整个过程有快照有审计有交接记录。这不是让模型变聪明而是让它们别互相踩脚。和同类工具比CrewAIPython 优先用来以编程方式构建智能体系统。你要在它的框架里造智能体。OpenRig 不造智能体它安排已经存在的智能体。AutoGen把智能体组织成共享群聊的参与者。2025 年底进入维护模式。OpenRig 更轻更偏终端和真实 coding session。Claude Managed AgentsAnthropic 托管方案容器和事件循环跑在它们基础设施上。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 值得认真看。它不会让你的智能体更聪明但会让它们停止互相踩脚。
阅读完成 · 觉得有帮助？
