1. 研究缘起当AI开始提交代码我们该如何审视最近我所在的团队开始尝试引入一些AI编程助手比如GitHub Copilot来辅助日常开发。效果确实不错代码补全、生成注释、甚至写一些简单的工具函数效率提升肉眼可见。但很快一个更有趣也更具挑战性的场景出现了当AI助手的能力不再局限于“辅助”而是能够理解需求、规划任务、编写完整功能模块并最终以“智能体”的身份像一个真正的开发者一样向代码仓库发起一个Pull Request时我们该如何应对这个问题并非空想。随着大型语言模型能力的演进以及像AutoGPT、LangChain这类框架的成熟构建一个能够自主完成复杂任务的“AI智能体”门槛正在迅速降低。可以预见未来将有越来越多的代码变更其作者栏里填写的可能不是人类工程师的邮箱而是一个AI Agent的ID。这些由AI发起的PR我们该以何种标准来评审是更宽容还是更严苛它们被合并或拒绝的背后逻辑又是什么这正是标题《Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study》所指向的核心领域。它本质上是一次对“人机协作新范式”的实证探索。我们不再仅仅研究AI生成的代码片段质量而是将AI视为一个完整的、具有“行动意图”的贡献者去系统性分析其产出的、具备完整上下文的变更集即PR在真实开发流程中的命运。对于技术管理者、工程效能团队以及每一位一线开发者而言理解这个问题都至关重要。它关乎代码库的长期健康度、团队协作流程的演进以及我们如何定义开发工作中的“责任”与“信任”。这篇内容我将结合我对AI辅助开发、代码评审流程的观察以及对这个新兴研究领域的理解来拆解“智能体PR”从诞生到终结的全链路探讨其背后的核心考量、技术挑战与评审逻辑。2. 定义“智能体PR”超越代码生成的完整工作流单元在深入讨论合并与拒绝的原因之前我们必须先明确研究对象——“Agentic Pull Request”究竟是什么。它绝不仅仅是“由AI生成的一堆代码文件”。2.1 智能体PR的完整生命周期一个典型的、由AI智能体驱动的PR其生命周期远比我们想象的要复杂。它始于一个高层级的目标或任务描述例如“为用户登录接口添加速率限制功能”或“修复项目在Node.js 18环境下启动报错的问题”。智能体需要完成以下一系列动作任务理解与规划解析自然语言描述将其拆解为具体的、可执行的技术子任务。例如“添加速率限制”可能涉及查阅现有认证中间件、选择合适的限流算法库、编写中间件代码、更新配置文件、编写单元测试、更新API文档等。上下文感知智能体需要“理解”它所要修改的代码库。这包括拉取最新代码、分析相关模块的架构、理解现有的编码规范和风格、识别可能受影响的依赖关系等。它不能在一个真空环境中生成代码。代码生成与修改这是核心环节但目标不是生成孤立的完美函数而是生成一组逻辑连贯、与现有代码库无缝集成的变更。这包括新建文件、修改现有文件、删除废弃代码等。自我验证与测试高级的智能体会尝试运行相关的测试命令如npm test,pytest或执行静态代码分析如eslint,pylint甚至尝试构建项目以确保其变更不会立即导致构建失败或基础测试用例崩溃。提交信息与PR描述撰写智能体需要生成有意义的提交信息Commit Message和PR描述。优秀的PR描述应清晰说明变更动机、实现方案、测试覆盖情况以及可能的影响范围这对于人类评审者至关重要。发起PR最终智能体将这一系列变更打包推送到远程仓库的特定分支并向主分支或目标分支发起合并请求。由此可见一个“智能体PR”是一个包含了意图、规划、执行、验证和沟通的完整工作流产物。评审它就是在评审一个AI智能体完成一个微型软件工程项目的全过程。2.2 与人类PR及传统AI辅助的差异为了更清晰地定位我们可以做一个对比特性维度传统人类PR传统AI辅助如CopilotPR智能体AgenticPR任务发起者人类开发者人类开发者AI智能体基于人类指令决策与规划人类全程主导人类主导AI提供片段建议AI主导任务拆解与执行规划代码生成范围完整模块基于设计单行或代码块补全完整的功能性变更集可能跨多个文件上下文感知开发者对项目有深度理解局限于当前文件或邻近代码的窗口试图理解整个项目结构、规范和依赖自我验证依赖开发者的本地测试无可能包含自动运行测试、检查语法等步骤沟通内容PR描述、评论交流由人类完成PR描述由人类撰写PR描述由AI生成后续交流可能由AI或人类接管注意当前阶段的“智能体PR”并非完全自治。它通常在一个“沙箱”或受控环境中运行其行动范围和权限由人类设定。例如它可能被禁止直接推送至主分支或必须经过某些检查才能发起PR。这个对比表明评审智能体PR的焦点将从“这段代码的逻辑是否正确”部分转移到“这个智能体理解任务和规划行动的能力是否可靠”以及“它产生的整个变更集是否协调一致”。3. 实证研究视角如何科学地分析PR的命运标题中提到的“实证研究”意味着我们需要超越主观感受和个案分析通过收集数据、建立假设、进行分析来得出结论。那么如果要进行这样一项研究我们会关注哪些维度的数据呢3.1 关键数据指标与采集一项严谨的实证研究需要定义可观测、可度量的指标。对于智能体PR我们可以从以下几个层面收集数据PR元数据合并率最直接的指标即被合并的PR数量占总发起PR数量的比例。存活时间从PR创建到被合并或关闭所经历的时间。这反映了评审和修改的效率。评论数量与密度PR收到的评论总数以及平均每行代码的评论数。高密度评论可能意味着变更复杂或存在较多争议。修改次数在合并前PR经历了多少次新的提交Commit。这体现了迭代和修改的幅度。变更内容指标变更规模增加/删除的行数、涉及的文件数。智能体PR是倾向于大改动还是小改动代码复杂度引入的圈复杂度、嵌套深度等静态分析指标的变化。测试覆盖率PR是否包含了新的测试是否影响了现有测试的覆盖率依赖变更是否引入了新的第三方库或升级了现有库的版本过程与交互指标构建与测试状态PR发起时关联的CI/CD流水线如GitHub Actions, GitLab CI是否首次通过这直接反映智能体“自我验证”的有效性。评审者行为评审者是哪些人核心成员/普通成员他们评论的响应时间有多快评论的语气和内容是倾向于指导性“这里可以这样改”还是质疑性“为什么这么做”。智能体响应在收到人类评论后智能体是否能理解并做出正确的修改响应周期是多久3.2 建立研究假设基于上述指标我们可以提出一些待验证的假设这些假设也恰恰是实践中我们最关心的问题H1质量假设首次CI构建即通过的智能体PR其合并率显著高于构建失败的PR。H2规模假设变更规模行数、文件数过大的智能体PR其合并率较低评审周期更长。H3沟通假设拥有清晰、结构化PR描述的智能体PR比描述模糊的PR更容易被理解和接受合并率更高。H4学习效应假设随着项目历史中智能体PR数据的积累后续智能体PR的合并率会逐渐提高因为智能体或管理策略得到了优化。H5领域差异假设在前端UI、工具脚本等领域的智能体PR合并率可能高于在核心业务逻辑、分布式系统等领域的PR。通过设计实验如在开源项目或企业内部项目中部署智能体、收集数据、运用统计学方法检验这些假设我们才能得出“为什么”的可靠答案而非停留在猜测层面。4. 合并的通行证哪些特质让智能体PR备受青睐结合实践和上述研究思路一个能被顺利合并的智能体PR通常具备以下一个或多个特质。这些特质也是我们在实践中评估AI贡献时的核心正面标准。4.1 精准的任务完成度与有限的影响范围最理想的智能体PR是那种“目标极其明确且影响范围高度收敛”的变更。例如“将配置文件中所有硬编码的API端点地址替换为环境变量引用”。这个任务边界清晰成功标准明确所有指定配置项被替换且几乎不会影响到业务逻辑。评审者心理面对这样的PR评审者会感到“省心”。他们不需要去深究复杂的算法选择只需要验证1替换是否完整、无遗漏2替换后的环境变量名是否规范3是否有引入语法错误。智能体在这种重复性、模式化、高确定性的任务上具有天然优势其PR自然容易通过。实操心得在给智能体分配任务时指令的精确性是成功的第一要素。与其说“优化性能”不如说“将模块A中的数据查询方法从循环内查询改为批量查询这是当前代码位置...”。明确的输入和预期的输出能极大提高PR的可用性。4.2 完备的“交付物”与可验证性这指的是PR本身就是一个“开箱即用”的完整交付包。具体体现在通过CI门禁这是硬性门槛。如果智能体发起的PR连团队的自动化检查代码风格、静态分析、单元测试、集成测试都无法通过那么几乎会立即被拒绝或要求重做。这要求智能体在本地或沙箱中具备运行相关检查的能力。包含关联测试如果任务是添加新功能PR里应该包含相应的单元测试或集成测试。如果任务是修复BugPR里应该包含重现Bug的测试和修复后的测试。这展示了智能体对软件质量基础流程的理解。清晰的PR描述描述应该采用模板化的结构如“## 变更内容”、“## 动机”、“## 测试方案”、“## 影响范围”。清晰的描述能大幅降低评审者的认知负荷。评审者心理一个附带测试且CI全绿的PR传递给评审者的信号是“这个变更是经过初步质量验证的你可以更专注于审查设计逻辑而不是抓低级错误”。这建立了初步的信任。4.3 符合项目惯例与历史模式智能体是否能够学习和遵循特定项目的“习俗”这包括代码风格缩进、命名规范驼峰、蛇形、导入语句顺序等。架构模式是使用MVC、MVVM还是其他新的服务类应该放在哪个目录下提交信息格式是否遵循类似feat(scope): message的约定式提交规范。一个能完美融入项目现有代码风格的PR会让评审者产生“这就像是我们团队的人写的”的感觉减少了疏离感和审查阻力。这要求智能体在规划阶段必须对目标代码库有足够的分析能力或者由人类提供清晰的规范约束。踩坑记录我曾见过一个智能体PR功能实现得很好但它使用了项目里从未用过的日志库来打日志且日志格式与现有系统完全不同。虽然这不算错误但导致了额外的评审成本最终被要求按项目现有规范重写。这说明对项目“上下文”的理解深度直接决定了PR的融合度。5. 拒绝的红牌智能体PR常见的“致命伤”相反导致智能体PR被拒绝的原因往往更具启发性它们揭示了当前AI在软件工程全流程中存在的短板。5.1 “过度工程”与不必要的复杂性这是智能体尤其是基于强大LLM的智能体一个非常突出的问题。为了展示其能力或确保“鲁棒性”智能体常常会生成远超必要复杂度的解决方案。场景任务可能是“添加一个简单的配置文件解析函数”。人类开发者可能会写一个几十行、直接使用标准库的清晰函数。而智能体可能会生成一个包含完整工厂模式、多格式支持、缓存机制、详细错误处理类和上百行代码的“框架”。评审者视角评审者会问“我们需要这么复杂吗这带来了额外的维护成本而需求只是读取一个JSON文件。” 这种过度设计违反了“如无必要勿增实体”的原则增加了未来开发者理解和修改代码的难度通常会被要求简化。核心原因LLM在训练数据中见过太多设计模式和“最佳实践”的示例它倾向于生成它认为“完整”、“健壮”的解决方案而缺乏对“适度”和“简单性”这种工程哲学的判断力。5.2 对业务上下文和领域知识的缺失智能体可以理解语法和通用设计模式但很难理解深层次的、隐含的业务逻辑和领域知识。场景在一个电商系统中有一个计算优惠券折扣的函数其中包含一条特殊的业务规则“黑名单用户即使满足条件也不享受此券”。这条规则可能以一段注释或一个不起眼的条件判断存在。当智能体被要求“重构此折扣计算函数以提高可读性”时它可能会“优化”掉那段看似冗余的代码无意中删除了关键业务规则。评审者视角只有熟悉该业务域的人类开发者才能立即发现这个错误。这种错误是致命的因为它直接导致线上业务逻辑错误。评审者会对智能体产生严重的不信任感“它根本不懂我们的业务。”这种缺失是根本性的也意味着在核心业务逻辑密集的区域智能体PR必须接受极其严格、甚至逐行比对式的审查。5.3 糟糕的沟通与“黑盒”变更即使代码本身没问题糟糕的“沟通”也会导致PR被拒。模糊或错误的PR描述描述里写着“修复了一个Bug”但没说是什么Bug、如何复现、为什么这个修改能修复它。或者描述与实际的代码变更完全不符。无法理解评审意见当人类评审者在评论中提出疑问或修改建议时智能体无法进行有效的交互。它可能生成无关的回复或者做出错误的修改。PR流程因此陷入停滞最终需要人类开发者接管分支并进行修改这反而增加了工作量。“魔法数字”与缺乏解释在生成的代码中出现了未经解释的常量、看似随机的阈值调整。评审者无法理解其决策依据只能将其视为不可靠的“黑盒”操作。实操心得目前让智能体参与PR评论对话并正确理解上下文仍然是巨大的挑战。一个更可行的模式是“智能体生成人类沟通”。即由智能体完成代码变更和初始PR描述但后续与评审者的所有交流由人类开发者负责。这样既能利用AI的生成效率又能保证沟通的准确性和灵活性。6. 评审范式的转变从代码审查到“智能体行为审查”面对智能体PR传统的代码评审清单需要扩展。评审者的角色正在从单纯的“代码纠错者”部分转向“智能体行为监督员”和“任务定义验证者”。6.1 新增的评审维度除了检查代码的正确性、风格、性能之外评审者需要额外关注任务理解验证智能体是否完全、正确地理解了初始任务PR的标题和描述是否准确反映了任务目标有没有“跑偏”或“过度发挥”解决方案合理性评估智能体选择的实现方案是否是当前项目上下文下的合理选择有没有更简单、更直接的做法这个方案是否引入了不必要的依赖或复杂度对应“过度工程”问题变更范围审查智能体的修改是否严格限制在必要的范围内有没有“顺手”修改了无关的代码导致意外的副作用这需要仔细审查所有变更文件的差异。自我验证有效性检查智能体声称它运行了测试并通过了评审者需要确认它运行的是相关的测试吗测试覆盖率是否足够CI通过的构建是否包含了所有必要的检查步骤6.2 流程与工具适配为了应对智能体PR的涌入开发团队可能需要调整流程标签系统为PR自动打上agent-generated标签让评审者提前建立心理预期调整评审重点。预检查清单在人工评审前设置更严格的自动化检查关卡。例如必须包含测试、必须通过特定复杂度扫描、必须关联任务追踪号如JIRA Issue等。评审模板为评审智能体PR设计专门的评论模板引导评审者关注上述新增维度例如任务理解检查此PR的变更是否与Issue #XXX 描述的需求完全一致方案合理性这个实现方案是否是最简可行的有无过度设计领域知识影响变更是否涉及核心业务逻辑是否需要领域专家进行二次确认6.3 信任的建立与校准最终团队对智能体PR的接受度是一个动态建立的“信任度”函数。初期信任度低每个PR都会受到严格审视合并率可能较低。随着智能体在简单、重复性任务上持续产出高质量、可靠的PR信任度会逐渐累积。团队会慢慢将更复杂、更核心的任务交给它但始终会保持一个与任务关键性相匹配的审查级别。这个信任模型类似于对新加入团队成员的培养。你不会一开始就让新人重构核心系统而是从修复小Bug、编写工具脚本开始观察其能力与可靠性再逐步赋予更重要的职责。对于智能体我们也在进行同样的“能力校准”。7. 未来展望走向高效且可靠的人机协同编程实证研究“智能体PR为何被合并或拒绝”的终极目的不是为了评判AI的优劣而是为了找到一条通往高效、可靠人机协同编程的路径。基于目前的观察我认为有几个关键方向短期1-2年智能体将主要扮演“超级实习生”或“高级助手”的角色。其主战场是代码库维护批量重命名、代码风格统一、依赖版本升级、简单的Bug修复特别是那些有明确错误信息和修复模式的。样板代码生成生成CRUD接口、DTO对象、基础单元测试、配置文件等重复性高的代码。文档与测试补充根据代码生成或更新API文档、为复杂函数添加注释、补充边界情况的测试用例。在这些领域智能体PR的合并标准将逐渐明确和自动化成为提升开发效率的稳定力量。中长期随着智能体对特定项目上下文学习能力的增强以及“规划-执行-验证”循环的闭环优化它们可能开始承担更复杂的任务如小型功能模块的实现、代码重构等。但这需要突破两个瓶颈可解释性智能体需要能为其关键决策如选择某个算法、设计某个接口提供简明扼要的“推理链”或依据而不仅仅是生成最终代码。安全边界必须建立坚不可摧的“护栏”确保智能体的任何操作都在预设的安全边界内防止其对代码库造成不可逆的破坏或引入安全漏洞。回到最初的问题为什么有的智能体PR被合并有的被拒绝核心答案在于价值的净增益。一个能被合并的PR其带来的功能改进、效率提升或质量优化必须显著大于评审和修改它所付出的成本并且其潜在风险引入Bug、增加复杂度是可控的。当前智能体在降低“实现成本”上表现突出但在“理解成本”让评审者理解其意图和“风险控制”上仍是短板。未来的进化将是智能体在这两个短板上不断补强的过程而每一次合并或拒绝的决策都是训练和校准这个未来协作伙伴的重要数据点。作为开发者我们既是评审者也是这场深刻变革的设计师与参与者。