让 AI 智能体真正"做研究":Arbor 用一棵假设树把零散试验变成累积式探索
你有没有这种体验:让 Codex 或者 Claude Code 跑一个长任务,它确实能连续几个小时改代码、跑实验、看结果,看起来很勤奋。但跑到后半程你会发现——它在原地打转。前面试过的方向,后面又重新试一遍;某次实验明明暴露了一个关键问题,下一轮它压根没记住。它一直在"执行",但它没有在"积累"。
这就是当前自主智能体最别扭的地方。它们把长任务做成了一串互不相关的局部尝试,而真正的科研恰恰相反——研究者会维持好几个竞争方向,用实验去验证,从成败里提炼教训,再让这些教训重塑后面的探索。这是一个累积的过程,不是一串孤立的动作。
这篇来自人民大学、微软研究院等机构的论文,提出了一个叫 Arbor 的框架,核心就一件事:给自主研究装上一个"持久的研究状态"——一棵会不断生长、剪枝、回传经验的假设树(Hypothesis Tree)。结果挺能打的:在六个真实研究任务上全部拿到最优留出成绩,平均相对增益是 Codex 和 Claude Code 的 2.5 倍以上;在 MLE-Bench Lite 上配 GPT-5.5 拿到 86.36% 的 Any Medal,是对比里最强的。
arXiv ID 是 2606.11926,下面我们把它掰开聊聊。
一段话核心摘要
Arbor 想解决的问题是:现有智能体能"长时间执行",但不会"累积式研究"——失败的教训留不住,竞争方向管不起来。它的方案是把研究状态显式建模成一棵假设树:一个长生命周期的协调器(coordinator)管全局策略,决定在哪儿扩展、剪哪个枝、合并哪个候选;一批短生命周期的执行器(executor)在隔离的 git worktree 里实现并测试单个假设。每次实验的证据会沿着树向上传播经验(insight backpropagation),让叶子节点的一次观察变成方向级的约束。最关键的是一道留出合并门(held-out merge gate)——只有在 held-out 测试集上真的有提升的改动才允许合并进当前最优工件,专治"在 dev 上刷分但迁移不动"的过拟合。效果上,六个真实任务全部最优留出结果,平均相对增益超过两个强基线的 2.5 倍。说实话,这篇论文最值钱的地方不是某个炫技的模块,而是它把"研究该怎么组织"这件事,第一次落成了一个可执行、可审计的数据结构。
论文信息 - 标题:Toward Generalist Autonomous Research via Hypothesis-Tree Refinement - 作者:Jiajie Jin, Yuyang Hu, Kai Qiu, Qi Dai, Chong Luo, Guanting Dong, Xiaoxi Li, Tong Zhao, Xiaolong Ma, Gongrui Zhang, Zhirong Wu, Bei Liu, Zhengyuan Yang, Linjie Li, Lijuan Wang, Hongjin Qian, Yutao Zhu, Zhicheng Dou - 机构:中国人民大学、微软研究院等 - 日期:2026/06/10 - arXiv:https://arxiv.org/abs/2606.11926

图1:Arbor 一览。左边是一次运行真实长出来的假设树(注意它的分叉和深度),中间是开发集分数随探索逐步爬升的轨迹,右边把六个任务的归一化留出增益放在一起——Arbor 那一档明显高出基线一截。
先把问题讲清楚:为什么"跑得久"不等于"研究得好"
科研的难点从来不在于解一道孤立的题。难就难在你要跨越一堆不确定的假设、昂贵的实验、失败的尝试,还有延迟很久才回来的反馈,把这些东西攒起来往前推。
现在的 LLM 智能体——Codex、Claude Code、OpenHands 这些——它们的"自主性"主要体现在能持续执行:连续编辑代码、调工具、跑实验。这当然有用。但论文点出一个挺扎心的观察:单纯延长执行时间,并不能保证研究在进展。 如果智能体把每次试验都当成独立的局部尝试,它就把研究过程的结构给丢了。
我自己调模型的时候特别有共鸣。有时候你会发现智能体在第 8 小时尝试的方案,跟第 3 小时被它自己否掉的方案几乎一样——因为它没有一个地方记着"这条路走不通,以及为什么走不通"。它的上下文窗口一压缩,那段教训就蒸发了。
更麻烦的是,现有的科学智能体系统大多走两个极端:要么遵循一套预定义的固定工作流(死板,不会随发现调整),要么一次只修订单一研究路线(没法同时养着几个竞争假设互相对照)。两者都缺了让人类研究具有累积性的那套机制。
所以论文的核心命题是:在这类长程优化任务里,真正的瓶颈不只是局部的代码编辑能力,而是把成百上千次试验组织成一个连贯探索过程的能力。 这个判断我是认同的——你给智能体再强的编码手,如果它不会组织探索,它依然是个高效的瞎忙工具。
任务设定:什么是"自主优化"(AO)
为了把问题量化,论文定义了一个叫自主优化(Autonomous Optimization, AO)的设定。形式化成一个四元组:
拆开看其实很直观:
- \(\mathcal{M}_0\):一个可修改的工件(artifact),通常就是一份代码库加上它的数据,智能体可以读、可以改。
- \(\mathcal{O}\):目标,定义什么叫"改得更好",比如某个指标往哪个方向走。
- \(\mathcal{E}_{dev}\):开发评估器,它返回的反馈在搜索过程中可以随便用。
- \(\mathcal{E}_{test}\):留出评估器,衡量你基于 dev 做的改进,到底能不能迁移到反馈之外的数据上。
工件级的目标写出来是:
这里有个硬约束特别关键:你的假设和实现决策,不能把 \(\mathcal{E}_{test}\) 当成探索的预言机来用。 也就是说,一个只在 dev 上涨分、但迁移不到 test 的候选,根本不算成功的 AO 解。
这个设定我觉得设计得相当聪明。它把"做研究"这件虚的事,落成了一个有明确成功判据的优化问题,而且通过 dev/test 分裂,把"过拟合开发集"这个科研里最常见的自欺欺人行为直接堵死。后面你会看到,这道墙在实验里真的拦住了一个强基线。
Arbor 怎么做:协调器 + 执行器 + 一棵假设树

图2:Arbor 的整体框架。中间那个长生命周期的协调器是大脑,它读树、想新假设、派活、收证据、更新树;周围那些短命的执行器是手,各自在隔离的工作区里干一件具体的事。这个"大脑-手"的分工是整个设计的骨架。
三条设计原则
论文先立了三条要求,理解了这三条,后面的设计就顺理成章:
- 分支但要连贯:探索必须能分叉,才能同时容纳多个竞争假设。但分叉不能退化成一堆杂乱无章的尝试日志,得维持一个有组织、可比较、可执行的前沿。
- 全局策略与局部执行分离:战略决策要看全局证据,而实现单个假设只需要短视野的写代码、调试、评估。这两个层级得拆开,别混在一起。
- 探索归探索,准入归准入:dev 反馈用来引导搜索没问题,但只有当改进能迁移到 \(\mathcal{E}_{test}\) 时,才允许它成为工件级的真实进展。
假设树:把研究状态变成一个数据结构
这是整篇论文的灵魂。Arbor 把研究状态建模成一棵有根的假设树 \(\mathcal{T} = (\mathcal{V}, \mathcal{E})\),每个节点是一个"研究单元":
三个字段各司其职:
| 字段 | 是什么 | 我的理解 |
|---|---|---|
| 假设 \(h_n\) | 关于"怎么改工件能改进目标"的一个可验证声明 | 靠近树根是宽泛方向(比如"优化器的动量项可能有问题"),越往深层越具体可执行(比如"把 beta2 从 0.95 调到 0.98") |
| 洞见 \(\iota_n\) | 对证据的可复用解读 | 这是精华——它不是执行日志,而是紧凑的语义记忆:试了什么、发生了什么、为什么这个结果支持/削弱/约束了假设 |
| 元数据 \(\mu_n\) | 连接语义假设和可执行证据的桥 | 节点状态、dev 分数、事实结果、git 分支/提交引用。注意工件本身不复制进树,只存外部引用 |
这棵树同时扮演三个角色,我觉得这是它比"扁平实验队列"高明的地方:它是搜索前沿(哪些方向活跃、哪些已验证、哪些被剪了),是长期记忆(成功和失败的可复用证据都在),也是可审计的研究记录(每次工件改动都能追溯到驱动它的假设和证据)。
HTR:协调器的六步循环
假设树精炼(Hypothesis Tree Refinement, HTR)是 Arbor 的运行机制。协调器是长生命周期的,拥有这棵共享树,决定在哪儿扩展、信任哪些证据、剪哪些方向、何时合并。执行器是短命的,被叫起来测一个具体假设,在隔离的 git worktree 里实现、评估、返回结构化证据,它不能动共享树,也不能改搜索目标。
协调器每一轮跑六步:
| 步骤 | 干什么 |
|---|---|
| Observe | 读树的结构化投影——活跃前沿、近期证据、祖先洞见、当前最优工件,在上下文压缩后重新锚定研究状态 |
| Ideate | 选一个父节点,在它下面提出一组子假设(细化/替代/修正),以累积的树证据为条件,而不是自由头脑风暴 |
| Select | 在待执行节点里选,平衡期望收益和已有证据——这是部分反馈下的前沿控制,不是单纯的分数最大化 |
| Dispatch | 把假设派给独立执行器,在新 worktree 里实现并在 \(\mathcal{E}_{dev}\) 上评估,返回紧凑报告。同胞假设并行跑,直接提供对比证据 |
| Backpropagate | 把证据写进对应叶节点,再沿到根路径更新洞见——因果归因、适用条件、可复用经验,让叶级观察升级成方向级约束 |
| Decide | 决定继续扩展/剪枝/停止/合并。合并由留出合并门守着:候选在 \(\mathcal{E}_{test}\) 上重测,只有超过当前最优才合并 |
我特别想强调 Backpropagate 这步。这其实是借了强化学习里反向传播的直觉——一个叶子节点的实验结果,不该只停在叶子上,它得往上爬,变成对整个研究方向的判断。"这条路上三个具体尝试都失败了,且失败原因都指向同一个机制瓶颈"——这种方向级的结论,才是真正指导后续探索的东西。这就是 Arbor 跟那些"试完就忘"的智能体的本质区别。
还有执行器的那个绑定假设契约也很讲究。论文明确说:执行器被分配一个假设后,就只能为这个假设服务,不允许在指标停滞时偷偷改假设。为什么?因为一旦它改了假设,那返回的分数就不再是关于原节点的证据了,祖先级的洞见会变得没法解释。这个细节看着不起眼,但它保证了整棵树的证据是干净的、可归因的。
算法默认配置
算法 1 给出了完整流程,这里只点关键参数:默认预算是 20 个协调器周期,最大树深 2,分支数为 k。深度只有 2 听起来有点浅,但配合 20 个周期的横向扩展,实际探索规模可以很大(后面 Table 5 会看到某个任务长出了 150 个节点)。
实验:六个真实研究任务上的硬碰硬
任务设计
论文选了六个真实研究任务,横跨三个领域,我列个表:
| 领域 | 任务 | 初始材料 | 指标 / 划分 |
|---|---|---|---|
| 模型训练 | Optimizer Design | NanoGPT-Bench,调优 Muon 基线 | 达目标 loss 的步数(越少越好);test 取两个种子平均 |
| 模型训练 | Architecture Design | 一份 LLM 训练代码库 | 最终 loss(越低越好);test 取两个种子平均 |
| 框架工程 | Terminal-Bench 2.0 | 官方终端智能体代码库 | 通过率(越高越好);36 dev / 53 test |
| 框架工程 | BrowseComp | 极简 ReAct 风格搜索框架 | 准确率;50 dev / 300 test |
| 数据合成 | Search-Agent Data Synthesis | 手工搜索数据流水线 | 平均 pass gap;50 dev / 100 test |
| 数据合成 | Math-Reasoning Data Synthesis | 手工数学数据流水线 | 平均 pass gap;50 dev / 96 test |
数据合成那两个任务的评分方式挺有意思——用 pass@4 − pass@1 的差距来打分,奖励那种"一次解不出、多试几次能解出"的题。这等于在逼数据流水线去生产真正有区分度、有挑战性的样本,而不是一堆送分题。
实验设置上,基线是 Codex(GPT-5.5)和 Claude Code(Claude Opus 4.6),Arbor 的协调器和执行器默认也用 Claude Opus 4.6——注意这点,主干模型对齐了,比的就是框架本身。所有真实任务统一 48 小时墙钟限制,资源预算一致。
主结果:六战六胜
直接上 Table 2 的核心数字(我挑了 Δ vs init 这个相对增益,最能说明问题):
| 任务 | Codex(Dev/Test) | Claude Code(Dev/Test) | Arbor(Dev/Test,加粗为最优) |
|---|---|---|---|
| Optimizer Design | +0.00/+0.00 | +1.50/+1.13 | 最优 +3.01/+2.63 |
| Architecture Design | +0.64/+1.37 | +5.75/+5.92 | 最优 +6.11/+6.38 |
| Terminal-Bench 2.0 | +5.56/+3.78 | +16.67/+1.89 | 最优 +13.89/+7.55 |
| BrowseComp | +5.00/+4.67 | +2.50/+8.00 | 最优 +20.00/+22.34 |
| Search-Agent | +8.00/+4.00 | +8.00/+7.00 | 最优 +12.00/+13.00 |
| Math-Reasoning | +4.00/+5.21 | +6.00/+7.29 | 最优 +22.00/+19.79 |
(单位:百分比或绝对分点,视任务指标而定)
几个数字值得停下来看看:
BrowseComp 上,Arbor 把留出准确率从 45.33 干到了 67.67,而 Codex 只到 50.00,Claude Code 到 53.33。这个差距已经不是"略好"的级别了。
Math-Reasoning 上更夸张,Arbor 的留出 pass-gap 提升了 19.79 分,而两个基线分别只有 5.21 和 7.29。差了三四倍。
但我觉得整张表最精彩的一行是 Terminal-Bench 2.0。看 Claude Code:它拿到了最高的 dev 分(75.00),但 test 反而掉到 71.70。而 Arbor 的 dev 更低(72.22),test 却是最高的 77.36。
这就是关键。
Claude Code 在 dev 上刷出了最高分,但它过拟合了——改进迁移不到留出集。而 Arbor 因为有那道留出合并门把着,宁可 dev 分低一点,也只接纳真正能迁移的改动。这一行数据,几乎是这篇论文设计哲学的活体证明。 如果没有 held-out admission 这个机制,Arbor 很可能也会被 dev 分诱惑着走偏。
MLE-Bench Lite:换个主干就登顶

图3:Arbor 的框架是模型无关的。(a) 换不同主干模型,控制逻辑不变,效果都有提升,但天花板取决于任务和主干的契合度;(b) BrowseComp 上演化出来的搜索框架,冻结后直接拿去做没见过的任务,照样有迁移增益。
在 MLE-Bench Lite(Kaggle 风格的 ML 工程基准)上,有个特别能说明框架价值的结果:
- 同样用 Gemini-3-Flash 这个相对轻量的主干,Arbor 做到 100% 有效提交、86.36% 超过中位数、81.82% Any Medal。
- 只把主干换成 GPT-5.5,其他啥都不改(控制器、深度、调度器、适配器全不动),Any Medal 升到 86.36% ,Gold 率冲到 77.27% ,都是整张对比表里的最高。
这说明 Arbor 不绑定单一前沿模型,它是一层可以套在不同 LLM 上的"研究操作系统"。主干越强,它能达到的经验上限越高,但框架本身的价值是独立存在的。
消融:树和洞见,缺一不可
这是我最想看的部分。论文在 MLE-Bench Lite 上消融了 HTR 最核心的两个组件:
| 变体 | Above median | Gold | Any medal |
|---|---|---|---|
| Full Arbor | 90.91 | 50.00 | 81.82 |
| w/o tree(退化成扁平实验队列) | 72.72 | 31.82 | 63.64 |
| w/o insight feedback(留树但禁用经验回传) | 77.27 | 36.36 | 54.54 |
(单位:%)
三个发现很扎实:
第一,所有变体都是 100% 有效提交。这说明 HTR 改善的不是"能不能跑通",而是"结果质量"。差距不是基础执行失败造成的。
第二,也是最反直觉的一点:去掉洞见回传(54.54%)比完全去掉树(63.64%)还要差。 等等,这有点意思——光有树的层级结构,但不让经验在树上传播,反而不如没有树?论文的解释是:一棵不传播经验的树,只能在语法上把实验摆整齐,但没法提供后续决策需要的语义记忆。它成了一个好看的空架子。这反过来证明了 Backpropagate 那步才是树真正活起来的关键。
第三,树结构和洞见回传是互补的——树定义"在哪儿存储和比较竞争假设",洞见回传决定"哪些可复用信息往前传"。两者解决搜索问题的不同部分。
说句批判的话:这里有个小遗憾。论文反复强调留出合并门多重要,但 Table 4 的消融里并没有把它单列出来做对照。我挺想看到一个"w/o held-out gate"的变体——如果去掉这道门,过拟合会严重到什么程度?Terminal-Bench 那行已经给了暗示,但缺一个直接的消融数字,说服力会差一口气。
节点统计:大部分提升都被合并门拦下了

图4:token 花销 vs 留出增益。对 Arbor 来说 token 要算上协调器和执行器两部分。这张图回答了一个很现实的问题——Arbor 的提升是不是靠烧更多 token 换来的?
Table 5 的节点统计很能说明 Arbor 内部到底在发生什么:
| 节点类型 | Opt. | Arch. | Terminal | Browse | Search | Math |
|---|---|---|---|---|---|---|
| All(总节点) | 26 | 150 | 17 | 26 | 15 | 15 |
| Dev+ 节点(dev 上超基线) | 13 | 15 | 7 | 10 | 10 | 6 |
| Merged(合并进最优工件) | 2 | 9 | 3 | 3 | 4 | 4 |
看 Dev+ 和 Merged 这两行的落差:很多节点在 dev 上确实涨分了,但最终只有一小撮被合并。比如 Optimizer Design,13 个节点 dev 涨分,只有 2 个被合并。
这正是留出合并门在干活。dev 涨分的节点,可能仍然不如当前最优工件,也可能是过拟合了开发评估器、迁移不动。merge gate 就是要拦住这些"局部 dev 增益",别让它们被误当成工件级的真实进步。这张表是对前面 Terminal-Bench 那个反差现象的机制级注解。
跨任务迁移:演化出的框架能搬家
最后一个我觉得很惊艳的实验。Arbor 先在 BrowseComp 上跑,只用 BrowseComp 的反馈去演化搜索框架。然后把得到的框架冻结,直接拿去两个从没见过的搜索任务上评估,不做任何任务特定优化:
| 任务 | 迁移前 | 迁移后 |
|---|---|---|
| BrowseComp(留出准确率) | 45.33% | 67.67% |
| HLE | 25.50% | 31.50% |
| DeepSearchQA | 61.00 ± 6.76% | 69.00 ± 6.41% |
HLE 和 DeepSearchQA 在 BrowseComp 优化期间压根没出现过,但框架搬过去依然有增益。这说明 Arbor 发现的是框架级别、经得起任务分布偏移的改动,而不是死记硬背地拟合源基准。这对实际工程意义很大——你优化出来的东西能复用,而不是一次性的。
几张过程图:看 Arbor 是怎么"想"的

图5:探索效率对比。Arbor(实线)归一化后终点是 100%,Claude Code(虚线)止于自己的相对天花板。星标标出各自的留出最高分。能看出 Arbor 不光最终成绩高,爬升的轨迹也更扎实。

图6:这张图我特别喜欢。它展示了 Arbor 在 BrowseComp 上是怎么一步步深化对问题的理解的——从一个宽泛的问题框定出发,试一个修复,得到一个机制性发现,这个发现又推动下一次问题重构。这就是"累积式研究"的可视化:每一步都站在前一步的证据上。

图7:Arbor 在不同任务上想出来的代表性点子。论文强调这些想法是"程序性"的——是关于方法的可复用策略,不是针对某个具体样本的临时补丁。而且每个都是在前序节点排除了更大方向之后才提出的,体现了搜索的层层收敛。
我的判断:这篇论文好在哪,我又对什么打问号
先说亮点。
我认为这篇论文最大的价值,是把"研究该怎么组织"这个一直很虚的问题,落成了一个具体、可执行、可审计的数据结构。假设树这个抽象选得很准——它同时是搜索前沿、长期记忆、研究记录三位一体。这比"给智能体加个 memory 模块"那种缝缝补补的做法,在概念层面干净太多。
留出合并门是真正的点睛之笔。它直击 AO 任务最致命的陷阱——过拟合开发集。Terminal-Bench 那行数据(Claude Code 高 dev 低 test,Arbor 低 dev 高 test)就是活生生的证据。能在 AI 研究智能体里把科研方法论里"留出验证"这件事工程化,我觉得是这篇论文最成熟的地方。
消融里那个"没有洞见回传比没有树还差"的发现也很有洞察力——它说明结构本身不值钱,在结构上累积、传播证据的能力才值钱。这其实是对很多"加了树形结构就觉得万事大吉"的工作的一个提醒。
再说我打问号的地方。
第一,前面提过的,消融缺了对留出合并门的直接对照。这是个不小的遗憾,因为这道门是论文反复吹的核心,却没给一个"去掉它会怎样"的硬数字。
第二,树深默认只有 2,分支数 k 也没给具体取值和敏感性分析。论文用"固定深度跨任务都能赢"来论证提升来自搜索过程本身——这个论证方向我认可,但缺了深度/分支的超参数效应实验,我们没法判断这套机制对配置有多敏感。Architecture Design 长出 150 个节点而其他任务只有 15-26 个,这种巨大差异背后的规律,论文也没深挖。
第三,成本问题。48 小时墙钟、协调器加执行器双份 token——Arbor 显然比单智能体基线贵。图4 试图回应这点,但"2.5 倍增益"到底对应多少倍的成本,如果增益是靠堆资源换来的,那这个对比就需要打个折扣。这块我没完全看明白,得细读 cost log 才能下结论。
它处在什么位置?
放在自主科研智能体这条线上看,Arbor 不是第一个做"智能体搞研究"的(前面有 AI-Scientist、R&D-Agent、ML-Master 这一串),但它在"如何把长程探索组织成累积过程"这个具体问题上,给了一个我觉得相当成熟、相当工程化的答案。它的贡献更偏向系统设计和方法论,而不是某个底层算法突破。但有时候,把对的抽象选出来、把对的约束(留出门)立起来,比发明一个新 loss 更难、也更有用。
如果你也在搭长程自主智能体——尤其是那种要跑几十轮、要管多个方向的——Arbor 这套"假设树 + 洞见回传 + 留出合并门"的组合拳,我觉得非常值得抄进你的系统里试试。哪怕你不用它的全部,光是那道留出合并门,就能帮你挡掉一大半"看起来在进步、其实在过拟合"的假象。
觉得有启发的话,欢迎点赞、在看、转发。跟进最新 AI 前沿,关注我