3.1 动态规划与任务分解策略

3.1 动态规划与任务分解策略

复杂任务往往无法通过单一行动完成，需要Agent将高层目标分解为一系列可执行的子任务，并制定合理的执行计划。动态规划与任务分解策略正是解决这一问题的核心能力。本章将从任务分解的理论基础、规划算法、动态调整机制和工程实现四个方面展开讨论。

3.1.1 任务分解的理论基础

HTN规划的核心思想

任务分解的理论根基可以追溯到人工智能领域的层次任务网络（Hierarchical Task Network，简称HTN）规划。HTN规划的核心思想是：复杂的任务可以通过递归地将其分解为更简单、更具体的子任务来求解。与经典的状态空间搜索不同，HTN规划不是在抽象的状态空间中寻找从初始状态到目标状态的路径，而是沿着"任务-方法-子任务"的分解链条，自顶向下地将抽象目标逐步实例化为可直接执行的原子操作。

具体而言，HTN规划包含两个关键概念。其一是"方法"（Method），它描述了如何将一个抽象任务分解为若干子任务（可能是有序的步骤序列，也可能是需要满足一定条件才能选择的多个候选方案）。其二是"操作"（Operator），它定义了可以对世界状态产生实际影响的原子动作。HTN规划器的工作过程就是不断选择合适的方法来分解抽象任务，直到所有叶节点都是可以直接执行的操作为止。

将这一思想映射到Agent系统中，LLM本身就天然地扮演了HTN规划器中"方法选择器"的角色——它根据上下文判断应该采用哪种分解策略，然后输出具体的子任务列表。这一映射关系解释了为什么基于LLM的Agent在任务分解方面表现出了出乎意料的能力：LLM在预训练过程中已经内化了大量关于"如何做事"的层次化知识，这使得它能够为广泛领域的任务生成合理的分解方案，而无需为每个领域手工编写HTN方法库。

为什么需要任务分解

在HTN规划的视角下，任务分解的必要性得到了更清晰的阐释。

降低认知负荷：单个LLM的推理能力有限，同时处理过多信息会降低决策质量。通过任务分解，每个子任务只需要关注局部信息，降低了每步推理的复杂度。从信息论的角度看，任务分解实际上是将一个高维的决策空间映射到多个低维的子空间中，使得每次推理的信息熵显著降低。HTN规划通过层次化分解，确保每个推理步骤的信息复杂度始终保持在LLM的有效处理范围内。

提高执行可靠性：小粒度的子任务更容易验证和纠错。如果一个子任务失败，只需重试该子任务，而不需要从头开始。这在长链路任务中尤为关键——一个包含20个步骤的任务，如果每步的成功率为95%，整体成功率仅为36%；但如果能将步骤独立并支持重试，整体可靠性会大幅提升。HTN规划中的方法可以选择不同的分解方案作为备选，天然地支持了这种容错机制。

支持并行执行：相互独立的子任务可以并行执行，提高整体执行效率。在现代Agent架构中，这种并行能力不仅节省时间，还可以通过对比多个并行分支的结果来提高最终输出的质量。HTN规划生成的方法分解中，无序的子任务集合即为天然的并行候选集。

增强可解释性：清晰的任务分解结构使得Agent的执行过程更容易理解和调试。当Agent出现异常行为时，任务分解树为开发者提供了一个自然的"诊断框架"——可以逐层定位问题出在哪个子任务、哪个决策点上。这种可解释性也是HTN规划相较于端到端黑盒方法的重要优势。

任务分解的质量标准

一个好的任务分解方案应满足以下标准：

完整性（Completeness）：子任务的合集必须覆盖原始任务的全部需求，不能遗漏关键步骤。在工程实践中，完整性的验证通常依赖于"子任务检查清单"——在分解完成后，逐一确认原始需求的每个方面都有对应的子任务覆盖。在HTN规划中，完整性等价于所有抽象任务最终都被分解为可执行的原子操作，不存在无法进一步分解的"悬空"节点。

原子性（Atomicity）：每个子任务应该足够小，以至于可以通过一次或少数几次工具调用完成。一个实用的判断标准是：子任务的描述中不应包含"并且"——如果需要用"并且"连接两个动作，说明这个子任务应该进一步拆分。原子性确保了每个子任务对应HTN规划中的操作层，可以产生确定性的状态变化。

独立性（Independence）：子任务之间的依赖关系应尽可能少，理想情况下每个子任务都可以独立执行和验证。独立性越高，并行执行的空间越大，单一子任务失败对整体的影响也越小。

有序性（Ordering）：子任务之间如果有依赖关系，应明确执行顺序，形成有向无环图（DAG）。有序性不仅影响执行效率，还影响错误传播的范围——将高风险的子任务前置，可以在早期发现和修复问题。

可验证性（Verifiability）：每个子任务的完成状态应能被明确判断（成功/失败/待执行）。可验证性是实现自动化的前提——如果无法自动判断子任务是否完成，Agent就必须依赖人工干预，这大大降低了系统的自主性。

任务分解的层次结构

Agent的任务分解通常呈现出树状层次结构。以"撰写一份行业分析报告"为例，根任务可以分解为"收集行业数据""分析行业趋势""撰写报告""审校与完善"四个主要阶段，每个阶段再进一步分解为2-4个具体步骤。

这种树状结构在实践中有一个重要的工程考量：分解深度并非越深越好。经验表明，三层左右的分解深度（根任务→主要阶段→具体步骤）在大多数场景下是最佳平衡点。过深的分解会导致规划本身的Token消耗激增，而过浅的分解则无法有效降低单步推理的复杂度。此外，分解宽度（每个节点的子节点数）也应当控制——超过7个子任务会显著增加LLM规划出错的概率，这与人类认知中的"7±2"法则高度一致。在HTN规划的术语中，这意味着方法库中每个方法的分解宽度应控制在合理范围内，过宽的分解会使得规划器在选择正确的执行顺序时面临组合爆炸。

3.1.2 任务规划算法

静态规划与动态规划的本质区别

任务规划算法可以分为两大类：静态规划和动态规划。这两者之间的区别不在于"是否生成计划"，而在于"何时生成计划"以及"计划是否可变"。

静态规划要求Agent在开始执行之前，一次性生成完整的任务执行计划。它的核心优势在于执行过程有清晰的路线图，便于进度跟踪和回溯。在实际应用中，静态规划适用于信息相对充分、任务边界清晰的场景。例如"将这篇英文论文翻译为中文并生成摘要"这类任务，目标明确、步骤可预见，静态规划可以高效地产出高质量计划。静态规划与HTN规划中的"前向链式分解"高度吻合——从根任务出发，一次性递归分解到所有叶节点。

动态规划允许Agent在执行过程中根据新获取的信息不断调整和细化计划。它的核心优势在于适应性强——当执行过程中发现初始计划的假设不成立时，可以及时调整方向。动态规划在面对不确定性较高的任务时表现更好，例如"调研某新兴技术领域的发展现状并给出投资建议"这类开放性任务，初始信息不足以制定精确计划，需要边执行边规划。动态规划更接近HTN规划中的"反应式规划"变体——先分解第一层，执行后根据新状态再决定下一层的分解方式。

Plan-and-Solve与ReAct的任务分解效果对比

在当前的Agent规划实践中，两种代表性的规划范式值得关注：Plan-and-Solve和ReAct。它们分别对应了静态规划和动态规划的两种极端实现。

Plan-and-Solve范式采用"先规划后执行"的两阶段模式。Agent首先生成完整的执行计划，然后按计划逐步执行。这种范式的好处是计划具有全局视角，子任务之间的依赖关系可以在规划阶段就被识别和安排。以下是一个经过工程验证的Plan-and-Solve规划Prompt模板：

你是一个任务规划专家。请对以下目标进行分解。

目标：{goal}

请按照以下格式输出你的规划：
1. [步骤名称]：[具体描述]
   - 依赖：无 / 前置步骤编号
   - 预期产出：[描述]
   - 验证方式：[如何判断完成]
2. ...

规划完成后，请自检：
- 是否遗漏了关键步骤？
- 步骤之间的依赖关系是否正确？
- 是否有可以并行执行的步骤？
​

这个Prompt模板的设计蕴含了几个重要的工程考量：首先，要求Agent输出"验证方式"，强制Agent在规划阶段就思考如何判断每个步骤的完成状态，这直接对应了任务分解的"可验证性"质量标准；其次，要求标注"依赖"关系，为后续的DAG调度提供了结构化输入；最后，自检环节引入了元认知——让Agent审视自己的规划质量，这与本书3.3节讨论的反思机制一脉相承。在实际部署中，这个模板的输出通常还需要经过一次后处理，将自然语言的依赖描述解析为结构化的DAG数据。

ReAct范式则采用"边想边做"的交织模式。Agent在每一步都先进行推理（Reasoning），然后执行行动（Action），根据观察结果（Observation）决定下一步。ReAct不需要预先制定完整计划，而是通过逐步的推理链自然地推进任务。ReAct的推理过程本质上是一种"在线分解"——每一步的推理都在回答"当前应该做什么"这个隐含的分解问题。

两种范式的对比可以用一个比喻来理解：Plan-and-Solve像是一个建筑师先画好完整的施工图纸，然后按照图纸施工；ReAct像是一个探险家，每走到一个路口都根据当前看到的风景决定下一步往哪个方向走。

在实验对比中，两类范式的表现呈现出明显的任务类型依赖性。对于结构化程度高的任务（如数据处理流水线、标准化的报告生成），Plan-and-Solve的执行效率和成功率通常更高，因为提前规划可以避免不必要的探索，减少了无效的LLM调用。我们的内部测试数据显示，在文档生成类任务上，Plan-and-Solve比ReAct平均减少约30%的LLM调用次数，同时任务完成率从82%提升到91%。而对于探索性强的任务（如开放式研究、创意性工作），ReAct的灵活性优势更加突出，因为它可以根据执行过程中发现的意外信息及时调整方向——这是静态规划无法做到的。在信息检索与综合分析类任务上，ReAct的任务完成率比Plan-and-Solve高出约12个百分点。

值得注意的是，两种范式并非完全互斥。Plan-and-Solve在规划阶段可以采用ReAct风格的推理链来提高规划质量，而ReAct在执行过程中也可以维护一个轻量级的"意图队列"来保持方向感。理解这两种范式的优劣边界，是设计混合规划策略的前提。

混合规划策略

实际系统中，最有效的方式是结合静态规划和动态规划的优势，形成混合规划策略。这种策略的核心理念可以概括为"粗规划、细执行"：

1. 初始规划阶段：使用静态规划生成高层框架计划（3-5个主要阶段），确定任务的整体结构和执行顺序。
2. 执行阶段：逐步展开每个主要阶段的详细子计划，在展开时利用已获取的信息进行更精确的规划。
3. 监控阶段：持续监控执行状态，当发现执行结果与预期偏差超过阈值时，触发局部的重规划。

混合规划的一个关键工程挑战是重规划触发条件的阈值设定。如果阈值过于敏感，Agent会频繁重规划，导致执行效率低下和Token浪费；如果阈值过于迟钝，Agent可能会在错误的路线上走得太远，浪费大量资源后才发现方向错误。一个有效的实践是为不同类型的信息设置不同的敏感度——对于明确的执行失败（如工具返回错误）应立即触发重规划，而对于模糊的预期偏差（如"搜索结果不太理想"）则可以容忍一定程度的偏差，等待更多信息积累后再决定是否调整。这种分级阈值策略在工程上可以表达为一个简单的优先级规则表：工具报错立即重规划（优先级最高），输出格式不符延迟一步观察（优先级中），内容质量不理想容忍2-3步再判断（优先级最低）。

3.1.3 任务依赖图与执行调度

依赖关系的建模

当任务被分解为多个子任务后，子任务之间往往存在依赖关系。这些依赖关系可以用有向无环图（DAG）来表示和调度。DAG中的每个节点代表一个子任务，每条有向边代表一个"前置依赖"关系——如果任务B依赖任务A，那么A完成后B才能开始执行。

在Agent系统中，DAG的构建通常由两个环节协作完成：LLM在规划时以自然语言标注依赖关系（如"依赖步骤1和步骤2"），后处理模块将这些自然语言描述解析为结构化的邻接表。以下是一个简化但完整的依赖图构建与拓扑调度流程的伪代码描述，它展示了从规划输出到并行执行调度的核心逻辑：

// 构建任务依赖图（从结构化规划输出解析）
DAG = 空图
对于计划中的每个子任务 T:
    将 T 添加到 DAG 中
    对于 T 的每个依赖项 D:
        添加边 D -> T

// 拓扑调度执行
当 DAG 中还有待执行任务时:
    找出所有入度为0且状态为pending的任务 -> 可执行集合
    如果可执行集合为空:
        报告循环依赖错误
    并行执行可执行集合中的所有任务
    对于每个已完成的任务 C:
        标记 C 为 done
        对于 C 的每个后继任务 S:
            减少 S 的入度
​

基于DAG的调度算法（如拓扑排序）可以自动识别出哪些任务可以并行执行、哪些任务必须串行等待。以上伪代码展示了最基础但实用的调度逻辑：每次迭代取出所有入度为零的任务并行执行，然后更新依赖关系，直到所有任务完成。在工程实践中，这个基础框架还需要扩展以支持超时处理、失败重试和软依赖等特性。

在工程实践中，DAG调度器还需要处理一些边界情况。例如，当某个并行任务组中的部分任务失败时，调度器需要决定是等待所有任务完成后再重规划，还是立即中断同组的其他任务。一个实用的策略是引入"软依赖"的概念——某些依赖关系是建议性的而非强制性的，当上游任务失败时，下游任务仍可基于部分信息执行。例如在报告撰写任务中，"市场趋势分析"依赖于"数据收集"，但即使数据收集只完成了一部分，趋势分析仍然可以基于已有数据开始，只是分析结果可能标注为"部分分析"。软依赖的引入使得Agent系统在面对不完美执行结果时具有更好的韧性，避免了"一个环节失败导致全盘停摆"的脆弱性。

另一个重要的工程考量是DAG的动态演化。初始规划生成的DAG在执行过程中可能需要动态调整——某些子任务可能产生新的子任务（"发现需要额外的数据验证"），某些依赖关系可能因为执行结果而改变（"原来计划的竞品对比不再需要"）。支持DAG的在线修改是成熟调度器的重要标志。

3.1.4 规划质量的评估与改进

规划质量的度量维度

评估一个任务分解方案的质量，需要从多个维度进行综合考量：

计划可行性（Feasibility）：计划中的每一步是否都可以被Agent执行？是否存在不可达的步骤或缺少前置条件的情况？可行性是规划质量的底线——一个不可行的计划无论多么"优雅"都是毫无价值的。在实际系统中，可行性验证可以通过模拟执行来检测：在真正执行之前，让Agent快速走一遍每个步骤，检查是否存在明显的阻碍。更高级的做法是构建一个"能力注册表"，记录Agent可用的所有工具及其输入输出规格，然后在规划完成后自动检查每个步骤是否匹配某个工具的能力描述。

计划效率（Efficiency）：计划的总步骤数是否最优？是否存在冗余步骤？是否充分利用了并行执行的可能性？效率评估的一个实用指标是"有效步骤占比"——在最终成功的执行路径中，实际被执行的步骤数与计划总步骤数的比值。如果这个比值过低，说明初始规划中包含了大量无用的步骤。另一个有价值的指标是"关键路径长度"——DAG中最长路径上的步骤总数，它决定了任务的最短完成时间。一个优秀的规划应当尽量缩短关键路径，同时充分利用并行执行来压缩总耗时。

计划鲁棒性（Robustness）：当某个步骤执行失败时，计划是否仍能继续？是否有合理的后备方案？鲁棒性高的规划方案会在关键路径上设置备选方案，并且将高风险步骤前置，以便尽早发现和修复问题。鲁棒性可以通过"单点故障分析"来评估：逐一假设每个步骤失败，检查DAG的剩余部分是否仍然能够产出有意义的部分结果。

计划粒度（Granularity）：子任务的大小是否适中？过粗的子任务难以执行（一步完成不了），过细的子任务增加规划开销（每步都需要一次LLM调用）。粒度的最优值取决于任务的性质——对于高度确定性的任务（如文件操作），粒度可以较粗；对于高度不确定性的任务（如信息检索），粒度应该更细，以便在每一步都能根据新信息调整方向。

任务分解质量的评估方法

在实际工程中，上述维度需要转化为可操作的评估流程。我们推荐一套分层评估方法：

第一层是自动化静态检查，在规划生成后立即执行。检查项目包括：DAG中是否存在循环依赖（拓扑排序的失败即指示循环）、每个叶节点是否匹配已注册的Agent能力、是否存在孤立节点（既无入边也无出边的非根节点通常意味着规划遗漏）。这些检查可以完全自动化，成本极低，应当在每次规划后自动运行。

第二层是模拟执行验证，在正式执行前进行。让Agent以"模拟模式"快速走一遍计划，不实际调用工具，而是基于已有知识和上下文预测每一步的可能输出。模拟执行可以发现静态检查无法捕获的问题，例如步骤间数据格式不兼容、中间产物与后续步骤的输入需求不匹配等。

第三层是执行后回顾分析，在任务完成后进行。记录实际的执行路径与初始计划的对比，计算有效步骤占比、重规划次数、失败步骤位置等指标。这些数据不仅用于评估当前规划的质量，更重要的是作为反馈信号，驱动规划策略的持续优化。

动态调整分解方案的策略

高质量的规划不是一次性完成的，而是在执行过程中不断优化的。动态调整分解方案的策略包括：

局部重规划：当某个子任务执行失败时，只重新规划该子任务及其下游依赖，而不影响已成功完成的部分。这种策略的效率最高，但可能遗漏失败的根本原因。例如，如果"搜索市场规模数据"失败，局部重规划只会尝试其他搜索方式，但不会考虑"也许这个数据根本不存在"的可能性。局部重规划适用于失败原因明确且局部的场景，例如网络超时、API限流等临时性故障。

全局重规划：当执行结果与预期严重偏离时，从头开始重新规划整个任务的执行方案。这种策略虽然开销较大，但能够避免在错误的基础上继续累积错误。全局重规划的触发条件应当设置得足够严格，以避免不必要的资源浪费。典型的触发条件包括：连续两次以上局部重规划仍然失败、执行结果与预期目标的偏差超过预设阈值、发现了与初始假设根本矛盾的新信息。

增量式规划调整：在执行过程中持续微调计划，而不是等到失败后再重规划。例如，当搜索结果比预期更丰富时，可以增加"深度分析"子步骤；当发现某个子任务比预期更简单时，可以合并或跳过后续的详细步骤。这种策略的核心是让Agent保持"对计划的审视意识"——不是机械地按计划执行，而是在每一步都评估"当前计划还合理吗？"。增量式调整的成本最低，但要求Agent具备较高的元认知能力，能够在不中断执行流的情况下进行计划审视。

反思驱动的规划改进

Agent应该在任务执行后反思规划的质量，持续改进自身的规划能力。反思的重点包括：哪些步骤是浪费的？哪些并行化机会被遗漏了？重规划的触发是否及时？初始规划的信息收集是否充分？

一个容易忽视的细节是反思结果的持久化。如果反思产生的经验教训仅存在于当前会话的内存中，那么每次启动新会话时Agent都会犯同样的规划错误。一个成熟的系统应当将反思结果写入结构化的经验库，在未来的规划阶段通过检索增强（RAG）注入规划提示词中，从而实现真正的"越用越聪明"。这种从"经历"到"经验"的转化机制，与本书讨论的反思机制（3.3节）和记忆系统（2.3节）深度关联，构成了Agent持续学习的基础设施。

3.1.5 实际工程中的规划策略

渐进式规划模式

在实际Agent系统中，一种高效的模式是"渐进式规划"：

1. 快速启动：立即执行不需要规划的第一步行动（如信息搜索），避免"过度规划"的陷阱
2. 边做边想：在执行过程中收集信息，同时构思后续计划
3. 计划细化：随着信息积累，逐步细化执行计划
4. 定期检查：每隔几步执行一次计划审查，确保方向正确

渐进式规划避免了"过度规划"的陷阱——在信息不充分时花费过多时间制定详细计划，而不如先行动起来收集信息。在信息检索类任务中，渐进式规划的效果尤其显著。例如，当Agent被要求"分析某个技术框架的优劣势"时，直接开始搜索往往比先花大量时间制定详细搜索计划更高效，因为搜索结果本身就会揭示需要深入探索的方向。

计划模板与模式库

对于常见的任务类型，可以预定义计划模板，提高规划效率和质量。模板提供了结构化的骨架，LLM在这个骨架上填充具体的步骤细节，兼顾了规划效率（模板保证基本结构合理）和规划质量（LLM根据具体任务定制细节）。在工程实践中，我们还可以将历史成功执行的计划作为"案例模板"加入模板库，让Agent在遇到相似任务时直接复用经过验证的规划方案。

实战建议汇总

基于大量实践，以下是任务分解与规划的核心建议：

• 三层分解是最佳深度：根任务→主要阶段→具体步骤，超过三层通常得不偿失。这与HTN规划中方法库的典型深度一致，过深的分解反而会增加LLM在维护全局上下文时的认知负担
• 先"做什么"后"怎么做"：规划阶段只确定意图和预期产出，将具体工具选择推迟到执行阶段，避免过早承诺。这种"意图优先"的策略使得计划在执行时具有更大的灵活性
• 为每个步骤定义验证标准：在规划时就明确如何判断步骤完成，而不是执行完再想。验证标准的明确化是实现自动执行和自动纠错的前提
• 设置重规划预算：限制最大重规划次数（通常2-3次），防止陷入"规划-执行-失败-再规划"的无限循环。超过预算后应当转而寻求人工干预或返回部分结果
• 记录并复用成功计划：将经过验证的计划存入模板库，这是Agent规划能力持续提升的最有效途径。模板库的质量直接决定了Agent在重复性任务上的表现上限
• 警惕过早承诺：规划阶段确定的工具和方法应保持灵活性，执行时根据实际情况调整。过早的具体化会导致计划在面对意外情况时缺乏适应能力
• 选择合适的规划范式：结构化任务优先使用Plan-and-Solve以获得更高的执行效率，探索性任务优先使用ReAct以获得更强的适应能力，复杂混合任务采用"粗规划+细执行"的混合策略

小结：动态规划与任务分解策略是Agent系统处理复杂任务的核心能力。本章从HTN规划的理论基础出发，系统介绍了任务分解的质量标准（完整性、原子性、独立性、有序性、可验证性），对比了Plan-and-Solve与ReAct两种代表性规划范式的适用场景与效果差异，阐述了混合规划策略的设计要点，并深入讨论了基于DAG的依赖图调度、分层质量评估方法以及动态调整策略。在实际工程中，"粗规划、细执行"的混合策略和渐进式规划模式是经过验证的有效方案。反思驱动的持续改进机制和计划模板库的构建，是Agent规划能力从"能用"走向"好用"的关键路径。