让 Agent 团队边做边规划：HTN-Orchestrate 用分层任务网络重构多智能体编排 | GAIR Paper 137

HTN-Orchestrate助力开源Flash底座跑出BrowseComp 89.73%，逼近GPT-6 Astra。

编辑丨岑峰

多智能体系统越搭越复杂，除了用哪个模型，谁来拆任务、谁来派活、谁来收尾，也直接影响系统的性能表现。

近期，南洋理工大学与Apodex联袂推出的HTN-Orchestrate给出了一个分层答案：上层用分层任务网络（Hierarchical Task Network, HTN）管全局规划，下层为每个可执行的叶子任务配一个专属Orchestrator调度多个worker。更关键的是，上层不在开工前把计划写死，而是等前置结果回来，再决定下一步怎么拆。

在同一底座DeepSeek-V4.1-Flash下，它在5个基准上全部超过ReAct、Agent Team和DeepSeek Harness。BrowseComp（完整1266题）准确率达到89.73%，SUPERChem达到73.44%，分别比Agent Team高出2.45和4.69个百分点。放进论文列出的闭源与开源模型成绩里，它的BrowseComp分数离榜首GPT-6 Astra（91.50%）只差1.77个百分点，在FSR和PRL-Bench上的分数也是最高的。

论文：https://arxiv.org/abs/2610.22195

代码：https://github.com/ycdeng-ntu/htn-orchestrate

01

问题出在哪：

结构和灵活，只能二选一？

先看一道BrowseComp题（Q193）：一本1993年角色扮演游戏补充手册的某位作者，2015年写过一本童书，他的父亲有一档电台节目。问：这家电台是哪一年首次播出的？

这类题的特点是一环扣一环：先拿到手册的作者名单，后续查谁写了童书就能直接缩小范围；确定了具体作者，再去找他的父亲也更有针对性。

现有的多智能体编排大致有两条路，各自在结构和灵活性之间做了不同取舍。

第一条是结构化工作流。从MetaGPT到自动生成工作流的AFlow，都在开工前把阶段和控制流定好。全局结构清晰，但拆解方案在执行前就定死了，中途查到的新线索改写不了后面的计划。

第二条是运行时派发。Magentic-One、AOrchestra，以及Agent Team这类方案，让一个主Agent边跑边拆、并行派发子Agent。灵活是灵活了，但拆任务、派任务、汇总结果全压在同一个总指挥身上，子任务的层级关系和兄弟任务之间的先后依赖，都没有被显式建模。

ADaPT、ReAcTree等动态分解方法允许计划在执行中演化，但对复杂依赖关系的支持同样有限。

说到底，编排要同时回答两个问题：全局上，任务怎么拆、先后怎么排；局部上，每个子任务怎么调Agent、怎么查证。现有方法大多把两件事揉在一起，或者只顾其中一件。

02

HTN-Orchestrate：

总包管工序，工长管现场

打个比方：盖一栋楼，总包负责整体工序，先打地基再砌墙，水电和装修谁等谁；每个分项工程交给一位工长，带一个小队现场施工，遇到问题现场调整。

HTN-Orchestrate就是这样分的两层。

HTN-Orchestrate整体框架：上层 Planne r基于执行结果做规划，下层Orchestrator在每个可执行叶子任务内调度多个worker

▎上层Planner：一张会生长的任务网络

任务被表示为一张分层任务网络，包含两类边：层级边表示父任务由哪些子任务共同完成，依赖边表示兄弟任务之间谁必须等谁的结果。

经典HTN规划器从预定义的规则库里挑分解方式，这里的Planner则用LLM在执行过程中生成分解，网络随着前置结果返回逐步长出来。一个叶子任务只有在所有前置任务完成后才进入就绪状态；Planner再结合原始目标、祖先任务和前置结果摘要，决定是直接交给下层执行，还是继续拆成子任务。

这就是结果驱动的规划（result-informed planning）：依赖任务的内部结构，要等前置结果回来再定，而不是开工前凭假设写死。每次生成的分解还会检查是否覆盖父任务、依赖是否无环，不通过就修订。

结果沿层级边向上汇总，遵循AND语义：叶子任务返回Orchestrator的执行结果，非叶子任务等所有子任务完成后再综合，一路汇总到根节点得到最终答案。每份结果都标记“已解决”或“仍未解决”，供后续规划判断还要不要继续投入。

▎下层Orchestrator：每个叶子任务一个“工长”

每个可执行的叶子任务，都分配一个专属Orchestrator，手下有两类worker：负责调研的Researcher和负责核验的Verifier。

Orchestrator在每个决策点只做三选一：派活、等待、收工。worker的报告一到就收，其他worker还在跑时，它就可以根据新报告安排针对性追查，或在发现结论有争议时派Verifier核实。

收工时，它停掉不再需要的任务，把报告综合成一份叶子结果：摘要、是否解决、证据引用。

▎重规划：推倒重建，但不清空记忆

如果执行失败，或者当前任务网络下找不到可信答案，Planner会触发重规划。

重建不是从零开始。Planner先从已完成和部分完成的报告里提取有证据支撑的发现，作为新一轮规划的上下文，再从原始任务出发构建一张新网络。这些证据只作为规划参考，不会自动把新任务标成已完成，所以新一轮可以换一种拆法，同时保留已有线索。

重建次数有上限。预算耗尽时，框架汇总已有证据并列出未解决的需求，不把“停下来”当成“做完了”。

03

实测：同底座下5个基准全面领先

▎实验设置

团队在5个基准上评测，覆盖网页研究、科学推理和科研工作流：

• BrowseComp（BC）：完整1266题，考察持续网页检索能力（执行分析与消融实验使用随机抽取的200题子集）；

• FrontierScience两个赛道：Research（FSR，60题）为开放式科研子问题，Olympiad（FSO，100题）为物理、化学、生物奥赛级推理；

• SUPERChem：256道纯文本化学多步推理题；

• PRL-Bench：100道源自已发表论文的理论与计算物理科研任务。

在评测时，FSR、FSO、SUPERChem 和 PRL-Bench 均禁用搜索、网页检索和外部网络访问，保留 Python 计算。对比基线为FrontierAgent中实现的ReAct与Agent Team，以及DeepSeek官方Agent运行时DeepSeek Harness。四种方法统一使用DeepSeek-V4.1-Flash作为底座，均为高推理强度；HTN-Orchestrate中的worker则使用低推理强度。

为控制成本，任务网络最大深度为2、每个节点最多4个子任务；每个叶子任务最多3个并发worker、12轮编排；整个任务最多重建一次。

▎主结果

主结果（含同底座对比与各模 型公开成 绩）：BC、FSO、SUPERChem为准确率，FSR为成功率，PRL-Bench为平均rubric满足率

HTN-Orchestrate在全部5个基准上都超过了三个基线：

• BrowseComp：89.73%，比ReAct高15.80个百分点，比Agent Team高2.45个百分点；

• SUPERChem：73.44%，比ReAct和Agent Team分别高8.21和4.69个百分点；

• FSR：成功率43.33%，ReAct与Agent Team分别为25.00%和40.00%；

• PRL-Bench：平均得分46.00，比ReAct（36.13）和Agent Team（35.81）分别高9.87和10.19分；

• FSO：准确率79.00%，比Agent Team（75.00%）和DeepSeek Harness（76.00%）分别高4.00和3.00个百分点。

▎Flash底座，和前沿大模型同台

底座只是开源权重的DeepSeek-V4.1-Flash，但放到论文列出的各模型公开成绩里，HTN-Orchestrate依然能打：

• BrowseComp：表中只有GPT-6 Astra（91.50%）、Kimi K3（91.20%）和GPT-5.6 Sol（90.40%）分数更高；

• FSR与PRL-Bench：表中所有模型里最高，FSR超过Meta Muse Spark（38.00%），PRL-Bench超过Gemini 3.1 Pro（44.27）；

• FSO：79.00%，与Gemini 3.1 Pro并列表中最高；

• SUPERChem：73.44%，只比表中最高的GPT-5.6 Sol（73.60%）低0.16个点。

▎与Agent Team相比，更准，也更快

多智能体方案常被质疑“拿时间换精度”。团队在BrowseComp 随机采样的200题子集上，逐题对比了完成时间。

BrowseComp 200题子集 上的 逐题完成时间（左：对比ReAct；右：对比Agent Team），点落在对角线下方表示HTN-Orchestrate更快

• 和Agent Team相比，两者都答对的165题中，HTN-Orchestrate有112题（67.9%）完成更快，单题耗时之比的中位数为0.699。

• 和单Agent的ReAct相比，HTN-Orchestrate在共同答对的题上通常更慢，但多答对了38道ReAct做错的题，只丢了12道，净增26题。

并行度也更高。在200题上，HTN-Orchestrate的平均worker并发数为2.47，Agent Team为1.70；共同答对的165题上为2.42对1.82。在共同答对的165题上，HTN-Orchestrate有24.6%的时间同时有至少4个worker在工作，Agent Team为11.8%。当然，它没有worker在跑的“空档期”也更长，这段时间留给了规划、协调和结果综合——这种“集中并行、穿插调度”的节奏，和它按子任务分批派发worker的分层结构是一致的。

Browse Comp上 的worker并发情况

04

三个核心机制，每一个都有用

▎消融实验

团队在同样的200道BrowseComp题上，分别去掉三个核心组件，其余机制保持不变。在这个子集上，完整系统的准确率为92.0%。

Brow seComp 消融结果与执行统计

• 改为开工前一次性分解（Upfront decomposition）：准确率从92.0%降到90.5%，协调开销反而更大。worker调用次数中位数从14升到16，Orchestrator决策轮数从14升到17，触发重建的题目比例从17.5%升到22.5%，单题完成时间中位数也从25.23分钟拉长到30.02分钟。

• 叶子任务改为单Agent执行（Single-agent leaf execution）：准确率降到89.5%。叶子层查得不够透，压力转回Planner：平均执行的叶子任务数从4.67增至6.15，重建比例从17.5%几乎翻倍到32.0%。

• 禁用重建（No rebuilding）：准确率同样降到89.5%。完整系统多出的准确率，来自重建带来的额外调研：平均执行叶子任务4.67个、worker调用23.16次，禁用后为4.12个和19.01次。

执行轨迹也印证了这些机制确实在起作用：200题中有57题，Planner在带前置依赖的节点上动态生成了子任务，共79次；35题触发了任务网络重建，其中27题最终答对。

▎案例一：拿到名单再查人（Q193）

Q193上的结果驱动规 划（ 左）与一次性分解（右）

回到开头那道题。HTN-Orchestrate先查出补充手册的四位作者，再把这份名单直接写进新生成的子任务：这四位里，谁在2015年出过童书？随后锁定写了童书《Grandmother Fish》的Jonathan Tweet，再沿其父亲Roald Tweet的电台节目，定位到电台WVIK，答出1980年。

一次性分解的版本也答对了，但它在开工前只能写下“找有RPG履历的2015年童书作者”这样的独立检索任务，再加一步“对齐两份候选名单”。结果驱动的计划执行了4个叶子任务，一次性分解则需要5个（worker调用也是15次对20次）。

▎案例二：第一版没找到，带着线索重建（Q501）

Q501上的任务网络重建：第0轮保留的证据进入第1轮规划

这道题要找一篇日期为12月27日、列有24首歌的博客文章中的第3首歌，附带“每周专栏”和“第21首歌所属专辑”两条约束。第一轮搜索没能定位到目标文章。

HTN-Orchestrate没有清空重来，而是保留了候选专辑、反复出现的每周专栏和已排除的文章；重建任务网络时，新增了“按专栏特征搜索”和“专辑与第21首歌匹配”两个任务。最终定位到Wilfully Obscure上2013年12月27日那篇24首歌的文章，答出Tobin Sprout的《Serial Killer》。禁用重建的版本，答的是《Silent Night》。代价是调研量明显更大：完整系统两轮共执行5个叶子任务、72次worker调用，禁用重建的版本只有2个和18次。

05

结语：让规划和执行互相喂信息

HTN-Orchestrate的思路可以浓缩成一句话：全局有一张理清层级与依赖、随前置结果逐步生长的任务网络，局部每个子任务有自己的小团队，两层通过执行结果互相传递信息。

上层不再开工前一锤定音，而是等前置结果回来再拆；下层不再单打独斗，而是边查边核、按证据调度；第一版计划走不通时，也不是推倒重来，而是带着已有证据重建。

在团队看来，多智能体系统的性能，取决于全局规划与局部执行能否既分得开、又连得紧；而一张显式刻画层级与依赖、随执行结果不断演进的任务网络，正是连接两者的接口。

CNCC 即将召开，欢迎参会的研究者、学生，以及关注计算机领域前沿进展的读者加入我们的CNCC 交流社群。

在这里，你可以认识同行、交流研究，分享招生信息、科研合作、约饭、投稿、组队参会等，寻找潜在的合作伙伴。

大会期间，我们也会持续带来现场报道速递、嘉宾演讲解读、前沿方向梳理和论坛精华。

会场见，也在群里见。

进群传送门：扫码进群或添加微信Qvv0909777，备注：CNCC + 单位/学校+姓名+方向。

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。