欧易数字货币交易所 更快、更好、更强

软件开发这件事正在被重新拆分，再重新拼回去，只不过拼接方式不再围绕“人写代码”，而是围绕“系统自己完成交付闭环”。

Factory这次推出的2.0版本，叙事很直接：不再把自己当成开发者辅助工具，而是试图把整条软件生命周期压进一条自动化流水线里。从需求理解、代码生成，到测试、安全扫描，再到上线和运行监控，链路被尽可能压扁。

听上去像“全自动开发”，但更贴近现实的说法可能是——把原本分散在不同角色、不同工具里的决策点重新收拢，然后交给系统内部的调度机制。

比较有意思的一点，是它没有绑定任何单一大模型。企业可以在不同环节指定不同模型，系统再通过所谓“智能路由器”去分配任务。这种设计有点像云计算早期的多云策略，只不过对象从算力资源换成了模型能力。底层逻辑其实很现实：没有任何一个模型能在所有开发场景里保持稳定优势。

再往下看，会发现它试图解决的不是“写代码效率”，而是“软件生产的组织结构问题”。

比如 bug 处理不再是人工排查日志，而是系统自动定位报告、生成修复方案，然后继续推进后续编译和安全扫描。流程之间的衔接被压缩到几乎没有人为切换点。某种意义上，这更接近制造业里的产线质检闭环，而不是传统意义上的DevOps流程。

但软件和制造的差别在于，代码的“偏差空间”更大。一个小改动可能在运行环境里触发完全不可预测的结果。所以Factory把自主权分了层级：简单修改交给 droid 智能体直接处理，复杂任务则进入“missions”系统，由多个智能体协作拆解。这种结构有点像把工程团队拆成微型自治单元，只是成员变成了模型和代理。

企业侧更敏感的其实不是自动化能力，而是数据边界。

系统支持自带密钥、本地私有化部署，甚至完全物理隔离环境运行。对于NVIDIA、Adobe、Palo Alto Networks这类已经深度依赖内部代码资产的公司来说，代码是否“出内网”往往比效率提升更关键。尤其在安全与合规压力持续增强的背景下，任何涉及源代码外流的工具都必须重新设计信任模型。

从另一个角度看，这种架构其实是在尝试绕开一个现实问题：企业不会轻易把核心研发流程完全交给单一外部模型或平台。于是Factory选择把控制权拆散，变成“可编排的能力层”。

有点像云计算刚兴起时的AWS，但不同的是，这次被拆解的不是服务器，而是开发行为本身。

值得留意的是，它已经进入了一批大型企业的生产环境，包括Adobe、Palo Alto Networks、Ernst & Young、Wipro以及Adyen。这些公司本身就处在不同软件形态之中：金融、咨询、安全、支付、企业服务，各自的开发链条差异很大。

这种分布意味着一个事实：Factory并不是在押注单一垂直场景，而是在尝试覆盖“企业软件生产的共性结构”。如果这一点成立，它对开发工具市场的影响会比单点提效更深。

但问题也并不复杂——当“自动生成+自动部署”成为默认路径之后，责任归属会变得更难拆分。bug是谁引入的，模型？路由器？还是任务拆解层？这些问题在工程层面可以记录，但在治理层面仍然空白。

软件工厂这个词听起来很工业，但软件本身并不完全服从工业规律。Factory 2.0更像是在尝试把不确定性压进结构里，而不是消灭不确定性。效果如何，还要看企业在真实生产环境里愿意放开多少权限。