Uber 70% PR 已与 AI Agent 关联

Uber 内部数据显示，AI Agent 已关联超过 70% 的 Pull Request，日执行量突破 3 万次。这一数字直接反映出 Agent 在实际工程流程中的渗透规模。过去开发者需要手动创建、审查和合并的代码变更，现在大部分都由 Agent 自动触发或参与完成。

具体来看，70% 的关联比例意味着在 Uber 的代码仓库中，绝大多数变更请求都至少经过一次 Agent 的处理。日执行量超过 3 万次则表明系统每天要处理海量的自动化任务，包括生成补丁、运行检查和提出修改建议。这些数据来自 Uber 自己的工程博客，显示出 Agent 已经不是实验性工具，而是生产环境中的主力。

这一规模的落地并非一夜之间实现。Uber 构建了名为 AI 软件工厂的内部平台，将大模型与现有 CI/CD 管道深度集成。Agent 可以直接读取代码库、理解上下文，并根据预设规则或学习到的模式执行操作。结果是 PR 处理速度大幅提升，开发者不再需要为每个小变更都亲自动手。

从实际效果看，这种高渗透率让 Uber 的代码迭代周期明显缩短。以前可能需要几天才能合并的变更，现在 Agent 可以在几小时内完成大部分准备工作。当然，70% 的数字也意味着仍有约 30% 的 PR 完全由人工主导，通常是涉及核心架构或高风险变更的部分。这也说明 Uber 目前仍在保留人工最终决策的机制。

整体而言，这一数据标志着软件工程进入了一个新阶段：AI 不再只是辅助补全代码，而是开始系统性地接管重复性劳动。Uber 的实践为行业提供了可量化的基准，证明 Agent 在大型代码库中能够稳定运行并承担主要工作量。

请求量增 9.4 倍但 AI 成本几乎持平

Uber 报告显示，在 Agent 大规模应用后，AI 相关请求量增长了 9.4 倍，但整体成本几乎没有上升。这一结果与很多人对大模型推理成本的预期完全相反，背后依赖于特定的技术架构和优化手段。

首先是模型选择和路由策略。Uber 很可能采用了混合模型方案：对简单任务使用轻量级、小参数的专用模型，只有复杂场景才调用大模型。这样大部分请求消耗的算力远低于直接调用 GPT-4 类模型的水平。其次是缓存和重用机制。许多代码审查和测试生成任务具有重复性，Uber 可能建立了向量数据库或相似性匹配系统，让相同或相似的请求直接复用之前的推理结果，避免重复计算。

另一个关键是批量处理和异步执行。3 万次的日执行量如果全部实时同步调用，成本会急剧上升。但通过将多个相关任务打包、错峰执行，以及利用内部 GPU 集群的闲置容量，Uber 把边际成本控制在很低水平。信号中明确提到成本几乎持平，说明他们在推理优化上投入了大量工程努力。

此外，Uber 可能对 Prompt 进行了极致精简，并使用微调后的领域特定模型。这些模型在代码相关任务上准确率高，同时 token 消耗显著低于通用模型。9.4 倍的请求增长如果对应的是以前人工完成的劳动，现在转为机器执行，反而把人力成本转移到了算力上，但通过上述优化，算力支出没有同步暴涨。

这一事实对行业具有重要参考价值。它证明只要在架构上做足功夫，大规模部署 AI Agent 并不必然带来成本爆炸。Uber 的经验表明，请求量与成本可以实现一定程度的解耦，这为更多公司尝试类似转型提供了财务可行性依据。

Agent 具体接管审查、测试与合并环节

在 Uber 的流程中，AI Agent 已经深度介入代码审查、测试生成和合并决策三个核心环节。

代码审查阶段，Agent 能自动分析变更内容，检查风格一致性、潜在 bug、安全漏洞和性能问题。它会生成详细的审查意见，有时直接建议具体修改方案。开发者不再需要从零开始阅读每一行 diff，Agent 先过滤掉大量常规问题，只把真正需要人类判断的部分推送给工程师。

测试环节是 Agent 发挥作用最明显的领域之一。Agent 可以根据代码变更自动生成单元测试、集成测试甚至端到端测试用例。它不仅写测试代码，还会运行测试、分析覆盖率，并在测试失败时给出修复建议。这一能力直接减少了开发者编写测试用例的重复劳动，也提高了测试的及时性。

合并流程中，Agent 的角色更为主动。在满足预设质量门限、审查意见被解决、测试全部通过的情况下，Agent 可以自动批准并合并部分 PR。这一自动化合并能力是 70% 关联比例得以实现的重要支撑。当然，关键路径上的合并仍然需要人工确认，但大量常规 PR 已实现无人值守合并。

这些环节的打通依赖于 Agent 与现有工具链的紧密集成，包括 GitHub、内部 CI 系统和监控平台。Agent 不是孤立的聊天机器人，而是嵌入式的工作流参与者。它能理解 Jira 任务、读取相关文档、甚至参考历史 PR 的处理方式。

Uber 的实践表明，Agent 在这些环节的表现已经达到可投入生产的水平。但它目前更擅长处理确定性强、规则明确的场景，对于高度创新或涉及业务逻辑判断的任务，仍然需要人类介入。

工程师从动手编码转向 Agent 监督

随着 Agent 接管 70% 的 PR，Uber 工程师的日常工作内容正在发生结构性变化。过去大量时间花在编写 boilerplate 代码、写测试、做代码审查上的工作，现在更多转向定义 Agent 的行为、审核 Agent 输出和处理例外情况。

角色定位从「代码生产者」转向「系统监督者」。工程师需要更多思考「这个变更的目标是什么」「Agent 遗漏了哪些边界条件」「如何用自然语言清晰描述需求」这类问题。动手写代码的比例下降，设计、验证和协调能力变得更加重要。

对个人技能的要求也随之改变。熟练掌握 Prompt Engineering、理解 Agent 架构、具备较强的代码阅读和调试能力成为新门槛。那些能有效「指挥」多个 Agent 协同完成复杂任务的工程师，将比单纯编码速度快的工程师更有竞争力。

这一转变并非对所有人都友好。部分习惯于传统编码流程的开发者可能需要一段时间适应。Uber 内部很可能已经或正在开展相关培训，帮助团队完成角色转型。同时，绩效评估标准也需要调整，不能再简单以代码行数或 PR 数量衡量贡献。

长远来看，这种转变有望让工程师把精力集中在更有创造性的工作上，比如架构设计、新功能构思和跨团队协作。但短期内，监督 Agent 本身也可能成为新的认知负担。如何在不增加总体工作量的情况下完成这一转变，仍是 Uber 和整个行业需要持续观察的课题。

中国互联网公司可复制的效率路径

Uber 的案例为中国互联网公司提供了一条清晰的工程效率提升路径。国内大厂普遍面临代码规模大、迭代速度快、开发者人力成本高的压力，引入类似 AI Agent 系统有望在不显著增加预算的情况下实现产能放大。

首先是技术路径的可复制性。国内公司可以基于开源大模型或国内厂商提供的 API，构建自己的「AI 软件工厂」。重点不在于追求最强模型，而在于做好与现有 GitLab、Jenkins、内部代码平台的集成，以及针对自身代码风格和业务领域的模型微调。

组织方式上，可以采取渐进式 rollout。先在非核心业务线试点，收集数据验证成本和质量指标，再逐步扩大到全公司。70% 的关联比例不是一蹴而就的目标，而是通过持续迭代 Agent 能力逐步达成的。

对工程效率的提升可能体现在多个维度：PR 处理周期缩短、测试覆盖率提高、重复劳动减少。这些变化最终会转化为产品迭代速度加快和人力投入产出比提升。对于面临激烈竞争的互联网公司来说，这意味着能用同样的团队规模支撑更多业务线。

当然，复制过程中需要注意本地化问题。中国公司的代码规范、审查文化、合规要求与 Uber 存在差异，需要对 Agent 的规则库和决策边界进行针对性调整。那些已经积累了大量内部代码和审查数据的公司，在训练领域特定 Agent 时会具备明显优势。

Agent 自主性与质量把控边界仍未明确

尽管 Uber 取得了显著进展，但 Agent 的自主性边界和质量把控问题仍缺乏明确答案。

目前还不清楚在 70% 的 PR 中，Agent 自主决策的比例到底有多高。哪些变更可以完全由 Agent 合并，哪些必须经过至少一名 Senior Engineer 复核，Uber 并未公开具体阈值。这导致其他公司难以直接复制其治理框架。

代码质量风险是另一个悬而未决的问题。Agent 生成的代码和测试可能在短期内通过所有门限，但在长期维护性、可读性或隐含的架构问题上存在隐患。Uber 是否建立了针对 Agent 产出代码的长期跟踪机制，目前没有公开信息。

人工复核比例同样关键。即使 70% PR 与 Agent 关联，仍可能有相当比例需要人工最终签字。完全依赖 Agent 自动合并的比例如果过高，可能引发质量事故；如果过低，又会限制效率提升的空间。这一平衡点仍在探索中。

责任归属也是模糊地带。当 Agent 引入的 bug 导致线上故障时，责任应该由编写 Prompt 的工程师、审核 Agent 输出的开发者，还是平台维护团队承担？这一问题在法律和组织层面都还没有形成共识。

Uber 的案例虽然亮眼，但也提醒行业：技术可行性不等于治理完备。在全面推广 Agent 之前，公司需要同步建立质量保障、风险控制和责任认定机制。否则，短期效率提升可能被长期的技术债和事故成本抵消。

这些未明确的部分正是未来研究和实践需要重点突破的方向。只有当自主性边界、质量标准和责任体系都清晰之后，AI Agent 才能真正从实验工具转变为可信赖的工程伙伴。

参考来源