context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

workflow_orchestrator_mode

Z3 全文↑ Z2 条目

道-方法 · 道层 skill 全文

← 返回道层 skill 索引 · 返回方法论区

本页是 <code>rules/skills/drafts/workflow_orchestrator_mode.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 rules/skills/drafts/workflow_orchestrator_mode.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）
name: workflow_orchestrator_mode
status: draft (Beta) — 2026-06-15 起草（OD 域）；晋级前需在 ≥1 个真实长复杂任务上跑通"派 worker→检测产物→据剩余推进"端到端，过 landing_gate。**晋级证据已到位（2026-07-03，待人工确认+landing_gate）**：buildout Run3 以本模式（主协调只编排+13 个域编排 lane）真实跑通 22h campaign，13/13 域关闭（CAMPAIGN_CLOSED_BOUNDED，真源 Run3/reports/CAMPAIGN_REPORT.md）；并行运行硬规则已沉淀进本文「多编排者并行运行硬规则」节
description: 纯编排器模式（道）。把一个长而复杂的需求交给主 Agent 时，让主 Agent 退化成只排 phase 的机器——观察状态 → 派独立 worker session（Codex/OpenCode/CC）→ 检测产物是否真完成 → 据剩余持续推进，绝不亲自实现。触发场景：用户说『用编排器模式 / 派 session 跑这个 / 把这个复杂需求拆开派出去做 / 一直推进直到做完』、或一个需求长到主 Agent 会被吸进实现细节而非安排 phase。配套术命令 `orchestrate`。
consumer: orchestrator

纯编排器模式：主 Agent 只排 phase、只派发、只检测、只推进

道 skill。结果确定性优先；实现交 worker session；工具按名引用（路径查 tools/INDEX.md），skill 按名引用（查 rules/skills/INDEX.md）。

consumer: orchestrator（P1A-NEW-011）：本 skill 的消费者是扮演编排者角色的 Agent 自己，不是被派发的 worker——skill_discovery 的 worker 首步发现（OD-9）据此把它排除在 worker 任务的适用 skill 清单之外，避免一个只负责 phase 安排的编排者纪律被误注入进具体执行任务的 worker prompt。字段约定见 bestpractice_skill_writing_guide.md。

一句话

收到长而复杂的需求时，主 Agent 的职责不是"我怎么做完"，是"我怎么安排别人做完"：观察当前状态 → 派一个 worker session 做一件 bounded 的事 → 检测它产物是否真完成 → 据还差什么决定下一步派什么 → 持续推进，直到彻底完成或触到必须人工介入的边界才停。主 Agent 的全部 context 用于编排，实现细节全部下放给 worker session。

解决的真问题

给一个很长很复杂的需求时，主 Agent 会被吸进"怎么完成这项任务"，把 context 烧在实现细节上，而不是"怎么把它拆成 phase 派出去"。结果是单项任务做得有条理，但跨 phase / 同 phase 派多 session 的协调一塌糊涂。本模式用一条纪律（主 Agent 不实现）+ 一组编排原语（每个编排动作一条命令）把主 Agent 钉在编排层，让它没机会滑进实现。

何时用 / 不用

用：需求长、涉及多文件多维度、要拆成多个 phase / 多个 worker session 才做得完；要"派出去做 + 检测 + 持续推进直到完成"；用户点名要编排器模式 / 派 session。

不用：trivial 单步任务（直接做）；单文件小改（直接做）；纯事实查询。判据：这件事值不值得拆成 ≥2 个 bounded 单元派出去——不值就别套编排器。

核心纪律：主 Agent 是纯编排者

主 Agent 在本模式下只做四件事，循环往复：

  1. 观察状态：读当前 phase 计划、已完成的、剩余的 gap（orchestrate status）。
  2. 派发：给当前要做的一件 bounded 事派一个 worker session（orchestrate dispatch）。一个 worker 一件事，≤3 个子任务。
  3. 检测产物：worker 回来后，检测它产物是否真完成（orchestrate check），绝不信 worker 自报 done。
  4. 推进：据检测结果决定下一步——完成则 advance 到下一 phase，没完成则据可定位 gap 派 follow-up（retry/branch），遇到必须人工介入则 await_user。

承重墙（防漂移）：主 Agent 在本模式下禁用 Edit/Write 到实现代码文件，只能写 phase 计划 / handoff / 编排记录。要改实现就派 worker。这条把"不亲自实现"从口头变成可检测约束——主 Agent 一旦自己动手写实现代码，就是脱离了编排器模式。

循环契约（每轮要留下什么）

每轮（派一个 worker → 检测 → 决定）至少留下：派了谁做什么（task_id + channel + result_path）、检测判据与结果（done / remaining 可定位 gap）、下一步决定及理由。这些经 orchestrate 的 receipt 自动留痕，不靠主 Agent 记忆。一轮 = 一个 bounded 单元的派发-检测-决定闭环，不是"把活全干完"。

完成检测纪律（OD-3 / OD-5，承重）

这是模式的承重墙。两层：

判据：worker 说"我做完了"不算数；文件存在不算数；staged 不算 landed。check 返回的 done 是机械 + 独立核验的结果。

Pre-dispatch 信息收集纪律（OO-02，候选 C）

纪律：对于任何声明了 requires_info_gather: true 的 phase，主 agent 在 orchestrate dispatch 前必须先完成以下三步，否则 orchestrate check 会通过 info_gather_gate 直接 FLAG。

三步流程：

  1. 派独立 clean session 收集：用 Agent() 工具（或等价的独立 sub-agent）派一个专门的信息收集 session，让它读取相关文件、skill、设计文档，产出 info_manifest。该 session 只做信息收集，不做任何实现。
  1. 产 info_manifest（最小格式）：
  1. 注入 §6 补充位：把 info_manifest 路径写进 worker prompt 的 §6 补充位，作为仅供参考的信息指针，不作为强制 required_read。

收口检测：orchestrate check 时传 --manifest <路径> --worker-output <结果路径> 给 info_gather_gate（工具路径 tools/info_gather_gate/check.py）：

worker 侧义务（IG2 要求）：收到标记了 requires_info_gather 的 phase prompt 后，worker 在完成工作后必须在产出中写一节 INFO_SUFFICIENCY:，列出信息已充分的条目（satisfied:）和仍不足的条目（unmet:）。不需要完美，但必须写，且 unmet: 非空时应在 §7 遇阻逻辑中标明缺失。示例：

INFO_SUFFICIENCY:
satisfied:
  - orchestrator engine check_phase structure understood
  - gate pattern from intake_gate confirmed
unmet:
  - need production run history to assess false positive rate

向后兼容：未声明 requires_info_gather: true 的 phase，gate 自动 SKIP，不 FLAG，不影响现有 phase 行为。

任务二分 task_type → skill 注入表（OO-02 Slice 2）

设计：轻量 tag 驱动，不做全模板分支。phase 作者在 YAML 里声明 task_type: reading 或 task_type: implementation；dispatch_phase 据此在 dao_skills 基础上追加对应类型的 skill，不改 §3 产出模板、不动 info_gather_gate、漏标退化为默认注入而非报错。

task_type 值域：reading | implementation | 缺省（不写）。其他值在 plan 加载时报 PlanValidationError（早期发现拼写错误）。

注入映射表（维护真源：tools/orchestrator/engine.py:TASK_TYPE_SKILL_MAP）

task_type追加注入的 skill
readingworkflow_precise_reading（精准阅读 + 覆盖义务自查）、workflow_requirement_analysis_quality（需求覆盖质量验收 MC1-MC4）
implementationworkflow_what_to_how_execution_bridge（What→How 执行桥）、workflow_real_task_test_case_design（真实任务测试用例设计）
缺省 / None无额外注入，injected_skills == phase.dao_skills（现有行为，完全向后兼容）

分配执行 session 时的信息读取要求：

实现位置：

向后兼容：未声明 task_type 的 phase（所有现有 phase）注入行为完全不变，已有测试零回归（见 Slice 2 报告）。

派发 worker 首步强制 skill 发现（OD-9，承重）

派出去的 worker 该用哪些 skill，不靠编排者凭记忆在 plan 里手写——手写会漏，漏掉的 skill 永远不进 worker。所以每个 worker 的契约加一条强制首步：执行具体任务前，先派一个 skill-发现 sub-agent，拿本任务描述对照 _DAO_ROUTING（任务特征→skill 路由表）+ skill INDEX，产出适用 skill 清单，worker 读取后在执行中使用。

发现归 worker，不归编排者。编排者留给编排本身（观察状态、派发、检测、额度 / session 调度），把"这个任务该用哪些 skill"的判断下放给 worker，让 worker 轻量自治：开头思考怎么做任务的同时并发派出发现 sub-agent，发现回来就把清单里的 skill 读进来再动手。

三步（worker 侧）：

  1. 首步并发派发：worker 读既有成果（landing 三件套）的同时对自己的任务跑 skill 发现，不阻塞思考。不支持并发的 channel（如 Codex exec 串行）串行跑，但必须在执行任务前完成发现。
  2. 明确产出：发现 sub-agent 出结构化清单——适用 dao / 术 skill 名 + 每条一行理由 + 置信度，落进发现 receipt。
  3. worker 使用：worker Read 清单里每个 skill（与编排者在 skill_injection 给的可选种子的并集），再开始执行。

强制是结构化的，不是 prompt 里一句自觉（本项目历史上口头纪律约 40% 合规）。两层保障：worker prompt 的 §1.5 强制节写明首步发现；发现落 receipt（contexts/runtime/skill_discovery/<task_id>.json），编排者 check 核 receipt 在否——worker 跳过发现，check 直接 FLAG。发现跑在 worker 侧、可见性由 receipt 这个 artifact 兜底，不把发现搬回编排者。

channel 无关：发现 sub-agent 做成命令原语 skill_discovery（tools/skill_discovery/），CC worker 和 Codex worker 都能在首步调它、产物一致；CC worker 也可直接用 Task 工具自派等价 sub-agent。skill_injection 因此从"唯一来源"降级为编排者的可选种子，worker 的强制发现是系统补全层。

动态纪律（OD-7）

不盲目按固定计划走。check 报 remaining 就据可定位 gap 派 follow-up，不强行 advance。phase 计划可带 depends_on，某 phase 阻塞时让位先跑独立的 ready 兄弟节点（DagStrategy）。下一步派什么由主 Agent 对 check 的具体 gap 做判断，不是查死表。"持续推进"靠的是据剩余动态安排后续，不是一次排完所有 phase 就不管了。

遇阻 / 边界

硬规则（从 landing / production push 真实踩坑倒推，非臆测）

多编排者并行运行硬规则（Run3 实战沉淀，2026-07-03）

来源：buildout Run3（13 域并行 campaign，2026-07-02~03，事故与恢复编年史见 adhoc_jobs/context_infra_base_tooling_buildout_20260615/Run3/logs/dispatch_log.md）。全部条目来自实发事故或实测成功，非预测。

验收标准（无上下文 agent 可自判用对了没）

术命令（按名引用）

交叉引用

诚实 claim ceiling / 缺口

← 返回道层 skill 索引 · 返回方法论区