探索如何构建AI软件工厂系统,从工作摄入到最终合并,掌握自动化代码生成的五个核心阶段与审查瓶颈,提升研发效能
人工智能正在以惊人的速度重塑软件工程的传统边界。过去,代码的编写是开发者的核心使命,而现在,随着强大的编码代理加入战场,代码的生产效率已经被提升到了前所未有的高度。斯蒂芬·图布在三万五千英尺的高空,仅凭一部手机就开启了九个拉取请求,其中七个成功合并,这个故事生动地揭示了当前的行业现状。一个具备良好判断力的工程师,借助手机上的编码代理,其生成拉取请求的速度已经彻底超越了团队人工审查的极限。人工智能改变了代码生产的经济学,真正引人深思的问题已经不再是如何让代理编写代码,而是如何去吸收它们产生的大量产出。正是在这样的背景下,AI软件工厂的概念应运而生,它成为了将自主编码代理从一场技术演示转化为团队可以真正消化的吞吐量的关键。
要理解什么是AI软件工厂,我们必须首先厘清它与单一代理的本质区别。AI软件工厂并非代理本身,而是围绕编码代理构建的整个系统化基础设施。在这个系统中,工作从队列中自动到达,代理在隔离的工作空间中运行,验证过程完全自动化,而人类则只在明确的合并门前进行最终的决策。在你的笔记本电脑上运行编码代理,仅仅是拥有一个代理,你依然需要自己选择任务,注视它的工作过程,阅读代码差异并手动合并,除了打字之外,一切仍由你掌控,你的注意力始终是最大的瓶颈。而软件工厂则将这些步骤全部转移到了基础设施之中。没有人决定代理应该挑选哪个问题,因为摄入规则会自动筛选;没有人需要手动设置工作空间,因为隔离环境会被自动配置;没有人需要检查更改是否能编译,因为验证会在人类介入之前全面运行。
人只会在最后出现,专门负责那些承载问责的决策。构建一个真正的软件工厂,需要经历五个核心阶段,每一个阶段都有一扇关键的门锁控制着流程的推进。这五道门分别是工作摄入、环境隔离、工具赋予、验证审查以及合并放行。每一道门都在阻止工作流向下一阶段,而最昂贵的阶段往往被安置在最后端。这种设计不仅是为了效率,更是为了在失控之前拦截错误。第一阶段是工作摄入,它决定了什么才是值得启动的工作。
如果这一步出现偏差,所有下游阶段都将在根本不值得开始的任务上白白消耗昂贵的令牌。最为朴素的做法是将代理分配给每一个开放的问题,但真正成熟的系统都会首先进行严格的过滤。Sentry的Seer系统为每一个传入的错误进行行动性评分,只对那些越过门槛的问题进行深入调查。Shopify则采取了不同的策略,通过Slack路由所有的摄入请求,并确立了一条不可动摇的规则:代理只在公共频道中工作,绝不回应直接消息。Shopify的CEO图比·卢特克曾明确表示,代理不会回应私信,而是礼貌地拒绝并建议创建公共频道。这种约束并非出于技术考量,而是基于组织层面的深思。
一个私有的代理会话只能教会一个人,并且会随着窗口的关闭而彻底消亡,而公开的会话则能让任何团队成员随时加入并获取知识。在摄入阶段,还有一道至关重要的门是重复检测。在个人开发中,检查是否有人已经修复了某个问题是锦上添花;但在像斯德哥尔摩银行每周合并一千三百个代理PR的巨大规模下,在已经解决的问题上生成代理,正是软件工厂存在所必须消除的浪费。第二阶段是选择隔离模型。两个代理同时编辑同一个工作目录,是浪费一整天的最快方式。这也是大多数自建的软件工厂在此停滞不前的原因,因为看似完美的方案往往在第四个并发代理出现时就会失效。
隔离模型大致分为三种,成本与能力递增。工作树是最基础的起点,它是一个拥有独立分支的第二个工作目录,与原仓库共享代码。这种方式适合在一台机器上运行两到五个代理,但如果代理数量增加,就会面临端口冲突、数据库竞争等共享资源的问题。容器则提供了更强的隔离,它隔离了文件、依赖、网络和进程,特别适合处理冲突的依赖版本和不受信任的代码更改。而云沙箱则达到了隔离的顶峰,它隔离了包括资源在内的一切,并提供了无限的并发能力,是舰队规模部署的必然选择。值得注意的是,每个工作树都是一个全新的检出环境,这意味着你的环境变量、依赖库以及空闲端口都不在其中。
这往往是导致代理数量增加时系统崩溃的真正原因,而非工作树本身无法扩展。第三阶段是赋予代理双手,而不仅仅是一个大脑。一个仅仅拥有仓库访问权限的模型,只是一个高级的自动完成工具;而一个能够调用测试运行器、访问遥测数据、控制功能标志并操作部署工具的模型,则成为了真正的同事。这两者之间的差距正是工具层,这也是软件工厂中最不引人注目却最具决定性的阶段。行业领导者对这一层的重视程度从数据中可见一斑,斯德哥尔摩的Toolshed在内部托管了大约五百个内部工具,Cloudflare运行着内部MCP门户并生成了跨越数千个仓库的指令文件。这一层的核心杠杆在于它是整个舰队的统一配置,而非每个代理的单独设置。
一个统一的模型上下文协议块可以触及每一个代理。在典型的工厂工具层中,测试和运行器负责回答代码是否能构建和通过,遥测系统负责回答是否在生产中引发了错误,功能标志控制某条路径是否真正开放,生态文档则确认某个API是否依然有效。第四阶段是验证,这也是软件工厂真正体现出差异的地方。每个软件工厂都能生成代码,但区分它们的,是代码生成之后到人类看到之前所发生的一切。这一阶段包含了最多反直觉的已发布结果。斯德哥尔摩的反馈循环结构最为清晰:内层循环由仓库中的确定性验证器组成,自动选择格式化、编译和测试工具,完全不涉及模型;法官环节则由模型评估差异是否保持在范围内,它否决了大约百分之二十五的代理会话,其中约一半可以通过纠正代理来恢复,而不是直接丢弃工作;外层循环则是CI和PR检查。
失败模式的排名极具参考价值:一个失败的PR生成只是烦恼,一个失败的PR是工程师的负担,而一个通过了CI却在功能上是错误的PR,则会侵蚀整个系统的信任。因此,设计应当朝向第一个失败演进,并远离第三个失败。在验证阶段,有一个极其宝贵的负面结果值得警惕,那就是信心分数陷阱。Faire构建了一个内部审查器,并尝试了最直观的质量杠杆:按照模型自身的信心分数来过滤评论。然而,这一招完全失效。在最严格的门禁下,百分之六十五的评论被直接丢弃,而接受率几乎没有变化。
数据显示,一个得分零点九三的评论被抛弃,而得分零点三五的评论却被接受并修复。真正提升接受率至百分之七十三的,是关于更改的更好背景信息,以及更精准地定位哪些评论值得提出意见,并用模型分级门替代确定性阈值。自报的信心分数从来不是质量信号。第五阶段是合并门,这是写得太少却决定软件工厂是资产还是负债的阶段。问题不在于代理是否可以打开PR,而在于在PR着陆之前必须满足什么条件。已发布的策略按爆炸半径分为不同层级。
机械性且可逆的更改,如依赖升级或代码格式调整,可以由自动化检查自动合并;范围受限的功能或修复,需要一个人类审查;代理撰写的非实质性更改,如触碰产品行为的代码,通常需要两个人类审查;而涉及认证、支付、数据删除等领域的敏感更改,无论作者是谁,都需要指定的领域所有者进行审查。Faire的规则最为具体,要求代理撰写的PR必须经过两次审查,且在拉取领域专家之前必须先有一个审查,以避免代理将专家拉入未完成的工作中。归因问题同样不容忽视。Linux内核的二零二六年政策规定,AI代理不能添加签名行,因为该声明是模型无法做出的法律断言,而是要求使用辅助行来标明代理和模型版本。GitHub则采取了另一条路,通过代理总部来管理代理身份,就像管理人类开发者一样。这两种做法都有其合理性,但保持沉默是不可取的,因为半年之后没有人能回答哪些更改来自何处。
极端的一端是OpenAI的Codex团队,他们报告说在内部项目上人类可能审查PR,但并非必须,代理经常自行压缩并合并PR,团队已经将几乎所有审查努力转向代理到代理的处理。但这是建立在全新代码库且无外部用户的背景下,在采纳这种做法之前必须深思熟虑。数据揭示了这些系统背后的真实状况。代理PR合并的频率明显低于人类PR。微软长达十年的dotnet/runtime审查是唯一具有同类比较的公共数据集。数据显示,代理PR合并了百分之六十七点九的时间,而微软工程师则为百分之八十七点一。
自主性的分裂更为剧烈:收到人类提交的PR合并率高达百分之八十六点二,而完全自主的PR仅为百分之五十五点一。回滚率保持稳定,说明最终合并的代码质量并没有明显下降。通过测试并不等同于可合并。METR让来自热门开源项目的维护者审查了已经通过自动评分器的AI拉取请求,结果大约一半不会被合并,通过评分器与实际合并之间存在约二十四百分点的差距,且这一差距并未随模型迭代而缩小。吞吐量和不稳定性往往同时上升。DORA的报告发现,AI采用与更多的交付吞吐量以及更多的交付不稳定性相关联,这表明AI是组织既有状态的放大器。
数量也带来了维护成本,代码重复率上升,重构比例下降,损耗增加。与这些挑战相对的是,采纳的数字是真实且庞大的。Shopify报告了数以万计的代理会话和合并的PR,Ramp在没有强制要求的情况下达到了合并PR的百分之三十。Airbnb在六周内迁移了约三千五百个测试文件,这原本需要一年半的人力。然而,软件工厂面临的最大瓶颈始终是审查容量。生成速度随着算力支出而扩展,但审查速度却无法同步。
OpenAI的团队曾坦诚,在自动化循环之前,他们每周五都要花费整整一天清理AI产生的废话,这根本无法扩展。斯德哥尔摩的维护者也指出,最长的尾端文件需要数十次重试。开源社区正在吸收这些外部性,当项目暂停外部贡献时,维护者们意识到编写代码已经变得极其容易,真正困难的工作变成了审查。构建AI软件工厂的最终建议是,从一个门开始。不要急于构建整个舰队或编排器,而是选择你的代理目前产生最多返工的阶段,并在那里放一道门。这篇文章中提到的每个成功架构都是如此组装起来的,而那些试图直接跳到数量的公司,往往就是那些在周五晚上清理废代码的人。
在未来,软件工厂将不仅仅是生成代码的机器,它将成为企业核心的生产力引擎,重新定义工程团队的价值与协作方式。 。
