代理让CI成了瓶颈，更快的流水线并非正解。
内容提要
AI编程导致CI成为瓶颈：代理并行工作使PR量激增，Anthropic的CI任务半年增25倍。但CI仅验证单个代码库，无法发现分布式系统中跨服务边界的故障。DORA数据显示，AI采用率越高，交付越快但越不稳定。解决之道是在代理循环内、提交PR前，用共享Kubernetes集群上的轻量测试环境对真实系统做验证。
延伸解读
CI加速的局限：验证对象仍是代码库
文章指出，当前行业努力让CI更快，但默认验证对象是代码库。对于云原生系统，一个代码库只是数十个服务之一，其测试会模拟其他服务。因此，即使CI飞速通过，跨服务边界的故障仍无法被发现。加速CI并未改变验证内容，只是让同样的验证更快，无法解决分布式系统中的接缝问题。
代理循环内的系统级验证：共享集群与轻量环境
文章提出，应在代理循环内、提交PR前，对真实系统进行验证。通过共享Kubernetes集群运行所有服务的稳定版本，并为每个变更部署轻量测试环境，仅部署被修改的服务，其他请求路由到稳定版本。这样，代理可以针对真实依赖测试，成本仅相当于一个Pod，且能快速启动，支持大量代理并行。
结构化验证与治理：平台团队的关键角色
文章强调，仅有廉价环境不够，代理需要结构化的验证步骤。平台团队应预先编写一系列经批准的操作，让代理通过技能和钩子调用，以针对真实系统执行请求、捕获日志、断言契约。同时，治理确保代理在共享集群中不会执行不安全操作。验证记录可作为工件供后续审查和合并门禁使用，使CI成为确认步骤而非首次发现跨服务问题的地方。
Q&A
为什么AI编程会让CI成为瓶颈？
因为AI代理并行工作导致PR数量激增，CI任务量大幅增长（如Anthropic半年增长25倍），而CI流水线原本是为人类开发速度设计的，无法快速处理如此多的验证请求。
为什么仅仅加快CI流水线速度不能解决根本问题？
因为CI只验证单个代码库，无法发现分布式系统中跨服务边界的故障。加快流水线只是让同样的验证更快，但验证的内容没有改变，仍然无法捕捉服务间的交互问题。
DORA数据揭示了AI采用与软件交付之间怎样的关系？
DORA发现，AI采用率越高，软件交付吞吐量增加，但软件交付不稳定性也同时增加。即交付更快，但更容易出问题。
在分布式系统中，哪些类型的故障是CI无法发现的？
跨服务边界的故障，例如：响应中重命名的字段导致下游消费者读取错误、一个服务中收紧的超时引发其他服务的重试、模式变更在测试夹具中正常但在预发环境中锁表、新端点在被测试工具调用时正常但被依赖服务调用时异常。
如何在代理循环内实现系统级验证？
在共享Kubernetes集群上运行轻量级测试环境，每个环境只部署变更的服务，其他服务使用共享的稳定版本。请求经过修改的服务，其他跳转解析到稳定版本。这样代理可以在提交PR前对真实系统进行验证。
为什么在共享集群上为每个代理创建独立测试环境是可行的？
因为通过多路复用，一个共享的Kubernetes集群可以运行所有服务的稳定版本，并在其上托管数千个轻量级测试环境。每个测试环境只部署变更的服务，成本大约相当于一个Pod，几秒内即可启动。五十个代理可以共享一个稳定环境，而不是克隆五十次。
