早上十点我习惯性地刷了一遍团队的 PR 列表结果发现一个有意思的现象好几条新提交的 PRcommit 信息规规整整描述模板填得一丝不苟测试也全部跑绿但提交人是我没见过的账号头像是个卡通章鱼。点开一看原来是部门最近在试跑的 AI Agent自动把一段需求拆成变更、写代码、跑测试、出 PR一条龙。我当时的反应是“有点东西”但也没太当回事直到后来看到一个数字Uber 放出来的数据Agent 已经在整个代码变更流程里接管了大约 70% 的 PR。这个数据放在两年前我是绝对不会信的。那时候大家对 AI 写代码的认知基本停留在“给 Copilot 当个自动补全工具”的水平输出质量时好时坏代码里时不时夹带点私有 API 幻觉别说自动提 PR能让它把当前文件改对就不错了。但最近这半年情况明显变了。围绕 Agent、PR 自动化、代码生成的工作流开始密集出现我也在不同团队里见证了同样一套逻辑被反复验证不是 AI 突然变聪明了而是我们终于把“写代码”这件事拆成了 Agent 能接管、能验证、能闭环的流水线。这篇文章我想把这套东西掰开揉碎讲清楚Uber 那 70% 是怎么来的Agent 在实际代码流程里到底做了什么以及一个普通团队或独立开发者现在能做什么才能跟上这波节奏。1. 70% 这个数字到底指的是哪一部分 PR说实话刚看到“70% PR 由 Agent 接管”这个说法时我脑子里的第一反应是那工程师在干嘛躺着数钱吗后来研究了一下 Uber 那套体系的运作逻辑才发现这个 70% 不是指 70% 的需求都让 AI 自己从头到尾搞定了而是指在 PR 的生命周期里有 70% 的环节变成了不需要人亲自动手的状态。1.1 PR 早就不是“写完代码提上去”这么简单一个 PR 的完整生命周期比大多数人想象的要长得多。简单拆一下至少包含这些环节需求理解与任务拆解从一段产品描述里提取出要改哪个模块、动哪些文件代码实现真正把 diff 写出来自测与编译本地或 CI 里跑单元测试、静态检查、类型检查PR 描述与元信息标题、改动说明、测试计划、关联 issue、reviewer 指派代码评审与修改处理 review 意见迭代提交合并前的最终校验再次跑全量测试、检查冲突、合规审查过去这些年我们所谓的“工程师效率工具”基本只覆盖了第一个和第二个环节的一部分比如 Copilot 补全、自动格式化。但从第三步开始一直到最后一步大量时间其实消耗在处理流程、等待验证、和 reviewer 来回沟通上。Uber 那套 Agent 体系的聪明之处在于它把后半段全部接了过去而且能把前半段的质量拉到足够干净让后面的自动环节能跑通。1.2 Agent 实际接管的是这四个环节根据 Uber 在工程博客和各种技术分享里透露的信息我可以把 Agent 在 PR 流程里实际承担的工作归纳成四块这四块组合起来就是那 70% 的由来。第一块是代码生成。这是最直观的部分。给定一个任务描述Agent 会把涉及到的文件找出来生成一份可运行的 diff。注意关键词是可运行不是“按格式生成一段代码就完事”。为了实现这个标准Agent 通常需要先读一遍相关模块的代码结构搞清楚现有抽象再动手写而不是看到一个 TODO 就硬塞一段逻辑进去。第二块是自动验证循环。这是最容易被低估的一环。Agent 生成了代码之后并不会直接提交而是先进入一个“自己挑自己毛病”的循环跑测试 → 发现失败 → 读报错 → 修改代码 → 再跑。这个循环在 CI 里是自动化的在 Agent 设计里则是核心的 self-correct 过程。很多团队最开始做 AI 编程时效果差就是因为跳过了这一环只让模型写代码不让模型看测试结果效果自然跟盲写差不多。Uber 的实践是把验证循环做成闭环代码质量才能达到可以进 PR 的程度。第三块是PR 的完整包装。这听起来像小事但在大团队里其实是很大的工作量。一个符合规范的 PR 需要写清楚背景、改动清单、如何测试、有没有破坏性变更、target 哪个版本分支。Agent 可以自动生成这些内容而且格式永远统一永远记得关联对应的 issue 编号比人类工程师在周五下午写的敷衍描述要靠谱太多。第四块是初步代码审查。Agent 提完 PR 之后会自己先把一遍关也就是所谓的 self-review。它会按照团队预设的规则查一遍是不是有调试代码忘了删、是不是有没处理的边界条件、命名是不是统一、有没有明显重复代码。这一步相当于把所有低质量的 PR 在递交给人类 reviewer 之前就筛掉了一轮让人力只集中在真正的技术判断上。1.3 70% 不是玄学用数据视角理解理解 70% 这个数字还有个角度它不是一次性达到的而是一个演化结果。早期可能只有 10% 的简单 PR 能由 Agent 完整生成比如修改一个配置文件、添加一个新的 API 端点、修复一个明确的小 bug。随着 Agent 和代码库的磨合它开始能处理更大范围的改动比如跨两个服务的数据流调整、增加一个新的数据库字段并同步修改读写逻辑。到了稳定期团队会发现大部分 PR 本质上是有“套路”的。它们遵循已有的代码模式改动范围清晰验证方式明确。这类 PR 占到总数的七成并不夸张。真正剩下的三成是那些需要产品判断、架构权衡、跨团队协商的复杂变更这些短期内还是人的主场。所以更准确的说法是不是 AI 抢走了 70% 的工作而是 70% 的“套路型编码”被剥离出来自动化了。2. Agent 不是换个工具是整个研发流程被重写了很多团队试过引入 AI Agent 之后大失所望原因基本一致他们只把 Agent 当成一个更智能的代码补全插件没有改变周边的基础设施和流程规范。Uber 能跑到 70%核心不是模型多厉害而是整个工程体系被打磨成了适合 Agent 发挥的形态。2.1 依赖一套足够强的 CI 和沙盒验证体系Agent 自动提 PR 的前提是它能在不打扰人的情况下快速验证自己的代码是不是真的能用。如果每次验证都要排队等 CI 半小时Agent 的效率会暴跌因为它在自我纠正循环里每改一轮都要等一轮而人类工程师可能等不起就会介入。Uber 的做法是提供一套足够快的增量验证能力只跑受影响的测试子集、分钟级甚至秒级的编译检查、可控的沙盒环境。Agent 在这个沙盒里随便折腾不用担心把主分支搞坏。这一点我感触特别深。去年我带个小团队也尝试做类似的事卡的最狠的不是模型选型而是 CI 太慢。Agent 每改一次代码要等十几分钟才能看到测试反馈然后它还要再改再等一个简单 PR 拖了俩小时。后来把测试拆了分层本地路径的先跑小套件全量留到晚上跑速度上来了Agent 的成功率才明显提升。所以说没有基础设施铺垫Agent 就是个玩具。2.2 代码规范与模块边界必须提前治理Agent 自动生成代码最容易翻车的场景是一个模块的边界极其混乱到处是隐式依赖改一处炸三处。这种代码库别说 AI人类工程师上手都要小心翼翼。Uber 这种体量的公司代码规范已经沉淀得很深模块之间靠接口沟通项目里有一套清晰的目录结构和命名约定Agent 在生成内容时有非常明确的参照系产出就稳定得多。所以如果你想在团队里推 Agent 流程第一个要做的不是买模型 API而是把代码库里的“潜规则”显性化。到底哪里该放工具函数哪里是数据访问层异常应该抛出还是吞掉这些如果不写清楚Agent 就只能靠猜猜出来的代码格式对逻辑也能跑但就是跟你团队的气质不符review 的人看着难受最后还是要手工返工。2.3 人在流程里的角色从执行者变成了审核者和兜底者很多人听到 70% 就慌觉得工程师要被取代。但我看了 Uber 那一套流程之后反而觉得它把工程师从繁琐的执行里解放出来了让人的工作变得更像“技术 owner”而不是“写码工”。Agent 负责把 PR 送到一个“可评审”的状态而工程师的主要精力集中在三件事上判断这个 PR 有没有改对方向回答 Agent 在注释里留下的疑问以及处理那 30% 真正有挑战的复杂变更。这意味着一个新的工作习惯review PR 不再是从头到尾读 diff而是先看 Agent 生成的设计摘要、自检报告、测试结果再针对性的看关键逻辑。如果 Agent 已经把低层问题都扫过一遍了人类 reviewer 就可以把力气花在真正的架构判断上而不是天天抓“你是不是少了个分号”这种鸡毛蒜皮。这个转变对老工程师来说体验很好因为终于不用再看低级错误了但对新人的培养方式提出了新挑战——这是后话。2.4 和“自动补全”式工具的本质差异人在驾驶位上还是在监管位上拿 Agent 和传统的 AI 辅助编程工具比最根本的区别是交互模式变了。传统的 Copilot 类是“人在驾驶位上AI 做副驾”模型基于你当前的上下文给你补下一行、下一个函数节奏由人控制。Agent 则反过来“AI 在驾驶位上人做监管”你给一个目标它自己规划路径、执行、检查、纠错最后把结果交给你验收。这个差异直接改变了你应该如何评估工具。评估 Copilot 类工具你看的是它能不能猜中你想要的代码评估 Agent 类工具你看的是它能不能在没人管的情况下自己跑完一整个任务闭环。前者的指标是“补全准确率”后者的指标其实是“端到端成功率”也就是它开出 PR 之后你需不需要大幅返工。Uber 那 70% 的意思就是大部分 PR 交出来之后人只需要做少量调整甚至直接 approve。3. 做成这件事的门槛到底在哪看到这里你可能会觉得听起来也没那么难嘛那我也搞一个。但现实是能从 Agent 流程里吃到红利的团队都有一些共同的“隐性门槛”。这些门槛决定了一个团队是能跑到 70%还是卡在 20% 就上不去了。3.1 工程债是最大的隐形拦路虎这是我最想强调的一点。Agent 对代码库的“整洁度”要求比人类工程师高得多。人类工程师可以忍受一个历史遗留的烂模块靠经验绕开那些坑Agent 没有这种绕开能力它只会根据上下文推演如果上下文里全是坑它就会用更创新的方式踩出新的坑。比如在一个测试覆盖率不到 30% 的项目里Agent 很难做自动验证循环因为改了代码之后没有足够的测试兜底来告诉它改对了还是改错了。结果就是 Agent 只能靠静态检查和一两次本地跑通来判断质量自然上不去。Uber 的测试基建已经很成熟才能撑起这么高的自动化比例。所以说想搞 Agent 流程先把测试补起来这是一切的前提。3.2 算力和成本投入每个 PR 都不是免费的Agent 自动写 PR 看着爽但背后是实打实的推理成本。每生成一个 PRAgent 可能要在内部跑几十次甚至上百次模型推理如果启用了多轮自我纠正循环成本还要更高。Uber 这种体量的公司能承担这种成本因为它省下来的工程师时间远超模型调用费用。但对小团队来说这个账就要算得很清楚如果 Agent 一天帮你省了俩小时但模型费用吃掉了一个小时的人工成本那它的价值就有限了。不过这块的成本下降速度非常快模型 API 的价格一年内腰斩不止开源模型做本地部署也越来越香。我的建议是不要因为成本就放弃而是先跑通流程再逐步优化模型选型和缓存策略把单 PR 成本降下来。3.3 安全、合规和代码所有权问题Agent 自动生成并提交代码引出了一堆过去不存在的问题代码所有权到底归谁如果 Agent 用了训练数据里有版权争议的代码段责任怎么算在强合规的行业里Agent 能不能碰涉及用户隐私或金融交易的代码这些不是技术问题但对落地的阻碍比技术问题还大。Uber 的做法比较务实先划禁区再逐步扩展。比如涉及安全敏感的变更、需要多人评审的架构级改动明确规定不让 Agent 碰Agent 只负责那些风险低、模式成熟的改动。等信任度积累够了再一点点扩大范围。这套策略值得所有团队借鉴不要在第一天就想让 Agent 接管一切。3.4 小团队和个人项目能不能复刻能但要学会做减法。你不需要一步到位搭一套完整的 Agent 基础设施可以先从最简单的半自动方式开始用 Agent 生成代码骨架和 PR 描述你负责审查修改和提交。这是一个几乎零风险的起点能让你先感受到工作流的变化再决定要不要继续深入。个人项目更灵活很多规则都可以自己定甚至可以在自己最常用的仓库里先跑起来体验一下自动 PR 是什么感觉。4. 从 0 到 70%普通团队可以复制的渐进路线既然不是所有团队都能一步到位那从普通状态到 Uber 那个级别的自动化路径到底长什么样我结合自己团队的经验以及观察到的行业案例拆解出一条四阶段的渐进路线每个阶段都有明确的目标、工具和验收标准。4.1 阶段一人写代码Agent 做 PR 包装和自审这个阶段的目的很纯粹让团队先建立对 Agent 的信任同时零风险地体验它带来的便利。具体操作上工程师还是照常自己写代码提交之前把 diff 丢给 Agent让它做三件事生成规范的 PR 标题和描述按团队模板自动列出改动文件和测试计划以 reviewer 的视角挑毛病包括遗漏的边界情况、不合理命名、没清理的调试代码等这个阶段几乎不需要额外的基础设施改造现有 CI/CD 流程完全不用动。工程师只需要在本地或网页端打开 Agent 工具把 diff 贴进去把生成的 PR 描述和 review 意见复制过来即可。我实测下来这个阶段对 PR 质量的提升非常直观尤其是团队里如果有刚入职的新人Agent 给的 review 意见比老工程师在 code review 时口头讲的更结构化新人学到的东西反而更多。这个阶段建议跑两到四个星期目的是收集数据Agent 提示出的问题里有多少是真实的它生成的描述需要修改几轮这些数据会决定你能不能进第二阶段。4.2 阶段二Agent 出 draft PR人在合入前确认到了这个阶段你需要开始改造基础设施了。核心动作是允许 Agent 把代码直接推到远端以 draft PR 的状态提交。注意是 draft PR不是直接可评审的 PR。draft 状态在 GitHub、GitLab 里都有意味着“这东西还没准备好仅供预览”。Agent 会把代码和 PR 描述都生成好然后通过 IM 或邮件通知对应的工程师来确认。工程师的确认流程是快速扫一眼 Agent 生成的 PR重点看它的实现思路是否符合团队设计的约定而不是一行行细读。如果思路没问题就点一下标记 ready for review或者自己补几个小改动再合入。如果思路有问题就在 Agent 生成的 PR 下面直接回复意见让它重新生成。这个阶段最考验的是 CI 质量。Agent 推到远端之后CI 能不能快速跑完增量测试会极大影响体验。如果 CI 要跑四十分钟Agent 每改一轮都是四十分钟的等待工程师等得不耐烦就会忍不住自己上手。所以这个阶段一定要先把测试分层做好提交触发快速检查合入前才跑全量。4.3 阶段三低风险模块全自动 PR 人工抽查到了这个阶段你已经积累了不少数据对不同模块的 Agent 成功率心里有数了。这时候可以做一个大胆的动作对风险较低的模块比如内部工具库、无状态 API 端点、配置变更、模板改动等开启全自动 PR 流程。Agent 生成代码、跑测试、出 PR直接标记 ready for review然后自动分配给一位 reviewer。但有个关键机制必须设计好人工抽查。不抽查Agent 很容易悄悄往代码库里堆“看起来对但没考虑全”的代码。我们当时的做法是每个开发迭代随机抽取 20%-30% 的 Agent PR 做深度人工 review看看是不是有系统性缺陷。同时设定一个“退化阈值”一周内 Agent PR 的合并后回滚率如果超过 X%就暂停全自动流程回到阶段二排查原因。抽查机制让自动化流程有了安全网也让我们能持续监控质量。4.4 阶段四建立“Agent 开发 Agent”的飞轮这是比较进阶的玩法也是迈向 70% 的最后一环。当你有了一批高质量的历史 PR 数据后就可以开始微调一个属于自己团队的专用 Agent 模型或者至少积累一套高质量 prompt 模板和 few-shot 示例让后续的 Agent 更懂你们团队的代码风格和设计约定。Uber 能做到 70%很大程度是因为它的 Agent 不是通用模型直接调 API而是深度适配了自身代码库的体系。普通团队不用追求到这个深度但至少可以做到每次人工修改 Agent 生成的代码时记录下修改内容定期整理成“纠错文档”回填到 prompt 或 RAG 知识库里让 Agent 逐步减少重复犯错。跑这个循环半年下来你会明显感觉到 Agent 生成的 PR 越来越合你的心意人工介入的幅度越来越小。5. 跑了一段时间 Agent 自动 PR 之后我踩过的几个坑最后这部分纯粹是我自己和身边团队在实践过程中总结出来的血泪经验。网上关于 AI Agent 的教程很多但真正实战跑过三个月以上、跑过上百个 Agent 生成的 PR 之后你才会遇到这些具体问题。5.1 Agent 在“快路径”上飞快在“慢路径”上是灾难这是最容易被天花乱坠的 Demo 迷惑的地方。Demo 里展示的 Agent 都是挑那种逻辑清晰、依赖简单的小任务一顿操作猛如虎三十秒出一个 PR。但实际遇到一个需要跨五个文件、还牵扯到老接口兼容性的改动时Agent 的规划能力会明显下降可能折腾很久还在原地打转。我的经验是一定要给 Agent 设置“时间预算”和“复杂度上限”。比如改动超过 8 个文件就自动降级为 draft PR或超过 15 分钟的自纠循环就放弃并通知人来处理。别让 Agent 在一个复杂问题上无限死磕那不只是浪费时间还会把代码库搞出各种中间态。5.2 70% 之后人工 PR 的标准反而在提高这个现象很有意思。当 Agent 把大多数套路型 PR 都解决掉之后剩下的 30% 人工 PR 就是真正需要深度思考的部分。reviewer 在经历了 Agent 那些“格式工整、测试齐全、描述完整”的 PR 洗礼之后对代码质量的心理阈值会被拉高看人工提交的代码反而更容易挑刺。这可能不是坏事但也给团队提了个醒人工 PR 的体验需要保护和包容否则工程师会产生一种“我的代码还没 AI 写得好”的挫败感。管理上要做的是明确区分Agent 负责标准化人负责创造性和判断力两者评价标准不应该一样。5.3 review 从“看实现”变成了“看意图”过去 code review 的核心是“这段代码写得好不好”现在 Agent 已经把“写得好不好”这部分做了大半review 的核心变成了“这段代码为什么要这样改方向对不对”。这是工作方式的根本转换。对 reviewer 来说这意味着你需要更关注 Agent 生成的设计摘要、任务背景、边界说明而不是一头扎进 diff 的细节里。甚至可以说未来的 code review 更接近“需求对齐会”而不是“代码纠错现场”。5.4 指标别只看 PR 数量小心古德哈特法则当团队开始用“Agent 接管了多少 PR”作为考核指标时要警惕表演性生产。古德哈特法则说得很明白当一项指标变成了目标它就不再是好的指标。团队可能会为了提升 Agent PR 比例故意挑简单的任务喂给 Agent把复杂的改动也强行拆成小份让 Agent 啃结果 PR 数量上去了系统架构却在加速腐化。我的建议是关注两个真正的核心指标一是 Agent 提交的 PR 合并后回滚率二是工程师在 Agent PR 上花费的平均 review 时间。这两个指标能更真实地反映 Agent 的价值。5.5 有些领域现阶段别让 Agent 碰从实际运行的情况看有几类代码不适合让 Agent 直接操作。安全认证和权限控制相关的代码出了错代价太高涉及敏感数据迁移或大表结构变更的代码一旦出错影响面巨大跨团队多服务的联动改动沟通成本远超 Agent 现有能力。在这些领域坚持让人来写、让 Agent 来做辅助分析和 PR 包装就可以了。安全底线不能被一个“酷”字冲昏头。写在最后的个人体会说真的我从“AI 写代码只是 DEMO 噱头”到“把一部分 PR 放心交给 Agent”心态转变大概花了大半年时间。最大的顿悟就是Agent 真正的价值不在于它能“写”代码而在于它能掉进完整的工程流程里形成闭环——它会看测试结果会按模板出描述会等待 review 意见再迭代修改。这些过去被整个行业忽视的“杂活”才是开发流程里最消耗人力、最不适合人类的环节。我现在完全可以想象再过一两年一个团队的 PR 系统里大部分变更都是 Agent 在跑人类的角色更像是“产品意图的翻译者”和“最后一道安全闸门”。这不是坏事反而可能是软件工程这个行业走向更高抽象层次的开始。如果你还在观望我的建议很简单别等完美方案先找个低风险的仓库让 Agent 帮你整理第一个 PR 描述跑通一次最小流程。你现在动手付出的成本很低但积累的认知差距一两年后会非常值钱。