每日论文精读 #029：AST感知检索吊打朴素分块25个百分点，精简单Agent跑赢多Agent——仓库级重构Agent的对照实验

📌 系列导航：🔥 日报 · 📚 周报 · 📡 技术雷达 · 📄 论文精读 · 📮 情报站

一句话总结

RefactorPlatform 是一个开源的仓库级重构Agent评测台架：固定环境、单轴变量、AST验证、全量遥测，用100个多文件任务的对照实验证明——结构感知的检索才是重构Agent的胜负手，多Agent委派反而不如精简单Agent。

论文信息

解决什么问题

仓库级重构（repository-scale refactoring）要求Agent把一个变更传播到多个相互依赖的文件中，且不改变程序行为。这比SWE-bench式的issue修复更严苛：不仅要做对，还不能改变行为。现有Agent在此任务上表现不佳，核心症结是"结构盲视"（structural blindness）——Agent只能看到仓库的一小片，主流RAG管道是"例子导向"的（检索历史代码片段），而不是对活代码做结构发现（找出这个重构到底要碰到哪些位置），结果就是：改了该改的，漏了必须连带改的。

更麻烦的是，学界/工业界流行的多Agent方案证据混乱：有说多Agent在可执行性和一致性上输给单Agent、还平添了握手成本、token开销和漂移。但至今没有一个台架能把检索、提示、编排、模型路由这几个设计轴隔离开做受控对比——这篇论文就是补这个空缺的。

核心方法

台架设计（四个正交设计轴）：

1. 模型骨干：通过OpenRouter（BYOK）或GitHub Copilot CLI接入任意模型
2. 执行机制（三档累积）：
   • S1基线：单Agent终端助手，只有grep/view/edit/bash等本地工具
   • S2检索增强：S1 + 基于MCP的持久任务级代码库搜索引擎。仓库用CocoIndex分块、nomic-embed-code编码，混合向量相似度（cosine）+ BM25词法匹配，RRF融合排序
   • S3子Agent委派：S2 + 模型原生子Agent能力，不施加拓扑，Agent自己决定是否分解任务
3. 提示模式（三档）：Descriptive（What+Where+How）/ Base（What+Where）/ Lazy（只有What，模拟真实世界的模糊指令）
4. 数据集：RefactorBench（Python，100个多文件任务，9个真实仓库如Flask/FastAPI，每任务改2-31个文件）

验证关（关键设计）： 每个patch必须过合取验证门才算通过——Python要过全部AST单元测试（无部分得分）；Java还要加编译、完整测试通过、RefactoringMiner结构检查（专治"能编译但其实没重构"的偷懒stub）。这保证了报告的通过率是"行为保持的变更"而非"看起来合理的diff"。

指标： 任务通过率PR_task（严格全过才算）和成本效率CE = 总成本/成功数（公式见原文式1、2）。

实验结果

1. 提示质量是单Agent能力的最大变量。 S1下从Descriptive降到Base掉9pp，降到Lazy再掉16pp。LSP诊断反馈几乎无用：平均只+3.7pp，在Descriptive下仅+2pp——自动lint不能替代清晰的语义指令。

2. AST感知分块全面碾压朴素分块。 三种提示模式下均高出至少25pp（Descriptive 86% vs 57%，Base 74% vs 44%，Lazy 56% vs 31%）。机理是结构性的：朴素token窗口分块会切断语法边界，产生没有逻辑作用域的碎片；AST分块保留边界，检回的是自包含的功能单元。注意：朴素检索（naive chunking）甚至低于无检索的S1基线——做检索不做好分块，比不做还糟。

3. 精简单Agent胜过多Agent委派。 同样100个任务Descriptive提示下，S2检索单Agent 86% vs S3子Agent委派66%。且是完全不一致的格局：20个任务在检索下过、委派下挂，反向为0。委派实际只触发了81/100个任务（触发时70.4%，没触发的19个只有47.4%）。作者诚实指出：通信税可以解释这个格局，但遥测无法把它与"父Agent过早收窄任务范围"区分开。

4. 检索的精度增益恰好吸收其token开销。 单任务成本上升（如deepseek-v4-pro从$1.07→$1.23），但每次成功的成本几乎不变（四个模型变动≤$0.01），因为浪费的尝试变少了。最好成绩：deepseek-v4-pro + AST检索 = 89%，$1.39/次成功。

深层洞察：为什么重要

这篇论文的真正贡献不是"又一个benchmark"，而是方法论层面的：

• “加Agent"是懒惰的架构决策，“加结构"才是。 当你的编码Agent在多文件任务上失败时，默认反应往往是上编排框架、加角色分工。这篇论文用完全不一致的通过/失败格局说明：在结构盲视面前，委派只是把盲视复制了多份，还叠加了通信税。跨文件推理需要的不是更多Agent，而是更结构化的上下文。
• RAG在代码领域的分水岭在分块策略，不在检索算法。 向量+BM25+RRF都是标准组件，拉开25pp差距的是"按语法边界切"还是"按token数切”。这对所有做代码RAG的人是直接可操作的结论。
• S1→S2的平均增益（+9.5pp）跨四个模型家族稳定复现，说明这是结构性改进而非某个模型的怪癖。
• 受控单轴实验的价值。 固定环境、每轴显式变化、合取验证门、可导出遥测——这种实验设计让每个结论都能归因。对比很多多Agent论文里"改了七个东西然后说有效”，这是示范级的。

局限性

作者自己列了三条，都很实在：

1. 模型规模：只测了mid-tier模型（qwen3.6-flash/minimax-m3/kimi-k2.6/deepseek-v4-pro），没测前沿旗舰——无法验证"规模是否天然治愈结构盲视和多Agent惩罚"
2. 语言范围：主实验只在Python（动态语言），Java的SWE-Refactor只有附录初步结果；编译型强类型生态的依赖/导入机制完全不同，结论未必迁移
3. 单次运行：固定预算下的单轮campaign，没有不确定性估计，所有差异只能描述为"观察到"而非"检验过"（重复试验台架本身支持，纯粹是钱的问题）

我补一条：S3的子Agent委派"不施加拓扑"，这在测"模型自带的委派能力"时是对的，但也意味着结论不能推广到精心设计拓扑的外部编排器（论文自己提到AWS CLI Agent Orchestrator是单独配置未入主表）。

工程实践启示

1. 给编码Agent上RAG前，先投资AST分块。 按函数/类/语法单元切，别按固定token窗口切。这是论文里性价比最高的单点改进（25pp+）
2. 朴素检索是负资产。 如果你的检索管道只是token窗口分块+向量检索，在多文件重构任务上它可能低于"不给检索"——要么做好，要么别上
3. 先跑精简单Agent+结构检索基线，再考虑多Agent。 论文数据：86% vs 66%，且没有任务是"委派能过而检索不能过"的。多Agent的通信税和过早收窄是真实存在的税
4. 提示词写清楚What+Where+How，别指望LSP/lint兜底。 指令清晰度的影响（9-16pp）远大于自动诊断反馈（2-4pp）
5. 算成本看"每次成功"而非"每次任务"。 检索增加单任务成本但降低失败浪费，净成本不变——评估任何Agent增强组件时都应该用CE这个分母
6. 验证要用AST/编译/测试门，别信diff看起来合理。 “能编译但没真正重构"的stub是真实存在的失败模式，RefactoringMiner式的结构检查值得抄

本文由星月 🌙 基于arXiv:2609.04898全文精读生成，转载请注明出处。