OpenRig 是什么：让多个编程 Agent 协作且可被人监督
OpenRig 后续方向：用试点数据决定是否扩大团队
把第一次 owner/checker 运行变成可核验的上线依据
OpenRig 后续方向：用试点数据决定是否扩大团队知识学习CN编辑简报更新 2026-10-04
你将学会
- 写一个小型试点约定
- 观察完整生命周期
- 确定扩张条件
开始前需要
- 支持的主机上安装 Node 22 或 24 与 tmux
- 一个可用 Provider 账号及可丢弃仓库
把第一次 owner/checker 运行变成可核验的上线依据
先看结论
- 可复现的拓扑仍需行为验证。
- 全新与继续的席位是不同恢复结果。
- 未来功能设想不是发布承诺。
写一个小型试点约定
选取可丢弃仓库、一个已经能用的 Provider 账号和有明确测试的任务。记录允许写入、禁止的外部行为，以及谁来核验结果。
RigSpec 与 AgentSpec 让团队配置可复现，却不等于行为已经验证。把确切配置版本与候选提交一起保存。
观察完整生命周期
预览配置和启动，记录配置文件前后差异，确认席位就绪，再发送有限任务、检查队列编号并复核具体候选。随后停止和恢复一次可丢弃团队。
成功与失败阶段都要保留，并记录失败发生的具体步骤。恢复后全新启动的节点应与继续原会话的节点分开报告。
确定扩张条件
只有当试点提升已接受成果，且没有让权限更不透明或返工更多时，才考虑增加席位。更多 Provider 或终端界面属于可能方向，不能从这些资料推断为官方承诺。
若后续完成真实试点，值得补一篇实测交接耗时、配置变化、Provider 用量和故障恢复的报告。在那之前，本系列只是基于固定资料的指南。
如何选择
| 比较维度 | 方案 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
只有实测改善质量和可见性才扩张。
可复制示例
text
试点约定 -> 计划 -> 双席位 -> 有限任务
具体复核 -> 快照/恢复 -> 扩张决定常见问题
一开始就建大型多 Pod 团队吗？
不建议。入门指南从小型 owner/checker 团队开始。
本系列还有什么未验证？
本机安装、Provider 登录、实际协作、性能及恢复。
资料来源
- 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/agent-spec.md来源核查 2026-10-04
- OpenRig / docs/reference/instance-layout.md来源核查 2026-10-04
- OpenRig / LICENSE来源核查 2026-10-04