AI Agent写科研实验记录：完整方法论与操作流程

在科研工作中，实验记录往往是最容易被忽视却又最关键的一环。本文基于B站UP主「AI加速科研全流程」系列课程的第0章第4节内容，系统梳理如何借助AI Agent建立一份贯穿项目始终的科研日志（Research Log），让实验记录真正成为科研反思与决策的有力工具。

为什么需要一份统一的Research Log

科研项目中的信息通常分为三类：实验记录、科研想法、方法与代码的改动。如果把这三类信息拆分成三份文档分别管理，会带来两个明显的问题。第一是容易造成信息遗忘和割裂，实验、想法与代码改动本应相互关联，分开记录反而破坏了这种上下文；第二是当使用AI Agent处理时，分三份文档会导致token消耗过大，效率低下。

这里所说的token是大语言模型处理文本的基本计量单位，一个中文字大约对应1.5-2个token，一个英文单词约对应1-1.5个token。当前主流大模型如GPT-4o、Claude 3.5等虽然拥有128K甚至更大的上下文窗口，但token消耗直接关系到API调用成本和推理速度。将三份文档分别喂给AI意味着每次交互都需要重复加载背景信息，造成冗余消耗。而合并到一份文档中，AI只需一次性加载完整上下文即可进行分析推理，在长期项目中可以节省数倍的API费用。

更好的做法是将三类信息合并到一份Markdown文档中，保持在正常的上下文长度范围内。Markdown是一种轻量级标记语言，使用纯文本格式编写，通过简单的符号（如#表示标题、-表示列表、**表示加粗）即可生成结构化文档。它特别适合科研记录的原因在于：纯文本格式天然兼容Git等版本控制系统，每次改动都可追溯；几乎所有AI模型都能完美解析Markdown结构，便于Agent理解文档层级；文件可以在任何文本编辑器中打开，不依赖特定软件，确保了长期可读性。

这样做的核心价值在于：当你需要让AI反思实验问题时，它能获得完整的上下文。基于连贯的历史记录，AI可以对比每天的实验结果，帮你分析实验中的问题，甚至为你设计未来的实验计划和每日流程。

这份文档本质上是一份「科研日记」，从项目启动持续到项目收尾，记录整个研究过程的完整信息流。

实验记录的骨架结构

一份完整的实验记录应当包含清晰的层级结构：

项目起点：明确研究定位

文档开头需要明确项目的整体定位，包括当前研究问题、研究范围以及要实现的目标。这部分是整个Research Log的锚点，为后续所有实验提供背景参照。

按日期组织的每日记录

每一天的记录按日期展开，内部包含一个或多个实验。每日记录遵循固定框架：

• 今日目标与计划：早上开始实验前先制定今天的目标
• 实验执行与改动：一天中通常进行多次实验，依次追加 experiment001、experiment002 等
• 收尾总结：晚上或下班时进行当天的收尾

项目收尾：整体复盘

当所有实验完成后，进行整个项目的收尾总结。这里有一个重要原则：如果某些部分信息缺失，就留空，绝不让AI自行编造填补。

项目推进中的操作流程

以一个典型的实验日为例，可以清晰看到Research Log的推进逻辑。假设早上九点开始实验，先在文档中写下今天的计划，然后进行第一次实验 experiment001 并检查输出是否异常。

如果在下午发现了异常，正确的做法是新增 experiment002 并引用 experiment001，而不是删除或覆盖 experiment001。这是整套方法论中反复强调的核心原则——失败的实验记录同样具有价值。到了晚上，进行当天的解释与总结，说明新证据为何改变了判断，并给出明天要做的内容。

每日收尾总结的四个部分

每天结束前，将当天总结拆分为四个明确的区块：

1. 发生了什么：今天的实验实际发生了什么，做到了什么
2. 解释：对结果做出解释（这部分需要研究者亲自核对）
3. 问题与修正：今天实验存在什么问题，哪些地方需要修正
4. 下一步：明天该做什么、需要达到什么条件、从哪里开始

这四个区块合并成一天记录的收尾部分，一天的记录就算完成了。

实验前的结构化思考规范

在动手做实验之前，一套结构化的思考逻辑能大幅提升实验质量。做实验前应当先问自己几个关键问题：

• 这个实验要回答什么问题？
• 控制变量：本次实验改变什么条件，其他条件是否保持不变？
• 成功标准：期望得到什么样的实验结果，怎样才算得到答案？
• 失败处理：实验失败了会怎么样，要不要停止？

这里的「控制变量」遵循的是实验科学中最基础的控制变量法（Controlled Variable Method）。其核心思想是在一次实验中只改变一个变量（自变量），同时保持其他所有条件不变，从而确定该变量与实验结果之间的因果关系。在机器学习和深度学习实验中，这意味着每次只调整一个超参数（如学习率、batch size、模型架构的某一层），以便准确归因性能变化的来源。如果同时改变多个变量，即使实验结果有所改善，也无法确定是哪个改动起了作用——这在科研中被称为「混淆变量」问题。将这一经典科学方法论显式化为可操作的检查清单，正是结构化思考规范的价值所在。

关于失败处理有一条明确规范：如果实验失败，就直接如实记录下去，不要再尝试用新方法覆盖这次实验。如果实验一失败，应当进行实验二，同步实验一的条件但不覆盖实验一的记录和输出。这种「只追加、不覆盖」的原则贯穿整套方法论。

实验完成后如何写记录

实验完成后，实验条件的变化和代码的更改都要写在同一条记录里，并说明为什么改、真正改了什么。

对于计算机相关的实验，这里有一个高效的技巧：如果代码文件出现改动，可以先进行git提交，然后让Agent读取git记录的变化，由它自动总结今天代码改了什么、达成了什么效果。

Git是目前最广泛使用的分布式版本控制系统，最初由Linux之父Linus Torvalds开发用于管理Linux内核代码。在科研场景中，Git不仅可以管理代码，还可以记录数据处理脚本、配置文件甚至论文LaTeX源码的每一次变更。每次git commit（提交）都会生成一个唯一的哈希值，记录下谁在什么时间修改了什么内容。通过git diff可以精确看到两个版本之间的差异，git log则能展示完整的修改历史。让Agent读取git记录来自动生成代码变更总结，本质上是利用了Git天然的变更追踪能力，将机器可读的diff信息转化为人类可理解的自然语言描述。这样既保证了记录的准确性，又减轻了手工记录的负担。

而对于生物等实验类学科，Agent则会主动询问一些详细情况，由研究者自己填入。整个每日实验记录的完整闭环是：制定当次实验计划和目标 → 进行实验 → 检查事实 → 用git记录代码更改（或人工填写实验情况）→ 人工判断实验结果 → 进入下一次实验。而下一步实验必须沿着原记录来完成，这在算力和成本上都能显著降低开销。

AI Agent与研究者的分工边界

这套方法论最值得称道的地方，在于对AI Agent与人类研究者分工的清晰界定。

AI Agent（智能体）是指具备自主规划、工具调用和环境交互能力的AI系统，区别于简单的对话式大模型。一个典型的Agent可以分解复杂任务为子步骤、调用外部工具（如文件读写、代码执行、网页搜索）、根据执行反馈调整后续行为。当前主流的Agent框架包括AutoGPT、LangChain Agent、Claude的Computer Use等。在科研场景中，Agent可以自动读取实验日志、分析数据文件、提出假设性问题，但其核心局限在于缺乏对物理世界的真实感知——它无法判断实验数据是否真实、结论是否可靠，这正是本文强调人机分工的根本原因。

Agent负责的部分

Agent可以收集问题背景、整理文件结构、标记信息缺失、审计矛盾等。它的核心职责是「把问题问清楚」——通过提问引导研究者补充事实信息。

研究者负责的部分

研究者负责总结每一次实验记录、规划下一步、批准方案。强烈建议不要使用全自动模式，每一步实验都应由人来确认，这样更安全可靠。

使用Agent必须警惕的风险

使用Agent时需要重点防范几类问题：

• Agent是否产生了敏感信息
• 是否对历史记录进行了覆盖
• 提供的建议中事实来源是否准确
• 前后实验的证据是否存在冲突
• 是否越权执行了任务

最关键的一条警示是：不能让Agent把它自己补充的内容做得像真的一样。这一警示直指AI领域中一个核心技术难题——AI幻觉（Hallucination）。AI幻觉是指大语言模型生成看似合理但实际上不正确或无依据的内容，其根源在于语言模型的生成机制：它基于统计概率预测下一个最可能的token，而非基于对事实的理解和验证。在科研记录场景中，AI幻觉的风险尤为严重——Agent可能编造不存在的实验数据、杜撰引用文献、或将假设性推测表述为确定性结论。这不仅会误导研究者的判断，更可能构成学术不端。近年来已有多起论文撤稿事件与AI生成的虚假引用直接相关。

因此绝不能把「可能的原因」写成结论，也不能把「修改了代码」等同于「产生了结果」——代码改动本身不代表验证成功。

正确的做法是：让Agent标记出待确认的问题、提出核实性问题，等它问清楚后，由研究者输入真实信息，这才是人机协作的正确姿势。

总结：从一份research_log.md开始

本节课的核心产物其实很简单——创建一份 research_log.md，写下今天的第一条实验记录，并为后续所有实验确立每日日志规范和每次实验的日志规范。

但这份看似简单的文档背后，蕴含着一套严谨的科研记录哲学：只追加不覆盖、失败也是宝贵经验、人机分工明确、绝不让AI编造结论。这些原则确保了实验记录的真实性和可追溯性，也让AI真正成为科研反思的助力而非隐患。据UP主预告，下一节将讲解「非常非常重要」的提示词工程，值得持续关注。