别再把 coding agent 当成会写补丁的聊天机器人：2026-06-24 arXiv 的真正主线是定位、验证与迁移

如果只看标题，2026 年 6 月 24 日这批 arXiv 新论文并没有出现那种一眼就会在社交媒体上刷屏的“全新通用 coding agent”。但对做 Reliable Coding Agents for Real-World Software Change and Evolution 的人来说，这一天反而很值得认真读，因为它把几个真正限制落地的问题同时推到了台前：仓库级 repair agent 到底怎么定位，验证预算怎么分配，已有专家脚本工作流怎么渐进迁移成可演化 harness，多 agent 之间的上下文连续性怎样不靠人脑补，依赖升级这种高频真实维护任务能不能从“单项目修补”升级成“跨项目可迁移修复”。

更具体地说，这一天的强相关论文几乎都在修正一个常见误区：今天很多 coding agent 论文默认“问题已经被看见”，于是主要精力花在生成和反思上；可一旦任务真的落在大仓库、多文件修改、昂贵验证和复杂历史工作流里，决定成败的第一瓶颈往往不是生成，而是你是否拿到了正确证据，以及你是否用合适的代价去消耗这些证据。这也是为什么今天最值得深读的论文，不是那种再包一层多 agent 壳子的系统，而是把定位、控制、迁移、可审计连续性这些“脏活”认真拆开的工作。

如果把它们合在一起看，今日主线很清楚：coding agent 研究正在从“模型能不能写”转向“软件变更链路能不能被可靠组织起来”。这条主线和真实仓库、复杂构建/测试环境、legacy maintenance、跨工具 handoff、以及 OpenHarmony 这类复杂工业平台上的 agent 化软件工程问题，是高度同构的。

今日脉络

今天真正相关的论文可以分成三组。

第一组是 仓库级修复与定位闭环。SHERLOC、Bayesian control for coding agents、BigBag 都在处理“知道哪里错”和“知道何时该验证”这两个常被低估的问题。前者关心 repository-level repair agent 的 fault localization 怎样从 file retrieval 变成 actionable diagnosis；后者关心验证与修复动作如何在成本受限下调度；再后者则把 breaking dependency update 这种真实维护任务提升到跨项目可迁移的 AST transformation 级别。

第二组是 agent workflow 的可迁移性与可持续组织。Toward Self-Evolution-Ready Workflow Harnesses 和 ESAA-Conversational 都不是在卷模型本体，而是在补 software change engineering 里更持久的结构问题：已有专家工作流能否低风险迁移，多个 coding agents 之间的状态与决策能否变成可重建、可审计的事件流，而不是散落在不同供应商会话中的上下文残片。

第三组是 边界、供给链与运行时现实。LemonHarness、AutoSpec、Detecting AI Coding Agents in Open Source、FirmCure、SemChunk-C 都不是今天最核心的主线，但分别触到 workspace 边界、agent safety rules、开源仓库里的 agent 痕迹、复杂 firmware runtime 修复、和代码分块对下游 agent 的结构性影响。它们更像是今天主线的外围证据：真实软件工程语境里，agent 的难点越来越少是“会不会写代码”，越来越多是“如何在受约束系统里稳定工作并留下可追溯证据”。

强相关论文深读

1. SHERLOC：仓库级 repair agent 最缺的不是文件召回，而是带解释的诊断定位

论文信息
标题：SHERLOC: Structured Diagnostic Localization for Code Repair Agents
作者：Hovhannes Tamoyan, Sean Narenthiran, Erik Arakelyan, Mira Mezini, Boris Ginsburg
arXiv 链接：arXiv:2606.24820
分类：cs.CL
发布日期：2026-06-23

一句话 TL;DR
这篇论文真正推进的不是“定位更准一点”，而是把 repository-level bug localization 从“给你几个文件路径”改成“给 repair agent 一份结构化诊断意见”，从而把定位阶段直接嵌进后续修复链路。

为什么这个问题重要
今天很多仓库级 repair agent 的失败，并不是因为模型不会改，而是因为前半段把大量预算浪费在无效搜索上。论文开宗明义地指出，LLM agents 在 repository-level coding tasks 里，常常把接近一半预算花在 fault locating 上。更关键的是，即便现有 localizer 找到了正确文件，它通常只输出 location ranking，而没有告诉下游 agent：为什么这个位置可疑、根因可能是什么、还依赖哪些相邻文件、补哪些测试最关键。对真实软件变更来说，这种“只返回位置不返回诊断”的接口很弱，因为下游 patcher 仍然要重新做一遍理解工作。

方法怎么工作
论文的 Figure 1 把 SHERLOC 设计讲得很清楚。它不是一个依赖微调或多 agent 编排的大系统，而是一个 training-free 的定位框架，由四块组成。

第一步，是一个推理型 LLM 负责提出假设和搜索计划。
第二步，是一个 deterministic executor 替它访问仓库，但工具集刻意压得很小，只保留四类对 LLM 友好的 repository tools：文件查看、字符串搜索、仓库树检查和 import graph navigation。
第三步，是 lightweight self-recovery 机制，专门处理上下文截断、循环探索、tool call malformed、以及最终答案合成失败等常见 agent runtime 问题。
第四步，也是这篇最重要的区别点：最终输出不是单纯的 ranked files，而是一份 structured finding，包含 location explanation、root cause、solution idea、dependencies、testing impact 五个字段。Figure 5 给了一个 Django 案例，能直观看到这种 finding 已经接近一个可消费的诊断工单，而不是纯 retrieval 结果。

这套设计背后的判断很对：repair agent 真正需要的不是更多“候选文件”，而是足够压缩且带因果解释的上下文入口。

关键实验与证据
它的实验证据相对扎实，而且同时覆盖 localization 与 downstream repair transfer。

• 在 SWE-Bench Lite 上，SHERLOC 达到 84.33% accuracy@1。
• 在 SWE-Bench Verified 上，达到 81.27% recall@1。
• 当把 SHERLOC 的 findings 注入下游 repair agent 时，跨 5 个 repair models 和 2 个 agent frameworks，平均 resolve rate 提升 5.95 个百分点。
• 在较弱模型上收益更明显，例如文中给出 Qwen3-Coder-Next 下，SWE-Agent 从 44.7% 提升到 54.0%，OpenHands 从 49.4% 提升到 53.0%。
• 在效率上，平均 localization tokens 降低 36.7%，total tokens 降低 23.1%，说明它不是单纯把更多上下文塞给 agent，而是真的减少了无效搜索。

论文还做了一个很有价值的 finding-quality 分析。Figure 7 显示，高质量 findings 的 resolve rate 可以到 75.9%，而低质量 findings 只有 20.0%。这说明“定位结果能否转移为修复收益”高度依赖 finding 本身的诊断质量，而不仅仅是文件命中。

局限和可信度
它最强的一点也是一个明显局限：论文后半段的质量过滤依赖一个 external judge，而且这个 judge 看到了 ground-truth patch，因此 quality-filtered 结果不能被直接当成 deployment-ready 方案。作者自己也承认，这部分更像 retrospective analysis，而非当前可上线策略。另一个限制是，框架虽然 training-free，但主体仍依赖强推理模型；对更便宜模型是否同样稳，需要更多工程数据。

不过整体可信度仍然高于一批只报 file retrieval 的定位论文。因为它至少证明了三件事：位置找得更准、tokens 更省、下游 resolve 更高，而且这些证据是串在一起的。

与当天主题的关系
SHERLOC 是今天最贴近“仓库级 agent 可靠变更链路”的论文之一。它在提醒我们：repository-level code repair 的中间表示不该只是位置，而应该是诊断证据。这和你关注的 execution feedback、证据锚定、agent QA 主线高度一致。

2. BigBag：依赖升级修复不该永远停留在“给每个项目写一次补丁”

论文信息
标题：Agentic Generation of AST Transformation Rules for Fixing Breaking Updates
作者：Frank Reyes, Benoit Baudry, Martin Monperrus
arXiv 链接：arXiv:2606.24446
分类：cs.SE
发布日期：2026-06-23

一句话 TL;DR
这篇的关键贡献是把 breaking dependency updates 的修复对象从“单项目 patch”升级成“可执行、可迁移的 AST transformation program”，让同一类 API breakage 有机会跨项目复用。

为什么这个问题重要
依赖升级导致的编译失败，是现实仓库维护中最常见、最烦人的长期任务之一。传统 LLM repair 系统大多是在某个 client 项目里把编译弄过，但这对软件演化的帮助很有限，因为同一库版本升级造成的破坏，往往会同时打在多个项目上。若每个项目都单独生成 patch，就失去了 API-level 变化本可复用的结构信息。对 software change intelligence 来说，更有价值的是提炼出“这次依赖变化的修复规则”，而不是只为一个 repo 打一个临时补丁。

方法怎么工作
Figure 1 对 BigBag 的 pipeline 描得很清晰，一共四步。

第一步是 Input Context Assembly。系统会把 client 项目里的编译错误、相关源代码、依赖 API 文档等修复所需上下文拼起来。
第二步是 Transformation Generation and Application。agent 不直接改目标仓库源码，而是生成 AST transformation program，底层可落在两种引擎上：Spoon 或 JavaParser。
第三步是 Transformation Verification。论文非常强调这一点：要把生成的 transformation 重新单独应用回原始项目，在 agent loop 之外再次跑 build，确认真正起作用的是 transformation 本身，而不是 agent 在循环中顺手做的别的隐藏修改。
第四步是 Cross-Project Transfer。把通过验证的 transformation 应用于遭受同一 breaking change 的其他 client projects，测试它能否迁移。

这个设计的工程味很足，因为它抓住了一个常被忽略的点：agent 在全自治修复时很容易偷偷做出额外 edits，所以如果不做 isolated verification，你根本不知道“可迁移规则”是否真实成立。

关键实验与证据
这篇的实验对象很贴近真实维护：作者在 BUMP benchmark 上评测 157 个 breaking dependency updates，覆盖 69 个 client projects 和 70 个 libraries。

• 最强配置 GeminiCLI/Gemini-3.1-Pro + JavaParser 的 Fix Rate 为 78.6%。
• 八个配置上的 Compilable Rule Rate 差异很大，最佳能到 94.3%，说明 model 选择和 transformation engine 选择都显著影响结果。
• 如果做 multi-model ensemble，论文估计 JavaParser 上可达 99.4% CRR，Spoon 上 98.7% CRR，也就是“能生成可编译 transformation”这一层已经很接近全覆盖。
• 真正更重要的是跨项目迁移：作者报告总体 Cross-Project Fix Rate 为 33.3%，即 43/129 个可复现实例能被迁移修复。
• 论文还指出 Test Failure 在部分配置里占比很高，例如 OpenCode/GPT-5.4-mini/JavaParser 有 17.7%，OpenCode/DeepSeek-v3.2/JavaParser 有 14.2% 的案例是“编译修好了但行为改坏了”。

这最后一个结果尤其重要，因为它提醒我们：对真实软件变更，build success 只是第一层，测试失败才是规则泛化时最容易暴露的真实语义风险。

局限和可信度
BigBag 的强点是问题定义和 verification protocol 都站得住，但它也有几个限制。首先，它聚焦的是 Java 生态和 breaking API updates，外推到动态语言、多运行时构建场景、或者非 API-level 维护任务，还需要新证据。其次，33.3% 的跨项目 fix rate 说明“规则可迁移”确实存在，但距离通用自动化还远。最后，它的验证目标主要围绕 compile 和 test，对更深层运行行为或性能回归覆盖有限。

尽管如此，这篇依然很值得重视，因为它把“repository repair”从 instance-level patch 往 “change pattern synthesis” 推了一步。这正是 software evolution 里更有复利价值的方向。

与当天主题的关系
BigBag 支持今天的第二条主线：可靠软件变更 agent 不该只学会给当前仓库打一补丁，而应该尽量提炼出可验证、可迁移的变更规则。

3. Bayesian Control for Coding Agents：昂贵 verifier 不是多跑几次就更稳，关键是何时值得跑

论文信息
标题：Bayesian Control for Coding Agents
作者：论文 PDF 未在首页显式突出完整作者行，此处以 arXiv 页面为准
arXiv 链接：arXiv:2606.24453
分类：cs.AI, cs.CL
发布日期：2026-06-23

一句话 TL;DR
它把 coding agent 编排正式建模成一个 cost-sensitive sequential hypothesis testing 问题，核心不是“多加 verifier”，而是根据当前正确性后验、critic 信号和 verifier 成本，决定现在该 refine、该 verify、还是该停。

为什么这个问题重要
做真实仓库级 agent 的人都知道，verification 往往既必要又昂贵。轻量 critic 可能只是语法检查、单测片段或 LLM judge；重型 verifier 可能是完整 build、Dockerized eval、integration test，甚至 UI/runtime replay。很多 orchestrator 现在仍然用固定规则，比如“先生成一次，再跑测试，不行再反思”，这其实默认了 verifier 成本和信息价值是静态的。可一旦环境复杂、测试昂贵、token 预算有限，这种固定策略很快会变得粗糙。

方法怎么工作
论文的 Figure 1 给了一个相当标准但又很有用的建模框架。

第一步，控制器维护一个候选补丁正确性的后验 belief state。
第二步，它把不同动作统一到一个决策空间里：生成新候选、调用便宜 critic、调用昂贵 verifier、或直接停止。
第三步，用 critic 的 noisy signals 和 refine transition 的统计规律做 Bayes 更新。
第四步，基于 Bellman 方程导出两类控制器：one-step Bayesian greedy 和 finite-horizon Bayesian dynamic programming controller。

作者特别强调，动作选择不应只看“当前通过率”或单一 tool success，而应看价值-成本权衡，也就是“这次多花一次 critic / verifier 调用，预期能换回多少 correctness 信息或修复收益”。

关键实验与证据
这篇实验范围不小：覆盖 6 个 generators、9 个 coding benchmarks，而且不是只在单一 benchmark 上讲故事。它最强的地方不是某个单点绝对分数，而是把不同 regime 划出来。

• 论文明确报告，Bayesian control 在 verification 成本高、先验成功率低、critic 有一定信息量但非近似 oracle 的区域最有价值。
• 相反，当 public test critic 已接近 oracle，简单的 gate(Crtest) 往往就够了，复杂 Bayesian aggregation 不会带来多少额外收益。
• 论文还测了 belief state 作为 uncertainty quantification 的效果，Table 1 指出它在 LCB-Medium 和 LCB-Hard 上优于 token probability 和原始 tool success 之类的 baseline。
• 从 Figure 4 的 verifier-cost sweep 可以看出，随着 Cver 升高，最佳策略会从“直接 verify”切换到“先 gating”，再切换到“Bayesian controllers 主导”，这对设计真实 SWE-bench-like harness 很有启发。

这篇论文没有把结论吹成“Bayesian 永远最好”，反而把“何时值得用复杂控制器”说清楚了，这一点非常加分。

局限和可信度
它的局限也很明显。首先，这篇更像 orchestration methodology，而不是 end-to-end repo agent 系统论文，所以你无法直接从中得到一个落地 repair pipeline。其次，belief update 依赖 held-out calibration data，真实线上环境如果任务分布漂移，参数可能需要重估。再者，论文强调的是成本敏感控制，默认 correctness 可以被二元化建模；现实中的 partial correctness、silent semantic bug、multi-objective quality 并不总能被这一框架自然吸收。

但就 agent reliability 来说，这篇很重要，因为它在逻辑上把“验证闭环”从经验规则推进成了显式决策问题。相比“To Run or Not to Run”式的经验观察，这里给了更系统的控制视角。

与当天主题的关系
它直接服务于今天的主线之一：验证不只是要不要做，而是如何在预算受限的真实 agent loop 里被理性调度。 对复杂仓库、昂贵测试、移动/工业平台运行反馈尤其 relevant。

4. Toward Self-Evolution-Ready Workflow Harnesses：真正难的不是从零造 agent，而是把已经在跑的专家脚本系统迁过去

论文信息
标题：Toward Self-Evolution-Ready Workflow Harnesses: A Reversible Migration Path and Convertibility Taxonomy for Expert LLM Pipelines
作者：论文 PDF 以案例论文形式呈现，作者信息请以 arXiv 页面为准
arXiv 链接：arXiv:2606.24598
分类：cs.SE, cs.AI, cs.LG
发布日期：2026-06-23

一句话 TL;DR
这篇最有价值的地方，是把“把现有 LLM+script workflow 渐进迁移成可演化 harness”当成独立研究问题来处理，并给出 Strangler-Fig 式迁移路径与 convertibility taxonomy，而不是假装所有有价值系统都能从零重写成 agent。

为什么这个问题重要
现实组织里大量有效的 AI 工作流并不是原生 agent，而是“专家脚本 + 一些模型调用 + 人工规则”的混合系统。它们往往已经产生业务价值，但缺乏可演化性、可审计性和反馈驱动调整能力。学术界却更偏爱 greenfield agents 和 benchmark settings，仿佛迁移成本不存在。对 software evolution 研究来说，这种忽视很不现实，因为大多数工业 adoption 问题根本不是“要不要上 agent”，而是“如何不打断已有价值系统地逐步迁移”。

方法怎么工作
这篇的 Figure 1 和 Figure 2 是关键。

首先，作者提出一条 reversible Strangler-Fig migration path。不是一次性重写，而是先包裹旧系统，再逐步把逻辑抽成可独立执行、可签合同的 stage。
其次，harness 的核心组成包括：typed stage、decision engine、safety gate、human checkpoint、trace。也就是说，它把 agent 化理解成“在阶段边界上引入受控自治”，而不是把整条 workflow 一次性交给模型。
第三，也是最关键的概念创新，是 convertibility routing stage。作者不假设每个 legacy workflow 都可直接 agentify，而是把“这个 workflow 能否分解成 typed independent stages”本身当成一个判断步骤。Figure 2 的决策程序就是围绕这个问题展开的。
第四，论文给出 A/B/C 类型 convertibility taxonomy，并结合 migration cost checklist 来判断某条 legacy pipeline 该如何迁移，或者是否应该先 code-first refactor 再谈 agent 化。

这个框架的价值在于，它终于开始正视 agent adoption 里的“组织与结构债务”。

关键实验与证据
证据层面，这篇不像 benchmark 论文那样有大规模对比，而是一个生产案例研究。作者在一个真实的微信公众号工作流上报告：

• 9 个 expert functions 被迁成 9 个 independently runnable tools。
• 0 business-logic change。
• one-flag rollback。
• no production disruption。

这些数字看起来朴素，但它们比很多花哨 benchmark 更贴近 industrial migration 的核心诉求。论文还在表格里详细列出 migration cost、stage contracts、安全不变量和 subprocess engine vs agent engine 的差异。

局限和可信度
它最大的限制是只有单案例，且领域是内容工作流而不是软件仓库操作流，所以外部效度有限。作者也比较诚实，明确把这篇定位成“single-case study honestly bounded”。但这并不妨碍它在概念上很有价值，因为“convertibility”这个词把很多组织里模糊的 agent 迁移争论说清楚了。不是所有工作流都该直接 agentify；更现实的问题是它有没有可分解、可审计、可逆的 stage 边界。

与当天主题的关系
对真实软件工程 agent 来说，这篇的迁移视角非常重要。无论是 complex repo repair pipeline，还是 OpenHarmony 这类复杂平台上的 build-test-run workflow，真正难的常常不是新造一个 demo agent，而是把已有可靠流程逐步迁成可反馈、可验证、可追责的 harness。

5. ESAA-Conversational：多 coding agents 时代，真正缺的是可重建 handoff，而不是更长上下文窗口

论文信息
标题：ESAA-Conversational: An Event-Sourced Memory Layer for Continuity, Handoff, and Curation Across Heterogeneous LLM Coding Agents
作者：论文 PDF 以 ESAA 系列工作延伸形式呈现，作者信息请以 arXiv 页面为准
arXiv 链接：arXiv:2606.23752
分类：cs.SE
发布日期：2026-06-23

一句话 TL;DR
它的关键不是再做一个 memory module，而是把跨 agent 连续性重写成 event sourcing 问题，让 handoff、state、decisions、tasks 都来自 append-only conversation log 的 deterministic projection。

为什么这个问题重要
多 agent、跨工具 coding workflow 已经是现实：开发者会在 Codex、Claude Code、Grok 之类工具之间切换，也会因为上下文窗口、权限边界、子任务专业化而反复 handoff。问题是，这些 agent 的对话状态通常各自封存在私有日志里，导致目标、决策、开放任务和验证结果在切换时不断漂移。今天很多所谓“memory”工作只是在做检索或摘要，但没有把 continuity 设计成可重建、可审计的系统对象。

方法怎么工作
ESAA-Conversational 的方法并不复杂，但软件工程味很强。

第一步，把 visible conversation 机械记录到 append-only 的 .conversation-esaa/activity.jsonl。
第二步，不手写 state，而是从事件流 deterministically 投影出一组 read models，比如 handoff.md、state.md、decisions.md、tasks.json。
第三步，新 agent 接手时，不是让人类重新总结上下文，而是从这些 read models 和 selective window 中冷启动。
第四步，把 continuity、handoff、decision provenance、task projection 统一到同一个 event-sourcing 语义里。

这个设计背后的软件工程思想其实很传统：日志是真源，状态是投影；不要靠人工维护脆弱摘要。这比很多 agent memory 论文更靠谱，因为它首先解决了 provenance 和 reproducibility。

关键实验与证据
这篇更偏系统设计与长期使用经验，不是 benchmark 型论文。PDF 明确强调两类目标：

• 一是展示 event-sourced conversational layer 在 sustained real-world use 中是否可行。
• 二是展示 selective、deterministic handoff 对多 agent coding continuity 的实际价值。

它提供的证据主要是 artifact 设计与使用流程，而不是大规模 A/B 数字。Table 1 列出了一整套核心工件，论文中也举例说明 handoff.md 和 decisions.md 如何在实现前提供稳定的上下文接力。

局限和可信度
这篇不是严格意义上的评测论文，缺少大样本对照和量化成效，因此很难据此断言它对 resolved rate 或 token efficiency 的提升有多大。它更像一篇系统构件论文。即便如此，它依然值得关注，因为多 agent coding 现实里最常见的失败之一就是 context drift，而这篇至少给出了一条可审计的工程路线。

与当天主题的关系
它补的是今天主线里的组织层短板：当 coding work 横跨多个 agent、多个回合、多个会话时，连续性本身就是一种软件工程 artifact，需要像事件流一样被治理。

中相关论文速读

LemonHarness Technical Report：workspace state 终于被当成一等对象

LemonHarness 关注的问题很贴近真实 coding agent runtime：agent 实际修改的是文件系统状态，但它通常只能“看到”工具输出和日志碎片，看不到一个清晰的 workspace boundary。论文围绕这一点设计 harness，把文件写入、临时产物、状态扩散等行为变成可约束、可观测的对象。它和今天主线的关系在于：如果没有稳定的工作区边界和状态可见性，仓库级 agent 的审计、回滚、故障归因都会变得很脆弱。之所以没有放进强相关，是因为这篇更偏 runtime/infrastructure report，关于 repository-level task success、patch correctness 或长期演化收益的直接量化还不够。

AutoSpec：安全规则也该随 agent 行为与环境共同演化

AutoSpec 把 LLM agent 安全规则学习成一个 inductive logic programming 问题，目标是缓解手写规则“过松漏风险、过紧拦好操作”的两难。对做真实代码 agent 的人，这篇的意义在于它把 destructive commands、敏感数据泄露、domain constraint violation 等风险纳入可演化规则空间，而不是只做静态黑名单。它和今天主线是边缘相关，因为讨论重点是 agent safety governance，而非 repository repair 本身；但如果你关心 agent 在 shell、文件系统、企业环境中的可靠部署，这篇值得保留。

Detecting AI Coding Agents in Open Source：agent 已经进入供给链，但痕迹高度碎片化

这篇论文做的是供给链侧实证：通过配置文件、commit message、author identity 和 bot signatures 等多层方法，在 1.8 亿+ Git 仓库上估计 AI coding agents 的真实存在形态。它的价值不在于算法复杂，而在于提醒我们：agent 代码已不只是实验室现象，而是在开源生态中以多种弱痕迹进入。对软件演化研究，这意味着未来关于 maintainability、review burden、supply-chain trust 的研究，会越来越需要“agent-produced change”这一观测维度。之所以不深挖，是因为它更偏测量研究，和当天的定位/验证主线没有直接方法学耦合。

FirmCure：复杂 runtime 修复值得关注，但目标更偏 firmware rehosting

FirmCure 是一篇很强的复杂环境代理修复论文：它把 Linux-based firmware rehosting 的障碍分成 perception、boot-time synthesis、runtime fault resolution 三层，再用 manager + specialist agents 做 sequential handoff。它对你这条研究线有启发的地方，是它证明了复杂环境中的 agent 修复必须消费脏证据、分阶段修复、避免一次性乱改；这和移动平台、复杂工业软件栈上的 bug fixing 很接近。没有放进强相关，主要因为论文对象是 firmware security analysis，而不是 repository-level software change。

SemChunk-C：代码分块结构会影响下游 agent，但今天还只是基础能力层

SemChunk-C 做的是 C-family 代码的语义分块。它报告在手工测试集上平均 90.03% chunk boundary accuracy 和 96.08% category accuracy，并展示对 retrieval / generation 下游任务的帮助。这个方向和 CodeAnchor、Exploring Code Analysis 一类工作有一定接壤，因为 chunk quality 确实会影响大仓库上下文恢复。但这篇更偏基础 representation work，还没直接进入仓库级变更验证链路，因此留在中相关末尾。

可留意 / 可跳过

• NatureBench: Can Coding Agents Match the Published SOTA of Nature-Family Papers?：可留意它对 containerized scientific environments 的构建思路，但主任务是科研复现，不是软件变更工程。
• Privacy Engineering: A Systematic Literature Review：可留意其中 verification/testing 与 governance/accountability 维度，但它是领域综述，不是 coding agent 论文。
• CONDUCTOR: An LLM-Orchestrated Digital Twin for Uncertainty-Aware Distribution Grid Operations：保留“LLM orchestrates heterogeneous solvers in high-stakes domain”这个判断即可，对 coding agent 本体关联较远。
• Critique of Agent Model：是概念性反思，不是软件工程证据论文。可留意其对“何为 agent”的界定，但当天 digest 不必深挖。

横向比较

论文	问题定义	最强证据	工程可迁移性	可信度风险
SHERLOC	repository-level repair 的诊断定位	SWE-Bench Lite 84.33% acc@1，Verified 81.27% recall@1，下游平均 +5.95pp resolve	高，直接可嵌入现有 repair agent	quality filter 依赖外部 judge，deployability 仍待验证
BigBag	breaking update 修复规则生成与跨项目迁移	157 个 breaking updates，最佳 78.6% Fix Rate，跨项目 33.3%	高，尤其适合 dependency maintenance	主要限于 Java/API-level updates
Bayesian Control	verifier / critic / refine 的成本敏感编排	6 generators × 9 benchmarks，清楚划分何时 Bayes 有利	中高，适合设计 agent harness 控制层	correctness 二元化较强，需校准数据
Workflow Harnesses	legacy expert workflow 向可演化 harness 迁移	9 functions -> 9 tools，0 业务逻辑变更，可回滚	高，尤其适合工业 adoption	单案例，软件仓库场景外部效度有限
ESAA-Conversational	多 agent coding handoff 的连续性治理	append-only log + deterministic projections 的工件设计	中高，适合多 agent 协作流	定量评测不足，更像系统设计论文

我的判断

如果只看“能不能直接帮助你这条研究线推进”，今天是一个 强方法日，不是强 headline 日。我的主观分级如下。

• 创新性：A-。不是靠单个大模型结果取胜，而是几篇论文一起把 repository-level diagnosis、verification control、migration、continuity 这些长期被弱化的问题推到了前台。
• 实用价值：A。SHERLOC、BigBag、Bayesian control、Workflow Harnesses 都有很强的工程可迁移性，尤其适合拿来塑造真实 coding agent 的系统分层。
• 严谨性：B+。SHERLOC 和 BigBag 的证据最实；Bayesian control 的方法学清晰；Workflow Harnesses 与 ESAA-Conversational 更偏系统/案例论文，量化外部效度有限。
• 与用户方向相关度：A。这一天的主线几乎正对 LLM-based Software Change Engineering：不是提示词技巧，不是单文件生成，而是仓库级定位、执行/验证反馈、变更可迁移性、agent 组织结构与连续性。

不确定性主要有两点。第一，今天部分最有启发性的论文是系统或案例导向，而不是公开 benchmark 上的大规模横向压制，因此“研究价值”高于“立刻拿来刷分”。第二，像 Workflow Harnesses、ESAA-Conversational 这样的工作非常接近工业真实问题，但短期内还很难靠统一 benchmark 获得漂亮数字，这要求读者自己有能力判断“结构性价值”而不是只看 leaderboard。

如果要给今天一个总判断，我会说：2026-06-24 这批与 software change engineering 最相关的 arXiv 论文，在共同纠正一个偏差：可靠 coding agent 的中心任务，不是更会写，而是更会定位、更会验证、更会迁移、更会交接。 这比再多一个“会修 30% SWE-bench”的 agent，更接近真实软件仓库里真正难的问题。