AI 写论文，你敢用吗？Google 用 CoE 给结论上证据链

🙋‍ 我是 Luhui Dev，一个长期拆解 Agent 工程、探索 AI 教育落地的开发者。关注 Agent Harness、LLM 应用工程、AI for Math 与教育 SaaS 产品化实践。

AI 写出一篇科研论文，你敢用吗？

想象一下。

你把一个科研问题交给 AI：寻找一种降低大模型推理成本的新方法。

几个小时后，它返回一篇完整论文、一套实验代码、一组 Benchmark 数据，以及一个看起来很新的算法。

论文结构完整，图表漂亮，实验结果也很惊艳：推理速度提升 35%。

问题来了：你相信吗？

你可能会先打开代码，确认里面是不是真的实现了论文描述的方法；再检查实验日志，看看 35% 是实际跑出来的，还是模型从某次中间实验里挑出来的；最后还要逐条核对引用，确认那些名字很像真的论文确实存在。

然后你发现代码里没有那个算法、实验结果也无法复现，甚至引用的论文都查不到。

最尴尬的是，这篇论文读起来依然可能非常专业。

ScientistOne 想解决的，不是让 AI 更会写论文

2026 年 5 月，Google Cloud AI Research 团队发布了一篇 arXiv：ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence。

这项工作的重点并不只是再做一个更强的 AI Scientist它，它更关注的是如何让 AI 生成的研究可以被审计。

论文团队审计了 5 个自动研究系统在 5 类前沿系统研究任务中生成的 75 篇论文。结果很有意思：

• 有的系统，虚假引用比例达到 21%；
• 有的系统，论文分数重新验证后的通过率只有 42%；
• 不同系统的方法与代码一致率只有 20% 到 80%。

换句话说，一篇论文可能写得很好，算法也可能真的跑出了不错的结果，但论文里的数字、方法、代码和引用并不一定属于同一条事实链。

这有点像一个程序员交付了漂亮的技术文档、完整的测试报告和一份能运行的代码，唯一的问题是：三者写的不是同一个系统。

ScientistOne 给出的核心方案叫：Chain-of-Evidence（CoE）证据链

它的基本就是每一个重要 Claim，都必须能够沿着一条被记录的证据链，回到它的原始依据。

从"生成答案"到"生成可验证的知识"

普通 Agent 的输出过程通常是：

用户问题 -> Agent 执行 -> 最终答案

比如它告诉你：新算法让准确率提升了 10%。到这里任务就结束了。

而 CoE 关心的不是这句话够不够像结论，而是它后面有没有一条完整链路：

Claim：准确率提升 10%
  ↓
Evidence：evaluation log 中的指标
  ↓
Artifact：评测脚本、训练代码、数据版本
  ↓
Grounding Source：真实实验运行结果
  ↓
Verification：重新运行并计算指标

所以 CoE Agent 最终交付的，不应该只是一段文本，而是一个可以被审查的知识单元。

别人不需要因为它"说得很像真的"而相信它。

别人可以顺着证据链，自己去检查它是不是真的。

CoE 怎么工作：先给研究中的 Claim 分类

论文把科学声明分成四类：

Citation Claim       引用声明
Numerical Claim      数值声明
Methodological Claim 方法声明
Conclusion Claim     结论声明

不同 Claim，需要不同的证据。

如果 AI 说"某篇研究提出了某个方法"，它需要关联到真实存在、实际读取过的论文。

如果 AI 说"准确率提升 10%"，它需要关联到评测输出和实验日志。

如果 AI 描述了一种新的 Attention 优化方法，它需要关联到代码中真正实现该方法的模块。

如果 AI 得出一个研究结论，它需要明确依赖哪些已经被验证的数值声明和方法声明。

这一步看起来只是把自然语言结构化，实际上非常关键。

因为"我们的方法效果很好"没有办法直接验证，但下面这个声明可以：

{
  "type": "numerical",
  "claim": "模型准确率由 81.2% 提升到 89.4%",
  "evidence": "runs/exp_042/evaluation.log#L118",
  "metric": "top-1 accuracy"
}

只有 Claim 被结构化，验证才有明确的对象。

ScientistOne 不是最后再补引用，而是从一开始就记录证据

这是我觉得 ScientistOne 最值得关注的地方。

很多 Agent 设计会在论文快写完时，再让另一个 Agent 检查引用、修数字、补证据。

这很像代码上线前一天才开始补测试：不是完全没用，但大量上下文已经丢了，最后只能靠猜。

ScientistOne 的思路是让证据跟着研究过程一起产生。

它的系统大致分成三段：

Problem Investigator
文献检索、全文阅读、生成有来源的研究简报

        ↓

Discovery Engine
并行探索方案、运行实验、保留评测结果与日志

        ↓

Paper Writer + Claim Verifier
基于已有产物写作，并逐条验证 Claim

在文献阶段，它从学术数据库检索论文，阅读完整 PDF，并记录来源信息。

在实验阶段，它把代码、Evaluator 分数、执行日志和消融实验结果一起保存。

在写作阶段，每个带有数字或引用的句子，都要提前绑定具体证据。Claim Verifier 再检查论文里的数字能不能在日志中找到、引用是否支持原句、方法描述是否与实验记录一致。

没有来源，或者证据标记不合法的 Claim，会被直接删除。

这不是让 AI 在答案后面随手贴几个链接。

它是在研究发生的同时，建立一份可以回放、可以检查的证据账本。

Verification，而不只是 Provenance

记录来源并不等于完成验证。

一个文件存在，不代表里面的数据正确。

一篇论文真实存在，也不代表它支持当前这句话。

一段代码能够运行，更不代表它实现了论文声称的方法。

所以 ScientistOne 还设计了一套 CoE Integrity Audit，专门检查四类问题：

Score Verification
论文报告的分数能否重新跑出来

Specification Violation
方案是否钻了评测规则的空子

Reference Verification
引用是否真实存在

Method-Code Alignment
论文描述的方法是否真的出现在代码里

按照项目公开的数据，ScientistOne 在这组实验中实现了：

• 337 条参考文献中，虚假引用为 0；
• 12 篇可重复评测的论文，分数验证全部通过；
• 15 篇论文中，14 篇通过方法与代码一致性检查。

这些数据来自论文团队自己的实验，当前论文也还是预印本，因此不应该直接理解成"AI 自动研究已经可靠"。

但它至少说明了一个很重要的方向，可靠性不能只靠模型自觉，必须被做成系统中的检查机制。

这和软件工程很像，代码不能因为开发者说"我觉得没问题"就上线。

AI 生成的研究，也不能因为语言通顺、图表漂亮就自动获得信任。

CoE 和 RAG 到底有什么区别？

看到这里，很多人可能会问：这不就是 RAG 加引用吗？

不完全是。

RAG 主要解决模型去哪里找外部知识？

CoE 主要解决模型生成的这个 Claim，如何被证明？

RAG：
Document → Retrieval → Answer

CoE：
Claim → Evidence → Artifact → Verification

RAG 可以给模型提供真实文档，也可以帮助答案附上引用，但它不天然保证：

• 引用真的支持当前 Claim；
• 论文中的数字来自实际运行结果；
• 方法描述和提交代码一致；
• 最终结论能沿着中间产物回溯。

因此 CoE 不是 RAG 的替代品。

它更像是加在 RAG、工具调用、代码执行和论文写作之上的一层可信度基础设施。

我对此的总结是，

RAG 解决资料从哪里来。

CoE 继续追问结论凭什么成立。

写在最后

过去几年，我们一直在解决如何让模型知道更多。

所以有了 RAG、Vector Database、Knowledge Graph 和更长的上下文。

现在 Agent 开始自己搜索、写代码、跑实验、生成报告，新的瓶颈出现了：它不仅要给出结果，还要保留结果是如何产生的。

ScientistOne 和 Chain-of-Evidence 的价值，不是又造出了一个更会写论文的 AI，而是把 AI 研究的评价标准往前推了一步。从结果像不像真的，走向结论能不能被验证。

这可能也是 Agent 进入真实世界必须补上的一课。可信并不意味着它永远正确，而是当它出错时，我们能够沿着证据找到问题；当它正确时，我们也不必只凭感觉相信。

真正值得信任的 Agent，不只是会给出答案，还要让人随时能够检查：它为什么正确，又可能错在哪里。

---

参考资料

• ScientistOne 论文（arXiv）
• ScientistOne 项目主页