想象一下，你正试图修理一栋百层摩天大楼里一个漏水的水龙头。你不需要阅读整栋建筑的蓝图、食堂菜单或安全日志，你只需要知道到底是哪根管子在滴水，并看到它周围的即时区域。
这就是关于“编程智能体”（coding agents）——即编写和修复软件的 AI 机器人——的一项新研究带来的惊人启示。长期以来，技术界一直认为这些机器人需要将整个项目的代码库（有时高达数百万行）全部“吞”进它们的“大脑”才能胜任工作。当时的逻辑是：“上下文越多越好。”
但这篇论文指出：停止向大脑灌输信息。 研究发现，对于实际的修复代码行为，AI 几乎只需要它即将修改的那几行代码。
“寻找”与“行动”
研究人员将问题分为两个部分：
- 寻找（The Find）： 定位损坏的代码。
- 行动（The Act）： 一旦找到代码，如何实际修复它。
为了测试这一点，他们使用了一个“魔法地图”（预言机/oracle）来告诉 AI 损坏代码的具体位置。这意味着 AI 不需要猜测在哪里寻找，它只需要专注于如何去修复它。随后，他们给 AI 展示了该代码的不同“视图”，以观察哪种方式效果最好。
大失所望：摘要并不奏效
一个流行的想法是：“让我们直接给 AI 一个自然语言形式的代码摘要，就像书的简介一样。”
- 测试： 他们要求 AI 利用代码的完整源代码或由超强 AI（前沿模型）编写的摘要，来回答关于代码行为的棘手问题。
- 结果： 完整源代码答对了 45 道题中的 27 道。而摘要呢？仅答对了 45 道题中的 4 道。
- 转折点： 无论摘要是由世界上最聪明的 AI 还是最微小的基础模型编写的，结果都一样——它们都失败了。问题不在于编写者，而在于格式。摘要无法承载修复 Bug 所需的特定“行为”细节。这就像试图通过阅读一份关于汽车的旅游手册来修理汽车引擎；手册很精彩，但它不会告诉你哪颗螺栓松动了。
“骨架”对比“全身”
接着，他们测试了 AI 是否需要完整的、丰满的代码，或者只需要“骨架”（即结构，如函数名称和签名）。
- 设置： 他们使用了 70 个真实的编程问题。对于某些问题，他们提供了完整的代码文件；对于另一些，他们只提供了“骨架”（UML 图和签名）或“保留/丢弃”（keep/drop）版本（即仅保留核心部分并删除其余部分）。
- 结果： “骨架”版本和“保留/丢弃”版本解决问题的数量与完整文件不相上下。事实上，“保留/丢弃”方法解决的问题（70 个中的 25 个）甚至略多于完整文件（19 个中的 19 个），尽管这种差异很小，可能仅仅是运气使然。
- 成本： 关键点在于这里。使用完整文件解决一个问题的成本是 94,000 个 token（文本单位）。而使用压缩后的“保留/丢弃”方法，成本仅为 19,000 个 token。这是一个巨大的节省——大约 3 到 3.7 倍的成本降低——且性能并未下降。
“噪声”警告
研究人员还发现了一个奇怪且重要的现象：即使他们在完全相同的设置下运行完全相同的测试，AI 有时也会给出不同的答案。大约有 9% 的时间，实验结果在两次运行之间发生了反转。这意味着，如果你看到两种方法之间存在微小的差异（例如 2% 的提升），那可能只是随机噪声，而非真正的突破。
核心结论
论文得出结论：对于修复代码这一特定任务，少即是多。
- 有效的方法： 给 AI 提供它需要编辑的精确代码行，并将其精简至核心部分。
- 无效的方法： 向 AI 灌输摘要、完整的历史文件或复杂的结构图。
- 定论： “信号”存在于代码本身，而不是我们讲述的代码故事中。通过剔除冗余，我们可以以极低的成本修复 Bug，而不必为了修理一个漏水的水龙头而去阅读整栋摩天大楼。
作者非常谨慎地指出，这适用于“单次尝试”（single-shot）修复（即 AI 尝试一次后无法重新阅读或寻求帮助的情况）。但在这种特定的、高风险的编辑时刻，数据是明确的：你不需要整个图书馆，你只需要正确的那一页。
技术摘要：编码智能体（Coding Agent）实际需要什么样的上下文才能执行任务？
问题陈述
现代编码智能体拥有足以容纳整个代码仓库的巨大上下文窗口，但有证据表明，这些上下文中的大部分并未被使用。虽然通常采用检索增强生成（RAG）和复杂的脚手架技术来管理上下文，但像 ContextBench 这样的基准测试表明，这些复杂的系统往往仅仅略优于平凡的基线。核心问题不在于智能体能持有多少上下文，而在于在何种表示形式下，最少需要多少上下文才能让智能体成功地进行代码编辑。
作者区分了两个经常在智能体设计中被混淆的子问题：
- 查找（Find）： 定位必须进行工作的特定函数或文件。
- 执行（Act）： 在给定位置的情况下，是否拥有足够的信息来正确执行编辑。
本研究隔离了执行阶段。通过固定定位过程（使用提供精确黄金标准文件的“预言机/Oracle”来确保定位准确），作者仅改变代码的表示形式，以确定实现解析所需的最小上下文。
研究方法
实验框架：resolve@cost
作者构建了一个经过审计的工具，用于衡量解析率与上下文成本之间的关系。
- 数据集： 来自 SWE-bench Verified 的 70 个多文件实例（排除了一个因其黄金补丁无法通过自身环境验证的实例）。
- 预言机定位（Oracle Localization）： 为了隔离表示效果与检索错误，每个实验“臂”（条件）都接收完全相同的、用于修改的黄金文件集。唯一的变量是这些文件的内容如何呈现。
- 智能体： 单次运行的 Claude Sonnet 4.6（温度为 0，最大 8000 token）。智能体输出
SEARCH/REPLACE 块，这些块由确定性构建器（difflib）转换为统一差异（unified diffs），并通过 Docker 容器进行验证。
- 验证：
- 可表达性门槛（Expressibility Gate）： 在任何智能体调用之前，都会验证黄金补丁中删除的每一行或插入的锚点在渲染的上下文中都是逐字存在的。
- 确定性： 补丁的构建是确定性的，以避免非可重复差异生成带来的干扰。
- 预注册： 假设和协议在数据收集前已冻结。
表示形式分支（Representation Arms）
研究对比了黄金变更文件的三种主要表示形式：
oracle_full： 完整且未经修改的源文件。oracle_tier： 一种结构化表示，其中非变更位置的代码被渲染为 UML 骨架（类结构）和方法签名，而变更发生的具体位置保持完整。oracle_keep_drop： 一种二元处理方法，其中非变更位置的代码被完全删除，仅保留正在编辑的特定函数/类。
行为探测（“查找/执行”边界）
为了测试压缩表示是否携带可操作信号，作者使用了行为探测：
- 设置： 从
seaborn、pylint 和 pytest 中选取 15 个留出的类。为每个类根据测试文件生成三个探测问题（行为问题）。
- 任务： 智能体（Sonnet 4.6）阅读一种表示（全量源码、前沿模型摘要、3B 模型摘要或签名）并回答探测问题。
- 评判： 使用独立的评判者（GPT-4o-mini）对答案进行评分。
- 控制： 使用前沿模型（Sonnet 4.6）和小型模型（Qwen-3B）生成摘要，以确保“摘要失败”并非由于摘要质量差导致的。
关键结果
1. “执行”上下文极其精简
注册假设（H2）预测，结构化分层（UML 骨架/签名）将比简单的二元保留/删除（keep/drop）方法解决更多的议题。该假设失败了。
- 解析率：
oracle_keep_drop: 25/70 已解决 (35.7%)oracle_tier: 23/70 已解决 (32.9%)oracle_full: 19/70 已解决 (27.1%)
- 统计显著性： 结构化分层与 keep/drop 之间的差异为零（McNemar p=0.75）。当定位完美时，将周围代码渲染为 UML 骨架相比于直接删除它，并没有带来可衡量的收益。
- 成本效率： 压缩后的上下文解决问题的效率比全量文件高出 3–3.7 倍。
- 每个解决案例的成本：约 19K tokens (
keep/drop) vs. 约 94K tokens (full files)。
2. 自然语言摘要无法携带可操作信号
行为探测显示，源代码与摘要之间存在巨大的可操作信息差距。
- 准确率： 全量源码回答了 60% (27/45) 的行为探测。自然语言摘要（无论是前沿模型还是 3B 模型）仅回答了 ~9% (4/45)。
- 表示形式 vs. 摘要器： 这种差距源于表示类本身，而非摘要器的质量。前沿模型的摘要表现与 3B 模型摘要的表现一致。
- 签名： 方法签名 + 文档字符串的表现略好于纯文本摘要（6/45），但仍无法匹配源代码。
- 结论： 自然语言摘要无法回答源代码能够回答的行为问题；其“信号”存在于代码结构本身，而非叙述性摘要中。
3. 运行间的非确定性
一个关键的方法论发现涉及温度为 0 时 LLM 推理的稳定性。
- 观察： 使用字节级一致的协议重新运行
keep/drop 分支（相同模型、相同提示词、T=0），导致 ~9% 的单实例结果发生了翻转（最初为 25/70 解决，重新运行后为 23/70）。
- 启示： 这一噪声底限（~9%）限制了对微小效应值的解释。像本研究（包括其自身的零结果）中报告的 1-2 个实例的差异，在统计学上与推理噪声是无法区分的。
贡献与意义
该论文声称有四个主要贡献：
- 一个经过审计的工具： 一个包含单实例可表达性验证、确定性补丁构建和预注册假设的
resolve@cost 框架，确保每个数字都可追溯到原始人工制品。
- 一个强力的零结果（Powered Null Result）： 提供了证据，证明在预言机定位下，结构化表示层（UML/骨架）相对于二元 keep/drop 并不携带额外的解析信号。这挑战了“结构越多越好”的假设。
- 一个去循环化的“查找/执行”边界： 证明了源代码携带的可操作信号大约是自然语言摘要的 7 倍。至关重要的是，前沿摘要器无法弥合这一差距，这表明局限性在于表示格式，而非摘要器的能力。
- 方法论上的审慎： 量化了单次调用、T=0 API 推理中存在的 ~9% 噪声底限。这表明许多在 SWE-bench 文献中报告的微小效应值（包括本文自身的零结果）可能是由非确定性造成的伪影，而非真实的信号。
范围与局限性
作者明确指出，其结论适用于没有执行反馈循环的单次（single-shot）智能体。他们承认，多轮对话智能体可能会通过阅读更多内容从压缩的上下文中恢复，但在单次运行模式下，“查找”步骤必须是完美的（预言机），且“执行”上下文必须是极简的。该研究并不声称摘要对于导航（查找代码）是无用的，而是强调在与源代码相比时，它们不足以支持执行（编辑代码）。
论文得出结论：对于在给定正确位置后编辑代码的具体任务，所需的最小上下文就是正在编辑的代码本身，而周围的上下文（即使是以结构化形式存在）也几乎没有带来额外价值，同时还会产生显著的 token 成本。
每周获取最佳 machine learning 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。