构建代理式软件工厂？从传感器开始。
内容提要
文章讨论“软件工厂”式交付：AI代理使代码变更量激增，瓶颈转向验证。验证是控制回路中的传感器，需兼顾时延、保真度和并发能力，否则代理会基于过时信息重试并放大故障。团队应衡量变更到验证结果的时间、逃逸率和并发验证容量，而非代理工作量。真实服务环境验证最难，却决定自主程度。
延伸解读
验证是代理式软件工厂的传感器
文章将软件工厂视为控制回路：意图是设定点，代理是控制器，验证是传感器。控制器速度超过传感器时，不会更快，反而会基于过时信息重试并放大故障。因此，团队应关注验证的时延、保真度和并发能力，而非代理的工作量。传感器决定工厂能自主运行的程度，而非模型本身。
三个关键指标衡量验证能力
文章建议衡量三个指标：变更到验证结果的时间（时延）、逃逸率（合并后发现的失败比例）和并发验证容量（带宽）。时延长会导致代理基于未验证变更重试；保真度低会让代理优化错误目标；带宽不足则使失败无法归因。这些指标比PR数或token数更能反映交付系统的健康度。
真实服务环境验证最难但决定自主程度
分布式系统中，变更可能跨服务边界出错，因此高保真验证需要包含真实邻居服务。但真实环境验证往往面临时延和带宽挑战：共享环境一次只能验证一个变更，复制全栈则成本高、耗时长。文章指出，多数团队只能同时满足两个属性，而能同时满足三者的传感器（如Signadot）是软件工厂的关键。
Q&A
什么是“软件工厂”？它和传统交付方式有什么区别？
软件工厂是一种高度自主的交付系统：意图输入后，由AI代理规划、编写、测试并发布变更，人类负责规格和关卡。与传统交付相比，代理使代码变更量激增，瓶颈从编码转向验证，验证成为控制回路中的传感器，决定工厂能自主运行的程度。
为什么说验证是软件工厂的瓶颈？
因为AI代理使代码变更量呈指数增长（如Anthropic从每天约2500次合并增至超过30000次），编码不再是瓶颈，而验证（测试、场景运行、运行时检查）必须跟上代理的写入速度。若验证滞后，代理会基于过时信息重试并放大故障，因此验证能力决定自主程度。
衡量验证传感器好坏应该看哪些指标？
应关注三个核心指标：时延（从变更就绪到生产类环境验证结果的时间）、保真度（验证结果与真实系统的匹配程度，用逃逸率衡量）、带宽（并发验证容量）。此外，变更失败率和返工率可判断回路是否稳定。不要只衡量代理的工作量（如PR数或token数）。
在软件工厂中，人类应该扮演什么角色？
人类负责意图和慢循环（如架构），而不是逐行审查每个变更。人类拥有规格和关卡，审查变更是否达到意图的证据，而非阅读每一行代码。对于定义明确的变更类别，配合保留场景和快速回滚，可以无需审查直接合并。
为什么在分布式系统中实现高保真验证特别困难？
因为行为在服务边界处会断裂：一个服务重命名的字段可能被另一个服务读取，消费者可能假设主题不保证的顺序。每个变更在自身边界内正确，但组合起来可能出错。因此高保真传感器必须包含变更周围的真实服务，而这与低时延、高带宽难以同时满足，多数团队只能做到其中两项。
常见的验证方案（共享环境、批量测试、全栈复制、行为克隆）各有什么局限？
共享环境：保真度高但一次只能一个读取，报告延迟数小时，无法进入代理循环。批量测试多个变更：失败无法归因，代理无法根据红色结果行动。全栈复制：提高保真度和隔离，但配置耗时数十分钟，成本随并发代理增长，只能 ration 给少数变更。行为克隆：适用于第三方稳定服务，但对大量内部服务会漂移，且是第二套实现。
