项目地址：/mvschwarz/openrig

当多个 AI 编程代理同时投入一项工作时，真正棘手的往往不是如何多开几个终端，而是如何让它们成为一支能持续协作、彼此可见、能够交接任务的团队。

OpenRig 想解决的正是这件事。

它并不试图替代 Claude Code 或 Codex，也不把重点放在单个代理本身。它关注的是这些代理共同形成的系统：谁在运行，谁负责什么，谁与谁协作，任务如何传递，团队状态如何查看，工作现场又如何在停止之后恢复。

一句话来说，OpenRig 是一个多代理编排工具。它为已经存在的 AI 编程代理套上一层更大的结构，让 Claude Code 与 Codex 可以出现在同一个团队中，并作为一个整体被管理。

## 从一堆终端，到一支有席位的团队

很多人都见过这样的场景：终端窗口一个接一个地开着，每个窗口里都有一个正在工作的代理。它们各自拥有上下文，各自执行命令，各自等待下一条指令。窗口越来越多，信息却越来越散。

OpenRig 希望把这些零散会话变成持久、有组织的团队。

在 OpenRig 的语境里，代理不只是一次临时对话，而是拥有稳定身份的席位。一个席位可以有固定的角色和地址，例如：

```text
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 中给出的流程先要求检查环境，再预览启动计划，随后正式启动并打开共享终端界面：

```bash
tmux -V
codex --version
codex login status
```

```bash
cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared
```

这里的 `--plan` 很像正式行动前的一次排兵布阵。它让启动前的安排先被看见，再决定是否执行。

启动之后，可以检查团队中各个节点是否已经就绪：

```bash
rig ps --nodes --rig first-project
```

当负责人席位准备完成，就可以给它一个边界明确的目标：

```bash
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 也提供队列查看命令：

```bash
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，并展示从接收、规划、构建到审查的交接路径。

```bash
rig specs preview conveyor --kind rig
rig up conveyor
```

而 `product-team` 则是一个更大的产品开发示例，其中包含两名编排者、实现、质量保障、设计和两名独立评审者。

```bash
rig specs preview product-team --kind rig
rig up product-team
```

除这些模板外，OpenRig 还提供 `implementation-pair`、`adversarial-review`、`research-team` 与 `secrets-manager` 等示例。

查看可用的规格库，可以运行：

```bash
rig specs ls
```

这些名称背后呈现出一个很清晰的方向：OpenRig 不只是启动代理，更是在提供不同协作组织形式的起点。

## 可见、可查、可进入的工作状态

多代理系统最怕黑箱。

如果团队成员都在工作，但你不知道谁卡住了、谁已经完成、谁正在等待、谁与谁有关联，那么再多的代理也可能变成更复杂的混乱来源。

OpenRig 提供了终端界面，用于查看团队的协调状态。它能够呈现 rig、pod 与 seat，并以表格和图形展示拓扑。界面中还可以查看项目、规格、信息流与实例健康状态。

它的组成包括 CLI、TUI、MCP 服务、本地守护进程、SQLite、tmux 以及运行时适配器，整体结构如下：

```text
CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters
```

其中各部分承担不同职责。

- CLI 用于启动团队、查看状态、发送消息、追踪归属工作与管理上下文
- TUI 用于浏览拓扑、表格、图形、席位详情、Specs、Projects、Terminals、Feed 与 System
- MCP 为代理提供管理自身拓扑的工具，例如启动 rig、查看状态、发送消息与发送聊天室信息
- 运行时层负责 Claude Code、Codex、终端节点与 Pi adapter 的连接

每个代理都运行在一个可以直接进入、检查和操作的 tmux 会话中。OpenRig 并没有把代理封进不可触碰的黑盒，而是让人仍然可以接近真实的工作现场。

如果需要从共享看板暂时离开而不停止它，可以使用 tmux 的分离方式。之后再运行共享 TUI，即可回到同一视图。

```text
Ctrl-b 然后 d
```

```bash
rig tui --shared
```

## 不只启动，也能发现、接管、扩展与收缩

现实中的代理会话并不总是从 OpenRig 开始。

有时候，Claude Code 或 Codex 已经在 tmux 中运行。OpenRig 支持发现这些既有会话，并将它们接管到受管理的 rig 中。

```text
rig discover
rig adopt
```

这让已有工作不必为了进入编排系统而被迫从零开始。

当团队规模变化时，OpenRig 还可以通过一组命令演化正在运行的拓扑：

```text
rig grow
rig shrink
rig launch
rig remove
```

这组动作很有意思。它意味着团队不是一次启动后就被固定住的静态配置，而是可以随着任务推进扩展、缩减、增加成员或移除成员的运行中系统。

对于一个需要长期推进的项目来说，这种能力尤其重要。今天可能只需要负责人和检查者，明天可能需要实现、设计与两个独立评审者；问题不是代理数量本身，而是团队结构能否随着工作变化。

## 快照与恢复，让协作不必从断点重新猜起

OpenRig 支持对拓扑进行快照。

使用 `rig down --snapshot` 可以捕获完整状态，随后可以通过名称再次使用 `rig up <name>` 恢复。恢复过程会报告每个节点的结果，例如已经恢复、重新启动或失败。

```bash
rig down --snapshot
rig up <name>
```

README 中还给出了 demo 相关的恢复流程，并特别强调 Claude 与 Codex 的原生恢复语义存在差异。

在该演示中，Codex 的新鲜会话可以立即恢复，而新鲜 Claude 会话在刚刚执行 `rig up` 后并不会立刻具备快照安全性。完成一次预热交互后，当前存储的 Claude 标识可以恢复。

因此，demo 会建立并验证一个恢复基线。相关命令如下：

```bash
npx tsx demo/scripts/check-demo-health.ts --rig demo-rig
npx tsx demo/scripts/verify-native-resume.ts --rig demo-rig
npx tsx demo/scripts/seed-resume-baseline.ts --rig demo-rig
npx tsx demo/scripts/verify-native-resume.ts --rig demo-rig
```

这种把恢复能力纳入验证流程的做法，透露出 OpenRig 对持续协作的重视。团队协作并不只发生在启动后的那一段时间里，也发生在停止、重启、恢复与再次接手的每一个节点。

## RigBundle：把团队拓扑装进可携带的归档

除了快照恢复，OpenRig 还提供 RigBundle。

RigBundle 是一种可携带归档，其中包含 vendored AgentSpecs，并使用 SHA-256 完整性校验。它的目标是让团队拓扑可以跨机器共享。

demo 目录提供了对应的打包、检查、安装与启动流程：

```bash
rig bundle create demo/rig.yaml --rig-root demo -o /tmp/demo.rigbundle
rig bundle inspect /tmp/demo.rigbundle
rig bundle install /tmp/demo.rigbundle --yes --target /tmp/demo-install
rig up /tmp/demo.rigbundle
```

从团队定义到代理蓝图，再到可分发的归档，OpenRig 试图让多代理系统具备更清晰的可复制性。

## 让代理管理代理团队

OpenRig 的 MCP 工具让代理不仅可以完成编码任务，也可以参与管理自身所在的团队。

代理可以使用如 `rig_up`、`rig_ps`、`rig_send`、`rig_chatroom_send` 这样的工具来启动团队、查看状态、发送消息和进行聊天室沟通。

这使得协作结构本身也能够成为代理工作的一部分。

一个代理不只是被启动后等待指令的执行者，它还可以在明确边界内了解团队状态、协调工作、交接事项与反馈结果。对于复杂任务而言，这种能力让团队不必完全依赖外部人工逐条转发信息。

## 从代码团队延伸到被代理管理的软件

OpenRig 的一个更进一步的方向，是让 rig 不只承载代理，也能打包由这些代理管理的实际软件。

README 给出的示例是 `secrets-manager`。它包含一个由专门代理管理的 HashiCorp Vault 实例。

```bash
rig up secrets-manager
rig env status secrets-manager
rig send vault-specialist@secrets-manager "Check Vault health and report status." --verify
```

这类服务型 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 也尚未经过测试。

首次安装可以使用：

```bash
npm install -g @openrig/cli
rig setup --dry-run
```

也可以通过 Bun 安装：

```bash
bun add -g @openrig/cli
```

不过 OpenRig 本身仍运行在 Node.js 上，因此仍需要安装 Node.js 22。

`rig setup` 会尝试进行核心机器准备，包括 tmux、cmux、Claude Code、Codex 以及 tmux 默认设置。它会报告尝试过的操作和实际成功的结果。

如果希望准备更完整的操作工作站环境，可以使用：

```bash
rig setup --full
```

当环境发生变化，或者某些部分不再正常工作时，可以运行：

```bash
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 中的终端：

```bash
rig terminal open first-project --provider herdr
```

如果使用 cmux，则将 provider 指定为 `cmux`。

无论使用哪个终端工作区提供方，底层会话依然可以通过 tmux 访问。这让可视化工作区与原始终端会话并不是彼此替代的关系，而是对同一协作现场的不同入口。

## 一个八节点演示，展示团队的层次感

OpenRig 的 North Star Demo 给出了一套完整的多代理拓扑示例。

这个 demo 包含四个 pods、八个节点，其中六个是代理运行时，两个是终端基础设施节点。

其结构包括：

- `orch` pod 中的 `lead`，负责编排
- `dev` pod 中的 `impl`、`qa` 与 `design`
- `rev` pod 中的 `r1` 与 `r2`
- `infra` pod 中的 `daemon` 与 `ui`

其中，`orch.lead` 会把工作委派给 `dev.impl`，`dev.qa` 观察 `dev.impl`，`rev.r1` 与 `rev.r2` 协作。

启动 demo 的方式很简单：

```bash
./demo/run.sh
```

脚本会启动拓扑，并为 demo rig 建立恢复安全基线。若新会话还不能恢复，它会为每个代理植入一次预热交互，然后重新验证原生恢复能力。

完整证明流程可以运行：

```bash
./demo/run-proof.sh
```

它会生成启动记录、节点状态、健康检查结果、恢复探测结果、停止记录、tmux 检查记录与恢复记录等自动化证明产物。

这套 demo 的价值不只在于展示多个代理同时运行，更在于展示一个团队如何拥有拓扑、关系、基础设施节点、恢复验证与可重复检查的过程。

## OpenRig 的真正主角，是协作本身

OpenRig 的主角并不是某一个模型，也不是某一个终端，更不是某一个看板。

它真正关注的是协作本身。

当 Claude Code 和 Codex 作为独立会话工作时，它们已经具备各自的能力。但当任务扩大到多个角色、多个阶段、多次交接与长期运行时，能力之外还需要秩序。

需要谁负责。

需要谁检查。

需要任务从哪里来，又交给谁。

需要团队状态能够被看到。

需要工作能够在中断后恢复。

需要既有会话能够被发现和接管。

需要团队结构可以随着工作演化。

OpenRig 用 rig、pod、seat、AgentSpec、Culture、快照、恢复、TUI、MCP 与 tmux，把这些原本散落在终端、提示词与人工记忆中的协作元素，收拢成一个可以运行、观察和调整的系统。

它让多代理编程不只是许多窗口同时亮起，而更像一间真正开始运转的协作工坊。

当多个 AI 编程代理同时投入一项工作时，真正棘手的往往不是如何多开几个终端，而是如何让它们成为一支能持续协作、彼此可见、能够交接任务的团队。

OpenRig：把散落的 AI 编程会话，编织成一支可持续协作的团队

技术副总监/联合创始人

人工智能

OpenRig是一款多代理编排工具，通过YAML定义团队拓扑，将ClaudeCode与Codex整合为统一协作系统。它提供席位管理、任务交接、状态可视化、快照恢复及RigBundle归档功能，支持代理发现、接管和动态扩展，让AI编程代理从散乱终端转变为有组织、可持续协作的团队。

代码解释

数据库

AI编程

Windows

SQLite

Linux

YOLO

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OpenRig：把散落的 AI 编程会话，编织成一支可持续协作的团队-腾讯云开发者社区-腾讯云

OpenRig：把散落的 AI 编程会话，编织成一支可持续协作的团队

OpenRig：把散落的 AI 编程会话，编织成一支可持续协作的团队

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐