RELAY 用规则复用加智能体修复历史构建
论文AI 评分 68/100arXiv cs.AI待复核
AI 聚合
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
研究者在 14,159 个 OSS-Fuzz 案例上考察环境衰减问题，发现 69.7% 的案例已无法完成重建与验证，且多数失败集中在少数反复出现的症状上。RELAY 框架让 LLM 从代表性失败中推导并验证确定性修复规则，规则可复用且无需调用模型，规则无法解决的案例再交由逐案例智能体处理。实验显示规则推导可完全自动化，复用规则能达到与逐案例智能体相同的修复量且构建执行次数更少，而智能体能修复规则覆盖不到的案例；先规则后升级的混合方式修复量超过任一单独方案，成本也低于纯智能体方案。
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载环境衰减的规模
论文关注的是历史软件重建中的外部依赖漂移问题：构建过程依赖基础镜像和软件包等资源，而这些资源会独立于源码发生变化。作者在 14,159 个 OSS-Fuzz 案例上量化这一现象，结果是 69.7% 的案例已无法完成重建与验证。这一数字说明漏洞基准与软件工程研究中依赖历史构建的做法面临普遍障碍。材料同时指出，失败并非高度分散，多数失败共享少量反复出现的症状，这为「诊断一次、修复复用」提供了前提。
规则与智能体的分工
RELAY 是一个混合框架。它先用 LLM 从代表性失败中推导并验证确定性修复规则，规则一旦确定，后续复用不再需要模型调用；对于规则无法解决的案例，再交由逐案例智能体处理。作者在人工引导和全自动两种规则推导模式下评估该框架，并与纯逐案例智能体方案对比。结果显示规则推导可以完全自动化，复用规则能达到与逐案例智能体相同的修复数量，同时构建执行次数更少；而智能体的价值在于覆盖规则触及不到的案例。
混合路线的收益
对比结论指向一种顺序策略：先应用规则，再把剩余案例升级给智能体。这种组合修复的构建数量超过单独使用规则或单独使用智能体，成本则低于只用智能体。对需要长期维护历史构建复现能力的团队而言，材料给出的信息是：把重复失败沉淀为可复用规则能减少模型调用与构建执行，而智能体作为兜底处理长尾案例。
为什么值得看
给出可复用的构建修复规则与智能体兜底的混合路线，附大规模失败率数据，对软件工程与 AI 智能体落地有参考价值。
智能体
信源1 家
关键事实
相关 · 论文
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。