OpenRig Software Factory配方详解用rig grow持续扩展团队的完整实战指南【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一款多智能体协作框架multi-agent harness把 Claude Code 和 Codex 编入同一个软件工厂Software Factory团队统一管理。本文将详解官方内置的 Software Factory 配方如何从 2 人小队起步用一条rig grow命令持续扩展团队并让每个任务都经过独立审查。1. 什么是 Software Factory 配方很多新手用 AI 编程工具时的困境是开一个会话写一段代码换个任务再开一个会话——会话之间互不相识上下文越堆越乱。OpenRig 的思路完全不同它管理的不是单个智能体而是智能体组成的团队。团队被定义在 YAML 文件里称为 RigSpec一条rig up命令整体启动之后你可以像管理真实项目组一样管理它——加人、派活、交接、扩编、裁撤。仓库内置的openrig-software-factory技能就是这条从仓库变更到持续团队的配方核心思想只有一句话从一个有用的仓库结果开始协调机制要等它值回票价时才逐步加码。配方把协作深度分成三档你可以按需选择而不是被迫逐级升级需求起步方式什么时候加码一次变更、人工密切指导手动派活给 owner 一个结果实现后找独立 checker 审查工作需要跨回合存续、在座位之间流动时持续工作、归属可见队列编排rig queue create→ 认领 →rig queue handoff重复步骤需要显式依赖图和出口时显式执行契约Workflowrig workflow compileinstantiate-lifecycle项目需要可复用画像、更多角色或关卡时完整的配方文档位于 openrig-software-factory/SKILL.md配套的 CSV 校验实战案例在 references/worked-example.md。2. 起步两个座位就是一座工厂入口 配方推荐的第一站是官方内置的first-project起始 rig——两个座位分工明确dev-ownerowner负责实现和协调dev-checkchecker独立审查不算自己查自己在你自己的仓库里启动rig up first-project --cwd .这个owner 独立检查者的最小组合就是软件工厂的胚胎owner 带着候选结果走过独立审查把如何验证它的说明交给你。两个座位是入口不是上限——这正是rig grow登场的地方。上图是 OpenRig 的 TUI 拓扑视图每个座位seat都有稳定地址如dev-ownerfirst-project。你可以在 UI 的 Explorer 中点击 rig 查看团队结构再点击座位旁的CMUX按钮直接在终端里看到真实会话3. rig grow一条命令给运行中的团队加人当工作量超出两个座位的承载——比如出现可以并行推进的独立任务——配方建议的下一步不是推倒重来而是给运行中的 rig 直接加座位rig grow $RIG_ID a b --pod dev --runtime codex --cwd $PROJECT_ROOT这条命令会在运行中的 rig 里创建新座位本例为dev.a、dev.b地址是dev-afirst-project、dev-bfirst-project自动启动这两个座位无需重建、无需 down/up 循环已有会话原样保留解析内置的通用orchestrator智能体规格作为新座位的默认配置几个实战要点来自 worked-example.md 的Grow the running team一节加一个座位就只写一个名字rig grow $RIG_ID a --pod dev即可想放进全新 pod改用--new-pod build座位会命名为build.a、build.b两个参数互斥新座位不会继承 owner 的对话和任务加座位 ≠ 派活你需要显式用rig send送达上下文、用rig queue create派发任务加完先体检rig ps --nodes --rig first-project --json检查每个节点的状态和原生 pane已创建不等于已就绪想换完全不同的团队结构走 OpenRig Architect 路径rig context get skills/core/openrig-architect/SKILL.md编写自定义 RigSpec扩编后的职责分工建议明确写进项目工作约定例如座位刻意约定的职责dev-owner最初实现协调可演进为专职编排者选结果、拆任务、拥有集成交付dev-a/dev-b各自实现互不重叠的授权任务返回精确候选和证据不越界改对方的文件dev-check保持独立判断力实现者不能把自己的自检当作独立审查⚠️ 注意并行的前提是输入和编辑可以独立推进用互不重叠的文件或独立 worktree并指定一个集成负责人。共享文件、串行依赖和审查瓶颈会抵消一切加速收益而且更多活跃座位意味着更多 token 消耗——扩编前请先和用户约定时间/预算上限。4. 扩编之后把团队形状存下来rig grow会把新拓扑持久化到运行实例的数据库中但不会改写你手写的rig.yaml。想把扩编后的形状保存成文件用导出rig export $RIG_ID -o .openrig/factory/first-project-expanded.yaml然后检查导出内容、与你自己维护的 RigSpec 对账保留原有的 culture/启动/上下文设置再用rig spec validate path --json校验。切记从旧的手写规格打的 bundle 会漏掉新增座位扩编之前拍的快照无法恢复新座位不要为了保存定义就停掉、重建正在运行的 rig5. 收缩rig remove 与 rig shrink ️扩编有rig grow裁撤同样是一等公民rig remove $RIG_ID dev.a—— 移除单个座位rig shrink $RIG_ID build—— 移除整个 pod裁撤会结束受影响的会话如果座位上有活跃工作移除会被拒绝除非你显式指定一个--fallback live-seat接手。配方特别提醒先保存工作和下一任归属再裁撤不要用 fallback 丢弃义务也不要仅仅因为座位看起来空闲就移除它。6. 延伸阅读从配方到完整团队配方主文档skills/_canonical/core/openrig-software-factory/SKILL.mdCSV 校验完整实战含队列循环与 Workflow 契约references/worked-example.md官方演示拓扑4 个 pod、8 个节点含 lead/impl/qa/design/reviewerdemo/rig.yaml、demo/README.md起始 rig 一览first-project、conveyor、product-team等README.md写在最后OpenRig Software Factory 配方的精髓可以浓缩成三步小起步owner checker 两座位完成第一个经审查的变更按需扩出现真实独立工作流rig grow一条命令加人不折腾现有会话存形状rig export保存扩编后的拓扑裁撤时用rig remove/rig shrink有序退场团队大小和协作深度是两条独立的决策线——先用最轻的方式拿到经审查的结果再让团队随工作自然长大。这正是一座真正持续扩展的软件工厂该有的样子。【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考