Uber 用 Agent 接管 70% 的代码 PR同时 AI 账单零增长这个标题很容易被误读成“AI 开始大规模替程序员写代码了”。结合 Uber 的工程实践和 Agent 项目落地的常见路径来看真正被接管的并不是“写代码”这个动作而是 Pull Request 生命周期里大量重复、机械、流程化的环节PR 描述生成、变更摘要、代码规范初筛、CI 失败归类、常见问题定位。这些环节占掉了开发者和评审者的大量时间但又不依赖深度业务推理正好是 Agent 最容易切入的地方。这件事对普通团队最大的价值不是那个 70% 的数字本身而是它证明了只要把 Agent 的任务边界、触发规则和成本预算设计清楚代码评审这类高频流程完全可以做到在可控成本下大幅自动化。下面我从“这个案例到底在说什么”开始拆成六个部分讲清楚Agent 在 PR 流程里的作用、成本为什么没涨、如何从零落地、权限和边界怎么划、踩坑排查清单以及你的团队到底要不要追这个模式。1. 先弄清楚 Uber 的 Agent 到底“接管”了什么1.1 70% 不是“AI 写的代码”而是 PR 生命周期里的自动化很多人看到标题第一反应是Uber 现在有七成代码是 AI 生成的。这个理解基本是错的。在实际工程流程里代码 PR 是一个很长的生命周期包含分支创建、代码提交、开启拉取请求、编写描述、代码评审、CI 测试、修改反馈、最终合并。整个过程里真正需要深度思考的是“功能实现是否合理”“架构是否健康”“有没有隐藏的业务风险”而大量周边动作是非常机械的。Agent 能接管的恰好在机械动作这一侧根据提交记录生成 PR 标题和描述。对比主干分支和当前分支生成变更摘要。扫描代码规范问题比如命名风格、格式化、未使用的依赖。把 CI 失败原因归类告诉开发者是测试挂了还是编译挂了。识别重复代码、明显错误处理遗漏、硬编码密钥这类常见问题。按文件路径或标签把 PR 分配给不同评审小组。所以更合理的理解是Agent 接管的是 PR 相关流程任务而不是代码编写任务。70% 这个数字更应该被看作是“PR 生命周期中可自动化环节”的覆盖率而不是 AI 自动产出代码 diff 的比例。如果你把这个概念搞错了后面做方案设计时就会走偏。你可能会要求 Agent 自动生成代码、自动 approve、自动合并这既危险又很难拿到真实收益。1.2 一个 PR 从创建到合并Agent 能参与哪些环节为了方便理解把 PR 流程拆成一张表。每个环节都可以问一个问题这里需要的是深度业务判断还是重复流程处理。环节Agent 适合参与吗原因PR 标题和描述生成适合信息来自 commit 和 diff模式固定变更摘要适合可以把大段 diff 转成结构化说明代码规范初筛适合规则明确结果可验证CI 失败分类适合失败日志有固定特征常见 bug 模式扫描较适合只能做提示不能当结论架构合理性评估不适合依赖上下文、历史决策、业务约束安全审计部分适合只能在明显问题上提醒最终判断留给人最终 approve不适合必须有人负责这是问责边界合并代码不适合应保留人工触发这张表的划分逻辑是越接近“规则明确、结果可验证、失败影响小”的环节越适合 Agent越接近“判断复杂、责任重大、影响面大”的环节越要留给人。1.3 为什么说这件事比 AI 写代码更值得关注生成式 AI 直接写代码最大的问题是质量不稳定。它能写出看起来很完整的函数但可能在边界条件、依赖版本、业务约定上出错。更麻烦的是代码错误往往要到运行期才暴露。Agent 参与 PR 流程则不一样。它的输入是代码变更输出是评论、摘要、分类结果。就算某个评论说错了开发者一眼就能看出来不会对线上系统造成直接影响。这种“低风险、可人工兜底、可量化评估”的特征让 PR 流程自动化非常适合作为 Agent 落地的第一站。对多数团队来说这也是更现实、更容易复制的能力。大厂能训练模型做代码生成的团队是少数但给 Agent 写一套 PR 评审规则任何有一定工程能力的团队都可以尝试。2. “AI 账单零增长”背后的成本控制逻辑2.1 账单增长通常从哪里来Agent 跑在代码评审流程里账单增长通常不是单一因素导致的而是一连串设计失误叠加出来的。第一个来源是上下文过大。很多团队把整个 PR 的全部 diff 一次性塞进模型甚至把相关文件全文都带进去。一个大型 PR 可能包含上千行代码反复调用几次Token 量立刻涨上去。第二个来源是模型选择不合理。不管任务简单还是复杂全部调用同一个最强模型。做一次 lint 扫描其实用一个轻量模型就够了但如果你统一上最强模型成本会成倍增加。第三个来源是重试机制没有上限。Agent 调用模型失败后如果配置了无限重试或者重试次数过高账单会在短时间内暴涨。另一个隐蔽问题是同一份代码多个 Agent 实例重复处理没有做缓存或去重。第四个来源是批量并发没有限制。Agent 收到 webhook 后十几个 PR 同时触发所有任务都开足马力跑。性能看起来是上去了成本也上去了。2.2 零增长的常用手段“AI 账单零增长”不是魔法而是把每一笔模型调用都当成预算来管。从工程实践来看至少要做五件事。第一任务分流。不要所有 PR 都进 Agent更不要所有 PR 都用同一套复杂逻辑。先判断 PR 规模、文件路径和变更类型简单任务走规则或轻量模型复杂任务才走强模型。第二模型分级。把任务分成几个等级。普通的 PR 摘要用便宜模型深度代码评审用强模型安全敏感目录直接送人工不让高成本模型接无关流量。第三上下文裁剪。只把变化的文件、变化的行数、相关函数的签名传给模型而不是把整个仓库都读进去。Prompt 里可以明确写只关注新增或修改的代码块不要分析未变更部分。第四缓存和复用。同一个分支的连续提交只需要重新分析新增 diff同一个文件在不同 PR 里被重复提问时结果可以按文件指纹缓存。这样能省掉大量重复调用。第五预算硬限制。在系统层面设置单日 Token 上限、单 PR Token 上限、单次任务重试次数上限。超过阈值直接跳过转到人工处理而不是无限生产内容。2.3 成本控制要盯哪些指标不要只看“AI 账单总额”这一个数字总额下降有可能只是 Agent 没人用。更值得盯的是几个效率指标单 PR 平均 Token 消耗判断上下文裁剪是否有效。每千行变更成本衡量处理代码变更的单位成本。模型调用次数与 PR 数量的比例判断是每 PR 一次调用还是一个 PR 反复多次调用。重试率重试率高说明模型不稳定或 Prompt 有问题。评论采纳率如果 Agent 评论没人采纳说明输出价值低花再少的钱也是浪费。Uber 案例里“零增长”的含金量应该从这些指标里去理解。它不是广告词而是成本治理能力的结果。注意如果你的 Agent 上线后所有 PR 都触发了完整深分析账单很难控制住。先给任务分流再谈产出质量。3. 从零落地一条 PR Agent环境、步骤和判断标准3.1 前置条件代码托管平台、CI、权限和触发方式普通团队不需要一步到位复刻 Uber 的基础设施。你可以用现有代码托管平台把最小闭环跑起来。前置条件主要有这些代码托管平台GitHub、GitLab、Gitea 都可以。一个 Agent 专用账号也就是机器人账号独立于开发人员个人账号。一个接收事件的入口通常用 Webhook也可以在 CI 里触发。一个部署环境可以是一台轻量服务器、一个 Docker 容器或者一个无服务器函数。模型访问凭证优先通过环境变量或密钥管理服务注入不要硬编码进仓库。一个存储任务状态的数据库SQLite 起步就够PR 量大了再换 PostgreSQL。在权限方面我建议最小化授权。Agent 账号只需要能读取 PR 信息和提交评论不需要代码写入权限也不需要管理员权限。权限越小出问题的面越小。3.2 最小闭环先做一个只写评论的 Agent不要一上来就做复杂的批量处理、自动合并、自动回滚。第一步的目标很简单有一个 PR 被开启或更新时Agent 根据这次变更生成一条摘要评论评论里有变更范围、涉及文件和需要注意的点。下面是一段逻辑示意说明最小闭环的流程不是某个代码托管平台的现成 SDK 文档。# 伪代码一个只写评论的 PR Agent def handle_pr_opened(pr): # 1. 拉取变更信息 diff get_pr_diff(pr) # 2. 先做前置过滤器 if not diff: return if len(diff) 5000: post_notice(pr, 本次变更过大跳过 Agent 自动评论) return # 3. 构造精简上下文 prompt build_summary_prompt(pr.title, pr.commit_messages, diff) # 4. 调用模型设置超时和重试上限 result call_model(prompt, max_retry2, timeout30) # 5. 写入评论 post_comment(pr, result) # 6. 记录 token 消耗用于成本核算 save_usage(pr, result.tokens)这段逻辑最值得注意的点有三个前置过滤器、超时重试上限、用量记录。前置过滤器解决的是“不要让 Agent 处理所有 PR”。变更过大的 PR模型容易丢上下文评论质量也差不如直接跳过。超时重试上限解决的是“不要让 Agent 卡死或反复烧钱”。模型调用超时后跳过该 PR进入人工兜底。用量记录解决的是“上线之后你怎么知道贵不贵”。没有成本记录后面优化无从谈起。3.3 阶段二按规则决定哪些 PR 走 Agent哪些走人工最小闭环跑通后再考虑第二步接入分流规则。分流规则要放在 Agent 调用模型之前。千万不要让 Agent 自己判断“这个 PR 是否值得分析”模型建议只能作为辅助参考真正的过滤逻辑应该由规则引擎完成这样可解释、可调试、可审计。常见规则包括按 diff 行数少于 300 行的 PR 走 Agent超过 500 行的 PR 转人工中间部分先用规则打分。按文件路径src/payment/、src/auth/这类高风险目录直接转人工。按 PR 类型依赖升级、配置修改、格式化重构这些重复性任务优先走 Agent。按作者新成员的 PR 更适合人工多看核心老成员的常规 PR 可以先用 Agent 辅助。规则可以用 JSON 或 YAML 配置便于业务团队直接修改不需要改代码。下面是示意配置rules: - name: 依赖升级自动摘要 match: title_contains: [Bump, chore(deps)] changed_files_suffix: [.lock, .toml, .xml] action: agent_review - name: 支付相关目录不自动处理 match: changed_files_prefix: [src/payment/, src/auth/] action: human_review - name: 超大 PR 转人工 match: diff_line_count_gte: 500 action: human_review这套配置的意义是把风险高低判断交给规则而不是交给模型。规则的好处是结果稳定出问题时容易定位不用去猜模型为什么做了某个决定。3.4 阶段三把 Agent 编排进现有 CI/CD 流水线当单 PR 评论稳定后可以进入第三阶段把 Agent 作为 CI/CD 流水线的一部分。这时候 Agent 不只是被动处理 Webhook而是会和现有测试、构建、部署有交互。需要注意几点以非阻塞模式接入。Agent 的评论和检查结果不影响 PR 的 merge 流程即使 Agent 挂了代码评审和合并仍然照常进行。统一日志。把 Agent 的处理记录、Token 消耗、错误原因都写入同一个日志系统方便后面排查。保留人工开关。当 Agent 的错误率上升时团队可以一键把流量切回全人工等待问题修复后再切换。不在流水线里自动 approve。Agent 在 CI 里可以作为检查项但不要让它拥有 approve 权限也不要在它成功时自动放行。这里说的“编排”不一定非要用复杂的 Agent 框架。如果 PR 量不大一个队列、一个 Worker、一张任务表就够。只有当任务类型变多需要多个 Agent 协作时再考虑引入 Agent 框架和编排层。我一般建议新团队直接认准“先单任务再批量再编排”的顺序。跳过任何一步后面都要补课。4. 哪些环节能接管哪些不能4.1 适合自动化的高重复环节Agent 真正有价值的地方是为开发者省掉低质量重复劳动。PR 描述生成是很典型的一类。很多开发者不喜欢写描述提交信息也比较随意。Agent 可以根据 commit message 和 diff 自动生成一段描述包含改动背景和影响范围。虽然不一定完美但比空描述强得多。规范初筛也很适合。代码库如果有 ESLint、Prettier、Checkstyle 这类工具Agent 可以把工具输出翻译成面向开发者的建议而不是让开发者自己去翻一堆工具的原始日志。CI 失败归类同样适合。CI 失败时开发者第一件事是看日志。Agent 可以自动判断是编译失败、测试断言失败、超时还是环境问题并评论在对应 PR 下面。这样开发者在手机上就能了解问题不用先打开日志。4.2 必须保留人工的环节自动化边界要守得住。下面这些环节我不建议交给 Agent最终功能验收。Agent 可以描述代码做了什么但能否通过产品预期必须有人确认。架构评审。涉及模块边界、技术选型、长期维护成本的判断模型很难理解团队历史决策。数据库迁移评审。改表结构、加索引、数据回填一旦出问题影响是线上的。安全权限相关。密钥管理、权限模型、用户数据访问控制这些应该由安全负责人把关。争议处理和最终决策。评审双方意见不一致时Agent 不应该出来当裁判。简单说Agent 负责“把事实摆出来、把规范跑一遍、把异常标出来”人负责“拍板”。4.3 权限和审批红线设计权限设计是所有 Agent 项目里最容易踩坑的地方。一开始就把权限放开后面很难再收回来。我的建议是Agent 默认只有评论权限没有 approve 权限没有 merge 权限没有修改分支权限。Agent 不能直接触发部署流程除非是已经验证过的低风险依赖升级也不要让它自主决定。Agent 的模型输入要对敏感信息做脱敏。日志、密钥、用户手机号、邮箱等字段要先过滤再进入 Prompt。API 密钥全部使用密钥管理工具不写死在代码和配置里。所有 Agent 自动行为必须留下审计日志至少能回答“它评论了什么、什么时候评论的、为什么触发”。权限红线不是限制 Agent 的能力而是保护团队。只要人能兜底Agent 出点小错误问题不大一旦 Agent 拥有合代码权限出问题后没有人愿意担责。5. 踩坑清单和排查链路5.1 常见失败现象Agent 接入 PR 流程后常见问题很集中。我把最常见的现象和可能原因列一下现象可能原因Agent 完全不评论Webhook 没触发、事件类型配置错、账号无权限评论出现但明显滞后队列堆积、模型调用慢、并发设置过低评论内容是乱码或无关建议输入编码问题、diff 过大、Prompt 指令冲突同一个 PR 被重复评论事件去重没做synchronize事件重复触发Token 成本上涨很快没有分流规则所有 PR 都走强模型或重试次数过多模型输出质量不稳定上下文里混入了大量无关文件或者缺少明确规范描述这些现象里大部分不是模型能力问题而是工程接入问题。先不要急着换模型按顺序排查。5.2 排查顺序遇到 Agent 异常时我建议按下面这个顺序走而不是直接打开代码看逻辑。第一步看事件日志。确认触发事件是否到达 Agent 服务。如果日志里根本没有记录问题在代码托管平台的 Webhook 配置、网络或权限。第二步看输入数据。把 Agent 实际收到的 PR 信息打印出来检查 diff 有没有拉全、文件路径是否正确、提交信息是否为空。很多问题其实是输入不对而不是模型不行。第三步看模型调用。确认模型是否返回内容是超时还是返回了空结果还是返回格式不符合解析要求。模型日志里通常会有状态码和耗时。第四步看写入结果。如果 Agent 生成了评论内容但页面上没有显示多半是评论权限、接口权限或账号配置问题。第五步看分流规则。检查 PR 是不是被规则过滤掉了或者进入了一条不该进的处理路径。规则配置的优先级和顺序经常是问题来源。排查时不要一上来就重新发一遍 Prompt。先确认事件到了没有、输入对不对、调用成功没有多数问题在源头就能发现。5.3 效果评估和边界控制评估 Agent 效果不能只看“接了多少 PR”还要看有没有节约真实人力。我建议用两周小流量试点并且只针对某一个仓库、某一种 PR 类型。试点阶段需要记录Agent 评论数量。开发者点击、展开评论的比例也就是互动率。开发者明确采纳评论建议的次数可以通过“按 Agent 建议修改后重新提交”来判定。误报率开发者标记为无效或直接关闭提示的比例。PR 平均从开启到合并的时间是否有变化。人工评审者花在“重复规范类评论”上的时间是否减少。如果互动率低、误报率高先不要扩大覆盖率。把 Prompt 和规则调整到评论质量稳定后再慢慢放开流量。如果把 Agent 当成一个“所有 PR 都要产生评论”的工具最终只会得到一堆没人看的噪音。真正好的 PR Agent 应该该说的才说不该说的保持安静。6. 你的团队要不要追这个模式6.1 什么团队适合PR 量大、重复评审多、流程相对标准化的团队更容易从这个模式里获得收益。如果你们的 PR 主要是功能开发而且已经有比较明确的代码规范、已有 CI 检查、有稳定的测试流程那 Agent 参与 PR 摘要和规范初筛会很有价值。它不会替代评审者但会让评审者把注意力放在更重要的逻辑问题上。如果团队里已经有做 Agent 开发的人有一定模型调用和 Prompt 工程经验推进起来会更快。没有也别慌用最简单的 Webhook 加模型调用也能起步不一定需要复杂框架。6.2 不建议一上来模仿的几种情况反过来有些团队不适合过早追这个模式。如果你只有几个人一周只有十几个 PR那接入 Agent 的收益可能还抵不上维护 Promot 和规则的成本。这种情况更适合先人工评审把流程规范沉淀下来。如果代码库本身没有统一规范Agent 很难给出稳定意见。它看到的代码风格千奇百怪输出的评论也会忽好忽坏开发者很快就会忽略它。如果没有人力维护 Prompt 和分流规则我也不建议硬上。Agent 不是部署完就不用管的工具它需要根据反馈持续调整。一个没人维护的 Agent会逐渐变成 PR 页面上的一条噪音。6.3 我的建议先做 20% 的自动化回到 Uber 这个案例我觉得最值得学习的不是 70% 这个数字而是他们把一个高频流程拆成了可量化、可控制、可验证的工程任务。对大多数团队来说我更建议先做 20% 的自动化只让 Agent 处理 PR 摘要、测试结果归类、基础规范检查这三件事。这三个环节规则清晰、失败影响小、人力成本高是最容易见效的切入角度。把这三件事跑稳定评估收益再决定要不要扩展到代码评审、依赖升级、CI 排查。每扩展一步都要同步扩展成本控制和权限边界。如果你问我个人怎么选我会把单任务跑稳放在第一位把覆盖率放在最后。Agent 能评论多少 PR 不重要重要的是它发出的每一条评论都是开发者愿意认真看的内容。踩过几次坑之后我发现这类项目真正难的不是“让 Agent 做更多事”而是让它在有限的预算、有限的权限、有限的风险范围内把一件事做好。能做到这一点70% 是自然结果不是硬性指标。