FDE到底是什么

现在聊到 AI 的真实落地，有一个重要的概念正越来越频繁地被大家提起，叫 FDE。

这个词背后，对应的是 AI 项目从技术能力走向生产结果时必须完成的一段工作。模型能够生成内容、分析数据和执行动作，说明能力已经具备；但进入真实业务后，企业还要回答一连串更具体的问题：数据和系统由谁接通，权限、安全由谁处理，工作流怎么改变，不同角色如何真正用起来，运行结果又由谁持续负责？

FDE 就出现在这段AI真实的落地距离里。它的全称是 Forward Deployed Engineer，中文叫前线部署工程师，由一家叫做 Palantir 的公司提出并使用，这个职位最开始的完整的名称又叫FDSE，即前线部署软件工程师。

事实上，这套角色的历史其实比生成式 AI 的落地爆发早了近二十年。

这个文章单纯聊聊FDE到底是什么？怎么出来的？包括FDE是怎么运转/执行的等等。

FDE 是从 Palantir 的客户现场里长出来的

2006 年，有电子与计算机工程背景的Shyam Sankar 作为第 13 号员工加入 Palantir，他后来成为 Palantir 的 CTO，也是这家公司最早的 Forward Deployed Engineer。

加入公司时，CEO Alex Karp 问了他一个很特别的问题：为什么法国餐厅能够保持很高的水准？

Karp 的观察是，一家优秀法国餐厅的服务人员深度参与整套餐饮系统。他们了解菜品、做法和客人的反馈，也会把餐桌上发生的事情带回厨房。前厅与厨房因此连成了一个持续响应客人的系统。Karp 希望 Sankar 为软件工程建立类似的组织方式。

这个类比就是 Palantir 当时面对的真实问题。公司早期服务的主要是情报机构和军事单位，这些组织的数据分散在不同系统里，权限严格，任务也会随现场不断变化。不仅他们服务的用户很难提前写出一份完整的软件需求文档，Palantir总部也无法只靠几轮访谈理解他们的用户具体每天如何判断和行动。

于是，Palantir 就把能够修改产品的工程师直接放到用户身边，让他们直接观察用户怎样工作，接触真实的场景、数据和行动约束，在现场编写和部署代码，再根据使用结果继续调整产品。

所以，沿用法国餐厅的类比，如果核心产品团队是厨房，客户现场是餐桌，那么 FDE 就站在两者之间的服务员：既能看见用户怎样工作，也能把工作现场的真实反馈带回厨房改良产品开发。

Palantir的CTO Sankar 在《The Primacy of Winning》的内容说他在 2007 年将这套模式命名为 Forward Deployed Engineering。名字来自 Palantir 当时服务的客户，“Forward deployed”带有部署到前线的含义。2009 年，《Science》的同期报道已经将 Sankar 和同事称为“forward-deployed engineers”。

所以，FDE其实是有两层含义：

• 第一个，它既是一套让工程师深入客户现场的交付模式；
• 第二个，它也是一个用来描述执行这套模式的人的岗位名称。

那 Palantir 是如何把这套模式拆成具体角色去运行的？

FDE 既是一套交付模式，也是一类前线岗位

站在交付模式层面，Palantir 目前用一句话概括这套模式：“FDE is a radical commitment to the outcome.” 意思是，FDE这套模式是一个要对最终结果负责到底的承诺。

Palantir 对 参与前线部署落地的工程师 的要求很明确：工程师从第一次沟通就进入客户的真实环境，持续参与构建、上线和使用，直到系统真正改变客户的运营方式。

Palantir 内部将这套模式的结果责任分给 Echo、Delta 和 Dev 三类角色。它们围绕同一个客户结果协作，但主要所有权不同。

Echo，又叫Deployment Strategist，中文叫部署策略师，负责把业务问题和采用路径跑通。他进入用户的日常工作，理清数据、决策和卡点，把模糊需求变成被定义的问题、成功的标准和新的工作流；系统上线后，再组织培训、观察使用反馈并验证对业务的影响。这些工作都写在 Palantir 当前的 Deployment Strategist 职位说明中。

Delta 才是 Palantir 狭义的 FDE。因为 Palantir 早期前线交付的核心对象是平台、数据和生产软件，所以他们内部对应的典型岗位叫前端部署软件工程师，简称 FDSE。进入 AI 时代，交付对象进一步加入模型、上下文、工具调用和评测，Palantir 又在 Delta 中设置了 Forward Deployed AI Engineer，前端部署AI工程师，我们简称为 FDAE 吧。它延续了 FDSE 的结果责任，但更多聚焦在AI时代的软件构造，也是现在大家重点讨论的 FDE。

Delta 核心干的是把 Echo 明确的问题做成能够持续运行的生产系统：接入数据、编写代码、搭建应用或 Agent，补齐权限、评测、监控和异常处理；系统上线后继续维护结果，并把现场经验带回产品团队。

Dev 负责把不同项目中反复出现的需求沉淀为平台能力。当数据连接、权限控制、模型评测或工作流具有共性时，Dev 会把它们做成可复用的产品组件，供后续 Delta 团队直接使用。

Palantir 在其官方说明中用一组镜像关系区分两者：

• Delta 是“一个客户，多种能力”——所有权围绕一个客户的业务结果展开，为此组合平台、数据、代码、应用、模型和工具等多种手段；
• Dev 是“一个能力，许多客户”——所有权围绕一项可复用的产品能力展开，让它服务更多客户。

把这些职责放回前面的法国餐厅比喻，就更容易看出三者如何配合：

• Echo 更像前厅经理。他在餐桌旁理解客人真正需要什么，设计服务流程，并观察客人是否满意；
• Delta 更像驻店主厨，他把这些需求变成真正端上桌的菜，并对出品结果负责；
• Dev 则是中央厨房里的研发厨师，把不同餐厅反复需要的菜谱、酱料和工具沉淀成标准的能力，来快速应对不同的客人需求。

Palantir 的内部介绍也提到：Echo 通常更接近产品经理，Delta 更偏技术，但两者都会参与产品、工程和策略工作。我目前也在用AI去做一些事情，我会觉得Echo更像是一个懂营销增长懂客户销售的AI产品经理，Delta更像是一个懂产品懂算法的全栈工程师。

简单提一嘴，我其实没有专门对外说自己是FDE，但有一些人联系我寻求类似FDE的服务，你们可能被抖音上一堆拿这个概念说事的人误导了，实际上，FDE要求很高的，上来帮你安装claude code/codex，带你搓两个skill，做一些培训的，那些都不算是FDE真正该干的事情，我目前的定位更像是Echo，专注于跟客户沟通，梳理业务和流程，并提供解决方案/策略，这个也符合我过往的能力经验，类似于AI加持下的营销专家+产品经理。

回到FDE的这个模式上，要理解这份结果责任如何落到持续运行的 AI 工作流里，还要看一下 FDE 运行在什么系统底座上。

FDE 运行在什么系统底座上？

Palantir 的前线团队不是每到一个客户现场就从零开发软件，而是把三类已经存在的平台能力带进去。Palantir 官方把它们定义为数据运营平台 Foundry、生成式 AI 平台 AIP 和持续交付平台 Apollo。三个名字分别回答三个问题：业务系统怎么建立，AI 怎么进入业务，软件又怎么持续上线和运行。

• Foundry（直译：铸造厂）：数据库、表格和旧系统里的数据只是“原料”，Foundry 负责把这些原料接到公司的办事规则和日常工作中，让系统能看懂信息、帮人判断、供员工操作，并把该提醒谁、谁来审批、下一步做什么串起来。它的关键层是一个叫 Ontology（本体论） 的东西：把“客户、订单、资产、项目、人员”等业务概念定义成对象，说明对象有什么属性、彼此如何关联、可以执行什么动作，以及谁有权限。也就是说，Foundry 不只是存数据或做报表，而是让数据进入日常决策和执行。

关于本体论是什么意思，这里简单说一下。本体论原本是哲学概念，它追问的是：世界上究竟有哪些东西，它们是什么，彼此又是什么关系？计算机科学后来借用了这个词，把一个领域里的概念和关系明确写下来，让机器也能处理。

还是用前面的法国餐厅概念来举例。前台看到的是预约和桌位，服务员看到的是客人和订单，后厨看到的是菜品和原料，财务看到的是账单。大家服务的是同一顿饭，但系统里保存的却是彼此分散的记录。Ontology 会把客人、预约、桌位、菜品、订单和 员工定义为一个个明确的业务对象，再说明谁订了哪张桌、哪道菜属于哪一单、库存不足时能触发什么动作，以及谁有权换桌或免单。

这样，当老板问 AI：‘今晚哪些重要客人还没确认？哪些订单可能受缺货影响？提醒相关负责人处理。’这样 AI 就不必在几张表里猜字段，自己理关系，而是在一个已经定义清楚的业务世界里寻找对象、判断关系，并执行被允许的动作。

所以，Ontology 不只是连接数据，更像企业的一张‘业务世界地图’：让业务人员、软件和 AI 都知道这里有哪些人和事、它们怎样关联或串联、接下来能做什么及怎么服务业务要求地去做。

• AIP（Artificial Intelligence Platform，人工智能平台）：它是 Palantir 的生成式 AI 平台，不是某一个大模型，也不只是给系统增加一个聊天框。AIP 把可选择的大模型安全地接到 Foundry 和 Ontology 的业务上下文、权限与动作上，让团队可以构建 Agent、自动化流程和 AI 应用，再通过评测、日志和监控检查 AI 是否可靠。大白话说，Foundry 先让系统知道企业里有什么、能做什么；AIP 再让 AI 在这个范围内理解、判断和行动。

• Apollo（产品名）：官方把它定义为持续交付平台，也称为自动化软件部署的“任务控制中心”。你可以把它理解成软件的发射与运控系统：管理承载 Foundry 和 AIP 的软件版本、环境条件、审批、监控、升级与回退，让同一套软件持续部署到云、本地机房，甚至网络受限或隔离的环境。Apollo 不负责理解业务，也不负责让 AI 推理；它负责确保前两者能够在不同环境里持续、稳定地运行。

所以它们是三套支持的工具：Foundry 把业务变成可运行的系统，AIP 把 AI 接进这套系统，Apollo 让整套软件系统持续交付和运行；FDE 则围绕客户问题，把这些能力组合成真正能进入客户真实生产环境的AI软件系统或工作流。

这套底座也不是Palantir一开始就有，而是在长期服务真实任务的过程中，一层层把它长出来的：早期的他们用 Gotham 等产品先解决情报与行动数据如何接入现场工作；随后 Foundry 从数据平台逐步扩展到分析、机器学习、建模、仿真、数字孪生和工作流；Apollo 则解决同一套软件如何跨不同环境持续交付和运行；直到 2023 年生成式 AI 兴起后，AIP 才作为独立的 AI 平台加入，负责把大模型、Agent、自动化和评测接进这套已有系统。

这套底座是FDE模式的产物也是基座，那FDE模式是怎样一步一步把客户现场的一个具体问题，做成用户真正会用、能够稳定运行、还能持续改进的系统的？它是怎样一条执行和交付的路线呢？

FDE 如何把客户问题做成能持续运行的系统

这条路径的重点，不是把平台功能逐项交付，而是对一个客户问题从发现、建模、上线到改进的全过程负责。

Palantir 没有把 FDE 固定成一套标准动作。官方资料更强调一个持续运转的循环：工程师尽可能靠近客户的问题，在现场构建和交付，再把获得的反馈带回核心工程团队，推动产品继续演化。Palantir 把这个过程称为“人类版本的反向传播”。

反向传播原本是训练神经网络的机制：模型先产生结果，再根据结果与目标之间的误差反过来调整参数。借用到 FDE 上，就是产品能力先进入客户现场，现场暴露的问题再回到核心产品团队，推动产品更新。大白话说，就是先把一个能解决问题的产品带进真实业务里跑；哪里不适配、用户真正需要什么，会在实际使用中暴露出来，团队据此快速调整，再把有效的做法沉淀回通用产品。

在 Palantir 工作八年的前 FDE Nabeel Qureshi，把这个过程讲得更加具体。FDE 每周大部分时间待在客户现场，理解真实的业务流程，快速做出一小块可以使用的软件，拿给用户验证，再根据反馈继续修改。FDE 先解决当前客户的问题，核心产品团队再从中提取共性，把有效方案变成可以服务更多客户的产品能力。

OpenAI 对 AI 时代的 FDE 给出了更完整的工作说明。一个项目通常从诊断 AI 能够创造价值的环节开始，由团队选择少量优先工作流，再将模型连接到企业的数据、工具、权限和业务流程，经过设计、构建、评测和安全审查后受控上线，并根据真实运行结果持续改进。

虽然产品和组织方式不同，这些实践反复出现同一条主线：先在现场找到真正值得解决的工作流，再把它变成可以运行的系统，放进生产环境验证，最后把有效经验带回产品。

为了方便记忆，我把这套从现场到产品的路径提炼为 DRIVE 闭环。五个环节分别是：Discover（找准问题）、Represent（建成可执行业务模型）、Implement（做出并验证最小闭环）、Validate（上生产环境并验证结果）、Evolve（把现场学习带回产品）。

第一步，Discover，找准问题。 Echo 先进入客户的真实工作，搞清楚是谁在做这件事、现在怎么做、具体卡在哪里。这个阶段不急着做产品，先把要解决的问题、成功标准和试点边界说清楚：我们到底想改变什么，又怎样判断它真的有用。

第二步，Represent，把问题讲成系统能理解的模型。 Echo 和 Delta 要把现场的说法整理成对象、关系、规则、动作和权限。比如谁是客户，谁能审批，什么情况下该提醒，什么情况必须交给人处理。这样形成的 Ontology，不是把资料抄进一张表，而是让人、软件和 AI 对正在处理什么、能做什么，先有同一套理解。

第三步，Implement，做出一个最小但能跑通的闭环。 Delta 接入真实数据和工具，把前面的模型做成应用、自动化流程或 Agent。重点不是一下子铺开全部功能，而是先让系统用真实数据完成一条端到端任务，再通过评测和用户测试验证最关键的假设。

第四步，Validate，让它真正进入日常工作。 Echo 和 Delta 补上安全控制、权限、监控和异常处理，推动用户开始使用，并持续观察结果。只有系统真的进入工作流、运行情况看得见、业务结果能被检验，这一步才算完成。

第五步，Evolve，把现场经验带回产品。 Delta 和 Dev 会区分哪些是这一个客户的特殊要求，哪些是其他客户也会反复遇到的问题。后者会被沉淀成可复用的组件、工具或方法，让下一个项目不必从头再做一遍。

真实项目不会沿直线走完 DRIVE，而是可能会在五个环节之间反复，且整个过程 Echo、Delta 和 Dev 会协同完成。其中，Represent 是把现场理解变成系统结构的关键一步：Echo、Delta 要把客户现场里“大家在处理什么、彼此怎样关联、下一步能做什么”的说法，整理成系统能识别的业务模型，就是我们刚刚说的ontology。

至此，关于FDE的一些基本理解就说的很清楚了： 第一，它不只是一个岗位，也是一套把现场问题、业务模型、生产系统和反馈回流连成闭环的工作方式。

第二，FDE这套模式核心由Echo、Delta 和 Dev 三种角色负责协作才能实现，Delta才是狭义的FDE，这个团队背后有由Foundry、AIP 和 Apollo 提供系统底座作为支持。 第三，FDE这套模式的推进可以概括为 DRIVE 路径。其中比较关键的点就是第二点，Represent，把现场的实际业务问题转化成机器可识别的ontology。至于ontology的细节是什么？后续可能会出一个内容单独讲一下。