尧图精选

OpenRig Conveyor Builder 启动上下文:从 `rig whoami --json` 到数据包交接的流水线席位实战指南

🕒 发布时间:2026/10/1 2:20:32 📁 来源:尧图网络
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载本指南以 OpenRig 仓库中 Conveyor starter rig 的 Builder 席位启动上下文文档startup/context.md为核心完整讲解 Builder 代理启动时必须遵守的拓扑自检、身份确认与数据包交接约定。读完本文你将掌握如何用rig whoami --json验证自身会话身份build-builderconveyor理解 Builder 在计划planner→ 构建builder→ 审查reviewer流水线中的输入输出契约以及收到返工数据包时如何保持证据链完整。Conveyor一个用于学习队列交接的站式流水线 RigConveyor 是 OpenRig 0.3.0 的 launch-grade starter rig设计定位是紧凑的站式流水线一个 intake接收、一个 planner计划、一个 builder构建、一个 reviewer审查席位通过清晰的交接路径推动队列中的工作流动。其拓扑定义在 rig.yaml 中Pod成员agent_refruntime默认职责intakeleadlocal:../../../agents/conveyor/leadclaude-code澄清数据包、关闭数据包planplannerlocal:../../../agents/conveyor/plannercodex产出小型计划buildbuilderlocal:../../../agents/conveyor/builderclaude-code执行计划、产出可审查的 proofreviewreviewerlocal:../../../agents/conveyor/reviewercodex审查结果、必要时发回返工rig 内部通过边edges描述协作关系intake.lead → plan.planner → build.builder → review.reviewer为delegates_to委托链而review.reviewer可can_observe观察build.builder与intake.leadintake.lead亦可观察build.builder与review.reviewer。这正是 Builder 启动上下文里rework packets may also arrive from review的拓扑来源——审查席位通过队列交接把后续工作路由回构建席位。启动上下文文档的三条核心契约Builder 的 startup/context.md 全文只有三层指令却是整个 Builder 席位运行纪律的浓缩1. 先拓扑自检再作拓扑断言Runrig whoami --jsonbefore making topology claims.这是启动上下文的第一条硬性要求在做出任何关于我是谁、我在哪条链上、我应该把成果交给谁的断言之前必须用rig whoami --json确认真实拓扑。从 CLI 源码whoami.ts可以看出该命令支持--json输出其身份结构WhoamiIdentity包含rigName、logicalId、attachmentType、podId、memberId、sessionName、runtime等字段并附带resolvedBy标记说明身份解析来源。这意味着 Builder 的自我认知不是写在角色文档里的假设而是由运行时解析出的真实席位事实。2. 确认会话身份build-builderconveyorConfirm that your session isbuild-builderconveyor.build-builderconveyor采用podId-agentIdrigName的命名范式build是 pod、builder是成员、conveyor是 rig 名。对照 rig.yaml 中buildpod 的member_id: builder与agent_ref: local:../../../agents/conveyor/builder即可确认该身份指向的正是 Builder 席位。与之对应计划席位是plan-plannerconveyor审查席位是review-reviewerconveyor接收席是intake-leadconveyor见 lead/startup/context.md。3. 默认工作流角色builderDefault workflow role:builder.Builder 在conveyor工作流与basic-loop工作流中都以builder角色运行。角色承载了具体职责——见下一节。数据包契约从 planner 收向 reviewer 交接受 review 返工启动上下文明确了 Builder 的两条数据包通道输入Receive planned packets fromplan-plannerconveyor——Builder 的执行对象是 planner 产出的计划数据包而不是自己凭空想象的实现目标输出Send proof-ready work toreview-reviewerconveyor——Builder 交给 review 的不是裸代码而是可审查的 proof证据回流Rework packets may also arrive from review——审查发现缺陷时返工数据包会按原路径回到 Builder。这条契约与 guidance/role.md 中的职责清单一一对应在编辑或产出工件之前先读计划read the plan before editing or producing an artifact保持实现范围与数据包对齐keep implementation scope aligned to the packet运行与变更匹配的验证命令run the verification commands that fit the change向review-reviewerconveyor交接时附上变更文件、运行过的命令、残余风险hand off with changed files, commands run, and residual risks若审查退回工作处理具体发现项并保留证据轨迹preserve the evidence trail。其中Tests and proof are part of the work product测试与证明本身就是交付物的一部分与 Do not claim success without reproducible verification没有可复现的验证就不宣称成功两条原则正是proof-ready work这一交接标准的行为学基础。agent.yaml启动上下文如何被加载Builder 席位配置在 agent.yaml 中它把启动上下文与角色文档正式绑定为启动加载项name: conveyor-builder version: 1.0 description: Conveyor builder - executes the planned packet and prepares proof for review defaults: runtime: claude-code imports: - ref: local:../../shared profiles: default: uses: skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion] guidance: [] subagents: [] plugins: [shared:openrig-core] runtime_resources: [shared:claude-default-settings, shared:claude-default-mcp, shared:codex-default-config, shared:claude-activity-hooks] resources: guidance: - id: role path: guidance/role.md - id: startup-context path: startup/context.md startup: files: - path: guidance/role.md delivery_hint: send_text required: true - path: startup/context.md delivery_hint: send_text required: true actions: []值得注意的细节startup.files中required: true意味着startup/context.md与guidance/role.md是 Builder 每次启动的强制上下文缺失即启动失败delivery_hint: send_text表示上下文以文本形式投递给运行时默认加载的技能development-team、test-driven-development、systematic-debugging、verification-before-completion与 role.md 中测试与证明是交付物可复现验证的原则形成支撑。在conveyor与basic-loop工作流中的实战路径启动 READMEREADME.md给出了两种运行方式rig up conveyorconveyor工作流默认站式流水线允许多个数据包同时活跃可观察不同席位的队列深度差异这正是 CULTURE.md 强调的backpressure signalbasic-loop工作流单工作项的慢速演练适合完整观察一个数据包走完所有席位。README 还提供了一个可直接用于首个数据包的示例目标Draft a tiny release-readiness checklist for a command-line tool. Keep it to five checks and include one verification command.期望的运动路径是intake-leadconveyor澄清数据包并交给计划席位plan-plannerconveyor将其转化为小型计划build-builderconveyor起草清单产出 proof-ready 工件review-reviewerconveyor检查结果intake-leadconveyor携带证据关闭数据包。Builder 处于第 3 步其启动上下文确保它只做计划内的事、带证据交接、接受返工并保留证据轨迹。当review需要返工而非直接关闭时通过普通队列交接把工作路由回build席位这正是 CULTURE.md Operating Notes 中描述的行为review 可按需把后续工作送回 build默认通过路径则是 review → close。与其他席位的对照Builder 在拓扑中的精确位置将 Builder 的启动上下文与其邻居对比可以更清楚地定位它的责任边界Plannerplanner/startup/context.md强调先rig whoami --json再推导实际席位因为 planner 会被多个 rig 复用conveyor 与 factory-rsi 都使用 planner它产出计划后通过所选工作流的投影/出口返回避免并行队列交接Lead默认角色为intake与closer负责澄清与关闭并可观察 build 与 reviewBuilder既不澄清也不关闭只负责在计划边界内执行并产出可审查证据同时是 review 返工的唯一接收方。由此可以推断Builder 启动上下文的存在意义是在启动瞬间就把输入来源planner、输出去向reviewer、返工回流review→builder三条通道写死避免 Builder 在缺少路由上下文时猜测收件地址——这与 planner 上下文Missing routing context is an input to resolve, not a reason to guess an address的纪律同源。实践要点小结每次会话启动先执行rig whoami --json核对logicalId/sessionName是否为build-builderconveyor再作任何拓扑断言只消费plan-plannerconveyor的计划数据包实现范围严格对齐数据包交接review-reviewerconveyor时提交三类信息变更文件列表、运行过的验证命令、残余风险收到返工数据包时处理具体发现项并保留证据轨迹而非在聊天中掩盖缺陷将 startup/context.md 与 role.md、agent.yaml 三者合读即得到 Builder 席位的完整运行契约启动上下文管身份与通道角色文档管职责与原则agent 配置管加载与资源。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐OpenRig Conveyor Lead 启动上下文从 rig whoami --json 到站台交接的身份确认实战OpenRig Conveyor Lead 启动上下文从 rig whoami json 到站台交接的身份确认实战 本文以 OpenRig 仓库中 conve人工智能AI Agent多智能体Agent 编排代码智能体CLIYARP 反向代理 Prometheus 监控实战基于 Telemetry.Consumption 的指标采集与可视化指南YARP 反向代理 Prometheus 监控实战基于 Telemetry.Consumption 的指标采集与可视化指南 本指南以仓库中 samples/P人工智能AI Agent多智能体Agent 编排代码智能体CLIWindows 与 Office 激活不出门MAS 开源脚本实践完整指南Windows 与 Office 激活不出门MAS 开源脚本实践完整指南 MAS 是社区维护的开源脚本能用 HWID、Ohook、TSforge、在线 KM人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇5分钟掌握B站直播推流码获取告别直播姬限制的完整指南下一篇CANN 平台 DeepSeek-R1 / Kimi-K2 高性能推理实战指南从环境搭建、权重转换到 PD 分离部署与长序列优化创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
上一篇/下一篇内容由系统自动关联 返回资讯列表 →