为什么企业AI需要前向部署工程师（Forward Deployed Engineers）

大约十年前，“前向部署工程师（FDE）”在Palantir诞生。现任CTO Shyam Sankar将这一角色描述为“吸收痛苦，产出产品”，将前线的混乱转化为已交付的软件。

此后，FDE在整个行业中被重新包装为Agent工程师、AI工程师或客户工程师。但其底层功能现在比以往任何时候都更加重要。随着AI Agent成为核心企业工作流的主流，前向部署工程正逐渐成为一条不可避免的路径。

以下是原因，以及如何做对。

AI让软件本身变得不同

在SaaS时代的大部分时间里，企业软件是确定性的。你购买一个记录系统，按照安装步骤操作，软件就成为你技术栈中一个固定的层级。部署过程繁琐，但一旦运行起来，就稳定可靠。围绕它形成了部落知识：runbook、cookbook、Confluence页面。一种围绕稳定事物建立的操作肌肉记忆。

销售也遵循同样的结构：一个客户团队 → 一个DRI（直接责任人） → 几个季度的实施 → 一条可预测的上线路径。

AI Agent打破了这种模式，但方式并非人们通常描述的那样。Salesforce、HubSpot和Splunk等记录系统仍然存在。不同之处在于你在它们之上部署的内容。

你不再部署一个执行定义逻辑的确定性层级，而是部署某种概率性东西。一个旨在完成人类原本会做的工作的东西。而要把它做好，AI Agent必须内化的不仅仅是记录系统。它必须内化那个让公司真正运转的、混乱且未文档化的决策轨迹。制度记忆、边缘案例，或是那些没人写下来的判断——因为做出判断的人并不知道自己正在做判断。

这就是困难所在，而当问题领域已经足够复杂时，这种困难会加剧。部署AI来生成工单的初稿相对宽容。部署AI来调查一个跨六个团队、十五个服务的分布式系统中的生产事件则不然。Agent需要理解的不只是工具，还有它们之间的关系；不只是当前状态，还有它是如何到达当前状态的。

FDE的真正工作是压缩，而非支持

正是这种部署场景让前向部署工程变得不可或缺。它本身就是产品。

FDE的工作是消化客户的世界，构建关于其基础设施、环境和边缘案例的深度领域直觉，并将这些抽象化后反馈到产品路线图中。

“从很多方面来看，FDE是公司中保真度最高的产品信号。”

在企业AI中，前向部署工程中的痛苦转化为产品能力的速度，决定了你建立的是平台公司还是服务公司。

对这种FDE模式最常见的质疑是规模化。如果每个FDE都必须深入了解每个客户的环境，那么当客户达到500家时会发生什么？

“答案在于重新定义FDE实际在做的事情。他们不是支持角色。FDE是产品最苛刻的用户，在产品的能力边界上操作。他们的挫败感是数据。他们的变通方案是路线图上的条目。而他们最重要的任务是确保在实地学到的东西不会只停留在实地。”

在实践中，这意味着FDE不仅仅报告出了什么问题。他们编写高质量的评估（evals），将真实场景转化为核心工程团队可以改进的结构化基准。这些评估是客户特定的，利用了核心工程团队无法获得的环境特定上下文。它们反映了每个客户领域的真实复杂性。如果产品真正在复利增长，那么边界会随时间向外推移。FDE创建的评估应该变得更难，而不是更简单，因为产品正在吸收原本需要人类处理的复杂性。

“一个简单的诊断指标：你FDE的输出中，有多少是全新的反馈，与反复出现的同样问题？如果团队每个季度都在同样的边缘案例上循环，那说明存在产品吸收问题。但如果FDE始终在技术可能性的边界上操作，那就是服务转化为产品资产的方式。这就是你建立复利护城河的方式。”

从这个意义上说，FDE的工作就是压缩。吸收现实世界的复杂性，将其转化为产品可以吸收的东西，并逐步缩小需要人类和不需要人类之间的差距。

每个FDE组织都会经历三个阶段

FDE生命周期是一个有用的诊断工具，可以判断公司所处的位置以及下一步需要做什么。阶段并非僵化，但演进是真实的。

第一阶段：工程驱动的增长

在初创阶段，工程师与每个客户紧密合作。产品过于原始，无法建立正式的FDE职能。公司本身——从CTO往下——就是前向部署层。早期采用者不会期望产品开箱即用。大量的手动工作是被预期的，有时甚至有意针对特定客户环境进行过度拟合。

这一阶段的护城河在于复杂性。如果问题真正混乱且困难，就值得解决。如果人工努力与产品能力之间的差距没有显著扩大，通常意味着还没有一个清晰且具体的、有价值的愿景。

这种动态也解释了为什么早期集成要求较低的AI工具往往难以留住客户。低集成摩擦是一把双刃剑。容易集成的东西也容易被替换。那些在发布时不需要前向部署的产品往往没有持久的护城河。

第二阶段：FDE驱动的增长

现在产品能够可靠地交付价值，但前提是需要针对每个企业的约束进行定制。一些设计合作伙伴账户正在转化为大规模生产部署。产品开始嵌入日常工作流。

随着FDE吸收客户特定的复杂性并将其转化为评估，核心工程团队可以专注于平台层面的问题，而不是扑灭定制部署的火。

这一阶段的转折点发生在FDE能够同时支持更多账户时。曾经需要定制的工作通过连续的产品发布被整合进产品中。产品能力开始超过手动部署所需的人力，你开始看到真正产品成熟度的早期迹象。低复杂性的环境需要更少的FDE参与，而高复杂性的企业仍然需要深入的前向部署。

这正是我在Resolve AI所处的位置。我们正在解决的问题——让每个工程师能够同时调查代码、基础设施、遥测和组织知识——本质上就是复杂的。每个客户的栈都不同。服务、所有权模型、告警拓扑、关于故障方式的部落知识。理解这些没有捷径。

在实践中，这意味着每一次互动都教会我们一些东西，这些东西会成为Resolve AI理解生产系统的一部分。当客户纠正一条调查路径，或解释为什么他们的Redis集群行为与预期不同时，这种纠正就成为了系统知识的一部分。FDE的工作就是确保这些学习不会只停留在本地。它必须反馈到产品中。

我的一部分职责是主动管理一个由FDE反馈驱动的Sprint团队，每月强制直面最高摩擦的差距。观察这个过程——看到实地学习转化为产品能力——正是让前向部署在这个阶段值得做的原因。

第三阶段：产品驱动的增长

最后阶段是整个生命周期所追求的最终目标。产品无缝运行，以至于部署几乎零摩擦，平台开箱即用即可可靠处理企业复杂性。

大多数客户无需FDE介入即可部署。交易完成时客户团队参与最少。FDE被保留给最高复杂性、最高风险的客户，在那里他们是在一个强大平台的基础上进行扩展，而非弥补缺口。

此时FDE赢得了解决他们所在公司更重要问题的权利。产品现在已经能够开箱处理低复杂度环境，同时仍能扩展到最苛刻的集成。

从这里开始，挑战转向了革新。扩展到新的工作流，重启循环，确保前向部署继续将前沿复杂性转化为持久的产品优势，而不是在已经吸收的东西上停滞不前。

当循环有效时，以及当它失效时

在这个生命周期结束时，如果产品成熟度与人工参与之间的差距没有显著扩大，那么你实际上已经变成了一家服务公司。这通常意味着产品执行不力，或者FDE在实地体验到的问题与真正被优先处理的问题之间存在持续脱节。

但如果这个差距已经扩大，说明产品已经吸收了复杂性，并且现在处于大型企业的关键路径上。这是值得努力追求的结果。

最优秀的FDE以第一性原理思考，构建持久的基元，并在不同客户之间复利学习。最优秀的公司将FDE团队视为工程团队的延伸，而非销售团队的延伸——因为这才是他们真正的角色。

我之所以在现阶段加入Resolve AI，原因之一是实地学习与产品能力之间的路径直接而短促。问题足够困难，以至于我在每次互动中学到的东西对产品构建真正重要。这是罕见的，值得追求。我很幸运能随着生命周期的推进见证这一切，并与Resolve AI一个才华横溢的团队一起从零开始构建这个职能。如果你也深有共鸣，我很乐意进一步交流！

Swarit Joshipura
前向部署工程师
@ Resolve AI