港大团队提出 DeepCode ，让 Agent 真能“读论文写可运行代码”
港大团队提出 DeepCode ，让 Agent 真能“读论文写可运行代码”
01 论文概述
这篇论文来自香港大学团队（通讯作者：Chao Huang）。论文提出并开源了DeepCode ：一个能“自动写项目”的智能体框架，想解决的不是让模型多写几段代码，而是让它读完论文或技术文档后，能把一整套代码工程搭起来，包括项目结构怎么拆、不同文件怎么配合、训练/评测脚本怎么写，最后还能把复现实验真正跑通。
论文名称：DeepCode: Open Agentic Coding
👉 论文链接
👉Github
👉 大模型实验室 Lab4AI
当论文动辄几十页、细节分散在图表/公式/附录里，模型的上下文窗口又装不下全部信息时，它为什么还能稳定生成一个能跑通的完整仓库？
论文的核心观点其实很直白：现在很多 coding agent 不是“不会写代码”，而是很难把一篇论文真正落成一个能跑的完整项目。问题也不主要在模型参数不够大，而在于一个硬矛盾——论文信息太多太散（文字、公式、图表、附录到处都是细节），但模型的上下文窗口有限，装不下也装不准。
如果用最朴素的办法：把论文全文和前面生成过的代码一直往上下文里塞，结果往往是越塞越乱。大量无关细节把关键约束淹没了，模型抓不住“到底哪些东西必须照论文做”。最后就会出现一种常见失败：仓库看上去结构也有、代码也像那么回事，但关键细节写错、文件之间对不上、脚本一跑就报错。
所以DeepCode 换了个思路：把这件事当成“有限容量里怎么传递关键信息”的问题。也就是，不追求把所有内容都喂给模型，而是让系统学会把信息先整理、再按需取用，保证每一步写代码时看到的都是“当前最相关的那部分”。
基于这个思路，作者将关键挑战总结成四类：
- 规范保真：论文要求分散在各处，模型容易漏掉或写偏；
- 部分视图下的全局一致性：仓库模块互相依赖，但生成按文件推进且上下文有限，易接口漂移；
- 未充分指定设计的补全：论文常只写算法核心，工程细节与实验框架大量默认不明说；
- 可执行保真度：不仅要“合理”，还要能端到端跑通，长链路更易积累细小 bug。
DeepCode 的解法可以理解成“四个工具 + 三步流程”：先把论文提炼成一份“可实现的项目说明书”（Blueprint），再用一套“项目记忆”记录每个文件的作用和接口（CodeMem），需要补缺时再从外部检索可靠实现模式（CodeRAG），最后用自动检查 + 实际运行来抓 bug 并逐条修掉（Verification），确保最终交付的是能运行的仓库而不是“看起来很像的代码”。
02 核心贡献
论文的核心贡献主要是以下三点：
- 先把问题说清楚：作者指出，做“读论文写完整项目”这件事，最大障碍不是模型不聪明，而是论文信息又长又散、模型上下文又有限。想做对，不能靠硬塞内容，必须学会把信息整理成结构、压缩重点、按需取用。
- 再把方法做成系统：他们把这个思路落成一个可用框架 DeepCode，用四个关键模块把流程跑通：先把论文提炼成“项目说明书”（蓝图），再用“项目记忆”保证多文件不跑偏，需要时从外部补齐缺失实现，最后通过自动检查和运行测试不断修错，专门解决“细节漏、接口乱、缺工程细节”的老大难问题。
- 最后用结果证明有效：在 PaperBench 这种要求“真复现、真跑通”的基准上，DeepCode 的表现明显强过主流商用代码 Agent，而且在一些关键设置下，甚至超过了顶尖机构的博士级人类复现水平。
03 核心技术
DeepCode 不把“读论文写仓库”当成一次性生成任务，而是拆成三步走：先把论文梳理成“能照着做的说明书”，再按说明书写代码，最后用自动跑通来纠错。
3.1 阶段 1：Blueprint（把“论文”变成“项目说明书”）
（1）关键点 1：分层切片（Hierarchical Content Segmentation）
它不会把整篇论文一股脑塞进模型上下文，而是先按“章节/小节”切成很多小块，并用“标题当 keyword”做键值索引（可以理解为“目录 + 标签”）。后面写某个模块时，只把当前真正相关的那几段取出来看，避免上下文越塞越乱、重点被稀释。
（2）关键点 2：双分析智能体分工（Concept / Algorithm）
- Concept Agent（大框架）：负责把论文讲的内容翻译成“项目怎么拆、先做什么后做什么”的路线图。
- Algorithm Agent（抠细节）：负责把关键细节“抠出来”：公式、伪代码、网络结构、训练流程、超参表等；论文也允许它通过在线检索补齐实现参考（比如某些标准算法的常见写法）。
（3）关键点 3：蓝图的标准化内容（canonical sections）
最后由 Planning Agent 把两部分分析合成一份“蓝图 B”，更像一份工程规格书：
- 仓库大概长什么样（文件/目录结构）
- 每个组件要实现什么（对应论文的算法与模块）
- 怎么验证对不对（验证协议/运行入口）
- 运行环境怎么配（依赖、版本、脚本）
- 开发步骤怎么排（分阶段计划）
3.2 阶段 2：CodeMem + CodeRAG（让多文件不跑偏、缺的细节能补上）
这一阶段核心就是两件事：第一是写到一半别“失忆”，第二是论文没写的工程细节别硬猜。
CodeMem：用“项目记忆”替代“把历史代码贴回去”
每生成一个文件，它不把整段源码再塞回上下文，而是把这个文件“总结成一条记忆卡片”，重点只保留：
- Core Purpose：这个文件/模块是干嘛的
- Public Interface：对外暴露什么类/函数/常量（接口签名）
- Dependency Edges：它依赖谁、谁会依赖它（依赖关系）
这样上下文不会随着仓库变大而爆炸——写新文件时，只拿相关记忆摘要就够了。
CodeRAG：需要时再“外部查资料”，不是每次都搜
论文考虑到很多工程细节在论文里压根不写（比如常见训练脚手架、标准实现套路）。所以它会先把候选仓库索引好（筛相关文件 → 做摘要 → 建立 source→target 的关系），写某个目标文件时，模型先判断一句：“我这一步需不需要检索？”
需要就把最相关的 snippet/用法/模式拿来当参考注入上下文，不需要就不搜，避免检索噪声反而干扰。
3.3 阶段 3：Verification（把“写得像”升级为“跑得通”）
DeepCode 最后一定走验证闭环，因为“看起来对”不等于“能复现”。验证分两层：
- 静态分析 + 行级修补（LSP 风格）：先对照蓝图检查：有没有缺文件、空文件、明显质量问题。修复时尽量做“行级补丁”，而不是整文件推倒重写，避免越改越引入新错误。
- 沙箱运行 + 迭代纠错：自动搭环境、跑入口脚本/测试流程，捕获报错栈（trace），定位可能出错的文件，再继续用行级补丁修。一直循环到能跑通，或达到迭代上限。
04 研究结果
4.1 基准与评测：PaperBench Code-Dev
PaperBench Code-Dev 用 ICML 2024 的 20 篇论文当题目，要求模型只看论文，从零生成完整仓库和 reproduce.sh，并在 VM/容器里跑起来。每篇论文都有作者认可的 rubric，把任务拆成 8,316 个可评分组件，再用 SimpleJudge（o3-mini）按层级权重自动打分。
换句话说，它测的不是“代码写得像不像”，而是复现有没有真的做到位、有没有真的跑通。
4.2 主结果：对 LLM Agent / 科研复现 Agent / 商用 Agent / 人类专家均显著领先
- 对普通 LLM-based agents：DeepCode 约 73.6%：最强对照（o1）约 43.3%（论文引言也提到 o1 在 20 篇上约 42.4%）。
- 对科研复现 Agent（PaperCoder）：PaperCoder 51.1±1.4%，DeepCode 73.6±2.8%。
- 对人类专家（Top ML PhD）：在 3-paper 子集上，人类 best-of-3 为 72.4%，DeepCode 为 75.9±4.5%。
4.3 与商用代码 Agent 的正面对打
论文在 5-paper 子集上，直接对比 Codex / Cursor / Claude Code，DeepCode 平均分约 0.85，显著领先；并强调 DeepCode 与 Cursor/Claude Code 使用相同底座模型时依然能拉开差距，说明优势主要来自架构与执行策略，而非“单纯模型更强”。
4.4 “模型底座换一换”会怎样？
论文在三项任务（fre / all-in-one / stay-on-topic）上比较 5 个底座：Claude-4.5、GPT-5、Claude-3.5、Gemini-2.5-Pro、DeepSeek-R1；结论是强底座总体更稳，但 DeepCode 的框架能显著抬高下限——也就是中等模型也能更像“工程师”一样把项目写完整、写一致、写到能跑。
4.5 组件消融：哪些模块最“值回票价”？
消融结果表明，CodeRAG、CodeMem、Verification 的“回报”各不相同：CodeRAG 对弱底座模型最值，在 Gemini-2.5-Flash 上可带来显著提升；CodeMem 则是保障长链路跨文件一致性的关键，相比简单滑窗丢历史，能把多项任务从 0.33–0.43 拉升到 0.70–0.92；Verification 的提升幅度相对更小但稳定（约 3.7%–6.5%），主要解决拼写、依赖缺失和命令行参数等“最后一公里”可执行性问题。
一句话点破 DeepCode 的“方法论价值”
如果把“复现论文写仓库”看成一个长链路的信息传递问题，DeepCode 的重点不是堆更大模型、开更长上下文，而是把信息流做成一套工程管道：先压缩成蓝图（Blueprint）→ 再用记忆维持一致性（CodeMem）→ 必要时补知识（CodeRAG）→ 最后闭环修到能跑（Verification），从而在有限上下文里也能稳定交付“能跑通的项目”。
本文由 AI 深度解读，转载请联系授权。关注“大模型实验室 Lab4AI”，第一时间获取前沿 AI 技术解析！