构建智能体软件工厂，为什么要从“传感器”开始

顶尖工程团队与钟形曲线其余部分之间的交付速度差距由来已久。在软件行业的大部分历史中，这个差距是以每周部署次数来衡量的倍数。智能体正把这个倍数变成指数，而分界线不再是工具或人才。关键在于团队是否已将交付系统重建为业界如今所称的“软件工厂”——一个基本自主的系统：意图输入其中，智能体负责规划、编写、测试并交付变更。人负责规格说明和关卡。

Anthropic 本月为这一差距给出了具体数字。5 月，该公司每天合并约 2,500 项代码变更，到 9 月，每天合并的变更超过 30,000 项。他们写道，编码不再是瓶颈。瓶颈变成了为人类规模而构建的开发者基础设施，他们现在要问：当数千项变更在测试仍在运行时就被合并，持续集成（CI）究竟还意味着什么。

“智能体正把这个倍数变成指数，而分界线不再是工具或人才。关键在于团队是否已将交付系统重建为业界如今所称的‘软件工厂’。”

要做到这一点，就需要围绕一个问题重新思考交付生命周期：工厂如何在下一次上千项变更叠加其上之前，知道某项变更确实有效？把它看作一个控制回路：意图是设定值，智能体是控制器，验证是传感器。跑得比传感器更快的控制器并不会更快。它会基于过时信息重试，并交付传感器本应捕获的失败。传感器决定了工厂有多少部分可以自主运行。

智能体软件工厂由什么构成

大多数人采用的是 Addy Osmani 的定义：软件工厂是许多受约束的回路同时运行，由工作队列供给，并通过评审关卡排入生产，而人类从上方掌控全局。

意图是说明“完成”意味着什么的规格、工单和场景。队列保存待办事项。约束框架用工具、上下文和规则来约束每个智能体。生成是编码智能体。验证是测试、场景运行和运行时检查，它们在变更合并前报告其是否有效。评审关卡是人或策略允许变更合并的地方。集成和部署将其推送到生产，而生产反馈把遥测和事故带回队列。

智能体改变了控制器，传感器也必须随之改变

智能体在两个地方改变了生命周期。它们增加了一个生成步骤，因此后续阶段接收变更的速度与智能体编写变更的速度一致；它们还把验证从一个人们等待的阶段，变成了智能体在自己的循环内部调用的服务。

“跑得比传感器更快的控制器并不会更快。它会基于过时信息重试，并交付传感器本应捕获的失败。”

控制工程师把传感器安装在运行中的系统上是有原因的：这是唯一能反映系统实际行为的读数。传统生命周期在每个阶段都用更廉价的替代品勉强应付——提交时的单元测试、CI 中的集成测试、发布前的共享预发布环境以及发布后的遥测——因为对每项变更都读取真实系统既慢又昂贵。每个阶段都以保真度换取速度，而只要由人来设定节奏，这种取舍就成立。

一个花两天做一项变更的开发者，几乎不会注意到预发布环境花了四个小时才给出报告。一个四分钟就写完变更的智能体，要么等待——这浪费了速度——要么带着它能看到的任何信息继续推进。它能看到的取决于它能访问的环境和测试，而对许多团队来说，那就是单元测试和模拟。

Dan Shapiro 的 AI 编码五个层级，若以每一层由什么来验证代码来解读，就是一部传感器的阶梯。在第 3 层，智能体编写代码，而你整天审查差异，这几乎是所有人能达到的上限。在第 4 层，测试就是传感器，而这是否安全取决于测试针对什么运行。

StrongDM 的两条规则——代码不得由人类编写，也不得由人类审查——确实引起了关注。使其可行的是它的数字孪生宇宙：其第三方依赖的行为克隆，智能体针对其运行数千个场景。这就是在流水线中加入智能体与运行一座工厂之间的分界线。规则可以免费照搬，但传感器才是昂贵的部分，也正是它给人留下了位置：负责意图和架构之类的慢循环，而不是充当比人阅读速度快一百倍的控制器逐项变更的检查员。

传感器有三个属性，而工厂三者都需要

延迟

延迟是传感器报告所需的时间，而延迟会破坏回路的稳定。变更与其信号之间的每一个动作，都建立在一个已不复存在的状态之上，于是智能体基于未经验证的变更重试，其他智能体又在此基础上继续构建。要跟踪信号时间：从变更就绪到在类生产环境中获得已验证结果所需的分钟数。

保真度

保真度是指读数与真实系统的接近程度，它比延迟更重要，因为回路信任的是一个有偏差的传感器。单元测试和模拟报告的是变更针对其依赖模型所产生的影响，而智能体会针对传感器所奖励的任何东西进行优化。StrongDM 发现其智能体会返回 true 以通过范围狭窄的测试，于是它把场景移到代码库之外，作为留出集。需要跟踪的数字是逃逸率，即合并后才发现失败的占比。

带宽

带宽是指传感器一次能读取多少个读数，而这是智能体最先吃紧的属性。共享预发布环境一次只能读取一个读数，因此当五十个智能体的读数排队或混在一起时，失败就无法归因于某一项变更。这个数字是并发验证容量。

自主性跟随传感器，所以要衡量传感器

工厂能运行的自主性，最多只能达到其传感器所能验证的程度，Osmani 称之为背压。只有编译器和单元测试时，智能体提出方案，人验证一切。在类生产环境中对每项变更进行检查时，智能体在回路中反复迭代，直到变更得到验证，人则审查意图和证据。Anthropic 的工程师仍然审查其代码库的每一项重大变更，但他们审查的是变更确实实现了预期意图的证据，而不是逐行阅读。有了留出场景和快速回滚，定义明确的变更类别可以无需审查就合并。

“工厂能运行的自主性，最多只能达到其传感器所能验证的程度。决定水平的是传感器，而不是模型。”

决定水平的是传感器，而不是模型。在有偏差的传感器上使用更好的控制器，只会更快地得出错误答案；而审查每一项变更也是一种传感器，其延迟以小时计，带宽为每位审查者每天几项变更。

所以要衡量传感器，而不是智能体的努力。拉取请求数和每位工程师的 token 数衡量的是智能体工作有多努力。信号时间、逃逸率和并发验证容量告诉你哪项属性薄弱，而变更失败率和返工率告诉你回路是否稳定。从这三项开始。

云原生系统让传感器更难

在分布式系统中，行为会跨越服务边界而出错。一个服务中重命名的字段，另一个团队的服务仍在读取。一个消费者假定其主题并不保证的顺序。每项变更在自己的边界内是正确的，组合起来却是错误的，因此忠实的传感器必须包含变更周围的真实服务。这正是三项属性难以同时具备的原因：保真度意味着真实的邻居，而延迟和带宽意味着要为每项变更在几分钟内提供一个拥有这些邻居的环境。大多数团队只能做到三项中的两项。

在共享环境上验证一批拉取请求只能获得保真度，别无其他。环境是真实的，但它一次只能读取一个读数，并在变更后数小时才报告，处于任何智能体回路之外。为节省时间而在一次运行中测试多项变更，会使失败无法归因，于是智能体无法对红色结果采取行动。

为每项变更复制整个技术栈或其大部分，能提高保真度和隔离性，但会增加延迟和带宽成本。预配需要数十分钟，远长于智能体的一次尝试，而且成本随每个并发智能体增长，因此团队会把它配给值得这样做的变更。行为孪生适用于具有稳定公开行为的第三方服务。然而，对于 150 个内部服务，克隆是第二套实现，会逐渐漂移，而真实服务已经在集群中运行。

在规模化时，工厂需要一种方式，为每个智能体和每项变更提供一个真实的环境，让真实服务应答其调用，同时不承担复制技术栈的成本或延迟。这样的传感器满足全部三项属性，而这正是我们构建 Signadot 所要实现的那种模型。

为智能体重新思考 SDLC，要从传感器开始

每天合并 30,000 项变更的团队与其他团队之间的差距，不在于智能体，因为现在人人都有智能体。差距在于一个围绕传感器重建的交付系统，该传感器能在几分钟内报告、与真实系统匹配，并同时为每项变更运行。

在云原生系统上，这个传感器是最难构建的部分，它决定着更多智能体是交付更多软件，还是只会破坏更多软件。要了解完整架构，请参阅我们关于云原生系统软件工厂的完整指南。

文章《构建智能体软件工厂？从传感器开始。》最初发表于 The New Stack。