想试试 autoresearch 但不知道从哪开始?我做了个 Claude Code 插件 — EVO
对于已经 autoresearch-pilled 的各位,或者早就想入门 autoresearch 但不知道从哪开始的朋友 —— 我最近开源了 EVO。一个 Claude Code / Codex 插件。你把它指向一个 codebase,它自己找 benchmark,跑 baseline,然后派出并行 agent 去尝试超越它。更好的就保留,更差的就丢弃。
🔗 GitHub: github.com/evo-hq/evo Apache 2.0 开源协议。无需注册,不需要 Claude Code 或 Codex 以外的 API key。
autoresearch 是什么
autoresearch 是一种技术 —— 让 LLM 自己在代码库上跑实验。它提出一个假设,改代码,跑 eval,如果分数上去了就保留,不行就回退。循环往复。内循环里不需要人介入 —— LLM 就是研究员,benchmark 就是裁判。
Andrej Karpathy 发过 最早的版本 —— 单分支上的纯爬山
思路干净,而且确实能跑通。但是一旦你想把它做大 —— 并行跑多个实验、分支卡住时能绕开、防止 agent 在 metric 上作弊 —— 单分支的 try-and-revert 就不够用了。
EVO 加的正是这部分结构。
EVO:autoresearch,加了点结构
在纯爬山上面层了五件事:
1. 树搜索。 每个实验都从一个已提交的父节点 fork 出来,所以探索不会坍缩成一条路径。分支卡住的话,可以从更早的祖先节点再 fork —— 那里可能还有余量。
2. 并行 subagent。 N 个 subagent 同时跑,每个都在自己独立的 git worktree 里,有自己的迭代预算。它们读共享状态,提出假设,改目标文件,跑 benchmark,再回报。
3. 共享失败 traces。 每条 trace —— 试了什么、坏了什么、学到了什么 —— 都会写到一个 scratchpad,每个 agent 下手前都会先读一遍。不会再出现多个 agent 独立重复同一个坑的情况。
4. 回归 gate。 autoresearch 天然有 Goodhart 问题:如果分数是唯一目标,agent 会找出各种方式去搞分数而非真优化。gate 就是一道跟分数并列的检查 —— 后面会细说。
5. benchmark 自动发现。 你不用手动挑 metric。EVO 会读你的 repo(README、测试、配置、TODO、已有的 eval),然后给出一个带依据的候选清单。你选一个。
每个 ✓ 节点都是该实验分支上的真实 git commit。每个 ✗ 都是已经被清理掉的 worktree。值得注意的是 —— 最佳路径并不是开局领先的分支:全局最佳从 exp_3 → exp_6 → exp_11 → exp_12 出来,而不是早期看起来更强的 exp_1 一脉。这就是树搜索相对贪心爬山的价值:它允许一条慢热分支有机会复利涨上来。
安装
Claude Code:
/plugin marketplace add evo-hq/evo
/plugin install evo@evo-hq-evo
重载 Claude Code。两个命令在任何 repo 里都可用:
/evo:discover # 读你的 repo,提出 metric,跑 baseline
/evo:optimize # 启动并行 agent,每个从已提交的父节点 fork
Codex:
uv tool install evo-hq-cli
codex marketplace add evo-hq/evo
进入 Codex,/plugins 找到 evo 安装。同样两个 skill 在 Codex 里通过 $evo discover 和 $evo optimize 调用。
底层发生了什么
- 每个实验都是一个 git worktree,从它的父节点分出去。分数提升而且过了 gate,改动就会提交到该实验的分支;分数回退或 gate 失败就丢弃,worktree 清理。
- main 分支永远不会被提交。 benchmark harness、instrumentation、实验提交 —— 全部住在
.evo/run_xxxx/下的实验分支上。main 分支跟你跑 evo 之前一字不差。不想要结果?删掉.evo/目录就行。 - gate 沿着树向下继承。 某个节点上加的 gate 会自动应用到它所有子孙节点。实验跑起来时,会被它祖先加过的每一个 gate 检查。
- subagent 可以在运行中新增 gate。 当 subagent 发现某个不变量值得守护("refund 流程必须继续返回合法 JSON"),它会通过
evo gate add注册一个 gate,之后所有实验都要过这一关。gate 集合随运行成长 —— 反映的是系统发现了什么重要,而不是第一天写死的配置。 - Orchestrator 会观察跨轮次的 gate 失败模式。 如果一轮里三个实验全部死在同一个 gate 上,Orchestrator 会把这个模式提出来 —— 要么是 gate 太紧,要么是该方向本身有结构性缺陷。下一轮的任务书要么绕开,要么正面攻。
- Dashboard 在
localhost:8080—— 树、分数时间线、subagent 日志、gate 历史,全部实时。
想往深了看的几个设计笔记
- gate 是行为检查,不是分数检查。 gate 就是一条 exit 0 表示通过的 shell 命令。典型的有:测试套件(
pytest tests/core -x)、某个特定不变量的脚本(比如 refund 流程返回非法 JSON 就 exit non-zero)、benchmark 的一个 held-out 切片(优化期间 agent 看不到)。重点是:拦住那些把分数做上去但把其他东西搞坏的改动 —— 那些东西很重要,但没在 score 里。当 EVO 从零构建 benchmark 的时候,会强制要求至少一个非 trivial 的 gate 才能启动 —— 否则一个自己给自己打分的 benchmark 就很容易被"背答案"式地刷分。
- discover 是一个 skill 文件,不是写死的 heuristic。
evo:discover是plugins/evo/skills/discover/SKILL.md这个纯 markdown 文件,描述了怎么读你的 repo、怎么提候选 metric(带依据)、怎么搭 baseline。你可以读、可以 fork、可以改 prompt 适配自己的风格。 - optimizer 也是一个 skill。
evo:optimize就在 discover 隔壁,同样的 pattern。两者都可以检视可以修改 —— 没有魔法,没有.evo/之外的隐藏状态。
结语
如果这是你感兴趣的方向,给 repo 点个 star ⭐ —— 能帮到它被更多人看到,也让我知道要不要在这条方向上继续推。
评论区聊,欢迎提问、吐槽、建议。
