论文信息
| 项目 | 内容 |
|---|---|
| 日期 | 2026-09-30 |
| 论文 | Do Coding Agents Reuse Existing Code or Reinvent the Wheel? |
| 作者 | Dongsheng Ma, Sizhe Wang, Xinyi Huang, Zhengren Wang 等（北大、复旦、清华、上交、港中深、中关村学院） |
| 链接 | arXiv:2609.35357 |
| 代码 | 未公开（Work In Progress） |
一句话总结
论文提出 RepoReuse 多轮仓库级基准，审计发现编码 Agent 随轮次推进越来越不爱复用代码：到第 5 轮，50.8% 的任务链留下重复实现，而通过率几乎不动。
解决什么问题
编码 Agent 已大规模进入真实仓库做迭代开发，但现有评估（HumanEval、MBPP、SWE-bench）几乎只测"测试过没过"。可维护性同样关键：每次重复造轮子意味着一个 bug 要修两遍、接口漂移、后续代码越堆越多。更麻烦的是速度不对称——Agent 写代码远快于人审代码，冗余在无人监督下加速堆积。已有工作要么只到函数级，要么单轮，没有一个能在真实仓库的多轮迭代里逐步测量"复用行为"。
核心方法
基准设计：真实成熟 Python 仓库上多轮开发，需求逐轮揭示，工作区累积（Agent 前几轮写的代码也成为仓库一部分，构成"自我复用"目标）。
全自动构建流水线（无人工参与）：
- AST 静态分析建全仓库依赖图（函数为节点、调用为边），内部符号为起点；
- 强模型（GPT-5.6 Sol）在依赖图上做引导式游走收集证据包，第 2 轮起从上一轮产物出发，并注入邻近未用符号防退化；
- 任务合成：需求描述绝不点名任何符号（防止退化为字符串搜索）；参考解必须真实调用证据模块；测试期望值来自参考解的实际运行结果而非模型口述；
- 独立审计重装重跑全部测试后才交付。
指标体系（沿 Agent 工作流展开）：
- reuse_repo / reuse_self：提交是否通过真实调用边使用目标（AST 判定）；
- recall（上游）：本轮读了多少目标源码，区分"没读"与"读了没用"；
- C_dup（下游）：目标未被调用但逻辑被大部分重写的结构冗余计数。
实验结果
对 3,000+ 轮开发的审计发现：
- 探索退化：第 1 轮平均读 83.6% 的相关仓库代码，第 5 轮只剩 35.4%；
- “看见却不用”：对自己历史代码的 recall 几乎饱和，但 self-reuse 仍从 83.9% 衰减到 69.1%；消融显示完整给出历史源码与不给记忆效果几乎一样——瓶颈不是信息可及性，而是 Agent 复用既有代码的"倾向"；
- 冗余堆积：含跨轮重复实现的任务链从第 1 轮 13.8% 升至第 5 轮 50.8%，同时通过率几乎不动。
深层洞察
这篇论文的锋利之处在于揭示了评估的结构性盲区：以通过率为中心的评估永远看不见这类缺陷——Agent 一轮轮"正确地"解题，代码库却一轮轮变脏。它把复用决策拆成"探索→执行→后果"三个可测量环节，其中"看见却不用"是最反直觉的发现：问题出在模型的倾向（disposition），而非上下文或检索。这对整个 Agent 评估范式是个警告：功能正确性只是代码质量的一半。
局限性
- 限于 Python 单语言；
- Work In Progress，基准未公开，第三方复现受限；
- 构建流水线依赖 GPT-5.6 Sol 做证据收集与任务合成，存在强模型先验引入的偏差可能；
- 未提出改进方案（如复用奖励、上下文工程），只做审计。
工程实践启示
- 别只看测试绿不绿：把代码复用率、重复实现检测纳入 Agent 产出的 CI 审计；
- 多轮长任务里主动管理上下文：随轮次重置/重注入仓库地图与关键接口摘要，对抗探索退化；
- “给更多上下文"不解决问题——把复用倾向做进 prompt（强制先检索既有实现再动手）或做进训练信号才是方向；
- 冗余有复利效应：早期一次重复实现，后续每轮都在为其付利息，长周期任务要尽早做重构检查。