你同时开着三个 Claude Code 终端和两个 Codex每个有自己的工作目录和上下文切窗口靠记性昨天那轮讨论出的结论今天找不回来谁先做规划、谁去审查、谁写代码全靠你在脑子里调度。OpenRig仓库 mvschwarz/openrig就是冲这件事来的它不碰模型能力只做多会话编排这一层。TypeScript 实现Apache 2.0主页 openrig.dev。核心概念三层抽象README 给的说法是harness 包住一个模型Claude Code、Codex CLI 都算rig 包住你的多个 harness被「当作一套系统」管理而lead agent是唯一对你收口的人——你去跟它说要什么结果它去协调跨团队的角色只把需要你拍板的事情带回来。团队编制写在 YAML 里一条命令启动。README 强调两个词持久与同一地址——团队的工作与上下文不随某个终端会话消失下次接着用。怎么装、怎么用前置条件是 Node.js 20 / 22 / 24加上 tmux。包走 npm名为openrig/cliREADME 给出的首次路径是npm install -g openrig/cli rig setup --dry-run也可以bun add -g openrig/cli但 README 提示即使这样装OpenRig 仍跑在 Node.js 上需要另装 Node 22且 Bun 可能拦截该包的 postinstall 脚本。这里有一句必须先说的README 明确写着启动一个 rig 会写入 provider hooks 与 workspace trust 设置并提示执行命令前先读「what OpenRig changes on your machine」一节、备份相关文件。这是上手成本不是可选提示。用法建议是从「一个仓库 一个有用的小改动」起步。CLI 子命令清单、YAML schema 字段、配置文件路径——本次素材里没有不编。架构暂无足够素材这点必须说清楚。本次两次第三方深度解析都没拿到内容deepwiki 的抓取被 Vercel Security Checkpoint 拦截返回验证页codewiki 返回 404。所以没有源码级的模块划分、调度算法、状态存储方式也没有 agent 间通信协议的任何结论。只能做有限推断依赖 Node tmux说明底层很可能用 tmux 会话承载 agent 进程并充当那个「稳定地址」README 提到注入 provider hooks说明它需要往上游 CLI 写配置来接管启动。以上是推断不是结论。生态位被显式点名的上游只有两个Claude CodeAnthropic和 Codex CLIOpenAI。这是一个跨厂商定位不绑单一模型供应商而单一厂商方案天然做不到这点。是否支持 Gemini CLI、Aider 或自建 harness素材里没说。热度是真的成熟度很低截至 2026-09-30 最近一次推送仓库创建于 2026-04-01半年周期拿到 2783 stars / 197 forks / 12 contributors / 115 open issues。fork 与 star 之比约 7%不高——更像是围观加试用而不是大规模二次开发。12 位贡献者要持续跟进两家上游 CLI 的变更维护带宽是结构性风险115 个 open issues 相对这个 star 量偏高。另外强依赖 tmux非类 Unix 平台大概率要绕。本次信源只有 README 和仓库元数据两类没有任何基准测试、生产案例、定价或融资信息。热度真实成熟度低属于值得盯、谨慎上生产的阶段。三个可验证的观察点一它是否接住 Claude Code / Codex 之外的 harness——这直接决定「控制面」这个说法能不能立住。二如果上游把多 agent 团队做进自家 CLI 并拒绝外部接管 hook这层独立编排器还剩多少空间。三README 里那句「会写入 provider hooks 与 workspace trust」会不会升级成可审计的安全文档以及这些 hook 在上游升级后能否持久可用——这一条决定它能不能上生产。结论适合已经在多开 AI 终端、并且愿意先读一遍它会改动什么再上手的人现在还不适合放进生产流程——没有基准测试、没有生产案例架构也未被第三方验证。