OpenRig 是什么：让多个编程 Agent 协作且可被人监督
OpenRig 是什么：让多个编程 Agent 协作且可被人监督
先分清团队配置、固定席位和本地守护进程，再决定是否需要第二个 Agent
你将学会
- 先理解席位
- 跟随控制链
- 不要忽略首次副作用
开始前需要
- 支持的主机上安装 Node 22 或 24 与 tmux
- 一个可用 Provider 账号及可丢弃仓库
把第一次 owner/checker 运行变成可核验的上线依据
先看结论
- 席位是稳定职责，不是正确性的保证。
- TUI 看状态，tmux 承载会话。
- 托管启动可能改写信任设置和 hooks。
先理解席位
OpenRig 读取 RigSpec，按配置启动具有固定职责的团队。`dev-owner@first-project` 这样的席位有稳定地址，占用它的 Agent 会话却可以更换；Pod 负责分组，边描述席位之间的协作关系。
这适合让开发者与检查者讨论同一个候选改动，但不会自动提高答案正确率。任务范围、改动验收和是否合并代码，仍然由操作者决定。
跟随控制链
文档中的路径是 CLI、TUI 或 MCP 进入本地 Hono 守护进程，再由领域服务连接 SQLite、tmux 和 Provider 适配器。Claude Code 与 Codex 可以共处一个 rig，前提是对应本地账号可用。
TUI 展示的是协作状态，真正的终端会话由 tmux 承载。关闭查看窗口并不等于停止席位；看板消失时先确认会话是否仍在运行。
不要忽略首次副作用
安装 npm 包主要添加 CLI；守护进程启动和托管席位还可能写入 Provider hooks、信任记录和工作区文件。README 按时点列出了这些变化，并提醒 `OPENRIG_HOME` 不能隔离所有 Provider 配置。
第一次试用前应读完改动清单，在可丢弃仓库里选择一个已能登录的 Provider，并记录启动前后的配置差异。本系列没有安装或运行 OpenRig。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
给一次任务指定开发席位与检查席位。
- 2
区分守护进程、席位、终端和查看界面。
- 3
第一次启动前备份 Provider 与工作区配置。
可复制示例
RigSpec -> 席位和协作边
CLI / TUI / MCP -> 守护进程 -> SQLite + tmux
操作者 -> 核验具体候选改动常见问题
需要同时购买两种模型服务吗？
不需要。入门指南允许只使用已经可工作的一个 Provider，也可以选择两个。
关闭 TUI 会停止团队吗？
不会。底层 tmux 会话会继续运行，除非明确停止。
资料来源
- OpenRig / README.md来源核查 2026-10-04
- OpenRig / docs/reference/getting-started.md来源核查 2026-10-04
- OpenRig / docs/reference/rig-spec.md来源核查 2026-10-04
- OpenRig / docs/reference/instance-layout.md来源核查 2026-10-04