从 Uber 单体仓库到 SonarSource：CI/CD 架构的演进背景

Gautam Korlam，QAR 联合创始人兼 CTO，现任 SonarSource 首席工程师，拥有超过十年的构建与合并基础设施经验。在加入 Uber 的十年间，他负责单体仓库（mono repos）中的 CI/CD、ID 等系统，确保开发者的生产力。收购后加入 SonarSource/QAR，他的重点转向验证 AI 代理生成的代码质量。回顾 Uber 早期历史，面对每天数千次变更和漫长的构建时间，传统的串行合并会导致长达 20 天的等待期以维持主干分支稳定；而若跳过测试直接合并，则会导致主干频繁变红（broken），因为变更之间相互冲突。为解决此问题，Uber 开发了 Submit Cube 系统。

"We had one giant monor repo and we were doing like thousands of changes a day... if you just kept everything serialized... you would take a really long time up to days so 20 days in this case."

Submit Cube 的核心逻辑在于并行测试所有可能的提交组合。系统会预测哪些 PR（Pull Request）可能导致失败，若发现风险则将其从队列中移除并通知作者修复；只有当提交与所有其他进入主干的提交组合测试均通过时，才会被允许合并到主干。这一机制旨在保持主干清洁的同时减少等待时间。尽管如今 GitHub 等平台已推出合并队列功能，但在当时这是 Uber 内部开发的独特解决方案，且至今仍在运行。这一历史背景揭示了传统 CI/CD 在面对高并发、长构建时间时的局限性，也为理解当前 AI 时代的瓶颈提供了基础。

AI 代理引发的吞吐量爆炸与中心化瓶颈

当前软件工厂面临的核心挑战是提交量的指数级增长。Korlam 指出，SonarSource（原 QAR）团队规模虽小，但过去三年间的提交率增长了近 10 倍。行业数据显示，GitHub 等平台也观察到 PR 数量的惊人增长。以 SonarSource 为例，其审查的 PR 数量每月环比增长 25%。这种指数级增长并非个别现象，而是随着银行等高度监管行业加速采用 AI 而普遍存在的趋势。

"Our own rate of commits has almost like 10xed since we started guitar... Every month almost we're growing 25% month over month of just the amount of PRs that have to review."

然而，现有的 CI/CD 和代码审查队列是为人类速度设计的。过去，人类开发者每小时仅产生几次变更，系统可以逐个处理测试和审查。现在，AI 代理每天可生成多个 PR，且倾向于同时提交而非等待队列。这导致 CI/CD 和审查环节成为软件生命周期（SDLC）中的中心化瓶颈。当大量代理同时触发工作流时，系统因过载而陷入停滞。这种供需失衡表明，基于人类节奏构建的基础设施已无法适应 AI 代理的高频产出模式，必须重新架构以应对高并发压力。

主干稳定性危机与软件工厂的效率陷阱

在 AI 代理高频提交的环境下，传统的逐个测试模式存在严重缺陷：单个 PR 通过 CI 并不能保证合并后的主干依然稳定。如果代理生成的代码之间相互冲突或产生副作用，即使每个 PR 单独测试通过，合并后仍可能导致主干崩溃。此外，采用“软件工厂”模式（即由 AI 根据规范生成代码，人类仅负责规范和审查）也面临效率陷阱。现有的工厂流水线是为人工速度优化的，当 AI 加速输入时，每个环节都会减速。

具体瓶颈包括： 1. 构建与测试：编译失败或集成测试中的不稳定（flaky）测试会导致大量重试，复杂构建可能需要数小时。 2. 审查环节：虽然许多团队引入 AI 进行初步代码审查，但若缺乏系统化流程，人类审查者仍会成为瓶颈。在高 PR 速率下，审查者可能因无法跟进而进行“橡皮图章”式（rubber stamping）的盲目批准，从而牺牲代码质量。

"The factory line that exists today was built for human speed... as agents push more changes every part of the factory line is going to be slowing down."

因此，解决之道不仅在于加速单个环节，更需改变 CI 系统的架构和代码组织方式。系统需要智能地测试变更之间的相互作用，而非孤立对待每个 PR。只有当 CI 和审查队列具备处理高并发、预测冲突并自动协调的能力时，才能在保持主干绿色的前提下，实现 AI 规模下的快速迭代。

AI 代码激增带来的合规审计与可追溯性危机

随着 AI Agent 生成大量提交，传统的 CI/流程面临严峻挑战。过去依赖信号通过检查的方式已不再适用，且大量记录因过期而消失，导致缺乏有效的审计痕迹。> So there needs to be some record of these things for auditability and compliance checks to happen. 这种缺失使得合规性检查变得困难，因为仅仅有一个批准印章不足以证明实际进行了哪些检查。在受监管行业，政策执行必须超越代码编译阶段。例如 Uber 曾因功能标志变更导致司机未经过完整检查即可上车，从而在伦敦失去运营许可。为此，他们建立了严格的流程，要求所有影响特定区域（如伦敦）的变更必须明确其血缘关系及控制措施。对于 AI 生成的代码，仅靠编译通过无法确保符合 HIPAA、Tora 等政策规范。因此，必须在 CI 之外建立机制来强制执行这些规则，并记录执行过程以满足审计要求。

前置修复与自动合并策略

在代码提交至主分支之前，团队利用GAR（GitLab AI Reliability）等工具进行前置修复。这种机制不仅能防止昂贵的错误进入主分支，还能自动建议修复方案、提交代码并将工程师列为共同作者。通过这种方式，团队无需在合并后浪费时间去修补问题。GAR自动修复并承诺代码是提升效率的关键。随着越来越多的客户开始采用类似做法，团队发现使用策略和标准来决定何时批准变更变得尤为重要。许多日常或低风险的更改，如文档更新、不破坏API的依赖项升级、安全补丁以及内部工具的低风险变更，都可以被自动批准。GitLab原生支持这些功能，并允许用户添加用自然语言编写的自定义规则来创建审批和合并逻辑。目前，AI原生团队正在快速采用自动批准和自动合并按钮，即使在拥有超过10万名开发者的庞大团队中，这一采纳率也在迅速增长。

基于风险的审批策略与零信任原则

团队实施了一套精细的审批政策，根据变更类型决定是否需要人工干预。例如，对于依赖项升级和文档更改，系统会自动批准；但对于涉及支付或敏感领域的代码变更，则必须经过人工审批。核心原则是“零信任”，即生成更改的代理（Agent）不能批准其自己的变更。当新变更不符合自动审批标准时，流程会升级至其他审批人。代理生成的PR由他人批准是确保合规性的基础。这种机制不仅可以通过自定义Agent实现，GitLab也提供了开箱即用的解决方案。通过这种方式，团队能够在保持安全性的同时，大幅减少人工审核的瓶颈，让低风险变更快速流动。

CI数据留存与合规性审计挑战

仅依赖CI状态（绿色）并不足以证明代码符合规范，因为许多情况下CI通过并不代表合规。一个典型问题是Flaky Test（不稳定性测试）：如果强制推送以修复某个已知会失败的测试，分支指向的代码可能已发生变化。随着时间推移，大多数CI数据都会过期，如果没有记录发生了什么以及修复了什么，团队将无法进行合规性或审计追踪。因此，代理轨迹和每次推送后的结果记录至关重要。任何保存在PR或其他系统中的信息都将成为事实来源，以应对工件过期的问题。控制的核心在于确保变更由未编写代码的人批准和测试。记录失败原因及人工确认是关键，例如在管道失败的案例中，如果记录了已知故障模式并由他人批准保留该状态，则可通过检查；反之，若盲目信任代理且无合规记录，则存在风险。

全链路审计记录与流程优化

为了应对AI规模下的提交量，团队需要保留详细的审计记录。这些记录包括：哪个编码代理创建了PR、PR的来源会话、触发者是自动化工作流还是工程师提示。对于每次运行的CI，不仅要保存状态，还要保存测试报告。每个发现的问题都必须记录其解决方式（忽略、跟进或修复）。审批人必须与提示代理的人不同，且任何覆盖项（如跳过代码覆盖率）都必须明确说明原因。此外，合并的代码必须包含所有检查记录，确保不是在小变更上直接合并而遗漏了之前的验证。代理不能批准自己的更改是硬性规定。通过实施这些实践，团队可以移除瓶颈：更快的CI解除构建阻塞，将检查左移减少测试负载。自动化大部分审查并仅在例外情况下升级给人工，能显著提升软件工厂的潜力。每次批准和合并后记录结果为后续迭代提供了宝贵的上下文。

结论

视频论证表明，传统为人类速度设计的 CI/CD 架构已无法应对 AI 代理引发的提交量指数级增长，导致中心化瓶颈与主干稳定性危机。核心解决方案在于重构流程：通过前置自动修复、基于风险的零信任审批策略及自动化合并按钮，实现低风险变更的快速流动。同时，必须建立全链路审计记录以确保持续合规。

该模式在提升吞吐量与减少人工瓶颈方面优势显著，但高度依赖完善的自动化策略、严格的代理隔离机制及详尽的审计追踪。其适用条件包括具备自然语言规则定义能力的平台支持，且需警惕因过度自动化导致的“橡皮图章”式审查风险。