企业官网建设流程全解析

OpenRig 周榜第一是 Star 通胀，还是真需求？我站后者，但有个前提

【免费下载链接】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

过去一周，OpenRig 在 GitHub Trending 的周榜上冲到了第一。随之而来的是一轮熟悉的争论：有人把它归为"Star 通胀"——一个 0.x 版本的项目、一堆中文教程、一周内陡增的关注，怎么看都像社区运作的产物；也有人认定这是多智能体编排进入实用期的信号。这篇文章不打算站队，而是用仓库源码和社区事实做一次证伪：Star 数量能说明什么、不能说明什么，以及"Claude Code + Codex 组队"这件事为什么值得认真对待。

Star 通胀论的论据，与它站不住脚的地方

怀疑者的论据并不全是臆测：OpenRig 目前仍是 0.6.x 的预发布版本，官方自述是"AI 文明实验背后的开源系统"，项目起步于个人开发者，且社区里大量内容是教程型文章——从安装踩坑、rig setup --dry-run预演到 89 个 CLI 命令速查，密集得像是有人在刻意铺量。

但把"教程多"当成 Star 注水，恰恰忽略了这些内容说明的另一件事：上手门槛真实存在，而且真的有人在逐个击破它。Node.js 22/24 版本限制、tmux 依赖、Claude/Codex 双登录认证、Apple Silicon 上 better-sqlite3 的坑——这些教程不是凭空编造的营销稿，它们记录的每一步都是可复现的工程事实。

真正能检验 Star 成色的，是源码本身。几个硬指标：

• 数据库层有 98 个顺序迁移（packages/daemon/src/db/migrations），从会话绑定、快照、队列状态机一路演进到工作流并行与权限策略，这不是靠一个周末"生成"出来的代码量；
• CLI 命令面超过 89 个，覆盖环境诊断、团队生命周期、快照恢复、跨主机操作（packages/cli/src/commands）；
• 测试文件规模与领域逻辑相当，daemon 侧 domain 目录下数百个服务模块均配有对应测试，UI 与 TUI 各自维护独立的测试套件；
• CHANGELOG.md 中 0.6.8 的发布说明写得直白："mostly fixes, most of them from the community"——一个靠刷 Star 维持热度的项目，不会把社区提的 bug 修复作为版本主题反复发布。

换句话说：Star 曲线可以注水，但 98 个迁移和一份"修复大多来自社区"的变更日志注不了水。通胀论最大的漏洞在于，它把"传播热度"和"工程密度"混为一谈——前者可以买，后者买不出来。

为什么『Claude Code + Codex 组队』是真需求

这一轮 AI 编程工具竞争已经把单 Agent 的能力卷到了相当高度，真正的真空地带不在"一个模型多强"，而在两个最强 harness 之间怎么协作。大多数开发者手里既有 Claude Code 又有 Codex 账号，却只能各开各的终端、各记各的上下文、各答各的 prompt——所谓"组队"停留在人肉切换的阶段。

OpenRig 对这个痛点的回答体现在仓库里每一个核心文件上。以默认团队 starter 为例（packages/daemon/specs/rigs/launch/starter/rig.yaml）：

pods: - id: dev label: Project members: - id: build runtime: claude-code profile: default - id: review runtime: codex model: gpt-6-astra profile: default edges: - kind: delegates_to from: build to: review

一份 YAML 同时声明两种运行时、两种模型、一条委派边——Claude Code 写实现，Codex 做审查。同样的模式在 kernel（双运行时常驻团队）、factory（七座席：lead、advisor、build、QA、design 与两名独立审查）中反复出现，demo/rig.yaml 里还展示了can_observe、collaborates_with、escalates_to等更细的协作语义。

这背后是一套刻意为之的架构（README 中的 How It Works 一节给出了全景）：CLI/TUI/MCP 之上是 Hono HTTP daemon，往下是领域服务与 SQLite + tmux + 运行时适配器。每个 Agent 跑在独立的 tmux 会话里，你可以随时 attach 进去看它到底在干什么——协作不发生在黑箱里，发生在你能看到的终端里。daemon 通过 MCP 工具（rig_up、rig_ps、rig_send）让 Agent 能自己管理拓扑，这解决了多 Agent 系统的经典困境：谁来编排编排者？

社区情报也在印证同一件事。头条上三篇文章的标题分别是"Claude Code 和 Codex 组队干活：openrig 上手记与三个坑""OpenRig Agent编排神器，让Claude Code和Codex编成一支AI战队""把 Claude Code 和 Codex 放进同一套多智能体框架"——独立作者不约而同把"双运行时组队"当作核心卖点，说明这不是项目方自嗨，而是用户拿到手后第一眼看到的价值。

值得注意的还有官方与 Claude Managed Agents 的对比定位：OpenRig 选择开源、自托管、双运行时同队，模型用量费用照常走各自账号。在"托管式 Agent 团队"与"纯手工终端堆叠"之间，它占据了一个此前几乎空白的生态位。

增速放缓的三种可能解释

周榜第一之后，另一种声音开始出现：热度是不是已经开始退了？对这个观察，源码和社区数据能给出三种互不排斥的解释。

解释一：门槛陡峭期进入"消化期"。安装链路要求 Node 22/24、tmux、双 provider 登录，还涉及写入~/.claude/settings.json、~/.codex/config.toml和 tmux 配置等敏感改动。CSDN 上"环境准备清单""Apple Silicon 避坑""首跑实录"这类教程恰好是门槛的镜像——热度曲线趋缓，可能只是新用户从"围观"转入"安装 + 排障"阶段，而这一阶段恰恰不出现在 Star 数字里。

解释二：注意力被模型发布周期分流。多智能体框架的热度本质上依附于底层模型的能力跃迁，新模型发布窗口会显著抢占开发者注意力。对于 0.x 的编排类项目，短期 star 波动与其说反映项目质量，不如说反映"此刻谁的模型在刷屏"。

解释三：真实用户进入使用期。这是最值得留意的信号：从 CHANGELOG 看，0.6.8 和 0.6.9 的修复密集来自 Slack 频道和 issue 反馈——Slack 断连检测、跨主机 send 的送达不确定性、恢复后 kernel 就绪判定。一个项目从"被 star"转向"被使用"，体现为 issue 质量和迭代节奏，而不是 star 斜率。

三种解释的区分其实可以量化：去看 daemon 重启后的快照恢复使用、queue 中的真实任务记录、以及社区从"教程"向"踩坑复盘"的内容迁移——后者（比如头条那篇"上手记与三个坑"）只有真正跑过的人写得出来。

给跟风者的判断框架

最后落到实操。无论你是想跟进还是想质疑，以下五个检查点都能帮你在十分钟内独立判断，而不是跟着榜单情绪走：

1. 不看 star，看迁移与测试。打开 packages/daemon/src/db/migrations，数一数迁移数量；再看 daemon 测试目录的规模。工程密度是 Star 无法伪造的部分。
2. 跑一次rig setup --dry-run。这个命令零副作用地输出全部变更计划与目标文件路径。一个敢于在动手前把"我要改你机器上的哪些文件"明明白白列出来的项目，默认是尊重用户的；反之则要警惕。
3. 用 starter 走一次真实的 review 循环。给 build 座席一个真实仓库里的 bounded change，让它交付后由 review 座席（Codex）审查，再回读rig queue list与审查记录。重点不是它是否成功，而是失败时你是否能看清失败在哪一层——这是编排框架与玩具 demo 的分水岭。
4. 检查 fail-closed 设计。README 反复强调：YOLO 默认关闭，权限策略默认不写全局放行，跨主机 send 在送达不确定时报告remote-outcome-unknown而不是假装成功。安全语义上的"响亮失败"，是多 Agent 系统成熟度的硬指标。
5. 对号入座你的场景。如果你只维护单 Agent、单会话的短期任务，OpenRig 的 star 涨跌与你无关；如果你在真实仓库里做长期迭代、需要多人多角色持续协作，那么"同一个仓库里 Claude Code 和 Codex 各司其职、状态可快照可恢复"这件事，本身就是需求成立的证据。

回到标题的问题：我站"真需求"这一侧，但有一个前提——前提是你把它当作基础设施而不是热点。Star 通胀论的错误在于用传播指标否定工程事实，而盲目追捧的错误在于把编排框架当成模型能力的替代品。OpenRig 解决的从来不是"让 Agent 更聪明"，而是"让一堆聪明的 Agent 不再是一堆散落的终端"。这个需求在 Claude Code 和 Codex 并存的现实里真实存在，而它能否持续兑现，取决于 98 个迁移之后还有没有第 99、第 100 个——以及那些从"上手记"写到"三个坑"的社区用户，会不会继续留下来。

【免费下载链接】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