OpenRig Conveyor Planner 角色指南：把工作包转化为可执行计划的规划工位

人工智能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传送带是一套用于学习队列交接与工作流实例的启动 Rigstarter rig而conveyor-planner是其中负责把已接受的工作包变成一份有界计划的规划工位。本文以该角色的完整角色定义guidance/role.md为主线结合其 AgentSpec、启动上下文、工作流规范与源码测试讲清规划工位在流水线中的定位、技能栈、输出结构与交接路由规则让读者能够直接理解并复现这一规划即约束的协作模式。一、角色定位为什么流水线需要一位规划工位OpenRig 是一个把 Claude Code 与 Codex 编排进同一系统协同工作的多智能体 harness。Conveyor 启动 Rig 在 rig.yaml 中定义了四个 Pod构成一条紧凑的工位流水线Pod成员席位默认运行时角色intake受理intake.leadclaude-code接收原始请求、整理工作包、关闭完成的工作plan规划plan.plannercodex把工作包转化为可执行计划build构建build.builderclaude-code执行计划并产出可审查的证据review审查review.reviewercodex对照计划核查产出决定返工或放行四条delegates_to边串起主流转intake.lead → plan.planner → build.builder → review.reviewer另有若干can_observe边允许 review 观察 build 与 intake、intake 观察 build 与 review支撑返工与状态跟踪。conveyor-planner的 agent.yaml 将其定义为可复用的规划工位reusable planning stationTurns accepted packets into small executable plans —— 把已接受的accepted工作包转化为构建工位无需猜测即可执行的小型计划。关键词有两个已接受accepted规划工位不负责澄清原始需求、不负责接收随口一句话它处理的是已经过 intake 受理、进入队列的工作包packet。可执行executable且无猜测without guessing计划必须把完成意味着什么说死构建工位照单执行即可。这份角色定义位于 role.md是该 Agent 每次启动时通过startup.files以send_text方式强制注入的两份引导文件之一另一份是 startup/context.md。二、规划工位的四项核心职责角色定义把规划工位的职责收敛为五条可归纳为读 → 写 → 控 → 交 → 标五个动作读懂工作包Read the packet阅读被分配的工作包识别出具体、可验证的成果concrete outcome并明确点出任何缺失的输入missing input。命名缺失输入意味着如果工作包本身信息不足这不是规划工位的猜测空间而是需要向上游请求补充的显式输入。产出简短计划Produce a short plan计划必须包含三要素——预期文件expected files、命令commands与验证verification。三者的组合让完成变成可核查的客观状态而非模糊的工作主题。控制单轮规模Keep the plan small计划要小到一个构建轮次one build turn就能完成。这与 Conveyor 的整体文化一致——CULTURE.md 明确要求偏好能无需额外协调仪式就从受理走到审查的小工作包。推导身份与路由Derive seat and route用rig whoami --json推导自己的实际席位再根据被分配的工作包与所选工作流推导下一个角色/目标不硬编码起始地址Do not hard-code a starter address。路由规则的完整展开见下文第四节。诚实标记阻塞Mark blockers honestly如果仅凭现有输入无法规划出工作包必须如实标记 blocker而不是编造一个看似合理的计划蒙混过关。其中第 4 条是规划工位区别于静态角色卡的关键planner 不是 conveyor 专属的席位它被多个 Rig 复用因此身份与下一跳必须从运行时事实推导而不是写死在提示词里。三、技能栈规划工位装载的五项技能角色定义声明 planner 装载了五项技能它们决定了规划工位用什么方法干活。可从 openrig-skills/SKILL.md 的技能索引和对应 SKILL.md 中逐一印证技能作用实现依据openrig-user日常rigCLI 操作面send / queue / ps / whoami / scope / broadcast通用主干技能自动投递给所有 Rigmission-slice-sop任务/切片操作规程intent → mini-requirements proof contract → build → QA → proofopenrig-core 插件内的 SOP见 mission-slice-sop-plugin-parity.test.tsrequirements-writer把粗糙输入整理成可实现的 SPEC.md含验收标准与范围边界requirements-writer/SKILL.mdcontext-builder三层上下文模型reference原始资料→ context综合文档→ background.md特性上下文保证计划有据可依context-builder/SKILL.mdverification-before-completion证据先于断言任何完成声明必须有当轮运行的验证输出支撑verification-before-completion/SKILL.md3.1 requirements-writer把做什么写清楚这份技能定义了规划产物中成果侧的方法论一切以可观察的验收结果acceptance outcomes为准SPEC.md 里的每一条都会被 AI Agent 当作字面指令执行因此禁止理想化内容、禁止未来阶段、只写当下要构建的东西。验收标准统一采用 GIVEN / WHEN / THEN 三句式且必须描述用户可观察的结果而非系统内部行为。规划工位借它来回答这包工作的完成标准到底是什么。3.2 verification-before-completion让验证成为计划的硬性组成角色职责要求计划包含 verification其方法论底座正是这份技能。它的核心是铁律NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE 没有当轮新鲜的验证证据就不许声明完成Gate Function 规定了声明前的固定五步识别证明该声明的命令 → 完整运行该命令 → 通读输出与退出码 → 核对输出是否确证声明 → 才允许表态。它还点名了一批看似绿色实则撒谎的检查陷阱只比对形状不比内容、把标签当成验证、测试全部共享同一根未验证的轴、语法检查≠运行时正确、挂起型失败永远不会报错等。规划工位在设计验证字段时正是按这个标准挑选能证明完成的命令而不是随便填一条npm test。3.3 context-builder计划不凭空产生规划需要输入侧的依据。context-builder 的三层模型告诉规划工位先查validation.md需求证据、再查background.md背景综合、后查既有 SPEC 与已交付特性最后才写计划。这与职责 1 的命名缺失输入呼应——缺输入就点出来而不是靠脑补填上。四、启动上下文与路由规则不硬编码地址规划工位每次启动时还会被注入 startup/context.md它把 role.md 中的路由要求进一步操作化先自证身份任何拓扑论断topology claim之前先跑rig whoami --json从结果推导实际席位与所属 Rig。planner 被多个 Rig 复用所以我是谁、我在哪条流水线必须是运行时事实。默认工作流角色planner。读取工作包与工作流识别发送者、当前步骤、下一角色/目标。两种路由模式二选一工作流内激活的工作流拥有内环路由权计划通过其选定的projection/exit返回不做并行的队列交接工作流外使用工作包的目的地destination对照实际 Rig 解析后交接。缺失路由上下文是待解析的输入缺上下文就去解析而不是猜一个地址。这正是不硬编码起始地址的操作含义。启动上下文还给出了两个对照实例用于说明示例不等于身份绑定官方conveyor工作流使用plan-plannerconveyor与build-builderconveyorfactory-rsi工作流使用plan-plannerfactory-rsi并把计划经工作流路由给它的实现者。这两个地址只是当前这套 Rig 用这两个地址的例证并不构成被复用 planner 的身份或目的地。planning 输出保持精简objective目标、assumptions假设、steps步骤、verification验证、handoff notes交接说明。4.1 工作流规范中的planner角色工作流把路由规则固化为规范。以 conveyor.yaml 为例其中planner角色的定义为planner: skill_refs: [openrig-user, requirements-writer] preferred_targets: [plan-plannerconveyor]对应步骤- id: plan actor_role: planner objective: Turn the packet into an executable plan with verification. allowed_exits: [handoff, waiting, failed] next_hop: mode: require suggested_roles: [builder]关键语义next_hop.mode: require表示该步骤完成后必须发生交接不允许原地逗留suggested_roles: [builder]给出下一跳的建议角色而preferred_targets决定落到哪个具体席位这里是plan-plannerconveyorallowed_exits中handoff之外的waiting/failed是计划的诚实出口——输入不足就waiting无法规划就failed。这套projection/exit机制在测试中可直接观测规划工位以exit: handoff投影后运行时返回的nextStepId为build、nextOwnerSession为plan-plannerconveyor的下一跳。慢速教学版 basic-loop.yaml 结构相同只是把同一批席位按单包一步步走完并设置了max_hops: 10的循环护栏。五、四条原则规划的反模糊哲学角色定义用四条原则约束规划行为它们共同指向一个中心思想——有用的计划消除歧义而不是扩大范围消除歧义而非扩张范围计划的价值在于把要做的事钉死。任何让构建工位需要重新猜度、或顺势加戏的表述都是失败的。构建工位应确切知道完成意味着什么完成标准completion是计划的验收面。结合verification-before-completion这意味着计划里必须写清跑什么命令、看到什么输出、才算完成。偏好一个可验证的结果胜过宽泛的工作主题宁可把一包工作收敛到一个可验证的成果也不要给出改进系统性能这类无法判定的主题。这直接继承自 requirements-writer 的验收标准必须可观察。让工作流证据对新用户可读planner 的产出会被后续工位和新的 OpenRig 用户阅读证据链要能让新人顺着 objective → assumptions → steps → verification → handoff notes 就能看懂整包工作的来龙去脉。这四条原则在 Conveyor 文化CULTURE.md里也能找到对应物Keep every handoff explicit in the queue交接必须在队列中显式化、If a packet is blocked, the owner records the blocker and target instead of silently waiting阻塞必须记录 blocker 与目标而不是静默等待——后者正是职责 5诚实标记阻塞的文化底座。六、与上下游工位的协作契约规划工位不是孤岛它与另外三个工位通过队列交接构成契约链。三份角色定义彼此呼应上游 intake-leadlead/guidance/role.md把粗糙请求整理成规划工位可以动手的队列工作包保持工作流实例诚实当前所有者、下一所有者、终止状态始终可见处理背压——plan/build/review 积压时就停止投喂新包。下游 build-builderbuilder/guidance/role.md先读计划再动手Read the plan before editing or producing an artifact把实现范围钉在工作包上运行与改动匹配的验证命令然后带改动的文件、跑过的命令、残余风险三件套交接给review-reviewerconveyor。planner 的无猜测计划直接决定了 builder 能否做到这一点。末端 review-reviewerreviewer/guidance/role.md对照计划、声称产出与验证证据三方审查只有存在具体修复时才把返工发回 build普通队列交接放行时带紧凑证据摘要交给 intake-lead 关闭。三份 AgentSpec 都通过imports: [local:../../shared]引入共享资源并装载shared:openrig-core插件planner 与 reviewer 默认 runtime 为 codexlead 与 builder 默认 runtime 为 claude-code——这本身就是用不同模型交叉制衡的编排示例。七、实操演练在 conveyor 上观察规划工位7.1 启动与首个工作包按 conveyor/README.md启动并投喂一个示例目标rig up conveyorDraft 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起草清单review-reviewerconveyor核查结果intake-leadconveyor携带证据关闭工作包。7.2 规划产物的样子按 startup/context.md 的格式要求一份合格的规划输出应包含五个字段。以示例工作包为例## Objective 产出一份 CLI 工具的发布就绪清单5 项检查 1 条验证命令。 ## Assumptions - 工具已通过 CI 基本构建本清单面向发布前人工复核。 - 不包含打包、签名等超出本包范围的议题。 ## Steps 1. 起草 5 项检查功能冒烟 / 文档 / 版本号 / 变更日志 / 回滚预案。 2. 为每项检查标注验证方式附 1 条可执行验证命令。 ## Verification - 清单文件存在且恰含 5 项检查 - 验证命令可在仓库根目录运行并输出预期结果。 ## Handoff Notes 交接给 build-builderconveyor残余风险清单未覆盖安装包签名。这份产物的每个字段都能回溯到技能与职责objective/assumptions 来自 requirements-writer 的边界意识steps/verification 来自 role.md 的三要素要求verification 的可观察判定来自 verification-before-completion。7.3 源码级验证运行时确实按此流转conveyor-starter.test.ts 是这套流转的直接证据它验证了三件事内置工作流规格conveyor与basic-loop都能通过WorkflowValidator校验步骤序列严格为[intake, plan, build, review, close]入口角色为intake协调终端轮次规则为hot_potato多实例并发同一 Rig 上可同时存在两个活跃的 conveyor 工作流实例互不干扰——规划工位处理 A 包时B 包仍停留在intake步骤basic-loop 端到端测试逐级以exit: handoff投影断言每一步的nextStepId与nextOwnerSession依次为plan/build/review/close并在close步骤以exit: done收束后实例状态为completed、currentFrontier为空。其中测试还断言了 review 的拓扑边同时包含review→close放行路径与review→build返工路径——这意味着规划工位不必处理返工路由返工由 review 用普通队列交接发回 build工作流只管正向推进。规划工位的路由职责被精确限制在把计划通过工作流投影交给 builder这一件事上。八、复用边界planner 不止属于 conveyor最后值得强调conveyor-planner是一个被多个 Rig 复用的通用角色。规划工位的 AgentSpec 描述、启动上下文与角色定义都刻意不绑定具体 Rigagent.yaml 中的name: conveyor-planner是 Agent 的仓库内标识startup/context.md 明确this planner is reused by multiple rigs该规划工位被多个 Rig 复用并给出factory-rsi的对照实例role.md 的职责 4 用derive from runtime facts dont hard-code约束身份推导。因此若读者要把它用于自己的 Rig正确做法是在工作流规范的roles.planner.preferred_targets里填入本 Rig 的席位地址如plan-plannermyrig而不是修改角色卡本身。规划工位的可复用性正是通过这种提示词不写死、运行时来推导的机制实现的。结语Conveyor Planner 用一份不足五十行的角色定义承担了流水线中消除歧义、约束规模、诚实标记的关键职能。它的方法论可以概括为一句话把一包模糊的工作变成一份构建工位无需猜测、并能用证据证明完成的计划。在 OpenRig 的体系里这既是 AgentSpec 与工作流规范conveyor.yaml协同作用的实例也是多智能体交接必须依赖持久化队列与可验证证据而非私人对话这一核心文化的具体落点。想要深入实践可以从阅读 role.md、startup/context.md 与 conveyor-starter.test.ts 三份文件开始。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐用 create-plan 命令把需求文档转化为可执行实现计划claude-agent-sdk-demos 的 PRP 规划工作流实战用 create plan 命令把需求文档转化为可执行实现计划claude agent sdk demos 的 PRP 规划工作流实战 导读 本篇文章围绕 c示例工程oh-my-claudecode 的 Planner 智能体解析结构化访谈、共识规划与可执行工作计划的完整实现oh my claudecode 的 Planner 智能体解析结构化访谈、共识规划与可执行工作计划的完整实现 导读 本文基于 oh my claudecod人工智能AI Agent多智能体Agent 编排Agent 工作流AI 技能CLI开发工具oh-my-codex Planner 角色深度解析Prometheus 式证据驱动规划工作流oh my codex Planner 角色深度解析Prometheus 式证据驱动规划工作流 PlannerPrometheus是 oh my code人工智能AI AgentAgent 编排Agent 工作流CLI开发工具AI 技能上一篇对比测试gemma-4-e4b-it-OptiQ-4bit vs 标准4位量化模型 - 性能提升13.57%的奥秘下一篇一次配好六端发布Godot 导出与多平台发布实操指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考