人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】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点击查看免费下载导读factory-rsi是 OpenRig 在 0.4.6OPR.0.4.6.FAC2交付的单 Rig 递归自我改进Recursive Self-ImprovementRSI工厂 MVP一个 Rig 一个 workflow用七个 Seat 一一对应factory-rsi工作流的七个角色把计划 → 实现 → 检查 → 评审 → 发布这条有界内循环完全交给引擎路由同时把持续使用已发布产品并反馈进下一轮计划的 dogfood 反馈边解耦到带外运行。本文以 CULTURE.md 为骨架结合 rig.yaml、factory-rsi.yaml 工作流规格、两个专属 Agent 角色文档与对应测试完整讲解该 Rig 的循环架构、七个 Seat 的职责与运行时分配、可落地部署方式以及引擎层如何保证循环有界、确定性、可人工放行。读完你可以直接在自己的仓库上rig up factory-rsi跑通一个无需人工值守的自我改进闭环。一、factory-rsi 是什么单 Rig 的 RSI 工厂factory-rsi这个名字有两层含义它是工厂factory因为它把一次软件开发切片slice的生产过程流水线化它也是递归自我改进RSI因为闭环的输入本身来自产品使用产出的反馈。其设计基线在 rig 规格的 summary 中被明确为ONE rig whose seats map 1:1 to thefactory-rsiworkflow — the inner loop plans, builds, checks, and reviews one slice, then prepares its release. Dogfood is decoupled: it continuously uses the SHIPPED product out-of-band and feeds findings back into the next plan — the recursive-self-improvement edge, with no human required in the loop.几个关键定位均可在 CULTURE.md 原文中找到一个 workflow 驱动一个切片的内循环plan → implement → check → review → release每次循环只处理一个切片循环本身不依赖任何人工转包。Dogfood 与门控内循环解耦dogfood 不是对预发布构建产物的二次 QA而是持续、带外地使用已发布产品把发现记录为下一轮计划的输入。RSI 递归不受门控dogfood 发现反馈进下一轮计划不需要人工闸门人类可以通过 roadmap 引导但 MVP 中不被要求也没有 loop-stop。发布是人类行为Release Seat 只准备发布物把是否发布的决定握在人工闸门处没有任何 Seat 会自行 push、打 tag 或发布。二、内循环如何运转引擎路由而不是编排器人工转包CULTURE.md 强调的第一条铁律是引擎路由内循环而不是编排器——这是factory-rsi与人肉接力式多 Agent 协作的本质区别。这一点在工作流规格 factory-rsi.yaml 中有完整的机制支撑检查失败路由回构建qa_check步骤的next_hop.on.failed: implement即当 QA 对工件给出失败裁定artifact 的 verdict而非步骤本身故障时引擎自动把包路由回implement做有界补救bounded remediation评审失败同样路由回构建review步骤的next_hop.on.failed: implement实现跨运行时评审与构建的相互制衡干净通过则进入发布准备review的suggested_roles: [release_manager]把包交给发布 Seat。2.1 有界性max_hops 制裁与 WF-5 异常拨盘循环必须有界否则会演变成无限递归。工作流规格的loop_guards提供了两个可执行的硬约束loop_guards: # ENFORCEABLE (integer 1) — sanctions the bounded remediation loops # (qa_check→implement, review→implement) max_hops: 20 spawn_budget: 0max_hops: 20这是 WF-1 要求的**可强制enforceable**守卫要求为整数且 1专门制裁qa_check→implement、review→implement这两条补救回边。一旦跳数超限整个循环被判为异常并触发 WF-5 拨盘exception_routing.default: orchestrator异常首先上报给编排 Seatorch-lead让人在高空awareness 层知情spawn_budget: 0整个循环不允许额外派生子 Agent从资源侧堵死失控分支resume 只多给一个窗口CULTURE.md 明确a resume grants exactly one more bounded window即一次恢复只额外获得一个有界窗口循环永远不会失控跑飞对应 WF-5 FR-4 的 livelock 护栏。2.2 Findings 是记录状态不是记忆下一轮计划构建的输入是被记录下来的 dogfood 发现recorded closure evidence而绝不是某个 Seat 的聊天历史。CULTURE.md 原文Findings are recorded state, not memory. The next plan builds from the recorded dogfood findings — never a seats chat history.这一点也写进了plan步骤的 objectiveThe findings arrive as recorded closure evidence, never chat并由测试 factory-rsi-starter.test.ts 中 human gate 携带evidence_ref: proof/PROOF.md的断言得到印证——闭环读取的是持久化证据evidence_ref而不是即时对话。三、七个 Seat职责、运行时与 1:1 映射CULTURE.md 用一张表定义了七个 Seat。下面把表格原样保留并补充每个 Seat 的 Agent 引用与技能装配来自 rig.yaml 与 factory-rsi.yaml 的skill_refs。SeatRuntimeDoesplan-plannerclaude-codeturns the corpus / previous findings into ONE buildable slice specbuild-implementerclaude-codebuilds the slice, produces proofcheck-qacodexchecks the artifact; a failing check loops back to buildreview-reviewercodexreviews (cross-runtime vs the builder)dogfood-testercodexcontinuously USES the shipped product out-of-band; records findings that feed the next planrelease-managerclaude-codeprepares the release, holds the human gateorch-leadclaude-codethe exception dial target — exceptions only运行时分配的刻意设计CULTURE.md 强调Seats inherit their runtimes default model (no per-seat model pin)——没有任何 Seat 钉死具体模型全部继承其运行时claude-code / codex的默认模型。这样做的直接结果是跨运行时多样性构建方跑在 claude-code检查/评审/狗粮方跑在 codex评审与检查天然与构建方异源避免自己构建自己验收的同源盲区。测试 factory-rsi-rig.test.ts 对这一点做了逐 Seat 断言plan-planner/build-implementer/release-manager/orch-lead必须为 claude-codecheck-qa/review-reviewer/dogfood-tester必须为 codex且所有 Seat 的model字段必须为 undefined。1:1 钉扎bijectionrig 的七个 Pod 各只有一名成员因此每个规范会话名都是pod-memberfactory-rsi与工作流每个角色preferred_targets的第一目标一一对应角色workflow rolepreferred_targets技能装配plannerplan-plannerfactory-rsiopenrig-user, requirements-writerimplementerbuild-implementerfactory-rsiopenrig-user, development-team, test-driven-developmentqacheck-qafactory-rsiopenrig-user, verification-before-completionreviewerreview-reviewerfactory-rsiopenrig-user, review-team, plan-reviewrelease_managerrelease-managerfactory-rsiopenrig-user, release-managerorchestratororch-leadfactory-rsiopenrig-user, orchestration-teamdogfooddogfood-testerfactory-rsiopenrig-user, dogfood, systematic-debugging测试 factory-rsi-rig.test.ts 的第五个用例专门验证7 roles ↔ 7 seats 且每个 seat 恰好被使用一次的双射关系杜绝孤儿角色或闲置 Seat。3.1 两个专属 Agentdogfood 与 release-manager除复用既有 Agentplanner、implementer、qa、independent-reviewer、orchestrator外本 Rig 新增了两个专属 Agent均有完整角色文档Dogfood Testeragent.yaml role.md——factory-rsi-dogfood。它的职责是整个循环中其他步骤永远无法证明的那一跳把对已发布产品的真实使用转化为下一轮计划。角色文档明确区分了几件事它跑在带外与门控内循环解耦持续使用已发布产品——不是冒烟测试、不是清单勾选、更不是对预发布构建产物的二次 QA它不是内循环的闸门不裁决构建工件通过与否那是内循环 check/review 的事只对已发布的东西做 dogfood 并把发现喂给下一周期它记录发现时必须是持久化证据packet trail /evidence_ref绝不作为 ambient chat因为下一周期读的是记录状态它不自己路由内循环真阻塞以异常形式上报orchestrator-first它的倾向是发现真问题优先于宣告成功——存在的意义是暴露已发布但不该发布的问题而不是给产品背书。Release Manageragent.yaml role.md——factory-rsi-release-manager。它的职责是准备发布物后在人工闸门处停下绝不发布。准备物包括通过循环的切片对应的发布说明release notes、需要的文档/网站更新、以及暂存而未合并的发布 PR并以工作区中记录的proof/PROOF.md作为人工签字所依据的证据。角色文档反复强调硬规则publish is a human act——不 push、不 tag、不npm publish、不切 GitHub release、不升级任何 host这些动作只能由release_signoff处的人类完成。四、部署形态工作区无关的 shipped starterCULTURE.md 最后给出部署方式作为随附的 starter这个 Rig 是工作区无关的——把命令指向任何真实仓库即可rig up factory-rsi --cwd repo--cwd指向的是循环要改进的真实代码库规划器的产品意图语料product-intent corpus就是该仓库真实的规格文档real specs。这也解释了为什么 rig.yaml 中每个成员的cwd都设为.——Seat 的工作目录跟随启动时的目标仓库而不是写死某个路径。启动后实例化factory-rsi工作流entry 角色为plannercoordination_terminal_turn_rule: hot_potato循环即开始闭合。五、工作流规格深度拆解六个步骤的完整旅程工作流 factory-rsi.yaml 定义了六个步骤factory-rsi-starter.test.ts 对其顺序有完整断言plan → implement → qa_check → review → release_prep → release_signoff。与 CULTURE.md 的五段式plan → implement → check → review → release相比发布腿被拆成了两步这是本规格最值得注意的细节。5.1 内循环四步plan / implement / qa_check / review步骤执行角色目标出口与下一跳planplanner把当前输入首轮为产品语料之后为带外 dogfood 发现转化为一个可构建的切片规格handoff/waiting/failed→implementerimplementimplementer按计划构建切片并产出供检查的 proofhandoff/waiting/failed→qaqa_checkqa检查构建工件通过交给评审失败工件裁定路由回 implementfailed → implementreviewreviewer跨运行时评审与构建方异源通过交给发布准备失败路由回 implementfailed → implement5.2 发布腿两步release_prep → release_signoff先准备、后签字这是该工作流的一个rev1 修正测试注释中明确记载旧形态把 gate 放在release_prep上导致先签字后准备的顺序颠倒正是 rev1-r1/r2 的阻塞点。修正后的设计release_prepRelease Manager 的可执行步骤在任何闸门之前真正干活——写发布说明、文档/网站更新、暂存发布 PR并把本周期发布证据记录到工作区proof/PROOF.md即签字闸门指向的evidence_ref。它没有 gate测试断言release_prep的gate为 undefinedrelease_signoff人工闸门gate.target: humankernelsummary 为 RSI cycle clean; release artifacts prepared — sign off to publish (publish is a human act)evidence_ref: proof/PROOF.md。它的next_hop.mode: forbid——签完字只能done/waiting/failed引擎禁止再往下路由发布动作由人类在闸门外完成。为什么用显式 step-id 路由而不是角色路由因为release_prep与release_signoff共享同一个release_manager角色若按角色走suggested_roles会歧义会匹配到第一个 release_manager 步骤所以release_prep的next_hop.on.handoff: release_signoff是显式 step-id 路由。测试 factory-rsi-starter.test.ts 的第三个用例完整验证了这条腿走到release_prep时实例仍为active、包未被 blockedrelease-managerhandoff后进入release_signoff此时包才以blocked状态停在humankernel并携带 summary 与evidenceRef: proof/PROOF.md实例状态转为waiting。5.3 不变量、异常路由与闭环定义invariants: continuation_required: true preserve_lineage: true closure_required: true allowed_exits: [handoff, waiting, done, failed]continuation_required/closure_required任何步骤必须给出可接续的出口与闭合证据不允许无声消失preserve_lineage全程保留血缘provenance保证 findings 与证据可追溯allowed_exits收敛到封闭枚举qa_check/review的失败分支只落在implement上。异常路由统一走 WF-5 拨盘exception_routing.default: orchestratororchestrator_role: orchestrator即任何异常包括max_hops超限都 orchestrator-first 上报人类在 awareness 层知情。闭环三态在closure中定义successRSI cycle clean发布候选已准备并停在人工发布闸门degraded周期因具名阻塞或max_hops超限停下等待 resumefailed步骤以异常失败保留 finding 并经拨盘路由。六、验证与保证测试如何证明这个闭环是真的仓库为该 Rig 提供了两层测试把 CULTURE.md 的每条设计主张都变成了可执行断言factory-rsi-rig.test.tsrig 层验证rig 规格通过RigSpecSchema校验恰好声明七个 RSI Seat每 Pod 一名成员运行时分配符合 0.4.6 FAC2 设计构建方 claude-codeqa/review/dogfood 用 codex无任何 Seat 钉模型两个新增 Agent 规格校验通过每个 workflow 角色与 Seat 1:1 钉扎——无孤儿角色、无闲置 Seat双射断言。factory-rsi-starter.test.tsworkflow 层在内存 SQLite 事件总线 WorkflowRuntime 上真实实例化运行验证规格干净通过WorkflowValidatormax_hops为 1 的整数、分支映射可解析、角色 1:1正向遍历plan → implement → qa_check → review时每个角色的handoff都被引擎投影到正确的下一步骤与下一负责人review交给release-managerfactory-rsi发布腿顺序正确review → release_prep无 gate、实例 active、包未 blocked→release_signoff包 blocked 在humankernel、携带 summary evidence_ref、实例 waitingqa_check以failed退出时包被路由回implement、负责人回到build-implementerfactory-rsi。这四条恰好覆盖了 CULTURE.md 的五条核心设计主张中的四条引擎路由、有界补救、发布是人类行为、release 先准备后签字并验证了 dogfood 角色是声明角色而非内循环步骤spec.steps中不存在actor_role: dogfood的步骤。七、把 factory-rsi 用起来从命令到闭环综合 CULTURE.md 与仓库配置完整的上手路径是准备目标仓库选择任何真实代码库作为循环要改进的对象确保其规格文档specs可被 planner 读取启动 Rigrig up factory-rsi --cwd repo把--cwd指向目标仓库rig.yaml 中所有成员的cwd: .会随启动目录生效rig 与工作区解耦实例化工作流启动factory-rsiworkflow入口角色 planner第一个周期以仓库真实 specs 为产品语料plan 步骤产出第一个可构建切片观察闭环引擎沿plan → implement → qa_check → review → release_prep → release_signoff路由qa/review 失败自动弹回 implement最多 20 跳异常自动上报 orch-leaddogfood Seat 持续带外使用已发布产品并记录 findings成为下一周期 plan 的输入人类只在两处出现可选地通过 roadmap 引导方向以及在release_signoff人工闸门处对已准备好的发布物签字放行发布本身仍是人类行为。需要明确的前提与限制max_hops与spawn_budget保证的是有界而非永不失败——循环可能以 degraded超限待 resume或 failed异常经拨盘收场这正是设计的一部分dogfood 的持续带外运行机制在 factory-rsi.yaml 中注明后续版本细化当前 MVP 中 dogfood 以内循环之外、由该角色驱动的形式存在。如果你想深入了解底层机制可继续阅读 rig 规格、工作流规格 以及两个测试文件 factory-rsi-rig.test.ts 与 factory-rsi-starter.test.ts。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】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 factory-rsi 之 Dogfood Tester 角色解析把已发布产品的真实使用转化为下一轮计划的 RSI 反馈环OpenRig factory rsi 之 Dogfood Tester 角色解析把已发布产品的真实使用转化为下一轮计划的 RSI 反馈环 在 OpenRig人工智能AI Agent多智能体Agent 编排代码智能体CLIZenbot RSI 策略深度解析基于 RSI 高水位追踪的逆势交易实现与调参实战Zenbot RSI 策略深度解析基于 RSI 高水位追踪的逆势交易实现与调参实战 导读 本文围绕 Zenbot基于 Node.js 与 MongoDB 的金融科技后端OpenRig factory-rsi 发布座席实战release-manager 如何只准备、不发布把发布权锁死在人类门禁上OpenRig factory rsi 发布座席实战release manager 如何只准备、不发布把发布权锁死在人类门禁上 本篇技术指南以 Open人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇QuickRecorder一条命令装好的macOS免费录屏工具3步完成第一次录制下一篇3步让你的Windows任务栏瞬间变透明TranslucentTB新手完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考