夜雨聆风学习资料网

ARTICLE · 1250580

构建智能体软件工厂?从传感器开始.

构建智能体软件工厂?从传感器开始.

本文探讨了构建智能体软件工厂的核心不在于AI模型本身,而在于能够提供低延迟、高保真和高并发的验证传感器。传感器决定了系统的自动化程度与稳定性。

译自:Building an agentic software factory? Start with the sensor.[1]

作者:Arjun Iyer

长期以来,最优秀的工程团队与其余团队在发布速度上一直存在一条鸿沟。在行业历史的大部分时间里,这个差距是通过每周部署次数的倍数来衡量的。而智能体(Agents)正在将这个倍数变成指数,分水岭不再是工具或人才,而是团队是否将交付系统重建为行业现在所称的“软件工厂”——这是一个高度自主的系统,意图输入其中,智能体负责计划、编写、测试和发布变更。人类则掌控规范和把关机制(gates)。

Anthropic 本月用数字量化了这一差距。5月,该公司每天合并约2,500个代码变更,到了9月,合并数量超过了30,000个[2]。他们写道,编码不再是瓶颈,瓶颈变成了为人类规模构建的开发者基础设施。他们现在甚至开始质疑,当数千个变更在测试仍在运行的同时被合并时,持续集成[3](CI)究竟意味着什么。

“智能体正在将这个倍数变成指数,分水岭不再是工具或人才。而是团队是否将交付系统重建为行业现在所称的‘软件工厂’。”

要实现这一点,意味着需要围绕一个问题重新思考交付生命周期:工厂如何在成千上万个新变更叠加之前,知道某个变更确实有效?将其视为一个控制回路,意图是设定点(setpoint),智能体是控制器,而验证则是传感器。跑得比传感器更快的控制器并不会变得更快。它会在陈旧的信息上不断重试,并发布那些本该被传感器捕获的失败变更。传感器决定了工厂能有多大程度的自主运行。

智能体软件工厂的组成部分

Addy Osmani 的定义是大多数人都在使用的定义:软件工厂是许多同时运行的受控循环,由工作队列提供动力,并通过评审门控流向生产环境[4],人类则在最高层掌控全局。

意图是规范、工单和场景,它们定义了“完成”的含义。队列保存待办事项。工具环(harness)通过工具、上下文和规则约束每个智能体。生成就是编写代码的智能体[5]。验证则是测试、场景运行和运行时检查,它们在变更合并之前报告其是否有效。评审门控则是人或策略允许变更合并的地方。集成和部署将其推向生产环境,生产环境的反馈则将遥测数据和故障带回队列中。

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

智能体在两个地方改变了生命周期。它们增加了一个生成步骤,使后续阶段以智能体编写的速度接收变更;同时,它们将验证从人们等待的阶段转变为智能体在其自身循环内部调用的服务。

“跑得比传感器更快的控制器并不会变得更快。它会在陈旧的信息上不断重试,并发布那些本该被传感器捕获的失败变更。”

控制工程师将传感器安装在运行中的系统上是有原因的:它是唯一能反映系统实际运作情况的读数。传统的生命周期在每个阶段都凑合使用廉价的替代品(提交时的单元测试、CI 中的集成测试、发布前的共享预发布环境以及之后的遥测),因为为每个变更读取真实系统既慢又昂贵。每个阶段都用保真度换取了速度,而当节奏由人类掌控时,这种权衡还能维持。

一个花了两天时间处理变更的开发者几乎不会注意到预发布环境花了四个小时才给出报告。而一个在四分钟内写完变更的智能体要么只能等待(这就浪费了速度),要么就只能利用它能看到的任何信息继续前进。它能看到什么取决于它能访问的环境和测试,对于许多团队来说,那只是单元测试和模拟(mocks)。

Dan Shapiro 的 AI 编码五级分类,如果根据每个阶段验证代码的方式来看,其实就是一个传感器阶梯。在第3级,智能体编写代码,你整天都在审查代码差异(diffs),这也是几乎所有人的上限所在[6]。在第4级,测试就是传感器,而这是否安全取决于它们针对什么进行测试。

StrongDM 的两条规则[7]——代码绝不能由人类编写,也绝不能由人类审查——无疑受到了广泛关注。让这些规则可行的是其数字孪生宇宙(Digital Twin Universe),即第三方依赖项的行为克隆,智能体会在其上运行数千个场景。这就是将智能体添加到流水线与运行软件工厂之间的分水岭。规则可以免费复制,但传感器才是昂贵的部分,它赋予了人类应有的位置:专注于意图和架构等慢循环,而不是充当比人类阅读速度快百倍的控制器的逐个变更检查员。

Flow diagram of the software factory control loop.

传感器具备三个属性,而工厂需要这全部三个属性

延迟

延迟是指传感器报告所需的时间,而延迟会破坏循环的不稳定性。变更与其信号之间的每个动作都依赖于一个不再存在的状态,因此智能体会基于未经验证的变更进行重试,其他智能体也会在此基础上构建。追踪获取信号的时间:从变更就绪到在类生产环境中获得验证结果的分钟数。

保真度

保真度是指读数与真实系统的匹配程度,它比延迟更重要,因为控制循环会信任有偏差的传感器。单元测试和模拟报告的是变更针对其依赖项模型表现出的行为,智能体会为了传感器奖励的任何指标进行优化。StrongDM 发现其智能体在狭隘的测试中返回 true 以通过测试,因此它将场景移至代码库之外作为保留测试集(holdout set)。需要追踪的指标是逃逸率(escape rate),即合并后发现的故障比例。

带宽

带宽是指传感器可以同时获取多少读数,这是智能体首先吃不消的属性。共享预发布环境一次只能读取一次,因此当五十个智能体的读数排队或混合在一起时,故障就不再能归因于某个特定的变更。这个指标就是并发验证能力。

自主性取决于传感器,因此请衡量传感器

工厂能够运行多大程度的自主性,取决于其传感器能够验证多少,不能超过这个限度——Osmani 将其称为背压(back pressure)。如果只有编译器和单元测试,智能体提出方案,人类验证一切。如果在类生产环境中有逐个变更的检查,智能体会进行循环迭代,直到变更得到验证,而人类则审查意图和证据。Anthropic 的工程师仍然会审查代码库中的每个重大变更,但他们检查的是证明变更符合预期的证据,而不是阅读每一行代码。通过保留场景和快速回滚,特定类别的变更可以在无需审查的情况下合并。

“工厂能够运行多大程度的自主性,取决于其传感器能够验证多少。是传感器而不是模型,决定了自主级别。”

是传感器而不是模型,决定了级别。在有偏差的传感器上使用更好的控制器只会更快地得出错误答案,而审查每个变更也是一种传感器,其延迟以小时为单位,带宽为每个审核员每天只能处理几个变更。

因此,请衡量传感器,而不是智能体的工作量。每个工程师的拉取请求(Pull Requests)和 Token 数量只能说明智能体有多努力。而获取信号的时间、逃逸率和并发验证能力则能告诉你哪个属性较弱,变更失败率和返工率则能告诉你循环是否稳定。从前三项开始。

云原生系统使传感器变得更难

在分布式系统中,行为会跨越服务边界而破碎。一个团队的服务仍在读取另一个团队服务中被重命名的字段。某个消费端假设了其主题(topic)无法保证的顺序。每个变更在自身的边界内是正确的,但在组合时却是错误的,因此高保真的传感器必须包含变更周围的真实服务。这就是为什么很难同时获得这三个属性的原因:保真度意味着真实邻居,而延迟和带宽意味着在几分钟内为每个变更提供包含这些邻居的环境。大多数团队只能三者得其二。

在共享环境上一气呵成地验证一批拉取请求只能获得保真度,除此之外别无他物。环境是真实的,但它一次只能读取一次,并且在变更发生数小时后才报告,完全超出了任何智能体的循环范围。为了节省时间而在一次运行中测试多个变更,会使故障无法归因,因此智能体无法对红色(失败)结果采取行动。

为每个变更复制完整的堆栈(或其很大一部分)可以改善保真度和隔离性,但会增加延迟和带宽成本。配置需要十几分钟,远比智能体的尝试时间长,而且成本随并发智能体的增加而增长,因此团队只能将其配给给那些值得这样做的变更。行为孪生(Behavioral twins)适用于具有稳定公共行为的第三方服务。尽管如此,对于150个内部服务来说,克隆就是第二个实现,当真实服务已经在集群中运行的同时,它会发生漂移。

在大规模情况下,工厂需要一种方法来为每个智能体和每个变更提供一个逼真的环境,让真实服务能够响应其调用,而无需承担复制堆栈的成本或延迟。这种传感器满足了所有三个属性,这也是我们构建 Signadot[8] 模型的原因所在。

A diagram showing the various software factory sensor approaches.

围绕传感器重新思考面向智能体的 SDLC

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

在云原生系统[9]上,这种传感器是最难构建的部分,它决定了更多的智能体是会发布更多软件,还是只会破坏更多软件。有关完整的架构,请参阅我们针对云原生系统的软件工厂完整指南[10]。

引用链接

[1] Building an agentic software factory? Start with the sensor.: https://thenewstack.io/agentic-software-factory-sensor/[2] 5月,该公司每天合并约2,500个代码变更,到了9月,合并数量超过了30,000个: https://www.anthropic.com/engineering/redesigning-source-control[3] 持续集成: https://thenewstack.io/ci-bottleneck-agent-verification/[4] 许多同时运行的受控循环,由工作队列提供动力,并通过评审门控流向生产环境: https://addyosmani.com/blog/software-factories/[5] 生成就是编写代码的智能体: https://thenewstack.io/5-key-trends-shaping-agentic-development-in-2026/[6] 你整天都在审查代码差异(diffs),这也是几乎所有人的上限所在: https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/[7] 两条规则: https://factory.strongdm.ai/[8] Signadot: https://www.signadot.com/?utm_source=tns&utm_medium=paid_sponsorship&utm_campaign=q4_26_sponsored_content&utm_content=software-factory[9] 云原生系统: https://thenewstack.io/agent-loops-cloud-native-verification/[10] 针对云原生系统的软件工厂完整指南: https://www.signadot.com/software-factory/?utm_source=tns&utm_medium=paid_sponsorship&utm_campaign=q4_26_sponsored_content&utm_content=software-factory

相关学习资料