📌 项目地址：mvschwarz/openrig | ⭐ 803 颗星 | 🔧 TypeScript | 📜 未标注
它解决什么问题
README 第一句话就把定位讲清楚了：harness 包裹模型，rig 包裹 harness。Claude Code 和 Codex 这类工具管理单个模型，OpenRig 管理这些工具本身。
具体痛点是这样的：你同时跑多个 AI coding agent，桌面上就是一堆终端窗口。谁在干什么、上下文存在哪，全靠自己记。OpenRig 的做法是让你在 YAML 里定义一支 agent 团队，一条命令启动，之后跟 lead agent 说你想要的结果，由它去协调各团队的 specialist，把成果和需要你拍板的事项带回来。团队的工作产物和上下文放在固定地址，查看用的终端关掉了，团队还在跑。
我觉得这个思路和大多数多 agent 编排框架不一样。那些框架一般在 API 层做抽象，OpenRig 不替代 Claude Code 或 Codex，而是把它们当作 rig 里的席位统一调度，底层靠 tmux 维持持久会话。你原有的 harness 认证和权限照常生效，不存在绕开重造一套的问题。已经在用这两个工具的人，要学的只有 rig 自己的概念。
上手流程
前置条件：Node.js 20/22/24、tmux、已认证的 Codex。安装后别急着跑，先看 setup 打算干什么：
npm install -g @openrig/cli
rig setup --dry-run
--dry-run 列出 setup 的完整计划，它会检查原生 harness 和 cmux。审查完再执行 rig setup。这个 starter 必须有 tmux 和已认证的 Codex，另一个 harness 和终端 provider 是可选项。
启动前在 shell 里确认环境：
tmux -V
codex --version
codex login status
缺工具或没登录就先解决。然后进仓库，先看计划再启动：
cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared
这个 starter 启动两个 Codex 席位：一个 owner，一个 checker。rig tui --shared 打开共享仪表盘，按 Ctrl-b 再按 d 可以分离视图而不停掉 dashboard，之后随时用同一条命令回去。rig tui 则打开独立视图。
派活之前，用 rig ps --nodes --rig first-project 检查席位是否就绪，把认证、信任、权限方面的提示都解决掉。然后给 owner 一个有边界的任务：
rig send dev-owner@first-project 'Implement ...
README 给的指令模式值得照抄：让 owner 在队列里跟踪任务并返回任务 ID、改动保持本地、验证行为，再请 dev-check@first-project 检查确切的候选结果。这套流程的核心是一个有边界的目标加一条验收链，而不是丢一句模糊的大话过去。
三个要留意的坑
它会改你机器上的文件。 启动 rig 会写入 provider hooks 和 workspace trust 设置。README 明确要求先读 “what OpenRig changes on your machine” 一节并备份相关文件，这步别跳。
权限要先配置。 README 建议启动前让 agent 配置好权限策略：保留提示、记住选定命令，或者主动选更宽的访问范围。配置和验证由 agent 完成，OpenRig 自带的默认值不变。
Bun 安装有坑。 bun add -g @openrig/cli 可行，但 Bun 可能拦截 postinstall 脚本，导致 Node.js 和 SQLite 检查不在安装时运行。OpenRig 实际还是跑在 Node.js 上，用 Bun 装也得装 Node.js 22。
我的建议
803 star，项目还在早期。第一次跑选个不重要的仓库，先走完 --dry-run 和 --plan 这两步审查，确认它要写什么文件再放手。