拆解太早会错，拆解太晚会慢：分层任务网络让多智能体编排既灵活又有结构
拆解太早会错，拆解太晚会慢：分层任务网络让多智能体编排既灵活又有结构
一句话版本：多智能体编排的两难——动态调度灵活但丢结构、预定义工作流有结构但太死板——用分层任务网络（HTN）解决：Planner 维护任务层级和依赖，推迟拆解到前置结果就绪时才做；本地 Orchestrator 调度工人执行叶子任务，结果逐层上传播。
多智能体系统在复杂任务上已经证明了威力：分工调查、并行探索、交叉验证。但怎么指挥这群智能体一直是个两难问题。
两难：灵活 vs 结构
现有方法分两类，各有致命伤：
动态调度（Router 类）：执行时实时决定谁做什么。灵活——能根据新发现调整方向。但不显式建模子任务层级和依赖关系——两个智能体可能重复做同一件事，上游结果变了下游不知道。
预定义工作流（Pipeline 类）：提前画好完整流程图。有结构——依赖清晰、进度可追踪。但在执行开始前就固定了拆解——问题是，你还没看到中间结果，怎么知道后面该拆成什么样？
真实任务往往是：前一步的结果决定后一步该怎么拆。提前拆死是错的，完全不拆是乱的。
解法：两层架构，拆解推迟
这篇论文引入 HTN-Orchestrate（Hierarchical Task Network Orchestration），核心思想来自经典 AI 规划的 HTN 理论——把「什么时候拆」和「谁来执行」分开管：
上层 Planner：
- 维护子任务层级和依赖关系
- 推迟拆解：不提前把任务拆到底，等前置结果就绪后再决定下层怎么分
- 保持全局视角：知道哪些子任务在跑、哪些等前置、哪些已完成
下层 Orchestrator（每个子任务一个）：
- 接收拆好的叶子子任务
- 调度工人（Worker）去执行
- 执行结果向上传播：Planner 拿到结果后决定下一层怎么拆
这个设计的精髓在于：拆解的时机被推迟到信息充分的时候。比如「调研市场竞品」这个任务，Planner 不提前拆——等调研完成、看到有几个竞品后，才决定「每个竞品深入分析」需要拆成几个子任务、每个分配什么角色。
结果传播：自底向上的信息流
叶子任务完成后，结果不直接给用户，而是逐层向上传播：
```
Worker 执行 → Orchestrator 收集 → Planner 接收 → 决定下层拆解 → 分配给新 Orchestrator → ...
```
这意味着 Planner 在每一层都有最新的信息来指导下一步。信息流和任务流形成一个反馈循环——上层根据下层结果调整策略，下层在上层指导下执行。
关键设计权衡
论文验证了几个重要的工程判断：
- 不拆到底：保留中间层级的抽象。直接拆到原子操作会丢失结构语义，让依赖追踪变得不可能。
- 本地自治：Orchestrator 在自己的子任务范围内有调度自由——不必事事请示 Planner。这减少了通信开销。
- 依赖追踪：Planner 明确知道「A 是 B 的前置」——不会出现 B 先跑然后发现需要 A 的结果再重跑。
对智能体构建者的启示
这篇论文讲的问题，是所有做多智能体系统的人迟早撞上的：
- 拆解粒度是动态决策，不是静态设计。一开始就画全流程图是错误的——中间结果会改变后续最优路径。
- 规划层和执行层必须分离。Planner 不执行、Orchestrator 不规划——各司其职才有清晰的责任边界。
- 依赖关系显式建模。隐式依赖（「应该先做 A」）在并发执行时会变成竞态条件。
在 BuddyMe 的多智能体实践中，有类似的分层思路：任务拆解由引擎根据中间结果动态决定（而非一次性拆到底）、子任务独立工作目录天然隔离、结果逐层汇报到主任务。当任务规模变大、智能体数量变多时，「推迟拆解+依赖追踪」的价值就越明显——它能避免大量重复劳动和错序执行的浪费。
论文：*HTN-Orchestrate: A Hierarchical Task Network Framework for Multi-Agent Orchestration*（arXiv:2610.22195）。
>
BuddyMe 每日免费 4500 万 Token，任务动态拆解、结果逐层传播、依赖显式追踪。