我最早看到Uber那条分享时第一反应是这确定不是PR稿70%的PR让Agent接走那工程师还能干嘛但后来我把他们在开发者大会上的公开内容翻了一遍发现事情没那么玄也没那么简单。简单说Uber内部把AI Agent引入了代码提交流程从一个想法到代码改动、写测试、跑CI、生成PR描述甚至收到review意见后做二次修改都有一部分交给了Agent处理最后由人类工程师做兜底把关。这篇文章不打算复述PPT上的数字而是想把这个数据拆开看Agent到底接走了PR流程里的哪些活普通团队能不能复刻这套玩法以及工程师手上的牌到底该怎么重新打。1. “70% PR被接管”到底是怎么回事1.1 被接管的不是合并权限而是“码字工作”先把这个传播最广的数字说清楚。Uber提到的70%指的是“由Agent生成代码改动/参与生成的PR数量”占到了PR总量的70%而不是说70%的PR在无人值守的情况下被自动合并进主干这两者差别非常大。我在很多群里看到有人焦虑说“工程师不动手了”“代码全让AI写了”这其实是误解。真实的流程更像是Agent作为“写代码的实习生”把第一版改动做好生成PR描述推到分支上然后人类工程师作为reviewer去看、去改、去否决。主导权始终在工程师手里Agent干的是最耗体力的那段——把零散需求翻译成代码改动把改动整理成能看的PR。这个细节很重要因为它决定了整套方案的落地姿态。Uber没有选择让Agent直接往主干推代码而是把Agent嵌到了“人类审核”的既有流程里。表面上看只是换了个写代码的人实际上是在不改变GitHub工作流习惯的前提下把生产力护城河往前推了一大截。1.2 数据背后藏着三个关键信号第一个信号是跨仓库、跨服务的代码上下文理解能力已经过了及格线。Uber这种体量的代码库服务和依赖关系极其复杂Agent不是在一个空目录里写hello world而是要理解某个内部服务的API该怎么调、测试该用什么框架、代码风格该怎么保持一致。70%这个数字说明Agent在这种“脏乱差”的真实环境里已经能稳定产出而不是只在demo里秀肌肉。第二个信号是团队对“AI生成的代码”接受度已经从尝鲜变成常态。我见过不少团队买了AI编码工具结果半年后只有两个人偶尔用根本原因不是工具不行而是流程没跟上。Uber的做法是把Agent当成一个正式的代码贡献者来对待该走review走review该挂标签挂标签这就让使用Agent不再是个人的“技术玩具”而是团队的标准工作方式。第三个信号是70%是平均值不是每个团队都到了这个比例。不同业务的代码特点、测试覆盖度、需求清晰度差异很大有的团队可能只有30%有的可能接近90%。所以如果你所在团队目前只有10%的比例也不用觉得落后关键是先把流程跑通。1.3 为什么不是100%剩下的30%给谁干这个问题的答案恰恰是理解Agent能力边界最好的窗口。剩下的30%通常集中在几类场景核心支付链路的逻辑改动、跨多个服务的架构级重构、涉及隐私合规的敏感变更以及需求本身模糊到没法拆成清晰指令的探索性任务。这些任务的共同特点不是“代码难写”而是“说不清楚要什么”。Agent对模糊需求的理解能力虽然比一年前强了不少但遇到产品经理自己都没想清楚的逻辑它也只能给你一版“看起来合理”的实现这种风险在核心模块上是不可接受的。所以Uber留下来的30%本质上不是Agent写不了这些代码而是一旦出错代价太大必须让最了解业务上下文的人类来做判断。我在自己的项目里也有同样的体感Agent在“把需求翻译成代码”这件事上越来越强但在“判断这个需求到底对不对”这件事上仍然需要人来兜底。认清这个边界才不会对Agent抱有不切实际的期待。2. Agent能接管PR靠的不只是大模型2.1 一个能“写PR”的Agent至少要过三关很多人以为把GitHub仓库喂给一个会写代码的大模型它就能自动产出PR了。真这么简单就不会有这么多团队在Agent落地上翻车了。一个能稳定干活的Agent至少要过三关。第一关是上下文关。它得知道这个仓库的结构、相关的文件在哪、依赖关系是什么、同类功能以前是怎么实现的。换到Uber的体量就是几百上千个仓库之间互相依赖Agent不能只盯着当前仓库看还得能跨仓库检索到正确的API定义和调用方式。这一关做不到后面全是空中楼阁。第二关是执行关。写代码只是第一步写完之后还得能跑起来格式化、跑lint、跑单元测试、构建出错了得读日志、找原因、改代码、重跑。这本质上是一个“计划-行动-观察-调整”的循环一个Agent如果只会在代码编辑器里生成diff但不会自己关闭报错循环那它就只能欺负最简单的场景。第三关是沟通关。代码写对了PR描述写得像鬼画符reviewer照样不想看。Agent要能生成清晰简洁的PR描述说清楚改了什么、为什么这么改、怎么测试验证还要能针对review意见给出合理的回复和修改。很多团队低估了这一关结果Agent代码能跑但人在review时看得一头雾水最后还是得重写描述效率反而更低了。2.2 从Issue到PRAgent的工作流长什么样虽然Uber官方分享里没有把完整技术栈逐行公开但从这套体系的通用形态来看Agent处理一个PR请求的标准工作流是可以还原出来的大致分七步接收任务描述从Issue、任务卡片或聊天指令里解析需求拆解成“要改什么、达到什么效果、有什么约束”。检索相关代码基于语义搜索和代码图谱找到需要修改的文件以及相关的测试、依赖、调用方。制定改动方案对比几种实现路径按最小改动原则选择方案并列出改动清单。写代码并补充测试按要求生成代码改动配套补上单元测试或集成测试。本地验证自动跑格式化、lint、静态检查、构建和测试失败就回到第4步迭代。提交分支并生成PR描述创建独立分支commit生成结构化的PR描述附上改动说明和测试结果。监听后续反馈PR创建后继续盯CI状态reviewer提了意见就基于意见迭代修改。这套流程里最容易被忽视的是第5步和第7步。很多Agent方案demo看着很酷但一接真实项目就露馅就是因为没有把“验证-反馈-迭代”这个闭环做好。Uber能做到70%说明他们的Agent在这两步上已经相当稳定。2.3 为什么先从PR环节切入而不是让Agent直接改主干我在给团队设计AI辅助开发方案的时候发现一个规律凡是让Agent自由发挥、直接改主干代码的方案最后都死得很难看凡是把Agent按进既有review流程里的方案活下来的概率就大得多。原因其实不复杂。PR是代码质量的天然闸门它自带一套人类确认机制可以让Agent的能力边界在可控范围内试错。就算Agent生成了一坨不太完美的代码reviewer也能拦住不会直接污染主干。另外PR有明确的格式和验收标准什么算完成、什么算通过边界很清楚这种结构化场景恰好是Agent最容易表现的领域。所以Uber选择从PR环节切入不是保守而是聪明。它没有改变工程师既有的工作习惯——照常在GitHub上review、合入、管理分支只是把“从零开始写PR”这个环节外包给了Agent。用最小的流程改造成本换来了最大的效率提升这也是普通团队最值得参考的思路。3. 普通团队复制这套方案从哪几步开始3.1 先盘点自己的工程底座别急着上Agent说实话很多团队看到Uber的数据就热血上头第二天就想让Agent接管全部PR结果第三天就灰头土脸撤下来。我见过太多失败案例根子不在Agent能力不行而是团队的工程底座压根没准备好。动手之前先对照下面这个清单做个体检代码托管平台用的是GitHub、GitLab还是其他平台对API的支持够不够CI/CD能力有没有现成的流水线测试和构建是不是自动跑的测试覆盖面核心模块有没有测试保护没有测试的代码Agent改完你敢合吗分支规范PR流程是否统一有没有明确的review人分配规则代码质量门槛有没有lint、静态检查、覆盖率卡点如果你团队的CI还在“点击按钮手动触发”的阶段核心服务一行测试都没有那第一步要做的不是上Agent而是先把这些基础补上。Agent本质上是个“写代码很快但不太懂事的新人”没有测试和CI当护栏它闯的祸会比省的时间多得多。3.2 第一层改造先给工程师配一个单人Agent助手工程底座达标之后我建议不要一上来就搞“Agent自动开PR”这种大动作先从最轻的一层开始给团队里的核心工程师配上单人Agent助手。这一层的做法很简单给工程师开一个能访问私有仓库的Agent工具比如Codex CLI、Claude Code这类命令行助手或者IDE里的Agent模式让他们在本地用自然语言描述需求让Agent生成改动、跑测试、提交分支。这个阶段的目标不是追求自动化比例而是让团队成员熟悉Agent的工作方式摸清它在自己代码库里的脾气。我在团队里推这个阶段时踩过一个坑一开始让所有人自由使用结果接受度两极分化严重爱折腾的人用得很爽不爱折腾的人觉得“不如自己写”。后来我们改成“先选两三个愿意尝鲜的人跑两周把常见用法沉淀成文档再组织分享推广”接受度一下就上来了。工具落地最难的不是工具本身而是改变人的习惯。3.3 第二层改造让Agent参与PR评审而不是只写代码第二层是把Agent从“写代码的助手”升级为“评审流程里的一员”。具体做法是在CI流水线里加一个Agent评审步骤PR一创建Agent自动跑一遍diff检查分析改动可能引入的bug、测试覆盖盲区、代码规范问题然后以评论的形式输出评审意见。这一步的代码逻辑其实不复杂核心是搭一个小服务监听PR创建事件拉取diff把diff和相关的仓库文档、历史代码上下文一起打包发到模型接口再把返回的评审意见以评论的形式回写到PR里。我实际用的配置里对Agent的要求分三层第一层看必改项比如明显的逻辑错误、空指针风险第二层看建议优化比如性能隐患、可读性问题第三层只给提示比如测试覆盖不足供人参考。这里有个很关键的细节Agent评审意见不能直接进入正式review流程更不能block合并它只能以“仅供参考”的机器人评论存在。一旦Agent的自动评论有了过大的决策权重工程师就会想办法绕过它整个机制就废了。保持“辅助”的定位这个工具才能活得久。3.4 第三层改造让Agent以“贡献者”身份自动创建PR做完前两层人和流程都磨合得差不多了再上第三层让Agent独立创建PR形同团队里多了一位全天候的“虚拟贡献者”。这一层才是Uber那种70%比例的实现路径。操作上Agnet会领取一个任务独立拉分支、写代码、跑测试、提交PRPR上会打上“generated-by-agent”的标签reviewer通过标签可以快速识别哪些PR是Agent生成的从而用不同的心态去review——不是不审查而是知道重点要看什么。合入门禁、Owner review规则、CI检查全部照旧Agent的PR没有任何特权。这一层能不能跑成我总结下来有三个决定性因素一是任务描述的拆解模板写得越清晰Agent产出越稳定二是仓库的上下文检索能力代码索引和文档质量直接影响Agent表现三是diff审核机制Agent容易出现“顺手改多了”的毛病需要靠diff评审钩子拦住无关改动。3.5 工具选型自研编排还是商用方案最后聊一下工具选型。市面上现在有三类东西一是通用Agent框架你可以基于它们自己编排“读取需求-检索代码-生成PR”的工作流二是商用编码Agent工具比如OpenAI的Codex、Anthropic的Claude Code、各类IDE的Agent模式三是更接近完整平台的解决方案比如GitHub Copilot coding agent这类直接和代码托管平台深度集成的能力。我自己对不同规模的团队建议如下小团队5人以内直接用商用工具的Agent模式每人一个助手先把个人效率拉满不需要自研。中型团队20-50人用商用工具轻量自建CI步骤把Agent评审、Agent自动PR这层薄薄地包一层不用自己训练模型。大团队100人以上考虑自研编排加上代码索引基建因为到了这个规模上下文检索、权限隔离、成本控制都是商用工具没法直接给的。选型时有一个原则能用别人的轮子就不要自己造。Agent领域迭代极快今天自研的编排框架可能三个月后就被某个开源项目超越了。除非你的需求真的非常特殊否则把精力放在流程设计和prompt打磨上比放在框架自研上划算得多。4. 工程师的新技能清单Agent来了谁被替代谁被放大4.1 “写代码”正在从体力活变成管理活很多开发者的焦虑点是“AI都写代码了我还要干嘛”。这个焦虑可以理解但方向错了。不是“AI替代工程师”而是“代码生产方式的劳动分工变了”。我打个比方以前工程师是木匠自己量尺寸、自己锯木头、自己打磨活干得细但慢。现在Agent是一个力气很大、手艺还不错但没什么审美的新学徒你把图样画清楚它能帮你把粗活干完剩下的精修、判断、决策还是你的。工程师的角色正在从“抡锤子的人”变成“看图说话、盯质量的人”。这个转变带来的直接结果是下面几项能力变得比以前更值钱了需求澄清能力能把模糊的产品需求拆成Agent能执行的清晰任务这个能力直接决定Agent的产出质量。代码审查能力Agent写得更快意味着你需要review的代码量更大能不能快速看出逻辑漏洞和隐性问题成了核心技能。业务上下文理解Agent不懂业务也不知道这个功能在真实场景里要怎么用只有你懂这是无法外包的壁垒。系统工程思维Agent擅长写局部代码但跨模块交互、数据一致性、故障恢复这层系统级的思考目前仍然是人的主场。4.2 把Agent当成“刚入职的实习工程师”来带这个类比是我在带团队时反复强调的。你对一个新来的实习生是什么管理方式对Agent就该是什么管理方式甚至更严格。实习生你不敢放手是因为你不知道他会捅什么篓子。Agent也一样只是它动作更快、闯祸范围更大。所以你要做三件事第一任务拆得足够细每个任务有明确的验收标准而不是一句“把这个功能实现一下”就丢给它第二给它配好工具和文档仓库里有没有清晰的README、有没有合理的代码目录结构直接决定它能不能找到该改的文件第三设定复查节奏Agent每完成一个阶段你就要检查一次不要等PR出来了再惊觉方向全错了。我个人的习惯是给Agent布置任务时一定会附上三样东西需求背景、验收清单、约束条件。缺一样都不行。需求背景告诉它为什么做验收清单告诉它做到什么程度算完约束条件告诉它哪些事不能做。有了这三个东西Agent的表现会稳定很多。4.3 把Agent生成的PR当成“外部贡献者”来管理Uber这套方案里有一个细节很值得普通团队学习就是给Agent生成的PR打上专属标签把它当外部贡献者的代码来管。这个设计的妙处在于它从流程上就锁定了风险边界。外部的陌生贡献者提交的PR你会自动提高警惕仔细看逻辑、看测试、看有没有安全风险。给Agent生成的PR打上标签等于让所有reviewer在打开PR的瞬间就切换到“审慎模式”而不是因为“这是我们自己的Agent写的”就放松警惕。在团队落地时可以配套几个具体动作给PR标签加颜色让人一眼识别设置至少一名有代码库ownership的工程师review Agent PRAgent PR里的测试覆盖率必须达到团队既定标准如果是核心模块的改动必须有第二个人二次确认。这几条规则听起来简单但在真实运行中能拦住绝大多数翻车事故。5. 我踩过的坑Agent处理PR的典型翻车与排查手记5.1 PR描述很漂亮代码却在摸鱼先说一个我早期印象最深的翻车。有一次Agent提交的PR描述写得那叫一个专业背景、方案、改动点、测试结果列得清清楚楚乍一看是高级工程师的水准。结果我点开diff一看核心逻辑压根没实现只是搭了个空壳测试也是那种“为了跑过而跑过”的假测试。后来我总结出规律大模型天生擅长生成“看起来合理”的文本所以PR描述漂亮不代表代码靠谱。防范的方法是强制要求Agent在PR描述里附上可验证的证据比如关键测试的实际输出、覆盖率报告、构建日志摘要。没有这些硬证据的PR直接打回。但这还不够人一定要拿着diff逐行看确认描述和改动对得上。把“描述漂亮”作为加分项而不是信任依据能避开大量画饼型Agent。5.2 改一行代码顺手改坏了三个文件另一个高频翻车是Agent在完成目标时“路径依赖太强”为了让它觉得代码更合理往往会附带一堆无关的重构和格式调整。你要它修一个边界问题它顺手把整个函数的命名都给你改了diff看起来很大review成本直线上升不说还容易引入隐藏回归。这类问题我排查下来根因通常是两个要么是Agent上下文检索时抓错了相关文件跑偏了要么是prompt里没有加“最小改动”的约束模型偏好生成看起来更完善的代码。解决办法有两层。提示词层面我会在任务描述里明确写“禁止无关重构只修改与目标直接相关的代码”流程层面会加一个diff规模检查步骤当单个PR改动文件数或行数超过设定的阈值时自动提示风险并要求人工确认。这两个手段一起用基本能把“顺手改坏”的概率压到很低。5.3 多个Agent同时提交互相覆盖的“幽灵冲突”当Agent被普及到团队以后会遇到一个人肉时代不太常遇到的问题多个Agent在同一个时间段基于同一个仓库状态做修改提交时互相覆盖。由于Agent的动作频率比人高得多这个问题会被急剧放大。我遇到过最头疼的一次两个Agent被安排到不同任务结果它们同时改了同一个公共模块互相把对方的改动打成冲突最后合入时代码逻辑直接错乱。排查下来我发现根因是Agent的工作流程里少了“前置同步”和“状态可见性”这两个环节。现在我们的做法是涉及公共模块的任务放进同一个队列串行执行Agent开始工作前必须先rebase到最新主干同一时间同一文件最多只有一个Agent在动合并前再强制跑一次全量测试。这套规则看起来笨但实际跑下来冲突率降了八成。5.4 常见问题速查表症状可能原因排查手段PR描述与代码改动不符模型偏好生成合理文本任务理解有偏差强制附带测试输出/覆盖率证据人工比对diffAgent改动范围失控上下文检索不准或缺少最小改动约束在prompt里明确禁止无关重构加diff规模告警多个Agent互相覆盖缺少任务队列和状态同步公共模块串行执行工作前rebase同文件互斥CI一直跑不过本地验证与CI环境不一致Agent在本地使用与CI一致的容器/脚本验证Agent对旧代码理解偏差仓库文档缺失、API用法不清晰完善README和接口注释补充相关索引生成的测试全是假断言提示词里没有测试质量的验收标准要求测试必须含失败路径审查断言有效性5.5 实操心得Agent能帮你写代码但不会替你背锅现在但凡问到要不要引入Agent来写PR我给的建议都是“要但得想清楚边界”。Agent最大的价值不是替你写代码而是把你从重复性劳动里解放出来让你把精力花在更复杂的判断和决策上。但同时你也要明白PR上签的是你的名字线上的故障不会去找Agent只会来找你和你的团队这个责任是Agent替代不了的。所以我个人体会是引入Agent最合适的心理预期不是“我去休息”而是“我换个更高级的活干”。让Agent去跑腿写初稿自己去盯架构、盯质量、盯那些机器判断不了的东西。这样你既不会被工具淘汰还能借着工具跑得更远。最后再分享一个我实测好用的技巧不要让Agent一次性生成一个巨无霸PR而是把大任务拆成几个小PR每个PR只做一件清晰的事每完成一个就合并一个。这样Agent的每一步改动都足够小、足够可控review难度低出错了也好定位回滚了也不心疼。你照这个节奏试一两周会发现Agent交付的PR质量稳定上一个大台阶。
我最早看到Uber那条分享时第一反应是这确定不是PR稿70%的PR让Agent接走那工程师还能干嘛但后来我把他们在开发者大会上的公开内容翻了一遍发现事情没那么玄也没那么简单。简单说Uber内部把AI Agent引入了代码提交流程从一个想法到代码改动、写测试、跑CI、生成PR描述甚至收到review意见后做二次修改都有一部分交给了Agent处理最后由人类工程师做兜底把关。这篇文章不打算复述PPT上的数字而是想把这个数据拆开看Agent到底接走了PR流程里的哪些活普通团队能不能复刻这套玩法以及工程师手上的牌到底该怎么重新打。1. “70% PR被接管”到底是怎么回事1.1 被接管的不是合并权限而是“码字工作”先把这个传播最广的数字说清楚。Uber提到的70%指的是“由Agent生成代码改动/参与生成的PR数量”占到了PR总量的70%而不是说70%的PR在无人值守的情况下被自动合并进主干这两者差别非常大。我在很多群里看到有人焦虑说“工程师不动手了”“代码全让AI写了”这其实是误解。真实的流程更像是Agent作为“写代码的实习生”把第一版改动做好生成PR描述推到分支上然后人类工程师作为reviewer去看、去改、去否决。主导权始终在工程师手里Agent干的是最耗体力的那段——把零散需求翻译成代码改动把改动整理成能看的PR。这个细节很重要因为它决定了整套方案的落地姿态。Uber没有选择让Agent直接往主干推代码而是把Agent嵌到了“人类审核”的既有流程里。表面上看只是换了个写代码的人实际上是在不改变GitHub工作流习惯的前提下把生产力护城河往前推了一大截。1.2 数据背后藏着三个关键信号第一个信号是跨仓库、跨服务的代码上下文理解能力已经过了及格线。Uber这种体量的代码库服务和依赖关系极其复杂Agent不是在一个空目录里写hello world而是要理解某个内部服务的API该怎么调、测试该用什么框架、代码风格该怎么保持一致。70%这个数字说明Agent在这种“脏乱差”的真实环境里已经能稳定产出而不是只在demo里秀肌肉。第二个信号是团队对“AI生成的代码”接受度已经从尝鲜变成常态。我见过不少团队买了AI编码工具结果半年后只有两个人偶尔用根本原因不是工具不行而是流程没跟上。Uber的做法是把Agent当成一个正式的代码贡献者来对待该走review走review该挂标签挂标签这就让使用Agent不再是个人的“技术玩具”而是团队的标准工作方式。第三个信号是70%是平均值不是每个团队都到了这个比例。不同业务的代码特点、测试覆盖度、需求清晰度差异很大有的团队可能只有30%有的可能接近90%。所以如果你所在团队目前只有10%的比例也不用觉得落后关键是先把流程跑通。1.3 为什么不是100%剩下的30%给谁干这个问题的答案恰恰是理解Agent能力边界最好的窗口。剩下的30%通常集中在几类场景核心支付链路的逻辑改动、跨多个服务的架构级重构、涉及隐私合规的敏感变更以及需求本身模糊到没法拆成清晰指令的探索性任务。这些任务的共同特点不是“代码难写”而是“说不清楚要什么”。Agent对模糊需求的理解能力虽然比一年前强了不少但遇到产品经理自己都没想清楚的逻辑它也只能给你一版“看起来合理”的实现这种风险在核心模块上是不可接受的。所以Uber留下来的30%本质上不是Agent写不了这些代码而是一旦出错代价太大必须让最了解业务上下文的人类来做判断。我在自己的项目里也有同样的体感Agent在“把需求翻译成代码”这件事上越来越强但在“判断这个需求到底对不对”这件事上仍然需要人来兜底。认清这个边界才不会对Agent抱有不切实际的期待。2. Agent能接管PR靠的不只是大模型2.1 一个能“写PR”的Agent至少要过三关很多人以为把GitHub仓库喂给一个会写代码的大模型它就能自动产出PR了。真这么简单就不会有这么多团队在Agent落地上翻车了。一个能稳定干活的Agent至少要过三关。第一关是上下文关。它得知道这个仓库的结构、相关的文件在哪、依赖关系是什么、同类功能以前是怎么实现的。换到Uber的体量就是几百上千个仓库之间互相依赖Agent不能只盯着当前仓库看还得能跨仓库检索到正确的API定义和调用方式。这一关做不到后面全是空中楼阁。第二关是执行关。写代码只是第一步写完之后还得能跑起来格式化、跑lint、跑单元测试、构建出错了得读日志、找原因、改代码、重跑。这本质上是一个“计划-行动-观察-调整”的循环一个Agent如果只会在代码编辑器里生成diff但不会自己关闭报错循环那它就只能欺负最简单的场景。第三关是沟通关。代码写对了PR描述写得像鬼画符reviewer照样不想看。Agent要能生成清晰简洁的PR描述说清楚改了什么、为什么这么改、怎么测试验证还要能针对review意见给出合理的回复和修改。很多团队低估了这一关结果Agent代码能跑但人在review时看得一头雾水最后还是得重写描述效率反而更低了。2.2 从Issue到PRAgent的工作流长什么样虽然Uber官方分享里没有把完整技术栈逐行公开但从这套体系的通用形态来看Agent处理一个PR请求的标准工作流是可以还原出来的大致分七步接收任务描述从Issue、任务卡片或聊天指令里解析需求拆解成“要改什么、达到什么效果、有什么约束”。检索相关代码基于语义搜索和代码图谱找到需要修改的文件以及相关的测试、依赖、调用方。制定改动方案对比几种实现路径按最小改动原则选择方案并列出改动清单。写代码并补充测试按要求生成代码改动配套补上单元测试或集成测试。本地验证自动跑格式化、lint、静态检查、构建和测试失败就回到第4步迭代。提交分支并生成PR描述创建独立分支commit生成结构化的PR描述附上改动说明和测试结果。监听后续反馈PR创建后继续盯CI状态reviewer提了意见就基于意见迭代修改。这套流程里最容易被忽视的是第5步和第7步。很多Agent方案demo看着很酷但一接真实项目就露馅就是因为没有把“验证-反馈-迭代”这个闭环做好。Uber能做到70%说明他们的Agent在这两步上已经相当稳定。2.3 为什么先从PR环节切入而不是让Agent直接改主干我在给团队设计AI辅助开发方案的时候发现一个规律凡是让Agent自由发挥、直接改主干代码的方案最后都死得很难看凡是把Agent按进既有review流程里的方案活下来的概率就大得多。原因其实不复杂。PR是代码质量的天然闸门它自带一套人类确认机制可以让Agent的能力边界在可控范围内试错。就算Agent生成了一坨不太完美的代码reviewer也能拦住不会直接污染主干。另外PR有明确的格式和验收标准什么算完成、什么算通过边界很清楚这种结构化场景恰好是Agent最容易表现的领域。所以Uber选择从PR环节切入不是保守而是聪明。它没有改变工程师既有的工作习惯——照常在GitHub上review、合入、管理分支只是把“从零开始写PR”这个环节外包给了Agent。用最小的流程改造成本换来了最大的效率提升这也是普通团队最值得参考的思路。3. 普通团队复制这套方案从哪几步开始3.1 先盘点自己的工程底座别急着上Agent说实话很多团队看到Uber的数据就热血上头第二天就想让Agent接管全部PR结果第三天就灰头土脸撤下来。我见过太多失败案例根子不在Agent能力不行而是团队的工程底座压根没准备好。动手之前先对照下面这个清单做个体检代码托管平台用的是GitHub、GitLab还是其他平台对API的支持够不够CI/CD能力有没有现成的流水线测试和构建是不是自动跑的测试覆盖面核心模块有没有测试保护没有测试的代码Agent改完你敢合吗分支规范PR流程是否统一有没有明确的review人分配规则代码质量门槛有没有lint、静态检查、覆盖率卡点如果你团队的CI还在“点击按钮手动触发”的阶段核心服务一行测试都没有那第一步要做的不是上Agent而是先把这些基础补上。Agent本质上是个“写代码很快但不太懂事的新人”没有测试和CI当护栏它闯的祸会比省的时间多得多。3.2 第一层改造先给工程师配一个单人Agent助手工程底座达标之后我建议不要一上来就搞“Agent自动开PR”这种大动作先从最轻的一层开始给团队里的核心工程师配上单人Agent助手。这一层的做法很简单给工程师开一个能访问私有仓库的Agent工具比如Codex CLI、Claude Code这类命令行助手或者IDE里的Agent模式让他们在本地用自然语言描述需求让Agent生成改动、跑测试、提交分支。这个阶段的目标不是追求自动化比例而是让团队成员熟悉Agent的工作方式摸清它在自己代码库里的脾气。我在团队里推这个阶段时踩过一个坑一开始让所有人自由使用结果接受度两极分化严重爱折腾的人用得很爽不爱折腾的人觉得“不如自己写”。后来我们改成“先选两三个愿意尝鲜的人跑两周把常见用法沉淀成文档再组织分享推广”接受度一下就上来了。工具落地最难的不是工具本身而是改变人的习惯。3.3 第二层改造让Agent参与PR评审而不是只写代码第二层是把Agent从“写代码的助手”升级为“评审流程里的一员”。具体做法是在CI流水线里加一个Agent评审步骤PR一创建Agent自动跑一遍diff检查分析改动可能引入的bug、测试覆盖盲区、代码规范问题然后以评论的形式输出评审意见。这一步的代码逻辑其实不复杂核心是搭一个小服务监听PR创建事件拉取diff把diff和相关的仓库文档、历史代码上下文一起打包发到模型接口再把返回的评审意见以评论的形式回写到PR里。我实际用的配置里对Agent的要求分三层第一层看必改项比如明显的逻辑错误、空指针风险第二层看建议优化比如性能隐患、可读性问题第三层只给提示比如测试覆盖不足供人参考。这里有个很关键的细节Agent评审意见不能直接进入正式review流程更不能block合并它只能以“仅供参考”的机器人评论存在。一旦Agent的自动评论有了过大的决策权重工程师就会想办法绕过它整个机制就废了。保持“辅助”的定位这个工具才能活得久。3.4 第三层改造让Agent以“贡献者”身份自动创建PR做完前两层人和流程都磨合得差不多了再上第三层让Agent独立创建PR形同团队里多了一位全天候的“虚拟贡献者”。这一层才是Uber那种70%比例的实现路径。操作上Agnet会领取一个任务独立拉分支、写代码、跑测试、提交PRPR上会打上“generated-by-agent”的标签reviewer通过标签可以快速识别哪些PR是Agent生成的从而用不同的心态去review——不是不审查而是知道重点要看什么。合入门禁、Owner review规则、CI检查全部照旧Agent的PR没有任何特权。这一层能不能跑成我总结下来有三个决定性因素一是任务描述的拆解模板写得越清晰Agent产出越稳定二是仓库的上下文检索能力代码索引和文档质量直接影响Agent表现三是diff审核机制Agent容易出现“顺手改多了”的毛病需要靠diff评审钩子拦住无关改动。3.5 工具选型自研编排还是商用方案最后聊一下工具选型。市面上现在有三类东西一是通用Agent框架你可以基于它们自己编排“读取需求-检索代码-生成PR”的工作流二是商用编码Agent工具比如OpenAI的Codex、Anthropic的Claude Code、各类IDE的Agent模式三是更接近完整平台的解决方案比如GitHub Copilot coding agent这类直接和代码托管平台深度集成的能力。我自己对不同规模的团队建议如下小团队5人以内直接用商用工具的Agent模式每人一个助手先把个人效率拉满不需要自研。中型团队20-50人用商用工具轻量自建CI步骤把Agent评审、Agent自动PR这层薄薄地包一层不用自己训练模型。大团队100人以上考虑自研编排加上代码索引基建因为到了这个规模上下文检索、权限隔离、成本控制都是商用工具没法直接给的。选型时有一个原则能用别人的轮子就不要自己造。Agent领域迭代极快今天自研的编排框架可能三个月后就被某个开源项目超越了。除非你的需求真的非常特殊否则把精力放在流程设计和prompt打磨上比放在框架自研上划算得多。4. 工程师的新技能清单Agent来了谁被替代谁被放大4.1 “写代码”正在从体力活变成管理活很多开发者的焦虑点是“AI都写代码了我还要干嘛”。这个焦虑可以理解但方向错了。不是“AI替代工程师”而是“代码生产方式的劳动分工变了”。我打个比方以前工程师是木匠自己量尺寸、自己锯木头、自己打磨活干得细但慢。现在Agent是一个力气很大、手艺还不错但没什么审美的新学徒你把图样画清楚它能帮你把粗活干完剩下的精修、判断、决策还是你的。工程师的角色正在从“抡锤子的人”变成“看图说话、盯质量的人”。这个转变带来的直接结果是下面几项能力变得比以前更值钱了需求澄清能力能把模糊的产品需求拆成Agent能执行的清晰任务这个能力直接决定Agent的产出质量。代码审查能力Agent写得更快意味着你需要review的代码量更大能不能快速看出逻辑漏洞和隐性问题成了核心技能。业务上下文理解Agent不懂业务也不知道这个功能在真实场景里要怎么用只有你懂这是无法外包的壁垒。系统工程思维Agent擅长写局部代码但跨模块交互、数据一致性、故障恢复这层系统级的思考目前仍然是人的主场。4.2 把Agent当成“刚入职的实习工程师”来带这个类比是我在带团队时反复强调的。你对一个新来的实习生是什么管理方式对Agent就该是什么管理方式甚至更严格。实习生你不敢放手是因为你不知道他会捅什么篓子。Agent也一样只是它动作更快、闯祸范围更大。所以你要做三件事第一任务拆得足够细每个任务有明确的验收标准而不是一句“把这个功能实现一下”就丢给它第二给它配好工具和文档仓库里有没有清晰的README、有没有合理的代码目录结构直接决定它能不能找到该改的文件第三设定复查节奏Agent每完成一个阶段你就要检查一次不要等PR出来了再惊觉方向全错了。我个人的习惯是给Agent布置任务时一定会附上三样东西需求背景、验收清单、约束条件。缺一样都不行。需求背景告诉它为什么做验收清单告诉它做到什么程度算完约束条件告诉它哪些事不能做。有了这三个东西Agent的表现会稳定很多。4.3 把Agent生成的PR当成“外部贡献者”来管理Uber这套方案里有一个细节很值得普通团队学习就是给Agent生成的PR打上专属标签把它当外部贡献者的代码来管。这个设计的妙处在于它从流程上就锁定了风险边界。外部的陌生贡献者提交的PR你会自动提高警惕仔细看逻辑、看测试、看有没有安全风险。给Agent生成的PR打上标签等于让所有reviewer在打开PR的瞬间就切换到“审慎模式”而不是因为“这是我们自己的Agent写的”就放松警惕。在团队落地时可以配套几个具体动作给PR标签加颜色让人一眼识别设置至少一名有代码库ownership的工程师review Agent PRAgent PR里的测试覆盖率必须达到团队既定标准如果是核心模块的改动必须有第二个人二次确认。这几条规则听起来简单但在真实运行中能拦住绝大多数翻车事故。5. 我踩过的坑Agent处理PR的典型翻车与排查手记5.1 PR描述很漂亮代码却在摸鱼先说一个我早期印象最深的翻车。有一次Agent提交的PR描述写得那叫一个专业背景、方案、改动点、测试结果列得清清楚楚乍一看是高级工程师的水准。结果我点开diff一看核心逻辑压根没实现只是搭了个空壳测试也是那种“为了跑过而跑过”的假测试。后来我总结出规律大模型天生擅长生成“看起来合理”的文本所以PR描述漂亮不代表代码靠谱。防范的方法是强制要求Agent在PR描述里附上可验证的证据比如关键测试的实际输出、覆盖率报告、构建日志摘要。没有这些硬证据的PR直接打回。但这还不够人一定要拿着diff逐行看确认描述和改动对得上。把“描述漂亮”作为加分项而不是信任依据能避开大量画饼型Agent。5.2 改一行代码顺手改坏了三个文件另一个高频翻车是Agent在完成目标时“路径依赖太强”为了让它觉得代码更合理往往会附带一堆无关的重构和格式调整。你要它修一个边界问题它顺手把整个函数的命名都给你改了diff看起来很大review成本直线上升不说还容易引入隐藏回归。这类问题我排查下来根因通常是两个要么是Agent上下文检索时抓错了相关文件跑偏了要么是prompt里没有加“最小改动”的约束模型偏好生成看起来更完善的代码。解决办法有两层。提示词层面我会在任务描述里明确写“禁止无关重构只修改与目标直接相关的代码”流程层面会加一个diff规模检查步骤当单个PR改动文件数或行数超过设定的阈值时自动提示风险并要求人工确认。这两个手段一起用基本能把“顺手改坏”的概率压到很低。5.3 多个Agent同时提交互相覆盖的“幽灵冲突”当Agent被普及到团队以后会遇到一个人肉时代不太常遇到的问题多个Agent在同一个时间段基于同一个仓库状态做修改提交时互相覆盖。由于Agent的动作频率比人高得多这个问题会被急剧放大。我遇到过最头疼的一次两个Agent被安排到不同任务结果它们同时改了同一个公共模块互相把对方的改动打成冲突最后合入时代码逻辑直接错乱。排查下来我发现根因是Agent的工作流程里少了“前置同步”和“状态可见性”这两个环节。现在我们的做法是涉及公共模块的任务放进同一个队列串行执行Agent开始工作前必须先rebase到最新主干同一时间同一文件最多只有一个Agent在动合并前再强制跑一次全量测试。这套规则看起来笨但实际跑下来冲突率降了八成。5.4 常见问题速查表症状可能原因排查手段PR描述与代码改动不符模型偏好生成合理文本任务理解有偏差强制附带测试输出/覆盖率证据人工比对diffAgent改动范围失控上下文检索不准或缺少最小改动约束在prompt里明确禁止无关重构加diff规模告警多个Agent互相覆盖缺少任务队列和状态同步公共模块串行执行工作前rebase同文件互斥CI一直跑不过本地验证与CI环境不一致Agent在本地使用与CI一致的容器/脚本验证Agent对旧代码理解偏差仓库文档缺失、API用法不清晰完善README和接口注释补充相关索引生成的测试全是假断言提示词里没有测试质量的验收标准要求测试必须含失败路径审查断言有效性5.5 实操心得Agent能帮你写代码但不会替你背锅现在但凡问到要不要引入Agent来写PR我给的建议都是“要但得想清楚边界”。Agent最大的价值不是替你写代码而是把你从重复性劳动里解放出来让你把精力花在更复杂的判断和决策上。但同时你也要明白PR上签的是你的名字线上的故障不会去找Agent只会来找你和你的团队这个责任是Agent替代不了的。所以我个人体会是引入Agent最合适的心理预期不是“我去休息”而是“我换个更高级的活干”。让Agent去跑腿写初稿自己去盯架构、盯质量、盯那些机器判断不了的东西。这样你既不会被工具淘汰还能借着工具跑得更远。最后再分享一个我实测好用的技巧不要让Agent一次性生成一个巨无霸PR而是把大任务拆成几个小PR每个PR只做一件清晰的事每完成一个就合并一个。这样Agent的每一步改动都足够小、足够可控review难度低出错了也好定位回滚了也不心疼。你照这个节奏试一两周会发现Agent交付的PR质量稳定上一个大台阶。
![[数字图像处理]数字图像的有理数倍缩放(缩小与放大)](http://pic.xiahunao.cn/yaotu/[数字图像处理]数字图像的有理数倍缩放(缩小与放大))
