AIDE ML 拆解：把机器学习代码写成搜索树的开源参考实现
AIDE: an LLM agent for machine learning engineering - the research Weco grew out of. Referenced in OpenAI MLE-bench.
秒懂
- 它是什么？
- AIDE ML 是 Weco 论文中 AIDE 算法的开源参考实现，用 LLM 在代码空间里做树搜索，直到用户给定的指标被优化。它面向的是想复现论文、替换搜索策略的研究者，而不是想直接上生产的团队。
- 适合谁用？
- 如果你在做 agent 架构研究，想替换搜索启发式、评估器或 LLM 后端，或者需要复现论文里的结果，AIDE ML 的定位正好对得上：pip install -U aideml 之后用 aide data_dir=... goal=... eval=... 就能跑起来，日志里会留下 best_solution.py 和 tree_plot.html。如果你的目标是稳定交付生产级流水线，这个仓库并不合适，README 自己把生产场景指向了 Weco 平台，而且它默认的 agent.code.model 是 gpt-4-turbo，跑一次的开销取决于 agent.steps 和 agent.search.num_drafts 的乘积。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 12 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是「谁来写下一版代码」这个问题
机器学习工程里最耗人的环节不是训练，而是反复改脚本：换特征、调预处理、修报错，然后重新看验证指标。AIDE ML 把这一圈交给 LLM。README 的定位写得很直白，它是一个 LLM 驱动的 agent，负责写、评估并改进机器学习代码，输入是数据集目录加上一句自然语言的 goal 和 eval，比如 goal="Predict churn" 和 eval="AUROC"。
目标读者被 README 分成两类。一类是 agent 架构研究者，可以换掉搜索启发式、评估器或 LLM 后端；另一类是机器学习实践者，想根据给定数据集快速搭出一条性能不错的流水线。这两类人的诉求差别很大，前者关心机制是否可插拔，后者关心跑完能不能拿到能用的代码。仓库的自我描述是 research-friendly，并且明确把自己和 Weco 的商业产品区分开：这个仓库是精简实现，用于实验和扩展。这句话其实已经划定了边界，它不是给生产环境准备的那一层。
树搜索的机制：每个脚本是一个节点，指标负责剪枝
AIDE 的核心不是让模型一次性写出完整方案，而是把搜索过程显式地建成一棵树。README 的描述是：每个 Python 脚本成为解树中的一个节点，LLM 生成的补丁派生出子节点，指标反馈用来剪枝并引导搜索方向。也就是说，agent 不是在一个上下文里连续对话，而是在维护一组候选实现，每个候选都带着自己的验证分数。
这个设计带来一个直接后果：搜索的宽度和深度都是可以调的参数，而不是靠提示词暗示。CLI 里 agent.steps 控制改进迭代次数，默认 20；agent.search.num_drafts 控制每一步生成几个草稿，默认 5。这两个数字相乘大致决定了你会调用多少次模型，也决定了成本量级。仓库还提供 HTML 可视化，把整棵解树和每个节点附带的代码画出来，跑完之后 logs/<id>/tree_plot.html 可以直接点开看。对研究者来说，这棵树本身就是可分析的对象，你能看出模型在哪些分支上浪费了预算。
README 引用 OpenAI 的 MLE-bench（75 个 Kaggle 竞赛）作为外部证据，说 AIDE 的树搜索拿到的奖牌数是最佳线性 agent（OpenHands）的 4 倍。这是论文层面的结论，不是这个仓库的基准测试，引用时应该按论文的口径理解。仓库还列出了一批基于或引用 AIDE 的公开研究，包括 METR 的 RE-Bench、Sakana AI 的 AI Scientist-v2、Meta 的 LLM Speedrunning Benchmark 和 aira-dojo、以及 SJTU 的 ML-Master。这份名单说明算法本身被复用过，但不构成对代码质量的判断。
跑起来只需要三个参数，但模型后端要自己接
安装和最小运行路径在 README 里很短。pip install -U aideml 装包，然后设置一个 LLM 的密钥，示例给的是 export OPENAI_API_KEY=<your-key>。接着一条命令就能启动优化：
aide data_dir="example_tasks/house_prices" goal="Predict the sales price for each house" eval="RMSE between log-prices"
跑完之后产物落在两个位置：logs/<id>/best_solution.py 是找到的最优代码，logs/<id>/tree_plot.html 是可视化出来的解树。这个约定很清楚，best_solution.py 是一个可以直接读、直接改的普通 Python 文件，不是需要反序列化的中间格式。
想换模型或加长搜索，改的是配置键而不是命令行开关。README 给的例子是 aide agent.code.model="claude-4-sonnet" agent.steps=50 data_dir=... goal=... eval=...。这里 agent.code.model 的默认值是 gpt-4-turbo，agent.steps 默认 20，agent.search.num_drafts 默认 5。README 说这套管线是 model-neutral 的，支持 OpenAI、Anthropic、Gemini，以及任何讲 OpenAI API 的本地模型。这一点对成本敏感的实验很关键，因为搜索的每一步都要调用模型，模型单价直接乘在步数上。
如果不想用命令行，仓库里带了 Streamlit 界面。用法是从 GitHub 克隆仓库，pip install -e . 安装（这一步会把 streamlit 一并装上），然后 cd aide/webui 再 streamlit run app.py。界面侧边栏可以粘贴 API key、上传数据、填写 Goal 和 Metric，点 Run AIDE 开始。界面会显示实时日志、解树和最优代码。注意这条路径需要本地克隆，pip 安装的包本身不带这个界面。
在 Python 里调用则是 aide.Experiment 对象：传入 data_dir、goal、eval 三个参数，然后 exp.run(steps=2) 返回 best_solution，可以读它的 valid_metric 和 code 字段。README 的示例还配置了 logging，把 aide 这个 logger 的级别设成 INFO。这段示例代码在 README 里是被截断的，最后一行只剩 ma，实际使用时需要自己补完入口判断。
它不适合当作生产流水线来用
最明显的限制来自仓库自己的定位。README 在顶部就放了一句指向 Weco 产品的链接，措辞是「Use in Production? Try Weco」，并在分层表里说明 Weco 产品把 AIDE 的能力推广到更广的代码优化场景，提供实验追踪和更强的用户控制。换句话说，实验追踪和用户控制这两件事在这个开源仓库里是缺位的，它们被划到了商业产品那一侧。如果你需要审计每次运行、回滚某个版本、或者让非工程角色参与评审，这个仓库不提供这些。
第二个限制是接口的窄度。任务的输入被压缩成 data_dir、goal、eval 三个参数，这要求你能用一句话把评估标准说清楚。像 RMSE、AUROC、RMSLE 这种单一数值指标很合适，但涉及多目标权衡、业务约束、或者需要人工判断的输出质量时，这个接口就没有表达空间了。README 里出现的所有示例都是这种单指标形式，没有给出多目标或约束优化的用法。
第三个限制是成本和不确定性。搜索的每一步都要调用 LLM，默认 agent.steps=20 加上每步 agent.search.num_drafts=5，意味着模型调用次数本身就是几十量级起步，而且每次生成的代码都要实际执行才能拿到指标。仓库没有给出成本估算，也没有给出失败重试策略的说明。默认模型是 gpt-4-turbo，这个默认值是否还是当下合理的选择，需要你自己判断。
还有一个更朴素的问题：这个仓库的定位是参考实现，README 用的是 lean implementation 这个说法。参考实现通常优先保证机制清晰、便于改动，而不是边界情况的健壮性。把它直接接到持续集成里，风险要自己评估。
树搜索和线性 agent 的差别在哪里
最直接的对照对象是线性 agent，README 里点名的就是 OpenHands。两者的差别不在于用不用 LLM，而在于如何组织历史。
线性 agent 维护一条轨迹：上一步的代码和输出进入下一步的上下文，模型在这个不断变长的对话里继续改。它的优点是上下文连贯，模型能看到完整的推理链条；缺点是早期的一个错误决策会一直留在上下文里，而且一旦某一步把代码改坏，回退的代价是重新构造整个对话。
AIDE 的做法是把每个候选脚本存成树上的独立节点，节点之间通过补丁派生关系连接，而不是通过对话历史连接。指标反馈决定哪些分支继续扩展、哪些被剪掉。这样做的好处是并行探索多个方向，坏处是每一步的上下文相对局部，模型看不到其他分支上发生了什么，跨分支的经验不会自动共享。README 里 MLE-bench 的 4 倍奖牌数结论，正是针对这种结构差异的，而不是针对某个模型的能力差异。
这个对比也解释了为什么仓库要把可视化做成一个功能。树结构如果不画出来，很难判断搜索到底在做什么，而线性轨迹读日志就够了。tree_plot.html 在这里不是装饰，是理解搜索行为的必要工具。
维护成本、版本节奏和 MIT 许可的含义
从发布记录看，这个仓库的节奏不快。v0.1.4 在 2024 年 4 月，v0.2.0 在 2025 年 1 月，v0.2.2 在 2025 年 11 月，主分支最后一次推送是 2026 年 9 月。版本号停留在 0.x，意味着 API 层面还没有进入稳定承诺期，升级时值得先看 release notes 里有没有配置键的改动。README 里出现的 agent.code.model、agent.steps、agent.search.num_drafts 都是点分层的配置键，这类键在 0.x 阶段发生重命名是常见情况。
依赖方面，仓库要求 Python 3.10 及以上，这一点在 README 的徽章里写明。Web UI 依赖 Streamlit，但只在 pip install -e . 这条路径上安装，普通 pip install -U aideml 不会带上它。如果你打算长期用，把这两条安装路径分开管理会省事一些。
许可方面，仓库采用 MIT License。这是一个宽松许可，通常允许修改、再分发和商业使用，具体义务以仓库里的 LICENSE 文件原文为准，这里不构成法律意见。需要留意的是许可覆盖的是这个仓库的代码，不覆盖 LLM 提供方的服务条款，也不覆盖你喂进去的数据集。README 里出现的 example_tasks/house_prices 和 example_tasks/bitcoin_price 是仓库自带的示例目录，用它们做实验前值得确认一下数据来源和再分发条件。
上手前先用示例任务量一遍
这个仓库自带示例任务，这是最省事的验证路径。用 example_tasks/house_prices 配 goal="Predict the sales price for each house" 和 eval="RMSE between log-prices"，或者用 example_tasks/bitcoin_price 配 goal="Build a time series forecasting model for bitcoin close price." 和 eval="RMSLE"，先把 agent.steps 设成 2 跑一遍。Python 接口里的 exp.run(steps=2) 就是这个用法。
两三次运行之后你会拿到三样东西：best_solution.py 里的代码质量、tree_plot.html 里的搜索形态、以及账单上的模型调用量。这三样分别对应你能不能接受它的输出、能不能看懂它的决策、以及愿不愿意为更多步数付费。
真正需要提前想清楚的是 eval 这个字段。它决定了整棵树的剪枝方向，写错或写含糊，搜索会朝着一个错误的目标收敛，而且从 best_solution.py 里不一定看得出来。README 给出的所有示例都是单值指标，如果你的任务没有这样的指标，这个工具大概率不是合适的选择。
编辑结论
如果你在做 agent 架构研究，想替换搜索启发式、评估器或 LLM 后端，或者需要复现论文里的结果，AIDE ML 的定位正好对得上：pip install -U aideml 之后用 aide data_dir=... goal=... eval=... 就能跑起来，日志里会留下 best_solution.py 和 tree_plot.html。如果你的目标是稳定交付生产级流水线，这个仓库并不合适，README 自己把生产场景指向了 Weco 平台，而且它默认的 agent.code.model 是 gpt-4-turbo，跑一次的开销取决于 agent.steps 和 agent.search.num_drafts 的乘积。上手前先确认两件事：你要的指标能否用一句话描述清楚并交给 eval 参数，以及你打算用哪个模型后端，因为换模型只需要改 agent.code.model 这一个键，但结果差异需要你自己在 example_tasks 上先量一遍。
社区笔记