跳转至

准备一个基准

你不需要写配置来让 Arbor 对准一个任务。唯一真正的硬性要求是：一个 Arbor 能 运行并产出一个分数的仓库。其余一切——指标的含义、哪些不能改动、目标设得多高——都在你 启动 arbor 时的一段简短接入对话（intake chat）里确定。无需手写 YAML，无需撰写评测契约， 也不需要 README。

1. 一个可评分的基线仓库

把你的代码和数据放在一个目录里——通常就是你已有的仓库：

my_task/
├── data/            # 数据集与任何固定输入
├── eval.sh          # 给候选打分并打印指标
└── train.py         # 你的起点代码（Arbor 会改这个）

Arbor 唯一需要的，是一条在某一行打印它能读取的指标的命令。你的 eval.sh （或 python eval.py、make eval……）应当输出形如：

score: 0.8123

仓库里已经有一个能跑通的简单基线是最理想的——它为 Arbor 提供了一个要超越的基准数字，也确认评测确实能跑。

只有代码？接入智能体能替你搭好评测

在你开始之前，你并不需要评测脚本——甚至不需要 dev/test 划分。如果你的仓库只有代码，照样 启动 arbor：在接入对话里，智能体会询问“更好”意味着什么，然后提出搭建一个最小评测 （如果你愿意，还会切分出 dev/留出划分）供你确认。没有留出集，也不打算准备？你可以在单一划分上 迭代——智能体只会提示最终分数缺少留出护栏。见 描述任务。

让接入智能体处理准备工作

你不必预先初始化 git、给脚本 chmod +x，或自己跑评测。当你启动 arbor 时，接入智能体会在 研究开始前自动替你完成这些准备步骤（并确认评测确实产出一个分数）。

2. 描述任务——用 README 或者 直接告诉 CLI

Arbor 需要对任务有一个清晰、通俗的整体了解。你可以用任一方式提供：

  • 在接入对话里 —— 最简单的路径。启动 arbor，智能体读取你的评测脚本和代码，提出它推断出的 指标、基线、目标与约束，并请你确认或纠正。任何缺漏，在对话中补充即可。无需编写文件。
  • 在 README 里（可选）—— 如果你的仓库已经有一份，智能体会像人一样读它，并据此预填计划，于是 要确认的东西更少。当你经常跑同一个任务、或要把它交给同事时很方便。

无论哪种方式，这幅图景都覆盖四件事——无论它们来自 README 还是来自你在对话中的回答：

  • 任务 —— 这个项目是什么，一个解长什么样。
  • 指标 —— 正在优化哪个数字，越高还是越低更好（例如"最大化 bash eval.sh 打印的准确率"）。
  • 目标 —— 这次运行的目标设得多高（“超过基线”、“达到 60% 以上”，或“尽可能提高”）。
  • 什么不能碰 —— Arbor 绝不能改动的任何东西，比如 data/ 或评测脚本本身。

没有特殊格式，也没有必填字段。描述越清楚——无论是文字还是口述——智能体的第一版计划就越好。

3. 启动并确认

从仓库内部启动交互式 CLI：

cd my_task
arbor

在接入对话里，智能体检视仓库（以及你的 README，如果有的话），陈述它推断出的指标、基线、 目标与约束，并请你一次性确认或纠正。确认开始后，它就启动研究——提出假设、修改你的代码、运行真实 实验，并只保留那些提升了留出分数的改动。

整个准备就这些。Arbor 所需的一切——怎么评测、保护什么、什么算"更好"——都来自你的仓库加上那段 简短的确认，而不是来自一份你要维护的配置文件。

留出纪律

Arbor 在 dev 信号上迭代，但只有当一个改动把 留出（held-out） 指标提升超过一定幅度时 才保留它。正是这一点防止了对迭代信号的过拟合。见 工作原理 → 评测纪律。

保存并复用一套设置

你告诉接入智能体的任何东西都不会被丢弃。每次运行都同时记录指令（你打磨后的目标）与本次运行 完全解析后的设置，于是你日后能延续或复现工作，无需重新输入任何内容。

  • 续上同一项研究 —— 每次运行都在 <project>/.arbor/sessions/<run_name>/ 下设有检查点。只需 在项目里再次启动 arbor，从续跑列表里挑一个过去的运行（或 arbor --resume --run-name <name>）。 这会恢复想法树、历史与原始指令。见输出与续跑。
  • 以相同设置全新重跑 —— 每次运行都把它解析后的配置写到 <run_name>/.coordinator/config_snapshot.yaml（合并了每一层，密钥已脱敏）。把它复制到项目根目录 并命名为 arbor.yaml（或 research_config.yaml），Arbor 在下次运行时自动加载它，于是预算、 保护路径与 provider 设置都会延续。见配置。
  • 为每个项目一次性设默认值 —— 运行 arbor setup 写出 ~/.arbor/config.yaml；这些会成为你 全局的 CLI 默认值。

  • 无人值守地重跑同一个目标 —— 以无头方式传入指令，完全跳过对话：

    arbor run "maximize dev score from bash eval.sh; don't touch data/ or eval.sh" \
  --yes --yes-cwd ./my_task

更进一步

对一次性研究，上面的步骤就够了。如果你反复运行同一类基准——并想固定确切的评测契约、保护 路径、预算与领域指导，让每次运行都保持一致——就把它们一次性固化进一个插件。Arbor 随附了一个面向 Kaggle / MLE-bench 的插件（mle_kaggle）作为可参照的范例。