OpenRig 是什么：让多个编程 Agent 协作且可被人监督
OpenRig 底层架构：RigSpec 如何变成 Agent 席位
从声明式配置跟到守护进程、tmux 与运行时适配器
OpenRig 底层架构：RigSpec 如何变成 Agent 席位知识学习CN编辑简报更新 2026-10-04
你将学会
- 编译团队声明
- 跟随一次启动请求
- 把显示与执行分开
开始前需要
- 支持的主机上安装 Node 22 或 24 与 tmux
- 一个可用 Provider 账号及可丢弃仓库
把第一次 owner/checker 运行变成可核验的上线依据
先看结论
- 声明式拓扑与实时就绪是两回事。
- SQLite 保存协调状态，tmux 承载终端。
- 查看器的生命周期不等于席位生命周期。
编译团队声明
RigSpec 描述 Pod、成员、关系边和连续性策略。AgentSpec 复用指导、技能、hooks、配置档案及启动契约；预览功能让操作者在启动前检查计划拓扑。
声明是配置，不保证账号登录成功或启动契约完成。启动后应把计划图与 `rig ps --nodes` 的真实状态逐项对照。
跟随一次启动请求
CLI 把 up 请求交给本地守护进程。后者通过领域服务协调状态，SQLite 保存协调信息，tmux 与运行时适配器承载真正的 Provider 进程。kernel 提供独立的运行支持。
即使占用席位的会话替换了，逻辑席位仍有稳定身份；这让检查者能继续找到同一职责，却不代表重启后的上下文完全一致。
把显示与执行分开
TUI 绘制席位图和表格；herdr 或 cmux 可排列终端，底层会话仍在 tmux。README 将旧 React Web UI 描述为维护模式。
界面异常时分别判断守护进程、tmux、运行时适配器和查看器。仅因查看窗口关闭就重启整个团队，可能造成重复工作。
如何选择
| 比较维度 | 方案 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
分别检查 RigSpec 与 AgentSpec。
- 2
比较预览拓扑和实际席位状态。
- 3
分层排查守护进程、tmux、运行时及查看器。
可复制示例
text
RigSpec + AgentSpec -> CLI 启动计划
CLI / MCP / TUI -> 守护进程 -> SQLite
守护进程 -> tmux 席位 -> Provider 运行时常见问题
TUI 就是 Agent 运行时吗？
不是。它展示状态，实际会话由 tmux 与运行时适配器承载。
固定席位就是不变的对话吗？
不是。席位的职责可以保留，占用它的会话却可能变化。
资料来源
- OpenRig / README.md来源核查 2026-10-04
- OpenRig / docs/reference/rig-spec.md来源核查 2026-10-04
- OpenRig / docs/reference/agent-spec.md来源核查 2026-10-04
- OpenRig / packages/cli/src/commands/up.ts来源核查 2026-10-04
- OpenRig / docs/reference/instance-layout.md来源核查 2026-10-04