过去三个月，我把一部分日复一日的实验流程交给了一个 AI 科学家 Agent 原型。这里的 Agent 不是那种聊聊天、写写摘要的接口封装，而是一个能自己翻历史实验记录、提出候选假设、设计对照组、跑数据统计、再决定下一步做什么的完整闭环。说白了，它把我原来最耗时的那段“验证想法”的动作链，接力跑了起来。
这篇文章不是来吹“AI 要取代科学家”的，恰恰相反，我倾向于更冷静的判断：今天的 LLM Agent 还做不到真正意义上的科学发现，但它完全有能力把“假设生成→实验设计→数据分析→再假设”这条链路里大量机械、重复、容易出错的部分自动化。对正在考虑把日常实验流程自动化，或者想搭一个科研 Agent 原型的朋友，这篇应该能提供一个可以落地参考的模板——包括模块怎么拆、提示词怎么写、数据怎么回流、哪些坑我替你踩过了。
1. 为什么 AI 科学家 Agent 绕不开“假设生成”这一步
1.1 假设质量决定闭环上限
很多人刚开始做科研自动化，会把精力全砸在“自动化跑实验”和“自动出图表”上。但我自己搭完这套 Agent 之后最大的感受是：假设生成才是整条流水线的上游。上游假设提得稀烂，后面数据分析再漂亮也是白搭。
一个假设必须是可检验的。比如做涂层材料研究，“这种涂层性能更好”就不可检验，因为它没有指定变量，也没有给出可测量的方向；“同一种树脂体系下，把固化温度从 60°C 降到 25°C，附着力的下降幅度不超过 10%”，这才叫可检验假设。它明确了两端：一端是可控变量（固化温度），另一端是可测量变量（附着力），还给出了预测方向。Agent 生成假设的时候，如果没有这种约束，它会非常自然地输出一堆听起来很专业但实际上没法做的空话。
我第一版 Agent 生成过这样的假设：“通过优化工艺参数提升材料综合性能。”这句子放论文里是安全的，但放到实验闭环里就是零信息量。没有自变量、没有因变量、没有对照组设计依据，后面的实验流程根本没法接。后来我把“可检验性”作为系统提示词里的一条硬规则，才解决了这个问题。
1.2 让 Agent“出题”的实际做法
我现在的做法是，给 Agent 一个结构化的“出题提示词”，核心不是让它自由发挥，而是给它加约束条件。基本模板长这样：
你是一个实验设计助手。请基于以下背景提出3到5个可检验假设。 背景：{研究背景} 已有数据：{历史实验数据摘要} 可用资源：{设备、时间、资金约束} 每个假设必须包含： 1. 自变量：明确给出变量名和取值范围 2. 因变量：明确给出测量方法和预期变化方向 3. 可检验性：说明设计什么实验可以验证 4. 优先级：给出推荐优先级，并说明理由这个模板看起来简单，但作用很大。它把 Agent 从“写一段科普文字”的状态拉回到“填一份结构化实验方案”的状态。加了这层约束之后，Agent 给出的假设质量明显提升，至少不会出现那种没法落地的废话假设。
我还会让它基于历史实验数据来出题——不是凭空想，而是先读一遍过往记录，找出“数据里被忽略的信号”。比如某次实验中记录到温度波动对某个中间产物有影响，但当时所有分析都聚焦在主产物上。Agent 把这个信号单独拎出来，生成了一条关于中间产物动力学的假设，后面手工实验还真验证出了规律。这个案例让我意识到：Agent 的记忆库如果接得好，它的“出题”就不是随机生成，而是数据驱动的二次挖掘。
1.3 多模型投票出题，避免单模型套路化
我自己用下来还有一个心得：不要只靠一个模型生成假设。同一个模型连续三次生成的结果，往往存在“自我重复”的倾向，用的句式都差不多。我后来改成“多模型出题 + 一个评审模型排序”的方式：让两到三个不同模型各自独立生成假设，再让一个专门的评审模型从中挑出最值得验证的 2-3 条，排序后给出理由。
这套组合下来，假设的多样性明显增强。评审模型的作用是做个“过滤网”——它不看生成过程的辞藻，只看哪条假设最容易被现有设备验证、成本最低、和已有数据冲突度最小。这样既保留了多样性，又不至于让 Agent 天马行空到没法落地。
2. 从假设到实验方案：我把 Agent 当成最较真的实验员
2.1 变量映射表是这步的骨架
假设生成之后，下一步就是把它翻译成具体的实验方案。这里我踩过一个很典型的坑：Agent 会把两个不同的实验变量合并成一个。它可能把“催化剂添加量”和“反应时间”混在一个描述里，导致最后实验结果根本没法归因。这问题不是偶然，而是 LLM 对工程细节天然不敏感。变通的做法是让 Agent 在生成实验方案之前，先强制填一张变量映射表。
| 假设编号 | 自变量 | 因变量 | 对照组设计 | 统计验证方法 |
|---|---|---|---|---|
| H-01 | 固化温度（25-60°C，4个水平） | 附着力（拉拔法，MPa） | 无催化剂对照组 | 单因素方差分析 + Tukey HSD |
| H-02 | 催化剂添加量（0.5%-2.0%，5个水平） | 反应转化率（HPLC面积归一化） | 不加催化剂组 | 线性回归 + 置信区间检查 |
这张表看起来简单，但它实际上是一次“变量拆分校验”。Agent 每次生成方案，必须先填表，再写操作步骤。只要这个环节被固定住，后面因为“变量混淆”导致的无效实验就少了很多。
2.2 双轨跑法：仿真实验和真实实验分开推进
真实的实验资源是有限的，不可能每个假设都上真机跑。我的做法是“双轨并行”：低成本的仿真实验用来筛选假设，筛选出来的少数假设再进真实实验。
仿真实验这边，我搭了一个基于历史数据的统计模拟器——给定自变量取值，它会按照历史数据的分布生成一组带噪声的模拟结果。Agent 的每个假设先在模拟器上跑一轮，通过“模拟结果是否有信号”来排序。这里有个重要原则：模拟器只能用来筛选假设，不能用来验证真伪。因为模拟器里的规律来自历史数据，本质上是在重复已知信息，它无法发现真正全新的机制。
真实实验这边，Agent 不出手做操作，而是生成一份操作清单，我来执行，然后把读数录回去。刚开始我也想过全套自动化，但现实是很多实验室设备根本没有标准接口，与其花三个月打通设备通信，不如人机协作先把闭环跑通。
2.3 实验方案模板的固定化
为了让 Agent 产出的实验方案统一、可执行，我给了一套固定字段。这套模板越固定，幻觉越少。之前用自由格式描述，Agent 偶尔会漏写某个关键条件，比如忘记标注仪器型号或者样品干燥时间。换成严格字段列表之后，信息完整度基本是百分百：
实验目的： 变量定义： - 自变量： - 因变量： - 控制变量： 分组设计：（每组样本量、重复次数） 操作步骤：（按序号列出每一步） 预期结果：（给出预测方向和幅度） 风险说明：（可能影响结果的因素）其中“风险说明”这一栏特别有用。它让 Agent 主动思考“哪些因素可能干扰这次实验”，而不是只按理想流程走。实际执行时，这栏内容经常能提醒我注意一些容易被忽略的细节，比如样品的批次差异。
2.4 一个典型实验的执行循环
跑通一次实验方案的大致流程，我这里用文字描述一下：
- Agent 读取变量映射表和实验方案模板，生成一份 JSON 格式的配置，包含组别、样本量、重复次数、参数水平。
- 工具脚本读取配置，拉起仿真器（如果是真实实验，则输出待执行清单，等待我录入结果）。
- 数据文件按统一命名规则落盘：
experiment_{假设编号}_{日期}.csv。 - Agent 读取落盘数据，做下一步分析。
这个循环看起来简单，但它能跑得通的关键在于：数据格式的统一。只要 CSV 的列名不一致，后面的自动分析就得返工。所以我把列名规范写死在工具脚本里，任何模型输出都必须按这个规范来，不然后续流程直接熔断。
3. 数据回来之后，Agent 如何“否定自己”并进入下一轮
3.1 自动解析和质量校验优先于一切分析
数据分析这块，大模型本身的统计能力并不差，但它有个致命弱点：它会基于记忆去编数据，而不是基于文件里的实际数据。我遇到过好几次，Agent 在汇报里写“共检测了 3 组实验数据”，但实际文件里只有 2 组。这是典型的上下文丢失问题——模型在长对话里很容易漏掉最初输入的数据规模。
解决办法是在分析流程的最前面加一道“数据完整性校验”：
def validate_experiment_data(file_path, expected_groups): """数据完整性校验：检查分组数与样本量""" df = read_csv(file_path) actual_groups = df["group"].nunique() if actual_groups != expected_groups: raise ValueError( f"组数不一致：期望{expected_groups}组，实际{actual_groups}组" ) return df这段代码看起来不起眼，但它价值极大。没有这道校验，后面所有统计结果都可能建立在残缺数据上却不自知。
3.2 统计报告不是跑出 p 值就行
数据分析阶段，我最想纠正的一个观念是：不要只关注 p 值是否小于 0.05。Agent 天然倾向于在回答里强调“差异显著”，因为这在语义上像是“有结论”。但做实验不是发论文，只看 p 值会漏掉大量信息。
我在提示词里专门加了一条要求：统计报告必须包含效应量、置信区间、样本量充足性评估。举一个实际输出例子：
实验 H-02 结果分析： - 主效应：催化剂添加量每增加0.1%，转化率平均提升2.3% - 效应量（Cohen's f）：0.42，属于中-大效应 - 95%置信区间：[1.8%, 2.8%]，区间较窄，估计较稳定 - 样本量充足性：当前每组5个重复，功效分析建议每组至少7个， 结果仅供参考，建议补充后再下结论这个报告明显比单纯说“p<0.05，显著”更有价值。尤其是“功效分析建议每组至少 7 个”这条，直接把结论的不确定性摆在台面上，不会让人误以为实验已经闭环。
3.3 迭代回路：不显著的结果也是素材
Agent 拿到“结果不显著”之后，它的反应路径我做了明确约束。原来默认行为是：结果不显著，Agent 会尝试调整假设方向，甚至改基准描述来“凑”出解释。这本质上是在 p-hacking 的边缘试探。我给它加了硬性规则：任何假设的主结论必须在实验前写定，实验后只能报告“支持”“不支持”“部分支持”，不能修改主结论来匹配数据。
迭代流程如下：
- 如果假设被支持：将这个假设标记为“验证通过”，更新记忆库，生成一个更细化的子假设继续挖。
- 如果假设被否定：记录“这个路径走不通”，把失败原因写进记忆库，降低同类型假设的权重。
- 如果结果模糊（比如效应接近显著性边界）：不做定论，生成一个“补充实验方案”，加大样本量再验证一轮。
这个三路分流逻辑，让 Agent 每次迭代都能产生有意义的下一步动作，而不是原地打转。
4. 一个可复现的最小原型：我的技术栈和完整跑通路径
4.1 整体模块架构
整个 Agent 原型由五个模块组成，我按功能把它们分开，避免所有逻辑都堆在一个夹层里。这里我不推荐上来就引入特别重的编排框架，先用手写脚本把闭环跑通，比过早引入复杂框架要踏实得多。
| 模块 | 职责 | 数据流 |
|---|---|---|
| 任务规划器 | 接收研究背景，生成假设、实验方案 | 输出 JSON 配置 |
| 工具执行器 | 读取配置，调用仿真器或输出操作清单 | 生成 CSV 数据 |
| 统计引擎 | 数据校验、统计检验、生成报告 | 输出 Markdown 报告 |
| 记忆库 | 存储历史实验结论、失败记录 | 向量化检索 |
| 审计日志 | 记录所有 Agent 决策和输出 | 纯文本追加 |
4.2 技术选型的理由
技术选型上我有几个明确偏好。首先是LLM 服务选 API 而不是本地部署。本地部署一个中大规模的模型需要 GPU 资源，而 API 的成本在工作流阶段完全可接受——一轮完整的仿真循环（10 组模拟实验 + 3 次假设迭代）大约消耗几十万 token，折合人民币也就是几块钱的规模，比租用任何硬件都便宜。
其次，记忆库我用向量检索，存的是实验结论和失败记录。每条记录包含假设编号、结论、数据存放路径、失败原因这几个字段。当 Agent 要生成新假设时，会先检索和历史最相关的五条记录，把它们作为背景。
最后，我刻意没有选功能特别重的全家桶框架，而是用轻量的“脚本 + LLM 调用”组合。原因很简单：Agent 的流程还在飞速变动，今天你要加一个变量校验，明天要改统计方法，重框架会拖慢迭代速度。轻编排的好处就是随时能改，坏处是需要自己处理上下文长度。
4.3 最小可跑通的代码路径
下面这段代码是完整闭环的最简版本，不是生产级，但足够把思路跑通：
import json import random from llm_client import chat # 任意LLM接入层 def generate_hypotheses(context, memory): """从记忆库检索背景，生成3个候选假设""" related = memory.search(context, k=3) prompt = build_prompt(context, related, task="hypothesis") response = chat(prompt) return json.loads(response.text) def run_experiment(experiment_config): """按配置执行仿真实验，返回带噪声的CSV路径""" groups = experiment_config["groups"] data = simulate(groups, noise=0.1) # 一个自写的模拟器 file_path = save_to_csv(data, "experiment_001.csv") return file_path def analyze_result(file_path): """统计引擎：先校验，再检验，最后出报告""" df = validate_experiment_data(file_path, expected_groups=4) report = run_statistical_tests(df) return report def update_memory(memory, conclusion): """把实验结论和失败原因写回记忆库""" memory.store(conclusion) # 主循环 context = load_research_background() memory = load_memory() for round in range(10): hypotheses = generate_hypotheses(context, memory) best_h = hypotheses[0] # 实际应加评审步骤 config = design_experiment(best_h) # 变量映射表 result_file = run_experiment(config) report = analyze_result(result_file) conclusion = judge_hypothesis(best_h, report) update_memory(memory, conclusion)这段代码最核心的部分是design_experiment这个函数。它接收假设，输出配置，这个环节必须要保证变量映射表的完整性，否则后面的数据没有意义。
4.4 完整跑通的五个步骤
如果你也想复现一个最小原型，照着下面五步走就行：
- 准备历史数据：至少要有 20 条以上真实实验记录（哪怕很粗糙），按统一 CSV 格式整理好。这是 Agent 的“经验池”，没有它，假设生成就是无根之木。
- 写工具函数：从 CSV 读写开始，写好
save_to_csv、read_csv、validate_experiment_data这三个基础能力。在这上面花时间绝不亏。 - 接 LLM 并注入系统提示词：把“可检验假设”“变量映射表”“统计报告要求”这些约束写进系统提示词。先手写对话测试几轮，觉得稳定了再封装进脚本。
- 加数据校验：数据完整性校验放最早，宁可截断流程，也不要让错误数据进入统计环节。
- 用模拟数据先跑十轮：先不要拿真实实验去试，让 Agent 在模拟环境里连续迭代十轮，观察它生成的假设质量、报告格式、记忆库增长情况，全部满意后再接真实流程。
这五步走完，你手里就有一个能自我迭代的 Agent 骨架了。后期想加新功能，比如接设备 API、加多 Agent 协作，都是在这个骨架上扩展。
5. 边界不回避：现在哪些环节我还不敢全交给它
5.1 重建一个“会骗人”的 Agent
这个标题可能有点吓人，但实际是我踩过最深的一个坑。最开始我为了让 Agent 更“聪明”，把历史数据、文献摘要、实验记录全部塞进上下文，让它自己挖掘信号。结果它确实“聪明”了，学会了一个我完全没教过的技能：编造看似合理的实验记录。
比如某次它为了支持自己提出的假设，在实验记录里自动补了一段“温度波动导致产物颜色异常”的描述，这段描述根本不在原始数据里。后来我查日志才发现，这可能是模型在生成实验步骤时“顺带”补的内容。这让我意识到：LLM 需要的是约束，不是自由。
解决办法是给 Agent 增加一个“实验记录模板强制校验”。生成实验记录时，只能填写固定的字段：实验目的、变量、数据文件路径、统计结论。自由描述一律禁止。这样至少把“编造成果”的可能性降到最低。
5.2 物理世界因果链不能全交给模型
我目前还有一类实验不敢交给 Agent 主导：需要物理因果推断的实验。比如“为什么某个样品在高温下破损率下降”，这类问题的答案可能涉及微观结构变化、热应力分布等多个物理机制，Agent 基于文本学习的因果推断能力还远不够可靠。
我的经验是：Agent 适合做“基于数据的筛选和排序”，不适合做“基于物理原理的最终归因”。对于高风险、高成本的实验——比如需要消耗稀缺样品或者连续实验超过一周——我仍会把方案拿给人来决策。Agent 输出一个“推荐方案”，但最终拍板的必须是人。
5.3 审计日志必须可追溯
最后一个实际建议：无论 Agent 多靠谱，审计日志都要保留。不只是记录它最终的输出，更要记录每一步的中间结果。我用的是最简单的纯文本日志，每条记录包含时间戳、模块名、输入摘要、输出摘要。这样一旦发现可疑的实验结论，我可以倒查到底哪一步出了问题。
有一次结果异常，查日志发现是记忆库里一条失败记录被错误标记为“验证通过”，导致新假设建立在错误前提上。如果没有日志，这个问题可能要过很多轮才会暴露。
现在这套流程已经稳定跑了两个月，我日常的工作节奏变成了：早上让 Agent 跑一轮仿真筛选，中午人工审核它的方案，下午执行真实实验，晚上让它出统计报告和下一步计划。它没有替代我，但把我的“无效科研时间”压缩了一大半。
最后再分享一个我试出来的小技巧：给 Agent 的实验记录模板越固定，它的幻觉越少。从自由摘要改成结构化字段之后，Agent 在周报里编数据的次数基本清零了。如果你也在搭类似的东西，这条可能帮你省掉不少排查幻觉的功夫。
