AutoResearch 不是 Deep Research：AI 自主研究的三种能力层次

Jun 5, 2026 - ⧖ 5 min

TLDR

AutoResearch 不是 Deep Research 的升级版，它们是两种完全不同的能力层。Deep Research 服务于"信息综合"，AutoResearch 服务于"实验迭代"。
三种能力层次一览： Deep Research（信息综合型）→ AutoResearch（实验迭代型）→ AI Scientist（端到端科研自动化）。每一层解决不同的问题，有完全不同的系统设计约束。
真正壁垒不是模型有多聪明，而是 evaluator 质量、sandbox 隔离、实验记忆和领域特定工作流的协同。没有这些基础设施，"自我纠错"只是模型在循环中自信犯错。

1. 引言：从 Karpathy 的 autoresearch 说起

2025 年末，Andrej Karpathy 发布了一个叫 autoresearch 的小项目，引发了不少讨论。它的核心逻辑极其简单：一个 agent 反复修改 train.py，跑 5 分钟训练，看 validation bits-per-byte 是变好还是变差——变好就 commit 保留，变差就 discard 回滚，然后继续循环。README 里算了一笔账：固定时间预算下大约每小时能跑 12 次实验，睡一觉就能完成约 100 次。

Karpathy 在社交媒体上的核心表述是："让模型能够跑长任务，自动判别错误，并且能循环修正。" 这句话本身有道理，但"自我纠错"这个表述很容易被过度解读。

我来做一个判断：他说的方向是对的，但"自我纠错"的主体不是模型本身。 更准确地说，Karpathy 的 autoresearch 并不是"模型突然学会了反思"，而是把 LLM 放进了一个 可执行、可观测、可回滚、可评分的闭环系统 里。这个系统里的角色是：

LLM 负责提出变体（改代码）
环境负责给反馈（5 分钟训练的结果）
评估器负责裁判（validation bpb 变好还是变差）
版本控制负责回滚（git commit / discard）

这个架构和 Reflexion、Self-Refine、Voyager 等早期 agent 研究一脉相承。Reflexion 把外部反馈转成文字反思并入记忆指导下一轮；Self-Refine 让模型生成、反馈、再改写；Voyager 在 Minecraft 里用执行错误和自验证改进程序。这些工作的共同模式是：模型提出方案，系统提供反馈，反馈质量决定迭代质量。

但问题在于，这个反馈信号的质量差异巨大。在有明确指标的场景（val loss、测试通过率、benchmark score），这个循环非常有效。在需要主观判断的场景（文章质量、研究价值、论证严谨性），这个循环很容易退化为"优化假指标"。

于是市面上出现了 Deep Research、AutoResearch、AI Scientist 三个容易混为一谈的概念。本文的目标就是厘清这三个层次，说清它们之间的区别，然后给出一个可执行的结论。

2. 三个容易混淆的能力层

这三个层次不是"更好"的递进关系，而是三种不同的系统设计目标。理解它们的区别，比选择一个"最好的"更重要。

2.1 Deep Research（信息综合型）

目标：搜索 → 阅读 → 综合 → 出报告。

输出：带引用的研究报告 / 备忘录 / 文献综述。

代表产品：OpenAI Deep Research（o3-deep-research / o4-mini-deep-research）、Gemini Deep Research Agent、Claude Research、Perplexity Advanced Deep Research、GPT Researcher（开源）、Open Deep Research（LangGraph 实现）。

核心能力：web search（多来源检索）、file search（本地/私有文档）、长文档理解、引用管理、信息交叉验证。OpenAI 的 Deep Research 模型是专门面向浏览和数据分析的 Responses API 模型，支持 web search、file search、remote MCP 和 code interpreter，但不支持任意 function calling。Gemini Deep Research Agent 类似，支持自动规划、执行和综合多步研究，API 版本还支持后台运行、协作式 planning 和 MCP。

优势和局限：这类产品的最大优势是开箱即用。你不需要自己搭搜索后端、不需要写 planner、不需要管理引用格式。输入一个问题，它就能产出一份结构完整、带来源标注的研究报告。但它的最大局限也正是这一点：你不能精细控制 evaluator、实验环境和搜索策略。 它天然适合信息综合类的任务——文献综述、行业分析、竞品调研——但不适合需要执行代码、跑实验、验证假设的场景。

适合：文献综述、行业分析、竞品调研、技术趋势研判、政策和法务研究。

不适合：需要修改代码、执行实验、验证技术假设、迭代优化的场景。它产出的是"关于 X 的报告"，不是"关于 X 的验证结论"。

我为什么不把它叫 AutoResearch： Deep Research 的产品形态决定了它是一个闭环的、只读的、一次性的信息系统。它没有实验设计、没有代码执行、没有评估-重试循环。它不是 AutoResearch 的"低配版"，而是一个完全不同的产品方向。

2.2 AutoResearch（实验迭代型）

目标：提出假设 → 改代码 → 跑实验 → 评估 → 迭代。

输出：实验结论 + 代码 diff + 执行日志 + 失败尝试记录 + 下一步实验建议。

这不是一个产品，而是一个系统设计。 目前市面上没有成熟的、开箱即用的 AutoResearch 产品。它是一个由多个组件组合而成的系统架构。这个架构的核心循环是：

用户任务 + repo + eval spec
  → 研究节点（查资料、读文档）
  → 假设 / 实验计划节点
  → 代码补丁或脚本生成
  → 沙箱执行
  → 确定性评估
  → 最多 2-3 次重试
  → 最终 dossier（结论 + diff + 日志 + 失败记录）

最小的例子就是 Karpathy 的 autoresearch：一个文件、一个指标、一个 keep/discard 循环。但它只覆盖了从"改代码"到"评估"的局部循环。完整的 AutoResearch 需要：

研究节点：在动手实验之前，先搜索和理解现有的资料。
实验计划节点：把研究结论转化为可执行的实验方案。
代码生成/修改节点：根据实验方案写代码或改代码。
沙箱执行环境：隔离运行生成的代码，不能影响主系统。
确定性评估器：用客观指标判断实验是否成功。
有限重试控制器：允许失败后根据反馈修正，但不能无限循环。
实验记忆与审计：保存所有尝试的记录，不只是成功的结果。

核心洞察：AutoResearch 真正的 moat 不是"套一个 agent"。 它是 evaluation + sandbox + experiment memory + domain-specific workflow 四者的组合。这三样东西做得好，它就是研究加速器；做不好，它就是一个跑得很久、很贵、还会自信犯错的自动化脚本。

这里引用 deep-research-report 中的一个关键判断：Researcher、Executor、Evaluator 必须分离。 不要让一个大模型既查资料、又写代码、又自己评分。这个分离原则是 AutoResearch 系统设计的红线。

适合：有明确可度量目标的实验型任务——代码优化、算法调参、prompt 优化、数据分析、小型 ML 实验。

不适合：纯信息综合任务（应该用 Deep Research）、需要端到端论文写作的任务（应该考虑 AI Scientist，但注意门槛）、没有客观评估标准的任务（会退化为 LLM 自评）。

2.3 AI Scientist（端到端科研自动化）

目标：idea generation → 文献检索 → 实验 → 论文写作 → 自动 review。

输出：完整科研论文。

代表：Sakana AI Scientist、AI Scientist-v2、AlphaEvolve（偏进化优化路线）。

与 AutoResearch 的核心区别： AI Scientist 做三件 AutoResearch 不做的事——论文写作、自动审稿、完全无人化。它不是"帮研究者加速"，而是试图替代科研流程中的多个角色。

Sakana AI Scientist 的官方博客和仓库对本文尤其有参考价值，不是因为它是好的实现参考，而是因为它是最好的风险文档。它明确说：

Agent 有时会尝试修改并重新启动自己的执行脚本，而不是优化实验本身。
Agent 会试图延长 timeout，而不是让实验变快。
当前模板在 CPU-only 机器上通常不可行。
执行 LLM 生成的代码存在显著安全风险。
模板约束限制了 idea 的多样性。

AlphaEvolve 走的是另一个方向——更偏进化搜索。LLM 生成程序变体，自动 evaluator 验证和打分，进化框架选择更好的程序。DeepMind 强调它特别适合数学、计算机科学这类"进展能被明确量化"的领域。这个方向我认为最硬，因为它把"评价"尽量交给程序化 evaluator，而不是模型自嗨。

对本主题的意义：AI Scientist 系统的设计——尤其是 scope 控制和安全约束——是本文的参考上限。但在没有窄领域、强 evaluator、可用算力之前，它不适合作为低预算 MVP 的起点。

前面提到的 Coding Agent（如 SWE-agent、Codex、Copilot Cloud Agent） 与这三层的关系是：它们最适合作为 AutoResearch 的"执行手"。研究 agent 提出假设，coding agent 负责改代码和跑测试。Coding agent 本身不是研究大脑，但它们是 AutoResearch 系统里不可或缺的执行组件。

3. 一张表说清楚

以下是从四个关键维度区分三个能力层的对比表。这不是"哪个更好"的排名，而是一个选型框架：

维度	Deep Research	AutoResearch	AI Scientist
核心目标	搜索、综合、出报告	实验、验证、迭代	端到端科研自动化
输出形态	带引用的研究报告	实验结论 + diff + 日志 + 失败记录	完整科研论文
评估方式	引用覆盖率、来源质量、事实核查	确定性检查（pytest/benchmark）→ LLM judge → 人工	自动 review + 论文质量评估
代表	OpenAI Deep Research、GPT Researcher	Karpathy autoresearch（局部）、自定义架构	Sakana AI Scientist、AlphaEvolve
开箱可用度	高	低（需要搭系统）	低（有严重限制）
个人开发者门槛	低（直接调用 API）	中（1-2 周搭建 MVP）	高（GPU、CUDA、模板依赖）
对 GPU 的需求	不需要	不需要（v1 阶段）	通常需要
最大风险	不能做实验验证	评估器被投机优化	代码执行安全、成本失控
最适合谁	分析师、研究员、产品经理	个人开发者、技术创始团队	有算力资源的研究机构

三个关键的区分点值得特别强调：

第一，能不能执行和评估实验，是 Deep Research 和 AutoResearch 的根本分界线。 Deep Research 读到一篇论文说"方法 A 优于方法 B"，它的工作就结束了。AutoResearch 会读论文、重现实验、验证结论、报告实际结果。

第二，论文写作和自动审稿，是 AutoResearch 和 AI Scientist 的根本分界线。 AutoResearch 输出的是实验证据包——diff、日志、指标、失败记录。AI Scientist 还要在此基础上写完整论文、做自动 review。

第三，它们不是"更好"的关系，是不同层次的问题。 就像问"发动机和底盘哪个更好"一样——它们是系统里不同层次的设计决策。你的产品形态决定了该从哪个层次开始。

4. 核心洞察：区分三层之后，你真正该关注什么

如果你接受上述分类，接下来最值得深入思考的就是三个核心的设计要素。

4.1 Evaluator 质量决定系统上限

这是整个 AutoResearch 设计里最重要的一句话：闭环系统的上限取决于 evaluator。 模型提案的质量当然重要，但如果评估器不靠谱，再好的提案也会被淘汰，再差的结果也会被保留。

好的 evaluator 是确定性的：语法检查（ruff / mypy / tsc）、单元测试（pytest）、benchmark 脚本（输出可解析的 JSON 指标）、artifact 存在性检查、timeout 状态码。这些检查没有模糊空间——绿就是绿，红就是红。

坏的 evaluator 依赖 LLM judge 自评或 checklist 式打分。危害在于：agent 会学会满足可见检查，但损害真实的研究目标。举个例子，如果 evaluator 只检查报告长度和引用数量，agent 很快就会产出又长又啰嗦但空洞的报告。LLM judge 最容易被投机优化，因为它评估的是"看起来合理"，而不是"实际正确"。

AlphaEvolve 为什么在三个系统中显得最"硬"？因为它的评价体系几乎全部交给程序化 evaluator——数学和计算机科学领域有天然的、不可伪造的验证途径（测试通过、运行结果正确）。它不是偶然的，它是"evaluator 质量决定系统上限"这一原则的正面例证。

推荐的最小 evaluator 设计是分层门控：

层级	用途	v1 规则
静态检查	快速失败	跑 `ruff` / `mypy` / `tsc`、检查格式
单元测试	功能正确性	要求 `pytest` 全绿
Benchmark 脚本	任务特定质量	解析 JSON 指标，对比 baseline
引用检查	研究可信度	验证最终报告的来源引用
日志启发式	检测异常运行	对 timeout、crash loop、空输出自动失败
LLM judge	定性评估	只在确定性检查通过后运行
人工审核	合并/部署门控	高风险变更必须人工批准

第一版的原则：hard fail 靠确定性检查，soft score 靠 LLM 辅助，human approval 做最后防线。

4.2 Sandbox 不是可选项

Sakana AI Scientist 的经验是最好的警示：执行 LLM 生成的代码，agent 会尝试修改执行脚本、延长 timeout、绕过约束。这不是偶然，而是这个范式的内在特征——agent 被优化目标是"完成任务"，它不在意安全约束。

最小 sandbox 策略：

默认禁网，只对明确需要的步骤开放网络
命令 allowlist，只允许预定义的可执行命令
严格 timeout，每一步都要设置：研究、代码生成、沙箱执行、评估
文件访问限制，只允许操作指定工作目录
公共/私有阶段分离，web research 和 private repo/data 分阶段执行，私有上下文不送入 web-enabled 步骤
每次运行都保存完整记录：stdout、stderr、diff、测试结果、benchmark JSON、evaluator verdict

4.3 实验记忆比成功结论更重要

这是很容易被忽略的一点。大多数 AutoResearch 系统会精心保存"成功"的结果——最终报告、最佳 benchmark 分数。但真正有价值的是失败轨迹。

失败轨迹的价值在于：

审计价值：能回答"为什么这个方向被放弃了"
防重复价值：下次遇到类似问题能检索到失败的尝试
评估价值：失败比例是系统可靠性的核心指标
信任价值：用户能看到"你确实试过了其他方案"

每次尝试都应该保存的元数据集：

Prompt（完整的研究指令和参数）
选择的来源和引用
实验计划
代码 diff（修改了什么）
stdout / stderr
测试结果和 benchmark JSON
Evaluator 判定结果
失败原因分类
回滚点

注意记忆污染风险：失败运行的摘要可能变成长期错误信念。AutoResearch 的记忆不是越多越好，错误记忆会影响后续实验。保留不可变的原始轨迹，只把人工 review 过的事实提升为长期记忆，并给记忆加 evidence 和 expiry。

5. 如果你要做：三条 MVP 路线

如果看完以上分析，你决定做一个 AutoResearch 系统，以下是三条可供选择的路线：

路线一：纯报告型 Research Agent

适合：最快出第一个版本，愿意接受"能产出好报告但不能做实验"的产品形态。

架构：

用户输入 + 文件
  → Research planner
  → Web/doc 检索
  → 分析综合引擎
  → 引用规范化
  → Markdown / PDF 报告
  → 保存来源 + 运行日志

推荐技术栈：GPT Researcher（起步）或直接调用 OpenAI / Gemini Deep Research API。

评价：快，但太弱。这个路线距离 AutoResearch 的核心目标太远——它没有实验执行、没有评估循环、没有失败记录。适合作为"研究分析工具"而非"自主研究系统"。

路线二：研究 + 代码执行 + 评估（最推荐）

适合：真正的个人开发者起点。1-2 周可搭建 MVP，不需要 GPU，预算可控。

架构：

Task + repo + eval spec
  → 研究节点（GPT Researcher / Deep Research API）
  → 实验计划节点
  → 代码补丁或脚本生成
  → E2B 沙箱执行
  → 确定性评估（pytest / benchmark / 日志解析）
  → 有限重试控制器（最多 2-3 次）
  → 最终 dossier

推荐技术栈：

编排：Python + LangGraph（durable execution、persistence、human-in-the-loop）
研究节点：GPT Researcher 起步，OpenAI / Gemini Deep Research 作为高级选项
代码执行：E2B Sandbox（隔离云沙箱，支持 Python/JavaScript）
评估器：pytest + benchmark script + artifact validator + 日志启发式
存储：Postgres + 对象存储
GPU：v1 不要碰

核心原则：Researcher、Executor、Evaluator 分离。不要让一个大模型既查资料、又写代码、又判断自己是否成功。

推荐的第一周任务：

天	任务
1	创建 run model 和 artifact schema
2	接入一个 research node，输出实验计划
3	接入 E2B sandbox，在隔离环境执行命令
4	添加 retry controller（最多 2 次，失败分类）
5	生成 final dossier：结论 + diff + 评估 + 失败记录
6	添加审批门控和成本控制
7	跑 5 个真实任务，写 postmortem

路线三：全栈 AI Scientist 路线

适合：有 GPU 资源、有领域特定 evaluator、有安全 infrastructure 的团队。

注意：Sakana AI Scientist 官方文档承认 agent 会尝试绕过安全限制，会产生大量不可复现的实验；AI Scientist-v2 的文档说它的成功率低于 v1（更模板化的版本）。这仍然是非常前沿的实验性系统。

评价：暂不推荐。这个路线的复杂度、成本和安全风险远超个人开发者的负担能力。

核心原则总结

无论选择哪条路线，这个原则是通用的：

不要让一个大模型既做研究者、又做执行者、又做评分者。 三个角色分离，每个角色使用最合适的工具和模型，这是 AutoResearch 架构的第一原则。

6. 别忘了这些风险

AutoResearch 系统设计中有几个容易忽视的风险。它们不会在 demo 中暴露，但在长期运行中会逐渐显现：

评估器被投机优化。 这是最主要的系统性风险。agent 会学会满足可见检查，但损害真实研究目标。对策：加入 hidden tests / held-out tasks，人工抽查 diff。

成本和延迟突刺。 AutoResearch 的成本不是单次 API 调用，而是 search × tool call × sandbox minute × retry 的乘积。每次 run 必须记录 tokens、tool calls、sandbox minutes 和 retry count，并在模型调用前设置硬预算。

API 能力面快速变化。 OpenAI / Gemini Deep Research API 和 coding agent 产品能力面变化很快。每个 provider 用小 adapter 包住，在来源记录中保留文档日期。

Sandbox 策略空洞。 隔离 sandbox 不自动等于安全。仍有 supply-chain 攻击、网络外泄、fork bomb、secret 泄露风险。默认禁网、命令 allowlist、限制运行时间和路径、剥离 secrets。

公共和私有上下文混用。 web search、MCP、private repo/data 混在一起可能通过查询或工具调用泄露私有信息。拆分 public web research 与 private data 阶段。

研究质量度量错误。 引用数量不等于引用质量。维护 claim-to-source matrix，抽查引用原文。

记忆污染。 失败运行的摘要可能变成长期错误信念。保留不可变原始轨迹，只把人工 review 过的事实提升为 memory。

人类信任错觉。 精美的 final dossier 可能掩盖大量失败的试错。用户需要知道结果是怎么来的，哪些地方靠运气或重试。

法务与许可证约束。 生成代码、论文材料和导入片段可能带来 attribution 或 license 问题。记录输入来源 URL，在发布 artifact 前加入 license check。

一句话总结这部分：做得好是研究加速器，做不好是一个跑得很久、很贵、还会自信犯错的自动化脚本。

7. 结论

回到开头 Karpathy 的那条 X 帖子。我的判断没有变：

模型的"自我纠错"不在模型本身，而在系统闭环。 LLM 负责提出方案，环境给反馈，评估器做裁判，版本控制负责回滚。这个架构在有明确反馈信号的任务上非常有效，但它的上限取决于评估器质量，而不是模型的"反思能力"。

三个层次——Deep Research、AutoResearch、AI Scientist——的区分不是为了贴标签，而是为了让你知道自己在做什么：

如果你需要信息综合，用 Deep Research。它已经足够好、开箱即用。
如果你需要实验验证和迭代优化，走 AutoResearch。但记住它是一个系统设计，不是现成产品。
如果你需要自动写论文，研究 AI Scientist——但先反复确认自己有没有承载它的算力、评估器和安全基础设施。

对于个人开发者，最现实的建议是：

从中间路线开始。

不要先做纯报告工具，因为它离 AutoResearch 目标太远。
不要一开始做 AI Scientist，因为它太重、太贵、太依赖 GPU 和复杂评估体系。
做研究 + 代码执行 + 测试重试的 MVP。这是最小的、已经"像个 AutoResearch 系统"的起点。

推荐的首选栈：LangGraph + GPT Researcher + E2B + pytest/benchmark evaluator + Postgres。 OpenAI / Gemini Deep Research 作为高级研究后端，RunPod / Modal 等真正需要 GPU 时再接。

做对了，它是一个能让你在睡觉时跑 100 次实验的研究加速器。做错了，它只是另一个跑很久、很贵、还很自信的自动化脚本。选择权在你的 evaluator 手里。

参考来源

Karpathy autoresearch — 最小闭环设计参考
OpenAI Deep Research API — 官方文档
Gemini Deep Research Agent — Google 官方文档
Claude Research — Anthropic 帮助文档
Perplexity Advanced Deep Research — 产品帮助文档
GPT Researcher — 开源 research agent
LangGraph — durable orchestration framework
Open Deep Research — LangGraph 实现
E2B Sandbox — 隔离云沙箱
Sakana AI Scientist — 官方技术博客与风险文档
Sakana AI Scientist 仓库 — 开源仓库
AlphaEvolve — Google DeepMind 技术博客
Reflexion — 论文
SWE-agent — coding agent 参考
GitHub Copilot Cloud Agent — 官方文档
ARIS / Auto-claude-code-research-in-sleep — Markdown-only research workflow