Arbor：当AI学会像科学家一样"种树"

> Jin, J. et al. *Toward Generalist Autonomous Research via Hypothesis-Tree Refinement.* arXiv:2606.11926, 2026. 中国人民大学 & 微软研究院.

---

一、一个科研团队的日常

想象一个真实的科研团队。

不是那种一个人闷头写代码的画面。是一个有三五个人、有白板、有咖啡渍的实验室。

有人在看论文，有人在跑实验，有人在白板前争论"这个方向到底行不行"。上周的实验失败了，但失败里藏着一个线索——数据预处理的方式有问题。这个线索被记在笔记本上，成为这周新假设的起点。

团队里有个"包工头"（PI），他不写代码，但他记得每个人在做什么、什么方向已经死了、什么方向还有戏。他看着满白板的分支，决定明天让谁去试什么。

这不是效率最高的组织方式。但它是有效的——因为科研本质上是试错，而试错的唯一价值在于：你记得上一次试了什么、为什么失败、失败里有什么可以复用。

微软和人大的团队最近做了一件事：他们把这套组织结构，写进了一个AI系统里。

它叫 Arbor。拉丁语里"树"的意思。

---

二、为什么单 agent 做不好科研？

在讲 Arbor 之前，先问一个问题：为什么现有的 AI coding agent——Codex、Claude Code、OpenHands——在做科研任务时，总是差点意思？

它们能写代码、能调包、能跑实验。给它们 48 小时，它们能不停地改、跑、再改。但问题恰恰在这里：

它们没有记忆结构。

每个实验都是独立的。第 10 次实验和第 1 次实验之间，除了日志文件里的痕迹，没有任何语义连接。如果一个实验失败了，agent 不会想"这个失败告诉我什么"，它只是继续试下一个。如果两个实验的方向互相矛盾，它不会意识到——因为它没有一个"全局视图"。

更糟的是，没有 dev/test 分离。它在训练集上调参，看到指标涨了，就以为自己进步了。但那个进步可能只是过拟合了 dev set。等拿到 held-out test 上一测，崩了。

人类科研者不会这样。我们会：

在白板上画树状图，标记哪些方向死了、哪些还活着
把失败的教训写成笔记，下次避开
只在验证集上确认有效后，才说"这个方向成立"

Arbor 的核心洞察：科研不是一连串独立的实验，而是一棵不断生长的假设树。

---

三、假设树精炼（HTR）：科研状态的结构化

Arbor 的架构分为两层：

┌─────────────────────────────────────┐
│         Coordinator（包工头）          │
│    持久化假设树 · 全局策略 · 决策        │
└──────────────┬──────────────────────┘
               │ 派遣/回收
┌──────────────▼──────────────────────┐
│         Executor（打工人）×N          │
│    隔离工作区 · 实现假设 · 跑实验        │
└─────────────────────────────────────┘

3.1 假设树的三个字段

假设树的每个节点不是一个实验记录，而是一个研究单元：

假设（h）：一个可验证的声明。根节点是宏观方向（"改进数据增强策略"），叶子节点是具体干预（"在预处理中加入高斯噪声，σ=0.1"）。

洞察（ι）：实验结果的可复用解释。不是原始日志，而是提炼后的教训——"σ=0.1 在 dev 上提升 2%，但 test 上无增益，说明过拟合了 dev set 的噪声特征"。这个洞察会上传，影响父节点和兄弟节点的后续决策。

元数据（μ）：指向代码分支、评估分数、事实结果的引用。树本身不存代码，只存指针——保持紧凑。

3.2 六步循环：Observer → Ideate → Select → Dispatch → Backpropagate → Decide

Coordinator 每轮循环做六件事：

1. Observe（观察） 读一遍当前的假设树。有哪些叶子还没执行？哪些分支最近返回了证据？当前最佳 artifact 是什么？

这一步防止 coordinator 依赖"对话历史"——树才是唯一权威状态。

2. Ideate（构思） 选一个父节点，提出几个子假设。不是自由 brainstorming，而是基于树的已有证据：

已验证的洞察 → 作为新假设的前提
被剪枝的节点 → 作为负向约束（不要再试这个方向）
最近的执行报告 → 提示哪些干预可行

3. Select（选择） 从 pending 节点中选下一个要执行的。选择标准不是"哪个分数最高"，而是"哪个实验能提供最多信息"。

一个强先验的方向值得试。一个和已有结果矛盾的方向也值得试——因为它的失败能澄清一个重要假设。

4. Dispatch（派遣） 把选中的节点派给独立的 executor。每个 executor 在一个隔离的 git worktree 里工作，实现假设、跑 dev 评估、返回结构化报告。

5. Backpropagate（回传） Executor 返回后，把证据写回叶子节点：分数、事实结果、提炼洞察、代码分支引用。然后把这个信号向上传播——更新父节点、祖父节点的洞察。

关键：传播的不是分数，而是因果归因和可复用教训。

6. Decide（决策） 基于更新后的树，决定：

继续扩展某个方向？
剪枝一个被证伪的子树？
停止搜索？
尝试合并一个候选分支？

合并门（Merge Gate）：一个候选分支只有在 held-out test 上验证有效后，才能被合并到当前最佳 artifact。这防止了 dev set 过拟合。

---

四、Executor 的"紧箍咒"： hypothesis-bound

Executor 的设计有一个关键约束：hypothesis-bound。

Executor 拿到一个节点，必须严格实现那个假设。如果实验过程中发现假设有问题，它不能擅自改方向——它必须如实返回"这个假设在当前条件下不可行"。

为什么？因为如果 executor 擅自改假设，返回的分数就不再是关于原假设的证据。树的语义就被破坏了——你不知道这个分数到底验证了什么。

这像是科研中的"预注册"（pre-registration）：你先声明要验证什么，再去做实验。实验过程中可以修正实现细节，但不能偷换研究问题。

---

五、实验：六个真实研究任务

论文设计了六个 AO（Autonomous Optimization）任务，覆盖三类真实科研场景：

5.1 模型训练

Optimizer Design（NanoGPT-Bench）

初始：Muon optimizer 基线
目标：用更少的优化步数达到目标验证 loss
测试：两个 held-out random seed 上的平均步数

Architecture Design（autoresearch benchmark）

初始：标准 LLM 训练代码
目标：固定时间预算内获得更低的最终 loss
测试：两个 held-out seed 上的平均 loss

5.2 Harness 工程

Terminal-Bench 2.0

初始：标准 terminal agent 代码
目标：提高 terminal 代码和 shell 任务的通过率
dev：36 个任务，test：53 个 held-out 任务

BrowseComp

初始：最小 ReAct 搜索 harness
目标：提高浏览问题的答案准确率
dev：50 题，test：300 题（不重叠）

5.3 数据合成

Search-Agent Data Synthesis

初始：手工设计的问题生成 pipeline
目标：生成更好的搜索 agent 训练数据
评估：强 GPT-5.5 ReAct evaluator 的 pass@4 - pass@1 gap

Math-Reasoning Data Synthesis

初始：AIME 风格推理题生成 pipeline
目标：生成更有挑战性的数学题
评估：同上

关键设计：所有任务都有严格的 dev/test 分离。Agent 只能在 dev 上探索，test 只用于最终验证。

---

六、结果：2.5 倍的差距

Arbor vs Codex (GPT-5.5) vs Claude Code (Claude Opus 4.6)，同等任务接口、同等资源预算（48 小时 wall-clock）。

6.1 六个任务全赢

任务	初始	Codex	Claude Code	Arbor
Optimizer Design (↓ steps)	72.0	65.0	62.5	51.5
Architecture Design (↓ loss)	3.423	3.398	3.389	3.364
Terminal-Bench (↑ pass%)	35.85%	41.51%	39.62%	49.06%
BrowseComp (↑ acc%)	45.33%	50.00%	53.33%	67.67%
Search-Agent Data (↑ gap)	0.104	0.135	0.146	0.219
Math-Reasoning Data (↑ gap)	0.104	0.156	0.177	0.292

Arbor 在所有六个任务上取得最佳 held-out 结果。

平均相对 held-out 增益是 Codex 和 Claude Code 的 2.5 倍以上。

6.2 MLE-Bench Lite

系统	Any Medal
AIDE	72.73%
ML-Master 2.0	72.73%
MARS	77.27%
AIBuildAI	81.82%
Arbor (GPT-5.5)	86.36%

Arbor 达到 86.36% Any Medal，对比系统中最高。

---

七、关键洞察：为什么树结构赢了？

实验结果支持论文的核心假设：

> 在 Autonomous Optimization 中，瓶颈不是局部代码编辑能力，而是把多次试错组织成连贯探索过程的能力。

三个关键设计决定了差距：

1. 失败的价值

Codex 和 Claude Code 也会失败。但它们的失败是"沉没成本"——失败了就失败了，不会系统性记录失败里有什么可复用的约束。

Arbor 的假设树把每次失败都变成树的一个节点，洞察上传播后成为全局约束。同一个坑不会踩两次。

2. Dev/Test 分离

单 agent 系统容易在 dev 上过拟合——看到指标涨就以为进步了。Arbor 的合并门强制要求 held-out test 验证，只有真正泛化的改进才被采纳。

3. 并行探索 vs 单线程执行

Codex/Claude Code 本质上是单线程的：改代码、跑实验、看结果、再改。Arbor 的 coordinator 可以同时派遣多个 executor 探索不同方向，比较证据后再决定哪个方向值得深入。

这不是简单的"多跑几个实验"，而是有结构地并行——每个实验的位置都在树上，彼此的关系清晰可见。

---

八、局限与追问

1. 树深度限制

论文默认树深度限制为 2。这个限制是为了控制搜索空间，但也意味着 Arbor 不能进行非常深层的假设细化。更深的树会不会更好？还是会更早陷入局部最优？

2. Coordinator 的瓶颈

Coordinator 每轮都要"读一遍整棵树"。当树很大时，context window 会不会成为瓶颈？论文提到 coordinator 会读"结构化投影"而不是整棵树，但具体的压缩策略没有详细展开。

3. 成本

Arbor 用了 coordinator + 多个 executor，token 消耗会不会远高于单 agent？论文说"没有显著更大"，但具体数字没有给出。

4. 通用性边界

六个任务都是代码可执行的。如果研究任务涉及湿实验（wet lab）、人体试验、或者需要数月的计算，Arbor 的假设树机制还适用吗？洞察的回传周期会从小时变成周甚至月，树的"活性"怎么维持？

---

九、总结：科研自动化的分水岭

Arbor 的意义不在于"又一个能写代码的 agent"。

它的意义在于：它把科研的组织结构——而不是科研的具体技能——自动化了。

一个 PI 记得住团队里每个人在做什么、什么方向死了、什么教训可以复用。一个研究生在笔记本上记录失败的原因，下次避开。一个团队在组会上争论哪个方向值得继续投资源。

这些不是"编程能力"，是科研的组织记忆。

Arbor 的假设树就是这个组织记忆的具象化。它让 AI 不再是"一个在做实验的个体"，而是"一个在进行结构化探索的研究团队"。

从 single agent 到 multi-agent 是第一步。从 multi-agent 到有组织记忆的 multi-agent 是第二步。

Arbor 走了第二步。

---

参考

Jin, J. et al. (2026). Toward Generalist Autonomous Research via Hypothesis-Tree Refinement. *arXiv:2606.11926*. 中国人民大学 & 微软研究院.
Lu, C. et al. (2024). The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. *arXiv:2408.06292*.
Jiang, D. et al. (2025). AIDE: AI-Driven Exploration in the Space of Code. *arXiv:2502.13138*.

#论文拆解 #自主科研 #Agent #多智能体 #微软 #人大 #Arbor #假说树 #小凯