OpenRig 冲上 Trending：把 Claude Code 和 Codex 编成一支队伍

OpenRig 想处理一个很具体的协作问题：当 Claude Code、Codex 和其他编码 Agent 同时在一个仓库里工作时，任务交给谁、谁在检查、上下文存在哪里，以及中断后怎么接上，不该只靠开着的几个终端窗口和人的记忆。

它今天出现在 GitHub Trending，榜单当时给出的窗口信号是 +622 stars today。这不是累计增量的推算；仓库当前累计约有 2,950 stars 与 203 forks。GitHub Trending 与仓库页是两组数字的复核入口。对经常让不同 Agent 分头写代码、审代码的人来说，OpenRig 的看点不在“再多一个 Agent”，而在于它试图把协作过程做成可查看、可恢复、也可以追责的一套运行结构。

我会借项目的 README、发布说明和随包 Skill，梳理它究竟把哪些事情统一起来，以及第一次试之前必须看清的权限边界。期望对大家有所帮助。

不是多个窗口，而是一套有地址的团队

OpenRig 对自己的描述是：harness 包住一个模型，rig 再包住多个 harness。它的团队定义写在 YAML 中，启动后每个成员是一个 seat。seat 既有运行时身份，也有工作目录、当前状态和可以恢复的上下文；团队还可以有 owner、checker 这样的角色。

最小的入门配置不要求同时购买两种服务。项目给了三种 starter：两个 Codex、两个 Claude Code，或由 Claude 负责实现、Codex 负责检查的混合组。典型路径是先启动 rig，确认 seat 就绪，再把一个范围明确的修改交给 owner，最后让 checker 审查同一个候选改动。

一个仓库与一个目标
        ↓
owner seat：理解、实现、记录任务
        ↓
queue：保存任务地址和交接状态
        ↓
checker seat：检查同一份候选改动
        ↓
可回到原 owner 的结果与待决事项

这个结构有个朴素但重要的约束：发送一条消息不自动等于创建任务。README 要求 owner 自己把任务记录进队列，再由人用 rig queue list 查看。这样做看上去比“让 Agent 自由互相喊话”多了一步，却给交接留下了可读的状态。Agent 断线、上下文压缩或人隔天回来时，仍有一个能定位的任务记录。

项目随包的 delegating-work Skill 也把这个选择讲得很直接：先问一件事需要多少既有上下文才能正确完成。需要大量上下文的工作，应交给已经持有它的团队成员；题目足够独立、能用提示完整说明的部分，才适合新开的 subagent。它不是一个调度算法，却是对多 Agent 协作里最常见误差的提醒 - “看起来完成了”的结论，可能只是因为接手者不知道漏了什么。

热度来自一轮密集的可核实更新

OpenRig 创建于 4 月 1 日，并非当天出现的仓库。它在这轮 Trending 中变得值得观察，是因为增长信号旁边还有连续的产品变化。

GitHub 的开发者趋势榜当天把作者 Mike Schwarz 列在第一位，热门仓库正是 OpenRig。Schwarz 的 GitHub 资料标注其公司为 Esoteric Labs，个人简介则写明他在构建长期运行的 Agent 团队。这只能说明项目作者和社区注意力的关联，不能代替技术判断；真正可核实的是最近两天的 release 与提交。

9 月 30 日较早发布的 v0.6.2 把首次项目流程、恢复诊断、混合 Claude/Codex 团队共享 Skill 的投放，以及避免把消息误输入裸 shell 的检查放进版本。随后 v0.6.3 修复了一项很贴近实际的回归：托管启动的 Claude Code seat 带显式 permission mode 时，rig send 曾把外层 shell 误认成没有 Agent 的终端而拒绝投递。

同日提交还包括 Codex 在非 OpenAI provider 下的就绪状态识别、快照 helper 清理，以及重复或归档 rig 的 seat 解析修复。这些不是新功能的广告词，而是在说明一个现实：当系统要向运行中的终端 Agent 写入消息、跨重启找回状态、又不能误操作别的会话时，边界条件本身就是产品的一部分。

它把权限当作团队运行的一部分

多 Agent 工具最容易被忽略的部分，往往不是“能不能启动”，而是它为了启动到底会修改什么。OpenRig 的 README 单独列了这一项，而且写得相当具体：rig setup 可能修改 tmux 配置；daemon 会创建自己的状态与数据库；启动时会写 Claude Code 或 Codex 的 hook、信任记录和工作区配置。选中的 MCP 资源也可能进入相关设置。

对 Codex，项目描述的默认受控启动是 workspace-write sandbox，并写入自己的 activity relay hook 与工作区 trust。更宽的 full_bypass 是独立的、被审计的选择，而非系统悄悄给出的默认值。它也强调了一点常被混淆的事实：状态输出和启动参数可以表明“计划以什么权限启动”，却不等于已经证明原生运行时的权限真的生效。

flowchart LR
  A[人选择团队与权限] --> B[OpenRig spec]
  B --> C[Claude Code / Codex seat]
  C --> D[任务队列与交接]
  C --> E[hook 与状态回传]
  D --> F[检查与可恢复记录]

这也是 applying-a-permission-policy Skill 最有价值的地方。它要求先区分命令白名单、sandbox、审批策略和工作指导，不能把其中一个当成另一个；修改前应读取已有规则、准备最小 diff、备份、再用无破坏性的读取命令验证。允许 rig 命令族，也不等于授权 Agent 自己决定新任务、发布内容或扩大网络权限。

这个边界让 OpenRig 更像是一个本地“团队控制面”，而不是云端托管 Agent 平台的替代品。你仍需要自己的 Claude 或 Codex 账户，也仍承担模型调用成本和工作区中的实际副作用。

先用一件小事验证它

第一次尝试最适合的不是把十个 Agent 接进生产分支，而是一个可复核的小改动：在隔离仓库里让 owner 修一个有测试覆盖的 bug，再让 checker 只审同一个提交或 worktree。开始前确认 Node.js 版本、tmux、选定的 provider 登录状态，以及当前工作区里是否已有会冲突的 hook、MCP 或 trust 设置。

还应先读清楚项目的限制。README 当前要求 Node.js 22 或 24，支持 macOS 与 Linux，原生 Windows 尚不支持。v0.6.0 中的 Slack app manifest/setup 辅助与 stream classifier 仍标为 experimental；权限模式的实际原生执行效果也要求在启动后的会话里再次检查。不要因为工具能把多个模型排成队，就把它当成无人值守的生产授权系统。

OpenRig 的趋势值得关注，是因为它把多 Agent 协作里原本散落在 tmux、提示词、临时消息和个人记忆里的东西，收成了角色、队列、状态与权限选择。对需要在 Claude Code 和 Codex 之间分工的团队，先把一条小流程跑通，比先扩张成员数量更有意义。

---

• 仓库：mvschwarz/openrig
• 入门指南：OpenRig Getting Started