8  AI Agent 辅助实证研究

本章核心判断

Agent 可以加快资料整理、代码执行、结果检查和文档撰写，但研究者必须先定义任务、划定资料边界，并对识别判断和最终结果负责。没有这些前提，Agent 只会更快地产生难以追溯的文件和结果。

很多人第一次使用 Agent 时，期待它把一项任务一次做完：读论文、找数据、写代码、跑回归、生成表格，再写一段解释。实际经历往往更复杂。几轮对话以后，文件多了，代码多了，结果也多了，但研究者反而说不清最终样本来自哪里、哪张表对应哪一版设定、某个变量为什么被加入模型。

问题通常不在于 Agent 没有执行，而在于任务本身没有被组织成可执行、可检查的研究流程。本章讨论的不是某一个 AI 工具，而是怎样让 Agent 进入实证研究后仍然保留研究者的判断、证据链和复现能力。

8.1 Agent 开始之前，先把任务说清楚

Agent 很难猜到研究者真正想要什么。你说「帮我复现这篇论文」，它可能会找一个替代数据源，写一份能运行的代码，再给出一组看似合理的结果。这个过程未必对应原文的样本、变量和识别策略。

开始前，研究者至少要说清四件事：

  1. 任务目标：是理解论文、整理数据、复现某张表，还是回应一条审稿意见？
  2. 已有材料：哪些论文、数据、代码、政策文件和说明文档可以使用？哪些材料质量较高、应优先使用？
  3. 交付内容：希望得到目录清单、清洗脚本、回归表、图形、复现说明，还是一份待人工判断的问题清单？
  4. 审查节点：哪些环节完成后必须停下来，由研究者检查再继续？

如果项目已有高质量数据库、机构数据、公开 API 或已经取得的访问权限，也应在任务说明中写清名称、访问方式和优先级。没有授权或不在清单中的材料，Agent 可以列为候选，但不应自行用网页搜索结果替代既定数据来源。

把大任务切成小任务很重要。例如，面对一条要求增加稳健性检验的审稿意见，第一步不应是「直接跑一遍」。更合适的顺序是：先确认审稿人质疑的识别问题，再检查现有数据能否支持该检验，随后写出脚本和日志，最后决定结果是否进入正文。

常见误区

不要把整篇论文、全部数据和一长串要求一次交给 Agent。任务越宽泛，Agent 越容易用平均化的方式补全空白；研究者越难发现它在哪一步替换了原本的研究判断。

8.2 研究者负责判断，Agent 负责执行

Agent 可以持续工作，也能生成一份看起来完整的材料。但政策背景、样本边界和识别策略并不存在唯一的平均答案。研究者需要在一开始明确核心观点：这篇文章是用公式给出简洁的论证，还是用案例解释制度机制？结果变量为什么代表政策目标？哪些数据源可信，哪些只能作为补充？

下表给出一个实用分工。

研究者应当判断 Agent 可以协助执行
政策是否构成可信冲击 整理政策文件、时间线和对象名单
处理组、对照组和结果变量如何定义 检查变量覆盖、缺失、重复值和合并键
平行趋势、排除限制和样本选择机制是否可信 按既定设定运行代码、汇总输出和报错
哪些结果进入主文，哪些只作稳健性检验 生成表格、图形、数据说明和复现说明
审稿意见应如何实质回应 将意见拆成任务清单和待确认问题

Agent 可以提醒你某个变量缺失很多，也可以指出某份脚本没有生成预期输出。它不能替你决定「这个冲击是否近似外生」「这个稳健性检验是否回应了核心质疑」「这组结果是否足以支持结论」。

8.3 用自然语言搭建项目，而不是手工背目录

初学者不需要先背下一整套目录结构，再开始使用 Agent。更实用的做法是：用自然语言说明研究对象、已有材料、希望得到的结果和不能触碰的边界，让 Agent 先提出目录方案；研究者确认后，再创建文件夹和模板。

下面是一段可直接改写的任务说明。

我准备研究 {政策或研究问题}。目前已有 {论文、数据、代码、政策文件}，其中 {材料名称} 是优先依据；{数据库或 API 名称} 可以使用。不在这份清单中的外部网页、数据或 API，只能列为候选，不能自行替代既定来源。

请为我设计一个可复现的实证项目目录，并先用表格说明每个目录的用途、哪些文件允许修改、哪些文件必须保留原样。项目需要包含：原始数据、中间数据、分析脚本、结果表图、研究设计说明、运行日志和环境依赖。

规则：
1. 不修改原始数据；
2. 所有中间数据必须由脚本生成；
3. 每张表和每幅图都要能追溯到生成它的脚本；
4. 不确定的数据来源、变量口径或识别设定必须单列为待确认问题；
5. 记录数据的版本、获取日期或其他可识别的信息；
6. 先给目录方案和 README 草稿，等我确认后再创建文件。

一个确认后的项目通常会包含类似结构：

project/
  data/
    raw/
    processed/
  scripts/
  output/
    tables/
    figures/
  docs/
  logs/
  env/
  README.md
  AGENTS.md

目录本身并不神秘。关键在于每类文件有固定去处：data/raw/ 保存不能改动的原始资料；scripts/ 保存可以重新运行的代码；output/ 保存由代码生成的结果；logs/ 记录运行、修改和待确认问题；env/ 记录软件和依赖。这样换一个 Agent、换一位合作者，研究过程仍然能接得上。

8.4 把通用规则写给 Agent

项目目录解决「文件放在哪里」；规则文件解决「Agent 在项目中可以做什么」。中文规则完全可以直接使用，不需要先翻译成复杂的技术术语。

# 项目规则

## 数据
- 不修改 `data/raw/` 中的文件。
- 所有清洗结果都由 `scripts/` 中的代码生成。
- 发现缺失、异常或口径问题时，记录到 `logs/data_issues.md`，不要自行删除观测。
- 只从任务中列明的数据源、数据库或 API 获取数据；清单之外的来源需要先确认。

## 代码与输出
- 新代码保存到 `scripts/`，不要只在对话窗口中给出代码。
- 每次运行都把命令、日期、输入数据和主要结果写入日志。
- 在日志中记录 Stata、Python 或 R 的版本、关键依赖和随机种子。
- 表格和图形保存到 `output/`，并注明对应脚本。
- 不覆盖已有正式结果；需要替换时，保留旧版本或先请求确认。

## 研究判断
- 不擅自改变样本、核心变量、固定效应或识别策略。
- 对不确定的政策事实、数据来源和文献链接，列入待确认问题。
- 需要覆盖文件、删除文件或安装新软件时，先请求确认。

这类规则可以保存为 AGENTS.md、PROJECT_RULES.md 或团队约定的其他文件。读者也可以从公开模板开始，再让 Agent 根据自己的研究主题改写为本地规则。记录软件版本、关键依赖、随机种子和输入数据版本，能避免“代码没有变，结果为什么不同”的无效排查。规则不是为了限制 Agent，而是让它在正确的边界内发挥作用。

如果希望进一步了解 Agent 分工、数据收集和规则复用，可以阅读：

8.5 复现包审计：先建立证据链

本章不要求读者马上完整复现一篇大论文，但应学会审计复现包。审计的目标是弄清楚：数据从哪里来，脚本按什么顺序运行，哪一个文件生成哪张表，以及哪些地方需要人工判断。

可以按五步推进：

  1. 读 README，找出作者说明的运行顺序、依赖和入口文件。
  2. 找主脚本，确认哪些脚本会调用其他脚本。
  3. 追踪数据流，记录原始数据如何变成分析数据。
  4. 对照表格和图形，建立输出与脚本的对应关系。
  5. 检查日志，区分代码报错、缺失依赖、数据不可得和结果差异。

让 Agent 做审计时，不要只问「这份代码对不对」。更合适的要求是：输出文件清单、主脚本、数据流、依赖清单、表图映射、错误日志，以及需要研究者判断的问题。这样得到的是一份可以继续工作的复现说明，而不是一句笼统评价。

审计提示词

请读取这个复现包的 README 和目录结构，但不要运行任何代码。请输出：主脚本及调用关系、数据输入和输出、预计生成的表图、软件依赖，以及无法从文件中确认的问题。不要猜测缺失的路径、数据或变量含义。

8.6 返修、交接和 Git：把结果留在证据链里

返修阶段最容易暴露 Agent 工作流的短板。研究者根据审稿意见补做分析，Agent 读取 Excel 数据、跑出一组新结果，表面上工作已经完成；等到准备提交时，却发现没有完整代码、没有运行日志，也说不清数据是怎样整理出来的。再次让 Agent 运行，结果可能因为随机种子、软件版本、数据处理细节或提示语变化而不同。

这类情况的补救成本很高。更稳妥的规则是：从第一轮补充分析开始，就把原始数据、中间数据和最终数据分开保存；让 Agent 把每一步写成 Stata、Python 或 R 脚本；每次运行后记录输入、输出和报错；在一个阶段完成后提交 Git commit。这样即使后续换了 Agent、换了合作者，新的执行者也能从同一套文件和日志继续工作。

下面这段规则适合放进返修任务说明。

本轮任务是回应审稿意见 {编号}。请先阅读现有研究设计、数据说明和主脚本，再提出执行计划。

执行规则：
1. 原始数据只读；中间数据和最终分析数据必须由脚本生成；
2. 所有新增分析保存为可重复运行的 Stata、Python 或 R 脚本；
3. 每张新增表图都注明脚本、输入数据和运行日期；
4. 将数据问题、模型变化和未解决问题分别记录到日志；
5. 不修改主结果或覆盖旧输出，除非我确认；
6. 完成一个可检查阶段后，汇总变更文件、主要结果和下一步建议，等待确认。

Git 在这里不是额外负担。它提供的是版本边界：哪些修改属于一轮返修，哪些结果是在某个设定下生成，哪些文件可以回退。小项目至少应在「数据整理完成」「主结果生成」「返修分析完成」这类节点留下清楚的 commit 信息。

最小工作日志

不需要一开始就建立复杂的项目管理系统。一份 logs/work_log.md 至少记录以下内容即可：

## 2026-07-10：处理缺失值

- 任务：检查并处理企业年龄变量的缺失记录。
- 文件：修改 `scripts/02_clean_data.do`；输入为 `data/raw/firm.dta`。
- 环境：Stata 19；随机种子不适用。
- 结果：保留原始缺失值，新增缺失标记变量；样本量没有变化。
- 待确认：缺失是否应进入基准回归，等待研究者确认。

对较长或较重要的任务，可以把“执行”和“复核”分开。执行 Agent 按已确认的计划修改文件、运行脚本和写日志；复核 Agent 只检查差异、日志、输出和未解决问题。研究者仍负责确认研究设计、变量口径和结果解释。这样做不必把一个小项目变成多层流程，但能把“做完了”和“做对了”区分开。

8.7 A8 模板包：把规则装进新项目

本项目配套提供了 A8 Agent 工作流模板包。它不预设某一种软件或研究方法，而是把最容易遗漏的边界整理成可直接改写的文件：

  • AGENTS_template.md：数据、代码、输出、研究判断和确认节点的通用规则；
  • research_design_template.md：研究问题、政策机制、样本、变量和识别风险的最小设计说明；
  • work_log_template.md、data_issues_template.md、model_changes_template.md 和 decision_log_template.md：把运行、数据问题、模型变动和研究判断分别留下记录；
  • replication_audit_checklist.md：不运行代码时审计复现包的检查清单；
  • prompts/：让读者自己的 Agent 创建新项目、从线上模板包安装文件，或组织审稿意见返修的提示词。

使用时，可以先下载整个文件夹，再保留最需要的 3–5 个模板。新项目通常从 README_template.md、AGENTS_template.md、research_design_template.md 和 work_log_template.md 开始就够了；需要复现或返修时，再加入审计清单和专项日志。

如果读者希望让自己的 Agent 协助安装模板，可以直接打开并复制 本地创建项目提示词，让 Agent 先提出目录和文件清单，确认后再创建。如果模板包尚未下载到本机，则使用 线上安装提示词。两份提示词都要求 Agent 不覆盖已有文件、不下载私有材料、不运行数据或代码，直到研究者确认。

8.8 Agent 扩大执行半径，研究者保留识别责任

本章最后只保留一个判断：Agent 可以把研究者从重复性工作中解放出来，但不能替代研究设计。

它可以帮助整理文件、运行脚本、检查数据、生成表图、拆解复现包和草拟说明文档。它不能替你决定政策冲击是否可信、比较对象是否合适、识别假设是否站得住，或一组结果是否足以进入论文结论。

对一天的课程而言，读者不需要立刻搭建复杂的多 Agent 系统。先做到三件事就够了：把任务说清楚，把代码和数据留在项目里，把每次重要修改记下来。这样使用 Agent，才会让后续研究更快，也更稳。

8.9 延伸阅读