一个 YAML，把两个孤立编码智能体编成团队
九月二十七日前后在 GitHub 走红的 openrig（仓库 mvschwarz/openrig）切入的是几乎所有跑编码智能体的人都已用手搭过的那层：一堆终端标签页，有的开 Claude Code，有的开 Codex，中间靠人肉复制粘贴搬工作。openrig 的口号很锋利——「harness 包住模型，rig 包住你的 harnesses」。它用一份 YAML 把团队拓扑声明出来，一条命令拉起，每个智能体拿到一个稳定地址，比如 dev-owner@first-project。它跑在 Node 加 tmux 上，从 npm 装 @openrig/cli，Apache 2.0 协议，TypeScript 写成；发布节奏很快，v0.5.15 到 v0.5.17 在几天内连续落地，GitHub 星数一度冲到约九百。它真实改写 ~/.tmux.conf、~/.claude.json 和 Codex 配置，所以 README 专门要求先 dry run、先备份，这点透明度在会装可执行钩子的工具里并不多见。
默认就是 owner 加 checker 的互审
openrig 最值得抄的不是它能编排，而是它的起始 rig 把「独立复核」做成了默认。起始团队是两张 Codex 席位，一个 owner、一个 checker：你给 owner 一个边界清晰的结果目标，它把任务记进队列，请 checker 复核同一份候选，再回报给你。这个默认背后是一个被研究反复推荐的朴素想法——让一个不共享作者盲点的检查者去审产出，比作者自审稳。openrig 的巧思在于把「跨厂商互审」做成产品默认：Claude Code 的产物可以交给 Codex 审，反过来也行，两个模型家族的盲点不同，互相查比自己查更难放水。它底下是一套本地守护进程加 CLI 加终端 TUI 加 MCP 服务器的组合，所有 agent 跑在 tmux 会话里，每个 seat 有稳定地址，rig up 拉起会话与就绪检查，rig send / rig broadcast / rig chatroom 在 agent 间传消息，rig down --snapshot 把整个拓扑拍下来、重启后能按名字恢复。
它解决的是「系统层」而非「模型层」
把视角拉高，openrig 填的是 harness 之上那层——多个智能体一起跑时形成的系统。过去这层是临时脚本加肌肉记忆：关笔记本拓扑就没了，各 harness 启动参数和权限面各不相同，消息在终端 pane 间丢、待办没人记、没有审计痕迹。openrig 用一份 RigSpec 声明 pods、members、edges 和 continuity 策略，把脆弱的手工编排变成持久对象：SQLite 记下每个 rig、pod、seat、edge，快照恢复时逐节点报告是恢复、全新还是失败。它还能 rig discover 指纹已有 tmux 会话、rig adopt 接管，而不强迫重启。对团队而言，真正值钱的是那个共享队列加 inbox/outbox 的协调原语——每次消息和任务都落库，交接能跨重启、事后能列清单。换句话说，它教的是「把 agent 当系统管」到底要哪些零件：稳定地址、持久状态、可恢复拓扑、跨 harness 适配、审计轨迹。
透明与侵入是一体两面
也要把边界说清。openrig 装 CLI 时会真实改写 tmux、Claude Code、Codex 的配置文件，并写入 ~/.claude/skills 之类的钩子与信任设置，所以它的 dry run 与备份提醒不是客套，而是必须照做的步骤——这类会装可执行钩子进你 agent 的工具，一旦配置被覆盖，恢复成本不低。另一个硬边界是平台：它原生支持 macOS 与 Linux 加 tmux，原生 Windows 不在支持范围，想在 Windows 上跑得自己垫一层。星数约九百、几天连发多版，说明「把编码智能体编成有地址的团队」这个痛点足够真实，但项目仍早期、API 与默认会动，生产采用前先在小仓库试 dry run 与快照恢复，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
一句收尾
openrig 的价值不在它多会写代码，而在它把「owner 分派、checker 独立复核、跨厂商互审」从一句方法论，变成了一条 rig up 就能跑的默认。当编码智能体的竞争从单模型跑到多模型协作，谁先把这层系统做厚，谁才接得住真实团队的复杂度的。