AI智能体与Workflow：科研文献结构化抽取及校验实践

凌晨一点，你坐在电脑前，屏幕上开着十几个 PDF 标签页，旁边是没写完的组会汇报和一堆格式各异的参考文献。你回想这一天，真正用来"想问题"的时间可能不到两小时，剩下的时间都在做同一类事：找文献、下载、转文字、做笔记、复制粘贴、调格式、改引用编号。这些活没有一件需要博士学位，却结结实实地吃掉了一整天。

这就是我想聊这个话题的原因。"读研读博想起飞，要把 80% 的事情交给 AI 智能体去做"这句话，很多人第一反应是"让 AI 帮我写论文"，这个理解偏得有点远，而且危险。我更愿意把它理解成一个时间分配原则：把那些低认知密度、高重复度、强格式约束的事务性工作交出去，把判断、设计、解释、批判留给自己。比例是 80 比 20，但划分标准不是"任务数量"，而是"这件事做错了，你能不能发现"。

这篇文章不打算讨论"AI 能不能做科研"这种空泛命题，而是把它拆成工程问题：Agent 和普通对话式 AI 到底差在哪，科研流程里哪些环节适合托管，怎么用几十行代码搭一个最小可用的文献结构化 Agent，怎么验证它没在胡说，以及它在什么情况下会把你坑得很惨。如果你正在读研读博，或者带学生、做研发，需要处理大量文献和重复性资料整理，这篇内容可以直接拿去改。

需要提前说清楚一点：本文所有代码和配置都是通用工程思路的演示，运行环境、模型服务、接口地址请以你所在实验室或公司的实际规范和授权为准。涉及未发表的实验数据、涉密材料、受版权保护的全文内容，不要上传到任何外部服务，这条底线比效率重要得多。

1. 这篇文章真正要解决的问题

研究生的时间黑洞，其实不太在"不会做研究"，而在"研究之外的事情太多"。我观察到的典型消耗集中在几类：一是文献环节，从检索、筛选、下载到读完做笔记，一篇论文从"看到标题"到"进入你的知识库"平均要经过五六个工具；二是记录环节，实验参数、运行日志、中间结论散落在聊天记录、临时文件和各种笔记软件里，过两周自己都找不到；三是产出环节，组会 PPT、周报、开题报告、论文初稿，每次都要重新组织一遍已有信息；四是格式环节，参考文献样式、图表编号、期刊模板，改起来没完没了。

这四类事情的共同点非常明显：规则相对固定、输入输出格式明确、错误可以被检查出来。这正好是自动化最擅长的区域。相反，选题判断、实验方案设计、结果解释、对一篇论文方法缺陷的批判性评价，这些事情的共同点是"没有标准答案，错了也不一定立刻暴露"，这才是必须由人来做的部分。

所以这篇文章要解决的核心问题只有一个：怎么在不牺牲学术严谨性的前提下，把可托管的那部分工作真正交出去，并且保证交出去之后你还能查、能改、能回滚。这不是一个"用哪个 AI 工具"的问题，而是一个工作流设计问题。

有一点需要提醒：网上很多"AI 科研"的教程，示范的都是"让模型总结一篇论文"，这只发挥了不到一成的价值。真正省时间的是批量、结构化、可复用的流水线——一次处理五十篇，输出统一的字段，直接能进你的表格和数据库，后续写综述时可以直接筛选和对比。这才是"80%"应该去的地方。

2. Agent、Chatbot、Workflow 的概念边界

很多人把这三个词混着用，导致后面所有的设计都变形。先把边界划清楚，后面的代码才好理解。

**Chatbot（对话式模型）**是最简单的形态：你给一段输入，它给一段输出，一次一问一答，没有记忆、没有工具、不碰你的文件系统。它的价值在于"单次生成"，缺陷在于每次都要你手工搬运上下文。

**Agent（智能体）**在 Chatbot 之上加了三样东西：工具调用能力（能读文件、能跑代码、能查数据库）、循环控制能力（可以自己决定下一步做什么，做完再看结果）、状态保持能力（中间结果能落盘，下次接着干）。它解决的是"多步骤任务没人盯着也能走完"的问题。

**Workflow（工作流）**则更进一步，把步骤写死：第一步做什么、第二步做什么、失败了怎么办，全部由你定义，模型只在特定节点上承担"生成"或"判断"的角色。它牺牲了灵活性，换来了可预测性和可复现性。

三者的对比可以看这张表：

这里真正容易踩坑的地方是：很多人一上来就追求"全自动 Agent"，结果做出一个黑盒，跑完不知道它对不对。对科研场景来说，我更推荐"Workflow 为主、Agent 为辅"的结构——流程由你定死，模型只负责其中"需要理解自然语言"的那几个节点。这样即使模型出错，错误也被限制在单个节点内，不会污染整条链路。

还有一个新手常见误解：以为 Agent 就是"更聪明的聊天机器人"。实际上 Agent 的能力上限很大程度上不取决于模型本身，而取决于你给它接了什么工具、工具的输出是否可验证。一个只能输出文本的模型，和一个能读文件、能执行校验脚本、能把结果写进结构化文件的模型，哪怕底层模型完全相同，可靠性也差着一个量级。

3. 科研任务拆解：哪些能交给 Agent，哪些不能

"80%"这个数字，落到具体任务上才有意义。我用的判断标准是三个问题，任何一个答案是"否"，这个任务就不该完全托管：

1. 这件事的输出能不能被机器检查？比如字段是否齐全、数字是否在合理区间、引用是否真的出现在原文里。
2. 这件事错了之后，你能不能在两分钟内发现？如果你要花半天才能确认它对不对，那托管省下来的时间还不够你复核。
3. 这件事是否涉及未公开数据、他人知识产权或学术诚信红线？涉及的话，只能做辅助，不能做替代。

按这个标准，我把常见的科研事务分成三档：

这张表里最值得说的是"综述段落初稿"这一行。很多人会把它归到"高可托管"，因为模型写综述段落确实流畅。但问题在于，流畅的段落里往往混着看起来像真的、实际不存在的引用，或者把 A 论文的结论安到 B 论文头上。这类错误在初稿阶段极难发现，等你改到第三稿才察觉，返工成本比一开始自己写还高。所以我的建议是：让 Agent 做"素材整理"——把十篇论文的方法、数据集、指标整理成一张对照表，然后你自己看着这张表写段落。这样既省了整理时间，又不会引入虚假引用。

4. 环境准备与前置条件

接下来进入实操。我们要搭的是一个文献结构化抽取 Workflow：输入是一批已经转成纯文本的论文，输出是每篇论文一条 JSON 记录，包含研究问题、方法、数据集、指标、局限性，以及若干条"原文引用"。最后那个字段是关键，它是我们后面做幻觉检测的依据。

环境要求不复杂，但有几处细节值得注意：

• 操作系统：Linux、macOS 或 Windows 均可，脚本用的是标准库的pathlib，路径分隔符不用操心。
• Python：建议 3.10 及以上，因为代码里用了from __future__ import annotations和较新的类型标注写法。具体版本以你实验室的实际环境为准。
• 依赖管理：用虚拟环境隔离，不要装到系统 Python 里。
• 模型服务：任何提供 OpenAI 兼容接口的服务都可以，接口地址和模型名通过环境变量传入，不写死在代码里。
• 目录结构：输入、输出、日志、提示词、Schema 分开放，这是后面能审计的基础。

先建目录和虚拟环境：

mkdir -p research_agent/{data/papers_text,data/records,logs,prompts,schemas} cd research_agent python3 -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install --upgrade pip

依赖文件requirements.txt内容如下。这里用>=而不是锁定死版本，是为了避免不同环境下装不上；生产或长期项目建议用pip freeze生成锁定文件。

# 文件路径：research_agent/requirements.txt openai>=1.0.0 PyYAML>=6.0 jsonschema>=4.0.0

安装：

pip install -r requirements.txt

密钥通过环境变量传入，不要写进代码、不要提交到 Git。如果你用的是实验室共享服务器，建议把环境变量写进自己的~/.bashrc或者用direnv之类的工具按目录加载，避免被同组同学看到。

export LLM_API_KEY="你的接口密钥" export LLM_MODEL="你的模型名称" export LLM_BASE_URL="你的接口地址"

这里有一条必须强调的安全原则：先确认你所在单位对数据出境、数据外传的规定，再决定哪些文件可以送进外部接口。未发表的实验数据、涉及合作方的材料、受版权保护的论文全文，都不适合直接上传。稳妥的做法是先做脱敏或只送摘要部分，具体边界请以你所在机构的规范为准。

5. 最小可用科研 Agent 的完整实现

这一节给出完整的四份文件：配置文件、输出 Schema、提示词、主脚本。全部可以直接复制运行，改一下路径和字段就能适配你的方向。

5.1 配置文件：把可变部分抽出来

配置文件的作用不只是"方便改"，更重要的是让每次运行都有据可查。半年后你回头看某条记录是怎么生成的，能查到当时的模型、参数、提示词版本，这在写论文方法部分时很有用。

# 文件路径：research_agent/config.yaml agent: name: paper-extractor version: "0.1.0" provider: base_url_env: "LLM_BASE_URL" api_key_env: "LLM_API_KEY" model_env: "LLM_MODEL" params: temperature: 0.2 max_tokens: 1500 timeout_seconds: 60 max_retries: 3 retry_backoff_seconds: 2 paths: input_dir: "./data/papers_text" output_dir: "./data/records" log_dir: "./logs" prompt_file: "./prompts/extract_meta.md" schema_file: "./schemas/paper.schema.json" runtime: concurrency: 3 skip_done: true max_chars_per_paper: 20000

几个参数值得解释。temperature设成 0.2 而不是 0，是因为完全为 0 时部分服务端行为不稳定，0.2 已经足够让输出保持稳定；max_chars_per_paper限制单篇送入的字符数，太长的论文只取前若干段加结论段，避免超出上下文窗口导致截断；skip_done是断点续跑开关，跑一半崩了不用从头再来，这在处理几百篇时会救命。

5.2 输出 Schema：先定结构，再让模型填

这是整个设计里最关键的一步。不要先让模型自由发挥，再想办法解析它的输出。正确顺序是先定义你要什么结构，再用 Schema 去约束和校验。

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "PaperRecord", "type": "object", "required": [ "paper_id", "title", "problem", "method", "dataset", "metrics", "limitations", "quotes", "confidence" ], "properties": { "paper_id": { "type": "string" }, "title": { "type": "string" }, "problem": { "type": "string", "minLength": 10 }, "method": { "type": "string", "minLength": 10 }, "dataset": { "type": "string" }, "metrics": { "type": "string" }, "limitations": { "type": "string" }, "quotes": { "type": "array", "minItems": 1, "items": { "type": "string", "minLength": 10 } }, "confidence": { "type": "number", "minimum": 0, "maximum": 1 } }, "additionalProperties": false }

quotes字段是整个方案的支点。我们要求模型在给出每个结论时，同时给出一段从原文直接摘录的句子。这样后面就能用程序判断这句话是否真的出现在原文里——出现过，说明模型至少是"读到了"；没出现过，这条记录直接标记为可疑。这比任何"请勿编造"的提示词都有效。

5.3 提示词：把约束写进模板

提示词单独存成文件，而不是拼在代码里。这样改提示词不需要动代码，也方便做版本对比。

# 文件路径：research_agent/prompts/extract_meta.md 你是一个文献信息抽取助手。你的任务是从给定的论文正文中，抽取结构化信息。 ## 输出要求 1. 只输出一个 JSON 对象，不要输出任何解释、前后缀、Markdown 代码块标记。 2. 字段必须严格符合给定 Schema，不得增加字段。 3. 所有字段内容必须来自输入文本，不得引入外部知识。 4. 如果某项信息在文本中确实没有，填写 "未提及"，不要猜测。 ## 字段说明 - problem: 论文要解决的核心问题，一句话，不超过 60 字。 - method: 论文提出的主要方法或框架，不超过 80 字。 - dataset: 使用的数据集名称；多个用分号分隔。 - metrics: 主要评价指标名称；多个用分号分隔。 - limitations: 作者在文中明确承认的局限性；若未明确说明，填 "未提及"。 - quotes: 3 条从原文逐字摘录的句子，用于支撑上述结论。必须是原文原句，不得改写、不得翻译、不得拼接。 - confidence: 你对本次抽取准确性的自评，0 到 1 之间的小数。 ## 输入文本 {{PAPER_TEXT}}

注意最后那个{{PAPER_TEXT}}占位符，脚本里会做字符串替换。这种写法比 f-string 更安全，因为论文正文里很可能包含花括号，用 f-string 会直接报错。

5.4 主脚本：批量处理、断点续跑、校验落盘

主脚本负责四件事：加载配置、拼装提示词、调用接口、按 Schema 校验后落盘。代码不算长，但每一段都有明确目的。

# 文件路径：research_agent/run_extract.py from __future__ import annotations import json import logging import os import re import sys import time from concurrent.futures import ThreadPoolExecutor, as_completed from pathlib import Path import yaml from jsonschema import Draft202012Validator from openai import OpenAI def load_config(config_path: str) -> dict: with open(config_path, "r", encoding="utf-8") as f: cfg = yaml.safe_load(f) provider = cfg["agent"]["provider"] cfg["_resolved"] = { "api_key": os.environ.get(provider["api_key_env"], ""), "model": os.environ.get(provider["model_env"], ""), "base_url": os.environ.get(provider["base_url_env"], ""), } missing = [k for k, v in cfg["_resolved"].items() if not v] if missing: raise SystemExit(f"缺少环境变量或值为空: {missing}") return cfg def setup_logger(log_dir: Path) -> logging.Logger: log_dir.mkdir(parents=True, exist_ok=True) logger = logging.getLogger("paper-agent") logger.setLevel(logging.INFO) if logger.handlers: return logger fmt = logging.Formatter("%(asctime)s [%(levelname)s] %(message)s") fh = logging.FileHandler(log_dir / "run.log", encoding="utf-8") fh.setFormatter(fmt) sh = logging.StreamHandler(sys.stdout) sh.setFormatter(fmt) logger.addHandler(fh) logger.addHandler(sh) return logger def strip_code_fence(text: str) -> str: """模型偶尔会包一层 ```json，这里兜底剥掉。""" text = text.strip() m = re.match(r"^```(?:json)?\s*(.*?)\s*```$", text, flags=re.S) return m.group(1) if m else text def call_llm(client: OpenAI, model: str, prompt: str, params: dict, logger) -> str: retries = params.get("max_retries", 3) backoff = params.get("retry_backoff_seconds", 2) last_err = None for attempt in range(1, retries + 1): try: resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": "你是一个严谨的文献信息抽取助手。"}, {"role": "user", "content": prompt}, ], temperature=params.get("temperature", 0.2), max_tokens=params.get("max_tokens", 1500), timeout=params.get("timeout_seconds", 60), ) return resp.choices[0].message.content or "" except Exception as exc: # noqa: BLE001 last_err = exc logger.warning("第 %d 次调用失败: %s", attempt, exc) if attempt < retries: time.sleep(backoff * attempt) raise RuntimeError(f"调用失败，已重试 {retries} 次") from last_err def build_prompt(template: str, paper_text: str, max_chars: int) -> str: text = paper_text[:max_chars] return template.replace("{{PAPER_TEXT}}", text) def process_one( txt_path: Path, cfg: dict, client: OpenAI, template: str, validator: Draft202012Validator, logger: logging.Logger, ) -> tuple[str, bool, str]: paper_id = txt_path.stem out_path = Path(cfg["paths"]["output_dir"]) / f"{paper_id}.json" if cfg["runtime"].get("skip_done", True) and out_path.exists(): return paper_id, True, "已存在，跳过" paper_text = txt_path.read_text(encoding="utf-8", errors="ignore") if len(paper_text.strip()) < 200: return paper_id, False, "正文过短，可能转换失败" prompt = build_prompt( template, paper_text, cfg["runtime"].get("max_chars_per_paper", 20000), ) raw = call_llm( client, cfg["_resolved"]["model"], prompt, cfg["agent"]["params"], logger, ) try: data = json.loads(strip_code_fence(raw)) except json.JSONDecodeError as exc: return paper_id, False, f"JSON 解析失败: {exc}" data["paper_id"] = paper_id data["_meta"] = { "agent_version": cfg["agent"]["version"], "model": cfg["_resolved"]["model"], "prompt_file": cfg["paths"]["prompt_file"], "source_file": txt_path.name, } errors = sorted(validator.iter_errors(data), key=lambda e: e.path) if errors: msg = "; ".join(f"{list(e.path)}: {e.message}" for e in errors[:3]) return paper_id, False, f"Schema 校验失败: {msg}" out_path.parent.mkdir(parents=True, exist_ok=True) out_path.write_text( json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8", ) return paper_id, True, "ok" def main() -> None: config_path = sys.argv[1] if len(sys.argv) > 1 else "config.yaml" cfg = load_config(config_path) logger = setup_logger(Path(cfg["paths"]["log_dir"])) template = Path(cfg["paths"]["prompt_file"]).read_text(encoding="utf-8") schema = json.loads(Path(cfg["paths"]["schema_file"]).read_text(encoding="utf-8")) validator = Draft202012Validator(schema) client = OpenAI( api_key=cfg["_resolved"]["api_key"], base_url=cfg["_resolved"]["base_url"], ) input_dir = Path(cfg["paths"]["input_dir"]) txt_files = sorted(input_dir.glob("*.txt")) if not txt_files: raise SystemExit(f"{input_dir} 下没有找到 .txt 文件") logger.info("待处理文件数: %d, 模型: %s", len(txt_files), cfg["_resolved"]["model"]) ok, fail = 0, 0 with ThreadPoolExecutor(max_workers=cfg["runtime"].get("concurrency", 3)) as pool: futures = { pool.submit( process_one, p, cfg, client, template, validator, logger ): p for p in txt_files } for future in as_completed(futures): path = futures[future] try: paper_id, success, msg = future.result() except Exception as exc: # noqa: BLE001 fail += 1 logger.error("[%s] 异常: %s", path.stem, exc) continue if success: ok += 1 logger.info("[%s] %s", paper_id, msg) else: fail += 1 logger.error("[%s] %s", paper_id, msg) logger.info("完成: 成功 %d, 失败 %d", ok, fail) if __name__ == "__main__": main()

代码里有几处设计是刻意为之。第一，Schema 校验放在落盘之前，不通过就不写文件，避免脏数据混进结果集。第二，_meta字段记录了模型和提示词版本，将来复现或写方法部分时能查到。第三，并发数默认 3，不是越高越好，多数接口有速率限制，并发拉太高反而全是 429 错误。第四，异常分两级处理，单篇失败不中断整批，这在跑几百篇时非常必要。

5.5 校验脚本：检查模型有没有在胡说

这一步很多人会跳过，但它才是让"80% 托管"变得可接受的关键。校验脚本做三件事：必填字段是否为空、置信度是否过低、quotes里的句子是否真的出现在原文中。

# 文件路径：research_agent/validate.py from __future__ import annotations import json import re import sys from pathlib import Path def normalize(text: str) -> str: """去掉空白和常见标点差异，降低误判。""" text = text.replace("\u3000", " ") text = re.sub(r"\s+", "", text) text = re.sub(r"[，。；：、,.;:!?！？\"'“”‘’]", "", text) return text.lower() def main() -> None: config_path = sys.argv[1] if len(sys.argv) > 1 else "config.yaml" import yaml with open(config_path, "r", encoding="utf-8") as f: cfg = yaml.safe_load(f) input_dir = Path(cfg["paths"]["input_dir"]) output_dir = Path(cfg["paths"]["output_dir"]) total, suspicious, missing = 0, 0, 0 report_lines = [] for rec_path in sorted(output_dir.glob("*.json")): total += 1 data = json.loads(rec_path.read_text(encoding="utf-8")) paper_id = data.get("paper_id", rec_path.stem) src = input_dir / f"{paper_id}.txt" if not src.exists(): missing += 1 report_lines.append(f"[原文缺失] {paper_id}") continue source_norm = normalize(src.read_text(encoding="utf-8", errors="ignore")) quotes = data.get("quotes", []) or [] hit, miss = 0, 0 for q in quotes: if normalize(q) and normalize(q) in source_norm: hit += 1 else: miss += 1 confidence = float(data.get("confidence", 0)) flags = [] if miss > 0: flags.append(f"引用未命中 {miss} 条") if confidence < 0.5: flags.append(f"置信度低 {confidence}") if data.get("limitations") == "未提及": flags.append("局限性缺失") if flags: suspicious += 1 report_lines.append(f"[可疑] {paper_id}: " + "; ".join(flags)) summary = ( f"总计 {total} 条记录，可疑 {suspicious} 条，" f"原文缺失 {missing} 条" ) print(summary) print("-" * 50) for line in report_lines: print(line) (output_dir / "_validate_report.txt").write_text( summary + "\n" + "\n".join(report_lines), encoding="utf-8", ) if __name__ == "__main__": main()

这里的比对逻辑做了归一化处理：去掉所有空白和常见标点，转小写后再做子串匹配。原因是模型摘录时经常会漏掉一个空格、把中文逗号写成英文逗号，直接用原文比对会产生大量假阳性。归一化之后，只要句子主干一致就能命中。

需要说清楚的是，这个校验只能证明"这句话在原文里出现过"，不能证明"它支撑了你给出的结论"。也就是说它能抓出纯粹的编造，抓不出"引用正确但用错地方"。后一种错误仍然需要人工抽检，这也是我坚持 80/20 而不主张全自动的原因。

6. 运行、验证与人工复核

准备好输入文件和上述四份文件后，运行方式很直接。先把 PDF 转成纯文本放进data/papers_text，文件名就是paper_id，比如2023_xxx_method.txt。

cd research_agent source .venv/bin/activate python run_extract.py --config config.yaml

成功时终端会输出类似这样的日志：

2024-01-01 10:00:00 [INFO] 待处理文件数: 12, 模型: your-model 2024-01-01 10:00:18 [INFO] [2023_xxx_method] ok 2024-01-01 10:00:19 [INFO] [2023_yyy_survey] ok 2024-01-01 10:00:20 [ERROR] [2024_zzz_bad] Schema 校验失败: ['metrics']: '未提及' is too short 2024-01-01 10:00:21 [INFO] 完成: 成功 11, 失败 1

单条记录的输出长这样：

{ "paper_id": "2023_xxx_method", "title": "An Example Paper Title", "problem": "现有方法在长尾分布下召回率下降明显。", "method": "提出两阶段重采样框架，结合对比学习增强尾部类别表示。", "dataset": "DatasetA; DatasetB", "metrics": "Recall@10; NDCG@5", "limitations": "作者指出在极端稀疏场景下提升有限。", "quotes": [ "we observe a significant drop in recall under long-tailed settings", "our two-stage resampling framework improves tail class representation", "improvements are limited in extremely sparse scenarios" ], "confidence": 0.82, "_meta": { "agent_version": "0.1.0", "model": "your-model", "prompt_file": "./prompts/extract_meta.md", "source_file": "2023_xxx_method.txt" } }

然后跑校验：

python validate.py --config config.yaml

预期输出：

总计 11 条记录，可疑 2 条，原文缺失 0 条 -------------------------------------------------- [可疑] 2024_aaa_study: 引用未命中 1 条 [可疑] 2024_bbb_review: 置信度低 0.4; 局限性缺失

怎么判断整批运行是成功的？我的标准是三条：Schema 通过率高于 95%、引用命中率高于 90%、可疑记录能被人工逐条解释。如果命中率明显偏低，第一步应该去看被标记的那几条的原文，判断是模型编造，还是你的归一化逻辑把正常引用误杀了——后者更常见，尤其是原文里有大量公式或特殊符号时。

如果运行失败，排查顺序建议是：先看logs/run.log里的错误类型；再看是接口问题（401/429/超时）还是数据问题（JSON 解析失败、Schema 不通过）；最后看输入文件本身是否转换质量太差。多数"模型输出乱七八糟"的问题，根源其实在 PDF 转文本这一步——页眉页脚、双栏错行、公式乱码都会让模型彻底迷失。

人工复核不需要逐条看，抽 10% 就够了，但要覆盖不同类型：方法类论文、综述类论文、实验类论文各抽几篇。重点核对method和limitations两个字段，这两个最容易出现"模型自己补全"的情况。

7. 常见问题与排查思路

实际跑起来会遇到的坑，基本集中在下面这些。

表格里最后一行是个小细节但很烦人：默认的json.dumps会把中文转成\u4e2d\u6587这种形式，文件能读但没法直接看。加上ensure_ascii=False就能正常显示，同时记得指定encoding="utf-8"，否则在 Windows 上会出编码错误。

8. 最佳实践：让 Agent 可复现、可审计、可回滚

前面讲的是"怎么跑通"，这一节讲"怎么长期用不出事"。对一个要陪你三五年的科研工作流来说，这部分的权重其实更高。

第一，提示词要版本化。不要直接在原文件上改，而是保留extract_meta_v1.md、extract_meta_v2.md，配置文件里指定用哪一版。原因很简单：你换了提示词之后，新抽出来的数据和三个月前那批不可比，如果没记录版本，后面做对比分析时会一头雾水。这一点在写论文的实验设置部分时尤其重要。

第二，中间产物必须落盘。包括原始文本、模型原始返回、校验后的 JSON、运行日志。占空间不多，但价值极大。我曾见过有人跑完一批抽取，两个月后发现某个字段定义理解错了，想重新处理，结果原文文本已经被覆盖，只能重新下载重新转换，几百篇的工作量白做。只要中间结果还在，重跑只是改个提示词的事。

第三，把"可验证"写进设计里，而不是写进提示词里。"请不要编造"这句话的效果非常有限。真正有效的是结构约束：要求给原文引用、要求置信度自评、要求字段缺失时填固定占位符、要求输出必须过 Schema。这些是程序能检查的，提示词是模型可以忽略的。

第四，成本要有预算意识。批量处理几百篇论文，按字符数计费的话开销不小。几个降低成本的惯用做法：先做一轮轻量筛选（只看标题和摘要判断是否相关），再对相关论文做全文字段抽取；把重复出现的提示词前缀做缓存（多数服务支持提示词缓存，能显著降低重复部分的费用）；对已经处理过的文件严格跳过。这些在配置里都有对应开关，别嫌麻烦。

第五，明确数据边界。这一条我放在最后但优先级最高。哪些文件可以送外部接口，哪些必须本地处理，最好在项目开始时就写成一个简单的判断清单贴在工作区。涉及合作方数据、未公开实验结果、专利申请相关材料时，宁可不自动化，也不要冒险。合规的成本远低于事后补救的成本。

第六，给自己留一个"完全手工"的对照集。挑 20 篇论文，自己完整读一遍并手工填一遍字段，然后和 Agent 的输出对比。这个对照集的价值在于：它是你判断"Agent 到底靠不靠谱"的唯一客观依据，也是后续调提示词时的回归测试集。没有对照集，你所有的"感觉效果不错"都是主观印象。

9. 从单点工具到研究工作流

把上面这套跑通之后，你会发现真正的收益不在"省了整理文献的时间"，而在于你的知识开始结构化了。几十篇论文变成几十条统一字段的记录，你可以直接按方法类型筛选、按数据集分组、按指标排序，写综述时不再需要在十几个 PDF 之间来回翻。这个变化是质变，不是量变。

再往前走一步，可以把这套思路复制到其他环节。实验日志用同样的方式结构化：定义 Schema（实验编号、参数、指标、异常现象），写个脚本从日志文件里抽，落盘成 JSON，然后周报和组会 PPT 可以直接从这些 JSON 生成初稿。代码调试记录同理：把报错信息、定位过程、解决方案存成结构化条目，半年后遇到同类问题直接检索。

但要始终记住那条边界：Agent 负责把信息从一种形式变成另一种形式，人负责判断这些信息意味着什么。前者可以做到 80% 甚至更高，后者一旦交出去，出问题的时候你连自己错在哪都不知道。我见过太多人用 AI 生成了看起来很漂亮的综述段落，投出去被审稿人指出引用不存在，那种返工的代价，远比一开始自己花两天整理素材要大。

如果你打算这周就开始动手，我的建议是从最小的一步切入：挑一个你手头正在处理的、十篇左右的小批量文献，把 Schema 定出来，把提示词写出来，跑一遍，看看validate.py报了多少可疑记录。那个数字会直接告诉你，你的工作流还差哪一环。