目录

代理式编程与工作流编排

• • To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study
• • Constraint Decay: The Fragility of LLM Agents in Backend Code Generation
• • BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases
• • Schedule-and-Calibrate: Utility-Guided Multi-Task Reinforcement Learning for Code LLMs
• • An Empirical Study of Proactive Coding Assistants in Real-World Software Development
• • From Agent Loops to Deterministic Graphs: Execution Lineage for Reproducible AI-Native Work
• • MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System

测试、修复与程序分析

• • SiblingRepair: Sibling-Based Multi-Hunk Repair with Large Language Models
• • Teaching LLMs Program Semantics via Symbolic Execution Traces
• • Exploring the Effectiveness of Abstract Syntax Tree Patterns for Algorithm Recognition
• • Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution
• • Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration

需求、伦理与开发者体验

• • From Chat to Interview: Agentic Requirements Elicitation with an Experience Ontology
• • Operationalizing Ethics for AI Agents: How Developers Encode Values into Repository Context Files
• • Evaluating Non-English Developer Support in Machine Learning for Software Engineering

依赖、供应链与安全治理

• • Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions
• • Modeling Dependency-Propagated Ecosystem Impact of Changes in Maintenance Activities: Evaluating Support Strategies in the PyPI Network
• • On Fixing Insecure AI-Generated Code through Model Fine-Tuning and Prompting Strategies
• • Beyond Accuracy: Policy Invariance as a Reliability Test for LLM Safety Judges
• • Heimdallr: Characterizing and Detecting LLM-Induced Security Risks in GitHub CI Workflows

研究方向：代理式编程与工作流编排

To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study

• • 作者：Shota Sawada, Tatsuya Shirai, Yutaro Kashiwa, Ken'ichi Yamaguchi, Hiroshi Iwata, Hajimu Iida
• • arXiv URL: https://arxiv.org/abs/2605.06464

Abstract

基于 LLM 的自主编码代理已经重塑了软件开发。虽然这类代理在代码生成方面表现出色，但 AI 生成代码的长期可维护性仍有待解答。本研究从实证角度考察了 AI 生成文件与人工编写代码在维护频率、人工参与程度以及修改类型上的差异。我们利用 AIDev 数据集中的 AI 生成 Pull Request 和 GitHub 数据，分析了 100 个热门仓库中的 1,000 多个文件以及约 3,200 次改动。

研究结果表明：(i) AI 生成文件接受维护的频率低于人工编写代码，且更新通常只影响文件规模的一小部分；(ii) 对 AI 代码最常见的修改是功能扩展，而人工更新更多聚焦于修复 bug；(iii) 绝大多数这类维护工作由人类开发者完成。

Constraint Decay: The Fragility of LLM Agents in Backend Code Generation

• • 作者：Francesco Dente, Dario Satriani, Paolo Papotti
• • arXiv URL: https://arxiv.org/abs/2605.06445

Abstract

在宽松规格下，大型语言模型代理表现强劲。然而，生产级软件要求严格遵守结构性约束，例如架构模式、数据库和对象关系映射（ORM）。现有基准往往忽略这类非功能性需求，从而奖励那些功能上正确但结构上随意的解法。我们开展了一项系统研究，评估代理在多文件后端生成任务中处理结构性约束的能力。通过在 80 个全新生成任务和 20 个功能实现任务上固定统一 API 合同，并覆盖 8 种 Web 框架，我们结合端到端行为测试和静态验证器，分离出结构复杂度带来的影响。

研究结果揭示了一种“约束衰减”现象：随着结构要求不断增加，代理性能显著下降。表现较强的配置从基线到完全指定任务，断言通过率平均下降 30 个百分点，而一些较弱配置则接近于零。框架敏感性分析显示出显著差异：代理在更简洁、约束显式的框架（如 Flask）中表现较好，但在更依赖惯例的环境（如 FastAPI、Django）中平均表现更差。最后，错误分析将数据层缺陷，例如错误的查询构造和 ORM 运行时违规，识别为主要根因。

BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases

• • 作者：Jhen-Ke Lin
• • arXiv URL: https://arxiv.org/abs/2605.06136

Abstract

大多数编码代理基准只问生成的代码是否行为正确。这一点当然仍然重要，但在仓库级工程中，工程越来越多地由代理管理：一个代理编写仓库，之后的代理再把它当作工作上下文进行检查、审计或扩展。在这种情境下，生成的仓库不仅是对任务的回答，也是供未来工作使用的沟通工件。即便强大的代理几乎满足可见的行为目标，不同仓库在暴露预期行为及其设计选择的清晰度上也可能存在差异。我们提出 BUILD-AND-FIND，这是一种评估协议，用于衡量下游代理能否从生成的仓库中恢复这些预期选择，以及恢复需要多少检查工作。

对于每个任务，builder 看到隐藏的仓库规格并构建代码库；finder 只能看到代码库和一个与规格追踪的多选题库。该协议将行为正确性与工件侧恢复分开，并报告恢复准确率、可重复性、实现覆盖率和检查工作量。准确率与稳定性作为门槛：只有在恢复可靠成功时，工作量才有解释意义。在能够恢复同一意图的工件中，同一个 finder 所需工作量越低，说明该工件越容易定位该意图。仅问题控制和仅规格控制量化了通用先验与规格访问的影响，而审计则将遗漏的主张与 finder 失败区分开来，并检查正确答案是否引用了工件证据。在我们发布的高先验任务包中，恢复准确率已接近饱和，因此检查工作量和 finder 特定效应成为主要的面板局部比较指标。

Schedule-and-Calibrate: Utility-Guided Multi-Task Reinforcement Learning for Code LLMs

• • 作者：Yujia Chen, Yang Ye, Xiao Chu, Yuchi Ma, Cuiyun Gao
• • arXiv URL: https://arxiv.org/abs/2605.06111

Abstract

强化学习（RL）与可验证奖励已被证明在代码 LLM 的后训练中有效，但为每个任务部署单独的专用模型会带来随任务数量增长的成本，这推动了统一的多任务 RL（MTRL）方法。然而，现有 MTRL 方法将所有编码任务一视同仁，依赖固定的数据课程和共享的优化策略，最终限制了多任务训练的效果。为解决这些局限，我们提出 ASTOR，一个由任务效用驱动的多任务代码强化学习框架，它根据在线学习动态估计每个任务的效用，并利用该信号联合控制数据调度与优化。

ASTOR 的核心是任务效用这一信号，它捕捉每个任务的学习潜力和跨任务协同；ASTOR 包含两个耦合模块：1）分层效用路由数据调度模块，按层次分配训练预算并优先选择信息量大的提示，从而把训练引向最有价值的数据；2）自适应效用校准策略优化模块，动态缩放每个任务的 KL 正则强度，使更新约束与任务当前训练状态相匹配。我们在两种广泛使用的 LLM 和四个代表性编码任务上进行实验，结果显示 ASTOR 能够稳定地改进单一模型在所有任务上的表现，优于最佳任务专用专家 9.0%–9.5%，并超过最强的 MTRL 基线 7.5%–12.8%。

An Empirical Study of Proactive Coding Assistants in Real-World Software Development

• • 作者：Lehui Li, Ruixuan Jia, Guo-Ye Yang, Jia Li
• • arXiv URL: https://arxiv.org/abs/2605.05700

Abstract

基于大型语言模型（LLM）的编码助手已经取得显著进展，但大多数系统仍然是反应式的，需要开发者显式表达需求。主动式编码助手旨在从集成开发环境（IDE）交互和仓库上下文中推断开发者的潜在意图，从而降低交互开销并提供更无缝的辅助。然而，这一方向的研究受限于大规模真实开发者行为数据的稀缺。因此，现有研究往往依赖由 LLM 模拟的 IDE 轨迹，而这些轨迹与真实开发行为的一致性仍不清楚。本文通过一项大规模实证研究，考察这一“模拟到现实”的差距。

我们通过一个定制的 Visual Studio Code 扩展，连续三天收集了 1,246 名有经验的工业界开发者的真实 IDE 交互轨迹，并构建了配对的 LLM 模拟轨迹以进行对照比较。分析表明，模拟轨迹在行为多样性、时间结构和探索模式上与真实轨迹存在显著差异。基于收集到的数据，我们提出 ProCodeBench，一个面向主动意图预测的真实世界基准。我们用代表性的 LLM、检索增强方法和 agentic 基线进行实验，结果显示，在真实 IDE 轨迹上，当前方法仍远未可靠，说明基于模拟的数据评估可能高估现实表现。最后，我们的训练研究表明，模拟数据不能取代真实数据，但在真实世界微调之前使用时可以作为补充。这些发现强调了真实开发者行为数据对于评估和训练主动式编码助手的重要性。

From Agent Loops to Deterministic Graphs: Execution Lineage for Reproducible AI-Native Work

• • 作者：Josh Rosen, Seth Rosen
• • arXiv URL: https://arxiv.org/abs/2605.06365

Abstract

大型语言模型系统正越来越多地被部署为代理式工作流，它们交织推理、工具使用、记忆和迭代改进。这类系统虽然擅长产出答案，却常常依赖隐式的对话状态，因此难以保持稳定的工作产物、隔离无关更新，或在中间工件上持续传播变更。我们提出 execution lineage：一种执行模型，将 AI 原生工作表示为一个有向无环图（DAG），其中包含产生工件的计算、显式依赖、稳定的中间边界以及基于身份的回放。我们的目标不是让模型成为更好的“一次性写作者”，而是让不断演化的 AI 生成工作在变化下仍然可维护。我们在两个受控的政策备忘录更新任务上，将 execution-lineage 的回放与以循环为中心的更新基线进行了比较。

在无关分支更新中，DAG 回放在所有运行中都精确保留了最终备忘录，且零改动、零无关分支污染；而循环式基线会重新生成备忘录，并且经常引入无关上下文。在中间工件编辑中，所有系统都将新约束反映到了最终备忘录中，但只有 DAG 回放在上游保留、下游传播、未受影响工件保留和跨工件一致性方面实现了完美表现。这些结果表明，最终答案质量和状态保持质量是两个不同的维度。强大的循环式基线在任务属于受限的综合/更新问题且所有当前来源都能放入上下文时，仍然可以产出体面的最终输出，但即时任务成功可能掩盖部分状态不一致，而这些不一致会在后续修订中累积。execution lineage 为“什么应当改变、什么应当保持稳定、工作如何跨修订演化”提供了更强的保障。

MAS-Algorithm: A Workflow for Solving Algorithmic Programming Problems with a Multi-Agent System

• • 作者：Yuliang Xu, Xiang Xu, Yao Wan, Hu Wei, Tong Jia
• • arXiv URL: https://arxiv.org/abs/2605.05949

Abstract

算法题求解是评估 AI 编码系统中结构化推理能力的严格试金石，因为它直接反映了模型在复杂场景中执行结构化推理的能力。现有方法主要依赖模型中心化策略，例如架构修改和数据扩展，这些方法成本高且可解释性有限。另一类依赖外部工具或提示技巧的方法（例如 chain-of-thought）则较为碎片化，缺乏统一框架。本文提出 MAS-Algorithm，一种受竞赛程序员和算法工程师实践启发的系统化多智能体工作流，用于算法题求解。我们的框架将端到端求解过程拆解为模块化阶段，使结构化推理、工具集成以及代理之间的灵活协同成为可能。

该设计强调严谨性与可扩展性，使其能够泛化到多种问题类型。基于自建基准的实验表明，该框架在多个 Qwen 系列模型上都带来了稳定改进，平均接收率提升 6.48%。相比之下，在相同数据上进行参数高效微调仅带来 0.89% 的边际提升。我们还在 LiveCodeBench-Pro 上观察到 4.72% 的提升，同时在其他准确率与效率指标上也保持一致改进。除性能提升外，我们还通过全面分析来理解工作流中的推理过程，包括错误模式和跨场景行为；进一步的替换和消融研究表明，单个代理的贡献最高可达 27.7%。这些结果凸显了 MAS-Algorithm 对推进 AI 驱动的算法推理具有强大潜力。

研究方向：测试、修复与程序分析

SiblingRepair: Sibling-Based Multi-Hunk Repair with Large Language Models

• • 作者：Xinyu Liu, Jiayu Ren, Yusen Wang, Qi Xin, Xiaoyuan Xie, Jifeng Xuan
• • arXiv URL: https://arxiv.org/abs/2605.06209

Abstract

开发者往往会在实现相关功能的多个代码位置犯下相似错误。这些位置被称为 sibling，它们共享相似问题，也需要相似修复。准确识别 sibling 并保持修复一致性，是自动程序修复的关键。Hercules 是一项面向 sibling 修复的 SOTA 技术。然而，它受限于对 sibling 位置和提交历史可用性的强假设、基于 AST 的刚性 sibling 匹配，以及不够灵活的模板式补丁生成。为了解决这些限制，我们提出 SiblingRepair，一种面向 sibling 修复的新的基于 LLM 的多处修复（multi-hunk）APR 技术。

以由基于谱的故障定位识别出的可疑位置为起点，SiblingRepair 通过基于 token 和 embedding 的代码匹配搜索语义相关的 sibling 候选项，而不再将发现过程限制为失败测试覆盖或提交历史。随后，它使用 LLM 识别与失败相关的 sibling，并通过两种互补策略生成一致的补丁：同时修复（simultaneous repair），即联合修复多个 sibling；以及迭代修复（iterative repair），即逐步分析候选项以构造补丁。SiblingRepair 还会保留此前可疑位置生成的有希望补丁，并将它们组合为泛化的多处补丁。我们在 Defects4J 和 GHRB 基准上评估了 SiblingRepair。结果表明，SiblingRepair 显著优于包括 Hercules 在内的 SOTA 多处修复技术。我们的评估进一步展示了其修复效率、sibling 检测与修复组件的有效性，以及 LLM 数据泄漏对结果的有限影响。总体而言，SiblingRepair 推进了 sibling 以及一般多处自动修复研究。

Teaching LLMs Program Semantics via Symbolic Execution Traces

• • 作者：Jonas Bayer, Stefan Zetzsche, Olivier Bouissou, Remi Delmas, Michael Tautschnig, Soonho Kong
• • arXiv URL: https://arxiv.org/abs/2605.06184

Abstract

我们提出了一个评测框架，包含基于 SV-COMP 2025 的 500 个 C 验证任务，覆盖五类属性（内存安全、溢出、终止性、可达性、数据竞争），并对 6 个家族中的 14 个模型进行评估。我们发现，整体准确率很高会掩盖一个关键弱点：虽然大多数模型能够可靠地确认属性成立，但对违规的检测却差异很大，并且会随着程序长度增长而显著退化。为弥补这一差距，我们在形式化验证工件上进行训练：用 Soteria 符号执行引擎在通用开源 C 代码上运行，并使用得到的执行轨迹对 Qwen3-8B 进行继续预训练。仅约 3,000 条 bug 轨迹，再加上推理阶段的 chain-of-thought，就能将违规检测提升超过 17 个百分点，使其成为被评估模型中最均衡的准确率配置之一。

在违规检测任务上，经过训练的 8B 模型甚至优于参数规模大 4 倍、但不使用思维链的 Qwen3-32B，并且在整体准确率上也接近后者。轨迹训练与 chain-of-thought 之间呈现超加性：单独使用任一方法都不会带来显著收益，但二者结合后效果明显。改进可迁移到全部五类属性，包括训练轨迹并未直接针对的属性。我们的 28 组配置证实，这些收益来自轨迹语义，而非代码量；同时，轨迹筛选与格式也很重要。

Exploring the Effectiveness of Abstract Syntax Tree Patterns for Algorithm Recognition

• • 作者：Denis Neumüller, Florian Sihler, Raphael Straub, Matthias Tichy
• • arXiv URL: https://arxiv.org/abs/2605.06098

Abstract

自动识别算法实现可以通过提供代码库中所包含关注点的知识，支持许多软件维护与重工程活动。此外，识别诸如 Bubble Sort 之类低效算法并建议更优的库替代方案，也有助于评估和改进系统质量。相关工作的方案存在易用性和可扩展性问题，而且准确率并未得到评估。本文我们研究，基于程序抽象语法树（AST）的模式，是否能提升自动算法识别的效果。为此，我们实现了一个原型，包括：一种专门用于捕捉算法关键特征的领域特定语言，并用它在 AST 上表达搜索模式；一种用于查找这些特征的匹配算法；以及一个初始的“即用型”模式目录。

为生成搜索模式，我们通过算法名称和参考实现的关键特征进行网络搜索，并使用我们的 DSL 对找到的参考实现进行描述。我们在 BigCloneEval 基准的一个子集上评估原型，其中包含 Fibonacci、Bubble Sort 和 Binary Search 等算法。我们取得了 0.74 的平均 F1 分数，优于 Codellama 的 0.35。作为对比，我们还使用了多个代码克隆检测工具，召回率达到 0.62，而表现最好的工具仅为 0.20。

Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution

• • 作者：Ye Shang, Quanjun Zhang, Haichuan Hu, Chunrong Fang, Liang Xiao, Zhenyu Chen
• • arXiv URL: https://arxiv.org/abs/2605.06125

Abstract

随着生产代码演化，测试套件也必须随之演化，才能保持有效。现有的测试演化基准停留在方法级粒度，并预先配对输入，绕开了从完整项目中定位受影响测试的任务，也完全排除了新增测试的需要。我们提出 TEBench，这是第一个项目级的测试演化基准。给定一个项目仓库和一条改变代码的提交，TEBench 要求系统自动识别需要修改的测试、判断何处需要新增测试，并生成相应的测试补丁。我们通过一个四阶段流水线在 Defects4J 项目上构建 TEBench，整理出来自 10 个项目的 314 个任务实例，并提供开发者编写的真值。

每个实例都被标注为一种或多种三类演化类型：Test-Breaking（测试失败）、Test-Stale（测试虽然通过，但已不再能有效验证更新后的行为）和 Test-Missing（新增功能需要新测试）。我们评估了 7 种配置，覆盖 3 个工业代理框架（Claude Code、Codex CLI、OpenCode）和 6 个基础模型，以及一个启发式基线。所有 7 种配置在识别任务上的 F1 都收敛到 45.7%–49.4%，显示出跨框架和跨基础模型的共同性能上限。Test-Stale 最难处理，平均 F1 约为 36%，因为这些配置依赖执行失败信号，缺乏前瞻性的语义推理。在更新任务上，这些配置生成了高度可执行的测试修改，但其表面形式与真值相差很大。轨迹分析揭示了一种反应式的“执行-失败-修复”循环：它对 breaking tests 有效，但在结构上无法处理 stale 或 missing tests。TEBench 可在 GitHub 和 leaderboard 上获取。

Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration

• • 作者：Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar
• • arXiv URL: https://arxiv.org/abs/2605.05564

Abstract

持续集成（CI）系统通常并行运行许多构建。在这种环境下，一次合法的构建失败未必是由触发它的代码提交引起的。这类无关构建失败会浪费开发者精力，因为开发者必须判断失败是否与当前变更相关。我们研究了来自 7 个开源 Apache 项目的 77,354 次 CI 构建失败，以理解并预测无关构建失败。我们发现，开发者在判定一次失败与其提交是否相关时，中位数需要 4 小时。我们还对从 10,316 个潜在无关失败中抽样得到的 371 个已确认无关构建失败进行了文档分析。分析显示，无关测试失败占开发者将构建失败判定为无关的案例中的 20%。

为了预测无关构建失败，我们从与触发提交相关的 issue 报告、issue 评论和 commit 中提取了 33 个特征。我们为 7 个 Apache 项目构建了半监督的 Positive and Unlabeled（PU）学习模型。模型的 precision 介于 0.70 到 0.88 之间，recall 介于 0.30 到 1.00 之间，F1 在 0.44 到 0.91 之间，AUC 在 0.63 到 0.97 之间。特征重要性分析表明，CI 延迟、重复错误消息以及先前评论数量是判断无关构建失败的有用指标。结果表明，PU 学习可以帮助开发者识别那些不太可能由当前提交引起的构建失败。

研究方向：需求、伦理与开发者体验

From Chat to Interview: Agentic Requirements Elicitation with an Experience Ontology

• • 作者：Dongming Jin, Zhi Jin, Yaotian Yang, Linyu Li, Zheng Fang, Yuanpeng He, Wenchun Jing, Xiaohong Chen
• • arXiv URL: https://arxiv.org/abs/2605.05828

Abstract

需求获取访谈在需求工程中至关重要且耗时，而且高度依赖需求分析师的经验。尽管大型语言模型（LLM）的最新进展为自动化这一过程带来了新机会，但现有方法仅依赖 LLM 进行自由形式对话，却没有考虑访谈与开发经验。这导致隐式需求被遗漏、重复提问增多。实际上，经验丰富的分析师在进行需求获取时，会隐式遵循一个结构化的认知框架。受此启发，本文提出一种名为 OntoAgent 的访谈代理，它借助经验本体来引导需求获取。OntoAgent 会自动分析领域特定的需求描述，构建一个经验本体，将需求关注点组织进该本体中，以支持系统化且可解释的访谈。

在访谈过程中，OntoAgent 首先执行四个由本体引导的操作（ParseUser、ScoreOnto、ReRankOnto、GatePrune），以识别相关需求关注点。随后，将选中的关注点与当前对话上下文结合，生成获取问题。为验证 OntoAgent，我们在广泛使用的网站应用领域进行了全面的定量实验。结果表明，OntoAgent 在获取效果和提问效率上均显著优于现有基线，IRE 提升了 33%，TKQR 提升了 21%。消融实验进一步验证了各关键设计组件的贡献。此外，定性用户研究展示了其在真实场景中的实际优势。我们认为 OntoAgent 也可以扩展到其他领域的需求访谈任务。

Operationalizing Ethics for AI Agents: How Developers Encode Values into Repository Context Files

• • 作者：Christoph Treude, Sebastian Baltes, Marc Cheong
• • arXiv URL: https://arxiv.org/abs/2605.05584

Abstract

随着 AI 编码代理嵌入软件开发工作流，开发者开始通过在仓库级上下文文件中编码行为规则来将伦理原则操作化，例如 AGENTS.md 文件。与其抽象地考察 AI 代理的伦理，不如研究伦理与价值观如何已经被翻译为可执行指令，从而塑造代理行为。通过一项初步调查，我们发现开发者已经在嵌入与公平、可访问性、可持续性、语气和隐私相关的指导。这些工件充当了由开发者编写的治理层，将抽象原则转化为开发工作流中具体语境下的自然语言指令。

我们提出一个研究议程，用于研究这种新兴实践，包括编码后的价值在不同社区之间如何变化、多方贡献者在协商这些文件时会出现怎样的治理动态，以及代理是否能够可靠遵守所规定的约束。理解伦理与价值观如何在现代软件工程实践中被操作化，对于将 AI 治理扎根于现实至关重要。

Evaluating Non-English Developer Support in Machine Learning for Software Engineering

• • 作者：Jonathan Katzy, Yongcheng Huang, Gopal-Raj Panchu, Maksym Ziemlewski, Paris Loizides, Sander Vermeulen, Arie van Deursen, Maliheh Izadi
• • arXiv URL: https://arxiv.org/abs/2605.05902

Abstract

大型语言模型在软件工程中的应用日益增加，但无论是代码生成还是其评测，仍然主要以英语为中心。这使我们对当前工具在多语言开发场景中的支持能力缺乏理解，而这类场景中代码会包含非英语自然语言。本文我们研究非英语代码注释生成，以及当前方法对这类输出进行评测的可靠性。我们在五种自然语言上评估五个代码 LLM（CodeGemma、CodeLlama、CodeQwen1.5、GraniteCode 和 StarCoder2）：荷兰语、英语、希腊语、波兰语和中文。我们还对 12,500 条生成注释进行了开放编码研究，由此构建了一个公开发布的人类标注数据集和一个包含 26 种错误类型的 taxonomy。

我们利用这些人工标注来评估神经指标以及 LLM-as-a-judge 流水线的表现。结果表明，生成性能在英语之外显著下降，语言错误最多增加 15.1 倍，同时还伴随频繁的语义不连贯和语义错误增多。更关键的是，我们发现对非英语注释的错误检测表现不足。在传统基于重叠的指标、现成的神经指标、使用更新的多语言、语言特定以及代码特定模型扩展后的神经指标，以及 LLM-as-a-judge 流水线中，没有任何自动方法能够提供可靠而一致的评估。神经指标无法区分正确注释与错误输出，甚至不能区分随机噪声，而且在非英语场景下倾向于高估质量。LLM-as-a-judge 方法与人工标注的一致性最高，但仍无法可靠捕捉重要的语言相关与语义错误。总体而言，我们的结果表明，评测与生成都是多语言工具的关键障碍，而人类判断仍然不可或缺。

研究方向：依赖、供应链与安全治理

Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions

• • 作者：Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao
• • arXiv URL: https://arxiv.org/abs/2605.06279

Abstract

大型语言模型（LLM）如今已广泛参与软件开发工作流，而它们生成的代码中常常包含带有特定版本标识的第三方库导入。这些版本选择可能带来安全与兼容性风险，但此前尚未得到系统研究。我们对 LLM 生成 Python 代码中的版本级风险进行了首次大规模测量研究，使用 PinTrace 这一由 1,000 个 Stack Overflow 编程任务构成的基准，在 10 个 LLM 上进行评估。模型在直接提示时指定版本标识的比例高达 26.83%–95.18%，而在直接创建清单文件时则降至 6.45%–59.19%。

在被指定的版本中，36.70%–55.70% 的任务至少包含一个已知 CVE，其中 62.75%–74.51% 的 CVE 评级为严重或高危。在 72.27%–91.37% 的案例中，相关 CVE 在模型知识截止日期之前就已公开。统计结果显示，所有模型都收敛到同一小撮高风险发布版本，说明这是一种系统性偏差，而非孤立的模型错误。静态兼容性通过率介于 19.70% 至 63.20% 之间，安装失败是最主要原因。动态测试用例进一步验证了这一模式，通过率仅为 6.49%–48.62%。进一步实验确认，这些失败源于版本选择而非代码质量，并且外部锚定的版本约束能够显著降低漏洞暴露和兼容性失败。我们的发现揭示了 LLM 版本选择是一个一等公民级、此前被忽视的风险面。我们已将这些发现披露给所评估模型的社区，其中一些模型已确认该问题。

Modeling Dependency-Propagated Ecosystem Impact of Changes in Maintenance Activities: Evaluating Support Strategies in the PyPI Network

• • 作者：Alexandros Tsakpinis, Emil Schwenger, Alexander Pretschner
• • arXiv URL: https://arxiv.org/abs/2605.06164

Abstract

背景：开源软件生态系统具有稠密的依赖网络，结构上居于中心地位的包如果维护恶化，其影响可能广泛传播。尽管人们对开源可持续性的关注日益增加，现有支持机制仍缺乏一种显式的、依赖感知的生态系统级影响概念来指导支持决策。目的：本文提出一种依赖感知的生态系统影响模型，用以刻画维护活动的变化如何在 PyPI 生态系统中传播并影响其整体状态。基于该模型，我们用这种“依赖传播”的生态系统影响概念来优先选择需要支持的包。

方法：我们将该框架应用于一个包含 718,750 个 PyPI 包和超过 200 万条依赖关系的快照，并将我们的影响驱动支持策略与现有支持机制（Tidelift、Ecosyste.ms 和 GitHub Sponsors）以及作为结构重要性基线的 PageRank 进行比较。结果：我们的结果表明，若按依赖传播影响进行排序，所建模的生态系统影响中有很大一部分（约 80%）可归因于仅 0.1% 的 PyPI 包。相比之下，外部定义的支持集合与生态系统影响的契合程度差异很大。我们还分析了维护者覆盖范围和元数据可访问性，揭示生态系统影响、社会影响力和运营可行性是彼此不同但又互补的支持维度。结论：依赖感知的生态系统影响建模为大规模软件生态系统中的支持优先级排序提供了透明而系统的基础。我们的发现表明，由生态系统管理者、资助机构和运营支持项目的组织推动的有效支持策略，应当用影响感知的决策补充现有分配逻辑。

On Fixing Insecure AI-Generated Code through Model Fine-Tuning and Prompting Strategies

• • 作者：Ali Soltanian Fard Jahromi, Amjed Tahir, Peng Liang, Foutse Khomh
• • arXiv URL: https://arxiv.org/abs/2605.05867

Abstract

AI 生成代码的安全性仍是其广泛采用的主要障碍。尽管代码生成模型在功能性基准上表现强劲，但其输出经常包含 bug 和安全弱点，从而削弱可信度。已有工作探索了多种缓解 AI 生成代码安全问题的方法，例如使用静态分析引导生成和提示工程。然而，这些方法在不同模型和设置下的效果差异很大。本文对一系列 Common Weakness Enumeration（CWE）条目上的模型生成代码加固策略进行了系统研究。我们评估这些策略在不同模型和编程语言上的安全改进程度，采用 fine-tuning 和 prompting 两类方法来细化模型输出。

除了弱点的普遍存在之外，我们还分析了已识别 CWE 的严重性、共现关系，以及修复带来的意外后果，即修复某些弱点是否会在同一代码中的其他位置引入新的弱点。结果表明，安全改进高度依赖具体策略和模型。尽管某些方法能够减少特定类别的弱点，但它们往往会以修复副作用的形式引入新的弱点。更重要的是，没有任何一种策略能在所有模型和场景中持续消除弱点，这凸显了不存在一种对安全 AI 生成代码普遍有效的“万无一失”方案。

Beyond Accuracy: Policy Invariance as a Reliability Test for LLM Safety Judges

• • 作者：Shihao Weng, Yang Feng, Xiaofei Xie
• • arXiv URL: https://arxiv.org/abs/2605.06161

Abstract

LLM-as-a-Judge 流水线已经成为代理安全评测的事实标准，但现有基准把它们的裁决当作真值代理，却不检查这些裁决到底依赖于代理行为本身，还是仅仅依赖于评测政策的表述方式。我们认为，任何可信的安全裁判都必须满足一个基本性质，我们称之为策略不变性（policy invariance），并将其操作化为三个可检验原则：在经过认证的等价改写下，rubric 语义应保持不变；在有意从严格到宽松的阈值变化下，rubric 阈值应保持不变；并且在存在歧义时，应该通过歧义感知校准让裁决不稳定性主要集中在真正有歧义的案例上。

我们将这些原则实例化为一个压力测试协议，并在来自 ASSEBench 和 R-Judge 的轨迹上，对四个代理级裁判进行测试，结果发现一个此前未被测量的失败模式：当今的裁判对有意义的规范变化和无意义的结构改写反应强度相近，且无法区分二者。内容保持不变的策略改写会使最多 9.1% 的裁决翻转，且在这些改写下，18%–43% 的翻转发生在无歧义案例上，因此现有安全评分把“代理做了什么”和“评测器如何被提示”混为一谈。除诊断之外，我们还提出了 Policy Invariance Score 和 Judge Card 报告协议，它们揭示出一个数量级上的裁判可靠性差异，而这一差异在只看准确率的排行榜上是不可见的。我们发布了该协议和代码，以便未来的代理安全基准能够审计自己的评测器，而不是默认信任它们。

Heimdallr: Characterizing and Detecting LLM-Induced Security Risks in GitHub CI Workflows

• • 作者：Bonan Ruan, Yeqi Fu, Chuqi Zhang, Jiahao Liu, Jun Zeng, Zhenkai Liang
• • arXiv URL: https://arxiv.org/abs/2605.05969

Abstract

GitHub 持续集成（CI）工作流越来越多地集成大型语言模型（LLM），用于自动化审查、分流、内容生成和仓库维护。这带来了新的攻击面：外部可控的工作流输入可以塑造 LLM 的提示和输出，而这些输出又可能影响安全决策、仓库状态或特权执行。尽管 LLM 安全与 CI 安全都已被广泛研究，但二者交叉处的问题仍然很少被关注。本文提出了首个关于 GitHub CI 工作流中 LLM 诱发安全风险的研究。我们从完整执行链上刻画该问题，并构建高层风险类别与具体威胁向量的分类法。

为在实践中检测此类风险，我们设计了 Heimdallr，这是一种混合分析框架：它将工作流规范化为 LLM-Workflow Property Graph（L-WPG），并结合触发性分析、LLM 辅助的数据流摘要和确定性传播来合成具体的威胁向量发现。我们在 300 个人工标注的唯一工作流上评估 Heimdallr，其在 LLM 节点识别（F1≈0.994）、触发性分类（99.8%）和威胁向量检测（micro-average F1≈0.917）上均表现出很高的准确率。作为持续检测与披露努力的一部分，我们已经负责任地披露了 802 个存在漏洞的工作流实例，覆盖 759 个仓库，并收到了 71 次确认。