1. 科研场景下 AI Agent 的真实困境1.1 从“能跑”到“跑对”之间隔了什么我最早把 AI Agent 引入科研工作流是在处理一批材料计算数据的时候。当时的需求很朴素让 Agent 帮我读一批结构文件提取关键参数按指定格式汇总成表格。第一次跑结果看起来挺像那么回事格式整齐字段齐全。但我随手抽查了三条就发现其中一条把晶格常数的单位从埃换成了纳米却没标注另一条把两个相似结构的编号搞混了。如果我没有抽查这份表格就会直接进入后续分析错误会被放大到整个结论里。这件事让我意识到一个核心问题AI Agent 在科研场景里最大的风险不是“跑不起来”而是“跑起来了但跑错了而且错得很隐蔽”。科研工作和普通的内容生成任务有本质区别它对可追溯性、可复现性、边界明确性的要求极高。一个写作助手把“大约”写成“大概”无伤大雅但一个科研 Agent 把对照组和处理组的标签弄反整篇论文的结论就废了。那怎么解决我试过很多办法。在对话里反复强调“注意单位”“注意编号”效果不稳定因为每次新开一个会话上下文就重置了。把要求写进系统提示词稍微好一点但系统提示词一长Agent 的注意力就会被稀释而且不同工具对系统提示词的支持程度不一样。后来我逐渐收敛到一个方案用项目文档 PROJECT.md 作为 Agent 的“科研规范说明书”把那些不能出错、不能含糊的约束从对话里搬到文档里让 Agent 每次执行任务前先读这份文档。1.2 为什么是 PROJECT.md 而不是别的你可能会问为什么偏偏是 PROJECT.md而不是 README.md、AGENTS.md 或者别的什么文件这个问题我认真想过也实际对比过几种方案。README.md 的定位是“给人看的项目说明”它通常包含项目背景、安装步骤、使用方法。这些内容对 Agent 也有用但它的组织方式是为人类阅读优化的不是为 Agent 执行优化的。人类可以跳读、可以凭经验补全缺失信息Agent 不行它需要的是明确的指令、清晰的边界、可枚举的规则。AGENTS.md 更接近我想要的它本身就是为 Agent 设计的上下文文件。但在科研场景里我发现单纯一个 AGENTS.md 还不够。科研项目往往有多个层次的信息项目级别的总体目标、子任务级别的具体规范、数据级别的格式要求、输出级别的验收标准。这些信息如果全塞进一个文件会变得臃肿如果分散到多个文件又需要一套组织逻辑。PROJECT.md 在我的实践里扮演的是总纲的角色。它不追求覆盖所有细节而是明确三件事这个项目要解决什么问题、Agent 在项目中承担什么角色、以及 Agent 必须遵守哪些硬性约束。具体的任务指令可以放在单独的 AGENTS.md 或任务描述里但 PROJECT.md 是每次会话开始时 Agent 必须先读的那一份。它就像实验室墙上的安全守则不涉及具体实验步骤但每个进实验室的人都要先看一遍。1.3 这套方案适合什么样的科研工作不是所有科研任务都值得上这套方案。如果你只是让 Agent 帮你查一篇文献的摘要或者翻译一段英文那直接对话就够了没必要搞项目文档。但如果你面对的是以下场景PROJECT.md 的价值就会非常明显多步骤、长周期的任务比如从原始数据清洗到最终图表生成中间有十几个环节每个环节都有格式要求。多人协作或多次复现的任务你需要保证不同时间、不同人跑出来的结果是一致的。对错误零容忍的任务比如涉及数值计算、统计分析、实验对照的任务一个标签错误就可能导致结论反转。需要频繁切换 Agent 工具的任务今天用这个明天用那个你不想每次重新交代一遍规则。我自己的经验是当一个科研任务的步骤超过五步或者需要我反复向 Agent 解释同一件事超过两次我就会停下来先写一份 PROJECT.md。这个投入通常在半小时以内但省下来的沟通成本和纠错成本往往是十倍以上。2. PROJECT.md 的核心结构与编写逻辑2.1 一份合格的科研 PROJECT.md 应该包含什么我见过不少 PROJECT.md有的写得像散文有的写得像代码注释有的干脆就是把 README 改了个名字。这些都不是我想要的。经过多次迭代我目前使用的 PROJECT.md 模板包含五个核心模块每个模块都有明确的编写目的。项目目标模块回答的是“我们在做什么”。这部分要写得足够具体具体到 Agent 能判断一个任务是否属于项目范围。比如“分析一批材料的力学性能”就太模糊“从给定的 200 个结构文件中提取弹性常数按指定格式汇总并标记异常值”就清晰得多。Agent 读到前者可能会去帮你查文献读到后者它就知道自己的边界在哪里。Agent 角色模块回答的是“你是谁你负责什么”。科研项目里Agent 可能扮演数据清洗员、代码生成器、结果校验员等不同角色。明确角色不是为了限制 Agent 的能力而是为了让它知道在什么阶段应该以什么身份行事。我通常会在这一节里写清楚Agent 在本项目中不负责提出科学假设不负责解释结果的物理意义只负责按规范执行数据处理和格式转换。这条边界非常重要它防止 Agent 越界给出看似合理但未经证实的科学判断。硬性约束模块是整份文档里最不能含糊的部分。单位、精度、命名规则、文件编码、缺失值处理方式这些都要一条一条列清楚。我习惯用“必须”“禁止”“一律”这样的词不用“建议”“尽量”“最好”。Agent 对模糊词的理解是不稳定的你写“尽量保留两位小数”它可能在某些情况下保留三位在某些情况下保留一位。你写“一律保留两位小数第三位四舍五入”它的行为就稳定得多。任务流程模块描述的是标准操作流程。这部分不需要写得像菜谱那么细但关键节点和检查点要明确。比如“数据读取后先检查行数和列数是否与预期一致”“计算完成后随机抽取 5% 的样本进行人工复核”。这些检查点看起来是给 Agent 的指令实际上也是给我自己的提醒让我知道在哪些环节需要介入。输出规范模块规定的是最终交付物的格式。文件命名、目录结构、表格列名、图表尺寸、颜色方案这些都要写清楚。科研工作的输出往往要进入论文或报告格式不统一会带来大量返工。我吃过这个亏所以现在会把输出规范写得非常细细到“表格第一列是样本编号第二列是数值第三列是单位列名用英文首字母大写”。2.2 为什么这些模块的顺序不能乱这五个模块的顺序不是随便排的。它遵循的是从抽象到具体、从目标到执行的逻辑。Agent 读文档的方式和人类不一样它不会跳读也不会凭经验补全。如果顺序乱了它可能会在还没理解项目目标的情况下就看到了具体的输出格式要求然后机械地按格式生成内容却忽略了内容本身是否符合项目目标。我做过一个对比实验。同样的内容一份按“目标-角色-约束-流程-输出”排列一份按“输出-流程-约束-角色-目标”排列让 Agent 执行同一个任务。前者的结果明显更符合预期后者虽然格式正确但在几个关键判断上出现了偏差。这个实验样本很小不能说明普遍规律但至少在我的场景里顺序是有影响的。另一个经验是硬性约束模块要放在任务流程之前。因为流程是“怎么做”约束是“什么不能做”。先让 Agent 知道红线在哪里再让它去执行步骤比反过来更安全。就像教学生做实验先讲安全规范再讲操作步骤顺序反了容易出事。2.3 一个真实的 PROJECT.md 片段下面是我在一个数据处理项目中实际使用的 PROJECT.md 片段隐去了具体项目信息保留了结构和写法。你可以直接参考这个格式替换成你自己的内容。# PROJECT.md ## 项目目标 从给定的结构文件中提取力学参数按指定格式汇总为 CSV 文件 并标记出数值异常或缺失的样本。不进行任何物理意义层面的解释。 ## Agent 角色 你是一个数据提取与格式转换助手。你不负责判断数据的科学合理性 不负责提出假设不负责解释结果。遇到无法确定的情况停止操作并 向用户提问不要自行猜测。 ## 硬性约束 - 长度单位一律使用埃保留 4 位小数。 - 能量单位一律使用电子伏特保留 6 位小数。 - 样本编号必须与原始文件名一致不得修改大小写或添加前缀。 - 缺失值一律填写 NA不得留空不得填 0。 - 所有输出文件使用 UTF-8 编码换行符使用 LF。 ## 任务流程 1. 读取指定目录下所有 .cif 文件。 2. 检查文件数量是否与预期一致不一致则停止并报告。 3. 逐个提取参数每处理 10 个文件暂停一次报告进度。 4. 汇总为 CSV按样本编号排序。 5. 随机抽取 5% 的样本与原始文件比对报告比对结果。 ## 输出规范 - 输出文件命名为 result_YYYYMMDD.csv。 - 第一列为 sample_id第二列为 lattice_constant第三列为 energy。 - 列名使用英文首字母小写下划线分隔。 - 数值列不得包含单位符号单位在 PROJECT.md 中统一约定。这份文档不长但信息密度很高。Agent 读完它基本不会在单位、格式、命名这些低级问题上犯错。剩下的精力就可以放在真正的数据处理上。3. 把 PROJECT.md 接入不同 Agent 工具的实操细节3.1 不同工具对项目文档的读取方式差异PROJECT.md 本身是一个纯文本文件但不同 Agent 工具读取它的方式不一样这直接影响你的使用体验。我目前主要用两类工具一类是命令行式的 Agent一类是编辑器集成的 Agent。它们的读取逻辑有区别需要分别处理。命令行式 Agent 通常需要你显式指定上下文文件。比如在启动任务时把 PROJECT.md 的路径作为参数传进去或者在任务描述里写明“先读取 PROJECT.md”。这种方式的优点是控制精确你知道 Agent 读了什么缺点是每次都要记得传容易忘。我的做法是在项目根目录放一个固定的启动脚本把读取 PROJECT.md 作为第一步固定下来这样就不依赖记忆了。编辑器集成的 Agent 通常会自动读取项目根目录下的特定文件。不同的工具认的文件名不一样有的认 AGENTS.md有的认 PROJECT.md有的两者都认。你需要查一下你用的工具支持哪些文件名。如果不支持 PROJECT.md有两个办法一是把 PROJECT.md 的内容复制到它支持的文件里二是用符号链接把 PROJECT.md 链接到它认的文件名。我一般用第一种因为符号链接在某些系统上会有兼容性问题。还有一个细节是读取时机。有些工具是在会话开始时读一次之后就不再读了有些工具是每次任务执行前都读。前者适合内容稳定的项目文档后者适合需要频繁调整约束的场景。我在项目初期会用后者因为约束经常要改等项目稳定了就换成前者减少不必要的读取开销。3.2 上下文窗口有限时怎么取舍这是很多人会遇到的问题PROJECT.md 写得太详细加上任务描述和实际数据上下文窗口就不够用了。Agent 要么报错要么开始“遗忘”前面的内容。我试过几种应对策略各有适用场景。策略一分层文档。把 PROJECT.md 拆成核心版和完整版。核心版只保留硬性约束和输出规范放在项目根目录每次必读。完整版包含项目背景、详细流程、示例放在子目录里只在需要时读取。这样上下文占用小关键信息又不丢失。策略二约束前置。如果只能读一份文档就把最重要的约束放在文档最前面。Agent 对文档开头的注意力通常比中间和结尾高。我把单位、精度、命名规则这些放在最前面把项目背景放在最后面。实测下来这样能减少不少低级错误。策略三动态裁剪。对于特别长的项目文档我会根据当前任务类型只把相关章节喂给 Agent。比如做数据提取时只给约束和流程做结果汇总时只给输出规范。这需要手动操作麻烦一点但上下文利用率最高。提示不要为了省上下文而删掉硬性约束。约束是底线底线不能省。要省就省项目背景和示例那些是锦上添花的内容。3.3 让 Agent 主动确认而不是被动执行这是我踩过坑之后养成的一个习惯在 PROJECT.md 里加一条规则要求 Agent 在执行任务前先用自己的话复述一遍关键约束并确认理解无误。这条规则看起来多余但实际效果很好。有一次我让 Agent 处理一批数据约束里写了“缺失值填 NA”。Agent 执行到一半遇到一个缺失值它填了“N/A”。这两个写法在人类看来差不多但在后续的自动化处理里“N/A”和“NA”会被当成两个不同的值导致统计出错。如果 Agent 在开始前复述了约束我就能及时发现它把“NA”理解成了“N/A”避免后面的返工。复述确认还有一个好处它能暴露 Agent 对约束的理解偏差。有些偏差不是字面上的而是语义上的。比如你写“保留两位小数”Agent 可能理解为“截断到两位”而不是“四舍五入到两位”。复述的时候它说“我会把数值截断到两位小数”你就能立刻纠正。我通常会在 PROJECT.md 的末尾加一段## 执行前确认 在开始任何任务前请先复述以下内容 1. 本项目的核心目标是什么。 2. 你扮演什么角色不负责什么。 3. 列出三条你认为最重要的硬性约束。 4. 你计划如何执行任务流程。 复述完成后等待用户确认再开始。这段确认流程会增加一点交互成本但比起事后纠错这点成本完全可以接受。4. 科研场景下的常见问题与排查实录4.1 Agent 忽略约束的几种典型情况即使写了 PROJECT.mdAgent 也不是百分之百遵守约束。我总结了几种最常见的情况以及对应的排查思路。情况一约束太多Agent 记不住。这是最常见的。一份 PROJECT.md 里列了二十条约束Agent 执行到后面就忘了前面的。解决办法是分级把约束分成“必须遵守”和“尽量遵守”两类必须遵守的用加粗或单独章节标出数量控制在五条以内。超过五条Agent 的遵守率就会明显下降。情况二约束之间有冲突。比如一条约束说“所有数值保留两位小数”另一条说“能量值保留六位小数”。Agent 遇到能量值时不知道该听哪条。解决办法是明确优先级在文档里写明“特殊约束优先于通用约束”或者干脆把通用约束改成“除能量值外所有数值保留两位小数”。情况三约束表述有歧义。比如“按样本编号排序”Agent 可能按字符串排序也可能按数值排序。如果编号是“1, 2, 10”字符串排序会得到“1, 10, 2”数值排序会得到“1, 2, 10”。解决办法是消除歧义写明“按样本编号的数值大小排序编号中的数字部分转为整数后比较”。情况四Agent 在长任务中“遗忘”约束。任务步骤多、耗时长的时候Agent 可能会在中间某个环节偏离约束。解决办法是设置检查点在流程的关键节点要求 Agent 重新确认约束。比如“每处理 50 个样本重新阅读硬性约束章节确认当前操作符合要求”。4.2 数据格式问题的排查清单数据格式问题是科研 Agent 最容易出错的地方也是排查起来最耗时的。我整理了一份速查表遇到格式问题时按顺序排查。问题现象可能原因排查方法解决方式数值精度不一致约束未明确舍入方式检查 PROJECT.md 是否写了“四舍五入”还是“截断”在约束中明确舍入规则单位混用约束未覆盖所有字段逐个字段核对约束列表补全约束或统一转换为基准单位缺失值处理不一致约束表述有歧义检查是否写了“填 NA”但未说明大小写明确写“填大写 NA两个字符”文件编码错误未指定编码格式用十六进制查看器检查文件头在约束中写明“UTF-8 无 BOM”列名不匹配输出规范不够具体对比实际输出与规范中的列名列表在规范中逐列列出列名和顺序排序结果异常排序规则未明确检查是否区分字符串排序和数值排序明确排序依据和比较方式这张表我放在手边遇到问题就对照着查。大部分格式问题都能在前三行找到原因。4.3 当 Agent 给出“看起来对但实际错”的结果时这是最危险的情况。Agent 的输出格式完美、数值合理、逻辑自洽但就是错的。我遇到过几次每次都是靠交叉验证发现的。一次是 Agent 汇总了一批计算结果数值都在合理范围内但总数对不上。我让它重新计算它给出了同样的结果。后来我手动抽查了原始数据发现它在读取某个文件时跳过了第一行而第一行恰好是有效数据。这个错误不会导致数值异常只会导致样本数少一个。如果我没有核对样本总数这个错误就会一直隐藏下去。从那以后我在 PROJECT.md 里加了一条硬性约束任何汇总操作必须报告输入样本数和输出样本数两者不一致时停止并报告。这条约束帮我拦住了好几次类似的问题。交叉验证的另一个方法是换一种方式算一遍。比如 Agent 用 Python 算了一遍我让它用另一种方法再算一遍对比结果。如果两种方法结果一致可信度就高很多如果不一致就说明至少有一种方法有问题。这个方法费时间但对于关键数据值得。注意不要因为 Agent 连续几次结果正确就放松警惕。错误往往是偶发的连续正确不代表下一次也正确。关键数据永远要交叉验证。4.4 多 Agent 协作时的文档同步问题当一个项目里用了多个 Agent或者同一个 Agent 在不同任务间切换时PROJECT.md 的同步就成了问题。我遇到过的情况是我更新了 PROJECT.md 里的约束但某个 Agent 还在用旧版本的约束执行任务导致输出格式不一致。解决办法是版本化。在 PROJECT.md 的开头加一个版本号和更新日期每次修改都更新版本号。然后在任务描述里要求 Agent 报告它读取的 PROJECT.md 版本号。如果版本号对不上就说明有 Agent 用了旧文档。# PROJECT.md 版本v1.3 更新日期2026-01-15 更新内容修改了能量值的精度要求从 4 位改为 6 位。另一个办法是单一来源。所有 Agent 都从同一个路径读取 PROJECT.md不复制、不转发。这样只要更新了源文件所有 Agent 下次读取时都会拿到最新版本。复制转发是版本不一致的主要来源能避免就避免。5. 从 PROJECT.md 到完整科研 Agent 工作流5.1 项目文档只是起点PROJECT.md 解决了“Agent 知道什么”的问题但没有解决“Agent 怎么执行”的问题。一个完整的科研 Agent 工作流还需要任务分解、工具调用、结果校验这几个环节。PROJECT.md 是这些环节的共同基础但它本身不构成工作流。我的做法是PROJECT.md 定义静态规则任务描述定义动态指令两者配合使用。PROJECT.md 里写的是“所有数值保留两位小数”任务描述里写的是“请处理 data 目录下的文件输出到 result.csv”。Agent 先读 PROJECT.md 建立规则意识再读任务描述执行具体操作。这种分离的好处是复用性。同一份 PROJECT.md 可以配合不同的任务描述处理不同的数据。我不需要每次都在任务描述里重复单位、精度、命名规则只需要写清楚这次要做什么。任务描述可以很短PROJECT.md 保持稳定。5.2 任务分解的粒度控制任务分解的粒度是个经验活。分得太粗Agent 容易跑偏分得太细交互次数太多效率低。我的经验是按检查点分解每个子任务结束时应该有一个可以验证的输出。比如“读取文件”是一个子任务输出是文件列表和样本数“提取参数”是一个子任务输出是原始参数表“格式转换”是一个子任务输出是符合规范的 CSV。每个子任务结束后我会让 Agent 报告结果我快速检查一下确认无误再进入下一个子任务。这样虽然交互次数多了但错误能在早期被发现不会累积到最后。科研工作里早期发现一个错误比后期返工的成本低得多。对于特别长的任务我会在 PROJECT.md 里预设自动检查点。比如“每处理 100 个样本自动暂停并报告进度和已处理样本的统计摘要”。这样即使我不在旁边Agent 也会在关键节点停下来留下检查痕迹。5.3 结果校验的自动化思路人工校验费时间而且容易疲劳。我尝试把一些常规校验自动化让 Agent 自己完成我只做最终抽查。常规校验包括样本数是否一致、数值范围是否合理、缺失值比例是否正常、格式是否符合规范。这些校验可以写成脚本也可以写成 Agent 的指令。我倾向于写成 Agent 的指令因为脚本需要维护而指令跟着 PROJECT.md 走改起来方便。比如在 PROJECT.md 里加一段## 自动校验规则 每次生成输出文件后自动执行以下校验 1. 输出样本数是否等于输入样本数不等则报告差异。 2. 数值列的最小值和最大值是否在合理范围内超出则标记。 3. 缺失值比例是否超过 5%超过则报告。 4. 文件编码是否为 UTF-8换行符是否为 LF。 校验结果附在输出文件末尾或单独生成校验报告。这段规则让 Agent 在交付结果前先自己检查一遍。我拿到结果后只需要看校验报告确认没有异常就可以进入下一步。这比我自己从头检查快得多。5.4 长期项目的文档维护节奏科研项目往往持续几个月甚至几年PROJECT.md 需要跟着项目演进。我的维护节奏是项目初期频繁更新项目中期稳定更新项目后期冻结更新。初期约束和流程都在摸索可能一周改好几次。这时候我会在文档里标注“草稿”状态提醒自己和其他协作者规则可能随时变。中期主要流程稳定了只有细节调整可能一个月改一次。后期项目进入收尾阶段文档冻结不再修改保证结果的可复现性。每次更新 PROJECT.md我都会在版本记录里写清楚改了什么、为什么改。这不是为了形式而是为了可追溯。半年后回头看我能知道当时为什么把精度从 4 位改成 6 位是因为发现了什么数据问题还是因为合作方提出了新要求。这些信息在写论文的方法部分时很有用。提示PROJECT.md 的版本记录不要写得太简略。“修改了精度要求”不如“将能量值精度从 4 位小数改为 6 位小数原因是合作方提供的参考数据精度为 6 位4 位会导致对比时出现舍入误差”。后者在半年后看仍然有意义。6. 我踩过的坑和总结出的经验6.1 不要试图用 PROJECT.md 解决所有问题我一开始犯的错误是把 PROJECT.md 写得太长恨不得把所有可能的情况都覆盖到。结果文档超过三千字Agent 读起来吃力遵守率反而下降。后来我明白了PROJECT.md 的作用是建立规则意识不是穷举所有情况。遇到文档没覆盖的情况Agent 应该停下来问而不是自己猜。所以我在文档里加了一条“遇到 PROJECT.md 未明确规定的操作停止执行并向用户提问不要自行决定。”这条规则比多写一千字的细节更有效。6.2 约束要可验证不要写“注意”“小心”这类词“注意单位统一”这种约束Agent 没法执行因为它不知道什么叫“注意”。可验证的约束是“所有长度值以埃为单位保留 4 位小数写入 CSV 时不含单位符号”。后者 Agent 可以逐条检查前者只能靠自觉。科研场景里靠自觉是靠不住的要靠规则。6.3 给 Agent 留出“不确定”的出口科研数据经常有模糊地带比如某个文件的格式和预期不符某个数值处于正常范围的边缘。这时候如果 Agent 强行处理可能引入错误。我在 PROJECT.md 里明确写了“遇到不确定的情况标记为待确认不要自行处理在输出中单独列出。”这样我拿到结果时能清楚知道哪些地方需要人工判断而不是被 Agent 的“自信”误导。6.4 定期回顾 PROJECT.md 的实际执行效果文档写了不等于执行了。我会定期抽查 Agent 的输出对照 PROJECT.md 的约束看哪些约束被遵守了哪些被忽略了。被忽略的约束要么是写得不清楚要么是不重要。不清楚的就改清楚不重要的就删掉。文档不是越长越好而是越有效越好。我现在的 PROJECT.md 通常控制在八百到一千字包含五到八条硬性约束三到五个流程步骤以及输出规范。这个规模 Agent 读起来不费力遵守率也高。超过这个规模我就会考虑拆分把不常用的内容移到子文档里。6.5 一个让我印象深刻的教训有一次我处理一批实验数据PROJECT.md 里写了“缺失值填 NA”。Agent 执行时遇到一个缺失值它填了“na”。我当时没注意直接进入了下一步分析。分析脚本里判断缺失值的条件是“ NA”小写的“na”没被识别被当成了有效值参与计算。结果那个样本的统计值偏离了正常范围我花了大半天才定位到问题。从那以后我在约束里写缺失值时会写“填大写 NA两个字符不含引号”。同时在自动校验规则里加一条“检查缺失值字段是否全部为大写 NA”。这个教训让我明白约束的精确度直接决定结果的可靠性。在科研场景里一个字符的大小写都可能影响结论。7. 这套方法还能怎么扩展7.1 从单项目到多项目的文档体系当一个实验室或一个团队有多个项目时PROJECT.md 可以进一步组织成体系。我的做法是每个项目有自己的 PROJECT.md同时有一个团队级别的 PROJECT.base.md包含所有项目共通的约束比如编码规范、文件命名规范、数据安全规范。每个项目的 PROJECT.md 继承 base 的内容再补充项目特有的约束。这样新项目启动时不需要从零写 PROJECT.md只需要在 base 的基础上补充差异部分。维护成本降低了规范的一致性也提高了。7.2 把 PROJECT.md 和自动化脚本结合PROJECT.md 里的自动校验规则可以进一步固化成脚本。Agent 执行完任务后自动调用校验脚本生成校验报告。这样校验不依赖 Agent 的“自觉”而是由代码保证。我目前把样本数校验、格式校验、缺失值校验做成了脚本Agent 在输出前调用不通过就报错。这比让 Agent 自己检查更可靠。7.3 用 PROJECT.md 沉淀科研经验PROJECT.md 不只是给 Agent 看的也是给未来的自己看的。每次踩坑后我会把教训写进 PROJECT.md 的约束里。比如“缺失值填大写 NA”这条就是踩坑后加的。时间长了PROJECT.md 就成了这个项目的经验集合。新人接手时读一遍 PROJECT.md就能避开大部分坑。这比口头交代或者散落在聊天记录里的经验可靠得多。我个人的体会是PROJECT.md 的价值不在于它有多复杂而在于它把那些容易忘记、容易忽略、容易出错的事情从人的脑子里搬到了文档里。Agent 读它人也读它。Agent 按它执行人也按它检查。这种一致性是科研工作可复现的基础。
