论文实验自动化

Curie: Toward Rigorous and Automated Scientific Experimentation with AI Agents

Curie:给自动实验 agent 装上『严谨性引擎』

Patrick Tser Jern Kon, Jiachen Liu, et al. (University of Michigan) · University of Michigan · arXiv · 2025-02 · 被引 34

一句话密歇根大学做的自动实验 agent 框架:不追求端到端写论文,专攻『实验环节的严谨性』——用拦截式的 rigor 模块强制可控变量、可复现和结构化记录。在自建的 46 题实验 benchmark 上,结论正确率 36.1%,是最强 baseline OpenHands(10.5%)的 3.4 倍。

这是什么

AI Scientist 类端到端系统(AI Scientist、Agent Laboratory 等)普遍有个软肋:实验环节不可靠——代码带 placeholder、变量没控制、跑一次就下结论、结果无法复现。Curie 的切入点就是这一环:它不做 idea 生成和论文写作,只把『从实验问题到可信结论』这一段做扎实。输入是一个实验问题(如『生成样本数如何影响 GSM8K 上的回答质量?』)加上 starter code,输出是实验设计、可复现的实验脚本、实验数据和结论。

系统由一个 Architect agent(设计和迭代实验计划)和一组 Technician agents(写代码、跑实验)组成,但核心创新不在 agent 本身,而在夹在中间的 Experimental Rigor Engine:所有 agent 动作都会被拦截、校验后才放行,类似给多 agent 工作流加了一层强制的流程控制和过程监督。

为了评估,作者自建了一个 46 题的实验 benchmark,覆盖 LLM reasoning(16 题)、向量检索/Faiss(15 题)、云计算/AWS(8 题)、ML training(7 题)四个 CS 领域,题目从真实论文(如 Large Language Monkeys)和开源项目的可检验结论中提炼,难度按 design/setup/relationship/goal 四个复杂度维度分级。2025-02 挂 arXiv,S2 引用 34;同组后续工作 EXP-Bench(2025-06)是这条线的延伸。

Curie 总览:左边输入实验问题和 starter code,中间是 Architect + Technicians 加三个 rigor 组件(Intra-ARM、Inter-ARM、Knowledge Manager),右边是产出链:实验设计 → 实验脚本 → 实验数据 → 结论。看这张图能明白它的定位是『问题进、可信结论出』,不含 idea 生成和写论文。

机制与做法

Intra-ARM:步步校验,不等实验跑完才发现坏了

Intra-Agent Rigor Module 借鉴 process supervision 的思路,在每个实验阶段插入模块化 validator,而不是等端到端跑完再验收。Setup Validator 在执行前静态检查实验代码:是否覆盖了计划中的自变量/因变量/控制变量,有没有 placeholder、硬编码值或没用上的变量,输入输出参数是否正确。Execution Validator 在干净环境里重复执行 setup,检查无报错、多次运行结果一致(可复现性),结果文件符合计划要求。Validator 是可扩展的,可以按领域加新的。

核心机制图:Architect(左)出实验计划,Inter-ARM(中上)把计划切成 partition 并用控制流强制状态转移,Intra-ARM(中)的一排 validator 在每次 agent 交接时拦截校验,Technician(右)只有过了校验才能执行;底部 Knowledge Module 用结构化读写记录全程。A/B/C 三步(拦截→校验→放行)是理解整个系统的关键。

Inter-ARM:计划分片 + 状态机式流程控制

Inter-Agent Rigor Module 负责『methodical control』:先把 Architect 的实验计划按自变量取值切成独立 partition(天然支持并行和细粒度追踪),然后用显式的控制流策略管理每个 partition 的状态转移——比如 Technician 写好的 setup 必须先过 Setup Validator 才能执行,新产生的结果必须先过校验才能回传 Architect,实验不允许在还有未完成 partition 时终止。调度器根据 Architect 设的优先级、允许的状态转移和 agent 空闲情况分派任务。这本质上是把 agent 间的自由对话换成了一个带验证关卡的工作流状态机。

Experiment Knowledge Module:结构化记录 + 分级写权限

作者认为不能把实验记录交给 LLM 的上下文管理(读会遗忘/幻觉,写会污染记录),所以所有实验计划和进展都存成带元数据的结构化格式,修改历史用 DAG 式的 'time machine' 记录——测过哪些假设、改过哪些变量、决策理由,可以回溯重建。写入采用 tiered write access:Technician 只能往自己负责的 partition 追加结果,Architect 权限更大但也只能改特定字段,每次写入先做结构和语义校验(如结果文件路径必须有效)再落库。

评估设置

对比对象是 OpenHands(编码 agent)和 Microsoft Magentic-One(通用多 agent),三者底座都是 GPT-4o,每题独立跑 5 次取平均。四个二值指标:实验设计正确、setup 可执行且可复现、实现与计划对齐、结论正确。design/setup/conclusion 用 LLM judge 对照 ground truth 判,implementation alignment 由人工评(作者自己评,辅以 LLM judge 交叉核对)。

关键结果

结论正确率(加权平均):Curie 36.1% vs OpenHands 10.5% vs Magentic-One 2.3%,即摘要里 3.4x 的来源;但注意绝对值——即便是 Curie,三分之二的实验问题最后结论仍是错的。
Execution setup(可执行 + 可复现):Curie 78.1% vs OpenHands 32.4% vs Magentic 6.8%,是 rigor 模块收益最明显的指标;各领域从 66.7%(ML training)到 92.7%(cloud)。
实验设计正确率大家都高(Curie 97.9%,OpenHands 83.6%,Magentic 82.9%)——说明这批题的设计环节本身不难,区分度主要在执行和结论。
分领域看:cloud computing 这类长时间运行的实验 Curie 优势最大(结论正确率 6.5x于 OpenHands);ML training 因环境配置说明不全,所有 agent 的 alignment 和 execution 都差,但 Curie 靠反思重试仍拿到 7.3x 的结论正确率。
随四个复杂度维度难度上升,所有 agent 性能都下降,但降幅是亚线性的——作者自己承认最难的题还不够难。

实证核查

扎实代码、46 题 benchmark、评估脚本都真实开源且与论文对得上,3.4x 是照实从自家表格算的;但要注意评估有自评成分、baseline 偏软、绝对成功率不高,且没查到第三方复现主结果。

论文称设计了 46 题四领域实验 benchmark 并将开源。

已核对仓库:benchmark/simple_curie_bench/ 下 cloud_infra 8、llm_reasoning 6+10、ml_training 7、vector_index 18 个 .txt 题目文件(含少量说明文件,与论文表格 16/15/8/7 的分布吻合),evaluation/ 下有 llm_judge.py、judge_herd.py 等评估脚本。声称属实。

『3.4x improvement in correctly answering experimental questions』。

论文 Table 1 显示结论正确率 36.1% vs 10.5%,3.4x 计算无误;但三点折扣要心里有数:(1) 两个 baseline(OpenHands、Magentic-One)都不是为实验任务设计的,只靠 system prompt 客串『实验员』;(2) implementation alignment 由作者人工评,其余靠 GPT-4o judge;(3) 每题 5 次试验但论文未报方差。没有搜到第三方复现该主结果的报告。

README 称『ensuring every step is conducted with precision, reliability, and reproducibility』,pip install curie-ai 即可用。

工程上没那么顺:open issues 里有 #100(硬编码 /allworkspace/ 路径导致 FileNotFoundError)、#109(Windows 下 Docker 路径处理失败)、#110(LLM 返回空 choices 时崩溃)、#105(内存管理问题)。仓库维护到 2025-09-28 后趋于停滞,371 stars。可以跑,但强依赖 Docker + Linux,别指望开箱即严谨。

框架强调可复现性(Execution Validator 多次重跑检查一致性)。

这个机制在 benchmark 指标上确有体现(setup 可复现率 78.1% vs baseline 32.4%,论文 Table 1),且 rigor 模块的设计(validator、分级写权限)在 curie/ 源码目录结构中可对应;但『可复现』的判定标准是自家 validator 定义的多次运行输出一致,不等于科学意义上的独立复现。

与我们方向的关系

对做 AI Scientist / 实验自动化方向的同学,Curie 的价值不在指标,而在架构思路:它论证了『把 rigor 做成 agent 外部的强制机制』比『指望 prompt 让 LLM 自觉严谨』有效——setup 可执行率从 32% 提到 78% 基本全是拦截式 validator 和状态机控制流的功劳。这套『计划分片 + 状态机 + 过程校验 + 分级写权限』的设计可以直接搬到任何多 agent 实验/评测流水线里,不限于科研场景。

另外它的 benchmark 构造方法值得借鉴:从已发表论文的可检验结论反推实验问题、按四个复杂度维度分级,这比『让 LLM 写论文然后 LLM 打分』的评估范式扎实得多。想跟进这条线可以直接看同组的 EXP-Bench(arXiv 2505.24785),把这个思路扩成了从真实 AI 论文提取的更大规模实验任务集。

阅读笔记

读 tex 源码时注意 exp.tex 里保留了大量作者的草稿注释(\if 0 块),能看到不少表格数字背后的坦白话,比如『我们最难的题还不够难』『ML training 的 starter code 不完整』。跑代码需要 Docker,官方明确说别在 Jupyter 里跑;2025-05 后仓库重心转向 AutoML 功能和 EXP-Bench,论文对应的原始 benchmark 在 benchmark/simple_curie_bench/(README 里写的 experimentation_bench 路径已过时)。