goal-driven-workflow

目标驱动的长时间运行工作流

让 Agent 自主运行数小时，以达成一个可验证的目标。主要的执行框架示例：Claude Code 原生的 /goal（条件 + 评估器循环）。此技能还会补充需求对齐、验收分层、子 Agent 上下文管理和运行后报告，并在 /goal 不可用时提供通用备用方案。 阶段 1–3 是只读的设计阶段；阶段 4 是运行阶段；阶段 5 是报告／验收阶段。默认采用手动模式（在每个阶段结束时暂停）。单独调用时，「自动模式」／「自动跑」／"auto mode" 仍会在阶段 1–3 结束时以及阶段 4 启动批准时暂停；不会跳过这些确认，也不会启动执行框架。队列子调用遵循 Stage-exit policy（见下文）。 输出模板：reference.md。

调用约定

• 触发词（依据 description）：「goal 长跑」「goal run」「goal-driven」「目标驱动长跑」「一个 goal 下去跑」「长跑目标」「无人值守跑任务」「goal-run」／goal run、goal-driven、long-run goal、autonomous run、run until done
• 命令形式：/goal-driven-workflow xxx、/goal-run xxx
• 默认行为：将 xxx 视为要作为目标运行的任务；进入阶段 1（澄清）。如果 xxx 已包含具体、可验证的目标和验收标准，则在输出模板 1（冻结块或明确的阶段 1 不适用说明）并获得一次确认后，直接进入阶段 2；该确认即计为阶段 1 完成，可标记为已通过设计检查。
• 不适用：单步编辑、没有可验证最终状态的任务，或更适合通过反复执行 /loop 式轮询或简单的单轮自动批准来处理的任务。按阶段门控 PDCA 设计的单次运行任务（每阶段产出工件并给出判定，而非循环运行直至完成）应直接转交 solve-workflow／opsx-solve-workflow——分派时的执行引擎选择由队列层（goal-driven-queue）负责。

强依赖

Frontmatter dependencies；前置检查必须通过，否则流程将中止：

• clarifying-question-discipline — 阶段 1 澄清
• completion-evidence-discipline — 阶段 2／5 验收证据
• design-approval-gate — 单独调用时，阶段 4 启动批准暂停并进入 Armed（见下文长时间运行流程的差异）
• intake-interview-discipline — 阶段 1 深入信息收集（范围受限的访谈 → 方法比较 → 冻结 → 启动前自查）；阶段 4 运行期间的自行回答规则；阶段 5 台账呈现
• ai-proxy-discipline — 代理检查点（Stage-exit policy: ai-proxy）：缺少模式时的信息收集问答、有界契约批准（Arm，而非 Launch）、阶段 5 报告检查；仅当卡片带有该策略且缺少此技能时才中止
• context-budget-discipline — 阶段 3 上下文计划量化（压缩阈值／阶段→重置边界映射／台账路径），以及阶段 4 在预算里程碑处的阈值检查
• figma-pixel-implement／figma-pixel-verify — 必须已安装；当目标文本包含 figma.com 或 node-id=，或用户要求像素级还原时，加载这两项技能

相关（仅供参考）：solve-workflow（完整 PDCA）；docs/7x24-agent-reliability-handbook.md 的第 8 节。

前置技能检查

启动时、阶段 1 之前，检查每项强依赖。

1. 扫描可用技能
2. 全部存在 → 继续
3. 有任意缺失 → 输出依赖缺失通知（reference.md § 前置技能检查 — 缺失通知）并立即中止

不降级：强依赖缺失时必须中止——绝不静默简化。

---

路径选择（轻量）

长时间运行的规模已由阶段 2 的目标条件和预算体现。对于单文件、高确定性的更改，保持阶段 2／3 精简（一个目标条件 + 最少的子 Agent 规划）；对于多模块／跨领域工作，则完整规划子 Agent 分工和上下文技术。绝不跳过阶段 5（报告 + 人工验收）。

---

阶段概览

阶段	工具权限	手动停止	必需输出
1 澄清与输出约定	❌ 读取/写入	⛔ 停止并等待确认	复述 + 模板 1
2 验收 + 目标条件	✅ 读取；❌ 编辑/写入	⛔ 停止并等待确认	模板 2 + 四部分条件
3 子 Agent 分工与上下文	✅ 读取；❌ 编辑/写入	⛔ 停止并等待确认	模板 3
4 启动长时间运行	✅ 所有权限	独立调用：⛔ 已就绪，等待启动 / 队列子调用：任务卡提供运行内容后开始	模板 4 + 运行日志
5 报告与验收	✅ Bash；❌ 编辑/写入	⛔ 停止并等待确认	模板 5

手动模式会在每个 ⛔ 处暂停。对于独立调用，自动模式仍会在第 1、2、3 阶段以及第 4 阶段的启动审批暂停点（已就绪）暂停；收到明确的启动指令前不会启动执行框架；第 5 阶段始终以人工验收结束。队列子调用遵循 Stage-exit policy，不会进入独立调用的已就绪等待状态。

队列子调用与独立调用

只有当本轮用户/编排器的派发消息已在第 1 阶段输入中内嵌冻结任务卡（至少包含冻结决策区块）时，此调用才是队列子调用。对话历史和磁盘上的 .goal-driven/ 任务卡均不算。不要扫描 .goal-driven/queues/。不要要求调用方未发送的 queue-child 标志。其他所有调用均为独立调用。

独立调用的运行前状态

• 已完成设计检查：第 1–3 阶段已在人类审批环节确认，并且第 4 阶段的启动审批（最终目标条件 + 预算 + 配套检查清单）已确认。跳过前置步骤仍需提供模板 1 + 一次确认（见上文）。
• 已就绪：已完成设计检查。声明长时间运行任务在收到明确的启动指令前不会开始。不要启动第 4 阶段的执行。
• 启动：仅在收到「开跑」 / "launch" / "start the run" / 「开始长跑」（以及明显的同义译法）时，才启动第 4 阶段的执行。以下不是启动指令：「自动模式」 / 「自动跑」 / "auto mode"；单独的「好的」 / "ok" / 「继续」 / "confirm"。启动后，不要重新询问第 1–4 阶段的问题。未完成设计检查时，拒绝启动并继续完成剩余检查。
• 队列子调用跳过此状态机；任务卡中记录的审批即为启动审批关卡的留痕。

---

阶段 1：明确需求与输出约定

⚠️ 遵循 clarifying-question-discipline（每轮只问一个问题；进行多轮提问，直到明确为止；先澄清，不要急于回答）。 🔒 深入访谈：加载 intake-interview-discipline，并执行其 §A（深入访谈 → 冻结方案 → 有界的启动前自审）。其存在层级决定深入程度：存在（默认）= 针对每项决策提问，并对高影响事项升级处理，同时采用三部分基础结构；明确声明缺失/结构性缺失 = 仅确认一次 + 完整记录，保持不变。 📦 可选的可追溯性：当项目存在 openspec/ 目录且有可用的 openspec CLI（或同等工具）时，将 traceability: openspec | none 作为访谈决策选项提供——默认关闭；项目政策可以强制开启；以用户的明确选择为准。将其记录在模板 1 中。 🎭 阶段退出策略：在模板 1 中记录 manual | ai-proxy | auto（队列子任务继承卡片的 interaction-budget ticket 中的设置；它优先于触发词模式传播）。proxy = ai-proxy-discipline 在列明的检查点（缺失模式下的访谈问答、作为有界预授权的契约审批——授权而非启动、第 5 阶段报告检查）依据其章程代替人类角色；manual = 手动模式暂停；auto = 由谁回答运行期间的问题（指定的例外情况 + §B）。在独立运行中，auto 不得跳过阶段 1–3 的确认，不得跳过阶段 4 的启动审批暂停，也不得视为启动。

1. 重述目标；提取目标 / 交付物 / 约束 / 预期结果。
2. 每轮只问一个最关键的问题，直到不再存在阻碍推进的模糊之处（按 clarifying-question-discipline 选择问题；按 intake-interview-discipline 判定是否完成）。优先采用带推荐答案的结构化单选；如果宿主没有结构化界面，则改用自由文本。
3. 比较并冻结方案——按照已加载的规范执行 §A 步骤 4–6（方案比较 → 冻结 → 启动前自审）；将冻结决策块写入模板 1（reference.md § Stage 1）。
4. 输出约定：就交付物以及“完成”的判定标准达成一致。
5. 预先判断输出与结果（参见阶段 2）：标记哪些标准可由 Agent 自行验证（输出类型），哪些需要人类判断（结果类型）。
6. 填写模板 1（reference.md § Stage 1），包括冻结决策块。

无人值守的访谈：当满足队列子任务判定条件时，内联卡片中的冻结决策将提供本阶段所需信息；如果该卡片没有冻结决策，则以自答模式运行访谈（intake-interview-discipline 集成指南 §4），并将每个答案标记为假设。独立调用不得通过自答完成 Design-checked——在缺少人类角色确认的情况下，拒绝 Launch。

警示信号：在一条消息中罗列多个澄清问题/待确定事项；澄清期间急于回答；尚未澄清就急于进入执行；目标含糊地写成“把它做好就行”；跳过范围/范围外边界；未冻结方案并完成自审（跳过深入访谈的冻结步骤）就启动；将磁盘上的 .goal-driven/ 卡片当作队列子任务的输入来源。

阶段 2：验收标准 + 目标条件

目标条件源自冻结后的方案（阶段 1 冻结）：本阶段在此基础上补充验收标准，不会重新审视方向。如果冻结后的方案在此处看起来有问题，应在启动前指出，而不是启动后。

1. 将验收标准分为三个层级（reference.md § 阶段 2 — 模板 2）：

   • 硬性（可由机器验证）→ Agent 自行验证；这些将成为目标测试框架的条件
   • 软性（LLM 评审 + 确定性检查器）→ 可选质量门槛
   • 人工（结果类型）→ 在阶段 5 由人工验收
   • 当目标文本包含 figma.com 或 node-id=，或用户要求像素级还原时，像素几何属于硬性。该子串就是范围事实。指定的检查项是 figma-pixel-verify 中的 scripts/check-figma-verify-report.mjs 以 0 退出。这些条目既不属于软性，也不属于人工。探测可见文本、可见性标志或列表长度，都不能满足硬性条目。在运行期间加载并遵循 figma-pixel-implement 和 figma-pixel-verify。当同一文本还包含 参考、match the existing 或 same as 时，将该事实传入 verify，使所命名控件的交互状态成为条目。

2. 使用四个部分设计目标条件。主要测试框架（/goal）的评估器只读取对话记录，不会运行命令或读取文件，因此条件必须能由 Agent 自身的输出证明：

   <one measurable end state> + <stated check: how the agent proves it> + <constraints that must not change> + <budget clause: "or stop after N turns / N minutes">
   

   • 好：test/auth 中的所有测试均通过，且 lint 步骤没有问题
   • 好：旧 API 的每个调用点都已迁移且构建成功，20 轮后停止
   • 不好：应用已达到生产就绪状态（对话记录中没有可验证的内容）

3. 预算是强制要求——主要 /goal 测试框架没有内置令牌预算。务必添加“或在 N 轮后停止”（或时间限制）。

4. 将复合目标拆分为一系列顺序目标，每个目标都有自己的可验证终态。

5. 输出模板 2 + 最终的四部分条件以供确认。

开启 traceability: openspec 后，产物映射关系如下：proposal ← 阶段 1 冻结的方案 + 原因，design ← 本阶段的验收标准分层 + 条件，tasks ← 阶段 3 的计划（openspec new change "<slug>"；随着运行进度更新复选框）。

危险信号：条件含糊（无限循环或虚构成功）；在一次测试框架运行中设置包含多个目标的巨型目标；缺少预算限制；可能被悄然违反的约束。

阶段 3：子 Agent 分工与上下文管理

原因：上下文腐化——随着对话记录增长，回忆准确度会下降。将所有内容都保留在同一上下文中的长时间运行会导致性能退化。拆分是必要条件，而非优化手段。

1. 分工原则：主 Agent 负责高层计划 + 综合（以及目标条件）；子 Agent 在干净的上下文中深入工作，并且只返回精简摘要（1–2k 个 token）。
2. 选择上下文技术（reference.md § 阶段 3）：
   • 子 Agent 架构——并行探索 / 多模块工作
   • 压缩——长对话流程；阈值和恢复规则遵循 context-budget-discipline（主动压缩至约占上下文窗口的 60–70%，切勿等到接近上限才压缩）
   • 结构化笔记——由里程碑驱动的迭代工作（NOTES.md / 记忆）
3. 根据 context-budget-discipline 量化上下文计划：明确 (a) 压缩阈值占上下文窗口的比例，(b) 计划生命周期中各阶段→重置边界的映射，(c) 会话交接时使用的日志路径——缺少其中任何一项的计划都无法获得阶段 4 启动批准。
4. 定义每个子 Agent 的任务、最小工具集、输出约定、完成条件和故障处理方式。优先采用独立执行框架（编写者与审阅者分离），以避免交叉偏差。
5. 填写模板 3。

危险信号：主 Agent 吸收子 Agent 的细节（上下文回流）；子 Agent 没有输出约定；工具集不受限制。

第 4 阶段：启动长时间运行

启动审批（独立执行）：加载 design-approval-gate，了解审批模式。确认最终目标条件、预算和配套检查清单。确认后进入 Armed 状态，且绝不能启动运行框架——低影响运行和自动模式下也不例外（design-approval-gate 的通用自动豁免不跳过此暂停）。高影响条件（无人值守／大额预算／不可逆）也由同一暂停流程处理；它们不会额外触发一次“审批即启动”步骤。队列子任务将卡片中记录的审批作为留痕，不执行此独立暂停流程。

启动指令（独立执行）：仅在进入 Armed 状态且收到上述封闭列表中的明确启动语句后，才开始执行。「自动跑」／"auto mode"／单独的确认都不算启动指令。代理可以完成 Design-checked；绝不能发出 Launch。

1. 启动前检查（意图优先；参见 reference.md § 第 4 阶段）。主要运行框架示例见括号：
   • 每轮项目约定文件，位于仓库根目录（例如 CLAUDE.md）——记录架构、编码约定和验收规则，确保多轮执行一致。
   • 编辑后验证钩子（例如 PostToolUse lint/type-check）——在运行过程中发现问题。
   • 自动审批模式，用于常规工具写入——否则，长时间运行会因每次文件写入而停滞。
   • 随运行一并携带冻结决策：运行提示词／契约应包含冻结方案和工单台账路径（intake-interview-discipline）；启用可追溯性时，还应包含 openspec 变更路径，以便运行过程无需人工介入即可回答“冻结了什么”。
   • 确认第 2 阶段确定的预算（轮数／时间／令牌）。
2. 启动（根据环境选择）：
   • 交互式目标运行框架：例如，在可用时使用 /goal <condition>。
   • 包装运行框架的非交互式 Agent CLI：例如，claude -p "/goal <condition>" --output-format stream-json --verbose。
   • 备用方案（没有目标运行框架时）：手动执行有界循环——开展工作 → 根据验收清单验证 → 未达标则继续（受预算限制）→ 否则停止；必须明确规定停止条件。
3. 运行中的决策规则：运行期间的决策遵循 intake-interview-discipline §B（自行作答优先级：冻结契约 → 已调查的事实 → 保守默认值；若有证据推翻冻结方案 → 干净停止 + 工单报告，绝不能悄然转向）。
4. 监控：检查运行框架状态（已用时长、轮数、令牌数、评估器最新原因）；通过环境的取消控件（例如 Ctrl+C / /goal clear）提前中断。每到一个预算里程碑（预算每消耗一半／三分之一），记录一行运行日志——评估器原因、剩余预算、异常情况；每到里程碑时，还要根据 context-budget-discipline 评估上下文压缩阈值（已达到 → 在下一个安全点重置，先记入台账）；持续无进展时，应提前中断，而不是耗尽全部预算。
5. 输出 模板 4。独立执行时：如果 Design-checked 尚未完成，则拒绝 Launch 并继续检查；如果已进入 Armed 状态，则等待封闭列表中的启动指令；只有收到后才启动运行框架。队列子任务则根据 Stage-exit policy 开始执行（卡片审批已留痕）。

危险信号：未启用自动审批模式（运行会因写入而停滞）；没有预算；没有每轮约定文件；用一个庞大的目标取代目标链；运行过程中悄然改变方案（违反 intake-interview-discipline 铁律 2）；Design-checked 尚未完成就启动运行框架；将「自动跑」或单独的 "ok"/"confirm" 视为启动指令；将启动审批与开始运行合并进行。

阶段 5：完成报告与人工验收

遵循 completion-evidence-discipline：任何“完成 / 通过”的声明都需要本轮新鲜证据（命令输出 / 测试结果 / 文件差异）。将每项标记为 Executed（命令 + 输出摘要）或 Pending（需要人工操作）。

1. 主 Agent 编写一份结构化完成报告（reference.md § 阶段 5 — 模板 5）：目标回顾、验收状态（硬性 / 软性 / 人工）、编号验证清单——目标达成情况与重述的契约 / 冻结方案对比 + 偏差 / 测试与证据（带 Executed–Pending 标签）/ 副作用（分为功能性 + 非功能性）/ 端到端逻辑审查——交付物 + 验证证据、遗留问题 / 风险、开销，以及决策 / 假设台账（intake-interview-discipline §C — 提请人工判断尚未解决的工单、低置信度假设，以及出错后影响重大的条目；包括干净停止的工单）。使用 Stage-exit policy: ai-proxy 时，清单须交由新上下文代理根据 ai-proxy-discipline 审核（带标签的判定结果）；未通过的项目退回重新验证或创建工单。
2. 启用 traceability: openspec 时：对变更运行 openspec validate，并在机器可验证的证据齐备后将其归档（同步主规范），并将两者记录为报告证据项。结果类型的发现应作为新变更或修订后的变更反馈，而不是作为归档阻碍。
3. 人工验收：
   • 机器可验证的项目：由 Agent 报告 + 抽查。
   • 结果级项目：由人工判断——测试框架评估器验证输出，绝不验证结果。
4. 反馈循环：验收发现将反馈到下一轮的模板 1。

警示信号：没有证据就声称“完成”；Agent 自动将结果级项目标记为通过。

---

模式生命周期

• 手动（默认）：在阶段 1、2、3、第 4 阶段的启动审批暂停点（已就绪）以及阶段 5 暂停。启动仍需要一条封闭列表指令。
• 自动（「自动模式」/「自动跑」/“auto mode”）：在独立运行中，仍会在阶段 1、2、3 和第 4 阶段的启动审批暂停点暂停；不会跳过这些确认；不会启动测试框架（自动模式相关词语不等于启动指令）；阶段 5 始终以人工验收结束。在队列子任务中，按照 Stage-exit policy 决定由谁回答运行中的问题；不要再插入第二次已就绪等待。
• 恢复手动模式：自动模式始终会在完成时（包括阶段 5 验收后）或任何中断时恢复为手动模式。重新进入自动模式需要明确触发；隐式继续不会重新激活自动模式。
• 长时间运行专属规则：运行结束时（达成目标或预算耗尽），将控制权交还给人工——未经明确确认，不得自动开始新目标或自动延长预算。

---

常见错误

错误	后果	修正方法
没有确定性检查器就自行修正	“修复”反而使原本正常的结果变差	仅针对确定性检查器失败进行迭代；每次修复后都重新验证
Agent 将结果级项目标记为通过	没有真正验收就声称“完成”	结果类型标准应由人工在阶段 5 判断
将主测试框架 CLI 视为唯一平台	其他 Agent 无法运行此技能	遵循第 4 阶段中意图优先的启动方式 + 通用回退方案