\n\n面对AI大模型难以在企业生产环境中落地的痛点，OpenAI和Anthropic等巨头大举招聘前线部署工程师（FDE），直接入驻客户企业解决集成难题，推动AI落地。
译自：Why OpenAI and Anthropic are hiring forward deployed engineer teams
作者：Oluwadamilola Oshungboye
那些试图在产品中加入AI的企业，往往认为强大的模型是成功集成的关键。这一假设在早期阶段是成立的，因为调用API可以快速展示其价值。然而，一旦AI成为不同团队高度依赖的大型系统的一部分，这一假设就不再适用了。
到了那个阶段，最大的挑战变成了如何让模型在现有的基础设施中可靠地运行，并与内部数据、遗留软件、合规规则以及那些从未针对AI设计过的工作流和谐共存。麻省理工学院（MIT）的 NANDA 计划研究了300个公开的AI项目，发现95%的企业AI试点项目几乎或完全没有对损益产生可衡量的影响。问题不在于模型本身，而在于它们是如何被投入使用的。
当像OpenAI and Anthropic这样的AI公司开始向大型企业推广其模型时，它们也遇到了同样的实施挑战。为了解决这个问题，它们开始将工程师直接派驻到客户身边。这些工程师与客户公司的团队并肩工作，负责系统集成、将其推向生产环境，并在出现问题时进行改进。这种紧密的合作缩短了反馈循环，加速了部署，并提高了系统在生产环境中切实发挥作用的概率。这种方法现在被称为前线部署工程（FDE）。
这种转变正变得越来越难以忽视。OpenAI在2024年成立了其前线部署工程团队，并迅速扩大了规模。Anthropic也宣布计划扩大其应用AI团队，以满足日益增长的需求。在整个行业中，前线部署工程师的招聘岗位在2025年1月至9月期间激增了800%以上。各大AI实验室似乎达成了一致共识：AI落地的未来取决于部署，而不仅仅是提高模型质量。
前线部署工程的起源
前线部署工程的概念早在AI公司走红之前就已存在。它实际上大约在二十年前起源于Palantir。
Palantir为政府机构和大型金融公司开发数据智能软件。这些机构所处的运行环境拥有复杂的基础设施、严格的合规要求和极高的运营复杂度，是现成软件难以轻易解决的。传统的“交付产品、提供文档、剩下的让客户自己搞定”的方法在这种情况下根本行不通。
因此，Palantir引入了一个名为“Deltas”的新角色。Deltas是直接与客户共事并在客户环境中构建解决方案的软件工程师，他们专注于在现实情况中使系统运转起来所需的要素。传统软件工程师通常会同时为许多客户设计功能，而Deltas则采取了不同的方法。他们每次只专注于一个机构，深入学习其基础设施、数据和工作流，然后调整系统以契合该机构的实际运作方式。
这种方法非常有效，以至于在2016年之前，Palantir拥有的Deltas数量超过了普通软件工程师。对于一家软件公司来说，这非同寻常。超过一半的工程师直接与客户一起工作，而不是在后方构建核心产品。
如今，这同一个理念仍然是前线部署工程的核心。为了理解为什么这种模式如此有效，有必要了解一下前线部署工程师实际上在做什么。
前线部署工程师（FDE）究竟在做什么
前线部署工程师直接在客户的环境中工作，目标非常明确：让系统在生产环境中运行起来，并保持平稳运转。
在实践中，这意味着成为客户技术团队的一部分。前线部署工程师会加入公司的沟通渠道，与产品和工程团队紧密合作，直接使用客户的数据和系统进行构建。他们不仅协助决定要构建什么，还负责构建、集成并确保系统在发布后表现良好。这个角色融合了软件工程、产品洞察和运营诀窍，衡量其成功的标准是系统的使用情况和性能表现，而不是投入的时间。
一次典型的对接始于了解该机构的实际运作方式。这包括绘制数据流向图，找出AI可以提供帮助或实现任务自动化的环节，并确定团队将如何使用这些结果。随后，前线部署工程师会构建并集成系统以满足这些需求。系统上线后，工程师会继续参与其中，进行微调、提高可靠性，并随着人们开始使用系统而响应反馈。
正如一位FDE所说：“模型通常是最干净的部分。难点在于找出那些没人记录的工作流、人们真正信任的数据源，以及那个知道流程为什么会那样运转的人。”
FDE的工作内容
这正是该角色与传统咨询的不同之处。顾问通常工作固定的一段时间，并以交付成果来衡量。而前线部署工程师则是通过系统上线后能否持续良好运行并继续创造价值来衡量的。他们的工作在交接时并没有结束，因为他们会一直参与其中，直到系统成为日常运营的一部分，且客户自己的团队能够独立管理为止。
了解了这项工作的日常形态，有助于解释为什么开发先进AI系统的公司会在这项举措上投入如此巨大。但这也留下了一个疑问：为什么传统软件不需要这种模式，而AI却需要？
为什么AI比传统软件工程更需要FDE
在传统软件中，大部分风险都发生在初始阶段。你进行设计、集成和测试，一旦一切运转正常，它通常就会保持正常运行。如果出了问题，也很容易找到并修复。
AI系统则引入了不同类型的风险，因为它们是概率性的。模型可能在测试中表现良好，但一旦接触到生产数据和真实用户，其性能就会下降。系统不会直接宕机，而是会变得不可靠，返回不一致或无关的结果，从而慢慢侵蚀用户的信任。
为什么AI部署需要FDE
典型的软件交付模式并不是为了处理这种类型的失效而设计的，因为内部团队的设立是为了交付功能，而不是长期参与以稳定一个随时间推移而演变的系统。另一方面，顾问通常在固定的范围和截止日期内工作，一旦工作完成，他们就会离开。在这两种情况下，恰恰在AI系统最需要密切关注的时候，责任归属却消失了。
前线部署工程师有助于解决这个问题。通过在客户的环境中工作，他们能在问题出现时及时发现，进行快速调整并实时改进系统。这种近距离的接触，正是将一个颇具前景的模型转化为足以让人信赖的可靠系统的关键所在。
FDE模式是如何变得更加触手可及的
领先的AI公司所采用的FDE模式，由于维持成本高昂，通常是小型组织无法企及的。预算充足的大公司可以为单一客户部署分配多名工程师，甚至是整个团队。而规模较小的组织面临着相同的实施挑战，却不具备将团队专门投入到开放式集成工作中的工程能力。
为了缩小这一差距，现在出现了几种不同的方法。AI实验室正在围绕其模型扩大部署支持，例如OpenAI推出了一个专门的部署公司，而Anthropic、OpenAI和Cohere都在增加对前线部署或应用AI角色的投资。大型咨询公司也在通过合作伙伴关系来填补这一空白，旨在帮助企业推动AI跨越试点阶段。与此同时，诸如Bit Cloud之类的平台公司正在将前线部署工程师与工具链相结合，使单个工程师能够将生产就绪的起点直接引入客户环境，而不是从零开始构建每个集成。
这些方法都秉持着一个共同的观点，即主要的瓶颈已经发生了转移。现在，挑战不再是模型本身，而是寻找那些能够在客户系统内工作、理解真实工作流并在生产环境中交付切实可行解决方案的工程师。
总结
前线部署工程是为了应对现实世界中的问题而诞生的。组织能够获得更强大的软件，但往往难以让这些系统在日常运营中发挥作用。主要问题不在于技术，而在于软件所提供的功能与组织对其自身基础设施、数据和工作流的实际需求之间存在鸿沟。
AI实验室也遇到了Palantir二十年前面临的同样问题。让复杂系统发挥作用最可靠的方法，就是让工程师贴近使用系统的人、他们所依赖的数据，以及他们旨在解决的问题。
随着AI成为核心业务系统的一部分，优势将向那些能够超越原型设计、实现可重复部署的团队倾斜。无论这种支持是来自内部团队、AI实验室还是平台，只有走对这一步的公司，其AI投资才能在生产环境中真正开花结果。全 工智能
