多智能体编排有个吵了很久的岔路：一边是动态派发——谁有空谁上，灵活但子任务之间没什么结构，依赖关系靠现场发挥；另一边是预定义工作流——层级、依赖都画在图上，清晰但分解在执行前就拍死了，前序结果没出来，后面的安排可能已经过时。10 月 15 日提交 arXiv 的 HTN-Orchestrate（编号 2610.22195）想把这个岔路走成一条路：用经典的分层任务网络（HTN）把「结构」和「延迟分解」装进同一个两层框架。
论文九位作者，归类人工智能与计算语言，尚未经同行评审，摘要页未列作者单位。框架分两层：Planner 负责维护子任务的层级与依赖，但把「怎么分解」推迟到前序结果就绪之后；局部 Orchestrator 调度工人执行叶子子任务，结果按 AND 语义向上汇总——所有分支都成，才算父任务成。积累的发现还会回流：当前分解无解时，不是硬撑，而是据已获得的信息重建任务网络再试。
数字不大，但落在难处
论文在五个基准上做了同基座模型对比，对照组是 ReAct、Agent Team 与 DeepSeek Harness，覆盖网页研究、科学推理与研究工作流。点名的两个读数：BrowseComp 89.73%，比 Agent Team 高 2.45 个百分点；SUPERChem 73.44%，高 4.69 个百分点。其余三个基准只以「超过全部对照组」概括，没有逐一给数。
增益是个位数百分点，这在今年的一堆编排框架里不算惊艳，但要看增量出在哪里。动态派发的对照组缺的是显式结构，预定义工作流的对照组缺的是调整机会——HTN-Orchestrate 两样都想要，多出来的分数更像「补结构税」而不是「换了个更聪明的脑子」。同一基座模型这个前提很重要：它说明分数不是模型能力带来的，是组织方式带来的。
放进台谱里看
「同伴报上来的情况默认是真的」——CLASHarness（1933）拆的就是这个默认设置，它说明多智能体的失败常常不是某个成员笨，而是协作结构有洞。GitSwarm（1939）从另一侧补结构：把推理积累存进 Git 分支，让后续尝试站在前面成功的肩上。HTN-Orchestrate 补的是第三样：任务之间的层级与依赖始终被显式维护，分解时机被推迟到信息足够。
三个工作放在一起看，多智能体工程今年的主线逐渐清楚：记忆（别重复走弯路）、通信（别轻信同伴）、结构（别把分解拍死在前）。过去一年行业默认「prompt 加得好就行」，今年开始有人还账——这些论文都是还账的收据。
几盆该浇的冷水
先看样本：五个基准里只公布了两个的绝对读数，其余是概括性结论，复现时无法逐项核对。其次，两层结构意味着更多调度开销，论文没有报告推理成本对比——多一次规划器调用也是钱。再者，HTN 是经典规划里的老形式化，搬到 LLM 系统后，「原子任务」的边界由模型临时划定，粒度不稳会直接影响层级图的质量。最后仍是预印本、未经同行评审、无代码发布说明，第三方复现要等。
给正在选编排方案的团队一个可落地的判断：如果任务依赖关系在执行中会频繁改写（研究类、排查类工作），值得把「延迟分解」这四个字写进选型清单；如果任务结构开工前就稳定，预定义工作流的可观测性仍然更香。框架是药，症状要对得上。