arbor

Arbor — 通过假设树精炼实现自主优化

概述

这项技能会运行一个 自主优化（AO） 循环：从现有产物和可衡量的目标出发，通过多轮实验和评估不断改进——无需人工逐步监督，也不会对反馈信号过拟合。当瓶颈不在于写出一个好的改动，而在于 组织数十次试验，让经验不断累积而非消散时，它就是合适的工具。

它实现了 Arbor（Jin 等人，2026）提出的 假设树精炼（HTR）。核心思路是：将研究状态保存在持久化的 假设树 中，而不是对话历史里。每个节点都关联一个假设、由此得出的精炼见解，以及实现该假设的产物版本指针。你将作为长期运行的 协调器，维护这棵树并决定搜索方向；短期运行的 执行器 子 Agent 则在隔离的 git 工作树中各自测试一个假设，并汇报结果。只有当某项改动在搜索期间从未用于优化的 测试 评估器上有所提升时，留出集合并门 才会放行。正是这一机制，让反复试错成为可累积、可审计的研究。

使用 scripts/tree.py 状态管理器完成所有记录工作（创建节点、记录证据、传播见解、剪枝、合并门、Observe 投影）。它会保持状态一致，让你能够专注于判断证据 意味着什么。

何时使用这项技能

当任务是 在评估器下迭代改进具体产物 时，请使用 Arbor：

• 模型训练：调整优化器、架构或训练方案，以降低损失，或用更少步数达到目标。
• Harness/Agent 工程：提高 Agent 循环、搜索 harness 或工具使用框架的通过率或准确率。
• 数据合成：改进生成/筛选流程，并依据下游模型行为进行评判。
• 基准测试优化：MLE-bench / Kaggle 风格的“改进提交结果”任务。
• 提示词/系统优化：能够自动对输出评分时使用。

以下信号表明适合使用这项技能：存在一个 可修改的产物、一个 目标、一种 对候选方案评分 的方法，并且预计会运行 许多次实验。如果用户只想要一次性修复或答案，这就有些小题大做了——直接完成任务即可。如果用户想进行没有评估器的开放式构思，请改用 hypothesis-generation 或 scientific-brainstorming。

AO 设置——先明确以下内容

在进行任何实验之前，先确定任务元组 (M_0, O, E_dev, E_test)。正确设置这一点比之后的任何决策都重要，因此请明确确认：

• M_0 — 初始材料：需要改进的产物（仓库、脚本、配置或提示词）。确保它已纳入 git 管理且当前能够运行。
• O — 目标：自然语言目标和指标的优化方向（提高准确率？降低损失/步数？）。
• E_dev — 开发评估器：可在搜索期间自由运行、为候选方案评分的命令。它应快速且可重复。
• E_test — 留出的测试评估器：一个 独立的 评估器（使用不同的随机种子、不同的数据划分或更大规模的运行），仅用于合并门。不得将它用作搜索预言机——这正是设置它的目的。

如果用户没有提供清晰的开发集/测试集划分，请自行构建并说明。开发集/测试集的分离机制能够捕捉过拟合：候选方案在开发集上胜出、在测试集上却不胜出，这并非成功，而是对反馈信号进行利用的警示。缺少这一机制时，自主搜索必然会过拟合。

初始化运行：

python scripts/tree.py init \
  --objective "Improve BrowseComp answer accuracy on the search harness" \
  --dev-eval "python eval.py --split dev --n 50" \
  --test-eval "python eval.py --split test --n 300" \
  --material "." --metric-direction max --branching 3 --max-depth 2 --budget 12

--branching 表示每个父节点提出多少个同级假设；--max-depth 2 将方向限定在深度 1，将具体干预限定在深度 2（论文中的默认值）；--budget 表示协调器循环的次数。先从较小规模开始（10–20 次循环）——结构化搜索胜过蛮力搜索；如果仍在取得进展，可以再扩展。

协调器循环

你要重复执行包含六个步骤的循环。这是 HTR 的核心；不要把它简化成临时编辑。每个循环运行一次 python scripts/tree.py cycle，以跟踪预算。

1. 观察

每个循环开始时，都要重新审视树，而不是依赖对话记忆：

python scripts/tree.py observe

这会打印目标、全局洞见、当前活跃的前沿（可选择的假设）、已执行节点及其证据、已剪枝的经验（负向约束），以及当前最佳产物。将树视为事实来源，才能在长时间运行中保持连贯；上下文压缩会丢弃细节。

2. 构思

选择一个有前景的父节点，并在其下提出几个子假设。依据树中的证据进行判断——这正是 Arbor 与随机搜索的区别：

• 已验证的洞见是你可以据此构建的假设。
• 已剪枝的节点是应避开的死路。
• “部分正确”的结果是更精确假设的起点，而不是放弃该方向的理由。

每个假设都应是一个可证伪的主张，说明如何通过修改产物来改变指标，而非模糊的意图。深度为 1 的节点表示宽泛方向（“搜索工具链丢弃了已检索到的正确答案”）；深度为 2 的节点表示具体、可执行的干预（“运行 K=5 次独立的 rollout，并按证据档案汇总，而非采用多数投票”）。

python scripts/tree.py add-node --parent n0 --hypothesis "Verification, not retrieval, is the bottleneck: candidates are found but discarded"
python scripts/tree.py add-node --parent n4 --hypothesis "Decompose the question into atomic constraints and verify each independently"

3. 选择

选择接下来要运行哪些待处理的叶节点。选择并非单纯追求分数最大化——选择假设时，可以考虑其强有力的先验依据、它能否消除兄弟节点揭示的歧义，或其失败能否澄清重要假设。在反馈延迟的情况下，前沿管理应优先考虑能提供信息的实验，而不只是看起来有前景的实验。

4. 分派

将每个选中的假设作为一个在隔离工作树中运行的执行器子 Agent（使用 Agent 工具并设置 isolation: "worktree"，或让执行器通过 git worktree add 创建工作树）。隔离很重要：并行实验不得相互覆盖，也不得影响当前最佳产物；探索性改动在通过合并关卡前都应保持隔离。

如果兄弟节点彼此独立，应并行分派（在一条消息中调用多个 Agent）——同一方向内的对比证据，正是之后进行剪枝和抽象的关键。

给每个执行器一份精简、与假设绑定的任务说明。完整模板见 references/executor-brief.md。HTR 能够奏效的契约是：**指标停滞时，执行器不得更改假设。**它可以修复自己的代码并重新运行，但 h_n 是固定的——否则返回的分数就不再是该节点的证据，树的语义也会被破坏。执行器必须恰好返回以下四项：

• dev_score — dev 评估器的结果（用于选择）；
• result — 对实际情况的事实性摘要；
• insight — 提炼出的、可复用的经验（说明结果为何支持、削弱或限定了该假设）；
• branch_ref — 保存产物的 git 分支、提交或工作树路径。

分派前将节点标记为 running（tree.py set-status --node n5 --status running），以确保 Observe 投影保持准确。

5. 反向传播

执行器返回后，将其报告写入节点，然后向上提炼经验：

python scripts/tree.py set-evidence --node n5 --dev-score 70.0 \
  --result "K=5 dossier aggregation recovers answers in minority rollouts" \
  --insight "Correct answers often appear in a minority of rollouts; aggregation beats majority vote" \
  --branch-ref "wt/n5"

python scripts/tree.py propagate --node n5 \
  --insight "Candidate coverage, not verification, limits this direction" --to-root

这一步让这棵树不再只是日志。叶节点层面的观察（“数据接口不匹配”）应当转化为方向层面的约束；如果这一经验具有普遍性，还应成为影响未来构想的全局先验。洞见传播是 HTR 大部分性能提升的驱动力——在论文的 MLE-Bench Lite 消融实验中，没有洞见反馈的树，得分甚至低于完全没有树的扁平实验队列（任意奖牌获奖率为 54.5% 对 63.6%，而完整系统为 81.8%）。仅有层级结构还不够：语义记忆才是关键。因此，请认真思考如何提炼经验；不要只是把叶节点的洞见原封不动地向上传递。

6. 决策

根据新证据决定下一步：继续拓展某个方向、剪除被证伪的子树，或尝试合并候选方案。

• 剪除死胡同，并记录原因——这个原因会成为负向约束：

  python scripts/tree.py prune --node n7 --reason "search-augmented judge overfits dev questions; no test transfer"
  

• 合并门槛——只有候选方案优于 E_test 时，才将其提升为新的最佳方案。请在全新的工作树中运行测试评估器（不要使用开发工作树，以免发生数据泄漏），然后：

  python scripts/tree.py merge --node n5 --test-score 67.67 --branch-ref "wt/n5"
  

  如果门槛拒绝了候选方案，这本身就很有参考价值：开发集得分高、测试集得分低，说明该方向可能是在利用开发集信号，而非带来可迁移的改进。请记录这条经验；不要暗中将其提升为最佳方案。

重复此过程，直到预算用尽、探索前沿耗尽，或进展明显停滞。

完成本轮运行

停止时，请生成一份简短报告（参见 references/report-template.md），内容包括：

• 最终最佳产物、其测试得分，以及相较于 M_0 的变化；
• 作为审计记录的树（python scripts/tree.py status），展示尝试过的方案；
• 主要假设的变化——任务理解在整个运行过程中如何加深（早期节点测试宽泛的机制；后续节点探明其局限；祖先节点的洞见则将这些经验提炼为最终设计背后的约束）；
• 已合并与已探索的方案：许多节点能提升开发集表现，但通过测试门槛的要少得多——请如实报告这一差距，不要夸大开发集上的胜利。

务必将 M_best 保留为命名分支上的真实、可运行产物，并告知用户如何检出该分支。

让这种方法奏效的原则（而非死板规则）

这些原则源自论文的分析；理解为何重要，胜过机械照做。

• 树是记忆；对话不是。 在较长的运行过程中，你的上下文会被压缩。每个周期都要重新观察，确保决策依据持久可靠的证据，而非有损摘要。
• 结构化搜索，而非增加采样。 Arbor 的收益来自预算的组织方式——维护彼此竞争的假设、比较同级节点、传递经验——而非消耗更多 token。不要漫无目的地扩展；每项实验都应以树中已有的知识为依据。
• 开发集提供指导，测试集决定准入。 可以充分利用开发集反馈来引导探索，但未经测试集确认，绝不能让开发集上的胜利进入最终产物。开发集与测试集的分歧本身就是值得解读的信号。
• 执行器受假设约束。 本地工程上的灵活调整（编辑、调试、重新运行）没有问题；但为了追求更好的数字而悄然改变假设则不可取——这会破坏证据的意义。
• 失败是约束，不是噪声。 被证伪的假设会告诉你解决方案必须避开什么。剪除时说明原因，比剪除后遗忘更有价值。

参考文件

• references/htr-methodology.md — 深入介绍 HTR、节点结构、六个步骤及论文中的实证经验（消融实验、迁移、成本）。想了解某项设计选择背后的理由时，请阅读此文件。
• references/executor-brief.md — 交给每个执行器子 Agent 的简报模板。
• references/report-template.md — 最终报告的结构。
• references/arbor-upstream.md — 介绍如何安装并运行 RUC-NLPIR/Arbor 提供的独立 arbor CLI，而不是以原生方式编排，以及何时应优先选择其中一种方式。

Agent 操作流程

1. 检查环境。 确认目标、评估指标、预算（时间、算力、资金）和停止标准。
2. 明确输入。 根据数据或用户提供的信息确认格式、标识符和参数。任何会影响结果的值都应询问，不要猜测。
3. 先运行小规模版本。 端到端运行一次迭代，并在扩大规模前检查日志。
4. 按照上述说明和参考资料执行完整任务。
5. 验证结果。 在留出数据上进行评估；保留每次迭代、假设和结果的审计记录。
6. 报告。 说明运行了什么（版本、命令、参数）、检查了什么，以及还有哪些不确定之处。

如果发生这种情况	请这样做
某次迭代产生了可疑的大幅提升	在接受结果前，检查是否存在数据泄漏或评估错误。
这些说明中的函数、标志或端点在已安装版本中不存在	查阅该版本自身的文档（help()、--help、官方文档），进行调整，并告知用户。切勿虚构 API。
必需的输入、标识符或参数存在歧义	询问用户，或在运行前明确说明所采用的假设。

诚信规则

• 切勿捏造结果、参数、标识符、引文或统计数据。如果无法运行或验证某项内容，请如实说明。
• 记录负面结果；切勿只选择或报告有利的运行结果。
• 请将此处与版本有关的细节视为可能已过时，并对照已安装版本的官方文档进行确认。
• 对于会产生费用、占用共享 GPU 或云配额、涉及个人或患者数据，或无法撤销的操作，请先征求同意。

相关技能

• research-skill-creator：创建、改进和测试适用于研究工作流（论文写作、实验室方案、分析管线、领域数据库）的 Agent 技能，使其达到……
• statistical-analysis：针对研究数据开展引导式统计分析——选择检验方法、检查假设、评估效应量和统计功效、提供贝叶斯替代方案，以及……
• nextflow：端到端构建、运行和调试 Nextflow 数据管线及 nf-core 工作流。