编程代理让 CI 成为瓶颈；加速构建流水线并非完整解决方案

随着编程代理的使用不断扩大，持续集成（CI）已成为新的瓶颈。这一结论基于 Anthropic、Linear 和 Depot 的工程团队在 9 月介绍的实践，而不是某一个工具发布的结果。Anthropic 的 CI 作业量在六个月内增长了 25 倍，同时，其工程师每个季度提交的代码量已经约为 2021 年至 2025 年期间原有水平的八倍。Linear 的测试套件规模也已接近 1 月份水平的四倍，而如今大多数测试由代理编写。

Anthropic 采用测试影响分析，只运行可能受到变更影响的测试；Linear 则几乎完全重新设计了其流水线。这些措施缩短了等待时间，但它们只解决了问题的一层：代码仓库检查的速度。

为什么 CI 速度已经不够？

CI 的设计历来遵循人工作业模式：开发者每周创建数量有限的合并请求，然后在转向另一项任务时等待流水线结果。而代理可以并行创建代码、测试和合并请求，从而使 CI 操作数量成倍增加。文章指出，销售 CI 运行器的公司 Blacksmith 观察到，其运行的作业数量每周增长 5% 至 10%。

第二个问题在于验证发生的位置。代理编写变更，然后在创建合并请求后等待结果。当结果在 20 分钟后返回时，它可能已经失去任务上下文，而每一个问题都意味着新一轮等待。

代码仓库不是系统

对于独立应用，代码仓库测试可能能够较为接近地反映系统行为。但在云原生环境中，代码仓库只是一个可能包含数十项服务的系统中的一项服务，而系统的其余部分通常由模拟接口或测试数据表示。

因此，一项变更可能通过单元测试、通过 CI，并在隔离环境中运行正常，却在第一个跨越服务边界的真实请求到来时失败。例如，修改另一项服务所依赖的字段名称，缩短超时导致一连串重试，修改架构导致测试环境中的表被锁定，或者某个端点在实际由消费者服务调用时表现不同。

文章引用了 DevOps Research and Assessment（DORA）的数据。该数据将人工智能采用率的提升与软件交付频率增加以及交付不稳定性增加同时联系起来。也就是说，更快地产生代码并不保证更好的验证。

实践中会发生什么变化？

建议的解决方案不是取消 CI，也不是让代理变慢，而是将部分验证更早地移入代理的工作循环，使其针对实际系统而不只是代码仓库副本测试变更。Cursor 等工具使用隔离的云环境；Cursor 合并的合并请求中，超过 30% 来自以这种方式运行的代理。其他工具，包括 GitHub Copilot cloud agent、Codex、Devin 和 Greptile，也提供了在临时环境中运行代码的不同形式。

但这些环境通常包含分支及其配置，以及初始化脚本能够安装的内容，却不包含其他服务、真实消息列表和类似生产环境数据的数据库。因此，文章认为，循环虽然闭合了，但它可能是围绕错误的对象闭合的。

共享环境与受控验证

文章建议在 Kubernetes 集群中运行一份稳定的共享服务副本，同时创建只部署已修改服务的轻量级测试环境。带有标签的请求会被路由到该服务，其余路径则连接到共享的稳定副本。这样，大量代理可以共享环境，而不必为每个代理复制整个系统；文章估计，环境成本可能接近单个容器的成本，启动时间为数秒，但来源没有提供独立测量来证明这些估计适用于所有环境。

环境本身并不足够。平台团队需要制定经批准的流程，明确要发送哪些请求、收集哪些日志以及必须证明哪些契约。还应记录测试接触过的服务及其结果，使记录能够被审查工具和合并网关读取。作者强调，治理对于防止代理在共享集群中执行不安全操作是必要的。

从 certi.news 的角度看，真正的变化不只是加速 CI，而是重新定义验证“成功”应当意味着什么。代码仓库测试仍然重要，但对于代理以更高速度生成的分布式系统而言，单靠它并不足够。成本、隔离、数据安全以及验证准确性的衡量方式等问题仍未解决，而且本文呈现的是一种分析性论点，而不是经过证实的标准或某个特定产品。