openrig
学习从来无捷径，循序渐进登高峰。——高永祚
OpenRig：把散落的 AI 编程会话，编织成一支可持续协作的团队
项目地址：https://github.com/mvschwarz/openrig
当多个 AI 编程代理同时投入一项工作时，真正棘手的往往不是如何多开几个终端，而是如何让它们成为一支能持续协作、彼此可见、能够交接任务的团队。
OpenRig 想解决的正是这件事。
它并不试图替代 Claude Code 或 Codex，也不把重点放在单个代理本身。它关注的是这些代理共同形成的系统：谁在运行，谁负责什么，谁与谁协作，任务如何传递，团队状态如何查看，工作现场又如何在停止之后恢复。
一句话来说，OpenRig 是一个多代理编排工具。它为已经存在的 AI 编程代理套上一层更大的结构，让 Claude Code 与 Codex 可以出现在同一个团队中，并作为一个整体被管理。
从一堆终端，到一支有席位的团队
很多人都见过这样的场景：终端窗口一个接一个地开着，每个窗口里都有一个正在工作的代理。它们各自拥有上下文，各自执行命令，各自等待下一条指令。窗口越来越多，信息却越来越散。
OpenRig 希望把这些零散会话变成持久、有组织的团队。
在 OpenRig 的语境里，代理不只是一次临时对话，而是拥有稳定身份的席位。一个席位可以有固定的角色和地址，例如：
1 | dev-owner@first-project |
坐在这个席位里的具体会话可以变化，但席位自身的身份、职责与已沉淀的上下文可以持续存在。这样的设计让团队协作不必完全依赖某一个短暂会话，而能够围绕明确角色继续向前。
你可以把结果目标交给主负责人，再让主负责人协调不同团队中的专门角色完成工作。实现、检查、设计、研究、评审等职责不再只是提示词里的临时称呼，而可以成为拓扑结构中真实存在的成员。
用 YAML 描述团队，而不是手工拼接窗口
OpenRig 的核心之一，是通过 YAML 定义团队拓扑。
这个定义被称为 RigSpec。它能够描述团队中的 pods、成员、连接关系以及连续性策略。换句话说，团队不是靠记忆和手工操作维持，而是有一份可以声明、启动、查看和演化的结构化蓝图。
其中几个概念构成了 OpenRig 的协作骨架。
RigSpec
RigSpec 是多代理编排定义。它用 YAML 描述 pods、成员、连接关系、连续性策略以及团队文化文件。
AgentSpec
AgentSpec 是可复用的代理蓝图，其中可以包含技能、指导内容、钩子、配置档案与启动约定。
Seat
Seat 是团队中的稳定角色与地址。它像一张长期保留的工位，具体坐在工位上的会话可能发生变化，但工位本身的身份不会轻易消失。
Pod
Pod 是一组具有共同指导和上下文的席位。Pod 中的成员仍然各自拥有独立的上下文窗口，但它们可以共享同一组协作方向。
Culture
CULTURE.md 用来定义团队协调规范。不同性质的团队可以有不同的文化：研究型团队可以更强调探索，实施型团队则可以采用更保守、强调验证的协作方式。
于是，多代理协作不再是一句宽泛的口号，而是可以被清楚定义的组织关系。
一条命令，拉起整个协作现场
OpenRig 的启动方式很直接。定义好团队之后，可以通过 rig up 拉起整个 rig。
这个过程不只是启动几个代理。OpenRig 会围绕团队启动 tmux 会话、代理运行时、启动文件与就绪检查，让各个席位进入可工作的状态。
最小的首次使用路径来自 first-project。README 中给出的流程先要求检查环境，再预览启动计划，随后正式启动并打开共享终端界面：
1 | tmux -V |
1 | cd /path/to/your/repository |
这里的 --plan 很像正式行动前的一次排兵布阵。它让启动前的安排先被看见，再决定是否执行。
启动之后，可以检查团队中各个节点是否已经就绪：
1 | rig ps --nodes --rig first-project |
当负责人席位准备完成，就可以给它一个边界明确的目标：
1 | rig send dev-owner@first-project 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate.' |
OpenRig 也提供队列查看命令：
1 | rig queue list --destination dev-owner@first-project --limit 1000 |
一个值得注意的细节是，发送消息本身不会自动创建队列事项。由负责人记录任务，意味着任务归属与任务沟通并不是同一件事。这样的区分让协作过程不只是消息来回流动，而能够保留明确的工作记录。
Claude Code 与 Codex，放进同一个系统里协作
OpenRig 的描述非常明确：它可以把 Claude Code 与 Codex 放进同一个 rig 中，作为统一系统进行管理。
这不是把不同工具简单并排摆放，而是让它们在同一份团队拓扑中拥有席位、连接关系和可观察状态。OpenRig 还支持原生 Claude Code 与 Codex 会话、终端节点，以及通过终端窗格内 RPC runner 运行的 Pi adapter。
对于团队来说，成员并不一定都是同一种代理。不同运行时可以承担不同角色，并在一个统一的协作结构中存在。
README 提供的 conveyor 就展示了这种混合方式。它是一个四席位的起步模板，混合使用 Claude Code 与 Codex，并展示从接收、规划、构建到审查的交接路径。
1 | rig specs preview conveyor --kind rig |
而 product-team 则是一个更大的产品开发示例，其中包含两名编排者、实现、质量保障、设计和两名独立评审者。
1 | rig specs preview product-team --kind rig |
除这些模板外，OpenRig 还提供 implementation-pair、adversarial-review、research-team 与 secrets-manager 等示例。
查看可用的规格库，可以运行：
1 | rig specs ls |
这些名称背后呈现出一个很清晰的方向：OpenRig 不只是启动代理，更是在提供不同协作组织形式的起点。
可见、可查、可进入的工作状态
多代理系统最怕黑箱。
如果团队成员都在工作，但你不知道谁卡住了、谁已经完成、谁正在等待、谁与谁有关联，那么再多的代理也可能变成更复杂的混乱来源。
OpenRig 提供了终端界面，用于查看团队的协调状态。它能够呈现 rig、pod 与 seat，并以表格和图形展示拓扑。界面中还可以查看项目、规格、信息流与实例健康状态。
它的组成包括 CLI、TUI、MCP 服务、本地守护进程、SQLite、tmux 以及运行时适配器，整体结构如下：
1 | CLI / TUI / MCP |
其中各部分承担不同职责。
- CLI 用于启动团队、查看状态、发送消息、追踪归属工作与管理上下文
- TUI 用于浏览拓扑、表格、图形、席位详情、Specs、Projects、Terminals、Feed 与 System
- MCP 为代理提供管理自身拓扑的工具，例如启动 rig、查看状态、发送消息与发送聊天室信息
- 运行时层负责 Claude Code、Codex、终端节点与 Pi adapter 的连接
每个代理都运行在一个可以直接进入、检查和操作的 tmux 会话中。OpenRig 并没有把代理封进不可触碰的黑盒，而是让人仍然可以接近真实的工作现场。
如果需要从共享看板暂时离开而不停止它，可以使用 tmux 的分离方式。之后再运行共享 TUI，即可回到同一视图。
1 | Ctrl-b 然后 d |
1 | rig tui --shared |
不只启动，也能发现、接管、扩展与收缩
现实中的代理会话并不总是从 OpenRig 开始。
有时候，Claude Code 或 Codex 已经在 tmux 中运行。OpenRig 支持发现这些既有会话，并将它们接管到受管理的 rig 中。
1 | rig discover |
这让已有工作不必为了进入编排系统而被迫从零开始。
当团队规模变化时，OpenRig 还可以通过一组命令演化正在运行的拓扑：
1 | rig grow |
这组动作很有意思。它意味着团队不是一次启动后就被固定住的静态配置，而是可以随着任务推进扩展、缩减、增加成员或移除成员的运行中系统。
对于一个需要长期推进的项目来说，这种能力尤其重要。今天可能只需要负责人和检查者，明天可能需要实现、设计与两个独立评审者；问题不是代理数量本身，而是团队结构能否随着工作变化。
快照与恢复，让协作不必从断点重新猜起
OpenRig 支持对拓扑进行快照。
使用 rig down --snapshot 可以捕获完整状态，随后可以通过名称再次使用 rig up <name> 恢复。恢复过程会报告每个节点的结果，例如已经恢复、重新启动或失败。
1 | rig down --snapshot |
README 中还给出了 demo 相关的恢复流程，并特别强调 Claude 与 Codex 的原生恢复语义存在差异。
在该演示中，Codex 的新鲜会话可以立即恢复，而新鲜 Claude 会话在刚刚执行 rig up 后并不会立刻具备快照安全性。完成一次预热交互后，当前存储的 Claude 标识可以恢复。
因此，demo 会建立并验证一个恢复基线。相关命令如下：
1 | npx tsx demo/scripts/check-demo-health.ts --rig demo-rig |
这种把恢复能力纳入验证流程的做法，透露出 OpenRig 对持续协作的重视。团队协作并不只发生在启动后的那一段时间里，也发生在停止、重启、恢复与再次接手的每一个节点。
RigBundle：把团队拓扑装进可携带的归档
除了快照恢复，OpenRig 还提供 RigBundle。
RigBundle 是一种可携带归档，其中包含 vendored AgentSpecs，并使用 SHA-256 完整性校验。它的目标是让团队拓扑可以跨机器共享。
demo 目录提供了对应的打包、检查、安装与启动流程：
1 | rig bundle create demo/rig.yaml --rig-root demo -o /tmp/demo.rigbundle |
从团队定义到代理蓝图，再到可分发的归档，OpenRig 试图让多代理系统具备更清晰的可复制性。
让代理管理代理团队
OpenRig 的 MCP 工具让代理不仅可以完成编码任务，也可以参与管理自身所在的团队。
代理可以使用如 rig_up、rig_ps、rig_send、rig_chatroom_send 这样的工具来启动团队、查看状态、发送消息和进行聊天室沟通。
这使得协作结构本身也能够成为代理工作的一部分。
一个代理不只是被启动后等待指令的执行者，它还可以在明确边界内了解团队状态、协调工作、交接事项与反馈结果。对于复杂任务而言，这种能力让团队不必完全依赖外部人工逐条转发信息。
从代码团队延伸到被代理管理的软件
OpenRig 的一个更进一步的方向，是让 rig 不只承载代理，也能打包由这些代理管理的实际软件。
README 给出的示例是 secrets-manager。它包含一个由专门代理管理的 HashiCorp Vault 实例。
1 | rig up secrets-manager |
这类服务型 rig 需要 Docker。
在这里，代理团队与实际运行的软件不再是完全分离的两层。团队可以围绕软件实例组织职责，而软件实例也成为团队拓扑所管理的一部分。
技能不是功能列表，而是按需加载的上下文
OpenRig 还包含 skills 机制。
这些 skills 是随 OpenRig 一起提供的渐进式上下文清单。它们不是传统意义上简单的能力标签，而是一种让代理按需加载工作上下文的原语。
skill 的 frontmatter 位于代理的热层，用于基于触发描述进行低成本模式匹配。正文会在 skill 被激活时加载，而目录中的引用资料则可以在需要时再加载。
这样一来，代理不必在任何时候都携带全部信息，而可以在遇到相应需求时加载合适的内容。
OpenRig 代理会自动发现 skills，通常不需要显式调用。对于 skill 的编写者来说，关键在于把重复出现的需求命名出来，并给出足够精确的触发描述，让代理能在正确时刻拿起正确的上下文。
skills 会随守护进程一起安装，并随着启动的 rig 提供给代理使用。
安装与环境要求
OpenRig 需要 Node.js、tmux，以及 macOS 或 Linux 环境。
README 列出的支持版本包括 Node.js 20、22 与 24。对于搭载 Apple 芯片的 Mac，推荐使用 Node.js 22。原生 Windows 尚未支持，WSL2 也尚未经过测试。
首次安装可以使用：
1 | npm install -g @openrig/cli |
也可以通过 Bun 安装：
1 | bun add -g @openrig/cli |
不过 OpenRig 本身仍运行在 Node.js 上，因此仍需要安装 Node.js 22。
rig setup 会尝试进行核心机器准备，包括 tmux、cmux、Claude Code、Codex 以及 tmux 默认设置。它会报告尝试过的操作和实际成功的结果。
如果希望准备更完整的操作工作站环境，可以使用：
1 | rig setup --full |
当环境发生变化，或者某些部分不再正常工作时，可以运行：
1 | rig doctor |
这两个命令都支持 --json，适合由代理驱动的工作流。
关于本机改动、权限与运行时配置
OpenRig 的 README 对本机改动说明得很直接。
在安装、设置和运行过程中，OpenRig 会写入实例状态、提供方集成与工作区文件，其中包括信任设置与可执行钩子。
rig setup 会检查缺失工具，并向 ~/.tmux.conf 写入 OpenRig 配置块，用于鼠标支持与滚动缓冲。在 macOS 上，它还可以安装 cmux 并启用其自动化 socket 控制。
守护进程启动时，会在 OPENRIG_HOME 下创建或更新实例状态，其中通常包括数据库和受管理插件资源。默认情况下，这一目录是 ~/.openrig。
受管理的启动会创建 tmux 会话，注入席位身份与守护进程连接环境，并将选中的指导内容、skills、插件与运行时资源投射到相应环境中。
对于 Claude Code，OpenRig 会管理工作区信任、onboarding 完成状态、上下文采集器状态行命令、活动钩子以及部分设置与 MCP 资源。
对于 Codex，OpenRig 会写入守护进程使用的 CODEX_HOME/config.toml，启用钩子，添加活动转发命令，并为这些命令预先写入信任哈希。席位启动时还会为工作区加入信任级别。
README 同时强调，YOLO 默认关闭。只有显式设置 OPENRIG_YOLO=1，或使用完整绕过席位策略时，才会选择高权限模式。
这意味着 OpenRig 并没有把权限绕过作为默认前提。团队自动化可以推进，但权限仍然是需要被明确选择的边界。
终端工作区与协作现场
OpenRig 的 TUI 负责展示团队协调状态，而 herdr 与 cmux 可以把实际代理终端放在一起展示。
如果已经安装并连接 herdr，可以打开 starter 中的终端：
1 | rig terminal open first-project --provider herdr |
如果使用 cmux，则将 provider 指定为 cmux。
无论使用哪个终端工作区提供方，底层会话依然可以通过 tmux 访问。这让可视化工作区与原始终端会话并不是彼此替代的关系，而是对同一协作现场的不同入口。
一个八节点演示，展示团队的层次感
OpenRig 的 North Star Demo 给出了一套完整的多代理拓扑示例。
这个 demo 包含四个 pods、八个节点，其中六个是代理运行时，两个是终端基础设施节点。
其结构包括：
orchpod 中的lead，负责编排devpod 中的impl、qa与designrevpod 中的r1与r2infrapod 中的daemon与ui
其中，orch.lead 会把工作委派给 dev.impl，dev.qa 观察 dev.impl，rev.r1 与 rev.r2 协作。
启动 demo 的方式很简单：
1 | ./demo/run.sh |
脚本会启动拓扑，并为 demo rig 建立恢复安全基线。若新会话还不能恢复，它会为每个代理植入一次预热交互，然后重新验证原生恢复能力。
完整证明流程可以运行：
1 | ./demo/run-proof.sh |
它会生成启动记录、节点状态、健康检查结果、恢复探测结果、停止记录、tmux 检查记录与恢复记录等自动化证明产物。
这套 demo 的价值不只在于展示多个代理同时运行，更在于展示一个团队如何拥有拓扑、关系、基础设施节点、恢复验证与可重复检查的过程。
OpenRig 的真正主角，是协作本身
OpenRig 的主角并不是某一个模型，也不是某一个终端，更不是某一个看板。
它真正关注的是协作本身。
当 Claude Code 和 Codex 作为独立会话工作时，它们已经具备各自的能力。但当任务扩大到多个角色、多个阶段、多次交接与长期运行时，能力之外还需要秩序。
需要谁负责。
需要谁检查。
需要任务从哪里来，又交给谁。
需要团队状态能够被看到。
需要工作能够在中断后恢复。
需要既有会话能够被发现和接管。
需要团队结构可以随着工作演化。
OpenRig 用 rig、pod、seat、AgentSpec、Culture、快照、恢复、TUI、MCP 与 tmux，把这些原本散落在终端、提示词与人工记忆中的协作元素，收拢成一个可以运行、观察和调整的系统。
它让多代理编程不只是许多窗口同时亮起，而更像一间真正开始运转的协作工坊。