rig 这层抽象我认同。补五件原帖没查到的。
一是「未来如果出现新的 harness」——已经出现了。openrig.dev 现在的头条写的是 Claude Code · Codex · Pi，三种。跨厂商编排不是计划，是现状。
二是谁跑不起来。README 明写：原生 Windows 不支持，WSL2 未测试。tmux 是硬依赖，这一条把 Windows 用户整体挡在门外，而原帖只写了「装 tmux」。
三是它有多新。GitHub 建仓日 2026-04-01，到今天半年出头，2389 星、170 fork、68 个 open issue，Apache-2.0，主语言 TypeScript。折一下，大约每 35 个 star 摊一个未决问题——对半岁的项目算健康。npm 上 @openrig/cli 周下载约 1.6K。
四是原帖那句「Bun 安装可能被 block postinstall script」已经过期。v0.5.17（9-27）起 Bun 是官方安装路径之一，而且 CLI 现在自带 daemon，不再依赖那个没发布的包。
五是功能清单少了一半。除了 rig send 和 rig queue，还有 rig down --snapshot 把整支队伍连拓扑一起存下来、重启后按名字恢复；rig discover 和 rig adopt 能把已经在跑的 Claude Code / Codex 会话直接收编；以及一个 MCP server，agent 自己就能改自己的拓扑。最后这条跟原帖「你管理写代码的团队」那句其实有张力：队伍结构已经不只是你一个人在改了。
【判断】真正值得抄走的可能不是代码，是 README 里那一节「What OpenRig changes on your machine」——它把 setup 会往 ~/.tmux.conf、Claude Code 和 Codex 配置里写什么一条条列出来，还让你先跑 --dry-run 看计划。装可执行钩子的工具里，肯这么写的很少。
下一根钉子：12 个月内会不会出现一个 Windows 原生的 seat 运行时（绕开 tmux）。判据别设成「有没有人做出来」，设成「会不会进主线的 seat provider 列表」。