DAGent：先规划后修补行不通，那就边做边长

2026 年的深度研究智能体圈子里，流传着一个几乎所有人都默认接受的做法：先把整个任务拆解成一张完整的计划图，再在执行过程中发现问题就修修补补。

这听起来没什么毛病，对吧？就像装修房子前先画好全套图纸，施工中哪里不合适再调整。可问题是，深度研究这件事的本质恰恰和装修房子不一样。你装修前至少知道房子的结构，承重墙在哪里，水电走向大概清楚。可深度研究任务不是这样的。你压根不知道第一步搜出来的东西会不会推翻你原本的设想。

这篇来自纽约大学团队的论文叫 **DAGent**，它的核心论点简单到有点扎心：你在对问题理解最浅的那一刻，做出了最大的规划承诺，这个顺序本身就是反的。

先说说这件事到底难在哪。

### 深度研究有多难，先看当时的困境

深度研究任务指的是那种需要在几十上百个信息源里跳来跳去、反复求证、层层推理才能回答的问题。比如论文里举的一个例子：找出一个人，他父亲是新教牧师，他娶了一位时装设计师，他在一个村庄建了所学校。这种问题没法一次搜索解决，你得先锁定"新教牧师的孩子"这个线索，再结合"时装设计师配偶"去交叉验证，一步步缩小范围。

目前做这类任务效果比较好的架构是

**DAG（有向无环图）**

：把一个大任务拆成一堆互相依赖的小任务，这些小任务组成一张像树状又比树状复杂的网络图，没有依赖关系的分支可以并行跑，每个分支只看它需要的那部分上下文，不用背着整个任务历史的包袱。

这套思路本身没问题，MindSearch、Flash-Searcher 这些系统都在用。但问题出在一个细节上：现有的 DAG 系统几乎全都是"先出整张图，再执行"。Flash-Searcher 一次性决策调用就生成完整计划，之后定期更新；FlowSearch 要经过好几轮规划器迭代，把整个知识流图搭好了，才开始真正执行，后面再靠一个独立的修正器做图变换。

论文把这套流程起了个名字，叫

**Plan-then-Patch（先规划后修补）**

：指在还没有任何节点真正跑起来、系统对问题的理解处于最浅层状态时，就完成了对整个任务的主要规划，后面的调整都只是在既定框架里打补丁。

这种做法放在数学题或者结构清晰的任务里问题不大，但放到深度研究里就危险了。因为深度研究的中间发现经常会直接推翻之前的假设。你规划时以为这个人是某个候选人，搜了三步发现压根不是，整条规划线都得重来，而系统却已经在这条错误的线上投入了大量计算。

论文用一组数据说明了这件事的代价：在同样的 DAGent 架构下，把"边做边长"换成"先规划后打补丁"，BrowseComp-Plus、GAIA、xbench-DeepSearch 三个基准测试的准确率分别掉了 5.3、4.8、4.0 个百分点，如果再退化到完全不做任何重新规划的"一次性计划"，差距直接拉大到 14.0、12.6、10.0 个百分点。

这组数字其实说明了一件挺反直觉的事情：规划得越"周全"，有时候反而越亏。因为那些提前规划好、后来被证明不需要的分支，系统还是得老老实实跑一遍，白白浪费了计算资源，还可能把答案带偏。

### Evaluate-then-Grow：先看懂，再长下一步

针对这个问题，论文提出的核心方案是

**Evaluate-then-Grow（评估后生长）**

：不预先承诺整张任务图，而是由一个叫 Orchestrator（编排器）的角色每次只规划一小批节点，等这批节点执行完、拿到结果反馈之后，再根据反馈决定下一批该规划什么。

这个思路换个场景讲可能更好懂。假设你要写一篇调查报道，采访十个人。先规划后修补的做法是：你先列好十个人的采访提纲，按顺序一个接一个问完，中途发现某个受访者说的和假设完全不同，你也只能先记下来，继续按原计划往下问，最后再回头调整报道结构。

而评估后生长的做法是：你先采访两三个人，听完他们怎么说，再决定接下来该找谁。如果第二个受访者的话让你意识到最初的假设方向错了，你立刻调整接下来要问的人和问题，不会浪费时间继续执行一份已经过时的提纲。

如果不这样做会怎样？

你会在错误的方向上投入更多精力，等到最后汇总的时候才发现问题，返工成本比随时调整要高得多。

具体到系统设计上，每个任务被建模成一张

**DAG（有向无环图）**

：图里的每一个节点 vi 代表一个原子子任务，节点之间的边表示依赖关系，比如节点 B 依赖节点 A 的输出结果才能执行。这张图一开始是空的，由 Orchestrator 一批一批地往里添加节点。

每个节点在执行完之后会产出两样东西。第一样叫

**QueryDoc（查询文档）**

：是一份压缩过的结构化摘要，包含这个子任务的答案、简短解释、关键执行步骤、置信度分数，以及一份"不确定性清单"，列出哪些地方可能还需要进一步核实。

第二样叫

**InteractionTranscript（交互轨迹）**

：是这个子任务执行过程中完整的行动和观察记录，比如具体搜了哪些关键词，打开了哪些页面，看到了什么内容。

每一轮迭代，Orchestrator 会先给上一批执行完的节点打状态标签，分成三种：Success（成功，证据确凿）、Uncertain（不确定，需要进一步核实）、Not Found（没找到，执行是对的但没搜到相关内容）。被标记成 Uncertain 或 Not Found 的节点会触发一个

**refine 节点**

：用不同的搜索策略重新尝试这个子任务，每条线最多给三次机会（一次初始执行加两次重试）。

论文里有张图很有意思，展示了四种典型的节点状态流转：一个节点成功了被往下展开；一个节点不确定被触发重试；一个被重试成功的节点；还有一个在三次机会用完后依然没查到东西，只能放弃接受这个缺口，继续往前推进。这四种情况拼起来，正好说明了评估后生长不是盲目乐观地假设一切顺利，而是真实地把"查不到"也当成一种有效信息去处理。

什么时候这张图算是长完了？答案是当 Orchestrator 安排了一个

**answer-type 节点（答案节点）**

：也就是综合上游所有证据给出最终答案的节点。这个节点必须单独出现在一批里，不能和其他搜索节点混在一起，确保它能看到所有被认定相关的上游证据。

这里有个巧妙的设计叫

**append-only（只增不减）**

：整张图一旦生成就不会被删除或重新连线，节点执行时看到的上下文，永远和它在最终图里的祖先关系完全一致。

这个性质看起来技术细节，但其实是后面强化学习设计的地基，后面会讲到为什么。

### 分层上下文传播：别让每个节点都背着全部历史

深度研究任务动辄跑几十上百步，如果每个节点都要看完整的历史记录，上下文窗口根本扛不住。论文给出的解法是

**Selective Propagation（选择性传播）**

：默认情况下，一个节点只接收它直接依赖的那几个父节点的 QueryDoc（压缩摘要），而不是整条路径上所有节点的完整记录。

这意味着每个节点的上下文负担，取决于它的"入度"（有多少个直接依赖），而不是整张图的深度或者节点总数。

这里可以打个比方。假设一个公司的项目汇报制度，你不需要让每个新入职的同事读完公司十年来的全部会议记录才能上手工作，只需要把跟他直接相关的那几份交接文档给他就够了。如果非要让每个人都背完整历史，公司效率会被拖垮，每个人花在"读资料"上的时间比干活还多。

但有时候压缩摘要确实不够用，比如下游执行需要某段原文的精确措辞，或者需要知道一个曾经被否定的候选人具体是怎么被否定的。这时候系统提供了一个叫

**RECALLTOOL（回溯工具）**

：允许执行子任务的智能体主动从某个直接依赖节点的完整交互轨迹中，针对一个具体目标提取出一段聚焦的证据片段。

论文统计显示，这个工具是个"后备手段"而非默认通道：在 Qwen3-32B 的测试里，只有 22.0%、13.6%、11.0% 的任务（分别对应三个基准）用到了至少一次回溯调用。换句话说，大多数时候压缩摘要就够用了，只有在真正需要翻旧账的时候才去查完整记录。

实验也验证了这套上下文管理的价值。去掉选择性传播这个机制后，三个基准的准确率分别掉了 12.6、10.6、8.0 个百分点；去掉 QueryDoc 掉 8.0、7.7、5.0；去掉完整交互轨迹（也就是关掉回溯功能）掉 4.0、2.9、2.0。三个组件的重要性排序很一致，选择性传播最关键，QueryDoc 次之，完整轨迹保留排在最后但也有实打实的贡献。

### DAGRPO：让强化学习看懂这张图的结构

论文的第二个核心贡献，是一套叫

**DAGRPO**

的强化学习训练方法，全称是 DAG-conditioned Group Relative Policy Optimization（DAG 条件下的组相对策略优化）。

要理解它为什么重要，得先说一下现有的强化学习训练方法有什么局限。目前主流的做法是

**GRPO**

：一种组相对策略优化方法，给一整条任务轨迹打一个统一的对错奖励（成功是 1，失败是 0），然后把这个奖励均匀地分摊到轨迹里的所有步骤上。

这套做法放在评估后生长产生的 DAG 结构里会出现一个明显的浪费。一条轨迹里，有些执行节点的结果最终真的被用来拼出了答案，另一些节点探索的方向压根没被最终综合采纳。但传统的奖励分配方式对这两种节点一视同仁，没有区分谁真正"立功"了，谁只是陪跑。

这就好比一个团队做项目，最后成功了，老板给所有参与的人发同样多的奖金，不管谁的工作真正被用在了最终交付物里，谁的方案被弃用了。长期这样做，团队成员会缺乏动力去判断自己的工作是否真正有价值，反而可能倾向于多做一些"看起来参与了"但其实没被采纳的工作。

DAGRPO 针对这个问题设计了两个结构性信号。

第一个叫

**topology-conditioned credit（拓扑条件信用分配）**

：论文定义了一个叫"答案包含闭包"的集合，指最终答案节点以及它所有的祖先节点，也就是真正为最终综合提供了证据的那部分执行节点。落在这个闭包里的节点保留完整的轨迹奖励，闭包外的"旁支"节点，奖励会被一个系数 α 衰减。

这个衰减系数的取值很讲究。论文做了从 0 到 1 的扫描实验，发现 α 等于 0（也就是完全不给旁支信用）效果反而比普通的 GRPO 基线还差，因为旁支节点在失败的轨迹里，可能恰好留存了一些有用但没被综合利用的证据，完全抹掉这部分信号反而让模型学不到东西。而 α 等于 0.5 在三个基准上都是最优值。

这里有个很关键的设计细节值得展开说一下：为什么用乘法（α 乘以奖励）而不是直接减去一个固定惩罚？因为一旦轨迹整体失败（奖励是 0），乘法形式的衰减就自动变成了 0，不会对旁支节点施加额外的负向惩罚。这个处理很细腻，它承认了"探索了一个最后没被用上的方向"不等于"做错了"，只是没被选中而已。

第二个信号叫

**structural compliance regularization（结构合规性正则化）**

：针对 Orchestrator 的规划决策，如果某一轮规划违反了预设的结构约束（比如没有给上一批节点都标注状态，或者该触发重试的弱节点没有被重试，或者答案节点没有单独成批），就给这条轨迹加上一个负的惩罚项。

有意思的是，论文还特别论证了这套信用分配机制为什么不会被"钻空子"。因为按照 append-only 的设计原则，整张图只能往外长，不能删除或重连已有节点。如果训练过程中模型学会了故意把更多节点连进答案闭包来骗取奖励，论文指出这条路走不通，原因有三点：目标函数里没有任何一项会随着祖先数量增加而变大；在选择性传播机制下，每多连一条边就意味着往下游节点塞进一份可能无关的上下文，反而会拉低任务准确率；而且实际训练记录显示，图的节点数在训练过程中是逐渐下降的，和"故意膨胀依赖关系"的预测方向完全相反。

实验数据证明了这两个信号确实都有贡献。在 Qwen3-8B 上，去掉拓扑条件信用，三个基准分别掉 2.3、1.9、1.7 个百分点；去掉结构合规性正则化，分别掉 1.6、1.0、0.7 个百分点。两个信号叠加起来，DAGRPO 相比同等训练预算下的普通 GRPO 基线，平均提升了 3.0 个百分点。

### 实验结果：从小模型到 GPT-5 都站得住脚

论文在三个基准测试上做了全面验证：

**BrowseComp-Plus**

：一个基于本地检索的高难度浏览类任务基准，把原始 BrowseComp 的问题和一个经过验证的语料库配对，检索方式是用 Qwen3-Embedding-8B 做本地密集检索。

**GAIA**

：一个评估通用人工智能助手综合解题能力的基准测试，主要用它的 103 题纯文本验证子集，检索走真实的谷歌搜索接口。

**xbench-DeepSearch**

：包含 100 道中文深度研究题目的基准，同样走真实搜索接口。

在 Qwen3-32B 这个规模上，DAGent 相比当时最强的非 DAGent 训练无关基线 FlowSearch，在三个基准上分别领先 4.0、3.8、2.0 个百分点，相比其余基线则领先 6.0、10.6、7.0 个百分点。这个优势在更小的 8B 模型和更大的 235B-A22B 模型上都能复现，而且随着任务难度上升，相对优势还在扩大。

论文还做了个很扎实的跨厂商验证，把 DAGent 架构套在四个不同厂商的中等规模模型上：字节跳动的 Seed-OSS-36B、智谱的 GLM-4-32B、英伟达的 Nemotron-3-Nano-30B，加上阿里的 Qwen3-32B。结果显示，无论换哪个底座模型，DAGent 都稳坐该模型下所有方法里的第一名。这说明这套方法论的收益不是靠和某个特定模型"适配得好"碰出来的运气，而是架构设计本身带来的系统性优势。

更进一步，研究团队把 DAGent 架构接上 GPT-5，上下文窗口拉到 327K，去和业界已发布的最强系统正面对比，包括 OpenAI 的 Deep Research、Manus、Kimi Researcher 这些产品级系统。结果是，DAGent 在 BrowseComp-Plus、GAIA、xbench-DeepSearch 上分别以 5.7、2.5、2.0 个百分点的优势超过了当时报告过的最强基线。

### 效率账：聪明的规划反而更省钱

这篇论文一个很容易被忽略但其实很重要的发现是：评估后生长不仅准确率更高，而且更省资源。

论文做了一个"同架构对比实验"，把 DAGent 换成一个只改变规划时机的 Plan-then-Patch 变体（其余组件全部保持一致），对比两者在 Qwen3-32B 上的每任务开销。结果显示，先规划后修补的版本比评估后生长版本多用了 40%、29%、18% 的 token（三个基准分别对应），多跑了 28%、21%、21% 的执行步数，多发起了 35%、27%、21% 的外部工具调用，多花了 35%、27%、23% 的墙钟时间，然而准确率反而还低了 5.3、4.8、4.0 个百分点。

这个结果其实挺有说服力的。它说明"先把计划定周全"这件事并不会带来效率上的回报，反而因为提前承诺了一堆后来被证明用不上的分支，系统还得老老实实把这些分支跑完，白白浪费了计算。论文还细查了这些多出来的开销从哪来：因为补丁节点（重试或新增的节点）在设计上都会自动连到答案节点上以确保证据能被用到，所以这些补丁节点天然是"在链上"的，多出来的开销只能是来自最初那份过度规划的计划本身，那些从一开始就不该被加进去的分支。

### 写在后面

读完这篇论文，我最意外的一点其实不是 Evaluate-then-Grow 本身，大多数做过项目管理或者写过长篇报告的人，都会凭直觉觉得"边做边调整"比"一次性定计划"靠谱。真正让我多想了一会儿的，是那个 append-only（只增不减）的设计限制。

这个限制乍看是个技术约束，但它其实解决了一个更深层的问题：如果一张图可以被事后删除和重连，那你就永远没法准确说清楚"某个节点执行时到底看到了什么上下文"。因为删除和重连会让历史记录变得不可信，节点执行时的真实上下文和它最终在图里的位置可能对不上。而只增不减这个约束，相当于给整个系统上了一道"历史不可篡改"的保险，这才让后面的强化学习信号可以被精确定义，因为你能确切知道每个节点当时到底依赖了谁。

这让我想起另一个完全不相关的领域，区块链的不可篡改特性。两者的技术目标天差地别，但底层的动机有点像：都是通过牺牲"事后修改"的灵活性，换取"可验证的历史真实性"。这种设计哲学的迁移挺有意思的，一个为了防篡改交易记录而生的思路，居然在多智能体规划系统里找到了另一种应用场景。

论文里还有个细节我觉得值得单独拎出来说：第一批节点是整个流程里唯一一次"盲目"的规划，因为这时候还没有任何执行结果可以参考，只能靠任务描述本身来猜。论文统计显示，这批节点里有 34.9% 会被评估为不确定，3.2% 彻底查不到相关内容。这个数字其实在提醒我们，哪怕是号称"边做边长"的系统，起点那一步依然带着盲猜的成分，只是后续的机制能及时纠正它，而不是让这个盲猜的错误一路传染到最后。

这篇论文没有解决的问题也挺明显，比如那个"答案包含闭包"作为贡献度衡量方式，本质上是个结构代理，不是真正意义上的因果归因。一个节点在图里连到了答案节点，不代表它的信息真的对答案起了决定性作用，也可能只是凑巧挂在了那条链上。论文自己也承认这一点，说这是个开放问题。这倒是给后来者留了个挺明确的方向：怎么在 DAG 这种结构里做出真正意义上的因果贡献度估计，而不只是读图读出来的连通关系。

Q&A

Q1：DAGent 和之前的 Plan-then-Patch 方法到底有什么本质区别？

A：Plan-then-Patch 是先把整个任务的计划图一次性生成好，再在执行过程中发现问题就打补丁修改；DAGent 的 Evaluate-then-Grow 则是每次只规划一小批节点，等这批执行完拿到反馈，再决定下一批该规划什么，图是一点点长出来的。

Q2：DAGRPO 相比普通的 GRPO 强化学习方法提升了多少？

A：在 Qwen3-8B 规模上，DAGRPO 相比同等训练预算的普通 GRPO 基线，平均提升了 3.0 个 Pass@1 百分点，两个结构性信号（拓扑条件信用和结构合规正则化）都各自有正向贡献。

Q3：DAGent 用了评估后生长的方法，会不会反而增加计算成本？

A：不会，实验显示它比先规划后修补的同架构变体更省钱，每任务少用 18%到40%的 token，少跑 21%到28%的步数，少花 23%到35%的时间，同时准确率还更高。