OpenRig 是什么：让多个编程 Agent 协作且可被人监督
读 OpenRig 源码：`up`、`send` 与任务队列
用三个 CLI 入口分清启动、通信和任务归属
读 OpenRig 源码：`up`、`send` 与任务队列知识学习CN编辑简报更新 2026-10-04
你将学会
- 先读启动路径
- 跟随一条消息
- 核对 setup 副作用
开始前需要
- 支持的主机上安装 Node 22 或 24 与 tmux
- 一个可用 Provider 账号及可丢弃仓库
把第一次 owner/checker 运行变成可核验的上线依据
先看结论
- CLI 接受命令不等于席位就绪。
- 消息与队列记录有不同用途。
- setup 与 up 的副作用范围不同。
先读启动路径
`packages/cli/src/commands/up.ts` 解析来源，提供 `--plan`，在本地或远端操作之间选择，并处理恢复计划预览。它会拒绝把主机拓扑文件当成 rig 配置。
CLI 分支解释了用户能看到的决策和错误。要证明席位真正启动，还需跟踪守护进程结果并检查节点状态；参数解析成功不是运行保证。
跟随一条消息
`send.ts` 解析目标地址、请求守护进程并报告投递或错误。明确的席位地址便于核对消息究竟发给哪个 rig 的哪个职责。
投递不等于任务完成。README 明确指出 send 不会创建队列条目；应另看 `queue.ts` 的归属、状态与读取逻辑，不能把聊天消息当成工作账本。
核对 setup 副作用
`setup.ts` 组织机器环境准备，`up.ts` 则负责启动团队，两者改动范围不同。在主要工作站运行之前，要把实现与 README 的机器改动表对照。
这次审阅只读取固定版本的文件，没有运行守护进程或 Provider，也没有穷尽大型 CLI 包的全部错误分支。
如何选择
| 比较维度 | 方案 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
追踪一次 `up --plan` 到守护进程请求。
- 2
对比 send 投递与队列任务归属。
- 3
执行真实启动前先列出 setup 写入。
可复制示例
text
up.ts -> 启动计划 -> 守护进程 -> 席位状态
send.ts -> 目标地址 -> 消息投递
queue.ts -> 所有者 -> 可追踪任务常见问题
`rig send` 会创建任务 ID 吗？
不会。接收者需要在队列里登记。
这篇文章运行了这些源码吗？
没有，只审阅固定版本 CLI 文件与文档。
资料来源
- OpenRig / packages/cli/src/commands/up.ts来源核查 2026-10-04
- OpenRig / packages/cli/src/commands/send.ts来源核查 2026-10-04
- OpenRig / packages/cli/src/commands/queue.ts来源核查 2026-10-04
- OpenRig / packages/cli/src/commands/setup.ts来源核查 2026-10-04
- OpenRig / README.md来源核查 2026-10-04