RucTangle:让编码智能体的提交保持可运行

论文AI 评分 72/100arXiv cs.AI
AI 聚合

本条为 AI 依据下方公开信源自动整理生成的摘要,不构成转载,可能存在偏差,请以原文为准。整理者:贝果科技 AI 资讯助手。

针对编码智能体生成的大块混杂补丁难以审查的问题,论文提出 RucTangle,一种在拆分提交时保证每次提交后代码仍可运行的智能体方法,并配套 TangleEval 评估框架,量化整理后的提交历史如何帮助编码智能体修复缺陷。在 131 个智能体生成的补丁上,RucTangle 产出的历史全部可运行,基线方法有 20.6% 至 37.4% 的历史不可运行。另用 453 个引入回归的补丁测试,将 RucTangle 生成的历史加入智能体上下文后,pass@1 绝对提升 5.2%。

全文梳理

AI 摘要依据下方信源原文自动整理,非原文转载

混杂补丁带来的审查难题

编码智能体在完成任务时往往一次性产出体量庞大、目的混杂的补丁,多个开发意图交织在同一份改动里,人工审查与后续维护都变得困难。提交拆分(commit untangling)的思路是把这类大补丁重新组织成若干条边界清晰、便于管理的提交。论文指出,已有研究存在两点不足:一是没有考虑拆分后的提交是有顺序的,且应当保证代码在每一步之后仍能运行,而维护者通常不会接受让代码跑不起来的提交;二是已有工作只是把拆分结果与开发者原始提交做语法层面的比对,并没有直接展示所声称的维护收益。

RucTangle 与 TangleE…

为填补上述空白,论文给出两项贡献。其一是 RucTangle,一种智能体式方法,在拆分提交的同时保证每条提交之后代码仍处于可运行状态。其二是 TangleEval,一个评估框架,用来量化经过拆分、更易管理的提交历史究竟能在多大程度上帮助编码智能体修复缺陷。这两项工作把「可运行」和「可验证的维护收益」作为拆分质量的核心指标,而不是停留在提交与原始改动是否形似的层面。

可运行率与修复收益

实验在 131 个智能体生成的补丁上,将 RucTangle 与四种拆分方法对比:RucTangle 产出的所有历史都可运行,而基线方法产生的不可运行提交历史占比在 20.6% 到 37.4% 之间。论文另外收集了 453 个引入回归的智能体生成补丁,即导致此前通过的测试转为失败的改动,并让另外两个编码智能体去修复这些回归。把 RucTangle 生成的历史加入智能体上下文后,pass@1 取得 5.2 个百分点的绝对提升。

智能体如何使用提交历史

论文还分析了智能体的执行轨迹,观察它们如何借助拆分后的提交来定位和修复缺陷。作者由此提出,在编码智能体时代采用成熟的软件工程实践是有价值的,并给出一个更宽的研究方向:智能体能否主动利用软件历史,做出更好的开发决策。这一视角把提交拆分从单纯的代码整理动作,扩展为智能体可读取、可利用的上下文来源。

为什么值得看

把软件工程里的提交拆分实践引入编码智能体,并首次量化其对缺陷修复的实际收益,对做智能体工具链的人有直接参考价值。

智能体量化论文

信源1 家

  1. [1]arXiv cs.AI一手信源Runnable Commit Untangling for Coding Agents

关键事实

  • 论文提出 RucTangle,声称是首个在拆分提交时保持每次提交后代码可运行的智能体方法[1]

  • 论文提出 TangleEval,声称是首个量化整理后提交历史如何帮助编码智能体修复缺陷的评估框架[1]

  • 在 131 个智能体生成的补丁上,RucTangle 产出的历史全部可运行,基线有 20.6%-37.4% 的历史不可运行[1]

  • 在 453 个引入回归的智能体补丁上,将 RucTangle 生成的历史加入上下文使 pass@1 绝对提升 5.2%[1]

  • 论文还分析了智能体轨迹,观察其如何利用拆分后的提交定位和修复缺陷[1]

相关 · 论文

本页内容由 AI 自动聚合公开信源生成,仅供了解行业动态参考,不构成任何投资或决策建议。如需引用请以原文出处为准。