先记住这个答案
当任务有稳定的阶段结构、多个可复用处理方法，且一次展开所有细节会消耗过多上下文时，可以采用分层任务分解。顶层保留目标和里程碑，下层在事实足够时展开，叶子节点对应可执行、可验证的动作。形式化 HTN 通常还包含任务、分解方法、前置条件和动作模型；LLM 写出缩进大纲并不自动获得这些约束或规划保证。简单任务应先评估分层带来的协调成本是否值得。
- 先稳定目标与阶段，临近执行时再展开不确定细节
- 叶子任务需要输入、产物和检查条件，父任务另有整体验收
- 多级文字大纲不等于具备形式化模型的 HTN 规划器
哪些任务适合分层
例如迁移一个中型应用，可以先分成现状调查、方案选择、模块迁移和整体验收，再按模块展开具体修改。不同模块可能复用同类方法，但输入和风险不同。上层关注迁移是否满足目标，下层关注某个模块的实际行为，避免每次工具调用都重述整个项目。
如果任务只是读取一个文件并回答一个明确问题，增加规划器、阶段管理和多轮汇报可能比直接执行更慢。是否采用分层应观察任务成功率、返工和总成本，而不是根据任务名称是否包含复杂两个字决定。
怎样从大纲走到可执行任务
每次分解要给子任务分配明确输入和产物，并说明这些产物如何支持父任务。例如完成兼容性检查，不能只列分析、思考、总结，而应明确运行环境、被检查接口以及发现问题的记录格式。叶子任务执行后用工具证据验收，模型宣告成功本身不是证据。
分解方法也要有适用条件：没有稳定接口时先做探索，已有成熟流程时可以使用固定步骤。这与 HTN 中根据领域知识选择分解方法的思路有关，但如果实际系统没有形式化状态和条件校验，就应把它描述为工程上的分层编排，不承诺算法能够证明计划可行。
控制展开深度与跨层反馈
远期阶段先保持粗粒度，近期任务再展开。调查发现原假设不成立时，把证据向上传递并修改受影响的方法，不必把整棵任务树完全重建。对共享产物应建立显式依赖，不能因为任务属于不同父节点就认为它们可以独立修改同一资源。
分层过深会造成摘要反复压缩、责任模糊和子目标偏离。可以设定展开深度或预算的控制策略，并要求每个子任务说明与父目标的关系。最终验收要回到用户目标，避免所有叶子任务都完成，但遗漏集成行为、性能条件或实际可用性。
容易答错的地方
- 每一层都调用一次模型才算分层
- 层级是决策和状态的组织方式，固定规则和现有工具也能承担部分工作，不必为形式增加推理调用。排查“LLM Agent 分层任务分解与 HTN”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 子任务全部成功就自动完成父任务
- 子任务集合可能遗漏要求，彼此产物也可能不能集成。父层要检查组合后的行为与全局约束。排查“LLM Agent 分层任务分解与 HTN”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
和普通待办列表有什么区别？
分层明确父子任务如何实现目标，并允许根据条件选择或替换分解方法；普通列表通常只记录要做的事项。
每个子任务都必须交给独立 Agent 吗？
不必。同一个执行器也能维护层级任务；是否引入其他执行者应由独立性、上下文收益与协调开销决定。
如何处理计划越来越细却没进展？
检查叶子任务是否能直接执行、是否有完成条件，并停止没有新增信息的重复分解。用实际产物和验证结果衡量进度。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。