\n\nAI 智能体引发的代码量激增使传统开发流程（SDLC）难以为继。GitHub 正面临 30 倍扩容挑战。文章建议将验证环节左移，构建“闭环”模式，让智能体在提交前自主完成系统级验证，以解决交付瓶颈。
译自：The agent code explosion is here. We need to rethink our pipelines, fast.
作者：Arjun Iyer
GitHub 最近发布了 一份关于可用性的更新，此前在 4 月份发生了一些严重的故障。文章的开头有一句话，每个工程领导者都应该看到：
“我们于 2025 年 10 月开始执行将 GitHub 容量提升 10 倍的计划，目标是大幅提高可靠性和容错能力。到 2026 年 2 月，我们很清楚，我们需要为应对当今规模 30 倍的未来进行设计。”—— Vlad Fedorov，GitHub CTO
软件正在以前所未有的规模产出，而这一拐点恰好与编码智能体从早期原型转变为工程组织内的默认工具相重合。
当运行着地球上最经得起考验的开发者基础设施之一的 GitHub CTO 表示，正在进行的 10 倍扩容计划已经不够，必须推倒重来实施 30 倍计划时，这绝非例行的容量公告。这是一次公开承认：关于软件如何生产的底层假设的变化速度甚至超出了 GitHub 的预期，而我们其他人也都处于这些假设的下游。
预言已久的智能体代码大爆发已经到来，增量式扩容并非答案。软件现在的产出量已经超出了现有软件开发生命周期（SDLC）设计的承载能力。
当你无法将产量转化为吞吐量时，规模就成了问题
规模本身并不是问题。原则上，代码产量的 30 倍增长可以转化为交付功能的 30 倍增长。之所以没能实现，是因为 SDLC 从未将原始代码量以接近 1:1 的比例转化为交付吞吐量。这种转化一直是损耗性的，而损耗点就在于验证。
在智能体出现之前就是如此。任何构建过大规模软件的人都知道这些症状：耗时一小时的测试套件、长期损坏或冲突的暂存环境、直到发布候选版才被发现的集成缺陷、因为评审人员是唯一能判断变更是否安全的人而堆积如山的评审队列。验证是流水线中最慢、最依赖人工、最容易出错的部分，它介于代码编写和代码交付之间。
在 云原生架构 中，这一点变得更加困难。现代应用是由不同团队拥有的服务图谱，每个服务都有自己的状态、依赖关系和部署节奏。对一个服务的更改可能会波及其他六个服务，而真正导致崩溃的问题——契约漂移、竞争条件、多租户边界情况以及负载下的性能——都是运行时属性，在源代码或单元测试中无法体现。
之所以必须重新思考而不仅仅是扩容，是因为验证成本是复合增长的。在开发者或智能体迭代的“内部循环”中发现的错误，修复成本几乎为零。在 CI 中发现同样的错误，需要消耗一个完整的构建周期。在暂存环境中发现，则需要消耗部署和队列名额。在生产环境中发现，则意味着事故、回滚和撤销 PR，而撤销 PR 本身还得经过同样的流水线。
在人工编写速度下，由于产量受限于工程师人数，SDLC 还能吸收部分低效。在智能体编写的速度和规模下，这种低效变得不可吸收，并开始复合增长为不断堆积的待办事项。
这就是为什么答案不是增加 CI 容量、更多的暂存环境或更多的评审人员。这些是对结构性转变的战术性应对。结构性的答案是将验证尽可能“左移”，移入智能体产出代码的内部循环。在那里获得的效率会在下游产生复合收益；而留在那里的低效也会在反方向产生同样无情的复合损失。
“结构性的答案是将验证尽可能左移，移入智能体产出代码的内部循环。”
闭环是缺失的一环
尽管左移验证的理由和 SDLC 本身一样久远，但这种转变至今仍未发生是有原因的。今天的编码智能体只是半个工作系统。它们能以前所未有的速度编写代码，但当代码遇到分布式系统的其余部分时，它们无法判断自己编写的代码行为是否正确。编译通过不代表正确。单元测试通过只代表单元测试覆盖范围内的东西没问题。除此之外，服务之间所有的交互面都在智能体自身能够验证的范围之外。
“今天的编码智能体只是半个工作系统。它们能以前所未有的速度编写代码，但当代码遇到分布式系统的其余部分时，它们无法判断自己编写的代码行为是否正确。”
因此，智能体做了它唯一能做的事。它宣布变更已就绪并将其推向下游，而判断它是否真正工作的任务则留给了人工评审员、集成测试、暂存部署或生产事故。验证的复合成本开始生效，内部循环的机会就此丧失。
解决办法是在源头闭环。一个能在内部循环中、在变更成为拉取请求（PR）之前，针对真实系统验证自己工作的智能体，能减轻下游所有环节的负担。而一个做不到这一点的智能体，只会给已经超出负荷的流水线增加负载。
闭环究竟需要什么
这里的技术挑战是实打实的。如前所述，云原生系统的验证面存在于服务之间的交互中，而非源代码本身。闭环意味着给智能体一种自主触达该验证面的方式。
这就是为什么许多现有的智能体验证方法都差强人意。Mock 模拟了依赖项的行为，却错失了真实的依赖。单元测试覆盖了单个函数，却错失了集成面。绿色的 CI 运行告诉你 已测试的项目 通过了，这并不等同于变更就是正确的。
为了让智能体真正实现闭环，它需要针对系统的真实版本运行其候选变更，包括真实的服务、真实的依赖和真实的流量模式。而且，它需要足够快、足够廉价地完成这一切，以便智能体能够迭代、观察哪里出错了并再次尝试，而无需人工参与，无需争夺共享环境，并能达到智能体所要求的速度和规模。
一个能够做到这一点的智能体，在开启 PR 之前就广泛验证集成、契约、性能和故障模式，它从下游流水线中减去了工作量，而不是增加。到达 CI 的 PR 已经通过了针对真实系统的运行时验证。评审员不再是第一道验证层，他们只是对一个已被证明有效的变更进行确认。
每个工程组织的战略问题
30 倍的曲线将继续攀升，产出代码的智能体在编写方面也会越来越强。就其本身而言，这只会让验证鸿沟变得更糟，而非更好。一个能力更强但仍无法验证自身产出的智能体，只会更快地产生更多未经验证的产出。
“一个能力更强但仍无法验证自身产出的智能体，只会更快地产生更多未经验证的产出。”
工程领导者的战略问题是，他们组织中的智能体是在闭环还是开环中运行。一个 能编写代码 并在内部循环中针对完整系统进行验证的智能体，是工程吞吐量的力量倍增器。而一个只能编写通过基本测试的代码的智能体，则是那些本已成为最大瓶颈的验证环节的负担倍增器。
这正是我们在 Signadot 努力的方向，通过轻量级的临时环境，在内部循环中为智能体提供生产级的信号。无论组织采用哪种方法，更广泛的观点依然成立：闭环是改变智能体生成代码经济效益的关键能力。
智能体代码大爆发已至。问题在于，是你的智能体在闭环工作，还是你的流水线被要求为它们闭环。
