第 9 章 Chapter Outline：Planning 与任务拆解

本文件是正文写作蓝图。Plan Brief、任务卡、任务图、并行候选、计划修订规则、停止条件和 API 认证测试案例都是本书的工程模型；它们不是 Plan-and-Solve、ReAct、Anthropic 或 OpenAI Agents SDK 的共同接口、默认行为或安全保证。正文写作当天必须重新核验动态的 REF-030；REF-004 与 REF-028 仅作为研究背景，REF-029 仅作为官方工程建议，均不得被改写为生产编排标准。

章节契约

读者完成后的能力： 能把一个模糊目标转换为包含目标、约束、完成证据、未知项、风险、停止条件和人工升级条件的 Plan Brief；能把它拆为带输入、输出、依赖、副作用边界、验收证据和失败表示的任务卡；能根据证据依赖、共享资源和副作用而非“看起来可以同时做”判断顺序与并行候选；能在新观察出现时局部修订、阻塞或升级，而不把新的计划文本当成执行完成。

前置知识： 已完成第 5 章，理解任务目标、项目规则、资料、输出契约不能混写为一段指令；已完成第 6 章，能把有来源、范围、预算和未知项的资料装入 Context Packet；已完成第 8 章，理解 Skill Contract 只说明可复用能力，不授予权限、也不替代工作流或 Tool。读者应能阅读 Markdown 表格、简单对象、依赖箭头和测试断言。

章节边界： 本章只讨论为什么做、拆成什么、依赖什么、何时停止和何时修订。第 10 章负责把任务状态、检查点、重试、恢复和交接做成工作流；第 11 章负责 Tool 输入、输出和错误协议；第 12 章负责环境、Sandbox、凭证和权限；第 14 章负责人工批准；第 26 章负责多 Agent 的任务隔离。本章不实现 Planner，不规定项目管理系统、DAG 调度器、并发库、真实 API、测试框架或性能指标。

小节蓝图

1. 计划不是步骤清单：先把愿望改写为可判断的 Plan Brief

• 读者问题： 为什么“给 API 增加认证测试，完成后告诉我”不是一个可执行、可交接的计划？
• 叙述任务： 以原创教学场景开场：维护者只给出一句目标，Agent 立刻列出“阅读代码、写测试、运行测试”的三步，却不知道认证方式、目标接口、可访问环境、允许变更、成功证据和停止条件。先区分“目标”“建议步骤”“任务已完成”三件事，再定义本书 Plan Brief 的目标、约束、完成条件、已知未知项、风险、停止条件与人工升级条件。强调 Plan Brief 用于暴露缺口，不是用长文本掩盖缺口。
• 证据边界： REF-028 只能作为“先计划、再拆分并执行子任务”的提示方法背景；REF-029 只能支持在其文章语境中优先选用最简单可行方案的建议。Plan Brief 的字段、判断规则和案例均为本书模型，不是论文方法或供应商产品字段。
• 计划工件： “愿望清单 / Plan Brief”对照表：同一目标分别列出缺失的约束、完成证据、未知项、停止条件和人工升级条件；再给一份可复制但未绑定真实系统的 Plan Brief 模板。
• 验证： 给定“为 API 增加认证测试”，读者能指出至少三个未决问题，并把“无认证契约”“不能确认测试环境”“写入生产凭证”分别映射为研究、阻塞或人工升级，而不是自动补充假设。
• 过渡： Plan Brief 说明整件事是否值得开始；下一步要把它拆成能够独立领取和验收的任务卡。

2. 任务卡：让每个子任务都有输入、输出、证据与停止方式

• 读者问题： 一项子任务缺少哪些信息时，执行者不应开始工作？
• 叙述任务： 定义本书任务卡的最小字段：任务名、要回答的问题、输入、预期输出、前置依赖、允许副作用、验收证据、失败或阻塞表示、负责人或交接对象。通过“查阅认证契约”与“编写认证测试”两张任务卡展示研究任务、实现任务和验证任务的输出不同；“已经阅读”或“生成了一段代码”都不是后续任务可消费的证据。
• 证据边界： 任务卡字段、状态命名、交接方式和验收动作均为本书工程模型。REF-004 可用于说明推理与行动交错时可以跟踪、更新行动计划和处理例外的研究背景，但不定义本书字段，也不证明任务会自动完成。
• 计划工件： 字段责任表：每个字段回答的问题、缺失时的动作、可据此得出的结论与不能得出的结论。表中专门区分“输入存在”“外部动作获准”“任务已验证”三种不同判断。
• 验证： 固定卡片应覆盖：缺认证契约、无测试目标、要求写入但无批准、没有验收证据、无交接对象。每一种缺口都应得到 blocked、requires_approval 或 not_ready 等明确动作，不能填入猜测值后标成可执行。
• 过渡： 单张卡片可被审查，但多张卡片仍可能按错误顺序执行；接下来要把依赖的类型画清楚。

3. 依赖图与并行候选：箭头表示等待的证据，不表示工作看起来相似

• 读者问题： 如何判断两个任务可以并行，而不是因为它们名字不同就同时开始？
• 叙述任务： 从三类依赖解释箭头：后续任务需要前序输出的证据依赖、同一文件/环境/账户会互相影响的共享资源依赖、写入或不可逆动作必须先确认范围的副作用依赖。定义本书的并行候选条件：任务之间没有上述依赖，且输出、资源与验收可以独立观察。强调“并行候选”不是“并行安全”“成本更低”或“执行更快”的承诺。
• 证据边界： REF-030 仅在 OpenAI Agents SDK 的代码编排示例中列举独立任务并行；正文只能引用其“独立”限定，不能外推任意任务图、运行时调度、并发语义、性能或 SDK API。任务图的边类型、检查规则和反例均为本书模型。
• 计划图示： chapter-09-plan-to-task-graph.mmd 将展示：需求 → Plan Brief → 认证契约研究、测试目标确认、测试实现、测试验证、文档更新；图中只将已说明的证据、资源或副作用关系画为箭头，并把可并行项标为“候选”。图不会表示真实 API、测试执行、权限授予或并行调度。
• 验证： 读者能为 API 认证测试案例标出“研究认证契约 → 定义测试断言 → 实现测试 → 运行验证”的证据链；也能解释文档草稿为何可能与研究并行，而与发布说明为何不应在验证证据出现前完成。
• 过渡： 箭头确定了计划内的结构，但不说明计划与 Skill、工作流、Tool 或权限谁负责；边界不清会让“已计划”被误读为“已执行”。

4. 概念边界：计划、Skill、Workflow、Tool 与权限各回答不同问题

• 读者问题： 为什么有一个可复用的测试 Skill、一个任务图和一条 Tool 调用说明，仍不足以执行真实测试？
• 叙述任务： 用同一案例分开五种职责：Plan Brief 说明为什么做、范围与停止条件；任务卡说明每一件子事的输入、输出与验收；Skill 说明可复用能力及其契约；Workflow 记录状态迁移、重试和恢复；Tool 协议描述一次调用；运行环境与源系统授权才判定真实读取、写入与凭证访问。用“计划中有运行测试任务”对比“环境允许实际运行测试”来消除概念跳跃。
• 证据边界： REF-029 对 workflow 与 agent 的区分仅限其官方工程文章的定义和建议；REF-030 对 LLM 编排与代码编排的区分仅限其 Python SDK 文档。跨概念矩阵、职责分配和教学案例是本书模型，不是跨产品架构标准。
• 计划工件： 五列职责矩阵：工件或概念、回答的问题、可产生的工件、不能证明的事项、应升级到的章节。特意列出“计划写了测试命令”“Skill 被选择”“Tool 返回文本”都不能证明测试已通过。
• 验证： 读者能把下列命题判为不成立并说明缺什么证据：“任务已在图上，所以已经运行”“Skill 可选，所以具有凭证”“Workflow 进入执行态，所以外部状态已改变”“Tool 返回成功文本，所以业务验收完成”。
• 过渡： 明确职责后，计划不应在初次写完后冻结；但更新的触发必须是观察和证据，而不是模型继续生成步骤。

5. 计划修订：观察改变局部决策，不能倒写执行历史

• 读者问题： 执行过程中发现未知认证方式、测试环境不可用或断言不成立时，怎样更新计划才不会掩盖失败？
• 叙述任务： 建立本书的更新链：任务输出或观察 → 关联任务卡与证据 → 判断是否影响目标、依赖、范围或风险 → 局部重排、补充研究、阻塞、停止或人工升级 → 保留变更理由。说明新计划只表达下一步候选；它不能将前序任务的未验证输出改写成已完成，也不能删除失败观察来让图“看起来顺畅”。
• 证据边界： REF-004 可以支持推理轨迹帮助跟踪和更新行动计划、处理例外的研究背景；本书的变更记录、局部更新规则、状态语义和关联字段不是 ReAct 或任何产品的实现。
• 计划工件： 计划修订记录模板：触发观察、关联任务、被影响字段、保留/新增/失效依赖、下一步、停止或升级理由、未验证范围。再配一张“发现认证契约缺失”的前后任务图差异表。
• 验证： 读者能在“接口返回 401 但契约未确认”“测试环境无访问权限”“断言与产品文档冲突”三种输入下，分别选择补充研究、环境升级或停止；不能把任何一种记录为“测试已失败且应用已修复”。
• 过渡： 更新能保持计划诚实，但有些条件不能通过继续拆分解决；下一节明确何时停止与何时交给人类决策。

6. 停止、阻塞与人工升级：拆得更细不等于风险更低

• 读者问题： 面对不明确的范围、敏感凭证、共享环境或高风险写入，为什么不应把计划不断细化后继续自动执行？
• 叙述任务： 定义四类停止信号：目标或验收不可判定、关键依赖无证据、需要超出已知权限的动作、风险超过当前任务的授权范围。区分 blocked、requires_approval、stopped 与“尚未开始”，并说明这些状态只描述本书任务模型，不能推断外部系统已经拒绝或接受请求。展示人工升级请求应携带什么：未知项、已知证据、计划影响、可选方案和所需决定。
• 证据边界： 停止分类、升级材料、状态名称和案例均为本书工程模型。REF-029 关于复杂度与方案选择的建议不构成审批、安全或合规规则；具体权限和人工批准在第 12、14 章展开。
• 计划工件： 停止决策表与人工升级模板；表中将“缺认证契约”“需要真实凭证”“可能改动共享测试环境”“无法确认验收标准”分别对应补证、批准、隔离或停止，且不提供自动绕过路径。
• 验证： 读者能解释为什么“为了让计划继续而猜测 token 格式”不合格；并能把一份缺失认证契约的任务卡升级为需要澄清的请求，而不是构造真实密钥、端点或测试结果。
• 过渡： 前六节给出通用拆解规则，最后用一个纯教学案例把 Plan Brief、任务卡、依赖、修订与停止条件串成可审查的闭环。

7. 完整工程案例：将“为 API 增加认证测试”拆成可审查的计划

• 读者问题： 在不连接真实 API、不运行真实测试的前提下，如何判断一个测试计划是否已经具备开始条件？
• 叙述任务： 设计原创、纯教学案例：输入是一句需求与假设快照，目标是为虚构服务增加认证测试。Plan Brief 明确目标、只读研究边界、缺失认证契约和不可访问环境；任务卡拆为研究认证契约、确认测试目标、设计断言、实现测试、运行验证和文档更新。案例通过依赖图显示哪些任务等待证据，哪些任务只是并行候选；遇到凭证或环境不明时停在升级，而不填造 endpoint、token、HTTP 响应或测试输出。
• 证据边界： 案例、术语、任务卡、依赖、状态和预期输出均为本书教学设计。它不读取真实代码库、不访问网络、不调用模型、Tool、测试框架、文件、环境变量、账户或凭证，也不证明任何 API、认证协议、测试质量、权限或部署行为。
• 计划示例： 09-planning-and-task-decomposition.example-plan.md 将定义纯内存函数，例如 assessTaskPlan。输入为 Plan Brief、任务卡和依赖快照；输出仅为 ready、blocked、requires_approval 或 not_ready，并给出原因、缺失项和允许的下一步。实现不会生成计划、执行任务、调度并行工作或修改外部状态。
• 验证： 最小测试至少覆盖：完整的只读研究任务可准备、缺验收证据阻塞、依赖未满足阻塞、要求外部写入而无批准升级、存在共享环境冲突时取消并行候选。断言只检查纯函数契约，不能把状态名解释成真实测试已运行或 API 已受保护。
• 过渡： 第 10 章会将可执行任务与观察放进可恢复的状态机；第 11、12、14 和 26 章再分别处理真实 Tool、环境权限、人工批准和多 Agent 隔离。本章到此只交付可审查的工作分解边界。

章节工件状态

1. 已完成：Research Brief 与候选参考资料。REF-004、REF-028 至 REF-030 的允许陈述、外推禁区和写作日复核要求已登记。
2. 本阶段完成：Chapter Outline。逐节定义了读者问题、叙述任务、证据边界、计划工件、验证条件和第 8、10、11、12、14、26 章的责任边界。
3. 未开始：First Draft、Fact Check、Mermaid 图源、Example Plan、Example Implementation、Technical Review、Diagram Review、Language Editing 与 Final Review。不得将本 Outline 中的计划图、任务卡、状态或案例写成已经创建、运行或核验的工件。

Outline 完成检查

• [x] 每个主要小节包含读者问题、叙述任务、证据边界、计划工件、验证和过渡。
• [x] 覆盖 Plan Brief、任务卡、依赖、并行候选、概念边界、计划修订、停止升级和 API 认证测试案例。
• [x] 明确区分研究背景、官方工程建议、特定 SDK 文档与本书工程模型，未把论文或产品范围外推为通用编排标准。
• [x] 明确第 9 章与第 8、10、11、12、14、26 章的责任边界，未提前实现工作流、Tool、权限、批准或多 Agent 隔离。
• [x] 图示、示例、案例和验证均标为计划或教学设计，未提前写入正文、Mermaid 源、真实 API、测试框架、Planner、并行调度或运行结果。