前阵子我在刷信息流的时候，被 Karpathy 在 GitHub 上公开的 AutoResearch 实验报告链接勾住了。本来想着扫一眼就划走，结果一口气读了两遍，又顺着他把他在 X 上关于 "software is changing" 的讨论全部翻了出来。这几年号称“AI 科研助理”“自动科研框架”的东西我见过不少，多数看完就忘，套路都差不多：套一个 agent 框架、接几个 API、拍一个看起来很聪明的 demo。但 AutoResearch 这篇实验报告，让我第一次觉得“自动科研”这四个字被指到了真正的方向上。
这篇文章适合三类人读：正在被文献综述和选题调研折磨的研究生；团队里想引入 AI 辅助研发流程的技术负责人；以及和我一样，一直在关注 LLM 应用范式变化、想弄明白“自然语言驱动的软件”到底长什么样的人。我会把自己读完报告后的拆解、验证过程中的思考，以及顺手搭一个轻量版管线时踩过的坑都写出来，尽量让没有太多工程基础的人也能跟上思路。
1. AutoResearch 实验报告到底做了什么：从一个“小实验”看科研自动化
1.1 报告背景：Karpathy 为什么突然做起了科研智能体
Karpathy 这个人有个很鲜明的习惯：想验证一个大判断的时候，不写宏大的商业计划书，而是直接做一个看上去有点“过于简单”的小实验。从 nanoGPT 到 nanochat，再到这次的 AutoResearch，都是同一套路数。这个实验的核心动机，我觉得是他想验证一句话：LLM 是不是已经强到可以当作“软件的基本执行单元”来用了。
“软件的基本执行单元”这个说法可能有点抽象，换个方式讲。以前写软件，是把所有逻辑分支用代码写死，每一步怎么走、异常怎么处理，都是人在预判。而 AutoResearch 想验证的是：如果你给一个大模型“研究清楚某个方向”这样一个模糊目标，它能不能自己规划路径、自己调用检索、自己整理材料、自己写出一份高质量的分析报告？在外人看来，这只是一个“又智能体了一把”的实验，但在 Karpathy 的表述里，尤其是他反复强调的 "software is changing"，这个实验真正的意义在于软件形态的变化。
我读报告时也确实验证了这个感受：AutoResearch 里真正值钱的不是某个高深的算法，而是那一整套“把模糊目标翻译成确定性流程”的系统设计。回到背景本身，AutoResearch 并不是一个产品级工具，而是一份公开的实验报告。他选择把完整过程、思路和判断都写进报告里，本身就很“Karpathy”——他一直在用这种方式教育大家：大模型时代的科研工作流应该怎么搭、怎么想、怎么判断效果。
1.2 实验的核心流程：从文献图谱到自动综述
报告里展示的实验流程，我把它拆成五步，每一步都很有意思。
第一步，从主题出发自动生成检索词。不是只做一次搜索，而是让模型把一个大主题拆成多个细分角度，再针对每个角度去 arXiv 等文献库拉取候选论文。第二步，构建引用图谱。以论文之间的引用关系为边，把一堆松散的论文变成一张有结构的网络。第三步，基于论文摘要做嵌入向量，然后做主题聚类，让系统自己把文献分成几个子方向。第四步，对每个聚类进行深挖，生成子方向的代表性工作概述、方法脉络和争议点。第五步，把各子方向汇总成一篇结构完整、带引用链接的深度分析报告。
这套流程表面上看是“文献管理工具 + LLM”，但它和传统的文献管理软件有本质区别。传统工具只是帮你存论文、标引用、按关键词过滤；AutoResearch 里 LLM 参与了每一步的判断——检索词是否合理、论文与主题是否真的相关、聚类标签应该怎么总结、子方向内哪些工作是连贯的脉络。这些判断以前必须由人来下，现在模型可以给出一个质量已经足够高的初稿。
需要强调的是，这套实验并没有用复杂的 multi-agent 编排框架。我在报告里看到的更多是基于脚本的顺序管线加 LLM 调用。这其实是 Karpathy 的另一个信号：自动科研的壁垒不在于“把 agent 编排得有多花哨”，而在于“让模型在每个节点都拿到恰好需要的上下文”。
1.3 报告中最让我意外的输出质量
真正让我意外的，是最终输出报告的质感。
以前我看过很多“AI 写综述”的演示，常见的问题是“正确的废话”：大框架面面俱到，细节全是空话，引文常常对不上号。但 AutoResearch 生成的报告，至少在实验展示的样例里，做到了几个关键点：它能指出某个子方向内部不同方法之间的实际差异，能看出方法演进中谁借鉴了谁，甚至会在归纳中表达出“某条路线似乎遇到了瓶颈”这类有判断力的话。
说白了，它不是把摘要搬过来拼一拼，而是有一个“先读透再重构”的过程。那种“有人真正读过了这批论文”的感觉，是绝大多数 AI 综述工具给不了的。当然，我也注意到这份报告的产出依赖不小的 token 消耗。这不是一个零成本系统，它本质上是“用 token 换科研劳动力”。但换个角度看，如果它真的能把一个博士生两个月才能做完的文献调研压缩到几天甚至几小时，那这个成本结构其实非常划算。后面我会专门展开成本和范式的关系。
2. 为什么说“软件正在改变”：AutoResearch 背后的范式转移
2.1 从命令式软件到自然语言驱动软件
理解 AutoResearch 的价值，绕不开 Karpathy 反复讲的那句话：software is changing。软件的定义正在变化，这是理解整个实验的钥匙。
传统软件的逻辑是指令式，本质是“每个分支都写死”。如果你要写一个研究文献的软件，你需要程序员先实现爬取模块、解析模块、去重模块、聚类模块、报告模板模块，再把它们串起来。每加一个新功能，都要重新编码。AutoResearch 代表的是另一条路：你只需要给出一个目标，比如“整理一下模型压缩这个方向的综述”，系统自己会规划步骤、调用工具、生成中间产物，最终把结果交到你手上。
这就带来一个根本性的变化：软件的功能边界从“开发时确定”变成了“运行时涌现”。用自然语言写软件，或者说用目标驱动软件，正在从概念变成工程实践。Karpathy 的实验报告就是这种实践的一个非常清晰的切片。
我不是说传统代码要被完全替代，至少在科研自动化场景里，确定性代码依然很重要——比如 arXiv API 的调用、引用数据的解析、嵌入向量的计算，这些环节用传统代码反而更稳。但系统的“大脑”和“编排层”确实在迁移：从规则迁移到模型推理。这个迁移，才是 "software is changing" 的准确含义。
2.2 Token 即劳动力：LLM 科研助手的成本结构
既然说范式转移，就不能回避成本。AutoResearch 这种系统的显性成本全部体现在 token 消耗上：每跑一次完整流程，读摘要、生成检索词、总结聚类、写报告，累计消耗的 token 量是非常可观的。
我自己的经验是，跑一个中等规模主题的自动文献综述，如果涉及几十篇论文，整个流程的输入输出 token 加起来可能达到百万级。这是什么概念？以前你雇一个研究助理，是按小时给他发工资；现在这个“虚拟助理”是按 token 计费。两种模式的成本结构完全不同，但后者有一个好处——边际成本递减，而且可以并行复制。
不过这里有一个很多初学者没意识到的坑：token 的大头不只是 API 计价器上的数字，更是“上下文管理”带来的隐性开销。如果你把几十篇论文的全文都塞进 prompt，上下文会爆炸，成本会失控，模型也会在大量不相关内容里迷失。Karpathy 的报告里一个很聪明的做法是先做聚类和过滤，把“需要让模型精读的材料”压缩到很小的范围，再让模型去做深度归纳。换句话说，token 要花在关键判断上，而不是花在搬运资料上。
这给了我一个很重要的实操启示：任何自动科研系统，第一步都应该是“把世界变薄”，先把几百篇论文压缩成几十个关键标签和聚类，而不是让模型面对一个无边无际的原始语料库。
2.3 AutoResearch 不是简单的 Agent，而是“编程语言”的进化
现在到处都是 agent 框架，什么 AutoGPT、MetaGPT，大家已经看麻了。如果把 AutoResearch 简单归类为“又一个 agent 应用”，我觉得会低估它的意义。
大多数 agent 框架在做的事情是“任务分解 + 工具调用”，本质还是把人的操作流程模拟成机器的操作流程。AutoResearch 实验做得更接近另一个层面：它验证了“程序可以由目标直接生成”。你不需要提前定义一个完整的 DAG 来规定每个步骤，模型在运行时自己生成执行路径。这跟“编程”之间的界限已经很模糊了。
我把这个理解为一种“编程语言的进化”：过去我们写程序，是在解释给机器听“怎么做”；现在用 AutoResearch 这类系统，我们更多是在描述“想要什么结果”。这要求使用者的核心能力从“懂语法”变成“懂边界、懂约束、懂判断”。你在 prompt 里写的每一句约束，相当于新语言里的类型检查；你设定的验收标准，相当于编译器的目标。
从这个角度看，Karpathy 的实验报告不只是在展示一个科研工具，它在展示一种新的开发范式。真正值得学的不是那几条代码，而是“如何把一个模糊的科研目标，拆成一个模型可以自动执行的语义程序”。
3. “自动科研”的真正方向：不是替代科学家，而是重造科研流水线
3.1 三个被 AutoResearch 验证的方向
读完报告后，我把“自动科研”拆成了三个已经被验证的方向，这三个方向共同构成了未来几年的核心落地场景。
第一个方向是文献调研自动化。这是目前成熟度最高的。从检索、去重、聚类到写综述，AutoResearch 已经证明机器可以做得相当好。我甚至认为，在“快速了解一个新领域”这件事上，一份用 AutoResearch 思路生成的报告，可能在效率上已经超过了人工综述。
第二个方向是研究假设生成。报告里的系统能在分析过程中自动提出“这个子方向可能存在什么问题”“下一步可能往哪里走”，这些内容本质上就是候选研究假设。它当然不会像顶级的科学家那样提出开创性假说，但它能作为一个“灵感放大器”，把领域里潜藏的空隙和矛盾暴露出来。
第三个方向是报告即产品。在自动科研系统里，最终研究报告本身就是高质量产物，它可以直接服务于选题判断、立项调研、课程学习甚至投资分析。这意味着科研基础设施的输出形式会发生改变：以前你给老板交的是“综述 PDF”，以后你给老板交的可能是“由系统动态维护、可交互更新的知识图谱 + 文字报告”。这三个方向不是割裂的，它们是一个完整闭环的三个环节。AutoResearch 的实验证明，至少这个环的下半段（输入文献、输出洞察）已经具备自动化基础。
3.2 人机分工：科学家做判断，智能体做劳动
我得泼一点冷水，避免大家把“自动科研”想成“AI 自己做科研”。
科学研究里最核心的东西，短期甚至中期内都很难被自动化：判断什么问题是重要的，设计一个能区分两种解释的关键实验，识别一个看似合理但是错误的结果。这些能力依赖科学品味、领域直觉和批判性思维，现在的 LLM 并不具备。所以在我看来，“自动科研”的真正方向不是替代科学家，而是把“科学家-干活”的旧结构，改造成“科学家做决策、智能体做劳动”的新结构。
Karpathy 的实验报告恰恰演示了这种分工的雏形：系统负责把文献山搬开、把路径画出来，科学家负责在山路里选择哪条路值得走下去。这种分工的收益是巨大的。我身边很多博士生，真正花在思考上的时间其实不到三分之一，剩下都在检索、阅读、整理。如果这些体力活可以被 AutoResearch 这类系统承担，研究者就能把省下来的时间投入到更深的问题里。
当然，这要求研究者本身也得升级：你不再是那个亲手把每篇论文读完的人，你要变成那个给系统提出好问题的人。懂得提问题、定边界、验结果，会成为科研工作者的核心能力。
3.3 落地到真实科研工作流的四个阶段
我把科研工作流粗略分成四个阶段，然后逐个看看 AutoResearch 思路能介入多深。
阶段一是探索与选题。这个阶段适合让自动科研系统生成“领域地图”：有哪些子方向、哪些方向在快速升温、哪些方向已经停滞。系统可以给出客观的结构化信息，但最终选哪个方向，一定得人来拍板。
阶段二是深度研读。系统可以做聚类和精读，把每个子领域的核心论文找出来，生成方法脉络。但关键论文的全文还是需要人类亲自读，因为论文里的数学细节、实验设置和隐含假设，是 LLM 不可能替你消化的。
阶段三是实验与验证。这是自动化介入最浅的部分。AutoResearch 目前能做的，最多是帮你生成代码框架、分析实验数据、自动跑一些简单的消融对比，但实验的物理过程和结果解释必须人在回路里。
阶段四是写作与沉淀。系统已经能生成令人惊讶的综述初稿和报告框架，但是论文写作中的学术判断、措辞审慎、贡献强调，依然需要人类的深度修改。四阶段看下来，结论很清楚：自动科研的价值在“连接器”而不是“发动机”。它的主要贡献是把文献、信息、结构、素材高效地输血到科学家的决策终端，而最终那一下点火还是人来做。
4. 边界与幻觉：自动科研最危险的坑在哪
4.1 幻觉与不可验证的引用
我必须把最大的坑放到最前面说：幻觉。
普通聊天场景里，AI 编一个例子，可能只是让人会心一笑。但在自动科研场景里，如果系统引用了一篇不存在的论文，或者把某篇论文的观点总结错了，后果是严重的——轻则误导一个研究方向，重则让整个综述失去可信度，甚至带来学术不端的风险。
Karpathy 在 AutoResearch 实验报告里对这个问题有明显意识。我看到的设计里，引用关系图是先基于真实元数据构建的，生成报告时再强制从真实引用集合中选取，这大大降低了“凭空编引用”的概率。但这仍不能消除另一种幻觉：模型可能把 A 论文的结果总结成 B 论文的结论，或者在归纳多个聚类时创造出原文并不存在的关联。
所以我的建议是：任何自动生成的科研报告，都必须把“引用真实性验证”当作一条硬性流水线。让系统在报告中为每一段关键论述标注可定位的引用，然后用脚本自动核对引用是否存在、位置是否对应。这一步省不掉，也别指望模型自己完全负责。
4.2 评估缺口：怎么判断一份自动生成的研究报告靠谱
判断一份自动研究报告好不好，其实比生成它更难。我自己的团队踩过很多次坑之后，默认用四个维度构建验收标准。
第一，引用真实性。随机抽 20% 的引用去核，看有没有不存在的论文、张冠李戴的观点。第二，内容忠实度。挑几篇关键论文，检查报告对它们的概括是否准确，有没有把“论文提出了一种办法”夸大成“论文证明了这个办法有效”。第三，结构合理性。看聚类划分是不是自然，有没有把明显不相关的论文硬塞到同一类。第四，信息增量。报告里除了复述摘要，有没有真正的交叉对比和趋势判断。
这四个维度我整理成了一个简单表格，方便大家在验收时直接对照。
| 验收维度 | 检查方法 | 不合格表现 |
|---|---|---|
| 引用真实性 | 抽查 20% 引用是否真实存在且位置对应 | 引用不存在、观点错位 |
| 内容忠实度 | 挑 3-5 篇核心论文人工核对 | 概括偏离原文、夸大结论 |
| 结构合理性 | 检查聚类与子方向划分 | 分类混杂、主题边界模糊 |
| 信息增量 | 评估是否给出交叉对比与趋势判断 | 仅拼接摘要、无观点 |
评估缺口是当前自动科研最大的短板。没有一套公认的、可以大规模执行的自动评估体系，就很难说某个系统“达到了什么水平”。这也是为什么我看完 AutoResearch 后，最大的感受不是狂喜，而是冷静——它打开了前路，也同时把“怎么验证这条路”这个问题摆到了桌面上。
4.3 从 AutoResearch 的局限看现有科研 Agent 的共性短板
说完优点和坑，还是得把局限摆清楚。
第一个局限，AutoResearch 做的还是“桌面研究”。它能读论文、写综述、画图谱，但它不能进实验室做实验，不能操作显微镜，不能跑一个月的物理模拟。真实的科研链条里，最花钱花时间的往往是实验环节，而这个环节几乎完全在自动化的触及范围之外。
第二个局限，依赖公开语料。AutoResearch 的覆盖质量高度依赖某篇论文能不能被检索到、摘要全不全、引用数据准不准。对小众领域、冷门语言、未数字化的历史文献，它的表现会明显下降。
第三个局限，缺少“可证伪”的科研行为。真正的科研不仅是归纳，还要提出假设并设计实验去检验假设。AutoResearch 在归纳和提出线索上做得不错，但它并不会主动去设计一个实验来检验自己生成的猜想。它最多是一个“聪明的阅读器”，离“独立的科学家”还有很长的路。
我自己对不同科研 Agent 的观察也是如此：绝大多数系统都押注在“读”和“写”上，而“做”和“验”几乎真空。这不是哪个框架的问题，是整个领域当前的能力边界。在做任何预算和预期管理时，都应该清醒地认识到这一点。
5. 我从中得出的实操启示：如何用 AutoResearch 的思路改造自己的工作流
5.1 把 AutoResearch 的思路拆解成可复用的模块
报告读完，光感慨没用，我更喜欢把它化成能带走的东西。我发现 AutoResearch 的骨架可以拆成四个可独立复用的模块，如果你不想用现成的重型框架，完全可以按这个思路自己搭一套轻量的。
第一个模块是检索模块。职责是根据主题生成检索词、调用文献库 API、拉回候选论文列表。要注意的点是让 LLM 先生成多个细分检索词，而不是直接用一个大词去搜。第二个模块是图谱模块。用论文 ID 和引用关系建图，顺便可以算一些简单的图指标，比如被引次数、中心度，这些指标对后续聚类标签很有帮助。
第三个模块是聚类模块。核心是 embedding 加聚类算法。把标题和摘要向量化，然后聚成若干簇，再让 LLM 为每个簇起一个能准确概括主题的名字。这一步做得好，整个报告的结构就已经成型一半。第四个模块是综述模块。让 LLM 按“背景—子方向—对比—开放问题”的框架，把各簇的内容综合成一份连贯报告。关键在于每个子方向都强制引用真实的论文 ID。
拆完之后你会发现，每个模块都可以用非常成熟的开源组件实现，甚至不需要“智能体”这个词。这恰好呼应 Karpathy 实验给我的最大启示：自动科研的关键不是引入一个无所不能的 agent，而是让模型在一个精心设计的流水线节点上各司其职。
5.2 本地搭建一个轻量版自动文献综述管线
我把自己最近搭的一个极简版本贴在这里，用的是最常见的 Python 库，作为参考起点。它没有花哨的界面，但足够体验一遍 AutoResearch 的核心感觉。
# 轻量版自动科研管线：检索 -> 聚类 -> 综述（示意代码） import arxiv import numpy as np from openai import OpenAI from sklearn.cluster import KMeans client = OpenAI() def fetch_papers(topic, max_results=40): search = arxiv.Search(query=topic, max_results=max_results) papers = [] for result in search.results(): papers.append({ "id": result.entry_id.split("/")[-1], "title": result.title, "summary": result.summary, }) return papers def embed(text): resp = client.embeddings.create( model="text-embedding-3-small", input=text[:8000] ) return resp.data[0].embedding def cluster(papers, k=4): vectors = np.array([embed(p["title"] + "\n" + p["summary"]) for p in papers]) labels = KMeans(n_clusters=k, n_init=10, random_state=42).fit_predict(vectors) for paper, label in zip(papers, labels): paper["cluster"] = int(label) return papers def summarize(papers, topic): clusters = {} for paper in papers: clusters.setdefault(paper["cluster"], []).append(paper) parts = [] for cluster_id in sorted(clusters): items = clusters[cluster_id] desc = "\n".join([f"- {p['title']}: {p['summary'][:300]}" for p in items]) resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是科研助理。请总结以下论文聚类的研究主题、代表工作与方法脉络。"}, {"role": "user", "content": f"主题：{topic}\n论文列表：\n{desc}"} ] ) parts.append(resp.choices[0].message.content) return "\n\n".join(parts) papers = fetch_papers("model compression", max_results=40) papers = cluster(papers, k=4) report = summarize(papers, "model compression") print(report)这段代码只是骨架，真正要跑起来还需要补很多细节，比如引用关系构建、重复论文去重、幻觉检查。但它的好处是清晰展示了“检索到聚类再到综述”的主干逻辑。你完全可以把每个模块替换成自己的实现。
我在实际搭建时踩过三个坑：一是 embedding 的输入长度，摘要太长要截断，否则会报错；二是聚类个数 k 需要根据主题规模调整，固定值会让报告结构失真；三是 LLM 的总结 prompt 里如果材料太多，模型会“消化不良”，最好先对每个论文做一句话预筛。这三个坑都不难解决，但会严重影响最终体验。
5.3 踩坑建议与验收清单
最后把我这段时间实践下来最值得分享的经验收拢一下。
第一，先限定目标领域。我第一次跑的时候贪大，直接让系统整理“整个深度学习方向”，结果报告空洞无物，聚类也是一团浆糊。后来把边界收缩到“视觉 transformer 中的 token 合并方法”，效果立刻好了一个档次。自动科研系统更适合解决“一个明确的子问题”，而不是包打天下。
第二，必须建立防幻觉机制。我的做法是让系统在报告里对每个关键段落标注引用 ID，再用脚本去校验这些 ID 是否真的存在、论文标题是否对得上。宁可多花一点时间，也不能把一份有假引用的报告发出去。
第三，人要负责终审。系统生成的报告，在我这里永远被当成“高质量草稿”，而不是最终答案。特别是涉及学术观点的地方，我会把最核心的 5 到 10 篇论文拿出来亲自过一遍，确保报告没有曲解原文。
第四，成本要提前估算。上面那种轻量管线，跑一个小主题大概也就几块到几十块的 API 成本，但如果主题很大、论文很多，成本会非线性上升。建议先跑一个小规模样例，再决定要不要扩大。
我也给自己列了一份验收清单，每次跑完自动文献调研都对着打勾：引用是否全部可查；每篇关键论文的核心结论是否被准确表述；聚类结果是否能让外行一眼看懂；报告是否包含至少三条新的交叉对比；有没有明显的致命幻觉。我用这套方法跑通了一个小规模的创新方向调研，节约的时间非常可观。虽然还不能说自动科研已经到了“完全可信”的程度，但它至少已经让我们看到了一个非常具体、可以继续迭代改进的方向。
最后说一点个人体会。Karpathy 的 AutoResearch 报告对我冲击最大的地方其实不在技术，而在心态：它让我意识到，未来做研究的方式会和过去很不一样。过去我们默认“读文献、写综述”是研究者必须亲力亲为的基本功；而 AutoResearch 这一类的实验正在把这种基本功外包给机器，把人释放出来去做真正需要创造力和判断力的事情。这也意味着我们每个人都需要重新思考一个问题：当机器能把信息的苦力活全包了，我们作为研究者的真正价值究竟在哪里？我的回答是，在于提出那个机器不会提出的好问题。
