Uber 工程师不动手Agent 接管了 70% 的代码 PR 这个话题最近几天在我朋友圈里刷了屏。不少朋友第一反应是标题党第二反应是那我是不是要失业了。说实话我一开始也觉得 Uber 官方是在 PR 公关稿里注了点水但仔细扒了一遍他们放出来的工程博客、演讲实录和代码仓库之后我改主意了——这可能是 2025 年 AI Agent 在软件工程领域最有参考价值的一次真实生产落地不是 demo不是 hackathon 玩具是几千名工程师日常在用的东西。这篇文章我想好好拆一拆Uber 到底怎么把 Agent 塞进代码评审流程的、70% 这个数字是怎么算出来的、他们用的是什么技术栈、以及作为普通开发团队我们能从里面抄到什么作业。1. 先搞清楚Uber 说的 70% 到底是什么很多人看到Agent 接管了 70% 的代码 PR这句话第一反应是AI 把 70% 的 PR 从头到尾写完了这是对PR这个概念最大的误解。在 Uber 的语境里PRPull Request拉取请求不是一个完整的功能开发任务而是一次代码变更从开发完成到合并主干的评审流转单元。90% 的 PR 根本活不到评审阶段——它们在半路就被机器人拦下来打回重做了。Uber 真正说的 70%是AI Agent 在代码评审这个环节的参与度。他们的系统叫 Cowboy底层用 Claude Code 驱动在 GitHub 的 review 流程里自动做三件事静态分析拿到 PR 之后Agent 先把 diff 拉下来跑一遍编译和 lint把低级问题格式错误、未使用的 import、明显的空指针隐患直接标出来。语义理解把 PR 对应的需求单、相关 issue、上下游模块的调用关系拼成上下文让模型理解这段代码到底想干什么而不是只看语法。评审意见生成在 PR 评论区生成哪些需要改、为什么需要改、建议怎么改的结构化意见并通知对应的负责人。这玩意儿工作的效果根据 Uber 放出来的数据在一次涉及 300 多个仓库的大规模接入测试里Agent 自动 approve 了大约 20% 的简单 PR四五成的 PR 被打回修改剩下的才进入人工评审。Uber 官方博客里给过一个更具体的数据AI 自动提出 review 意见的占比接近 70%人工最后 review 的只有 30% 左右。所以你明白了吗接管不是说 AI 替人把活干完了而是说 AI 把代码质量保障的第一道防线从人变成了Agent。这 70% 的 PR 在到达人类工程师面前之前已经被 Agent 筛过一遍、改过一轮了。这里我补充一个背景Uber 的技术栈是出了名的超级单体monorepo一个超大仓库里有上万个微服务和几十亿行代码人工 review 的压力极大。他们大概是所有大厂里最渴望用 AI 来给代码评审减负的公司之一——不是闲得没事搞噱头是真的疼。搞清楚这个数字的边界后面所有讨论才有意义AI 不是来取代工程师的AI 是来把工程师从每天看几十个 PR 的机械劳动里解放出来的。2. 为什么是现在Agent 接管代码评审的几个关键技术前提Uber 不是今年才想搞自动化评审的。早在 2018 年他们就有一套基于静态分析规则的机器人系统能自动检测代码风格和常见 bug。但那套系统最大的问题是规则是人写的写规则的速度永远赶不上业务代码膨胀的速度。而且静态分析只能抓模式看不到意图——它知道你调了一个空指针但它不知道这个指针为什么为空、上游为什么传了空值来。Agent 方案这几年能跑通核心在于三个技术前提都到位了。2.1 大模型真的能看懂代码了GPT-4 之前模型对代码的理解基本停留在自动补全级别给它前几行它猜后面几行。这种水平拿来做评审意见一定会闹笑话。但到了 Claude 3.5/4 和 GPT-4o 这一代模型的上下文窗口做到了几十万 token——什么概念相当于它能同时读下一个小型仓库的全部核心代码。加上代码模型在训练时专门强化了代码推理能力它已经能理解这个 PR 改了支付模块的汇率计算逻辑可能会影响上游对账系统这种跨文件的因果关系。Uber 的选择是 Claude Code而不是 OpenAI 的 Codex主要原因是Claude 在长上下文理解和遵循复杂指令system prompt上的表现更稳尤其是面对几十万行的 monorepo 代码时不容易失忆。再加上 Claude 的 Agent 功能允许它自主地跑命令、看日志、反复修改文件这跟只在一个对话框里聊代码完全是两个物种。2.2 Agent 从聊天机器人进化成了会动手的同事早期的 AI 编程工具是问答式的你问这段代码有什么问题它回答然后你去改。现在 Agent 是委托式的你说帮我把支付模块的重试逻辑改成指数退避它会自己打开文件、找到相关函数、修改、跑测试、再看结果不满意就继续改直到通过。这个差异决定了接管的可能性。Uber 的 Cowboy 系统之所以能自动给 PR 打回修改意见、甚至直接提交修改就是因为底层 Agent 有完整的工具调用能力能读写文件、能执行测试命令、能 git commit、能 push 分支。它不再是一个顾问而是一个实习生——而且是一个可以 24 小时不睡觉、同一时间处理 2000 个任务的实习生。2.3 代码评审场景本身很适合 Agent 试水说句公道话Uber 选代码评审作为 Agent 落地的第一站是非常聪明的策略。因为代码评审有几个特点收益可量化评审通过率、打回率、平均处理时长都是现成的指标能直接算 ROI。风险相对可控最坏情况是 AI 给了错误的评审意见被人类工程师忽略即可不会直接导致线上故障。上下文相对封闭评审一份 PR需要看的东西是明确的diff、相关文件、需求单比让 AI 完全自主开发一个新功能好控制得多。我甚至觉得代码评审是 Agent 在软件工程领域最完美的一个切入场景——它的目标不是创造而是判断和修改而这两件事恰好是当前大模型最擅长、我们人类最烦的。3. 从 0 到 1 搭一个能用的代码评审 Agent光聊 Uber 的架构不落地等于看了半天米其林菜谱还是不会做饭。我这里给你一套可直接复用的最小实现方案。这是我自己在团队内部跑了三个月的配置稳定干掉了大约一半的琐碎评审工作。整套方案不需要你有很强的 AI 背景照着做就能跑起来。3.1 工具选型为什么不推荐自己训练模型先说结论别自己训练代码模型没用纯烧钱。Uber 自己也没训练他们用的是 Anthropic 的 Claude Code 作为基座然后在上面做了一层封装。对于绝大多数团队我建议的组合是底座模型Claude性价比最高或 GPT-4o如果你已经在 Azure 生态里Agent 框架Claude Code 官方 CLI 或者开源的 OpenHands原 OpenDevinCI 集成GitHub Actions 或者 GitLab CI用来在 PR 创建时自动触发 Agent规则库把你们的团队规范、常见踩坑写成一个 Markdown 文件让 Agent 在评审前先读一遍这套组合唯一需要写代码的部分就是 CI 配置文件以及少量调 API 的脚本。正常一个后端开发半天就能搭完。3.2 核心实现CI 自动触发 Agent 自主评审我在团队里用的是 GitHub Actions Claude Code 的组合关键步骤和配置如下。第 1 步写好团队规范文件在仓库根目录建一个CLAUDE.md文件把你希望 AI 在评审代码时遵守的规则都写进去。比如我的文件是这么写的# CLAUDE.md ## 代码评审重点 1. 检查是否有潜在的并发安全问题共享变量、锁使用 2. 检查数据库查询是否缺少索引或存在 N1 问题 3. 检查错误处理是否完善网络超时、第三方接口异常必须有兜底 4. 检查日志是否完整关键业务操作必须打点禁止只 print 不落盘 5. 检查命名是否清晰禁止缩写命名禁止拼音命名 ## 评审输出格式 - 每个问题必须标注文件路径和行号 - 按严重程度分级CRITICAL必须改/ WARNING建议改/ SUGGESTION可选 - 修改建议必须给出具体的代码示例禁止只说请优化一下这个文件是 Agent 评审时的行为准则。Uber 内部有类似的东西只不过他们管它叫engineer playbook内容更庞大细化到了几百条工程红线。第 2 步配置 GitHub Actions 触发 Agent在.github/workflows/ai-review.yml里写上触发逻辑name: AI Code Review on: pull_request: types: [opened, synchronize] jobs: ai-review: runs-on: ubuntu-latest permissions: contents: write pull-requests: write steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 - name: Run Anthropic Review Agent env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | npx anthropic-ai/claude-code review \ --diff-mode \ --output-format markdown \ --rules-file CLAUDE.md这个 workflow 的作用很简单只要有人提 PR 或者往已有 PR 里 push 新代码GitHub Actions 就会自动跑一个 job把代码拉下来调用 Claude Code 的 review 模式按 CLAUDE.md 里的规范生成评审意见。第 3 步Agent 自动提交修改Uber 能做到接管而不是建议关键在最后这一步让 Agent 不只是提意见而是直接把能改的问题改掉。npx anthropic-ai/claude-code \ --dangerously-skip-permissions \ review \ --fix \ --commit加上--fix参数后Agent 会尝试自动修复它认为有问题的代码--commit则让它把修复直接提交到当前分支。这一套流程跑下来很多简单的 CRITICAL 问题比如空指针、未捕获异常根本到不了作者面前就已被 Agent 修好了。3.3 关键细节Agent 拿到足够上下文的三种方式很多人在搭这类 Agent 时会发现AI 的建议总是浮于表面因为它只看到了 diff看不到整个项目的背景。Uber 解决这个问题的办法有三招我实测下来非常有效关联需求单在 PR description 里带上 Jira 或线性Linear的单号CI 脚本先去拉需求描述文本和代码 diff 一起喂给模型。模型知道这段代码是为了实现 XX 业务功能之后评审的准确率能提升一个档次。喂仓库地图写一个REPO_STRUCTURE.md告诉 Agent 哪些目录是干什么的、核心模块之间的依赖关系类似给新同事一份入职导航。Claude 读了之后就不会在工具函数目录里对着业务代码胡说八道。允许 Agent 主动搜代码Claude Code 自带 grep 和文件浏览工具允许它自己去找相关调用方。比如它在评审一个支付函数时自己会去搜谁在调用这个函数然后判断改动的影响范围。3.4 验收指标别只看它说了什么很多团队给 Agent 上线后只会看AI 提了多少条意见这其实是个错误指标。AI 提 1000 条可有可无的意见噪音提 5 条精准打击神器。我建议用这几个指标来验收指标目标值说明人工 review 时间变化减少 30% 以上这是核心价值测不准这个就别上线Agent 意见采纳率大于 60%说明意见质量还行低于 40% 说明在瞎说CRITICAL 问题漏检率小于 5%用历史上有 bug 的 PR 回测看 Agent 能不能发现评审平均响应速度小于 10 分钟AI 应该在 PR 提交后几分钟内出第一轮意见Uber 内部盯的核心指标也是类似的他们统计过Agent 参与评审后一个 PR 从提交到拿到第一轮反馈的时间从平均 22 小时缩短到了 20 分钟以内。这组数据比70%更有说服力因为它直接改变了开发者的工作节奏——以前写完代码要等一天才有人看现在十分钟后 AI 就给你反馈了你可以在上下文还热乎的时候立刻修改效率完全不一样。4. 实测下来的踩坑与排查六个你没绕过的拦路虎再完美的方案落地时必定踩坑。我把自己和几个朋友团队在接入 AI 代码评审时遇到的典型问题整理了一下大部分都是网上教程里没人提的血泪教训。4.1 权限设置的坑Agent 分不清能看和能改我第一次配置的时候为了让 Agent 方便行动给了它很高的仓库权限。结果它顺手就把一个还在开发中的分支给合并了——因为我没配分支保护规则Agent 把手里的 write 权限用在合并 PR上了。后来我花了半天时间恢复分支。这个问题特别好解决CI 里的 Agent 权限能收多紧收多紧。我的经验是给 Agent 配一个单独的 GitHub 账号或机器人身份不要用你自己的 token只给pull和push到特性分支的权限永远不给main分支的写权限不要用--dangerously-skip-permissionsClaude Code 里跳过所有确认的参数除非你完全信任它的行为边界如果你用的是--fix --commit自动修改模式建议在 GitHub 里加一条分支保护规则特性分支允许 Agent 提交但合并到 main 必须经过人类 review CI 全绿。这是物理防线不可跳过。4.2 提示词设计的坑Agent 变成文科生和杠精的两种极端没有约束的 Agent 会变成文科生提一堆命名要更清晰、建议增加注释这类空洞意见完全无法落地触发建议疲劳——开发者看多了就再也不看 AI 的意见了。太激进的 Agent 会变成杠精死咬住某个风格问题不放非要开发者改成它习惯的写法导致 PR 作者和机器人吵起来。我在团队里见过最离谱的一次Agent 把一段用Exception的代码反复改成RuntimeException作者改回去Agent 又改过来来回拉扯了 5 轮。解决办法有两条。第一条是写清评审边界在 CLAUDE.md 里明确告诉 Agent只关注功能和正确性问题不纠结代码风格风格问题交由 linter 处理。第二条是加人工确认环节Agent 的修改一律以评论形式提交由人类决定采纳与否不要让 Agent 直接 push 修改到远程分支。4.3 上下文污染的坑Agent 越评越糊涂怎么排查我遇到过最诡异的问题是同一个 PRAI 第一次评审给出了 5 条意见第二次评审只给出 2 条第三次评审说没发现问题。排查下来发现是我的 CI 脚本在重复检查时有缓存——Agent 把上次的评审结果当成了代码的一部分读进去了导致它误以为问题已经修复了。排查这类越评越糊涂的问题遵循一个简单的排查顺序# 1. 在本地复现 Agent 的执行环境 npx anthropic-ai/claude-code review --diff-mode --verbose # 2. 确认 Agent 读到的文件列表 # 如果包含前一次评审留下的 comments.md那就是缓存污染 # 3. 清理 Agent 的工作区每次只保留干净的 git diff git reset --hard origin/main git clean -fd这类问题的根源大多出在工作区不干净清理之后基本能解决。4.4 模型幻觉的坑Agent 振振有词地改错了怎么办说说最要命的问题幻觉——AI 愣是判断某个函数一定会抛异常给改成了try-catch结果是业务代码这个异常不应该被吞掉直接导致一个支付回调的 bug 无声无息地溜过去了。我被这东西坑过一次之后老实加了个行为保险CRITICAL 级别的自动修改必须强制附上测试结果在 CLAUDE.md 里规定Agent 一旦做了修改必须在评审意见里附上自己跑的测试日志截图没测试结果的意见视为无效。这一条几乎把嘴上跑火车的 Agent 治得服服帖帖——它知道要自我验证就会收敛很多。对 Agent 自己的改动再做一轮静态检查Agent 修完代码之后CI 里再跑一遍eslint 单测 tsc有任何一项不通过就直接 fail 掉整个 PR。4.5 基础设施的坑几十秒的模型延迟如何扛住大规模并发大部分小团队可能遇不到这个问题但方向明确、Agent 用量上来之后一天几百个 PR你会突然发现GitHub Actions 的免费额度烧得太快了而且串行等待模型回复的时间长得让人崩溃。我的解决办法是改进调度策略把 Agent 任务放进一个队列系统Sidekiq 或者简单的 Redis 队列都行由 worker 异步消费不要让 CI job 同步等待模型返回结果对 API 调用做粒度改造走 Claude 的批量处理接口Batch API不用实时接口成本降低 50%延迟变成异步的不影响体验——Uber 的做法是自己在 Kubernetes 里跑了个 watchtower 服务用预留的 GPU 实例跑模型推理避免和对外业务抢同一批算力资源。如果你只是想验证方案完全没必要一上来就自建推理集群直接用官方 API 量够了再优化。4.6 人的问题工程师把 Agent 当成免死金牌最后这个坑乍一看不算技术问题但它是真实存在的一旦团队习惯反正有 AI 兜底之后写代码的人会肉眼可见地变糙。这是我在负责的团队里踩到的最大的坑比任何技术问题都难处理。人手写出来的代码越来越依赖 AI 的 review 养成惰性先随便写点能跑的然后靠 Agent 给改。时间久了发现真·代码设计问题架构不合理、模块耦合严重AI 是看不出大方向的而人类工程师已经不想思考了。我的应对措施有三条现在都在执行给 Agent 定位成第一个 reviewer而不是唯一的 reviewer关键 PR 仍然强制人工 review每周拉一次Agent 意见被驳回率的报表被驳回超过 30% 就降级 Agent 的权限回退成仅提示模式在 CLAUDE.md 里明确写Agent 只解决怎么改不负责要不要这么改业务决策必须由人拍板5. 这套玩意的边界在哪里它不会取代工程师但会让人分层最后我应该给你一个尽量冷静的判断AI Agent 做代码评审能做到什么程度做不到什么程度必须提前说清楚——这样咱们都不至于到时候被现实打脸。Agent 真正擅长的是查漏和改错。比如这里少了个判空、那里日志级别用错了、这个循环有性能隐患、这个新 API 跟老逻辑冲突了这类具体、明确、有标准答案的问题。它们 24 小时在线别的不用干就盯着所有 PR。你从下午一直干到半夜它也在那儿跑着能把那些无聊的統一命名、异常处理补充、语法规范校对全都无声无息地消化掉。这对一个每月合并几百个 PR 的团队来说省下的人力是真实可感的。Agent 目前做不到的是审美和取舍。它不会对你说微服务拆分的边界这里其实不对我们聚合根的理念出问题了这是架构级别的重构——不是它不聪明而是这类判断需要的上下文跨度太大超过了它看一段 diff的能力范围。Uber 也承认他们放给 Agent 自动处理的是那些低风险、高确定性的 PR涉及核心支付、司机分配这类动一发牵全身的逻辑依然是工程师亲手把关。所以这件事真正的走向我判断不是程序员失业而是程序员分层。单靠复制粘贴、走流程、改 bug 的底层码农岗位会被大幅压缩而那些理解业务逻辑、有架构判断力、能设计出好 prompt 和好流程的人会成为 AI 的上级——就像是每个工程师都配了几个 24 小时加班的AI 实习生你负责决策它们负责执行。在这轮变化里最应该从 Uber 这个案例里学到的不是怎么配 CLAUDE.md或者怎么调 GitHub Actions——那些都会过时。真正值得学的是那种把重复劳动拆解出来、交给工具、释放人力去做更高价值判断的思路。这条路从 U 盘时代开始就没变过Agent 只是把这个趋势加速了十年。如果你准备在团队里动手试这套东西我的建议就一句话从小事开始先把自动在 PR 上留评审意见跑起来跑顺了再让它碰代码它证明自己靠谱了你再给它加攻击面。当年我们学写代码也是先打印一行 Hello World开始的Agent 也一样。