mvschwarz/openrig

如果你已经在同时跑两个以上编码 Agent，并且花大量时间在终端之间搬运上下文，OpenRig 值得一试；如果你只需要一个窗口里一个助手，可以直接跳过。

解决什么问题

你想做一个横跨后端、测试和前端的功能，于是在几个终端里分别打开 Claude Code 和 Codex。几个会话彼此不知道对方做了什么决定，你得手工粘贴背景，忘了哪个窗口负责迁移脚本，机器重启后也拼不回谁在做什么。OpenRig 把工作单位从终端会话改成声明式的 rig：你在 YAML 里描述 pod、角色和延续策略，一条命令启动，然后对 lead agent 说要什么结果，由它把活派给不同专长的 Agent。换来的是一个跨会话持久的团队，上下文和任务归属都留在固定位置。

有什么不同

OpenRig 是“harness 的 harness”，不是又一个 Agent。它以本地 daemon 加 CLI、TUI 和 MCP server 的形态运行，底层是 SQLite 和 tmux，原生支持 Claude Code 和 Codex 会话，并通过 RPC runner 接入 Pi。用 tmux 做传输层的实际意义在于：已有的 Agent 会话变成拓扑里的一个个座位，daemon 可以检查、发消息，并在重启后恢复，而不是靠人记住哪些进程还在跑。Agent 还能通过 rig_up、rig_ps、rig_send 这类 MCP 工具查询和改动自己的拓扑，这正是 lead 加专才的架构能运转、而不需要人逐条转达消息的原因。

代价是你引入了一个有实际足迹的运行时层。安装会写入 provider 信任设置、可执行 hook 和工作区状态，项目明确要求你在 setup 或托管启动前先看它会在机器上改什么。拓扑配置本身也是要学习和维护的东西：有 pod、连线和延续策略的 rig，对真正有可分工角色的团队才有回报，只想多开几个标签页的人会觉得多余。README 还说明旧的 React Web UI 已进入维护模式，所以该评估的界面是 CLI/TUI/MCP，而不是浏览器视图。

谁值得试

适合已经在用两个以上 Agent、并且分工可重复的开发者：一个实现者、一个 QA 座位、一个跑对抗式 review 的座位（一个 Claude 加一个 Codex），或者一个负责派活的 lead。作者在 Show HN 回复里描述的正是这种日常配置，其中提到最长连续运行约四天的 rig，用于执行一份较大的实现规格。如果你想让 Agent 自己管理团队、而不是你手动驱动每次交接，MCP 那部分也有吸引力。

不适合只想在一个项目里用一个助手的独立开发者，也不适合不愿让 daemon 和 tmux 接管 Agent 会话的人。如果只是偶尔派一个任务，YAML 拓扑、座位概念和恢复模型带来的仪式感远大于收益。

使用条件与边界

需要 Node.js 22 或 24（Apple 芯片上要用 22，见兼容性说明）、tmux，以及 macOS 或 Linux；Windows 只支持 WSL2，项目说明其自动化测试还没有在 WSL2 上跑，并给出了一位用户可用的配置。开始阶段有一个已登录的 provider 就够。setup 会安装缺失的 Claude Code 或 Codex、写入 tmux 默认值，并在 macOS 和 Linux 上默认装 Herdr，除非传 --no-herdr。

安装本身不算难点：rig setup --dry-run 可以先看计划，手动安装路径也有文档。真正要花精力的是日常维护。provider 登录检查与 setup 共用逻辑，而且按 README 的说法并不能证明 Agent 真的能工作，你仍需用 rig ps --nodes 查看运行中的节点；机器变更后用 rig doctor 排查。版本也要盯住，因为仓库里的说明可能领先于 npm 上已发布的包。

HotRepo 点评

HotRepo 从 2026-05-10 开始追踪 OpenRig；它上过 7 次日榜，在 2026-09-27 至 2026-10-03 之间每个有记录的日子涨 114 到 781 star，并在 2026-10-27 的 TypeScript 月榜排第 17，当月 +7,695。这些是榜单采样，不是连续序列，因此无法据此判断记录日期之后能否持续。对应的 Show HN 帖只有 8 分、5 条评论（帖子），讨论热度说明不了什么。决定采用前，拿“OpenRig 会改什么”表格对照你现有 Agent 配置依赖的信任设置和 hook 检查一遍。