代理工作流导致拉取请求激增，使代码验证成为关键瓶颈。传统共享环境和完整复制集群成本高昂且效率低下。为解决此问题，需要可扩展的瞬时环境，它能迅速为每个PR提供隔离的真实运行环境。Istio等服务网格用户因其路由能力，在实现这一解决方案上具有显著优势，能有效加速验证流程并提升开发效率。
译自：The agent pull request flood is here. If you run Istio, you’re halfway to solving it.
作者：Arjun Iyer
代理拉取请求洪流来袭。如果你运行Istio，你已成功解决一半。
代理工作流正在迅速增加拉取请求的数量，而验证正迅速成为最关键的瓶颈。使用Istio等服务网格的团队，在瞬时环境中解决此问题处于有利地位。
各行业的工程团队正在面对一个严峻的新现实。代理工作流的广泛采用使得代码生成廉价且快速，但它也创建了一个新的基础设施问题。
在更简单的应用架构中，在持续集成流水线中运行单元测试和模拟可能足以验证代理生成的代码。但在云原生、分布式系统中，在实时环境中验证行为至关重要。
在过去的几个月里，我看到与客户和同事的对话从“代理非常适合编写代码，但我们没有看到它影响流水线”转变为“我们被PRs淹没了”。验证已成为分布式系统的新瓶颈。
“如果你不能像代理编写代码一样快速地验证代码，你的流水线将退化到其设计处理的人工级别吞吐量。”
这场洪流对各个组织的影响并不均等。像Stripe、Ramp以及其他高级AI工作流的早期采用者，在合并到主分支的代码量方面看到了指数级增长。他们很早就认识到，生成代码只是成功的一半。如果你不能像代理编写代码一样快速地验证代码，你的流水线将退化到其设计处理的人工级别吞吐量。
对于希望复制这些组织成功的团队来说，答案可能已经在他们的集群中运行。如果你的平台目前运行着像Istio这样的服务网格，那么你已经成功解决了一半的验证瓶颈。
AI速度错觉和集成瓶颈
最近的CircleCI 2026年软件交付现状报告证实了值班轮岗人员已经感受到的事实：流水线正因自身的成功而堵塞。尽管平均工作流吞吐量同比增长59%，但这些增长高度集中在顶端。精英团队正以空前的规模运作。前5%的团队吞吐量几乎翻倍，增长了97%。
对于绝大多数组织来说，流水线正在堵塞。中位数团队在AI支持快速原型开发的特性分支上的吞吐量增长了15.2%，但他们主分支的吞吐量实际上下降了6.8%。开发人员及其自主代理正在生成显著更多的代码，但团队却在努力审查、验证和推广它。
“流水线正因自身的成功而堵塞。开发人员及其自主代理正在生成显著更多的代码，但团队却在努力审查、验证和推广它。”
传统的共享暂存环境从未被设计来处理这种级别的并发。它们是为人工输出而设计的。对于一个50人的工程团队，每天生成2-3个拉取请求（PR），其基础设施被设计为每天处理100-150个PR。当遇到巨大的流量高峰时，这很快就成为一个关键的瓶颈点。队列的增长速度超过了其消耗速度。
未能升级其验证基础设施的组织发现，其AI投资所承诺的速度正在暂存队列中消散。那些取得成功的团队认识到，可扩展的验证基础设施是解锁代理工作流真正投资回报的唯一途径。
代理工作流的真正瓶颈
要理解这个瓶颈为何如此具有破坏性，你必须审视当机器输出速度与为人工吞吐量构建的基础设施相遇时会发生什么。代理以指数级增加拉取请求的数量，而传统的暂存队列和审查流程根本无法支持如此大的数量，从而导致难以置信的漫长积压。
由于流水线无法处理负载，开发人员被迫限制其代理的速度。他们不会提交全部代理生成的代码。相反，他们让代理依靠单元测试和模拟来避免暂存队列，直到开发的后期阶段。这种不完美的模式适用于对整个系统架构有心智模型并能直觉判断哪些更改会破坏下游依赖的人工开发人员。代理并非如此。它们经常生成通过局部单元测试但在引入更广泛的系统架构时失败的新颖代码。对于代理来说，与真实的运行环境进行快速反馈循环以验证其代码并非可有可无，而是必需的。
这意味着代理的潜在吞吐量被人为地限制在为人工速度设计的线性基础设施上。这也意味着通过的代码更有可能出错。CircleCI报告强调了这些集成失败的成本。大多数团队主分支的成功率降至70.8%。
环境复制的不可持续数学
为了将代理工作流增加的输出转化为实际吞吐量并消除这个瓶颈，验证基础设施需要为每个代理或拉取请求提供一个隔离的、真实的运行环境。传统上，平台团队会为每个拉取请求启动一个新的Kubernetes命名空间或一个隔离的集群。虽然这提供了必要的准确性，但在代理规模下，这种做法的数学模型完全崩溃。复制每个数据库、消息队列和微服务需要15分钟或更长时间。当你将这个开销乘以每天1000个拉取请求时，基础设施成本会爆炸式增长，而且15分钟的部署延迟会严重限制代理的迭代周期。
另一种绕过完整集群复制的常见方法是将负担转移到运行本地化容器设置的重型虚拟机上。我最近与一位工程主管交谈，他的团队通过动态生成Docker Compose文件用于隔离的云实例来处理集成测试。由于测试依赖于共享状态，在持续集成中触及少量核心文件会触发100个重型云实例群，这些实例会花费一小时进行顺序测试。
无论你是启动1000个完整的Kubernetes命名空间，还是编排重型虚拟机群以运行本地化容器，结果都是一样的。部署延迟会迅速累积，而AI工作流的速度在遇到线性基础设施瓶颈时就会减慢。
适用于代理规模的瞬时环境
这些复合因素意味着，唯一可行的解决方案是可扩展瞬时环境的新模型。为了处理机器速度的并发，环境必须在几秒钟内启动，并在不增加复制整个集群成本的情况下提供真实的运行环境。可扩展的瞬时环境模型不是复制所有内容，而是仅部署已更改的微服务，作为轻量级沙箱。架构的其余部分，包括所有重型数据库和稳定的下游服务，则从基线环境共享。沙箱动态地在已更改的服务和基线之间路由测试流量。
这种方法提供了与完整复制环境完全相同的高保真运行环境。代码针对真实的、实时依赖项进行测试。关键的区别在于资源占用。通过仅部署被测服务，环境在几秒钟内而不是几分钟内启动。它消耗的计算资源只是其中一小部分。
在这种模型中，代理可以验证其代码，获得即时反馈，并以大规模并发和零争用进行迭代。
路由出暂存队列
实施这种共享基线架构需要高级流量控制。从头开始构建这些环境的自动化和生命周期管理是一项巨大的工程任务。然而，运行Istio等服务网格的团队具有显著优势。
由于这些工具已经提供了所需的精确路由功能，因此实施上述可扩展的瞬时环境变得无缝。底层服务网格或入口控制器只需处理测试流量到轻量级沙箱的动态路由，同时确保所有常规流量不间断地流向稳定基线。
以下是Istio中配置时底层路由逻辑的样子：
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: location
namespace: hotrod-istio
spec:
hosts:
- location
http:
- match:
- headers:
baggage:
regex: ^.*\b(sd-routing-key|sd-sandbox)\s*=[^,]*\bqwblp48fpmb30\b.*$
- headers:
tracestate:
regex: ^.*\b(sd-routing-key|sd-sandbox)\s*=[^,]*\bqwblp48fpmb30\b.*$
route:
- destination:
host: local-location-location-9f4477c8.hotrod-istio.svc.cluster.local
port:
number: 8081
- route:
- destination:
host: location
当请求带有特定标头时，Istio会拦截它并将其直接路由到为该特定拉取请求部署的服务沙箱版本。
这背后的关键使能机制是上下文传播。在深度微服务调用链中，沙箱路由标头必须在每个服务之间自动传播。OpenTelemetry (otel) baggage传播无缝地处理了这一点。路由值随着跟踪上下文一起传输，跨越边界而无需任何单个服务显式转发它。
通过利用这些基础原语，平台团队可以轻松采用可扩展的瞬时环境解决方案，以编排沙箱服务的部署，并自动配置其现有网格中的路由规则。这使得代理能够针对实时集群依赖项验证自身工作，并获得即时反馈，从而消除集成瓶颈。
接下来
代理工作流是软件开发的新标准，它们已经揭示了传统代码验证和审查模型的裂缝。将可扩展验证基础设施作为首要任务的团队与尚未如此的团队之间的差距显而易见，并且只会越来越大。
已经运行Istio等服务网格的团队在这里遥遥领先。他们已经具备了流量路由原语，这使得实施像Signadot这样的可扩展瞬时环境解决方案变得无缝。这使他们能够迅速解决代理PR验证问题，以免其演变为全面危机。
