CI/CD适配AI智能体软件工程

CI/CD适配AI智能体软件工程

AI智能体不会简单地让开发效率提升几倍，它会首先把传统CI/CD的基本假设击穿：过去的软件交付系统服务于低频的人类提交，未来的软件交付系统必须服务于高并发、持续运行、可验证、可治理的智能体循环。

这场判断来自AI Engineer频道发布的一次技术分享。演讲者Madison Faulkner是NEA合伙人，长期关注基础设施和开发者工具，曾在Meta从事AI研究并带领数据与AI团队；Hugo Santos是Namespace CEO，曾在Google负责微服务相关工作，目前带领团队建设面向高性能计算和开发流程加速的基础设施。他们的核心观点可以概括为一句话：传统CI/CD不是彻底没有价值，而是不再适合作为智能体软件工程的中心架构。

要理解这一点，必须从传统CI/CD的设计前提说起。

在过去十多年里，现代软件工程形成了一套相对稳定的流程：开发者在本地修改代码，提交Pull Request，团队成员进行代码评审，CI系统运行构建、测试、安全扫描和部署前检查，失败后开发者修复，通过后进入合并队列，最终进入主分支并部署。

这套流程背后的隐含条件是：提交频率相对低，反馈延迟可以接受，人工评审是质量控制的核心节点。一个工程师一周提交一两个diff，哪怕一个中型团队有几十名开发者，系统也能通过排队和异步协作消化这些变更。构建慢、测试慢、评审慢并不一定立刻暴露，因为人类本身就是慢变量。

AI智能体改变了第一个变量：代码生成速度。

当代码生成的边际成本下降，软件开发不再是“人类慢慢写、机器偶尔验证”，而变成“机器持续生成、系统持续验证”。智能体可以同时处理多个任务、打开多个分支、在多个仓库中修改代码，并根据失败结果自动重试。过去一周几个PR的节奏，可能变成一天几十个、几百个候选变更。

这不是理论推演。Madison在演讲中提到，近几个月GitHub上的提交活动和新增、删除代码行数已经出现显著上升。与此同时，从GitHub Copilot到Cursor、Claude Code、各种企业内部智能体，开发团队正在把越来越多代码生成任务交给AI。2023年至2026年间，开发工具的竞争重点也明显从“辅助补全”转向“端到端任务执行”。

代码生成速度提高，直接导致第二个结果：CI/CD资源压力上升。

传统CI系统通常围绕分支、PR和提交触发任务。每个PR可能启动构建、拉取依赖、创建容器、执行测试、运行静态分析。如果智能体制造大量短生命周期分支，CI runner会更快饱和；如果每个分支都冷启动Docker环境，构建时间会被重复初始化吞噬；如果缓存被高并发任务频繁冲刷，原本用于加速的缓存反而会失去稳定性。

这正是传统流水线在智能体规模下的第一类故障：计算资源不是线性增加，而是被重复劳动放大消耗。

例如，一个人类工程师修改同一模块，可能在本地保持热缓存，连续几次测试都能复用环境。智能体如果在云端为每个候选分支创建新环境，就会反复安装依赖、拉取镜像、编译相同组件。单次看只是几分钟浪费，大规模并发后就会变成系统性成本。

因此，CI/CD适配AI智能体软件工程的第一步，不是发明新概念，而是加速现有构建、测试和部署链路。Madison提出，缓存会从传统意义上的性能优化手段，升级为新的编排层。它不只是保存中间结果，还要决定任务路由、环境复用、计算调度和状态保持。

这引出第三个因果节点：当缓存成为编排层，CI/CD就从“触发式流水线”走向“持续计算平台”。

传统CI/CD强调事件触发：提交发生，流水线启动，检查完成，结果返回。智能体工程强调循环：智能体拿到目标，检出代码，修改，实现，验证，失败后调整，再验证，直到满足要求。这个过程不适合每一步都从零启动。它需要状态，需要记忆，需要快速恢复上下文。

Hugo特别强调，未来的智能体循环必须是stateful，即有状态的。原因很简单：如果每一次验证都重新创建环境，每一次修改都重新加载世界，每一次失败都从头开始，那么智能体越多，系统越慢。状态不仅包括代码工作区，还包括依赖缓存、构建产物、测试结果、模型上下文、任务意图以及已知失败路径。

这使得开发基础设施的重点发生转移：从“如何把一次CI任务跑完”，转向“如何让一个智能体长期、高效、可控地运行开发循环”。

接下来，代码生成和验证速度的提升，会暴露第四个瓶颈：PR不再适合作为主要工作单元。

Pull Request最初是为人类协作设计的。它把一组代码变更打包成可审查单元，让团队成员异步阅读、评论、要求修改，然后批准合并。这种机制默认反馈可以延迟，也默认审查者能够逐个理解变更。

在智能体规模下，这两个默认前提都会失效。

第一，反馈不能太慢。智能体循环依赖快速反馈。如果测试要15分钟，安全检查要20分钟，人工评审要半天，那么智能体的实际吞吐量会被最慢环节锁死。第二，人类不可能逐个审查所有PR。Namespace团队已经观察到，内部类似传统PR的工作量达到以前的4倍，人类评审者很难继续按旧方式逐项阅读。

因此，工作单元必须从“PR”上移到“意图和计划”。

所谓意图，是团队真正想达成的目标，例如修复一个认证漏洞、实现一个结算接口、调整一个前端交互。所谓计划，是实现目标的步骤、约束和验证标准。它可以来自Linear工单、Slack讨论、产品需求文档或工程规范。智能体不应只是接收“改这段代码”，而应接收“完成这个目标，并满足这些约束”。

这一变化会带来一个关键结果：人类评审对象从diff转向outcome。

在传统流程中，人类看代码差异；在智能体流程中，人类更应该看意图、执行结果和验证证据。例如，一个功能是否真的可用，可以通过演示视频、自动化测试报告、截图对比、性能指标和安全智能体审查结论来说明。人类仍然参与决策，但不再被迫逐行阅读每一个候选变更。

这不是降低质量，而是重新分配质量控制职责。

因为在AI智能体软件工程里，质量控制不应集中在PR末端，而应嵌入整个循环。内部验证负责利用仓库中已有资产运行构建、测试和静态检查；外部验证则可以由专门智能体完成，例如安全智能体检查漏洞，API一致性智能体检查接口规范，合规智能体检查许可证和审计要求，性能智能体运行基准测试。

这导致第五个节点：CI不会消失，而是内嵌到智能体循环中。

过去CI像一道门。代码写完后，过门检查。未来CI更像开发过程中的神经系统，每次修改、每次推理、每次重试都触发局部验证。构建是否成功、测试是否通过、是否从可信commit开始、是否引入未经审查依赖、是否违反安全策略，这些不变量都要被持续执行。

Hugo在演讲中特别提到，合规场景下仍然需要保证代码从已知checkout开始，不能让团队内部某个未经验证的改动被智能体当作基础继续扩散。这说明治理不会因为AI自动化而消失，反而会更重要。因为机器速度越快，错误传播也越快；如果没有持续治理，一个错误假设可能在数百个候选变更中同时扩散。

当验证内嵌到循环后，第六个瓶颈会出现：合并队列变成序列化账本。

Git仓库可以被理解为一条账本。所有变更最终都要以某种顺序进入主分支。人类时代，提交频率低，合并队列的等待成本可以接受。智能体时代，候选变更大量并发产生，多个任务可能修改同一代码区域，主分支持续移动。于是，合并不再是简单按钮，而变成高并发系统中的一致性问题。

Hugo把这一点类比为高性能数据库：每个变更都想写入同一个账本，但为了保证一致性，系统需要序列化，需要冲突检测，需要确定写入顺序。机器生成代码越快，“time-to-commit”越可能成为真正瓶颈。

这就是为什么演讲提出pre-merge，即预合并层。

预合并层位于智能体完成候选变更之后、代码进入主仓库之前。它负责收纳已经通过初步验证的变更，进行冲突协调、语义分组、排序、去重和最终审批。大量变更不直接冲进主分支，而是在这里被整理成可以由人类理解和治理的结果包。

这个架构解决了两个问题。

第一，它避免主分支被高并发候选变更直接冲垮。第二，它让人类可以从更高层次审查结果，而不是逐个处理零散PR。一个预合并项可能并不对应单一commit，而是多个智能体围绕同一意图产生的多个候选结果，经过系统整合后呈现给人类。

再往前推一步，会出现第七个节点：开发进入多候选并行的“多重宇宙”。

如果主分支不断移动，智能体未必应该只基于最新commit工作。它可能需要在多个候选commit上并行尝试同一个计划，因为每个起点面对的上下文不同，冲突概率不同，最终合并成本也不同。系统需要比较这些路径，选择最符合意图、验证最充分、合并成本最低的结果。

这就是Hugo所说的multiverse。它不是文学化表达，而是并发开发的自然结果。当智能体数量足够多、任务足够密集、主分支变化足够快，单一路径开发会变得低效，多路径探索反而可能更稳定。

但多路径探索会显著放大资源消耗。每多一个候选起点，就可能多一套构建、测试、验证和冲突解决成本。因此，未来基础设施必须同时追求性能和效率：不做不必要的工作，不重复冷启动，不抛弃可复用状态，让智能体像过去的人类工程师使用本地工作站一样，尽可能增量地工作。

到这里，完整的因果链已经清晰：

AI降低代码生成成本，导致候选变更数量上升；候选变更数量上升，导致传统CI runner、缓存和构建系统承压；计算承压推动缓存和状态成为编排核心；智能体循环需要快速反馈，于是PR不再适合作为主要工作单元；工作单元上移为意图和计划，人类评审转向结果和证据；大量候选变更进入预合并层，合并队列变成账本一致性问题；主分支持续移动，又推动多候选、多起点的并行开发。

因此，“CI/CD已死”更准确的说法是：以PR为中心、以阶段为边界、以人类延迟为缓冲的CI/CD架构正在失效；以持续计算、状态复用、智能体验证和预合并治理为核心的新架构正在形成。

对工程组织来说，真正的问题不是要不要使用AI写代码，而是现有工程系统能不能承受AI带来的吞吐量。很多团队会误以为瓶颈在模型能力：代码写得不够好，推理不够强，工具不够智能。但从基础设施视角看，模型能力提升后，瓶颈会快速转移到验证、协调、合并和治理。

可以用一个判断框架来评估团队是否需要升级CI/CD架构。

第一，看吞吐量：AI工具引入后，PR、commit、分支数量是否明显上升？如果代码变更多了，但评审和测试资源没变，瓶颈必然后移。

第二，看反馈时间：核心构建和测试是否仍以分钟级甚至几十分钟级运行？如果是，智能体循环会被验证环节锁死。

第三，看状态复用：构建环境、依赖缓存、测试结果是否能跨任务、跨分支稳定复用？如果每次都从零开始，计算成本会随智能体数量急剧放大。

第四，看合并压力：主分支是否频繁出现冲突、重跑、排队和回滚？如果合并队列已经像数据库锁一样阻塞，说明仓库账本正在成为瓶颈。

第五，看治理能力：团队能否追踪每个智能体的身份、权限、起始commit、执行计划、验证证据和最终结果？如果不能，自动化越强，风险越难审计。

未来的软件工程竞争，可能不再只是“谁的模型更会写代码”，而是“谁的组织更会管理机器生成的变化”。CI/CD不会作为原则消失，构建、测试、验证、部署仍然重要；但它们必须从离散阶段变成连续过程，从PR管道变成智能体运行时的一部分。

真正值得讨论的问题是：当AI让代码产量提高10倍甚至100倍时，我们应该继续让人类站在PR门口逐个盖章，还是重建一套能让机器高速工作、人类高阶治理的新软件工程系统？这个选择，可能会决定下一代工程组织的效率边界。

以上是10xEngineer从视频字幕，通过LLM自动总结精选的文章，学习之用，内容不代表10xEngineer的观点。
☯🌱🤖⌨️🍶🗡️🐚