先说背景。Uber 工程效能团队最近公开了一个内部数据：在部分服务上，AI Agent 已经接管了 70% 左右的代码 PR 流程，工程师不再需要逐行点开 diff 去检查小改动，而是由 Agent 完成从“提交 PR 到自动修复、再评审、再合入”的大部分环节，人力只在关键节点做兜底决策。
这个数字出来之后，很多团队的第一个反应是“这玩意儿是不是就是个高级的静态检查机器人”，第二个反应是“70% 的PR都被接管了，那工程师是不是要失业了”。这两个反应其实都跑偏了。作为一个在研发效能工具链上折腾过几年的老兵，我拿到这个信息的第一反应不是焦虑，而是想知道一件事：Uber 到底是怎么设计这套 Agent 的工作边界和评测标准的，为什么它能放心让 Agent 去动 PR 流程，而不怕它把主干分支搞得一团糟。
这篇就围绕“Agent 接管 PR 流程”这件事，从架构设计、任务拆解、评测方法、踩坑经验几个维度拆一拆。不保证猜中 Uber 的每一个内部细节，但基于对 PR 评审链路和 Agent 落地模式的了解，这套拆解思路是通用可复用的。无论你是在做 AI 编程助手，还是想给自己的项目接入一个能自动处理简单 PR 的机器人，这篇都应该能给你一些实际参考。
1. Agent 从“辅助写代码”到“接管 PR 流程”，这一步到底跨了什么
先说一个经常被低估的事实：让 AI 辅助写代码，和让 AI 独立处理 PR 流程，完全不是一个量级的技术挑战。
写代码这件事，输出的产物是代码 diff，判断标准是“编译能不能过”“测试跑不跑得通”，Agent 写完代码之后，人还会做最后一道把关。就算 Agent 给出的代码有瑕疵，人在合入前会看到、会修改，最坏的情况也就是删掉重写，损失的是一个小时的人工时间。
但 PR 流程不一样。PR 不只是一段代码，它是一整套协作契约。一个 PR 里有 commit 规范、有 diff 内容、有 CI 状态、有评审意见、有合入条件、有分支策略，甚至还有跨团队的责任边界。Agent 要接管 PR 流程，意味着它必须在这些约束条件之间做权衡，而这些权衡本身就需要对业务上下文有理解。
过去一年里，我见过不少团队在“AI 自动修代码”上跑得挺顺，一到“AI 自动处理 PR 流程”就翻车，原因基本都出在同一个地方：把 PR 流程理解成了“代码的搬运工”。
以典型的小型 PR 为例，一次依赖升级或者配置项调整，代码量可能只有几行，但它的合入链路却牵扯一大堆问题：
- 这次升级会不会影响其他模块的兼容性？
- 配置项改动是否需要同步更新文档或线上告警？
- 这个 PR 对应的 issue 是否还处于 open 状态？
- 需不需要指定特定 reviewer 或者加自定义标签？
- 分支是基于最新的主干拉的吗？会不会有冲突？
这些问题，任何一个环节没处理好，AI 自动化合入的后果都比“人工忘记处理一个 PR”严重得多。轻则影响测试环境稳定性，重则引发线上事故，尤其在高并发、强实时的业务系统里，一个看似无害的配置项变化都有可能被放大成事故。
Uber 这套 Agent 之所以能做到 70% 的接管率，关键在于它不是把 PR 流程当成一组 if-else 规则，而是把“工程师处理 PR 的思维过程”整体拆解成 Agent 能理解和执行的工作流。这背后其实是一个很深刻的转变：从“AI 辅助人做决策”变成“AI 在受限环境下替代人执行决策”。
那这个受限环境是怎么设计的，决定了 Agent 的接管边界和风险等级，这才是我们需要重点拆解的维度。
2. 解构 Uber 这个 Agent 系统的四层技术架构
要把 PR 流程完整拆给 Agent 做，需要一套清晰的架构设计。综合现有公开信息和同类系统的通用做法，我整理出的 Uber Agent 技术架构大致可以拆为四层。每层负责一组能力，层与层之间通过标准的接口交互，这样既方便独立升级，也方便在某一层出问题时做熔断降级。
2.1 感知层：不仅仅是读 diff，而是理解 PR 全生命周期
感知层是所有上层决策的基础。传统自动化工具对 PR 的理解往往停留在“读取文件变更内容”和“检查是否有合并冲突”这两个层面。但 Agent 要替代人做决策，就需要感知更丰富的信号。
这一层有一个关键点：PR 不是一个静态的快照，而是一个动态的生命周期对象。从创建、提交、评审、修改、合并，到合入后可能出现的回滚，每个阶段的状态不同，Agent 采取的应对策略也应该不同。
所以感知层的设计，不只是拉取一次 MR 的 diff 内容，而是要在整个 PR 生命周期内持续追踪状态变化，收集多维信号：commit 历史、构建状态、评审意见、指派人变化、标签变更，甚至包括评论里的语气信号。举一个我在实践中踩过的坑：很多团队做 Agent 时，只让 Agent 读取“当前最新代码”的 diff，结果 Agent 不知道这个 PR 之前被 review 过一轮、被要求改过某些文件，于是重复提了一模一样的评论，搞得开发者心态爆炸。后来改为“全量对话历史 + 变更序列”作为感知输入，效果立刻改善。
2.2 决策层：从代码分析到语义理解的层次转换
感知层解决了“看到什么”的问题，决策层解决的是“怎么判断”的问题，这是整个系统里最容易低估难度的一层。
纯粹基于规则的代码分析工具每一次升级只能增加若干条规则，但 Agent 出现后最大的不同，是能把“语义理解”注入到决策过程里。比如，Agent 可以识别出“这个 PR 修改了用户鉴权模块中 session 的生成参数，而且没有同步修改对应的 token 失效策略，可能导致用户被强制登出”，这种因果关系推断，传统静态分析工具很难做到。
从实现角度来看，决策层大致包含三个并行的判断线路：
- 基于代码结构的判断：分析变更文件之间的关系、依赖方向、圈复杂度变化值、新增函数调用链的完整性。
- 基于语义的判断：结合仓库上下文和注释信息，判断这次改动的意图是否清晰且与描述一致，自动生成评审建议。
- 基于行为序列的判断：综合 PR 创建人的历史习惯、该模块的变更频率、reviewer 历史反馈偏好，预测这个 PR 被合入后可能产生的风险值。
这三个线路的输出又会汇入一个由人设定的“风险决策矩阵”。矩阵中规定了什么类型的 PR 属于“低风险，可自动合入”，什么类型的属于“高风险，必须由人来评审裁决”。风险决策矩阵的规则是动态调整的，类似 U 项和部分经验团队的 A/B 实验机制，规则也不是拍脑袋定的，而是拿历史上的 PR 数据去回测校准出来的。
2.3 执行层：Code Review 和 CI 修正的双引擎驱动
决策层给出判断之后，就到了执行层。这个层面，Uber 的方案中有两条重要的执行路径：一类是轻量级修正，直接对代码进行局部修改后提交到同一个 PR 分支；另一类是重型修改，需要在本地或云端构建完整环境才能验证改动是否正确，比如口令加密库版本更换涉及大量文档注释、单元测试样例的变化，这些改动更多由独立 Agent 并行处理。
- 直接修改引擎（代码 Agent）：直接作用于 PR 分支，修改代码并提交 commit，触发新一轮 CI 检查。
- 代码评审助手（评审 Agent）：生成结构化的评审意见并发布到对应的 PR 讨论区，等待开发者反馈。
这两个引擎不是同时启动的，而是根据决策层输出的风险等级进行串联的。低风险 PR 走“直接修改 → 自动重新验证 → 自动合入”的路径；中风险走“评审助手先评论 → 开发者确认或调整 → 重新验证”的路径；高风险则是直接抛回给人，Agent 只做信息汇总和辅助分析，不自动执行任何改动。
2.4 反馈层：每一次合入都是下一次更好的判断
如果系统只做到第三层，那它只是一个高级的自动化流水线，而不是“Agent”。Agent 和自动化工具的本质区别在于，Agent 应该能从每次操作的结果中学习，不断调整自己的判断策略，形成完整的闭环系统。
反馈层要处理的数据不仅仅是“CI 通过”或“测试失败”这种二进制结果，还包括更复杂的软信号：代码评审者的意见是否被采纳、被修改过的代码在合入后是否引发新的缺陷、某类自动修改在线上运行时是否出现性能退化。这些信号会被收集并各自记录到元数据存储中，形成一组决策样本，用于后续对 Agent 的策略优化和算法模型迭代。
就当前观察到的业界实践和社区反馈来看，能让反馈信号有效转化为决策优化的，不是简单地拿人工评审结果当标准答案做监督学习，而是要设计评测指标，理解哪些信号指向成功的结果，哪些信号指向潜在风险。这一点已经成为一个独立的重点方向，值得单独展开讨论。
3. Agent 如何接管 PR 流程：一条从提交到合入的五级流水线
讲完架构，我们落到具体的流程上。Agent 接管 PR 不是一下子从零走到 70% 的接管率，而是分五级渐进实现的，这一点很重要，很多团队一上来就追求全面接管，结果根本控制不住风险。
我把这五级流水线的完整链路展开说明一下，顺便把每一级最容易出错的地方标出来。
3.1 第一级：提交预检——在开发者的电脑上就拦截问题
Agent 的第一道防线不是在 CI 里，而是在开发者本地提交之前。通过 pre-commit 钩子或在 IDE 插件中嵌入轻量 Agent，扫描当前分支的变更内容，检查是否有密钥硬编码、明显的外部接口调用、无用日志残留、格式风格不一致等问题。
这个阶段的核心目标是减少低质量提交出现在远端分支上的概率。以 Uber 的实践来看，这一级能拦截掉大量无意义的提交，但不是阻断式拦截，而是以建议式反馈为主，AI 生成推荐补丁，开发者一键应用或忽略。这套模式的妙处在于：Agent 没有剥夺开发者的控制权，而是通过降低修正成本来引导更好的提交习惯。
实际操作中我的体会是，这一级要想跑得好，关键在于本地 Agent 必须足够轻量，响应时间不能超过几十毫秒，否则开发者会产生明显的感知延迟，用不了两天就会想办法禁掉这个钩子。
3.2 第二级：PR 创建后的智能补全——自动补全描述、标签和 reviewer
很多团队潜意识里忽略了一个事实：PR 流程中的大部分元数据，如描述、标签、指派人，长期以来依赖开发者的自觉填写。而大量低质量 PR 的根因，正是描述不清楚，导致 reviewer 根本不知道改动意图，评审效率极低。
Agent 在这一级做的事情是：读取 diff 内容和 commit message，自动生成结构化 PR 描述、根据仓库 CODEOWNERS 自动推荐 reviewer、智能打标签，甚至可以为不同类别 PR 自动生成测试说明模板。
这一级的技术壁垒不在“能不能生成”，而在“生成完怎么避免误导”。我见过不少 AI 生成的 PR 描述和实际代码改动牛头不对马嘴，如果此时系统又把描述自动发到团队 IM 群里，这个误导就会被放大，比不写描述更糟。实操建议是：所有 Agent 生成的文本类内容，状态一律标记为“AI 生成，待确认”，并且不主动推送大范围通知，只提醒 PR 作者本人来确认修改。
3.3 第三级：自动检查与一级评审——把机械性校验从人手里接过来
这是 Tier 1 的实现核心，也是 Agent 接管率提升最明显的一级。Agent 在 PR Opened 事件触发后，自动执行多维度编译、单测、静态检查、依赖安全性扫描等动作，并基于决策矩阵判断这套检查结果是否满足自动合入门槛。
值得注意的是，Agent 在这里做的不只是运行已有检查项，它还会根据代码内容动态补充检查逻辑——例如发现 PR 改动了 Dockerfile，就自动检查镜像层缓存策略和基础镜像标签是否可复现；发现 PR 修改了数据库查询逻辑，就自动拉取慢查询日志模板，检查新增查询是否可能引发慢 SQL 风险。
第三级的自动化覆盖场景包括仅修改注释、README 等文档型变更的 PR，纯依赖版本号变更且伴随说明的 PR，配置文件中与可枚举合法值对应修改的 PR 等。这类 PR 的共同特征是：改动范围明确、修改类型简单、不涉及复杂业务逻辑变化。
这一级要特别注意一个坑：Agent 对文档改动的判断，比较容易走向“只改注释、跳过测试”的极端。经验做法是，即使是纯文档修改，也要强制走一遍“构建产物是否受影响”的检查。因为在某些 monorepo 结构里，文档路径和构建配置存在隐式绑定，注释改动也可能触发构建失败，跳过检查反而制造隐患。
3.4 第四级：基于代码评审意见的迭代修改——让 Agent 成为会改稿的协作者
到了这一级，Agent 已经不再是简单的“检查员”，而是一个“会修改代码的协作者”。它可以根据评审意见自动迭代代码，然后通过直推或者新建分支的方式更新到 PR 中。
实现原理并不高深，以“评审意见 → 代码修改”为核心做 diff 级别的 instruction tuning，模型输入为具体评审会话记录或针对指定行号的评论列表，输出为更新后的目标文件版本。关键是采用“建议级别”的动作来避免过度修改：Agent 不直接替开发者做“大设计”决策，而只处理明确、局部、可验证的修改请求。
比如，评审意见是“这个函数缺少参数合法性校验”，Agent 可以自动加上输入检查并补充对应单元测试。但若评审意见是“这个模块的整体抽象需要调整”，Agent 只做分析和列出方案，最终由人来动刀。
这一级的难点在于，模型要识别出“评审意见针对的代码块”并精确定位到当前文件版本，因为评审意见往往是针对上一个 commit 的代码行，而开发者在收到意见前可能已经改了其他部分，直接按原始权重覆盖会产生冲突。更稳的做法是：把评审意见和当前最新版文件之间做一层“版本对齐”处理，定位到最新版中对应的语义位置再做修改，而这个定位操作可以由大模型自动完成。
3.5 第五级：自动合入与监控——合入不是终点，而是新循环的起点
第五级是“自动合入”，前提是以下条件全部满足：
- 所有自动检查项通过
- 强制评审中针对严重问题的评论均已被处理
- CI 最新状态为通过
- 目标分支保护规则允许机器人账号合入
- 合入风险等级低于预设安全阈值
但合入完成后，Agent 的职责并未结束。它会为该 PR 创建一个独立的任务监控循环，在一到两周内持续跟踪目标代码段的相关指标：变更是否引起回滚、是否触发新的 issue 引用、是否导致性能监控图出现异常点、相关告警数量是否显著增多。这层“合入后的监控闭环”相较传统工程实践有多重增益，既能帮助算法团队及时发现模型判断失误，也能找出容易出问题的语义特征，形成正向反馈。
有了这套五级流水线，再回看 Uber 的 70% 接管率，你就明白它不是一夜之间做到的，而是逐步放权、逐级验证后形成的结果。不同级别的 Agent 在不同团队、不同代码库的配比会有较大差异，这种渐进式策略正是这套系统的核心安全机制。
4. 衡量 Agent 效果的五个关键指标——从“能跑”到“能放心用”
很多团队做 Agent 的时候，最后卡住的不是技术实现，而是不知道该怎么验证 Agent 到底做得行不行。凭感觉拍板说“效果不错”和“效果不行”都很危险，因为直觉在复杂系统面前非常不可靠。这里我给出五个经过实践验证的关键指标，各有侧重，不要只看其中任何一个而忽略其他维度。
4.1 接管率（Adoption Rate）：最直观但最容易被误导的指标
接管率，即 Agent 自动完成变更率，是最常被引用的指标，也是理解“70% PR”这样的数据时首先要关注的数字。它的计算口径是：过去一段时间内 Agent 自动创建修改流程占全部人工流程的比例。
但我建议所有团队在关注这个指标时留一个心眼：接管率高不代表 Agent 做得好，只能代表它在某些任务上跑通了流程。如果安全阈值设置过低，或者为了追求接管率而压低评审标准，那最终收获的只会是一堆合入后疯狂返工的问题单，接管率瞬间就会被打回原形。
我的实操经验是，接管率要拆开看：
- 轻量 PR（文档、配置、依赖）的接管率，这个指标可以且应该争取做到 70% 以上。
- 业务代码 PR 的接管率，这里要谨慎得多，一开始定在 10%~20% 是比较合理的目标。
- 架构级 PR 的接管率，这种类型从一开始就不应该追求自动化，Agent 只做辅助分析。
4.2 返工率（Rework Rate）：避免出现“看似做到了，实际全是返工”的假象
返工率是衡量产出质量的远期指标，具体定义为：Agent 合入过的代码，在后续两周内被人工回滚或修正的有效比例。
为什么这个指标重要？因为很多 Agent 的隐性错误不会在合入时暴露。比如 Agent 自动修改的代码虽然通过了单测和静态检查，但设计上违背了模块间的依赖方向，未来一个月内会持续引发各种连带问题。但这些问题的代码在合入时评测试无可挑剔，如果只看上线时的指标，系统很容易被假象欺骗。
返工率低于 5% 是一个相对健康的水平。如果超过 10%，说明决策矩阵的规则设置和实际需求有较大偏差，需要及时回归调整，而不是继续盲目扩大自动接管范围。
4.3 人工介入率（Human Intervention Rate）：衡量 Agent 的自主能力是否真实达标
人工介入率指在某一个 PR 的完整生命周期里，是否有人工操作参与的统计概率。这个指标的细节口径需要注意，因为统计维度不同，数字差异很大。
如果用“是否有人工操作参与过 PR 生命周期”作为口径，只要有人动过一次就是 100% 介入；如果统计“完全端到端无需人工”的比例，那数字会低得多，Uber 的 70% 数据可能更接近这个口径。
我更推荐使用“按流程节点统计的人工介入率”，也就是分别统计提交预检、PR 创建、自动评审、迭代修改、合入决策这几个节点中“需要人力干预的比例”。这样不仅能看出 Agent 的整体表现，还能定位到具体是哪个环节最需要人力兜底，方便做针对性优化。
4.4 评审通过率与合入后缺陷逃逸率：衡量判断质量的双面结构
评审通过率衡量的是 Agent 对代码质量的把关能力，反映模型筛选和标记异常区域的综合准确率与召回率。合入后缺陷逃逸率则更直接，指的是 Agent 认可的自动合入操作，在线上引发严重缺陷的概率。
这两个指标和人工评审的基准线之间的对比非常有价值。如果 Agent 的缺陷逃逸率接近甚至低于资深工程师手动评审的批次水平，那就说明 Agent 在特定场景中确实具备了替代人做评审的能力依据，主管和技术委员会也更容易接受更大范围的接管。
我通常建议按严重级别分别统计：P0 级逃逸率必须为零；P1（功能异常，可快速恢复）级别应低于 0.5%；P2 级及以下的缺陷可以积累分析，但也要保持在上线前测试团队和历史人工评审结果的对比基线以下。
4.5 反馈闭环效率（Feedback Loop Velocity）：Agent 能否从经验中自我进化
最后一个指标关注的是 Agent 的自我进化能力，也就是从线上问题发生到策略更新生效的周期。具体衡量维度包括：每次人工纠错后，Agent 策略更新的平均时间周期；每次线上新问题类型出现后，识别并沉淀为新的检查规则所需的事件数量；策略更新后，同类问题的复发率是否显著下降。
这类指标表面看起来不如接管率或返工率“硬核”，但它恰恰是区分“高级自动化工具”和“Agent”的关键。自动化工具的运行逻辑是一成不变的，而 Agent 的核心优势在于持续学习、动态优化、经验抽象能力。如果一个 Agent 系统上线三个月后，决策策略和三个月前完全没任何差异，那它本质上是披着 Agent 皮的老工具，当面对新问题、新场景时会迅速流露出脆弱性。
5. 落地时最容易被忽略的三个技术细节——基于踩坑经验的总结
前面讲的是架构和指标，属于“从零到一”的框架。但在真正落地过程中，有几个更细的技术点，通常不会出现在官方文档和分享材料里，却往往决定了项目整体项目的成败。这些点不处理好，Agent 的表现回时好时差，且很难定位根因。
5.1 PR 里的“历史包袱”怎么处理：评审 Agent 的性能策略要按文件的审视维度分开设计
第一个细节是 PR 里老文件和新增文件的处理策略差异。
一个常见的场景是：一个代码仓库里有大量历史遗留文件，风格很混乱，同时存在复杂逻辑和明显设计缺陷。当某个 PR 修改到这个老文件时，Agent 很容易把历史问题当成新问题提出来，导致评审意见被开发者无视，甚至引发争执，因为开发者可能只是顺带修改了一行内容，并不需要对这个文件的历史债务负责。
正确的做法是，在 Agent 的评审指令里明确区分“本 PR 变更行”和“文件上下文行”。Agent 只对本 PR 新增或修改的行提出高强度评审意见，对未被修改的行，即使发现问题，也只以低优先级备注形式呈现，并明确标注“存量问题，非本 PR 引入，建议后续独立处理”。这样，Agent 的评审建议才能符合工程师之间协作的基本心理预期，开发者也不会因为被无差别挑剔而反感自动评审。
5.2 “AI 幻觉”的验证怎么做：自动修改必须绑定可自动验证的测试边界
第二个细节，也是最核心的安全底线：Agent 自动修改的代码，必须绑定可自动验证的验证手段，如单元测试、构建和静态检查，如果没有可行的自动验证方案，就直接禁止自动修改。
这个约束听起来简单，实际操作中经常被突破。比如 Agent 自动修改了某个函数的参数校验逻辑，但该函数所在的模块单元测试覆盖率很低，没有现成的测试能覆盖到这个改动，这时 Agent 可能会“智能”地跳过验证直接提交，这就是幻觉的高发时刻，AI 会含糊地补上一个看似合理的修改，实际运行起来可能是错的。
更危险的是 Agent 为了解决某个测试失败，不会去修改正确逻辑，而是反过来修改测试预期结果，造成“测试和代码同谋”效应，让检查全绿，实际上功能全崩。这是 AI 编程助手中相当常见且隐蔽的失败场景，必须在系统层面禁止，Agent 只能修改目标源码和新增测试用例来适配预期行为，不直接修改既有测试断言内容，除非额外获得人工授权的修改。
完整限定下，将“自动验证失败时的修改权限范围”明确为：只允许修改第一个测试失败点对应的目标源码，如果多个测试同时失败，且修正一个之后导致其他测试失败模式变化，则停止自动修改，将完整调用链打包后移交给人工处理。
5.3 不要让 Agent 成为合入的规则破坏者：强制评审接口的一致性返回要求
第三个细节容易被忽略的问题在分支保护机制上。很多团队的分支保护规则是“要求 PR 至少一个评审通过才能合入”，这套规则下，Agent 可以给自己并不完善的改动打上通过标记，此时再走自动合入，相当于自审自批，风险很大。
更符合规范的做法是：Agent 的评审结果与人工评审结果分为两个不同的接口信号，例如“AI-REVIEW-APPROVED”和“HUMAN-APPROVED”，而不是共用一个评审接口。细化为：Agent 的自动合入仅适用于经过人工预设的高置信度场景，一旦代码改动超过某个复杂度阈值或涉及敏感模块，Agent 的评审状态会自动降级为“需人工复核”。
这套理念和汽车行业的自动驾驶分级逻辑也是一致的，L3 之前叫辅助驾驶，L4 开始才允许在特定场景下完全脱离人工，而 L4 的前提条件是系统能识别出自己的能力边界。Agent 处理 PR 也是如此，最好的 Agent 不是能力最强的 Agent，而是最清楚自己能力边界的 Agent。明确的接口隔离，是实现边界感知的必要条件。
6. 未来三年 Agent 接管 PR 的演进路径与工程团队的角色变化
70% 这个数字不会是一个终点，随着 Agent 模型能力的持续提升和工程平台基础设施的完善，这个比例在很多通用业务代码场景下会继续上升。但本质上，接下来三年会更明显地看到三个趋势，理解这些趋势，才能真正理解 Agent 接管 PR 这件事对工程组织的深远影响。
6.1 从“接管常见场景”到“接管复杂场景”
当前 Agent 解决得最顺手的是短路径任务，即问题定位、修改方案、验证回归、合入上线这条链路中的信息传递损耗很少的任务，比如配置升级、依赖更新、API 迁移。这类任务的核心特征是目标明确、输出可验证、上下文边界清晰。
但接下来的演进方向，一定会走向长路径任务，即跨模块重构、性能调优、架构迁移这类需要多轮探索和时间跨度较长的任务。这类任务中，Agent 不再只是在 PR 级别做修改，而是在任务级别持续跟踪，理解多个 PR 之间的关联性，并主动维护一个“任务状态空间”来指导后续的代码变更。这意味着 Agent 需要具备更强的规划能力和长程记忆能力，而不仅仅是一个针对单个 PR 生成修改的模型。
6.2 从“单 Agent 执行”到“多 Agent 协作”
目前的 PR Agent 很大程度还是一个单体式结构，未来会出现更明显的多 Agent 分工协作模式：
- 代码编写 Agent，负责生成主逻辑。
- Code Review Agent，负责独立审视代码编写 Agent 的产出。
- 测试生成 Agent，负责补齐测试用例。
- 安全审计 Agent，负责扫描安全漏洞和合规风险。
- 文档更新 Agent，负责同步维护技术资料。
关键是，这些独立 Agent 不能在同一个上下文中运行，每个 Agent 在不同上下文空间独立工作、各取所需，只在特定的消息通道中交换结论，避免某个 Agent 的错误判断被其他 Agent 无条件复用。多 Agent 协作带来的不仅仅是能力增强，还带来了更深层的安全机制底色：意见交叉验证，一场思维实验，用不同角度审视同一个问题，在交叉验证中降低单点幻觉风险。
6.3 工程团队的角色变化：从“写代码的人”到“定义评价标准的人”
这是最值得讨论的一个变化。当 Agent 能处理大部分执行层面的 PR 修改任务时，工程师的核心价值会更多转移到评判与审核角色上：这是一次“对的事”，还是一次“错的事”？Agent 的方案是否满足长远设计约束？这个架构选择在三年的演进周期里是否依然合理？
接下来的工程师，最强的能力不是写出性能系数最优的代码，而是能给出清晰、可验证的标准和目标空间，然后让 Agent 在标准空间内高效执行。这类工程师通常具备极强的系统性思维和高维抽象能力，也有很高的沟通与表达标准。当“写代码”的门槛因为 AI 而降低，定义“什么值得写”的能力反而会成为更稀缺的核心资产。
本位和自动化的边界也会在未来三年持续争辩。但有一点是明确的：Agent 接管 PR 流程，不是为了消灭工程团队，而是把重复的、机械的、低创造性的协作工作，从工程团队面前移走。工程团队里每个人真正需要面对的，只剩那些需要人类知识、判断和责任感的问题，这些问题往往更复杂，但正好也是更有价值的部分。
回头再看 Uber 这个 70% 的数据，它更像是一个信号：“能自动化的工作已经步入被接管的路上了”。对于工程师个人，与其纠结 Agent 会不会抢走工作，不如尽早实践 Agent 的使用方法论，把精力投向真正没法被自动化的领域：定义问题、设计边界、评估方案、承担责任。这既是未来工程师的生存之道，也是一个高效 Agent 系统的基石所在。
