★ FEATURED ARTICLE OpenRig 三天登顶 GitHub 周榜Claude Code 与 Codex 第一次被编进同一支队伍【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig2026 年 10 月的第一周一个叫 OpenRig 的开源项目在 GitHub 周榜上异军突起。让开发者集体围观的不是又一个AI 编程助手而是一个把 Claude Code 和 Codex 塞进同一支队伍的编排框架——你可以用一份 YAML 定义出一个智能体团队Claude 负责实现Codex 负责审查Lead 负责派活重启之后整个团队还能按原样恢复。社区里流传的一句评论足以概括它的位置感Claude Code 和 Codex 组队干活了。本文结合社区一周内的真实反馈与仓库源码拆解 OpenRig 为何在此刻爆发、它用什么机制让两个不同厂商的编码智能体协同以及这股热度背后有哪些必须冷静看待的信号。OpenRig 是什么配置驱动多智能体编排框架官方定位一句话A harness wraps a model. A rig wraps your harnesses.harness 包装模型rig 包装你的 harnesses。OpenRig 不是又一个 Agent 实现它管理的是编码智能体们一起运行时形成的系统——哪些会话在跑、它们之间什么关系、重启后如何恢复、如何避免终端爆炸式蔓延terminal sprawl。从架构上看它是典型的本地优先设计一个 Hono HTTP daemon rigCLI TUI MCP server底层用 tmux 承载会话用 SQLite 持久化团队状态ARCHITECTURE.md。每个 Agent 都是未经修改的原生 Claude Code 或 Codex 会话OpenRig 只在其外围做协调启动与恢复、消息投递、持久化任务队列、按角色注入 skills 与上下文。packages/daemon/src/adapters/下的六个 RuntimeAdapterclaude-code、codex、pi、omp、terminal、stub就是这套代理层的边界。配置即拓扑一份 YAML 定义一支团队OpenRig 的核心抽象叫RigSpec——用 YAML 声明的多智能体编排定义包含 pods舱组、成员seats、edges协作边与 continuity 策略。看仓库里示范的最小团队demo/rig.yamlversion: 0.2 name: demo-rig culture_file: culture.md pods: - id: orch label: Orchestration members: - id: lead agent_ref: local:agents/lead runtime: claude-code - id: dev label: Development members: - id: impl runtime: claude-code - id: qa runtime: codex - id: design runtime: claude-code edges: - kind: can_observe from: qa to: impl - id: rev label: Review members: - id: r1 runtime: claude-code - id: r2 runtime: codex edges: - kind: delegates_to from: orch.lead to: dev.impl这份配置透露出三个关键设计进程即边界每个成员跑在独立的 tmux 会话里tmux list-sessions能看到orch-leaddemo-rig、dev-impldemo-rig这样的命名会话。Agent 之间不共享进程只通过rig send、rig broadcast、rig chatroom通信Seat 是稳定地址dev-buildstarter这样的 seat 是一个稳定的角色与地址占座的具体会话可以更换但身份与已产生的上下文不变——这是重启后按原址继续干活的基础运行时混合runtime字段直接声明该座位用 claude-code 还是 codex同一张拓扑图里两种 harness 并存。出厂自带的混编团队仓库自带三档开箱即用的团队starter/rig.yaml、factory/rig.yamlstarter一个 Claude Code 构建者 一个 Codex 审查者处理单次有界变更。build座位runtime: claude-codereview座位runtime: codex一条delegates_to边把构建结果交给审查workshoplead builder QA reviewer支撑单仓库持续工作factory七个座位——lead、advisor、build、QA、design、两个独立 reviewer。lead 与 QA 用 Codexbuild、design、reviewer 用 Claude Code边缘拓扑明确画出delegates_to与can_observe关系。甚至守护进程本身的kernel团队也是双运行时模板kernel/rig.yamladvisor 用 Claude Code 引导用户意图operator 与 queue worker 用 Codexescalates_to边把处理不了的问题上升给人类。这不是演示用的玩具配置而是 OpenRig 自举自身运营的真实拓扑。Agent 层面的混编更进一步implementer的默认运行时是 claude-code而qa的默认运行时是 codeximplementer/agent.yaml、qa/agent.yaml。QA 的角色引导文件明确写着验证者不得是作者——这种跨厂商互相审查的格局正是标题里编进同一支队伍的实义。为什么是现在Claude Code/Codex 普及后的组队刚需OpenRig 不是第一个多智能体框架——MetaGPT、CAMEL 这些AI 公司模拟器前两年就刷过屏。但那些框架是在框架内部实现 AgentOpenRig 的坐标完全不同它是为已经普及的两个终端编码智能体Claude Code 与 Codex做组队层。这个前提2024 年不存在2025 年底才开始成立。时机的三个支点其一终端编码智能体成了开发者日常。Claude Code 与 Codex 各自坐拥大量付费用户但它们是单兵武器一个终端会话解决一个任务任务一多就变成几十个 tmux 窗口的失控现场。CSDN 一篇安装实践帖总结的痛点非常典型状态碎片化、上下文共享缺失、任务协调困难。OpenRig 恰好把一堆终端会话变成一支有组织、可恢复的团队。其二异厂商协作有了真实需求。Claude 与 Codex 各有强项社区普遍反馈 Claude 长于长上下文重构Codex 在沙箱与自动化上更利落用户不想二选一。而把两家 CLI 塞进同一套编排涉及权限模型、会话恢复、hook 机制、信任配置的深度适配——这正是 OpenRig 投入最重的地方。源码里可见端倪Claude 用--permission-mode acceptEditsCodex 用-s workspace-writeOpenRig 分别写HOME/.claude.json与CODEX_HOME/config.toml并预写 trust hash。README 中what OpenRig changes on your machine一节的篇幅就是这门手艺的工作量证明。其三持久化与恢复被当成一等公民。Agent 跑长任务最怕中断。OpenRig 的rig down --snapshot/rig up name快照恢复、rig restore snapshotId --rig rigId显式恢复配合 demo 仓库里专门为native resume 语义差异建立的基线验证脚本demo/README.md把重启后团队还在原址做成了可验证的承诺。社区文章也普遍把快照恢复列为它的核心卖点之一。登顶周榜意味着什么三天登顶 GitHub 周榜说明触达的不只是多智能体研究爱好者而是正在被单兵 Agent 折磨的普通开发者。从社区情报能看出两个典型画像工具型用户CSDN 上最火的 OpenRig 内容不是原理而是《核心命令速查表89 个 CLI 命令按场景分类》《OPENRIG_HOME 实例布局图解》《环境准备清单》这类上手工具。rig setup --dry-run零副作用预览变更计划、rig up --plan只解析不执行、rig specs preview结构化预览团队构成这些安全落地设计降低了新用户的第一道门槛工程型用户安装攻略反复强调 Node.js 20/22/24 版本选择与 Apple Silicon 的 better-sqlite3 坑、tmux 依赖、Codex 登录认证——说明真有人在一台台真实机器上把它跑起来而不是只看 demo。一个值得注意的细节项目把 MCP 服务内置进了 CLIpackages/cli/src/mcp-server.ts里注册了rig_up、rig_down、rig_ps、rig_snapshot_create等 18 个工具。这意味着团队里的 Agent 自己就能管理自己的拓扑——rig_up启动团队、rig_ps查看状态、rig_send互相派活。当组队这个动作本身可以被队里的 Agent 执行OpenRig 就不仅是给开发者用的工具而是一个让 AI 团队自组织的基础设施。下图是 TUI 的拓扑视图可以看到七个座位被分组为 product、development、QA 等 pod项目的真实运转状态也佐证了这不是纸上框架demo/目录本身就是完整的多智能体拓扑规范示例demo/run-proof.sh会自动化产出从rig up到快照恢复的完整证据包packages/test-system/里跑着用 stub agent 驱动真实 CLI、daemon、tmux、SQLite 的场景库。README 里那张 10 秒的真实录制动图assets/readme/openrig-agents-working.gif展示的就是 build rig 从图到座位明细的完整运行态。必须警惕的降温信号热度来得快不代表基本面无忧。结合社区反馈与源码现状至少四个信号值得保持清醒1. 上手成本依然偏高。环境要求 Node.js 22/24、tmux、macOS/Linux原生不支持 WindowsApple Silicon 还必须用 Node 22 规避 better-sqlite3 预编译缺失。社区文章的标题清一色是避坑指南环境准备清单首跑实录——这仍是工具型早期采用者的入场券离开箱即用还有距离。rig setup会写~/.tmux.conf、安装 Herdr、配置两家厂商的 hook 与信任文件这些自动修改你的机器的动作对保守用户是一道心理门槛。2. 跨厂商适配是持续的运维负债。Claude Code 与 Codex 都是闭源 CLI版本更新不受 OpenRig 控制。demo 仓库自己都记录了Claude 与 Codex 的 native resume 语义不同fresh Claude 会话在rig up后不能立即快照安全这类运行时差异demo/README.md。每次厂商 CLI 大版本升级适配层、权限策略、hook 格式都可能需要重新对齐——这种负债在周榜热度消退后考验的是维护者的长期投入。3. 热度与成熟度之间存在时差。CSDN 上围绕 OpenRig 的高浏览量文章一部分如基于 Redis 的持久化编排实践描述的其实是另一个同名项目的设计——LangGraph FastAPI Redis 技术栈与本仓库Node.js SQLite tmux完全是两回事。这个细节本身就说明当前流量里混着大量搜关键词进来的泛多智能体好奇者真正的 OpenRig 用户占比需要打折。头部几篇教程的阅读量仍在数百量级与周榜登顶的声量存在明显落差——声量高、深度使用者少是开源热点的典型早期形态。4. 生态位正在被巨头挤压。就在 Claude Code 与 Codex 双双火热的当下官方托管的多智能体方案如 Claude Managed Agents也在快速补齐组队能力。OpenRig 的差异化在于开源、自托管、双运行时混合——这个定位有效的前提是开发者既不想被单一厂商绑定又愿意为本地化编排付出运维成本。一旦官方方案开放混编或托管成本足够低这个中间生态位的空间会显著收窄。结语OpenRig 登顶周榜本质上是一次需求信号当两个编码智能体各自足够好用之后开发者想要的下一件东西不是更强的单兵而是把它们编成一支队伍的编排层。它以 YAML 定义拓扑、以进程隔离边界、以快照保证恢复、以 MCP 让 Agent 自治——这套组合拳恰好打在 Claude Code 与 Codex 普及后的真实痛点上。但热度本身不构成护城河。跨厂商适配的运维负债、新手友好的缺口、以及官方托管方案的逼近都在周榜之后等着它。对读者而言OpenRig 值得现在就上手验证一个最小场景——跑一次rig setup --dry-runrig specs preview starter --kind rig看一份 YAML 如何把 Claude Code 和 Codex 编进同一支队伍至于要不要把整个团队的生产力押在它身上不妨先让这支混编队伍替你完成一次有界变更再说。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
)
