Uber 工程师不动手Agent 接管了 70% 的代码 PR。这个数字一出来很多人第一反应是又要抢饭碗了第二反应是又开始吹 AI 了。我在研发效能这个圈子里待了快十年说实话这两种反应都太极端。这个标题背后真正值得聊的不是AI 会不会取代程序员而是一个更实际的问题当一家公司把大量 PR 操作交给 Agent它的工程流程到底变成了什么样哪些环节真的能被接管哪些环节只是听起来很美。这篇文章我想把这条线拆开来讲。你会看到 Agent 到底处理了 PR 里的哪些工作为什么选 PR 作为切入点而不是直接让 Agent 写整个功能以及如果你想在自己的团队里复刻这套玩法应该从哪条链路开始搭。不管你是工程师、技术 Leader还是正在研究 AI 编程落地的同学只要你能接受Agent 不是来替你思考的是来替你跑腿的这个前提这篇文章里应该有不少能直接拿走用的东西。1. 这个 70% 到底意味着什么——先搞清楚 Agent 干了哪些活1.1 不是取代工程师而是接走 PR 流水线上的脏活先说一个容易误解的地方。70% 这个数字指的是PR 生命周期里可以被自动化接管的工作量不是 70% 的 PR 都不需要人看更不是 70% 的需求可以不用写代码。我见过很多团队一听到类似数字就兴奋然后立刻把 Agent 往最核心的架构设计上怼结果翻车翻得很难看。Uber 那边的做法我判断它的本质是把 PR 当成一条流水线从代码提交的那一刻起到最终合入主干之前中间要经过格式检查、静态分析、单测补充、依赖检查、冲突检测、review 意见汇总、修改建议落地这一连串动作。这些动作里有大量是确定性的、模式化的、可以靠规则加模型去完成的而这一块就是 70% 的来源。剩下那 30%才是真正考验人的部分。跨模块的架构取舍、业务语义上的 bug、无法用规则量化的设计权衡、合规和法律层面的审查这些工作不仅 Agent 干不了普通工程师也不一定每次都能干好。所以正确的理解方式不是Agent 替代了人而是Agent 先把最耗时、最重复、最让人不想干的 PR 杂活接走了人腾出精力去盯真正需要判断力的地方。我自己在实际项目里也验证过这个逻辑。之前在一个中大型后端仓库里接 Agent 做 PR 自动 review一开始团队预期是它能不能帮我找出隐藏的空指针和并发问题。跑了一个月之后发现Agent 最稳定的产出其实在另一个地方它把每个 PR 里格式不统一、注释风格漂移、日志打印缺上下文、导出函数缺少文档这类琐碎问题全部拦下来了。这些事以前是资深工程师在 review 时花时间提的而且提了之后新人还不一定服气现在 Agent 来做客观、一致、没有情绪。1.2 查出 Agent 盯得最紧的 5 类问题如果只看统计Agent 接管 70% 的代码 PR还是太空。我根据行业里公开的实践案例再加上自己落地时的经验把 Agent 在 PR 场景里盯得最紧、产出最稳定的几类问题整理了出来。第一类是格式和风格一致性。这是最没有争议的。缩进、引号、导入顺序、命名风格过去靠 lint 规则 人工 review 双重把关现在 Agent 可以直接按仓库规范把代码改好。重点是不需要团队费尽心力去调 eslint 或 clang-format 的每一条规则LLM 能理解这个项目里命名习惯是布尔值用 is 开头枚举值统一大写这类语义规则而不是机械地死记。第二类是静态缺陷和明显的 bug pattern。空指针解引用、资源泄漏、未经处理的异常、明显错误的比较条件。这类问题说难不难但分布很散人看代码容易疲劳Agent 不会。我见过最典型的例子是一个支付相关的 PR里面有个金额计算对浮点数做了直接相等比较人工 review 两轮都没发现Agent 在第一次扫描时就指出来了。第三类是测试覆盖和可测性。Agent 会检查你这个 PR 新增的分支有没有对应的单元测试测试里有没有只验证了 happy path 而漏掉了异常分支。更进一步Agent 还能直接生成测试代码的初稿。很多工程师对AI 写单测有偏见觉得生成的东西都是垃圾。但实测下来对于工具函数、状态机转换、纯计算逻辑这类代码Agent 生成的测试质量是能用的人工只要做边界值补充就行。第四类是依赖和兼容性风险。这个在大型代码库里特别值钱。一个 PR 升级了某个库的主版本Agent 能顺着依赖树去看哪些模块调用了被废弃的接口把影响面列出来。人在大型仓库里很难有耐心做完整的调用链分析Agent 反而能老老实实地梳理。第五类是文档和注释的同步。改了一个函数的行为注释没更新改了一个对外接口API 文档还是旧的。这类问题技术含量不高但非常消磨 review 者的耐心。Agent 能把 diff 和已有文档逐段对照直接提修改建议。这五类活每一类单拎出来都不复杂但合在一起占掉的工时非常可观。我做过一次粗略统计一个 10 人左右的小组每周大概有 15 到 20 个 PR每个 PR 从提交到合入平均要经过 2.5 轮 review。如果 Agent 能把格式、明显缺陷、测试补全、文档同步这几件事做掉保守估计每个 PR 能省 20 到 30 分钟的人工 review 时间。一个月下来相当于省了几乎一整天的全员投入。70% 这个数字靠的就是把这一类零碎但高频的操作全部接走。提示如果你也想在团队里验证 Agent 的 ROI不要上来就追求自动修复一切 bug先把它用在格式、单测、文档这一类最不性感、但最能耗人的地方。效果几乎一定会超出预期。2. 为什么是 PR 而不是写代码——Agent 落地的三个关键判断2.1 PR 恰好是风险可控、边界清晰的切入点我一直觉得Agent 落到软件研发流程里最大的问题不是模型能力不够而是边界不明。你让 Agent 从一个产品需求描述开始直接生成整个功能它面对的输入是开放的输出是开放的中间任何一步都可能跑偏。但在 PR 这个场景里事情不一样输入是一份已经写好的 diff输出是对这份 diff 的检查结论和修改建议Agent 不需要面对一个空白的编辑器。它是在人类已经迈出一步之后做审校、修补、提意见这些边界相对收敛的事情翻车的概率天然就低。这背后的逻辑很像开车。你让 AI 在一条没有车道线、没有交通标志的荒原上直接开到目的地大家都会紧张但如果是让 AI 在一条已经画好线的车道上做车道保持、根据前车距离自动刹车乘客的感受是完全不同的。PR 就是那条画好了线的车道。diff 是车道线CI 状态是交通信号已有代码库的历史提交记录是导航地图所有这些信号叠加起来Agent 的决策空间被约束得很好。还有一层考虑PR 是所有代码变更进入主干的必经之路天然是一个卡口。在这个卡口上部署智能化的检查逻辑无论它做得好不好影响的都只是进入主干的这一小段流程。不会像直接放开 Agent 修改生产代码那样搞得所有人晚上睡不着觉。2.2 企业级 Agent 的核心权限最小化和人工兜底我在很多技术分享里听到大家讨论 Agent 的模型选型、Prompt 设计、工具调用这些东西当然重要但企业级落地最关键的其实是两件事权限最小化和人工兜底。你要让 Agent 干活但不能让它想干嘛就干嘛。权限最小化意思是 Agent 在每个场景下能拿到的能力和能触发的动作都必须被压到最小。在一个 PR review Agent 的例子里它可以读代码、可以跑静态分析、可以提交 review 评论、可以在特定条件下生成一个修改版提交但它不应该有权限直接合入 PR不应该有权限修改主分支保护规则也不应该有权限触及生产环境的密钥和配置。权限收得越紧出大事的概率就越低。这跟给团队新人开权限的思路完全一致。人工兜底则是从流程设计上保证任何 Agent 的动作都在人的最终控制之下。我见过相对稳妥的设计是Agent 的修改永远以建议变更的形式出现在 PR 里由真人工程师确认后再合入Agent 的 review 结论不直接 blocking而是作为必须说明理由的非阻塞意见每次 Agent 修改代码提交信息里都会标记来源方便出问题时回溯。这些机制看起来保守恰恰是它能长期跑下去的原因。我自己有一个很深的体会把 Agent 当成一个特别勤快、特别较真、但绝对不值得完全信任的新同事你的流程设计就会很自然。你会给它开小的权限、检查它的所有输出、给它明确的黑白名单。相反如果你把 Agent 当成全知全能的 AI流程设计就会失守最后一定会出事故。2.3 避坑别把 Agent 的代码生成能力误解为审查能力这一节多说一个我踩过的坑。最开始我们设计 PR Agent 的时候觉得既然它能改代码那 review 能力一定也不差。实际跑下来发现会让 LLM 写一段代码和让 LLM 判断一段代码是否有缺陷是两个不同难度的问题。写代码是生成式任务它只要输出一个合理答案就行审查代码是判别式任务它必须发现那个藏在大量正常逻辑里的不合理之处。识别能力不足的典型表现是平凡的正确代码它夸得天花乱坠真正有问题的边界条件它反而看不见。所以后来我们调整了策略把最关键的缺陷扫描逻辑从让模型自己判断改成让模型按照显式 checklist 逐项确认比如是否有未处理的 None、是否有浮点等值比较、是否有资源未关闭、是否有裸 SQL 拼接。模型从一个自由评论者变成了一个严格按清单打勾的检查员准确率明显提升。这个经验我觉得值得所有准备做 PR Agent 的团队记下来先强制 Agent 做结构化检查再考虑让它自由发挥生成修改建议。顺序不能反。3. 一套可复制的 PR Agent 落地流程3.1 先跑通一条最小链路从创建 PR 到自动检查聊了这么多概念现在说点能直接上手的。如果你也想在自己团队的仓库里跑一个 PR Agent不需要一开始做得很复杂可以先搭一条最小链路等它稳定了再扩展。这条链路我建议包含五个环节第一个环节是事件触发。Agent 要能监听到仓库里的 PR 事件包括 PR 创建、新代码推送、review 意见更新。最省事的做法是用 GitHub Actions 或者 GitLab CI 自带的 webhook 触发机制。在 GitHub 上一个pull_request类型的 workflow就能覆盖绝大部分场景。关键点在于触发条件要按你的需求设准。如果只想在 PR 准备好时才运行就要过滤掉 draft PR。第二个环节是上下文收集。Agent 不能只看 diff它还需要相关文件的原始内容、PR 描述、关联 Issue、过往提交历史、CI 运行状态。这一层要做的事情是把散落在不同系统的信息拉到一个上下文里。我常用的做法是写一个轻量级 collector调用平台的 REST API 把数据批量抓下来然后按固定结构拼接成一段 JSON喂给后面的分析模型。上下文收集这一步做得越规范后面的识别效果就越稳定。第三个环节是规则引擎 模型的双通道分析。不要把所有检查都交给 LLM那些能用确定性代码判断的规则比如 lint、编译错误、明显的格式问题应该用传统工具直接跑。LLM 负责处理那些需要语义理解的检查项比如这个异常处理逻辑是否恰当这段并发代码是否有竞态风险。两条通道的结果再合并形成一份完整的检查报告。双通道的设计能控制成本也能降低误报率。第四个环节是生成评论和修改建议。检查报告要转化成可以执行的行动。对确定性问题Agent 直接生成修改后的 diff同时保留原代码在评论里做对比。对不确定的问题Agent 只在 PR 下面发表评论并提出疑问而不是直接动手改。这里有一个需要把握的度越是高风险的文件比如支付、权限控制、数据库迁移越要保守。第五个环节是人工确认与效果回收。Agent 的工作流处理完一轮之后必须有真人工程师做确认。同时在后台要记录指标每个 PR 的 Agent 检查耗时、提出修订数、被人工采纳的修订数、漏报数。没有指标回收的 Agent 就是自嗨有指标才能持续迭代 Prompt 和规则。按这个链路跑通之后你会很清楚 Agent 到底在哪些环节产出高在哪些环节只是在刷存在感。我见过不少团队卡在第三个环节习惯于让 LLM 用一句话给 PR 打总评这个 PR 实现了登录功能代码结构清晰建议合并。这种评论说了等于没说。真正有用的是定位到具体文件的精确建议。如果你发现自己的 Agent 只会输出这类正确的废话请立刻把重点转移到让 Agent 做 checklist 式检查上。3.2 分层规则设计让 Agent知道什么时候该闭嘴上一节讲了链路这一节要聊一个更关键的设计问题Agent 如何决定一条问题该提还是不该提。如果你什么都不管让 Agent 自由提意见它会在每个 PR 里挑出一堆模棱两可的问题搞得所有工程师都烦不胜烦最后直接无视它。要让 Agent 真正被团队接受必须有分层规则。我的做法是把问题分成三个级别。L1 级别是确定性规则问题。这类问题的判定逻辑非常清晰比如文件缺少许可证头、导入顺序错误、函数命名不符合项目规范、测试文件没有对应源码文件的变更。对 L1 级别Agent 可以自动修改不需要人确认。因为判定逻辑就是死的不可能错。这一级别大约能覆盖 40% 到 50% 的常见评论量。L2 级别是需要语义判断的问题。比如某个分支缺少 null 检查、资源流没有关闭、API 调用缺少超时设置、可能有整数溢出。这类问题需要模型理解代码语义判断可靠性相对高但也不是百分之百。对 L2 级别Agent 应该直接提出修改建议并且给出参考代码但不直接改动原文件让工程师按一下按钮就能接受或拒绝。L3 级别则是纯粹的架构和设计讨论。比如这个模块的职责是否过重这个抽象层级是否合理这里用事件驱动是否比直接调用更合适。这类问题没有标准答案Agent 即使提出来多数情况下也只是噪音。我建议这部分默认关闭只在特定仓库或特定条件下打开。你不关闭 L3 级别Agent 就会变成团队里那个什么都想插一句嘴的同事没人喜欢它。除了级别另一个设计是置信度阈值。我给每条检查规则都配了一个阈值只有模型对某个问题的置信度超过阈值才把问题输出给用户。阈值设低了Agent 会变成话痨阈值设高了Agent 会变成摆设。初始阶段建议把阈值调高一些宁可漏掉一部分问题也不要一堆误报把大家耐心磨掉。跑一段时间根据周报数据再慢慢下调。我自己实测下来的比例是L1 自动改L2 提建议L3 直接闭嘴这套策略可以让 70% 以上的 PR review 评论被工程师接受。有一个团队一开始没做分层Agent 的评论采纳率只有 20% 多后来改完分层规则两周之内提升到了 68%。有纪律的 Agent比聪明的 Agent 更有用。3.3 质量与安全红线什么情况下必须叫停不要以为配好了规则就能一路绿灯。PR Agent 在真实仓库里跑迟早会遇到你不想让它碰的东西。我建议你在上线第一天就定清楚这四条红线宁可让 Agent 少做也绝对不要越线红线一不允许 Agent 直接合入任何 PR无论它的检查结果多么完美。合入是最终的人为决策动作必须有真人负责。自动化合入一旦放开等出问题时你连回头的机会都没有。这就像银行的大额转账无论风控系统判断多么可靠最后一笔确认必须由人来点。红线二对生产配置、密钥文件、数据库迁移文件的 PRAgent 只能只读 review。它可以看到这些 diff可以提出意见但绝对不能在自动修复环节对这些文件动刀。我见过一个事故Agent 在帮忙修格式的时候把数据库迁移文件里的缩进改了虽然逻辑没变但因为格式变了工具链生成了新的校验和导致整套部署流程卡死。这种无妄之灾能避免就一定要避免。红线三Agent 的所有修改必须能被清晰地标识和回溯。在提交信息上加一个固定的标记比如generated-by: pr-agent在 PR 的 review thread 里留一个agent-check的标签。这能确保在出问题的时候你一路过滤、定位、回滚都不会卡壳。信息可追溯是让所有人敢用 Agent 的前提。红线四当 CI 显示编译失败或测试失败时Agent 只能报告不能尝试修复。一个稳定的项目CI 失败通常意味着有严重问题。这时候你要查的是根因而不是让模型在这堆脆弱代码之上再叠加一层修复补丁。Agent 的修复补丁一旦打上去很可能会把原有的问题搅得更乱。先让真人把 CI 拉绿再让 Agent 做后续的 review这个顺序不能乱。这四条红线我踩过其中两条的坑写下来算给大家提个醒。Agent 落地最怕的不是它能力不够而是流程上没有控制它就让它直接碰生产环境。4. 常见翻车现场与排查清单4.1 Agent 漏检/误检的典型场景不管设计多周密PR Agent 在真实仓库里跑总会有脑子短路的时候。下面这几种是我和几个同行交流时总结出来的高发问题遇到别慌按图索骥去查就行。漏检一上下文窗口截断导致永远看不到文件后半部分。大型单体仓库里一个文件动辄几千行加上 diff 一长很容易超出模型上下文限制。Agent 只看前面三分之一就开始评论结果真正的 bug 在后半段。解决思路有两个一是限制单个 PR 文件数太大就拆成多个批次分析二是按文件单独分析而不是把所有文件堆到一个 prompt 里前者更耗 token 但更准确后面可以根据成本做取舍。误检二把业务字符串当成硬编码错误。有些业务场景里就是需要硬编码一些字符串比如没有国际化规范的小工具、测试里的临时数据。Agent 会把这些也提成问题。你说它错吗按规则说没错但放在那个具体业务场景里就是噪音。解决办法是在规则库里维护一个白名单目录比如test/、tools/、scripts/下的硬编码直接豁免。误检三把测试代码的风格问题当成生产代码问题。很多人写测试代码都比较随意Agent 如果用生产代码的规范去 review 测试会提出一堆变量名太短函数过长之类的意见这些意见虽然不算错但没有多少实际价值。给 Agent 配置测试目录走单独的检查标准通常能减少三分之一左右的无效评论。误检四旧代码和新增 diff 混淆。有的 Agent 会把 diff 上下文里的老代码也拉进来 review提出一些这里本来就有问题的评论。虽然这类评论在技术上是成立的但在 PR review 场景里属于副作用噪音工程师根本不想处理这些历史遗留问题。要让 Agent 只关注新增和修改的代码行前提是在 prompt 里把 diff 范围标注得非常清楚。误检五对重构类 PR 反应过度。一个大规模重命名或者文件夹移动的 PR本身不改变任何业务逻辑但 Agent 可能因为大范围的代码变动而误判成高风险。我建议在规则层识别rename和move操作一旦识别到就自动降低检查级别只做编译和测试验证。4.2 5 个落地前必须想清楚的决策点基于我自己和周边团队的落地经验我再整理出 5 个决定项目成败的决策点。如果你正准备启动一个 PR Agent 项目这 5 个问题想不清楚后面大概率是要返工的。第一个决策点用现成产品还是自研。现在的代码托管平台上有不少现成的 PR Agent 产品能解决通用问题开箱即用。但如果你的仓库有强烈的业务领域特征比如内部 DSL、私有框架、特殊代码规范你可能需要定制。我的建议是先上现成产品跑两个星期输出一份质量评估再决定要不要自研。不要一上来就自己搭成本会失控。第二个决策点规则引擎还是纯 LLM 调用。我见过团队把构建工具、lint 结果、测试结果全部丢弃只让 LLM 看 diff纯靠AI 的理解。结果显示很多确定性问题它都判断得比规则引擎差。正确的做法是先用廉价、快速、确定性的工具把能筛的都筛一遍再把剩下的模糊问题交给 LLM。第三个决策点自动修改的权限边界放在哪。你要非常明确地定义允许自动修改和仅允许评论的文件目录和规则类型。比如src/下可以自动改格式、tests/下可以自动生成测试、migrations/下禁止任何自动修改。这个权限表越具体越好。它既是给 Agent 的行为规范也是在评审会上说服各方放心的关键文档。第四个决策点如何衡量成功。项目一开始就要定义北极星指标。我建议用Agent 评论采纳率和每个 PR 的 review 周转时长这两个指标。采纳率低于 50%说明它的高质量建议太少要考虑砍掉部分检查项周转时长没有下降说明它没在关键路径上产生价值。指标不达标项目就值得被质疑不要自我感动。第五个决策点谁来维护规则库。这是最容易被忽略的一点。PR Agent 不是一个部署完就完事的系统它是一个需要持续喂养的内容产品。新框架出现、新代码规范确立、业务的边界条件变化都需要你不断更新规则库。如果没有一个明确的 Owner规则库过了半年就会腐烂Agent 的建议质量会断崖式下跌。4.3 从 70% 到 80%几个我认为值得投入的扩展方向如果团队已经把第一步跑稳了想继续提高自动化覆盖比例我有三个方向觉得比较有前景也正在试验中。第一个方向是让 Agent 参与跨 PR 的变更协调。目前大多数 PR Agent 只分析单个 PR 内部的改动当一个大型功能被打成十几个 PR 时它看不到全貌。如果能给 Agent 关联同主题的多个 PR它就能识别出一些这个 PR 改了接口另一个 PR 还在用旧签名这类跨 PR 的断裂问题。这个价值比单个 PR 内部检查高得多。第二个方向是让 Agent 沉淀审查知识库。每一次人工 review 修正了 Agent 的建议都可以作为一条反馈样本存储起来。跑两三个月后你去看看这些样本的分布通常会非常惊讶原来团队里有一半的 review 意见集中在少数几个模式上。把这些模式整理成规则Agent 的拦截能力会明显上升。人机之间形成正向循环才是这套系统持续值钱的原因。第三个方向是把 Agent 的产出和研发指标打通。当 Agent 拦下一个线上潜在的故障点时把它记录到缺陷管理平台打上一个自动化拦截的标签。季度复盘的时候你就能直接算出自动化为质量节约了多少成本。这一步非常有助于争取团队认可和后续的资源投入。技术项目在一个组织里能不能做大很多时候靠的不是技术本身而是你能不能把效果翻译成组织听得懂的语言。最后说几句实在的我见了不少团队做 AI Agent 落地最容易犯的毛病是高估模型的能力、低估流程的难度。把 Agent 接到 PR 流程里这件事本质上不是在做 AI 创新而是在做工程治理。你对代码规范的维护是否认真、你对 review 流程的定义是否清晰、你对权限边界的划分是否合理这些传统的工程问题没解决好再强的模型也救不了。反过来当你把这些工程基础打扎实了Agent 才有附着点70% 这个数字才有机会变成现实。如果你正打算在自己团队里试这套方案我的建议很简单挑一个非核心但真实的仓库把 review Agent 挂上去让它先做两周只评论不改动的实验把采纳率跑出来。如果采纳率能过一半再逐步开放自动修改权限。一步到位的方案往往最后都要走回一步一个脚印的路线。