仓库级智能体开始补上证据链：2026-06-23 arXiv 里最值得读的一组软件变更论文

如果把 2026 年上半年的 coding agent 论文粗分成两类，一类还在证明“模型会不会写代码”，另一类已经开始追问“它在真实仓库里到底怎样失败、怎样被验证、怎样被约束、怎样被部署”，那么 2026 年 6 月 23 日这一批新论文明显属于后者。它们的共同点不是继续堆一个更花哨的 agent scaffold，而是把焦点放回软件工程里最麻烦的几个现实问题：多文件上下文怎么找、仓库级任务怎么拆、补丁怎样被确认、测试通过为什么还会漏 bug、agent 产出的代码为什么会在下一轮维护里变差。

这批论文特别值得连续读，不是因为有某一篇“单点爆炸”的大结果，而是因为它们拼出了一个越来越完整的可靠性闭环。你能看到仓库级代码生成开始认真做规划与接口契约，能看到 repository understanding 不再满足于 grep，能看到安全修复系统把 exploit oracle 和 regression oracle 拉回中心，也能看到评测社区开始正面承认：pass@1、resolved、suite all green 远远不够。

对做 Reliable Coding Agents for Real-World Software Change and Evolution 的读者来说，这一天最有价值的不是某个 benchmark 分数，而是一个趋势判断：coding agent 研究正在从“能力展示”转向“证据约束下的软件变更工程”。这和真实仓库、多文件修改、构建与测试反馈、补丁正确性、审计与追责、工业级运行环境之间的关系，比前几个月任何一波“agent team 很强”的论文都更近。

今日脉络

这一天的相关论文大致可以分成四组：

1. 仓库级生成与理解：CodeTeam、DeepDiscovery、Code Isn't Memory、Change Impact Recommendation for JavaScript 关注的是 agent 如何找到足够好的任务上下文、如何跨文件组织修改、如何让定位质量真正变成 solve rate。
2. 可靠性交付与可维护性：Is Agent Code Less Maintainable Than Human Code?、RigorBench、Skill Coverage、AgentMeter、All Green, Still Broken 在追问“做出来”和“后续还能继续演化”之间到底差了什么。
3. 验证闭环与安全修复：Revelio、RAVEN、VeriPort、A11YRepair 的共同点是都不满足于“生成一个看起来合理的 patch”，而是试图提供 exploit、sanitizer、regression、domain rules 等更硬的证据。
4. 复杂工业环境中的 agent 诊断：Holmes、EnterpriseClawBench、When Web Agents Finish but Still Fail、SpecBench 表明真实难点正从“单次解题”转向“异构工件、多模态证据、交互式澄清、企业工作流与真实运行痕迹”。

我会把真正强相关的论文放在深读里：它们要么直接落在 repository-level code change，要么直接推进 agent reliability / verification / industrial debugging 主线。其余论文不会略过，但会按“值得保留的判断”来读，而不是强行都写成一篇长论文。

强相关论文深读

1. CodeTeam：仓库级代码生成终于不再假装“多文件 = 多次补全”

论文信息
标题：CodeTeam: An LLM-Powered Multi-Agent Framework for Repository-Level Code Generation
作者：Yifei Wang, Ruiyin Li, Peng Liang, Qiong Feng, Zengyang Li, Mojtaba Shahin, Arif Ali Khan
链接：arXiv:2606.22082
分类：cs.SE, cs.AI
发布日期：2026-06-23

一句话 TL;DR
它的真正贡献不是“多 agent 写 repo”，而是把仓库级生成拆成了设计草图竞争 + CTO 归一化契约 + 依赖感知实现 + QA 驱动修复这一套相对像工程流程的链路，并且在结构指标和执行指标上都证明这套链路比直接让模型开写更稳。

为什么这个问题重要
从 README 或需求文档生成整个仓库，一直是 coding agent 很容易被高估的任务。因为“看起来像一个 repo”和“真能运行、接口一致、跨文件依赖没崩”是两件完全不同的事。很多仓库级系统只是把函数级生成扩成多轮 prompting，最后出现的大部分错误其实不是语法错，而是接口契约漂移、包结构不一致、import/packaging 崩溃、同一逻辑在不同文件里说法不一致。CodeTeam 把问题重新定义成“先有设计约束、再有实现”，这才开始碰到真实的软件变更工程。

方法怎么工作
论文的 Figure 1 很关键，整条流水线不是平铺的 agent 聊天，而是四个工程动作：

1. 多个 Architect 先从需求文档出发生成不同的软件设计草图（SDS），可选地检索设计参考。
2. CTO 对这些草图做选择和归一化，把它压成可机读的契约：技术栈、文件结构、接口、依赖边界、文件所有权。
3. Developer 按依赖图和 ownership 计划并行写代码，不是所有人同时乱改，而是受一个 dependency-aware scheduler 调度。
4. QA 在临时目录里组装、执行、反馈，再让开发阶段迭代修复。

论文后半段的 ablation 也说明作者不是把这些角色当装饰。去掉架构阶段检索、去掉动态 developer allocation、去掉基于 Git 的协调，都会让结果下降，而且下降不是均匀的：有的伤 sketch 结构，有的伤跨文件一致性，有的会增加 QA 报告的 mismatch failure。

关键实验与证据
这篇的证据相对完整，至少不是只报一个 end-to-end pass rate。

• 在 SketchEval 上，CodeTeam 相对对应的 CodeS 版本，SketchBLEU 提升 4.1（PE）和 2.9（SFT）个绝对点。
• 在外部执行验证 NL2Repo-Bench 上，平均测试通过率达到 34.6%（PE）和 42.3%（SFT），并且与 sketch 指标的排序一致，说明结构收益不是假象。
• 消融里，项目特定 developer allocation 和规划阶段的检索增强分别贡献了 9.9% 和 8.1% 的相对收益。
• 论文还给了 root-cause 分布，明确指出 packaging/import 错误和接口不匹配仍然是主要失效模式，这比只报均值更有用。

局限和可信度
它仍然主要在 benchmark 上验证，距离真实生产仓库的长期演化还有差距。一个更实际的问题是：SketchBLEU 这类结构指标再怎么做 decomposition，也只是 proxy；真正能证明“仓库可演化”的证据还是后续修改、回归测试、人工接手成本。论文也承认执行型 benchmark 的通过率仍然不高，说明“会规划”不等于“会交付”。但相比一大批只在单文件或 issue resolution 上套壳子的 work，这篇至少在问题定义上是站得住的。

与当天主题的关系
它代表的是今天最重要的一条线：仓库级 agent 不能只靠生成能力，必须显式建模规划、依赖和验证接口。它把“repository-level coding agent”从 slogan 往工程流程推近了一步。

2. Is Agent Code Less Maintainable Than Human Code?：agent 代码的问题可能不在“这次能不能过”，而在“下次还能不能接着改”

论文信息
标题：Is Agent Code Less Maintainable Than Human Code?
作者：Shaswat Patel, Betty Li Hou, Arun Purohit, Kai Xu, Jane Pan, He He, Valerie Chen
链接：arXiv:2606.21804
分类：cs.SE, cs.AI, cs.CL
发布日期：2026-06-23

一句话 TL;DR
这篇论文最值得记住的不是“agent 代码更差”这个结论，而是它提出了一个更贴近真实演化的评测问题：同样一段代码，这次修好了，下一轮 agent 再接着改时会不会更容易翻车？

为什么这个问题重要
真实软件演化不是一次性 patch。今天一个 agent 提的改动，明天可能被另一个 agent、另一个人类开发者继续扩展、回滚、修补。只看 resolved 会把很多后效应藏起来：一段代码可能在当前 issue 上是“正确”的，但它偷偷改坏了输入校验、错误处理或者局部接口，使得后继任务更难成功。对于 repository-level agents，这种“可继续维护性”其实比一次性交付更关键。

方法怎么工作
作者提出了 CodeThread。它不是再造 benchmark，而是把现有 repository-level coding benchmarks 转成“两步链式任务”：

1. 先让人类或 agent 生成第一步修改 PR1。
2. 再构造第二步任务 PR2，要求在 PR1 的基础上继续解决后续问题。
3. 比较 HA（human-authored PR1）和 AA（agent-authored PR1）条件下，未来 agent 解决 PR2 的成功率。

这个设计非常有意思，因为它固定了后继求解器和评测协议，真正隔离出来的是“PR1 是否留下了更难维护的代码状态”。论文还进一步看了哪些因素解释差异：传统 maintainability metrics、行为漂移、下游代码尺寸变化、输入校验/错误处理修改等。

关键实验与证据

• 在四个前沿 coding agents、四个 benchmarks 上，agent 在 agent-authored code 上继续解题时，resolve rate 最多下降 13.1 个百分点。
• Table 2 和 Table 3 显示这种差异在多个 benchmark 和任务类型上都存在，不是单一实例。
• 论文的回归分析指出，传统静态 maintainability metrics 解释力很弱；更有解释力的是一些细微行为漂移，例如 input validation 与 error handling 被改写，以及后续代码规模变大。

局限和可信度
它测的是“两步链”而不是长期演化，仍然比真实维护历史短很多；而且 PR2 仍由 agent 完成，没有人类接手版本的完整对照。但这并不削弱它的核心价值：它第一次相对干净地把“当前 patch 正确”和“后续可维护”分离开了。对整个 coding agent 评测方向来说，这个问题的提出本身就比再刷 2 个点更重要。

与当天主题的关系
它直接把今日主题从“功能正确”拉向“演化可靠性”。如果你关心 agent 时代的软件演化，这篇是当天最该优先读的几篇之一。

3. DeepDiscovery：仓库级理解的关键不只是把片段检回来，而是把“任务路径”找出来

论文信息
标题：From Fragments to Paths: Task-Level Context Recovery for Large Industrial Codebases
作者：论文页面列于 arXiv PDF
链接：arXiv:2606.22906
分类：cs.SE, cs.AI
发布日期：2026-06-23

一句话 TL;DR
它的核心贡献不是又做一个 retrieval，而是把 repository understanding 从“找相似片段”改成“找任务相关路径”，用 Location-Inference 两阶段恢复更完整的修改上下文。

为什么这个问题重要
今天很多 coding agent 在大仓库里失败，并不是不会改，而是根本没看见该看的文件。单点检索经常找到的是局部相似片段，而不是这次任务真正涉及的调用链、配置链、数据流链或业务路径。对于跨文件 bug fix、迁移、构建错误和复杂工业仓库，这个差别直接决定后续 patch 有没有可能正确。

方法怎么工作
DeepDiscovery 的做法很符合软件工程直觉：

1. 先做 Location，找到高置信度任务锚点，而不是一开始就扩整个图。
2. 再做 Inference，沿多关系仓库结构恢复与任务相关的更大上下文包。
3. 在预算受限下，只把足够解释任务的上下文送给下游 agent，而不是盲目扩大窗口。

从 PDF 里的 Figure 1 和方法描述看，它把语义线索、结构线索、任务线索结合起来，最终目标不是“召回更多文件”，而是恢复一条可被修改动作消费的任务路径。

关键实验与证据

• 在受控的 end-to-end 评测中，接入 DeepDiscovery 的系统在 SWE-bench Verified 上达到 78.6% Solve Rate，比对应 baseline 高 8.2 个百分点。
• 在组织内部的大规模工业代码库场景里，Full Recall Rate 在大型子项目上提升 1.6 到 9.2 个百分点，在中型子项目上提升 2.5 到 7.4 个百分点。
• 论文还强调它不依赖 heavy offline preprocessing，这对真实落地很关键。

局限和可信度
内部工业数据不可完全公开，所以可复核性不如公开 benchmark 那么强。另一个需要谨慎的点是：更好的 file recovery 不一定自动转化成更好的 patch correctness，尤其当上下文过大时可能反而带来干扰。不过这篇已经比“我们检索更强”更进一步，因为它至少报告了下游 solve rate 而不是只报 recall。

与当天主题的关系
它和 CodeTeam、Code Isn't Memory 一起，构成了今天关于 repository understanding 的最强一条线：仓库级 agent 真正的瓶颈不是 token 不够，而是上下文恢复方式不对。

4. Code Isn't Memory：结构化代码库索引不是花哨配件，而是多文件任务里的因果增益

论文信息
标题：Code Isn't Memory: A Structural Codebase Index Inside a Coding Agent
作者：论文页面列于 arXiv PDF
链接：arXiv:2606.22417
分类：cs.AI
发布日期：2026-06-23

一句话 TL;DR
这篇做了一件非常对的事：在固定模型、固定 harness、固定其余工具的前提下，只消融结构化代码索引，直接测它到底有没有真实因果作用。

为什么这个问题重要
coding agent 社区里有太多“索引、图谱、结构检索很重要”的口头共识，但真正做过干净 ablation 的工作并不多。很多系统同时改了 prompt、tool、planner、search policy，最后说不清到底是哪一环起作用。对想做 CodeAnchor、Exploring Code Analysis 一类工作的研究者来说，这篇比又一个总分更有参考价值。

方法怎么工作
论文采用 within-harness causal ablation：

1. SC-ON：开启结构化 codebase index。
2. SC-OFF：在同一个 harness、同一个模型、同一组 prompts 和 sandbox 下关闭该索引。
3. 再用一个 agentic grep 比较臂做 cross-harness 检查。

关键点是变量控得很死，因此 ON/OFF 差异可以较可信地归因到索引本身，而不是 agent 其它部分。

关键实验与证据

• 在 View B acc@5 上，SC-ON 达到 84.5%，SC-OFF 只有 44.3%，配对 Wilcoxon p < 0.0001。
• resolve rate 从 41.9% 提升到 50.4%，p = 0.003。
• 平均 turns 从 36.2 降到 28.3，tokens 也下降，而 per-cell cost 无显著差异；换言之，它不是“多花钱换正确率”。
• 在多文件任务里收益最大：3+ 文件 bucket 的 acc@5 从 44.9% 到 91.3%，这几乎直接说明结构索引的价值主要出现在复杂变更而不是单文件修修补补。

局限和可信度
这篇做得好的地方恰恰也限定了它的外推性：它验证的是某个具体 harness 里的某种结构索引，而不是所有 graph retrieval 都成立。与 OpenCode 的 cross-harness 差异没有总是显著，也说明“索引有效”不等于“所有实现都大幅领先”。但这并不影响它作为方法学论文的价值：它把“结构索引是否有因果收益”这个问题讲清楚了。

与当天主题的关系
它从工具层面支持了今天的主线：可靠仓库级 agent 的前提，是能稳定地把多文件任务定位到正确的结构路径上。

5. Local LLM Agents as Vulnerable Runtimes：agent runtime 本身开始被当作软件系统审计，而不是只当“模型外壳”

论文信息
标题：Local LLM Agents as Vulnerable Runtimes: A Source-Code Audit of the Agent Runtime Layer
作者：Zhengsong Zhang, Zongze Li, Jiawei Guo, Haipeng Cai
链接：arXiv:2606.21071
分类：cs.CR, cs.AI
发布日期：2026-06-23

一句话 TL;DR
它把 local coding agents 看成“有权限的软件 runtime”，然后用静态规则去审 prompt builder、tool dispatcher、skill loader、permission gate 这些中间层，指出安全边界不只在 prompt injection，也在实现层。

为什么这个问题重要
只要 agent 能碰 shell、文件系统、浏览器、凭据和消息应用，它就已经不是一个普通聊天模型，而是一个 privileged runtime。现实里很多人一谈 agent 安全，就只盯 prompt injection 或恶意 tool description，但真正导致危险动作的边界往往在实现层：参数解析、权限传播、技能加载、记忆写入、网络请求拼接、工具调用转义。对 real-world coding agents 来说，这些都是第一等软件工程问题。

方法怎么工作
作者提出 CLAWAUDIT：

1. 从 STRIDE 推出五类 agent runtime vulnerability taxonomy。
2. 为这些类别写定制规则，而不是只复用通用 CWE 规则库。
3. 在两个后端上落地：47 条 Semgrep 规则 和 30 条 CodeQL 查询。
4. 用 OPENCLAWBENCH 评测，这个 benchmark 有 446 条 source-code-level advisories，且做了时间切分，分 train/test。

这篇的价值在于它没有只做“我们提出一些风险”，而是真做了 taxonomy、规则、benchmark 三件套。

关键实验与证据

• 在 held-out test 上，Semgrep recall 从 21.7% 提到 66.8%。
• CodeQL recall 从 13.8% 提到 75.1%。
• train/test gap 都控制在 4 个百分点 内，说明不是纯粹记住训练 advisories。
• 手工精度审计也诚实地表明：这是 recall-oriented 工具，仍然需要人工 triage。

局限和可信度
论文主要在 OpenClaw 上验证，外推到其他 local agents 还需要更多实例；而且高 recall 规则天然伴随更多误报，想直接做 production gate 还不现实。它也不是在证明“静态分析就够了”，恰恰相反，它更像是在说：黑盒 agent evaluation 根本看不见这些 runtime-level 实现问题。

与当天主题的关系
它把 agent reliability 的讨论从“模型答得对不对”推进到“runtime 是否可审计、可验证、可约束”。这正是 coding agents 进入真实软件工程后绕不开的边界。

6. Holmes：复杂工业移动端崩溃诊断正在逼 agent 学会使用脏证据，而不是理想环境

论文信息
标题：Holmes: Multimodal Agentic Diagnosis for Mixed-Language Mobile Crashes at Industrial Scale
作者：Jia Li, Wenyuan Ma, Ting Peng, Haibin Zheng, Yuetang Deng
链接：arXiv:2606.21963
分类：cs.AI, cs.SE
发布日期：2026-06-23

一句话 TL;DR
这篇论文最有价值的地方，在于它处理的是一个 agent benchmark 常常回避的真实问题：没有可复现环境、代码多语言混杂、系统框架闭源、但工程上仍然必须给出可用 root cause。

为什么这个问题重要
真实工业平台，尤其是移动端和复杂客户端，不会总给你一个干净的 repro repo。大量 crash ticket 只有 stack traces、日志、线程状态、符号信息，甚至调用链一旦进入闭源框架就断了。像 OpenHarmony/HarmonyOS、Android、大型超级应用这一类场景，对 agent 的真正挑战从来不是“写一个函数”，而是在不完整证据里做高价值诊断。

方法怎么工作
Holmes 用的是分层 Retrieve-Explore-Reason 架构：

1. 从 crash report 抽取元数据和诊断锚点。
2. 并行检索多种运行时证据，包括 stack、logs、thread state，以及更低层的寄存器和汇编痕迹。
3. 在探索阶段压缩大搜索空间，把 7000 万行级别代码库缩到少量候选路径。
4. 在 reasoning 阶段输出 fault localization、evidence chain 和修复建议。

这个系统的意义是：它把“运行时脏证据”视作主输入，而不是把 repo 视作唯一真相来源。

关键实验与证据

• 在真实 WeChat crash 上，函数级 fault localization 准确率达到 87.6%。
• 平均诊断时间降到约 77 秒，比人工流程减少 98% 以上。
• 论文不仅给总分，还做了 taxonomy、ablation、per-root-cause breakdown，说明哪类 crash 更容易、哪类更难。

局限和可信度
数据来自单一工业环境，外部可复现性有限；而且 function-level fault localization 高，并不自动等于 patch-level correctness 高。另一个风险是 evidence chain 质量如何影响工程师信任，这比 pass@1 更难量化。但在“复杂工业平台作为 agent 试验场”这个维度，这篇非常有代表性。

与当天主题的关系
它证明了一件值得重视的事：可靠 coding agent 不一定总是从源码出发，也可能从运行时证据出发反推源码修改路径。 这对移动端、系统软件和复杂平台尤为重要。

7. Revelio：当漏洞发现开始要求“先给我可执行证据，再谈智能”

论文信息
标题：Revelio: Cost-Efficient Agentic Memory Safety Vulnerability Detection For Repository-Scale Codebases
作者：论文页面列于 arXiv PDF
链接：arXiv:2606.22263
分类：cs.CR, cs.AI, cs.MA, cs.SE
发布日期：2026-06-23

一句话 TL;DR
Revelio 的核心不是“又一个 agent 发现漏洞”，而是它坚持：只有当漏洞假设被可执行 PoV 和 sanitizer 确认时，才算真正发现。

为什么这个问题重要
repository-scale 安全扫描最怕两种事：幻觉太多，和扩展太贵。纯 LLM 审代码很容易报出一堆“像漏洞”的东西，但维护者最讨厌这种不可验证的噪声。Revelio 的设计抓住了一个关键现实：如果没有 exploit 或 sanitizer 级证据，AI 安全 agent 很难在工程上被信任。

方法怎么工作
从 PDF 里的 Figure 1 和 Figure 3 看，Revelio 是典型的“高召回假设生成 + 强验证收口”：

1. 先用便宜模型和轻量静态分析生成高召回 vulnerability hypotheses。
2. 对候选进行排序，并为高分候选构造 Proof-of-Vulnerability。
3. 通过 sanitizer 做确定性确认，只报告能复现的结果。
4. 采用分阶段模型路由：便宜模型做 hypothesis，强模型做 PoV 构造和调试。

这个架构的研究价值在于，它不是靠 prompt 把一个大模型哄成万能审计员，而是把发现与确认拆成不同阶段。

关键实验与证据

• 在 100 个 CyberGym 项目上，Revelio 找到 175 个有效漏洞，而 Claude Code、Codex、Sorcar 分别只有 55 / 39 / 31。
• 其中 122 个是所有三个 baseline 都没找到的。
• 它对已知漏洞的 recall 是 69%，同时保持 0 false positive。
• 在 fresh-CVE 评测上也保持领先，论文特别用它来反驳“只是记住 benchmark”的担忧。
• 机制验证上，从 prompt-only 阶段到完整 harness，vulnerability found 从 11 提升到 14，known-vuln recall 从 60% 提升到 80%，false positive 从 31% 降到 0%，成本还从 $10.57 降到 $8.43。

局限和可信度
它的适用范围仍然偏向 sanitizer-observable memory-safety 漏洞，业务逻辑缺陷或难以构造 oracle 的场景就没这么容易。它也假设目标仓库可构建、可运行并具备某种测试/执行 harness。这些限制并不小，但恰恰说明这篇的可信度来自边界收得很清楚。

与当天主题的关系
Revelio 是今天“验证闭环”这条线里最漂亮的一篇之一：agent 不只是发现问题，还必须交出可执行证据。

8. VeriPort：补丁回移真正难的不是“改对一版”，而是“在所有受影响版本上拿出可验证证据”

论文信息
标题：VeriPort: Automated and Verified Patch Backporting at Scale
作者：论文页面列于 arXiv PDF
链接：arXiv:2606.22704
分类：cs.CR, cs.SE
发布日期：2026-06-23

一句话 TL;DR
这篇论文把 patch backport 做成了真正的软件变更工程问题：不是把 upstream patch 抄下来，而是要为每个受影响版本同时证明“漏洞被堵住了”和“原有功能没坏”。

为什么这个问题重要
真实供应链安全里，开发者经常不敢升级到最新版本，但又必须修补已知漏洞，所以 backport 是高频且高价值的工程任务。难点不是 patch 会不会 apply，而是 advisory 经常不给最小安全补丁，旧版本 API/结构又不同。一个“看起来像”的 backport 如果仍可 exploit，或者破坏原有功能，在生产里就毫无价值。

方法怎么工作
VeriPort 的设计和 Revelio 一脉相承，但更偏软件变更：

1. 先从 advisory 和版本差异中恢复最小安全补丁（MSP）及相关语义。
2. 再把 patch 适配到每个受影响版本，而不是只修一个目标版本。
3. 用两个 oracle 收口：AUTO_POC 检查 exploit 是否被阻断，AUTOTESTER 检查回归功能是否保留。
4. 对每个 backport 输出证据链，而不是只输出补丁文本。

这篇最强的地方不是“多 agent”，而是把 verification 变成一等公民。

关键实验与证据

• 在 BackportBench 上，VeriPort 解决 95.3% 的 128 个 backport 任务，比最佳已有方案高 22.7 个百分点。
• 在 CVEPatchBench 的 393 个 npm 任务上，相对 Claude Code，pass1 高 16.2 个点，pass3 高 20.2 个点，pass@3 高 13.0 个点。
• 在 MSP 不提供的更现实设置下，Claude Code 和 mini-swe-agent 掉分很大，而 VeriPort 基本稳定，这正说明它不是只会“照着补丁翻译”。
• 消融里，去掉任一 oracle 都会掉分；尤其去掉 AUTO_POC 影响最大，说明漏洞阻断证据不是可有可无的附属品。
• 论文还报告已在生产中生成 5000+ 个 verified backported patches，用于 169 个高危和严重 CVE。

局限和可信度
它的验证链虽然强，但成本也更高，平均每个 advisory 的 wall-clock 时间明显长于通用 agent。另一个限制是它更适合有明确 advisory、可构建、可运行且有可写 oracle 的供应链任务。不过这种“慢但可证”的风格，恰恰更符合高价值安全修复的真实需求。

与当天主题的关系
VeriPort 是今天最能说明“software change engineering”四个字该怎么落地的论文之一：patch 不是文本生成物，而是带证据的跨版本变更对象。

中相关论文速读

RAVEN：把 RAG 和跨文件依赖检索引进自动漏洞修复，但验证强度仍弱于 Revelio / VeriPort

论文信息
标题：RAVEN: Agentic RAG for Automated Vulnerability Repair
链接：arXiv:2606.22647

RAVEN 很相关，因为它同样在做真实 CVE 修复，而且明确引入了 Curator Agent 去恢复跨文件依赖，这正击中“local snippet 不够修复杂漏洞”这个痛点。它在 160 个真实 CVE、两种语言、OOD 设置上做到 83.13% 的整体修复成功率，并强调本地可部署、开源模型、成本可控。这些都很实用。

但我把它放在中相关而不是强相关，主要因为它的“验证闭环”仍然比 Revelio / VeriPort 更软。它更像一个强力 repair pipeline，而不是一个严格的证据工程系统。对做 repository repair 的读者，这篇值得读方法设计和 retrieval 组织方式；但如果你想从中抽“高可信 patch correctness”原则，今天还有更硬的论文。

Change Impact Recommendation for JavaScript：历史耦合和运行时依赖几乎只重叠 22%，这个结论很值钱

论文信息
标题：Change Impact Recommendation for JavaScript: Lessons from History and Runtime Analysis
链接：arXiv:2606.21187

这篇很典型地属于 software change intelligence。作者比较了 co-change pattern、动态依赖分析和两者结合的 hybrid 方法，核心发现是：在更宽的 inspection budget 下，两类候选只有 22% 重叠。换言之，历史演化信号和运行时依赖信号看见的是两套不同的影响传播路径。

这件事对 coding agent 特别有启发。很多 agent 的 repository understanding 仍然偏静态文本或静态图，但这篇提醒你：真实变更影响里，evolutionary coupling 和 runtime coupling 都重要，而且互补性很强。它不是当天最直接的 agent 论文，但对做变更定位、相关位置同步修改和回归测试推荐的研究者来说，是一篇应该保留的“基础设施型”工作。

RigorBench：开始把“工程过程纪律”变成 agent benchmark，但任务规模仍偏小

论文信息
标题：RigorBench: Benchmarking Engineering Process Discipline in Autonomous AI Coding Agents
链接：arXiv:2606.22678

RigorBench 抓住了一个正确问题：coding agent 不能只看结果是否过测，还要看它是否计划、是否验证、会不会 doom loop、是否知道该 abstain、是否破坏 build。论文把这些抽成五根柱子：Planning Fidelity、Verification Coverage、Recovery Efficiency、Abstention Quality、Atomic Transition Integrity。

结果也不差看：结构化 harness 相比 baseline，过程质量分提高约 41%，下游结果也提升 17%。但它目前还是一个 30 任务的小 benchmark，更像一个很有方向感的 measurement proposal，而不是已经完成大规模外部验证的基准。今天值得保留的是它的评测哲学，而不是它的 leaderboard。

EnterpriseClawBench：企业 agent 评测开始不再把“单一分数”当答案

论文信息
标题：EnterpriseClawBench: Benchmarking Agents from Real Workplace Sessions
链接：arXiv:2606.23654

这篇之所以值得保留，不是因为最高分只有 0.663，而是因为它基于真实企业会话恢复出 852 个可复现实验任务，并强行要求评测报告 harness-model combinations、artifact delivery、visual quality、cost、runtime、skill-transfer behavior。这比很多 agent benchmark 只报单一成功率成熟得多。

它和今天主线的关系在于：真实工作空间里的 agent 不只是在 repo 里改代码，还要读异构文件、输出业务工件、通过多模态 judge 检查交付结果。对做仓库级 coding agents 的人，这篇提醒你“真实部署单元”不是模型，而是 model + harness + artifact route。

Skill Coverage：任务成功不等于技能被测试过

论文信息
标题：Skill Coverage: A Test Adequacy Metric for Agent Skills
链接：arXiv:2606.20659

这篇论文很像把软件测试里的 adequacy 概念搬到了 agent skills 上。作者不再只问任务成没成，而是问 skill 文档里写的行为约束到底有没有被 trajectory 真正覆盖。结果很扎眼：在 SkillsBench 上，现有执行轨迹只覆盖了 39.90% 到 43.98% 的 skill behavior constraints。

它和 coding agents 的关系是边缘但明确的：如果你的 agent 越来越依赖 skills / tools / policy docs，那么只看任务成功率会高估系统可靠性。今天把它放在中相关，是因为它更像评测基础设施，而不是直接面向代码变更任务。

All Green, Still Broken：测试全绿仍然漏 bug，这不是口号，是 seam 分布

论文信息
标题：All Green, Still Broken: Real-Flow Verification Lessons from an LLM-Integrated, Multi-Market Web Application
链接：arXiv:2606.22475

这篇更像 industry-flavored 经验论文，但问题切得很准。作者研究一个接入 LLM 的多市场 Web 应用，测试套件在六周内涨到 1553 个 case，依然持续漏出用户可见缺陷。看完 252 个 bug-fix commits 后，他们发现约 44% 的修复落在四类 unit/component tests 看不见的 seam：实时浏览器运行时、非默认市场、端到端 flow、整系统级。

这对 coding agent 研究的启发非常直接：all tests pass 从来不是完整 oracle，尤其在 UI、国际化、外部数据源和 LLM 输出混合的系统里。它不是 agent 方法论文，但它非常适合作为“为什么我们需要 Phantom Rendering / real-flow verification / browser-grounded validation”的现实论据。

SpecBench：好的 coding agent 先把需求问清楚，再决定写不写

论文信息
标题：Turning Intent into Specifications: A Benchmark and an Interactive User-Assistant Agent
链接：arXiv:2606.20585

这篇离“直接改代码”还有一步，但和真实软件变更非常相关：用户 intent 往往本来就是模糊的，很多 agent 失败不是不会写，而是过早进入实现模式。SpecBench 把任务重心前移到“把 intent 变成可执行 specification”，Buddy 用设计维度分解、模拟用户评估和有限轮澄清来生成 spec sheet。

实验里 Buddy 的综合 spec 评分是 4.28，高于 Claude Code 的 4.24，差距不算惊人，但方向是对的。对复杂 repo 任务，这篇提醒我们：真正的可靠性有一部分发生在编码之前。

AgentMeter：模型和 CLI 不是可分离变量

论文信息
标题：AgentMeter: Evaluating Model-CLI Matching for CLI-Based Local Task-Solving Agents
链接：arXiv:2606.21140

这是一个很现实、也很容易被忽略的问题。很多本地 agent 其实是 model + CLI mediator + context replay + tool output formatting + stopping policy 的组合，而不是“模型裸跑”。AgentMeter 证明了同一模型换 CLI，会显著改变 success、token、cost 和 effort profile；甚至 最高 Pass/30、最低 Tok./Pass、最低 USD/Pass 和 最高 AMS 选出的配置都不一样。

这篇中相关的原因是：它更像 deployment evaluation 而不是 code change intelligence 本身。但对做真实 terminal agents 的人，它非常值得记住一句话：部署单元应该是 model-CLI configuration，不是 model alone。

When Web Agents Finish but Still Fail：完成率不是正确率

论文信息
标题：When Web Agents Finish but Still Fail: Reproducible Triggers and Trace Diagnostics for Parallel Web Exploration
链接：arXiv:2606.20724

虽然它是 web agents 论文，但和 coding agent reliability 的评测哲学高度同构。作者在 Parallel WebBench 上发现，GRPO 训练后 completion 可从 50.7% 拉到 96.0%，element-wise F1 从 0.2489 提到 0.4529，但 binary accuracy 仍然远低于 completion。典型失败包括：拿到部分证据后提前终止、上下文循环、证据已经检回但最后综合崩掉。

这就是一个非常清晰的信号：只看“任务是否结束”会系统性高估 agent。对 coding agents，它几乎可以平移成“是否提交 patch”和“patch 是否真的对”的差别。

A11YRepair：多文件、多违规、带领域规则的 web repair，是 repository repair 的一个好测试床

论文信息
标题：A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair
链接：arXiv:2606.21926

这篇与用户主线的关系不是最直接，但我建议保留。因为它处理的是一个典型的多文件 repair 场景：现实 web accessibility 问题经常成簇出现，需要协调修多个相关位置，而不是逐 bug 单独修。A11YRepair 通过 violation grouping、root-cause decomposition 和选择性注入 WCAG 知识来减小冗余定位和 side effects，并构建了 60 个真实项目的 A11YBench。

它的结果说明：一旦 repair 任务带有明确领域语义和多点协同结构，普通 APR 系统就会明显失效。这对未来的 OpenHarmony UI / runtime behavior verification 类工作是个很自然的参考。

可留意 / 可跳过

这些论文我认为与今天主线有边缘关系，但不必在今天深挖：

• Whose Agent Are You? Multi-Layer Fingerprinting and Attribution of Autonomous Web Agents
  保留判断：如果你关心 agent 生态安全和可追责，这篇关于 agent 指纹与归因的工作有参考价值；但它主要是 web security / traffic attribution，不是软件变更本身。

• Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents
  保留判断：它对 capability revocation 和 effect boundaries 的建模很有意思，适合关注安全边界的人；但今天这篇 digest 更关心变更理解、验证和交付，所以先放次级。

• Beyond Simpson's Paradox: A Cascade of Confounders in AI Agent Pull-Request Co-Authorship
  保留判断：这篇提醒你别轻易把 PR co-authorship 关联解释成因果收益，对研究方法很有帮助；但它更多是在拆统计幻觉。

• Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code
  保留判断：它显示人类 reviewer 可能在 AI PR 面前逐渐放松审查，这是非常值得警惕的治理信号；但它不是 agent 内部能力或验证机制论文。

• CLI-Universe / Tmax
  保留判断：这两篇都在推动 terminal agents 的训练数据和 RL recipe，更偏“把 agent 训出来”；如果你今天关心的是可靠软件变更交付，而不是 agent pretraining，这两篇可以后读。

横向比较

论文	问题定义	最关键的证据	工程可迁移性	评估可信度
CodeTeam	从需求生成整个仓库	SketchEval + NL2Repo-Bench 双验证，34.6% / 42.3% 测试通过率	高，尤其适合 repo synthesis 与多文件接口协同	中上，proxy 指标仍多
Agent Code Maintainability	本次正确是否伤害下一次维护	后继任务 resolve 最多下降 13.1pp	高，几乎可迁移到所有仓库级 agent 评测	高，问题设定很扎实
DeepDiscovery	大仓库中恢复任务级上下文	SWE-bench Verified +8.2pp solve	高，适合 repo understanding 前端模块	中上，内部数据较多
Code Isn't Memory	结构索引是否真有因果收益	acc@5 84.5 vs 44.3，resolve 50.4 vs 41.9	很高，直接指导 harness 设计	高，ablation 很干净
CLAWAUDIT	agent runtime 是否可审计	Semgrep 21.7→66.8，CodeQL 13.8→75.1	高，尤其适合本地 agent runtime	中上，主要验证单一平台
Holmes	无法复现时如何做工业 crash 诊断	87.6% fault localization，77 秒平均诊断	高，复杂移动端/工业平台都能借鉴	中上，企业单域数据
Revelio	repo-scale 漏洞发现如何既可信又可扩展	175 vs 55/39/31，0 FP，69% known recall	高，特别适合 sanitizer-friendly 代码库	高，验证闭环强
VeriPort	安全补丁如何跨版本 verified backport	95.3% on BackportBench，CVEPatchBench 全面领先	极高，直接面向供应链修复	高，oracle 设计很硬

我的判断

如果只给今天这一批论文一个总判断，我会说：这不是“最炫的一天”，但可能是今年迄今为止对可靠 coding agents 最有研究含金量的一天之一。

• 创新性：A-
  真正新颖的不是单个 agent 架构，而是把 maintainability、task-level context recovery、verified backporting、runtime auditing 这些长期被忽视的问题推到台前。

• 实用价值：A
  DeepDiscovery、Code Isn't Memory、Holmes、Revelio、VeriPort 都非常接近真实工程动作，不是只在 demo setting 里成立。

• 严谨性：A-
  今天强相关论文里，很多都在认真做消融、跨 setting 验证、oracle 或时间切分；但也有若干工作仍然 heavily 依赖内部数据或 benchmark proxy。

• 与“LLM-based Software Change Engineering”相关度：A
  这一天的主线非常集中：仓库理解、变更传播、可维护性、验证闭环、补丁正确性、工业级运行环境。

最大的不确定性在于两点。第一，很多工业结果还缺跨组织复现。第二，repository-level correctness 与长期软件演化质量之间仍有很长的证据链没补全。也正因此，今天最值得研究者带走的结论不是“谁赢了多少分”，而是：下一阶段真正稀缺的，不再是会写 patch 的 agent，而是能在真实仓库里给出可解释、可验证、可继续演化的软件变更系统。