软件工厂、Agent 就绪度与自主性成熟度:Factory CTO 深度拆解前向部署工程

https://www.youtube.com/watch?v=wpOA-UXynoM

这篇演讲来自 Factory 的联合创始人兼 CTO Eno Reyes，主题是前向部署工程（Forward Deployed Engineering）在 AI 时代的定位、角色演变，以及 Factory 如何做这件事。以下是详细总结：

一、前向部署工程的背景

• 前向部署工程是当前 AI 领域最热门的议题之一。OpenAI、Anthropic、Google DeepMind 等头部公司都在组建大规模的前向部署团队。
• 这一模式最早由 Palantir 开创：把强软件工程师直接嵌入客户组织，围绕真实世界的复杂性来实施和定制平台。
• 如今这一角色已经分化，出现了多种称呼和模式：前向部署工程师、部署工程师、应用 AI 工程师等。大家常常搞不清楚他们到底是在做专业服务、围绕单个客户改造产品，还是在客户环境中从零构建新东西。

二、Factory 的立场：不做专业服务，做产品的“矛尖”

• Factory 明确不想替客户做专业服务工作。比如客户说“我要现代化一个代码库，咨询公司报价多少，你们能不能替我们做”，Factory 的目标不是真的去替客户完成迁移，即使过程中会用到自己的产品。
• 原因：专业服务虽然能带来不错的收入，但无法让产品变得更好，也无法让业务大规模扩张。
• Factory 的选择是：让部署工程师成为产品的矛尖。
• 部署工程师是来自最大、最关键客户的信息流：包括工程领导层、一线战术工程师，以及他们对软件开发和 AI 在该组织中实际如何发生的思考。
• 这些信息回流到产品中，让产品快速调整，更好地适配客户环境。
• Factory 的产品被部署到客户环境中后，应当能够自动组装（self-assembled）。面对 4.5 万人、数十万工程师、数万个代码库的组织，必须自动组装，不能手动安装。

三、软件工厂：信号进，结果出

• Factory 给客户提供的是一套构建“软件工厂”的积木。
• 所谓软件工厂，是每个组织都隐含运行的一个流程：
1. 信号流入
   ：客户对话、bug 报告、内部 Slack/Teams 对话、高管说“我们要做这个”等。不同信号权重不同。
2. 人类优先排序、分诊、制定计划
   。
3. 软件开发者把计划转化为变更
   ，进入代码库或工程系统这个“真相来源”。
4. 验证阶段
   ：代码审查、QA、安全评估、自动化验证（SAS 工具、linter、类型检查器等）。
5. 发布部署
   。
6. 已部署的软件产生更多信号
   ，形成反馈循环。
• 问题在于：这个隐式反馈循环在大多数组织中被极其糟糕地度量。
• 如果能用 AI 改造流水线的每个阶段，并理解每个阶段之间的工作流，就能实现从信号到部署的全流程无人类干预。
• 注意：这并不意味着人类不参与工程系统，而是信号到部署的流动不被人类打断。
• 软件工厂不是凭空出现的，需要组织投入。Factory 的理念是：这是“造出来”的，不是“买来”的。

四、为什么你要拥有 Agent Harness

• Factory 提供的是规范的、模型无关的 agent harness，这是构建软件工厂所需的核心。
• 如果选择 vendor-locked 方案，只有单一模型可用：
• 昂贵；
• 存在模型独立性问题：模型提供商可能决定你能或不能用软件工厂构建什么；
• 如果你不拥有 traces、数据以及流经软件工厂的一切，未来想演进软件工厂就会遇到麻烦。
• Factory 的 harness 叫 Droid：
• 模型无关；
• 你可以访问流经 Droid 的每一份数据；
• 企业层有集中治理和控制，决定什么信息流向哪里；
• 可以气隙部署（airgap）。金融、医疗、政府等最安全的环境会气隙部署 Droid，完全在内部运行软件工厂。有部署工程师开玩笑说“你甚至可以在潜艇里跑 Droid”，这是真的。

五、部署工程师的角色

部署工程师需要：

• 理解这种新的软件构建模式；
• 理解各种积木和组件；
• 帮助客户团队构建和搭建软件工厂；
• 最终让产品能够一键自动组装进客户环境；
• 在闭环末端，从一开始就有清晰的 ROI 或结果故事。

例如：

• 每个经过 AI 代码审查、AI QA、AI 安全分析的代码变更，命中 bug 的概率可能降低 87%；
• 这意味着 bug 率降低 X，客户满意度提升 Y，进而带来收入、增长或新业务；
• 必须有东西从软件工厂流程流向核心业务目标。

这通常是一个复杂的故事，需要工程知识，也需要商业知识。

六、自主性成熟度模型

• 大多数组织没有自主性成熟度模型，没有路线图，不知道真正构建自主软件组织意味着什么。
• 人类在这个世界中的角色非常清晰：演进、精炼和扩展软件工厂。
• 工程师从直接操作软件，转变为直接维护和管理一个“构建软件的系统”。
• 这种抽象层级的提升非常困难，即使是非常有思想的软件工程师也会有学习曲线。
• 适合的人：
• DevX 背景、已经在思考如何赋能其他开发者的人；
• 想快速变得非常技术化的产品经理；
• 习惯在高质量开发环境是优先事项的团队中工作的人。

七、让代码库为 Agent 做好准备

• 大多数组织在确定性验证循环方面有一定一致性：linter、类型检查器、安全扫描、端到端测试等，通过或不通过。
• Agent 就绪度
  衡量的是代码库中存在多少这样的确定性验证循环。
• 反馈循环越多，agent 就能在更复杂的任务上运行更长时间而无需人类干预。
• Factory 有一个产品叫 Missions：
• 一个极其精细的 harness，围绕“极难但可验证的知识工作问题”构建；
• 长时间运行的先进 agent harness，除了规划阶段几乎无需人类干预；
• 你定义一个有界任务，说明“解决这个任务意味着什么”，然后推动推理杠杆直到任务完成；
• 对于“完成是可验证的”问题，它极其强大。
• 已经看到的案例：
• 完全自主迁移 4000 万行代码库；
• 生物医学、医疗健康领域的深度学习策略；
• 金融机构优化股票研究，构建不同股票的模型，分析、比较，并在此基础上回测或交易。
• 但这不是下载、安装、按播放就能用的。需要 agent 就绪度。如果代码库没有 agent 就绪，就看不到当今最强 AI 系统的成功。
• 因此部署工程师要帮助客户：解决这个非常困难的问题，需要一种不同的投资形式——不是更多地去解决问题，而是准备环境以便验证问题。
• 这也符合模型训练的方式：模型在后训练复杂任务时获得密集奖励，验证信号构成奖励基础，让模型在长期目标导向的问题上保持正轨。

八、未来城市类比

• 类比 Walt Disney 的 Epcot：
• Disney 最初想创建一个总体规划的示范城市，说“如果我能创建一个未来城市，就能把它作为模型，让世界其他城市发展出全新的交通方式和繁荣”。
• 结果它变成了主题公园。
• 但有趣的是，在那个小例子中，很多其他城市实际上采纳了他写下和分享的一些关于集中城市交通的想法。过去 50 年建的一些当代城市，基本模仿了那个玩具示例。
• Factory 想要的是：
• 如果有一个“未来城市”“未来代码库”的工作示例，聪明的人类会看到并说“这很酷，让我们把它带到我们代码库的部分”。
• 但如果构建得太先进，人们会说“那是主题公园，和世界其他地方完全不一样，我看不出怎么应用到我们今天的工作方式”。
• 所以需要微妙的平衡：构建一个足够证明未来可实现、但又不会吓跑组织的示例。
• 引用：“未来已经到来，只是分布不均。”
• 有些代码库——不是公司，是代码库——真正非凡，实际上开始运行在自动驾驶上。
• Factory 自己大约有 15% 到 20% 的“自主性”，自主比率在 80% 多。自主比率指的是人类与 AI 系统在中断前完成的操作比例。
• Factory 自己的代码库相当 agent ready、自主。但一些客户的代码库实际上更自主，因为它们以更受约束的方式运行。
• 谁先获得 100% 自主性并不明显。可能是非常受限的内部工具，比如 Factory 的 Legal Droid，法律工作流实际上 100% 自主维护。
• 但核心 harness 还没有验证器能验证一些硬视觉问题，比如基于终端的 harness 中的闪烁，很难可验证地捕捉。所以无法闭环。构建能验证这些非常困难问题的系统是一项工程任务。

九、谁适合做这个

• 前创始人
  ：应该做这个。这是快速构建的好方式。Droid 的每个 SDLC 阶段——代码审查、事件响应、QA、测试——Factory 认为都是十亿美元级业务。
• 擅长技术和沟通的人
  ：
• 流利使用 AI；
• 知道如何与各个层级对话；
• 有商业敏锐度和高管气质。
• 系统思考者
  ：
• 喜欢设计系统；
• 喜欢闭环；
• 喜欢建模数据；
• 理解在潜在极其复杂的组织中流动应该是什么样子。

十、联系方式

• 如果感兴趣，可以直接联系 Eno：eno@factory.ai。
• 或者在 Factory 招聘页面申请，职位叫 Engineer, Deployed。

核心要点总结