人工智能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 仓库中packages/daemon/assets/vm-preview-fixtures目录展开讲解这套VM 预览夹具如何在 Tart 预览环境中为两个 OpenRig daemon 提供差异化内容——一个 daemon 拥有可演示的工作流样本另一个保持空白以对比首次安装体验。读完本文你将掌握夹具目录的构成、sample-basic-loop.yaml工作流规格的完整字段语义、通过two-daemon-start.sh启动双 daemon 并把夹具装载进workspace.specs_root/workflows/的实操步骤以及编写合规夹具的命名与内容约定。一、夹具的定位为空壳与有内容的对比演示而生packages/daemon/assets/vm-preview-fixtures目录的职责非常聚焦为 Tart 预览环境提供样本数据让一个 OpenRig daemon 拥有具有代表性的内容同时保持第二个 daemon 为空用于并排对比。这种一空一满的布局服务于一个真实的运营场景创始人在同一台 VM 里打开两个浏览器标签页一边看全新安装blank-slate的第一印象 UI一边看已经被填充populated的活过的 UI。从 scripts/vm-bootstrap/two-daemon-start.sh 的注释可以确认这套编排的完整意图在已安装 OpenRig CLI 的 Tart VM 上执行启动脚本脚本以完全隔离的状态启动两个 daemon独立的OPENRIG_HOME目录、独立的端口默认 7433 / 7434、独立的 SQLite 路径分别通过http://vm-ip:7433与http://vm-ip:7434访问空白与填充两套 UI。脚本开头还记录了一个重要的架构教训forward-fix #1CLI 的父进程模块级常量OPENRIG_DIR/STATE_FILE/LOG_FILE定义于 packages/cli/src/daemon-lifecycle.ts在导入时就从OPENRIG_HOME解析因此必须使用OPENRIG_HOMEdir rig daemon start这种环境变量方式隔离状态而不能依赖一个只传给子进程的--openrig-homeflag——后者会让父进程 CLI 的daemon.json、daemon.log仍然写进默认的~/.openrig路径破坏隔离。二、目录内容workflows 工作流样本夹具目录当前只有一类内容packages/daemon/assets/vm-preview-fixtures/README.mdpackages/daemon/assets/vm-preview-fixtures/ ├── README.md └── workflows/ └── sample-basic-loop.yaml其中workflows/存放公开的示例工作流规格。basic-loop 样本演示了一条完整的从 intake 到 close的交接链路并且不依赖任何私有 rig 或机器——任何部署环境下都可以直接装载、直接演示。这正是它被选作预览夹具的原因它只描述产品行为不绑定具体会话、主机或 rig 实例地址。三、sample-basic-loop.yaml 全量解析夹具的核心是 packages/daemon/assets/vm-preview-fixtures/workflows/sample-basic-loop.yaml。它几乎是内建工作流 packages/daemon/src/builtins/workflow-specs/basic-loop.yaml 的镜像唯一的关键差异是id不同见第五节。完整内容如下# Example workflow for the populated VM preview. # Its distinct ID avoids colliding with the built-in basic-loop specification # when copied into the populated daemons configured workflows directory. # The daemon discovers it on the next workflow-library listing. workflow: id: vm-preview-basic-loop version: 1 objective: Walk one work packet through the conveyor rig slowly enough for a new user to inspect each handoff. target: rig: conveyor entry: role: intake coordination_terminal_turn_rule: hot_potato roles: intake: skill_refs: [openrig-user, backlog-capture] preferred_targets: [intake-leadconveyor] planner: skill_refs: [openrig-user, verification-before-completion] preferred_targets: [plan-plannerconveyor] builder: skill_refs: [openrig-user] preferred_targets: [build-builderconveyor] reviewer: skill_refs: [openrig-user, review-team] preferred_targets: [review-reviewerconveyor] closer: skill_refs: [openrig-user] preferred_targets: [intake-leadconveyor] steps: - id: intake actor_role: intake objective: Restate the objective and hand off one packet. allowed_exits: [handoff, waiting, failed] next_hop: mode: require suggested_roles: [planner] - id: plan actor_role: planner objective: Produce a short plan for one build turn. allowed_exits: [handoff, waiting, failed] next_hop: mode: require suggested_roles: [builder] - id: build actor_role: builder objective: Build or draft the planned output. allowed_exits: [handoff, waiting, failed] next_hop: mode: require suggested_roles: [reviewer] - id: review actor_role: reviewer objective: Check the output and clear it for close. allowed_exits: [handoff, waiting, failed] next_hop: mode: require suggested_roles: [closer] - id: close actor_role: closer objective: Close the walkthrough packet. allowed_exits: [done, failed] next_hop: mode: forbid invariants: continuation_required: true preserve_lineage: true closure_required: true allowed_exits: [handoff, waiting, done, failed] loop_guards: max_hops: 10 spawn_budget: 0 closure: success: Walkthrough packet closed. degraded: Walkthrough stopped with a named blocker. failed: Walkthrough failed with evidence.3.1 顶层字段与语义对照 packages/daemon/src/domain/workflow-types.ts 中的WorkflowSpec类型可以逐字段确认语义字段值含义workflow.idvm-preview-basic-loop工作流唯一标识入库后作为 library 条目名。故意与内建basic-loop区分避免装载进 populated daemon 时与内建规格冲突workflow.version1规格版本与name一起构成workflow:name:version形式的稳定 library idobjective见 YAML工作流的目标描述让一个工作包在 conveyor rig 上走得足够慢便于新用户观察每次交接同时作为 library 列表的 summarytarget.rigconveyor目标 rig是默认值而非硬编码——实例化时targetRig参数可覆盖它生效绑定记录在实例的boundRig上entry.roleintake入口角色实例创建时从该角色的步骤开始coordination_terminal_turn_rulehot_potato协调终端轮转规则缺省值就是hot_potato3.2 roles角色的技能与目标席位每个角色WorkflowRoleSpec见 workflow-types.ts支持两个字段skill_refs该角色实现的技能标识列表。此字段当前是 v2 disposition仅文档化所有者解析实际使用preferred_targets验证器会对此给出 advisory 提示preferred_targets操作者提供的该角色优先会话目标被resolveDefaultOwner/ entry-owner 解析消费。例如intake-leadconveyor表示conveyor rig 上的 intake-lead 席位plan-plannerconveyor表示 planner 角色对应该 rig 上的 plan-planner 席位。夹具覆盖了 5 个角色intake技能 openrig-user backlog-capture、planneropenrig-user verification-before-completion、builderopenrig-user、revieweropenrig-user review-team、closeropenrig-user。它完整勾勒了一条 intake → plan → build → review → close 的生产线。3.3 steps五步交接链路五个步骤构成完整的交接链WorkflowStepSpec见 workflow-types.ts步骤角色目标allowed_exitsnext_hopintakeintake重述目标并交出一个包handoff, waiting, failedrequire → plannerplanplanner为一个 build 轮次产出简短计划handoff, waiting, failedrequire → builderbuildbuilder产出或草拟计划的输出handoff, waiting, failedrequire → reviewerreviewreviewer检查输出并放行收尾handoff, waiting, failedrequire → closerclosecloser关闭走查包done, failedforbid终结步骤关键点allowed_exits是闭合枚举的一个子集——系统级退出类型只有handoff/waiting/done/failed四种WORKFLOW_EXIT_KINDS见 workflow-types.ts步骤只能从中选取禁止自由文本、身份或非结构化证据 JSONnext_hop.mode: require表示该步骤必须交接给建议角色mode: forbid用于终结步骤。注意mode: prefer已从值空间中移除与省略 mode 行为完全相同解析器会给出 what/why/fix 迁移错误本样本没有使用next_hop.on按退出类型分支、harness固定 agent harnessclaude-code/codex、host固定、gate结构化闸门等进阶字段——它们在本规格中被省略属于字节恒等省略byte-identity-by-omission。3.4 invariants 与 loop_guardsinvariantsWorkflowInvariantsworkflow-types.tsallowed_exits: [handoff, waiting, done, failed]是实际被投影器消费的字段验证器会子集检查每个步骤的 allowed_exitscontinuation_required、preserve_lineage、closure_required目前是 v2 dispositionadvisory谱系始终通过chain_of_record保留收尾始终由 hot-potato 契约要求这些 flag 本身不 gate 任何行为loop_guardsWorkflowLoopGuardsworkflow-types.tsmax_hops: 10是被强制执行的投影器在比较 hop 数超过有效基线v1 基线为 0时会以 guard 名义诚实失败实例同时在验证期制裁死循环spawn_budget: 0当前为 advisory单前沿模型尚不存在 spawn/fan-out 接缝但仍建议明确声明以表达本工作流不派生子实例的意图。3.5 closure收尾消息closureWorkflowClosureMessagesworkflow-types.ts提供 success / degraded / failed 三种展示消息。当前没有消费者渲染它们v2 dispositionadvisory但它们为 UI 未来的收尾展示预留了文案。四、装载流程把夹具变成 daemon 可发现的工作流原文档的 Use 部分给出两步装载流程这里结合脚本与源码展开完整实操4.1 启动双 daemonbash scripts/vm-bootstrap/two-daemon-start.sh脚本核心行为scripts/vm-bootstrap/two-daemon-start.sh默认BLANK_HOME$HOME/.openrig-blank、POPULATED_HOME$HOME/.openrig-populated、BLANK_PORT7433、POPULATED_PORT7434均可通过同名环境变量覆盖FIXTURE_DIR默认指向本仓库的夹具目录对每个 daemon 执行OPENRIG_HOME$home rig daemon start --port $port --db $home/openrig.sqlite让 daemon 状态、CLI 生命周期簿记daemon.json、daemon.log与 SQLite 全部落在各自 HOME 下幂等性由每个 HOME 各自的daemon.json保证干净关机后重跑可重建状态若 daemon 仍在运行rig daemon start会拒绝重复启动失败时脚本会打印 RESET 指引OPENRIG_HOME... rig daemon stop后再清空目录。启动后脚本会提示下一步OPENRIG_HOME$POPULATED_HOME OPENRIG_PORT$POPULATED_PORT rig up product-team实例化一个示例 rig为 populated daemon 填充活过的内容。4.2 复制工作流 YAML 到 specs_rootcp packages/daemon/assets/vm-preview-fixtures/workflows/*.yaml \ $OPENRIG_WORKSPACE_SPECS_ROOT/workflows/这里的workspace.specs_root是符号化配置路径默认解析为workspaceRoot/specs见 packages/daemon/src/domain/user-settings/settings-store.ts环境变量优先级为OPENRIG_WORKSPACE_SPECS_ROOT见同文件第 225 行。工作流规格必须落在workspace.specs_root/workflows/目录下这是 bundle 装载器的硬性要求见 packages/daemon/src/domain/bundle-workflow-specs-router.ts。4.3 daemon 自动发现无需重启复制完成后的下一次 workflow-library 列表即可发现新规格——这是 Slice 11workflow-spec-folder-discovery的机制。从源码看每次 library 列表请求都会机会性地调用scanWorkflowSpecFolderpackages/daemon/src/domain/spec-library-workflow-scanner.ts其工作细节mtime 检查OQ-3文件 mtime 不晚于缓存行cached_at时直接跳过按秒比较规避 HFS/FAT 文件系统 mtime 取整问题readThrough 解析校验通过 packages/daemon/src/domain/workflow-spec-cache.ts 解析并缓存解析失败则写入statuserror的诊断行Library UI 会以内联错误样式展示操作者可就地修复文件文件消失清理OQ-4源文件被删除的缓存行会被移除并经由 EventBus 发出workflow_spec.removed审计事件reason:file_disappeared。因此把sample-basic-loop.yaml拷入目录、刷新一次 library 列表populated daemon 的 Spec Library 就会以workflow:vm-preview-basic-loop:1的身份列出它。五、与内建 basic-loop 的关系ID 冲突规避值得特别说明的是夹具里的sample-basic-loop.yaml在结构与语义上几乎就是内建 starter packages/daemon/src/builtins/workflow-specs/basic-loop.yaml 的复制但id被改写为vm-preview-basic-loop。注释明确写道Its distinct ID avoids colliding with the built-in basic-loop specification when copied into the populated daemons configured workflows directory.内建 starter 会在 daemon 启动时通过loadStarterWorkflowSpecs种入 SQLite 缓存spec-library-workflow-scanner.ts如果夹具沿用basic-loop这个 id就会在缓存中产生同名冲突。改名后populated daemon 可以同时拥有内建basic-loop与夹具vm-preview-basic-loop两个条目互不干扰——这既是夹具的实用技巧也是编写自定义工作流时的通用纪律先查内建 id避免重名。coordination_terminal_turn_rule: hot_potato同时与 packages/daemon/src/builtins/workflow-specs/conveyor.yaml 等内建规格保持一致从 workflow-spec-cache.ts 可以看到该字段的解析默认值就是hot_potato即规格缺省时同样生效。六、夹具编写约定Conventions原文档给出四条编写规范全部以可移植、可演示、不泄内幕为原则逐一展开用户相关路径统一用/Users/example/...夹具会被拷入不同机器的 workspace任何含用户名的路径如机器名、用户名目录都会破坏可移植性/Users/example/...是约定俗成的占位符。使用符号化配置路径而非机器特定位置例如写workspace.specs_root而不是/home/alice/openrig/specs。符号化路径由配置层解析环境变量OPENRIG_WORKSPACE_SPECS_ROOT或配置键workspace.specs_root保证夹具与机器无关。使用通用逻辑角色与 ID而非具体会话、主机或 rig 实例地址夹具中的intake、planner、builder、reviewer、closer都是逻辑角色preferred_targets也只指向intake-leadconveyor这类逻辑席位绝不能写入真实 session id、host 地址或 rig 实例名。描述夹具演示的产品行为省略发布历史、内部归属与实现规划夹具是面向新用户能否看懂交接的演示素材不是内部文档——发布说明、负责人、实现计划一律不进入夹具。七、如何基于夹具扩展你自己的演示工作流如果需要在 populated daemon 中演示更多场景可遵循以下模式在packages/daemon/assets/vm-preview-fixtures/workflows/下新建一个sample-*.yaml整体骨架复制sample-basic-loop.yaml为workflow.id取一个不与内建 id如basic-loop、conveyor、factory-rsi见 packages/daemon/src/builtins/workflow-specs/冲突的名字按需补充进阶字段next_hop.on做按退出类型分支、harness固定 claude-code/codex、gate声明结构化闸门目标可以是humankernel形式的人类席位会话或已声明角色名人类目标必须携带summary与evidence_ref、acceptance声明候选/裁决/证据的验收契约通过rig workflow specs或 Library 列表验证条目出现并核对拓扑投影getWorkflowReview会把 roles 映射为节点、把next_hop.suggested_roles映射为 direct 边把next_hop.on映射为带branchOn的 branch 边。相关的测试用例可以进一步印证行为packages/daemon/test/workflow-spec-cache.test.ts 覆盖缓存 readThrough 与 hot_potato 默认值解析packages/daemon/test/conveyor-starter.test.ts 覆盖 conveyor 工作流的实例化与启动。结语vm-preview-fixtures是 OpenRig 预览演示体系的一小块拼图但它完整展示了用可移植的工作流规格填充真实 daemon的闭环夹具目录定义样本 → 双 daemon 脚本提供隔离运行环境 →specs_root/workflows/装载 → 扫描器自动发现入库 → Library 与拓扑投影渲染。理解这套机制你既能熟练搭建双 daemon 对比演示环境也能掌握为 OpenRig 编写、命名与装载自定义工作流规格的全部纪律。赞分享人工智能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点击查看免费下载相关推荐Flutter设备预览工具Device Preview安装与配置指南Flutter设备预览工具Device Preview安装与配置指南 前言 在Flutter应用开发过程中开发者经常需要测试应用在不同设备上的显示效果。手动切UI库/组件移动开发开发工具asdf-vm团队协作工具统一开发环境的终极解决方案asdf vm团队协作工具统一开发环境的终极解决方案 痛点多版本环境下的团队协作困境 你是否曾经遇到过这样的场景新同事加入项目花费数小时配置开发环境团CLI开发工具Hive 浏览器架构设计解析从本地扩展到沙箱 VM 的统一 Agent 浏览器体验Hive 浏览器架构设计解析从本地扩展到沙箱 VM 的统一 Agent 浏览器体验 导读 本文基于 Hive 仓库内部的架构设计文档 browser arch人工智能AI Agent多智能体MCP 服务工具调用浏览器控制上一篇RetroWrite x64与ARM64版本对比功能差异与架构支持详解下一篇XCOM 2模组管理终极指南5步掌握AML启动器高效管理技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考