外观
从这里开始
这一页不精读任何一篇论文，它回答一个更前置的问题：一个做 Agent 的工程师，应该怎么把「读论文」这件事变成日常武器，而不是收藏夹里的愧疚。
如果你还没读过 什么是 AI Agent 和 全景解剖，建议先回去——论文精读假设你已经知道 Agent Loop、tool use、context window 这些基本概念，否则会在术语上反复摔跤。
一、为什么做 Agent 要读论文
先给一个直接的判断：只看框架文档和博客，你可以把 Agent 做出来；但只有读论文，你才知道自己做的东西有多大把握是对的。
框架文档告诉你「怎么做」，论文告诉你「为什么」
LangGraph 的文档会教你 add_node、add_edge，但不会告诉你为什么 ReAct 这种「边推理边行动」的交替结构在 2022 年之后成了默认范式，也不会告诉你在什么任务上它会输给简单的 plan-and-execute。这些「为什么」只在论文里：动机、反例、ablation（消融实验）、失败案例分析——这些恰恰是工程决策最需要、而营销材料最不会给你的东西。
论文还告诉你「什么被验证过不 work」
这是读论文最被低估的价值。工业界踩坑是沉默的：一个团队花了三个月做多智能体投票机制发现效果不如单 Agent 加 self-reflection，这件事不会出现在任何 Release Notes 里。但学术圈有发表负面结果和对比实验的传统（虽然不完美），很多「听起来很美的方向已被证伪」的信息，只存在于论文的 related work 和实验表格里。比如这两年多篇关于多智能体系统的实证研究都指出：在多数任务上，精心设计的单 Agent 加好的 scaffold，比一堆互相喊话的 Agent 更便宜也更可靠——这类结论你在框架官网的「Multi-Agent 快速上手」里是看不到的。更多讨论见 多智能体架构 与 设计原则。
还有一个功利理由：面试和判断力
Agent 岗位面试几乎必问「最近读过什么论文」「你怎么评价 SWE-bench 上的分数」。能说出「这个分数是在什么 scaffold、什么预算、什么子集上跑出来的」的人，和只会背榜单排名的人，在面试官眼里是两个物种。参见 面试题精讲。
论文、博客、文档：三种信息源的分工
同样一个主题，三种来源给你的是三种东西，不可互相替代：
| 信息源 | 给你什么 | 不给你什么 | 信任方式 |
|---|---|---|---|
| 框架文档 | API 怎么用、最新接口形态 | 设计动机、适用边界、失败场景 | 信其「能跑」，别信其「该这么设计」 |
| 厂商博客 / Release Notes | 产品能力边界、官方推荐姿势 | 任何对己不利的信息 | 当广告读，数字打七折 |
| 论文 | 动机、对比实验、ablation、（诚实的）失败分析 | 工程细节、可维护性、真实成本 | 信其方法，审其数字 |
成熟的工程师三种都读，但分工明确：用文档解决「怎么写」，用论文解决「为什么这么写、值不值得这么写」，用博客确认「厂商现在支持到什么程度」。只读第一种的人，做出来的系统总是慢半拍且不知道为什么。
一个心智模型
把 Agent 系统拆成「模型能力」和「scaffold（脚手架：prompt 结构、工具封装、循环控制、重试与验证逻辑）」两层。论文的最大价值，是帮你判断一个提升到底来自哪一层——这直接决定了它对你的系统有没有迁移价值。模型层的提升你等厂商发版就行，scaffold 层的提升才是你能抄走的。
二、本模块的论文是怎么选出来的
arXiv 上标题带 "agent" 的论文现在每天几十篇，绝大多数不值得你花时间。本模块的选文标准有三条，按重要性排序：
- 开创性（defining）：提出了一个被后续工作反复使用的概念或范式。判断标准不是发表会议的牌子，而是两年后别人写代码时还在用它的术语——ReAct、Reflexion、Tree of Thoughts 都属于此类。它们定义了今天的 Agent 是怎么搭的。
- 被引用与被复现：引用数是粗略信号，更有价值的是「被工业界复现」——某篇论文的方法出现在了 Claude Code、Devin、SWE-agent 这类真实产品或高星开源项目里。论文影响力以「进入生产代码」为终极检验。
- 工业界验证（battle-tested）：来自一线实验室的技术报告和系统论文（OpenAI、Anthropic、DeepMind、以及头部 Agent 产品团队），哪怕是非正式的技术博客式论文，只要披露了真实的工程细节和失败教训，优先级高于多数理论工作。
反过来，以下几类论文本模块基本不收：
- 只换了个垂直领域套壳的 "XX-Agent for YY"（医疗 Agent、法律 Agent、教育 Agent……），方法上没有新东西；
- benchmark 涨了一两个点但 ablation 看不出原因的刷分工作；
- 没有代码、没有 prompt 细节、关键实验不可复现的「概念验证」。
你可以用同样的三条标准去筛选任何新出现的论文。详细的逐篇精读见 核心论文，选不出来先看 论文地图。
三、怎么读一篇 Agent 论文
三遍法：先决定值不值得读，再决定读到多深
学术界最经典的阅读方法是 S. Keshav 的「三遍法」（three-pass approach），来自他 2007 年的短文 How to Read a Paper。原方法面向通用论文，我把它针对 Agent 论文做了改造：
第一遍（5-10 分钟）：决定读不读
├── 标题 + 摘要：它声称解决了什么问题？
├── 引言最后一段：贡献列表是什么？
├── 直接跳到实验表格：主结果涨了多少？跟谁比的？
└── 扫一眼引用：认识几篇？判断这是不是主流脉络上的工作
↓ 通过才进入第二遍（大部分论文应该死在这里）
第二遍（30-60 分钟）：理解方法，跳过细节
├── 方法节的图（pipeline / 架构图）——Agent 论文的图比文字重要
├── scaffold 的每个组件：prompt 怎么组织？循环怎么退出？
├── 实验设置：用的什么模型？什么 benchmark？预算上限？
└── 失败案例（如果作者诚实写了）——往往比成功案例更有信息量
↓ 只有打算复现或借鉴的论文才进入第三遍
第三遍（2-5 小时）：批判性精读 + 动手
├── 逐行读方法，在脑子里「重新实现」一遍
├── 对照官方代码仓库读，论文没写的实现细节全在代码里
└── 用自己的任务跑一个小规模验证，而不是信它的数字关键纪律：每一遍结束都允许扔掉论文。工程师读论文的目标不是「读完」，是用最少的时间拿走能用的东西。大部分论文值得第一遍，少数值得第二遍，极少数值得第三遍。
Agent 论文要重点盯的两个地方
1. Scaffold 细节。 Agent 论文的核心创新九成在 scaffold，而 scaffold 恰恰最容易写得含糊。要追问：
- prompt 全文给了吗？（很多论文只给「示意」，真实的 system prompt 藏在附录或代码里）
- 循环的退出条件是什么？最大步数、token 预算、还是模型自己决定？
- 工具调用失败怎么处理——重试几次？错误信息原样塞回 context 吗？
- 子任务之间怎么传递状态？全量历史还是摘要？
这些问题决定了方法的实际效果，也决定了你能不能复现。上下文组织方式的更多门道见 Context Engineering。
2. Eval 设置。 读实验节先别看分数，先看「这个分数是怎么产生的」：
| 要看的字段 | 为什么重要 |
|---|---|
| 底座模型及版本 | 换一个模型结论可能整个翻转 |
| 跑了几次、报的是 pass@1 还是 best-of-n | best-of-n 的数字在生产里毫无意义 |
| 单任务成本 / token 预算 | 不计成本的提升等于没有提升 |
| benchmark 子集 | 在 500 题子集上的 70% 和全集上的 70% 是两回事 |
| 基线是否同等预算 | 给自己 200 步、给 baseline 20 步的对比是耍流氓 |
一个正面例子：SWE-bench Verified 就是社区意识到原始 SWE-bench 的评测噪声后，由 OpenAI 与原作者合作人工筛出的 500 题高质量子集，修正了「正确解法被判错」「问题描述欠定」等问题——这说明连最权威的 benchmark 本身都需要被审视。2025 年以后，SWE-bench Verified 上 70%+ 的成绩已经常见，社区又转向更难的 SWE-bench Pro 来拉开区分度。读任何 agent 评测论文时，先确认它用的是哪一代 benchmark。评测方法论的展开见 评估与测试。
警惕什么：三个最常见的坑
Benchmark 污染（contamination）。 公开 benchmark 的题目会进入后续模型的训练语料，这是整个行业都知道但论文很少主动讨论的问题。早在 GPT-3 的技术报告里，作者就披露过部分 benchmark 与训练数据存在明显重叠。对 Agent 论文来说，污染更隐蔽：SWE-bench 的 issue 文本、Stack Overflow 的讨论、甚至参考 patch 都可能在预训练语料里。防御办法：优先看那些在「论文发布之后新构建的」或私有 held-out 测试集上的结果；对公开 benchmark 上的 SOTA 数字保持条件反射式的怀疑。
Cherry-pick。 表现形式包括：只报多个随机种子中最好的一次；从十个 benchmark 里挑涨的五个放进正文；case study 展示精心挑选的成功轨迹。识别方法：看有没有方差/置信区间，看附录里是否有完整结果表，看失败案例分析的篇幅——愿意用两页写失败案例的作者，通常比全文只有成功案例的作者可信。
Scaffold 过拟合。 刷榜专用 scaffold 会把分数和真实用户体验脱钩：评测 harness 里塞了复杂的重试、多采样投票、特定于题库的提示词，这些组件在用户实际部署时并不存在。已有分析明确指出，SWE-bench Verified 上近年的部分进展更多来自对问题空间的 scaffold 过拟合，而非能力提升。判断标准很简单：这篇论文的方法搬到你自己那一团乱麻的真实任务上，还能剩下几个点？
一个反向指标
如果一篇 Agent 论文不报成本（token 用量、单任务美元成本、平均步数），默认它的方法贵到没法用。严肃的 Agent 评测从 2025 年起已经把成本当作一等公民——有测量显示，在 SWE-bench Verified 上跑一轮的中位成本超过百美元量级，不同模型单任务成本可以差出两个数量级。不谈钱的 SOTA，是奢侈品广告，不是工程论文。
四、arXiv 生存指南
Agent 领域的论文生态和五年前完全不同，工具链也在快速洗牌。以下是 2026 年年中还成立的用法。
找论文：别用 arXiv 原生搜索
arXiv 的搜索框基本是上个时代的产物。实际工作流：
- 日常发现用 Hugging Face Papers。每天社区票选的 trending 论文，带讨论区，是「今天 Agent 圈在聊什么」的最快入口。质量参差，但它解决的是「不漏掉热点」的问题。
- 溯源和扩展用 Semantic Scholar。它的价值不在搜索，在引用图谱：找到一篇核心论文后，看它的高影响力引用（influential citations）能快速定位「这个方向后来最重要的跟进工作」。这比顺着 arXiv 时间线爬快得多。
- 精读前的预筛选用 alphaXiv。一个覆盖在 arXiv 上的讨论层，可以直接在论文页面上看评论、提问、关注作者——相当于给每篇论文配了一个公开的 review 区。把 arXiv URL 里的
arxiv.org换成alphaxiv.org即可跳转。 - 跟作者而不是跟关键词。Agent 领域的有效产出高度集中在少数实验室和学者手里。找到两三篇你认可的论文后，在 Semantic Scholar / alphaXiv 上关注其作者，比订阅关键词 alert 的信噪比高一个量级。
一个时代的眼泪：Papers with Code 已经没了
很多老教程还会推荐 Papers with Code 查「论文 + 官方代码 + SOTA 榜单」。注意：该站已于 2025 年年中被 Meta 关停，域名现在直接 302 到 Hugging Face。替代方案：论文与代码的对应关系看 Hugging Face Papers 页面挂的仓库链接或 alphaXiv；SOTA 榜单看各 benchmark 自己的官网（比如 SWE-bench 维护着带成本的官方 leaderboard）；找非官方复现就直接在 GitHub 搜论文标题。别再按照旧攻略去找 Papers with Code 了。
看代码：论文的真相在仓库里
Agent 论文的代码仓库值得花至少和论文一样多的时间：
- README 和 issues 比代码先看。issues 区里「我按论文配置跑不出报告的数字」这类帖子和作者的回复，是评估复现难度的金矿。
- 找 prompt 的真实全文。一般在
prompts.py或 yaml 配置里。论文里那段「示意 prompt」和仓库里两千行的真实 system prompt 之间的差距，就是学术表达和工程现实的差距。 - 看 git log 而不是只看 main 分支。刷榜时期的提交历史（比如临投稿前疯狂调 prompt）会告诉你哪些组件是核心创新、哪些是硬调出来的。
- 优先看被产品验证过的实现。SWE-agent 这类既有论文又长期维护的开源项目，是「论文到生产」的完整样本，比单纯论文更有学习价值。
一个小型 SOP
发现（HF Papers / alphaXiv trending）
→ 第一遍筛选（10 分钟内判死刑）
→ 值得读的进 Semantic Scholar 查引用脉络
→ 精读 + 对照官方仓库
→ 用自己的任务做 50 条以内的小规模验证
→ 结论写进自己的笔记（一句话：什么场景可用、成本多少、坑在哪）五、模块地图
本模块其余四页的分工：
| 页面 | 解决什么问题 | 什么时候用 |
|---|---|---|
| 精读路径 | 按目标（入门 / 求职 / 做产品 / 追前沿）给出不同的阅读顺序 | 不知道先读哪篇，从这里开始 |
| 论文地图 | 按主题（规划、记忆、工具、多智能体、评测……）组织全景图谱 | 想系统了解某个子方向时按图索骥 |
| 核心论文 | 逐篇精读定义了这个领域的论文：背景、方法、scaffold 细节、局限 | 主力内容，配合三遍法食用 |
| 前沿动态 | 近半年值得注意的新工作，含时效标注 | 保持手感，每月扫一次 |
建议的用法：先按 精读路径 选定顺序，用本页的三遍法读完 核心论文 里对应的几篇；遇到想深挖的子方向去 论文地图；前沿动态 则当作月刊，配合上面 arXiv 生存指南里的工具自己判断哪些新论文值得升级成精读。
最后提醒一句：论文是地图，不是领土。读完任何一篇，最终都要回到「它对我的系统意味着什么」这个问题上——这正是 动手构建你的第一个 Agent 和 常见陷阱 两页存在的原因。
参考资料
- How to Read a Paper（S. Keshav，Stanford 镜像 PDF） —— 三遍阅读法的原始出处，本文第三节的改造基础。
- SWE-bench 官方 Leaderboard —— 带成本信息的官方榜单，理解「分数 + 成本」双维度评测的入口。
- SWE-bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?（arXiv:2509.16941） —— 讨论 SWE-bench Verified 趋于饱和后如何构建更有区分度的评测。
- Papers with Code 关停公告（GitHub Issue） —— 确认该站 2025 年被 Meta 关停并重定向至 Hugging Face。
- Semantic Scholar —— 引用图谱与作者追踪，论文溯源的主力工具。
- alphaXiv —— arXiv 之上的讨论层，可看评论、关注作者。
- Hugging Face Papers —— 每日 trending 论文与社区讨论（注：本次写作时从国内网络直连未验证成功，URL 为 Papers with Code 官方关停公告中确认的重定向目标）。