夜雨聆风本文基于人大×微软开源的Arbor论文及VentureBeat报道整理，探讨如何将"假设树"思想应用到日常AI编程工具中。
你用过Claude Code或Codex ？
如果你用过Claude Code、Gemini CLI这类AI编程工具，大概率经历过这样的场景：
让AI优化一个RAG系统的准确率，它改了一堆东西——chunking策略、prompt模板、检索方法——一次全改了，跑出来分数涨了，但你根本说不清到底哪个改动起了作用。
让它继续优化，它换了另一个方向，分数降了。再换一个，又降了。折腾了一两个小时，最后可能还不如最初的版本。
问题出在哪？
不是AI不够聪明，而是它没有"研究记忆"。
每次尝试之间缺乏结构化的关联——失败的原因没有被记录，成功的经验没有被抽象，不同方向之间没法比较。AI只是在一条轨迹上闷头试错，试多了难免原地打转。
人大高瓴人工智能学院和微软研究院的Arbor框架，正是要解决这个问题。
Arbor是什么：一棵会生长的假设树
Arbor的核心机制叫Hypothesis-Tree Refinement（HTR，假设树优化）。它把整个研究过程外化成一棵不断演化的树，每个节点都是一个可被验证的研究假设。
每个节点包含四样东西：
假设：这个节点想验证什么——比如"把chunking从固定长度改成语义分割，检索准确率会提升" 代码改动：对应的artifact版本 实验证据：开发集分数、运行日志、错误信息 提炼的洞察：为什么成、为什么败、在什么条件下有效
这棵树同时扮演三个角色：
搜索空间：哪些方向在探索、哪些已经失败、哪些值得继续 长期记忆：成功和失败都变成结构化经验，不散落在对话历史里 研究记录：每次改动和背后的假设、证据、决策全部可追溯
两级架构：研究负责人+实验执行者
Arbor用了一个很干净的设计把"长期策略"和"短期实验"分开：
Coordinator（研究负责人）：维护全局假设树，观察当前研究状态，提出新假设，挑选值得做的方向，根据结果决定哪些继续、哪些剪枝。
Executor（实验执行者）：每个只负责一个具体假设，在隔离的git worktree里改代码、跑评测、查失败原因，最后把结果结构化交回去。
这种分离的关键在于：如果把全局策略和局部执行混在同一个长上下文里，低层执行细节（代码怎么改的、日志报了什么错）很容易把全局判断（哪个方向该继续、该合并哪些发现）淹没掉。
六步飞轮：让每次实验都有意义
Arbor的运行是一个持续转动的飞轮：
① 观察——Coordinator重读当前假设树，了解已有方向、最近结果、失败归因和已验证的洞察
② 提出假设——基于当前理解，选一个父节点，生成若干子假设
③ 选择方向——从待探索的叶子节点中挑最有价值的交给Executor
④ 执行实验——Executor在隔离的worktree里实现改动、跑评测
⑤ 洞察回传——把结果、分数、insight写回树，并沿着父节点向上传播
⑥ 合并决策——只有当候选在held-out验证集上超过当前最优，才真正合并
最后一步很关键——开发反馈负责探索，held-out反馈负责确认真实进展。Arbor刻意引入了held-out merge gate，防止在开发集上过拟合。
效果怎么样？
论文在六个真实科研任务上做了评测，覆盖三类场景：
模型训练：优化器设计、架构设计 Harness工程：改Agent的控制逻辑和工具使用方式 数据合成：改进数据生成pipeline
对照是Codex和Claude Code这两个最强的单轨迹coding agent，同样能看文件、改代码、跑实验，相同预算。
Arbor在六个任务上全部拿到最好的held-out分数。
几个具体数字：
BrowseComp（搜索Agent优化）：Arbor把held-out准确率从45.33%拉到67.67%，Codex只到50%，Claude Code到53.33% Math-Reasoning Data Synthesis：Arbor提升19.79个点，Codex和Claude Code分别只有5.21和7.29 MLE-Bench Lite：Arbor with GPT-5.5拿到86.36% Any Medal，当前SOTA
整体来看，Arbor的平均相对held-out gain是Codex和Claude Code的2.5倍以上。
更有意思的是消融实验：去掉假设树，Any Medal从81.82%掉到63.64%；保留树但去掉洞察传播，进一步掉到54.54%。光去掉洞察传播，比直接砍掉整棵树掉得还多——说明一棵不传播经验的树只是把实验排排坐，给不出后续决策真正需要的语义记忆。
关键不在"试得更多"，在"组织得更好"
Arbor消耗的token和Claude Code这些基线是同一量级，却拿到了更大的held-out增益。差距不在花了多少算力，而在算力被怎么用。
此外，Arbor还展示了跨任务迁移能力：在BrowseComp上优化过的搜索代码，拿到两个完全没见过的搜索任务（HLE和DeepSearchQA）上测试，性能也显著提升。这说明它学到的不只是过拟合特定benchmark的技巧，而是真正有泛化能力的搜索策略。
怎么用？三种方式
Arbor已经开源，GitHub上提供了三种使用方式：
方式1：CLI直接跑（适合有API key的用户）
pip install arbor-agent
arbor setup # 配置模型和API key
arbor # 启动交互式研究会话
支持Anthropic、OpenAI、以及通过LiteLLM兼容的DeepSeek、Gemini、Qwen、vLLM、Ollama等各种后端。
方式2：Claude Code/Codex里用Skill（最推荐）
如果你已经在用Claude Code或Codex，不需要额外API key：
pip install arbor-agent
arbor install # 自动检测并安装到你的coding agent
然后在Claude Code里直接输入：
/arbor-research-agent optimize this repo for accuracy.
Ask before training, package installs, or B_test.
Arbor会接管研究流程——提出假设、隔离执行、回传洞察、合并结果。你的coding agent的模型驱动研究循环，Arbor提供持久的假设树、评测隔离和合并决策。
方式3：纯Skill指令（零安装）
不想装Python包也没关系，Arbor的Agent Skill Suite可以直接作为纯指令使用——你的AI工具读指令、按流程执行，Arbor提供标准的stdlib fallback helper。
一个可以5分钟跑通的Demo
# 复制一个微型benchmark（纯NumPy，CPU-only，秒级完成）
cp -r examples/algotune_knn /tmp/algotune_knn
cd /tmp/algotune_knn
git init -q && git add -A && git commit -qm baseline
# 启动Arbor
arbor
这个demo的任务是让一个暴力k近邻算法更快，同时保证输出一致。一次6轮运行就能把dev speedup从1.01x推到7.77x，held-out test从1.00x到7.22x。
把Arbor的思想用到你的日常工作中
就算不直接装Arbor，它的核心思想也值得借鉴。下次你让Claude Code或Cursor做深度优化时，可以试试这些做法：
1、每次只改一个变量
别让AI同时改prompt、chunking、检索方法。把每个可能的改进方向拆成独立的假设——"如果我把chunking改成语义分割会怎样？""如果我在prompt里加few-shot example会怎样？"——然后逐个验证。
2、保留dev和test两套数据
就像Arbor的held-out merge gate一样，用开发集做快速迭代，只在test集上确认真实进展。防止AI在开发集上过拟合。
3、记录失败原因，不只是分数
每次实验后，不仅记分数，更要追问"为什么"。失败是因为接口不兼容？还是方向本身有问题？这些洞察比分数更有价值——它会指导后续的假设生成。
4、用git分支隔离实验
每个假设在独立的分支上实验，不要直接在main上改。这样你可以随时对比不同方向的代码差异，也能干净地合并有效的改动。
5、维护一个假设清单
用一个简单的Markdown文件或文档维护你的"研究状态"：哪些方向已验证、哪些已排除、每个方向的结论是什么。这就是手动的假设树。
写在最后
Arbor想回答的其实是一个更大的问题：
当AI已经会写代码、会跑实验之后，怎样才能让它真正积累起研究进展？
它的答案是——让AI像研究者一样维护假设、证据、失败和洞察，让每一次实验都成为下一次探索的基础。
这个思路不只适用于学术科研。任何需要长时间、多轮迭代的优化任务——调优一个RAG系统、改进一个Agent pipeline、优化模型训练配方——都可以从中受益。
正如论文作者金佳杰在接受VentureBeat采访时说的："一个循环并不等于进步。如果目标模糊，或者指标容易被hack，长时间运行的自动化往往只是更快地产出'改进'，而这些改进其实没人需要。"
Arbor的价值，正是让AI的探索变得结构化、可积累、可验证。
论文链接：https://arxiv.org/abs/2606.11926[1] 项目地址：https://github.com/RUC-NLPIR/Arbor[2] 参考来源：PaperWeekly、VentureBeat
引用链接
[1]https://arxiv.org/abs/2606.11926
[2]https://github.com/RUC-NLPIR/Arbor