最近我所在的团队发生了一件挺有意思的事早上打开 PR 列表发现十几个 PR 的作者头像都是同一个机器人。代码照常 review、CI 照常跑、合并照常进行。然后我点开一个一千多行的改动扫了一下核心逻辑基本挑不出毛病。说实话那一瞬间我脑子里第一反应不是“这代码行不行”而是“以后我还能干什么”。后来我在技术圈子里也看到了类似的分享——某头部科技公司内部有相当比例的代码 PR 是由 Agent 接管提交的。结合我自己这一年多在 AI 编程工具和 Agent 流程上的实践我越来越确定一件事Agent 真正改变的不是“自动补全”这种小打小闹而是“从需求描述到可合并 PR”的这一整条流水线。这篇东西我打算认真聊一下Agent 到底是什么级别的“写代码”、它凭什么能扛起 70% 的 PR 量、剩下 30% 为什么必须留给人以及如果你想在自己团队里把这条路走通从哪里开始最靠谱。1. “Agent 接管 PR”到底在说什么不是自动生成是自动闭环先说一个最常见的误解。很多人一听“Agent 接管了 70% 的代码 PR”第一反应是“一个机器人直接往仓库里推代码”。如果真这么干任何正经点的工程团队都不敢放它进生产环境。实际上像 Uber 这类公司里 Agent 参与 PR 的方式是端到端地接管一个小型任务的完整开发循环从接收任务描述、定位相关代码、形成改动方案、逐文件实现修改、跑测试、处理报错、到最后提交一个格式规范、描述清晰、可 review 的 PR。整个过程中人只负责两件事给出足够清晰的任务描述以及做最终代码评审。这一点如果不看清楚后面所有讨论都没有意义。因为只有理解了“Agent 完成的是闭环而不是片段”你才会明白为什么它能顶掉 70% 的 PR而不仅仅是一个“高级自动补全工具”。为了更直观一点我拿自己团队的实践来拆解。我们用的 Agent 工作流大概是这样一条链路需求来源一张写得比较规范的 ticket含背景、改动范围、验收标准预处理Agent 拉取最新的目标分支定位相关模块做代码检索和影响面分析实现阶段Agent 自主完成文件修改不是一次生成一大坨而是增量 diff每步可回退自验证阶段跑单测、跑 lint、跑构建报错了自己读日志、改代码、再跑直到通过提交阶段生成 PR标题、描述、测试结果、改动摘要都由 Agent 自己写完人工 review工程师只做逻辑层面的评审而不是帮它改缩进和拼写说句实话这套链路里的每一步拆开看都不是什么“黑科技”。但串起来之后效率和原来的工作方式完全不是一个量级。那“70%”又意味着什么它不是指 70% 的代码行数是 Agent 写的也不是 70% 的 PR 完全没人碰过。更接近的真实含义是团队里大约 70% 的、类型偏向机械和常规的编码任务可以做到“人只负责描述和评审Agent 负责从实现到提交”而整个过程不需要人写一行代码。这个数字之所以能发生核心就在于它切入的是那些重复度高、规则清晰、上下文边界明确的任务——这种任务过去吃掉的是工程师大量的日常时间但它们的复杂度和创造性需求恰恰没有高到必须由人来逐行手写。2. Agent 能“自己写代码”的底气一个建立在工具链上的执行体而不是一个聊天机器人很多人以为 Agent 写代码就是像跟 ChatGPT 聊天一样说一句“帮我写个订单模块”然后哗啦啦出来几十个文件。这是对 Agent 能力边界的严重低估也是高估。真实的 Agent 不是一个聊天窗口而是一个能操作系统、能执行命令、能读文件、能自己查资料、循环迭代的执行体。它生来就不是为了“聊天”而是为了“干活”。我更喜欢用一句话来描述它Agent 是给大模型装上了手和脚让它不再只是“嘴上说说”。2.1 Agent 的真正技术底座模型 记忆 工具调用一个能提交 PR 的 Agent至少包含这几层大模型决策层负责理解任务、拆解步骤、判断下一步动作代码上下文感知层通过检索和索引找到改哪个文件、影响哪些调用方工具执行层调用终端命令、读写文件、跑测试、操作 git而不是光靠模型“脑补”自省和反馈层看测试日志、看 lint 报错把错误信息回灌进模型再生成修补代码你往深了看模型本身只是“大脑”真正让 Agent 达到可用级别的是工具执行层和反馈层。没有这两个层模型生成的代码即便逻辑正确也无法保证和现有代码库的风格、依赖、接口完全对齐更不可能做到跑通测试。2.2 为什么大模型写代码“看着像那么回事”可一跑就废这就是为什么很多人自己用 AI 编程工具觉得“生成的代码质量不稳定”——因为他们只用了模型的单向生成能力而没有给它一个“自己验证自己”的闭环。人写代码写错了会 review、会跑测试、会修 bug。一个没有工具调用能力的裸模型写错了只会再给你生成一个“看起来更正确”的错误代码。Agent 却不一样。它写完代码后是真实地执行测试命令的测试挂了它真的会看到 stack trace然后返回头去改代码再跑一遍。底层逻辑和一个人写代码时的“调试循环”是一样的写代码 → 跑测试 → 看报错 → 改代码 → 再跑。这个循环一旦跑通Agent 的可用性就完全上了一个台阶因为它在交付之前已经替你把低级错误都挡掉了一轮。2.3 工程化接入才是“70%”的关键我在自己团队里做 Agent 落地时一个特别深的感受是模型能力只决定这个 Agent 能干到 60 分还是 70 分而工程化接入决定它是停在 demo 阶段还是能真正每天合并几十个 PR。工程化接入包括什么包括代码索引的实时更新、任务来源和分支策略的对齐、可重复的本地/远程测试环境、PR 描述模板的规范化、CI 状态回传机制……这一大堆东西听起来不酷但没有它们Agent 就是一个个孤岛无法嵌入到团队现有的协作节奏里。3. 从 0 到 70% 的实操路径我是怎么把 Agent 从玩具变成生产力工具的接上个话题光讲原理不够接下来聊聊落地路线。我们团队大概花了小半年时间把 Agent 参与 PR 的比例从 0 推到了差不多一半以上中间踩了不少坑。我把这条路径重新梳理了一遍去掉我们自己绕的弯路总结成四个阶段你可以把它当成一个可参考的实施蓝图。3.1 第一阶段挑对第一批“试验田”任务这个阶段的目的不是追求量大而是积累信任。我们的经验是永远不要一开始就让 Agent 去碰核心业务链路或者架构调整类的任务那相当于让刚拿到驾照的人直接上赛道。真正适合第一批交给 Agent 的任务有几个特征边界明确比如“给某个接口补全参数校验”“把某个模块的报错信息统一成 JSON 格式”有现成的测试基座改动后能通过跑测试来验证有例可循仓库里有大量相似的历史 PR 可以参考我们团队当时挑的是“日志规范统一”和“死代码清理”这一类任务风险极低但涉及的文件数量多非常适合 Agent。这类任务跑顺了几十个大家就会对 Agent 逐渐建立信任。3.2 第二阶段把任务描述从“人话”改造成“机器可执行的规格”这是我觉得目前整个 Agent 开发里最反直觉、也最容易被低估的一环。你以为 Agent 最大的瓶颈是“它写代码写得不够好”不是。我们遇到的最大瓶颈是人描述任务的时候太含糊了。习惯了跟人沟通我们默认对方能理解“把这个接口的报错处理优化一下”这种模糊表述。但 Agent 不会猜它只会根据字面意思去执行。你给它一句模糊的话它就会给你一个“看起来像在干活但很可能跑偏”的结果。后来我们总结出一套“任务规范化”模板现在团队里凡是准备交给 Agent 的 ticket必须包含这几部分背景这段代码现在为什么长这样要解决什么问题改动范围明确是新增、修改还是重构涉及哪些模块/文件至少给个大致方向验收标准哪些测试必须过、哪种行为不允许出现、输出格式是什么反面约束哪些事情不允许做比如不要动公共接口签名、不要连带重构一开始大家觉得写这么细太费劲了但跑了一段时间后发现写清楚 ticket 的人自己反而对需求理解得更透彻了。而且在 Agent 把大部分实现工作接走之后人的精力反而被逼着集中到了真正需要脑子的地方任务的定义、方案的取舍、边界的约束。3.3 第三阶段搭建“局部闭环”的验证环境在 Agent 提交 PR 之前至少要让它先在一个沙盒环境里完成自我验证否则它提交上来的东西大概率被 CI 红灯打回去来回折腾效率反而更低。我们的做法是给 Agent 的准备了一个隔离的执行环境可以是一个容器、一台开发机或者一套可本地复现的测试流水线。Agent 在环境里按顺序执行这些动作拉取目标分支的最新代码按任务描述生成改动 diff执行 lint 和格式化检查跑受影响的单测和集成测试有失败就自己看日志、修复、重新跑循环最多 N 次我们限制是 5 次全部通过了才生成 PR 提交到远端这个“先自测再提交”的环节非常关键。很多 Agent 的早期实现没有这一步提交上来的 PR 三天两头被 CI 打回来reviewer 的耐心都被磨没了。加上这个闭环之后PR 的“一次通过率”提升非常明显大家也就越来越愿意让 Agent 多干点活。3.4 第四阶段钉死 PR 的“描述规范”让 review 成本降下来这点看起来像是细枝末节但实际体验下来对于推广 Agent 写 PR 至关重要。如果 Agent 提交的 PR 描述写得乱七八糟reviewer 看不懂它改了什么、为什么要这么改、测试结果如何那么再好用的工具也会被团队用脚投票淘汰。我们给 Agent 的 PR 模板固定了这几块内容改动概览一句话说清楚做了什么事关联任务对应哪个 ticket关键文件列表每个文件为什么被修改测试验证跑了哪些测试、结果如何、覆盖率有没有变化风险与回滚方案哪些地方需要 review 特别注意一个写得清楚的 PR 描述本身就是对 review 体验的尊重。这套规范和上一步的沙盒验证加起来是我们 Agent PR 合并率能稳定提升的两个隐形功臣。4. 为什么不是 100%Agent 的边界、风险与必须人工把关的环节聊完怎么把比例推上去再来说说那个同样重要的问题为什么到 70% 就差不多了剩下 30% 留给人才是对的不是做不到 90%而是某些东西一旦让 Agent 碰成本和风险可能会反噬你省下的那点时间。4.1 Agent 不擅长“未知边界的探索”Agent 适合在给定路径上走得又稳又快但不太擅长在一片模糊地带里替你做出权衡决策。比如跨模块的大型架构调整、需要和多个团队对齐接口语义的改动、牵一发动全身的重构这类任务里“正确方案”往往不只取决于代码本身还取决于团队约定、历史包袱和未来方向。这些隐性的组织知识Agent 再强也难凭空感知。4.2 Agent 的“错误”可能看起来很合理这类问题是最让我警惕的。Agent 写出来的代码如果错了往往错得很“合理”——从语法到风格完全挑不出毛病但业务逻辑上就是不对。这种错误比明显的手误更难发现因为它要求 reviewer 对业务本身有足够的理解而不能只看代码“好不好看”。所以在这种背景下我对 review 策略的建议非常坚定人只看方案和结果机器只查规则和测试而不是让人逐行替 Agent 做陪跑式的 review。人工 review 的核心是方案是否匹配需求、边界情况是否被遗漏、有没有滥用依赖、改动是否过度。一旦你发现自己在一个 Agent 生成的 PR 里逐行检查缩进和命名那说明你的工具链没配置好——这些本该由格式化和 lint 自动拦住。4.3 哪些类型的改动必须留给人我的分类清单为了让这个判断更可执行我把自己目前实践中的“人和 Agent 分工清单”整理成了表格你可以直接用任务类型适合 Agent原因和说明新增独立模块/接口实现高度适合边界清晰有明确输入输出和测试场景日志/错误处理规范统一高度适合规则明确覆盖面广靠模式和检索就能搞定依赖版本升级无破坏性变更适合改动可控但需要依赖冲突测试来兜底单元测试补齐高度适合有明确目标驱动开发和覆盖逻辑都可以机械化梳理重构大类公共接口变更不适合影响面大需要全局理解和跨团队对齐性能瓶颈定位极不适合需要 profiling 经验和业务权衡Agent 难以自主决策安全/权限相关改动极不适合风险等级高语义边界极重要再省时间也不能让它碰跨团队业务逻辑编排不适合涉及多个系统、隐性约定、长期规划这个表不是死规定不同团队的技术栈和测试基座会改变每个任务的适合度。但总体的原则就是新代码和机械规整交给 Agent架构与风险判断留给人。4.4 “人机对抗”的另一个隐蔽风险团队能力退化最后说一个比较长远的问题。如果 Agent 接管了大部分“从需求到实现”的过程初级工程师从哪里获得写代码的“肌肉记忆”和调试的直觉这个问题在引进 Agent 之前我和团队讨论过很多次。它不会立刻暴露但过个一年半载你可能会发现团队里很多新人写不了超过 50 行的独立函数——他们太习惯于让 Agent 代劳、自己只做 review 了。所以我们现在有意识地保留一部分任务不给 Agent专门留给新人做“刻意练习”。不是反技术是反“无意识依赖”。这一点不知道对别人有没有用但至少在我们团队里已经成了一个默认的轮换机制。5. 人在新协作模式里的角色升级从手写代码到定义问题回到开头那个让我脊背发凉的问题“以后我还能干什么”这段时间想下来我的答案变了不是“我还能干什么”而是“我需要会干的事情变了”。70% 的 PR 由 Agent 接管之后工程师的核心技能正在从“把方案写出来”往前移——移到了“把问题定义清楚”上。一个很直观的现象是我们团队现在对 ticket 的要求比以前严苛了一个数量级。过去一个 ticket 写个标题加三行描述开发会自己去脑补细节。现在不行了因为读 ticket 的不只有人还有 Agent。你写得越模糊Agent 跑偏得越远返工成本远超你自己多花十分钟把边界写清楚。所以在我看来未来的工程师日常会慢慢变成这样花更多时间去理解和拆解业务需求去跟产品经理对齐细节把拆解结果写成 Agent 能执行的规格说明在 Agent 完成初稿后做高质量的方案级 review处理 Agent 搞不定的极端场景和跨模块整合说白了工程师的产出物从“代码”变成了“定义”和“判断”。代码量反而可能没那么重要了。这个过程对老工程师更友好——因为经验和判断力恰好是时间熬出来的东西对新人更苛刻——因为靠刷代码量往上爬的路会越来越窄。另外聊一个很多团队都会关心的实际问题引入 Agent 之后产出怎么衡量以前大家用 commit 数量、代码行数、PR 数量来衡量开发产出。Agent 大量参与之后这些传统指标基本失效了——Agent 一小时能提交的 PR 比人一个月都多但你不能说这个工程师一个月的产出快顶上一百个人。我们现在更倾向用这几个指标来评估成功合并率Agent 提交的 PR 有多少最终被合并返工率一个 PR 平均回退/修改几轮review 时长每个 PR 花在人工评审上的时间缺陷逃逸率上线后有没有引入线上问题这些指标更接近“工程质量”而不是“生产数量”它们也反过来驱动我们持续去优化 Agent 的训练/提示词/流程。6. 想在自己团队里做 Agent 落地给你几条我踩过坑后的实在建议这部分与其说是方法论不如说是避坑指南。我自己从 0 到现在跑通这条链路绕了不少弯路有些弯路完全是“我以为”和“实际上”之间的差距。6.1 先从“已存在的仓库模式”里抄作业不要一上来就上新技术栈Agent 在陌生代码库里生成代码跟一个新人入职第一天被丢进老项目是一模一样的最大的障碍不是不会写代码而是“不知道这个项目里有哪些约定俗成的东西”。比如这个团队是喜欢函数式风格还是面向对象错误处理是返回 error code 还是抛异常命名是 snake_case 还是 camelCase仓库里已有的注释风格、logger 的用法、异常类型的选择……这些都是大模型的“隐形知识盲区”。所以我的建议是在 Agent 开始的阶段尽量从代码库里提取足够多的“模式示例”喂给它或者让它先检索一个最相似的历史 PR 作为参考。甚至可以人为在需求描述里直接塞一两个类似文件的路径让 Agent 照着写——效果立竿见影。6.2 测试基座就是你 Agent 的天花板这一点再怎么强调都不为过。你有一个能快速、稳定运行的测试套件Agent 的成功率就高你没有测试或者测试跑起来要半小时且经常 flaky那 Agent 就是在裸奔。我们团队的经验在引入 Agent 的早期先花时间把 CI 的稳定性和速度解决好。不是追求 100% 覆盖率而是追求“在 Agent 改动影响范围内有能快速反馈的测试”。哪怕只有几个关键路径的集成测试也比一个测试都没有强很多。6.3 质检和策略要前置到“Agent 执行之前”而不是事后补救我们一开始犯最大的错误就是让 Agent 直接产出 PR再由人来 code review。看起来流程没毛病但实际问题很大——Agent 会用自己的“自信文风”把所有问题包装得很合理reviewer 如果没有特别警惕很容易就放过去了。后来我们把流程改成“策略前置”在 Agent 开始执行之前就把这几点规则注入到它的约束里不许修改与任务无关的代码不引入新的第三方依赖除非任务里明确要求不改动公共 API 签名逻辑复杂度有限制超过阈值的函数要拆解所有新增代码必须有对应测试这些约束写在 Agent 的系统提示词里配合工具层面的拦截比如 git diff 检查比事后 review 再来找问题高效得多。6.4 人性化预期管理团队里的接受度要靠“让大家更轻松”来建立最后这点也算是我个人的一个观察吧。Agent 落地最大的阻力往往不来自技术而来自团队的情绪。大家天然会担心“我的活是不是要被抢了”。但真正跑起来之后大多数人会很快感受到Agent 接走的不是“我的核心价值”而是“我本来就烦的那些琐碎活”。所以在推行过程中我的建议是别急着喊口号、定指标先把几个体验最好的用例做出来让大家亲眼看到 Agent 把一个平时要两小时的改日志任务的 PR 在十分钟内提交上来而且测试全绿。用结果说话比推任何制度都管用。写到最后的一些个人体会从这一路实践里我自己收获最大的一点其实不是“学会了怎么用 Agent 写代码”而是对“软件开发里什么东西最值钱”有了新的理解。以前我觉得写代码是最核心的能力现在我觉得定义任务、做出取舍、守住质量边界才是更不可替代的部分。Agent 把执行层变得极其廉价之后判断力反而成了稀缺品。如果你所在的团队还没有开始尝试我建议不妨找一两个低风险的模块先试点起来。不需要一上来就上一整套复杂的框架哪怕只是在 CI 里加一个“由 Agent 自动生成 PR”的 workflow先跑通一个最简单的闭环你就能感受到这条路到底值不值得继续深入。真正走过一遍之后你会发现回到没有 Agent 的工作方式就像习惯了自动驾驶辅助之后再去开一辆没有任何助力的老车——能开但总觉得哪里不得劲。