野外环境中自主代理贡献的研究：活动模式与代码随时间的变化 Investigating Autonomous Agent Contributions in the Wild: Activity Patterns and Code Change over Time
AI代理生成的代码变更更大但更不稳定
前置知识
Pull Request（PR）
Pull Request是Git协作开发中的核心机制，开发者创建一个包含代码修改的分支，然后向目标仓库提交合并请求。PR不仅包含代码变更本身，还包括元数据如提交记录、评论、审查意见、关联的issue等。在现代软件开发流程中，PR是代码审查、讨论和质量控制的主要场所，是衡量贡献质量和团队协作模式的重要窗口。
本文以PR为基本分析单元研究代理贡献，理解PR的组成和作用是解读论文方法论和结果的基础。
Code Churn（代码搅动）
代码搅动是指代码在一段时间内被修改或重写的程度，计算公式为$Churn rate = \frac{Churned LOC}{Total LOC}$，其中Churned LOC是新添加或语法上不同于初始版本的代码行数。高churn率意味着代码经常被重新修改，可能表明代码质量不高、需求频繁变更或缺乏良好的架构设计。churn是软件工程中预测缺陷密度和维护成本的重要指标。
本文使用churn率作为衡量代理生成代码稳定性的核心指标，通过比较代理和人类代码的churn差异来评估代码质量。
Survival Rate（生存率）
代码生存率衡量的是代码行在一段时间内保持不变的比例，计算公式为$Survival rate = \frac{Survived lines}{Added lines}$，其中Survived lines是内容在目标提交中保持不变的代码行数。高生存率表示代码被后续修改较少，相对稳定。生存率从语法层面衡量代码的持久性，不考虑语义层面的变化。这个指标在仓库级别被广泛用于评估项目的稳定性。
本文将生存率从仓库级别适配到提交级别，用于量化代理生成代码的长期稳定性，是回答RQ2的关键指标。
Autonomous Coding Agent（自主代码代理）
自主代码代理是基于大语言模型的AI系统，具有三个核心特征：自主性、扩展范围和工程实用性。与传统需要用户持续监督的AI助手不同，代理能够自主执行多步骤任务规划、运行自我评估、协调多个工具，并从观察到的自身行为效果中调整行为以实现用户目标。它们可以完成从需求分析到实现的完整开发工作流，包括创建分支、打开PR、执行代码审查等。
本文研究的五个代理（Codex、Claude Code、Copilot、Jules、Devin）代表了这一新兴范式的典型系统，理解其与传统助手的区别是理解研究动机的关键。
研究动机
随着大语言模型的发展，自主代码代理正日益深入地参与实际软件开发，在GitHub上已经占据了约10%的公开Pull Request。然而，现有研究主要关注静态基准测试或受控用户实验，这些方法在捕获真实开发环境的复杂性、节奏和细微差别方面存在局限性。大多数先前研究聚焦于有限的高人气仓库或单个代理，缺乏对代理活动的全面视角。更重要的是，对于代理生成的代码在维护性方面的影响——这是软件开发生命周期中资源最密集的阶段——知之甚少。代码编写和审查只是软件工程过程的冰山一角，生成的代码必须长期维护和更新，但现有研究缺乏对代理生成代码长期演化的纵向研究。
本文的目标是本文的目标是通过大规模实证研究，深入理解自主代码代理在实际开源项目中的贡献模式及其对代码质量的影响。具体而言，研究旨在对比五个主流代码代理（OpenAI Codex、Claude Code、GitHub Copilot、Google Jules和Devin）与人类开发者的PR在合并频率、编辑文件类型、开发者交互信号等方面的差异，并首次从纵向角度评估代理生成代码与人类编写代码在代码维护性方面的区别，包括生存率和churn率等关键指标。
与已有工作不同的是，本文的独特切入角度在于：首先，构建了迄今为止规模最大、覆盖最全面的代理PR数据集（约11万个PR），涵盖多个代理而非单一系统；其次，首次对代理生成代码进行纵向维护性分析，通过生存率和churn率等指标量化代码的长期稳定性；第三，揭示了代理活动在低星仓库中的集中趋势，这与人类开发者在更受欢迎项目中的活动模式形成鲜明对比，为理解代理的实际使用场景提供了新视角；最后，研究聚焦于被合并的PR的后续演化，而非仅仅关注合并前的接受率，这更能反映代码的实际质量。
核心方法
本文采用大规模GitHub数据挖掘的方法，通过GitHub GraphQL API抓取2025年6月至8月期间的Pull Request数据。研究针对五个自主代码代理（Devin、Claude Code、OpenAI Codex、GitHub Copilot和Google Jules）和人类开发者，构建了包含PR、提交、评论、审查、issue和文件变更的完整数据集。研究首先分析代理与人类PR在合并率、合并时间、变更规模、文件类型、仓库特征等方面的差异（RQ1），然后通过纵向分析代码变更指标——包括生存率、churn率和删除率——来评估代理生成代码与人类编写代码在维护性方面的区别（RQ2）。所有分析都使用统计检验（Mann-Whitney U检验、Cliff's Delta效应量）确保结果的统计显著性。
核心创新点在于首次对代理生成代码进行大规模纵向维护性分析，将传统的仓库级别生存率指标适配到提交级别，并通过三个时间窗口（3天、1周、3周）追踪代码演化。另一个关键创新是发现代理活动集中在低星仓库（0星仓库占绝大多数），这与人类开发者在高星项目中的活动模式形成对比，表明代理正在改变PR的使用场景。此外，研究通过分层抽样控制仓库流行度偏差，确保不同流行度仓库的代表性，提高了结论的可信度。
方法步骤详情
方法步骤包括：首先，根据每个代理的特征信号识别PR——Codex和Copilot通过分支前缀（head:codex/、head:copilot/）识别，Google Jules和Devin通过作者字段识别，Claude Code通过PR描述中的水印（"Co-Authored-By: Claude"或"Generated with Claude Code"）识别。其次，采用分层采样策略，对高活动代理使用更密集的采样（Codex每1小时），对低活动代理使用稀疏采样（Claude和Copilot每5小时），并设置每日上限防止某一天过度主导数据集。第三，收集每个PR的关联元数据，包括最多100个提交、评论、审查、issue和修改的文件。第四，对于代码变更分析，选择每个PR的第一个提交（代表代理的初始实现）作为种子提交，对于Copilot使用第二个提交（因为第一个提交通常是占位符）。最后，对合并的PR，计算三个时间窗口（3天、1周、3周）后的生存率、churn率和删除率，并进行分层随机抽样控制仓库流行度偏差。
技术新颖性
技术新颖性体现在多个方面：首先，数据集规模和覆盖范围前所未有，包含11万个PR和数百万行代码，覆盖五个主流代理；其次，首次将生存率指标从仓库级别适配到提交级别，使代码稳定性分析更加精细；第三，首次揭示代理PR在低星仓库中的集中趋势，这一发现对理解代理的实际使用场景具有重要意义；第四，方法上的创新包括分层抽样控制仓库流行度偏差、对Copilot特殊处理其第一个提交占位符问题、以及通过分层随机抽样确保代码变更分析的可靠性；最后，研究不仅关注PR的合并率，更关注合并后代码的长期演化，提供了更全面的代理贡献质量评估视角。
实验结果
研究发现代理活动正在快速增长，特别是在低星仓库中。具体而言，人类PR中有40.5%来自0星仓库，而Codex和Jules的PR中约75%来自0星仓库。代理PR通常涉及更大的代码变更：人类PR中位数约为60行，Claude PR中位数达到376行，Codex是唯一代理中位数较小的例外。代理更倾向于添加代码而非删除代码，所有代理的添加比例都高于人类。Copilot PR约有50%链接到issue，而人类PR仅约8%，这反映了不同代理的用户界面设计差异。在合并率方面，Claude和Codex的合并率高于人类，而Copilot和Devin较低。合并时间方面，人类PR中位数为0.4小时，CodexPR中位数仅0.5分钟，这可能反映了Codex被用于更简单的任务或在PR提交前已经过人工审查。最重要的发现是代理生成的代码在维护性方面表现不如人类代码：在所有三个时间窗口中，人类提交的完整生存率都高于任何代理，代理提交的churn率普遍高于人类，删除率也略高，表明代理生成的代码更不稳定，更容易被后续修改。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| PR变更规模 | 中位数变更行数 | Claude: 376行, Codex: 较小, Copilot: 大于人类 | 人类: 60行 | Claude变更规模是人类的6.3倍 |
| 0星仓库PR占比 | 百分比 | Codex: 75.3%, Jules: 75.7%, Copilot: 59.6%, Claude: 51.7% | 人类: 40.5% | 代理更集中在低星仓库 |
| 代码生存率 | 完整生存提交百分比（3周） | 代理: 显著低于人类 | 人类: 最高 | 人类代码更稳定 |
| 代码churn率 | 中位数churn率 | Claude: 0.8-1集中, 其他代理: 高于人类 | 人类: 0-0.4集中 | 代理代码churn率更高 |
| issue链接率 | 链接issue的PR百分比 | Copilot: 约50% | 人类: 8% | Copilot的UX更强调issue关联 |
局限与改进
研究存在几个重要局限性：首先，代理系统版本变化不透明，在数据抓取过程中这些系统可能被频繁修改和调整，虽然研究关注聚合行为模式而非特定版本效应，但这一因素仍可能影响结果。其次，代理贡献透明度有限，如Codex和Claude Code可以通过CLI接口进行不可追踪的贡献，并且可以禁用水印，特别是Codex的活动通常记录在人类账户下，使得完全追踪变得困难。第三，人类归属不确定性，由于所有活跃的代码代理的完整列表未知，过滤纯人类编写的数据可能仍包含未检测到的代理贡献。第四，仓库流行度分布不均衡，大多数PR来自低星仓库，虽然研究按仓库流行度报告活动结果，并在代码变更分析中使用分层抽样缓解偏差，但这一模式仍然需要在解释结果时考虑。最后，数据收集覆盖性限制，对于PR数量大的代理，GitHub API可能返回集中在特定时间段的贡献，可能导致数据集未能代表代理贡献的全局分布。
独立分析的弱点
独立分析的弱点包括：代理生成的代码稳定性较差，生存率低于人类代码，churn率和删除率更高，这意味着虽然代理可以提高短期生产力，但可能增加长期维护成本。代理活动过度集中在低星仓库，这表明代理可能更适合个人或小型项目，在大型、成熟项目中的采纳率较低，限制了其影响范围。不同代理的使用模式差异很大（如Codex用于小变更，Claude用于大变更），这使得难以给出统一的代理质量评估。代理生成的文档（Markdown文件）较多，虽然这对知识管理有益，但也可能反映了代理更倾向于进行"从0到1"的类型编辑，而非复杂的代码重构。对于高星仓库，代理PR的合并率普遍低于人类PR，特别是在复杂任务如功能开发和bug修复方面，这表明代理在处理复杂任务时可能仍有不足。改进方向包括：优化代理的代码生成质量以提高长期稳定性；增强代理对大型项目上下文的理解以提高在高星仓库中的适用性；设计更统一的代理工作流以提高一致性；平衡代理的文档生成与核心代码生成能力。
未来方向
作者提出的未来研究方向包括：扩展数据集以覆盖更长时间周期、包含新的代理、集成更丰富的元数据，以支持对随时间变化的行为和跨不同项目的行为变化的研究。将CI/CD指标（如构建和测试结果）、PR时间线（如审查迭代）和贡献者信息纳入分析，以获得更全面的代理贡献质量评估。研究代理生成代码的长期影响，通过分析技术债务积累及其与代理版本、项目特征和审查实践的关系。基于数据集开发新的基准测试任务，如代码生成和修复，使用真实世界的结果（如合并后churn或接受率）作为客观信号。未来研究还可以更深入地分析churn的驱动因素（bug修复、功能添加、需求变更或有缺陷的抽象），并更清楚地区分真实PR中不同类型的变更（如代码、评论和文档）。此外，随着代理系统的快速发展，需要持续跟踪和分析其演化，以理解这一新兴范式的长期影响。
复现评估
研究在复现性方面表现良好：数据集已公开发布在Hugging Face上（https://huggingface.co/datasets/AISE-TUDelft/MOSAIC-agentic-3m），包含11万个PR及相关元数据，为其他研究者提供了坚实基础。研究详细描述了数据收集过程，包括GitHub GraphQL API的使用、每个代理的识别信号、分层抽样策略等，这使得其他研究者可以复制数据收集过程。分析方法清晰定义了所有指标的计算公式和统计检验方法，包括生存率、churn率、删除率、Cliff's Delta效应量等。研究也明确指出了数据收集的局限性，如API返回的时间集中性问题和代理识别的不确定性。然而，完全复现可能仍面临挑战：GitHub上的代理活动是动态变化的，不同时间抓取的结果可能不同；代理系统的版本变化和功能更新可能影响结果的稳定性；一些代理的CLI使用方式使得贡献追踪困难；人类数据中可能混入未检测到的代理贡献。总体而言，研究在数据公开和方法透明方面做得较好，为后续研究提供了良好起点。
论文图表