Factory 如何做前沿部署工程——Eno Reyes

• FDE（forward deployed engineer，前置部署工程师）＝把非常强的工程师直接嵌进客户组织内部，围绕现实里那些微妙细节去落地和定制自家平台。这套打法是 Palantir 多年前开创的，如今 OpenAI、Anthropic、Google DeepMind 都在大规模扩建这类团队。→ 详细
• 它当年之所以必须"派人空降"，是因为有些东西只有掀开客户那层帘子才碰得到——数据流、内部软件、内部产品。你要做深度集成，就只能把人送进去。→ 详细
• 讲者：Eno Reyes，Factory 联合创始人兼 CTO，此前在 Hugging Face 和 Microsoft 做机器学习与软件工程；Factory 为企业团队做自主软件工程 agent，产品叫 Droid。→ 详细

• 现在自称 forward deployed engineer / deployed engineer / applied AI engineer 的人，做的事天差地别，界限一直模糊：替客户做专业服务？围绕单个客户改造产品？在客户环境里从零造新东西？还是只跟人打交道做策略？ Eno 列出的分歧维度是：FDE 在组织里坐哪个位置、跟产品/工程团队的接口多深、多少活是替客户做的 vs 跟客户一起做的、多少落在代码里 vs 落在人身上。→ 详细

• 典型场景：客户说"我要做一次代码库现代化改造，几家大咨询公司都报过价了，你们能接吗？"——Factory 的回答是不接，哪怕用的正好是自己的产品。→ 详细
• 理由有两层：一是替客户干活并不能让产品变好多少；二是"这确实是一条能赚到不少收入的路子，但我不觉得靠它能把生意做到极大的规模"。这是一条关于杠杆的取舍——用收入换产品进化速度，他们选后者。→ 详细

• "矛尖（tip of the spear）"的准确含义：deployed engineer 是一条把最大、最关键客户那边的信息带回来的通道——那个组织里工程领导层的想法、一线战术型工程师的想法、以及他们对"软件开发和 AI 在我们这儿到底是怎么发生的"的真实判断，全部回流进产品，让产品快速调整、更好地嵌进客户环境。→ 详细
• "产品"在这里的范围比你想的大得多：企业级管控、Droid harness、跑在它之上的工作流、可观测性工具、成本管控、模型自动路由、harness 本身的质量——每一项都是潜在改进点，而且"你只有深入到这些千差万别的组织内部去解决问题，才会发现它们"。→ 详细
• 目标状态是 self-assemble（自动装配）：Factory 被部署时，应该能在客户环境里自己装配起来，而不是靠人手工搭。→ 详细

• Factory 卖给客户的不是 agent，是"一套用来搭建软件工厂的积木"。所谓软件工厂，是指世界上每个组织其实都隐含地跑在这么一条流水线上，只是从没被显式画出来过。→ 详细
• 完整五段：① 信号流进来——客户对话、bug 报告、内部 Slack / Teams 里的讨论、某个高管说"我们要做这个"，都是信号，只是权重有高有低；② 人或明或暗地做优先级排序、分诊，围绕信号做出计划；③ 计划由开发者转成对某个事实源（source of truth）的改动——代码库、工程系统；④ 改动走进验证环节：有人 review 代码、做 QA、评估安全影响，再过一遍自动化校验（SAST 安全扫描工具、linter 代码规范检查、类型检查）；⑤ 全部通过就发布上线——而上线并被监控的软件又会产生新的信号，闭环回到第一步。→ 详细
• 关键判断——这个闭环在大多数组织里"可观测性做得非常差"。也就是说，所有公司都在跑这条流水线，但没人知道信号在哪一段丢了、计划在哪一段变形、验证在哪一段被绕过。Eno 的整套论述都建立在这个前提上：先把隐含的流程显式化并装上仪表，AI 才有地方接进去。→ 详细

• 达成条件有两个：用 AI 改造流水线的每一个环节，并且把组织里从每一环到下一环的工作流都梳理清楚——两者缺一不可。做到之后，"从信号到部署整条链路，全程不需要人工介入"。→ 详细
• 一个必须澄清的误解：这不代表人不参与这套系统的搭建。原话是"信号到部署这条流不再被人打断"——人被移出了流水线上的逐笔操作，但没被移出系统的设计与维护。这个区分是后面"人还干什么"那一节的伏笔。→ 详细

• 软件工厂不是打个响指就冒出来的，它需要组织真金白银的投入。Factory 内部的说法是 built, not bought（是"建"出来的，不是"买"来的）——供应商能给的只是积木和那个标准的 harness，工厂本身必须由客户自己建。这也正是 deployed engineer 存在的理由：卖一个需要客户自己动手建的东西，就必须有人进去教怎么建。→ 详细

• 先解释术语：harness＝agent 外面那层运行支架——调度、工具接入、上下文管理、校验、重试这一整套，模型只是插在里面的一个零件。Factory 做的 harness 就叫 Droid。→ 详细
• 为什么模型独立性（model independence）是硬要求：如果你把软件工厂建在一个被厂商锁死、只能用一个模型的方案上——第一，它会很贵；第二，模型提供方在多大程度上能决定你的工厂能造什么、不能造什么，这是个打问号的开放问题。工厂是你的长期基础设施，不该由别人的路线图来定它的上限。→ 详细
• 数据与 trace 的所有权同样是硬要求："如果流经这座工厂的 trace、数据这些东西你都不拥有，那等你想要演进这座工厂的时候，多半会很麻烦。" 反过来，用 Droid 你能拿到进出它的每一份数据，加上企业层的集中治理和管控，可以规定什么信息流向哪里。→ 详细
• 推到极端就是气隙（air-gapped，物理隔离、完全断网）部署：金融、医疗、政府这类安全要求最高的合作伙伴，把 Droid 隔离部署，整座软件工厂完全跑在封闭环境里。他们一位 deployed engineer 的玩笑是"你要愿意的话，在潜艇里都能跑 Droid"——Eno 说这话是真的。→ 详细

• 第二个交付目标是"为什么要做这一切"——Eno 要求从一开始就有一个极其清晰的 ROI / 结果故事。他给的示范链条是："我们知道，凡是经过 AI code review、AI QA、AI 安全分析的代码改动，出 bug 的概率大概会低 87%；这意味着我们能把 bug 率降低 X，从而把客户满意度提升 Y，最终带来收入、增长或者新业务。"→ 详细
• 必须有一条链路，能从软件工厂这套流程一路连到核心业务目标——而这"往往是个复杂的故事，既要懂工程，也要懂业务"。这也正是这个岗位难招的原因。→ 详细

• 这是 deployed engineer 要补的第一课，也是最关键的一步——"教会他们这套模式"。因为绝大多数组织没有自主化成熟度模型（autonomy maturity model）：没有路线图，也没有概念去想"真正建成一个自主的软件组织"到底意味着什么。→ 详细
• 换句话说，客户的问题往往不是"工具不够好"，而是"不知道自己要走到哪儿、下一格是什么"。你卖的是 built-not-bought 的东西，就得先给对方一张成熟度阶梯，否则他们连投入该投在哪都判断不了。→ 详细

• Eno 说人的角色"极其清晰"：去演进、打磨、扩展软件工厂。一家公司的工程师，从直接操作软件，变成直接维护和管理一套"造软件的系统"。→ 详细
• 但他毫不掩饰这个跃迁有多难："这种抽象层级上的跃迁其实非常难，很多人会觉得极具挑战。我甚至认为，绝大多数人，哪怕是非常有思考力的软件工程师，在做这个转变时都会经历一段学习曲线。"——难点不在技术，在于你不再直接碰产出物，而是去调那个产出产出物的系统。→ 详细
• 谁转得最顺：① DevEx（开发者体验）的人——他们本来就在琢磨怎么赋能其他开发者；② 想快速变得非常技术的产品经理；③ 泛泛地说，在"把高质量开发环境当成优先事项"的团队里待过的人——因为这类人手里已经有让 agent 跑得起来的那些基本条件。→ 详细

• 定义：agent readiness（agent 就绪度）＝你的代码库里到底存在多少条确定性验证回路。所谓确定性验证回路，就是那些结果只有"过"或"不过"的东西：linter、类型检查、安全扫描、端到端测试——一个对勾，没有中间地带。→ 详细
• 它为什么就是那个决定性变量："当你拥有大量这类反馈回路时，agent 就能在更复杂的任务上、在没有人工介入的情况下，持续运转更长的时间。" 验证回路的密度，直接换算成 agent 能独立跑多久、能啃多难的活。→ 详细
• 更狠的那句因果："这类长时间运行的高级 agent harness，输出质量跟你能验证它工作的程度是直接成正比的。所以，一旦你把'大规模验证'的能力引进来，你就把'越来越高的自主性'引进了这个组织。"——自主性不是调出来的，是验证能力换来的。→ 详细
• 反面警告："如果你的代码库不是 agent-ready 的，那今天这世界上最强的 AI 系统，你一样什么成果都看不到。" 这不是那种下载、安装、按播放键就能用的东西。→ 详细

• Factory 有工具能扫描代码库里缺哪些验证回路，但改造本身"很多时候并没那么简单"。大约 30% 到 40% 属于唾手可得的部分——你点一下 Droid，说"把这些都修了"，它进去就修好了。→ 详细
• 剩下那 60% 才是真正的活，因为它们涉及工作流的改变——而工作流的改变意味着要动人的习惯。Eno 点出的具体摩擦是："人有时候受不了这些自动化系统那种……我该说是'吹毛求疵'的程度。"→ 详细
• 所以 deployed engineer 真正要回答的问题是这一句："得留意人的顾虑，得考虑大家现在是怎么开发系统的，然后问：怎么才能在不打断这些人日常开发节奏的前提下，引入这些更严苛的验证策略？"——这是一道社会技术题，不是一道技术题。→ 详细

• missions 是什么："一套极其精细的 harness，专门围绕'处理那些极难、但可被验证的知识工作'这个概念搭起来的。" Eno 认为它是 agent 时代（至少是软件工厂时代之前）比较接近终局形态的 harness。→ 详细
• 它的运转方式：一个长时间运行的 harness，除了规划阶段之外几乎不需要人介入。你进去说"我有一个边界很清楚的任务，我知道我要解决它，而且'解决'的标准是什么我也说得明白"，然后就"一路推动推理这个杠杆，直到任务完成"。人的全部输入被压缩进了任务边界和完成标准这两件事。→ 详细
• 由此推出全片最可迁移的一句判据："只要你能把任何问题重新表述成'一组用来验证它的系统'，那这个问题今天就能用 AI 解决。" 反过来读也成立——问题解不了，往往不是模型不行，是你还没把"完成"定义成可验证的东西。→ 详细

• 代码迁移：全自主地迁移三千万、四千万、五千万行以上的代码库——注意是 fully autonomously，不是"辅助迁移"。→ 详细
• 生物医学 / 医疗健康：拿它做前沿的深度学习工作。→ 详细
• 金融机构做股票研究优化：给不同股票建模、分析、比较，搭出一套能反向传播、甚至能据此交易的系统。Eno 的感受是"我每天听到大家拿这些工具在做什么，都觉得不可思议"。→ 详细

• 销售话术要换个说法：进客户那里该说的是——"这个问题其实是能解的，但它需要的投入方式跟你原本想的不一样：重点不在于去解那个问题，而在于把环境准备好，让这个问题变得可验证。"→ 详细
• 底层原理的类比很硬：这些模型在复杂任务上做后训练时，拿到的是稠密奖励（dense reward）——也就是频繁、细粒度的对错反馈，而不是干完一整件事才给一次分。模型需要稠密奖励，而你代码库里那些验证信号，正是这种奖励的来源，是它们在长周期、目标导向的问题上不跑偏的依据。所以"多加验证关卡"不是工程洁癖，它和模型被训练出来的方式是同构的。→ 详细

• 核心目标是"交出一个转型样板"："如果我们能交给你一个'这场转型该怎么走'的样板，那理论上我们就可以说——我们先在几个地方做出来，然后由你的团队把它推广到整个公司。"→ 详细
• Epcot 类比：Walt Disney 最初想造的不是主题公园，而是一座规划完备的典范城市——"如果我能造出一座'未来之城'，那它就能成为全世界其他城市的样板。" 它最后变成了主题公园，但后来确实有城市借鉴了他关于集中式城市交通的那些想法，近五十年建起来的一些新城市基本就是照着那个玩具级样例做的。Eno 要的就是这个效果：有一个真跑得通的样例，"人是聪明的，是机灵的，他们看到之后会说：哇，这也太酷了，把它搬到我负责的那块代码里去。"→ 详细
• 但样板不能做得太超前，这是个很微妙的平衡："如果你的样例做得太超前，人们又会说：那是个主题公园，跟真实世界完全不是一回事，我实在看不出它跟我们今天的干活方式有什么关系。" 所以要既足以证明"未来是够得着的"，又不能把一个正在心里盘算"按这个速度转型代价得有多大"的组织吓跑。→ 详细

• "未来已来，只是分布不均"——Eno 强调，真正了不起、开始进入自动驾驶状态的单位是代码库，甚至不是公司。同一家公司里不同代码库的自主程度可以差很远。→ 详细
• 两个数字要分清，别混成一个：Factory 自己大概有 15% 到 20% 属于"自主运行"（即多大比例的工作是在自主模式下跑的）；而"自主率"在 80% 出头，定义是"在被人打断之前，AI 系统完成的动作与人完成的动作之比"。前者说覆盖面，后者说单次跑多远。→ 详细
• 一个反直觉的观察：有些客户的代码库比 Factory 自己还自主，因为他们的运行方式受到的约束更多——约束越多，可验证的边界越清楚，agent 反而越能自己跑。→ 详细
• 谁会第一个做到 100% 自主？"其实并不明显"——Eno 押注边界极其收敛的内部工具。他们内部有个叫 legal droid 的法务工作流，"基本上已经是 100% 自主维护了"。→ 详细
• 反过来，他们自己的核心 harness 就闭不了环：终端型 harness 里那些很难搞的视觉问题还没有 validator（校验器）能验——比如闪烁（flickering），很难以一种可验证的方式抓出来。"要造出能验证这类硬骨头问题的系统，本身就是一项工程任务。"→ 详细
• 这反而勾勒出人在未来的位置："人类在视觉上的优势、在掌握外部世界上下文上的优势，恰恰给我们留下了大量工作——就是去把这些系统搭出来。"→ 详细

• 前创始人："如果你当过创始人，那你绝对该来干这个。"理由是——Droid 覆盖的 SDLC（软件开发生命周期）每一个环节，他们都认为是一门十亿美元级的生意：光是 code review，光是故障响应，光是 QA，光是测试。这里每一块，你都能亲手去定义产品的形态。→ 详细
• 擅长技术沟通的人：对 AI 很熟、知道怎么跟各个层级的人对话、有商业判断力、有面对高管的气场。→ 详细
• 系统思考者：喜欢设计系统、喜欢把回路闭上、喜欢建数据模型、喜欢搞清楚一个可能极其复杂的组织里信息该怎么流动——"你在这个岗位上一样会如鱼得水"。→ 详细

本场是 AI Engineer 大会 FDE 专场的开场演讲，没有问答环节（同场还有 Anthropic、Cursor、Ramp、Decagon 等公司的讲者）。收尾是一段招聘 pitch：

• 这个岗位在 Factory 的正式名称叫「engineer, deployed」（工程师，已部署）——名字本身就是个玩笑式的宣言：不是"派驻工程师"，而是像一个被部署的服务。可以直接邮件联系，也可以到招聘页面投递。→ 详细
• Eno 对全场的定调：希望这段内容"让你们大致尝到我们在 Factory 做的事情是什么味道"——即 FDE 不是外派干活，而是带着一套软件工厂的方法论进去，教客户怎么把自己的开发流程改造成可验证、可自主运转的系统。→ 详细

• Eno Reyes — Factory 联合创始人兼 CTO，邮箱 eno@factory.ai（他在台上直接念了出来，说"反正也写在幻灯片上了"），欢迎直接发邮件。→ 详细
• 投递岗位：Factory 招聘页面上的 「engineer, deployed」。→ 详细