• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI

导读

在 OpenRig 的多智能体编排体系里，Conveyor（传送带）是一套用于学习队列交接与工作流实例的启动 Rig（starter rig），而conveyor-planner是其中负责"把已接受的工作包变成一份有界计划"的规划工位。本文以该角色的完整角色定义（guidance/role.md）为主线，结合其 AgentSpec、启动上下文、工作流规范与源码测试，讲清规划工位在流水线中的定位、技能栈、输出结构与交接路由规则，让读者能够直接理解并复现这一"规划即约束"的协作模式。

一、角色定位：为什么流水线需要一位"规划工位"

OpenRig 是一个把 Claude Code 与 Codex 编排进同一系统协同工作的多智能体 harness。Conveyor 启动 Rig 在 rig.yaml 中定义了四个 Pod，构成一条紧凑的工位流水线：

四条delegates_to边串起主流转：intake.lead → plan.planner → build.builder → review.reviewer；另有若干can_observe边允许 review 观察 build 与 intake、intake 观察 build 与 review，支撑返工与状态跟踪。

conveyor-planner的 agent.yaml 将其定义为"可复用的规划工位"（reusable planning station）：

Turns accepted packets into small executable plans —— 把已接受的（accepted）工作包转化为构建工位无需猜测即可执行的小型计划。

关键词有两个：

• 已接受（accepted）：规划工位不负责澄清原始需求、不负责接收"随口一句话"，它处理的是已经过 intake 受理、进入队列的工作包（packet）。
• 可执行（executable）且无猜测（without guessing）：计划必须把"完成意味着什么"说死，构建工位照单执行即可。

这份角色定义位于 role.md，是该 Agent 每次启动时通过startup.files以send_text方式强制注入的两份引导文件之一（另一份是 startup/context.md）。

二、规划工位的四项核心职责

角色定义把规划工位的职责收敛为五条，可归纳为"读 → 写 → 控 → 交 → 标"五个动作：

1. 读懂工作包（Read the packet）：阅读被分配的工作包，识别出具体、可验证的成果（concrete outcome），并明确点出任何缺失的输入（missing input）。"命名缺失输入"意味着：如果工作包本身信息不足，这不是规划工位的猜测空间，而是需要向上游请求补充的显式输入。
2. 产出简短计划（Produce a short plan）：计划必须包含三要素——预期文件（expected files）、命令（commands）与验证（verification）。三者的组合让"完成"变成可核查的客观状态，而非模糊的工作主题。
3. 控制单轮规模（Keep the plan small）：计划要小到"一个构建轮次（one build turn）"就能完成。这与 Conveyor 的整体文化一致——CULTURE.md 明确要求"偏好能无需额外协调仪式就从受理走到审查的小工作包"。
4. 推导身份与路由（Derive seat and route）：用rig whoami --json推导自己的实际席位，再根据被分配的工作包与所选工作流推导下一个角色/目标；不硬编码起始地址（Do not hard-code a starter address）。路由规则的完整展开见下文第四节。
5. 诚实标记阻塞（Mark blockers honestly）：如果仅凭现有输入无法规划出工作包，必须如实标记 blocker，而不是编造一个看似合理的计划蒙混过关。

其中第 4 条是规划工位区别于"静态角色卡"的关键：planner 不是 conveyor 专属的席位，它被多个 Rig 复用，因此身份与下一跳必须从运行时事实推导，而不是写死在提示词里。

三、技能栈：规划工位装载的五项技能

角色定义声明 planner 装载了五项技能，它们决定了规划工位"用什么方法干活"。可从 openrig-skills/SKILL.md 的技能索引和对应 SKILL.md 中逐一印证：

3.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 中的路由要求进一步操作化：

1. 先自证身份：任何拓扑论断（topology claim）之前先跑rig whoami --json，从结果推导实际席位与所属 Rig。planner 被多个 Rig 复用，所以"我是谁、我在哪条流水线"必须是运行时事实。
2. 默认工作流角色：planner。
3. 读取工作包与工作流：识别发送者、当前步骤、下一角色/目标。
4. 两种路由模式，二选一：
   • 工作流内：激活的工作流拥有内环路由权，计划通过其选定的projection/exit返回，不做并行的队列交接；
   • 工作流外：使用工作包的目的地（destination）对照实际 Rig 解析后交接。
5. 缺失路由上下文是待解析的输入：缺上下文就去解析，而不是猜一个地址。这正是"不硬编码起始地址"的操作含义。

启动上下文还给出了两个对照实例，用于说明"示例不等于身份绑定"：

• 官方conveyor工作流使用plan-planner@conveyor与build-builder@conveyor；
• factory-rsi工作流使用plan-planner@factory-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-planner@conveyor]

对应步骤：

- 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-planner@conveyor）；
• allowed_exits中handoff之外的waiting/failed是计划的诚实出口——输入不足就waiting，无法规划就failed。

这套"projection/exit"机制在测试中可直接观测：规划工位以exit: "handoff"投影后，运行时返回的nextStepId为build、nextOwnerSession为plan-planner@conveyor的下一跳。慢速教学版 basic-loop.yaml 结构相同，只是把同一批席位按单包一步步走完，并设置了max_hops: 10的循环护栏。

五、四条原则：规划的"反模糊"哲学

角色定义用四条原则约束规划行为，它们共同指向一个中心思想——有用的计划消除歧义，而不是扩大范围：

1. 消除歧义，而非扩张范围：计划的价值在于把"要做的事"钉死。任何让构建工位需要重新猜度、或顺势加戏的表述都是失败的。
2. 构建工位应确切知道完成意味着什么：完成标准（completion）是计划的验收面。结合verification-before-completion，这意味着计划里必须写清"跑什么命令、看到什么输出、才算完成"。
3. 偏好一个可验证的结果，胜过宽泛的工作主题：宁可把一包工作收敛到一个可验证的成果，也不要给出"改进系统性能"这类无法判定的主题。这直接继承自 requirements-writer 的"验收标准必须可观察"。
4. 让工作流证据对新用户可读：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-lead（lead/guidance/role.md）：把粗糙请求整理成"规划工位可以动手"的队列工作包；保持工作流实例诚实（当前所有者、下一所有者、终止状态始终可见）；处理背压——plan/build/review 积压时就停止投喂新包。
• 下游 build-builder（builder/guidance/role.md）：先读计划再动手（Read the plan before editing or producing an artifact），把实现范围钉在工作包上，运行与改动匹配的验证命令，然后带"改动的文件、跑过的命令、残余风险"三件套交接给review-reviewer@conveyor。planner 的"无猜测计划"直接决定了 builder 能否做到这一点。
• 末端 review-reviewer（reviewer/guidance/role.md）：对照计划、声称产出与验证证据三方审查；只有存在具体修复时才把返工发回 build（普通队列交接）；放行时带紧凑证据摘要交给 intake-lead 关闭。

三份 AgentSpec 都通过imports: [local:../../shared]引入共享资源，并装载shared:openrig-core插件；planner 与 reviewer 默认 runtime 为 codex，lead 与 builder 默认 runtime 为 claude-code——这本身就是"用不同模型交叉制衡"的编排示例。

七、实操演练：在 conveyor 上观察规划工位

7.1 启动与首个工作包

按 conveyor/README.md，启动并投喂一个示例目标：

rig up conveyor

Draft a tiny release-readiness checklist for a command-line tool. Keep it to five checks and include one verification command.

预期流转：

1. intake-lead@conveyor澄清工作包并交给规划；
2. plan-planner@conveyor把它变成一份小计划（本篇文章的主角登场）；
3. build-builder@conveyor起草清单；
4. review-reviewer@conveyor核查结果；
5. intake-lead@conveyor携带证据关闭工作包。

7.2 规划产物的样子

按 startup/context.md 的格式要求，一份合格的规划输出应包含五个字段。以示例工作包为例：

## Objective 产出一份 CLI 工具的发布就绪清单，5 项检查 + 1 条验证命令。 ## Assumptions - 工具已通过 CI 基本构建；本清单面向发布前人工复核。 - 不包含打包、签名等超出本包范围的议题。 ## Steps 1. 起草 5 项检查（功能冒烟 / 文档 / 版本号 / 变更日志 / 回滚预案）。 2. 为每项检查标注验证方式，附 1 条可执行验证命令。 ## Verification - 清单文件存在且恰含 5 项检查； - 验证命令可在仓库根目录运行并输出预期结果。 ## Handoff Notes 交接给 build-builder@conveyor；残余风险：清单未覆盖安装包签名。

这份产物的每个字段都能回溯到技能与职责：objective/assumptions 来自 requirements-writer 的边界意识，steps/verification 来自 role.md 的三要素要求，verification 的"可观察判定"来自 verification-before-completion。

7.3 源码级验证：运行时确实按此流转

conveyor-starter.test.ts 是这套流转的直接证据，它验证了三件事：

1. 内置工作流规格：conveyor与basic-loop都能通过WorkflowValidator校验，步骤序列严格为["intake", "plan", "build", "review", "close"]，入口角色为intake，协调终端轮次规则为hot_potato；
2. 多实例并发：同一 Rig 上可同时存在两个活跃的 conveyor 工作流实例，互不干扰——规划工位处理 A 包时，B 包仍停留在intake步骤；
3. 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 描述、启动上下文与角色定义都刻意不绑定具体 Rig：

• agent.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 + don't hard-code"约束身份推导。

因此，若读者要把它用于自己的 Rig，正确做法是：在工作流规范的roles.planner.preferred_targets里填入本 Rig 的席位地址（如plan-planner@myrig），而不是修改角色卡本身。规划工位的"可复用性"正是通过这种"提示词不写死、运行时来推导"的机制实现的。

结语

Conveyor Planner 用一份不足五十行的角色定义，承担了流水线中"消除歧义、约束规模、诚实标记"的关键职能。它的方法论可以概括为一句话：把一包模糊的工作，变成一份构建工位无需猜测、并能用证据证明完成的计划。在 OpenRig 的体系里，这既是 AgentSpec 与工作流规范（conveyor.yaml）协同作用的实例，也是"多智能体交接必须依赖持久化队列与可验证证据，而非私人对话"这一核心文化的具体落点。想要深入实践，可以从阅读 role.md、startup/context.md 与 conveyor-starter.test.ts 三份文件开始。

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI