规划与任务分解
规划与任务分解:把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划,以架构、轨迹与故障重放完成工程验收。
学习目标
- 能解释“规划与任务分解”如何把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划
- 能区分任务分解、任务图、先规划后执行、重规划、验收条件,并标出控制权、状态和副作用边界
- 能冻结输入与版本,沿以下证据定位首个分叉:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果
- 能注入“计划只列自然语言步骤,没有依赖或验收器,某一步失败后仍把后续全部标为完成”,完成阻断、恢复、复位和同输入重放
来源、课程身份与适用边界
“规划与任务分解”以Anthropic 公开全文《Building effective agents》建立工程总纲,并用Anthropic《Building effective agents》核对本章机制。
这不是一本名为《AI Agent 开发实战》的官方出版物,也不存在官方十四章目录。平台把公开工程文章、官方开发文档和原始论文重组为 14 个工程单元;下列 112 个节点是站内课程地图。正文、代码、图表、实验与练习均为独立教学重写,模型、API、协议或安全边界变化时必须重新验证。
本单元的八个工程坐标
- 规划与任务分解:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 1 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 小特接了个大活,不能想哪做哪:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 2 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 为什么要先规划:复杂任务得先谋全局:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 3 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 任务分解:把大目标拆成一棵任务树:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 4 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 三种规划策略:CoT、ToT、先规划后执行:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 5 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 反思与重规划:计划不是定死的:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 6 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 动手一:三种策略,这题该用哪个:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 7 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
- 动手二:计划行不通,怎么绕过去:这是“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的第 8 个工程坐标;必须进入机制解释、运行轨迹或故障证据,不能只停在目录。
术语与运行合同
↡任务分解:把目标拆成可执行且可验收的子任务;在“规划与任务分解”中按以下证据核对:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。、↡任务图:用节点和依赖边表示执行关系的结构;在“规划与任务分解”中按以下证据核对:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。、↡先规划后执行:先形成显式计划,再按计划调用工具的策略;在“规划与任务分解”中按以下证据核对:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。、↡重规划:环境反馈否定原假设时修改剩余任务的过程;在“规划与任务分解”中按以下证据核对:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。、↡验收条件:确定性判断一个任务是否完成的规则;在“规划与任务分解”中按以下证据核对:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。。
本页不变量是:计划中的每个任务都有输入、输出、依赖、责任主体和可验证完成条件。任何“成功”结论都要保存目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果;模型自评、最终措辞和单次 demo 都不能替代环境事实。
工程机制与反证实验
分解要落到可执行边界
“研究并解决”仍不可执行,子任务要明确产物、工具和完成条件。
动手验证:把模糊节点继续拆分,直到可由单次工具或检查器处理。
依赖决定并发与顺序
没有依赖图就无法判断哪些任务能并行,也难以阻断下游。
动手验证:删除一个前置产物,确认所有依赖节点保持 pending。
计划不是事实
模型写出的步骤是假设,执行观察可能要求换路或缩小目标。
动手验证:让关键 API 不可用,检查计划是否产生替代路径。
重规划必须有限
每轮全量重写计划会抖动并消耗预算,应只修改受影响子图。
动手验证:连续制造同类失败,确认达到上限后转人工。
从架构到故障重放
1. 架构复杂度实验
在“规划与任务分解”中切换简单基线、受控工作流和自主循环,先判断“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”是否真的需要更高自主性,再比较延迟、成本、可观测性与风险。
Architecture decision laboratory
规划与任务分解
把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划
不变量:计划中的每个任务都有输入、输出、依赖、责任主体和可验证完成条件
最小可运行切片
const plan = validateTaskGraph(await planner(goal));
for (const node of topologicalOrder(plan)) {
if (!dependenciesPassed(node, plan)) continue;
const observation = await executeNode(node);
record(node, observation);
if (!node.acceptance(observation)) {
await replanAffectedSubgraph(plan, node, { maxReplans: 2 });
}
}
return verifyGoal(plan, goal);切片只表达“把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划”的核心合同。生产实现还要补齐持久化、超时、密钥隔离、结构化日志、幂等和批量评测;如果不能重新取得目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果,代码跑通也不能证明机制正确。
练习与答案
练习
问题 1:最小证明。 怎样用正常、边界和单故障三类样本证明“计划中的每个任务都有输入、输出、依赖、责任主体和可验证完成条件”?
问题 2:节点覆盖。 规划与任务分解、小特接了个大活,不能想哪做哪、为什么要先规划:复杂任务得先谋全局、任务分解:把大目标拆成一棵任务树、三种规划策略:CoT、ToT、先规划后执行、反思与重规划:计划不是定死的、动手一:三种策略,这题该用哪个、动手二:计划行不通,怎么绕过去如何从目录词变成工程证据?
问题 3:恢复验收。 怎样证明“计划只列自然语言步骤,没有依赖或验收器,某一步失败后仍把后续全部标为完成”已经修复?
本章回顾
- “规划与任务分解”解决的是把大目标拆成带依赖和验收条件的任务图,并在环境反馈否定假设时有限重规划。
- 核心不变量是计划中的每个任务都有输入、输出、依赖、责任主体和可验证完成条件。
- 首要反例是计划只列自然语言步骤,没有依赖或验收器,某一步失败后仍把后续全部标为完成。
- 最小证据包包含目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。
名词解释
本章出现的专业名词,用大白话再讲一遍。
- 任务分解
把目标拆成可执行且可验收的子任务。在“规划与任务分解”中必须能按以下证据重新定位:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。
- 任务图
用节点和依赖边表示执行关系的结构。在“规划与任务分解”中必须能按以下证据重新定位:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。
- 先规划后执行
先形成显式计划,再按计划调用工具的策略。在“规划与任务分解”中必须能按以下证据重新定位:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。
- 重规划
环境反馈否定原假设时修改剩余任务的过程。在“规划与任务分解”中必须能按以下证据重新定位:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。
- 验收条件
确定性判断一个任务是否完成的规则。在“规划与任务分解”中必须能按以下证据重新定位:目标版本、任务图、依赖、计划变更、工具观察、失败原因、重规划次数与验收结果。