八堂FDE实战课

第一课　FDE“不存在”：一份不断叠加的职位史

一个名称，装进了太多工作

Meurer开场抛出“肮脏的秘密”：FDE并不存在。

她并不是说公司里没有这些人，而是说这个名称已经被用来描述太多不同工作。两家公司都招聘FDE，可能一个人在客户机房处理基础设施，另一个人在设计行业解决方案，第三个人像产品经理一样收集反馈，第四个人负责搭建AI Agent。把他们放在一起，唯一稳定的共同点只剩“离客户很近”。

这个判断并不是旁观者对热门职位的冷嘲。Meurer自己就是这段历史的一部分。她最初在乔治城大学外交学院研究科技政策，后来学会编程，2016年进入Palantir。五年间，她先后做过隐私、基础设施以及面向执法和国防客户的现场工程。离开Palantir、读完商学院之后，她又在2024年加入Sierra的部署团队，负责把面向客户服务场景的AI Agent送进企业。

刚加入Sierra时，她甚至不喜欢“部署团队”这个名字。她觉得团队做的并不是把一个包装好的产品安装给客户，而是在对一个持续变化的AI系统承担结果责任。2024年，她写过一篇关于“Agent Engineer”的文章，试图给这种工作一个更准确的名称：它是AI工程的一个分支，却继承了FDE对客户结果的直接责任。两年后，“Agent Engineering”“Harness Engineering”等新称呼相继出现；后者指围绕模型建设上下文、工具、权限、验证和运行框架的工程工作。名称反而更多了。这段经历让她意识到，也许问题不在于还缺少一个更好的职位名称，而在于行业试图用职位名称固定一组本来就在变化的责任。

要理解这种混乱，需要回到Palantir早期。那时“forward deployed”近乎字面意思：工程师真的被部署到客户现场。客户可能使用隔离网络、本地服务器和特殊数据环境，平台是否稳定运行，本身就是交付的一部分。

Meurer用四个年代描述工作怎样变化。

2008：先让系统别倒

DevOps不是某一款工具，而是让软件开发与运维共同负责测试、发布、监控和故障恢复的一组方法；站点可靠性工程（SRE）则用软件工程方法保障系统稳定。最早的FDE很像DevOps、SRE和现场支持的混合体。软件要装进客户环境，出问题时不能把工单扔回总部等待。凌晨两点的故障，现场工程师必须理解网络、机器、发布和产品行为，把系统救回来。

Meurer展示了Palantir在2016年前后的招聘信息，其中最醒目的资格并不是某一种语言或框架，而是工作地点。工程师可能要长期待在芬兰、堪培拉或某个军事基地。之所以先写地点，是因为许多系统不是运行在供应商统一管理的云上，而是在客户自己的服务器、网络和安全边界内。远程看不到环境，标准化运维工具也未必能进入；工程师必须和软件一起去现场。

她入职后的第一个练习，是把Palantir软件部署到Amazon Web Services（AWS）云中的一台虚拟服务器——EC2实例——上。这个听起来像普通云计算作业的任务，实际上在重现早期FDE的核心处境：如果产品连稳定运行都做不到，后面所有关于数据和业务价值的讨论都没有意义。她还用一封夸张却真实感十足的客户邮件说明当时的日常——某台机器又被人误拔了电源，请工程师凌晨两点过去看看。问题可能一点也不“高级”，但客户的业务已经停在那里，供应商不能以“这不是产品代码的问题”为理由离场。

这里形成了FDE最早的一项传统：责任不以代码合并或安装完成为终点。 系统没有在客户那里工作，工程就没有结束。

2012：系统稳定之后，数据成了问题

平台能运行，不代表里面有可用信息。客户的数据散在不同系统中，字段含义不一致，权限规则复杂，历史记录脏乱。FDE开始承担数据集成，并帮助客户建立本体（ontology）：把数据库里的表和字段，组织成业务人员认识的对象、关系与动作。

Meurer用了一个很形象的比喻：没有集成数据的数据平台，就像一座没有电影可放的电影院。建筑、座椅和放映机都在，却没有观众真正来这里的理由。

这项工作不只是把二十个数据库复制到同一个仓库。企业里的同一个概念，常常在不同系统里有不同名称和粒度：一个系统记录“客户”，另一个系统记录“账户”，第三个系统只知道合同编号；权限又决定了哪些人能看到哪些字段。数据接通之后，如果业务人员仍然只能面对表名、列名和连接语句，平台依旧没有真正进入工作流。

因此Palantir强调ontology。可以把它理解为数据与业务之间的一层共同语言：把分散表格中的记录组织成“飞机”“零件”“订单”“机构”这样的对象，说明它们之间的关系，并定义用户能够执行的动作。它既不是一份静态的数据字典，也不等同于知识图谱展示；它的价值在于让应用、权限和业务动作都围绕同一组业务对象运转。FDE之所以承担这项工作，是因为工程师既能读懂底层数据，又能在现场追问“这个字段在你们实际工作中代表什么”。

到这一阶段，FDE已经同时背着两份工作：底层平台依然要稳定，客户数据还要持续接入。新责任不是替代旧责任，而是叠加在旧责任之上。

2016：有数据之后，用户还需要解决方案

数据可用之后，下一个问题是业务人员怎样行动。Palantir当时的FDE会使用可视化应用构建工具Slate搭建仪表板和定制应用，把数据变成调查、运营和决策流程。工作重心从“平台是否可运行”，转向“这个客户能否用平台解决具体问题”。

工程师可以在Slate中把页面组件放到画布上，再把组件连接到已经集成的数据源。它和后来流行的低代码内部工具有些相似：不用从零搭建前端框架，就能迅速做出一个供特定团队使用的工作界面。由于FDE最清楚客户的数据和工作方式，自然也最适合把这些组件拼成解决方案。

但“看见数据”并不自动等于“改变决策”。Meurer特别提醒，只有读取、没有写回能力的仪表板，往往会慢慢失效。用户在屏幕上发现异常，仍要转到邮件、工单或另一个业务系统里采取行动；行动结果又没有回到平台，数据便与真实状态逐渐分离。Palantir后来常说要从“data”走到“decision”，关键正是把观察、判断和动作连成闭环，而不是多做一块漂亮大屏。

这一步也埋下了定制债务：一个现场快速做出的方案，很容易成为客户每天依赖的生产系统。它既不像核心产品那样经过长期设计，又不可能在项目结束后随手删除。

这也是FDE历史里经常被忽略的一层：所谓“定制”并不一定是客户提出一个功能、工程师照单写代码。很多时候，客户只知道自己想更快地做出某类决定。工程师要从数据和日常操作中反推出应用应该长什么样，再判断其中哪些能力值得进入通用平台。现场项目因而既是交付，也是产品发现。

2020：让客户自己构建

Palantir的核心数据运营平台Foundry，并不是一个单独的数据库：它把数据集成、业务对象、应用与工作流置于同一套安全和治理体系内。随着Foundry逐渐成熟，FDE又开始做平台赋能：组织训练营、教客户使用工具、把反复出现的解决方案变成自助能力。目标不再是每次都由FDE亲手完成，而是让客户和更广泛的团队能在平台上自己构建。

Airbus与Palantir合作推出的航空数据平台Skywise，把飞机传感器、机队配置、维修工单、备件和航班等数据放到一个可分析的云平台中。Meurer用它说明客户自建为什么重要：对于一家拥有大量工程师、运营人员和合作伙伴的航空企业，少数Palantir FDE不可能永久承包所有数据应用。平台能否扩大影响，取决于能不能让数以千计的Airbus工程师在Foundry之上完成原本由FDE承担的工作。FDE的任务于是发生了又一次上移：不仅要交付方案，还要设计培训、模板和平台能力，让客户逐渐拥有自己的构建能力。

Palantir的生成式AI平台AIP用于把模型接入企业数据、工具和运营流程；它的AIP Bootcamp则是短期实战工作坊，业务与技术人员在Palantir工程师陪同下，以小时或天为单位把一个真实场景做成可运行用例。这种做法延续了平台赋能的思路。到2026年，Palantir甚至把“AI FDE”做成了产品能力，让Agent通过自然语言执行数据转换、代码仓库操作和ontology修改。这里出现了一种耐人寻味的循环：过去由FDE手工完成的部分工作，正在被平台和AI吸收；与此同时，客户开始提出更复杂、更接近经营结果的问题，又把FDE推向新的责任边界。

这四个年代不是前后替代。基础设施、数据、本体、应用、培训和产品反馈一层层叠加。到2026年，公司招聘一个FDE时，往往暗中希望同一个人同时拥有高级工程师的技术深度、销售的沟通能力和解决方案架构师的系统判断。Meurer的反讽就在这里：这样的统一职业画像并不存在。

她把这种差异称作“FDE年份”。如果一个人在平台尚不稳定的年代受训，他可能特别擅长排障、部署和在压力下恢复系统；在数据集成年代成长起来的人，更熟悉schema（数据结构定义）、权限和ontology；定制应用年代的FDE，往往有强烈的产品直觉；平台赋能年代的人，则擅长培训、抽象和组织扩散。问一位候选人“你是哪一种年份的FDE”，常常比问“你做过几年FDE”更有信息量。

这也解释了为什么Palantir校友后来创办了许多企业软件公司。现场工作把一个年轻工程师同时暴露在基础设施、数据、产品、客户、商业和组织问题中。它未必培养出某个狭窄领域最深的专家，却很容易培养能在陌生环境中迅速建立问题模型的通才。

FDE工作的四层叠加

真正不该消失的是连续责任

Meurer认为，这个职位虽然模糊，却保留了一项重要设计：客户责任的连续性（continuity of customer accountability）。同一个人理解客户为什么买、系统怎样搭、用户为何不用、故障会造成什么损失，也能把这些信息带回产品团队。

当组织把售前、签约、实施、交付和支持切成多个部门时，每个部门都可能正确完成自己的局部任务，却没有人对端到端结果负责。FDE的价值，不在于一个人必须包办所有事情，而在于有人跨过交接边界，确保问题没有在组织图里消失。

这也是为什么2026年的招聘描述显得近乎荒诞。公司希望候选人既有多年staff engineer经验，又懂销售、解决方案架构、项目管理，最好还善于教学。不是因为招聘者真的相信世界上有大量这种全能人才，而是因为企业AI的交付链条尚未稳定，许多原本应该由产品、平台、售前、实施和客户成功共同承担的责任，被暂时压缩进了FDE这个名字。

因此，判断一家公司是否把FDE设计对了，不能只看招聘要求有多高。更应该看团队能否把不同责任拆开：平台团队消除重复的部署故障，数据产品提供可复用连接器，FDE聚焦问题发现和第一个生产结果，培训与客户工程帮助能力扩散。优秀的FDE组织不是依靠全能英雄维持，而是不断把英雄工作变成系统能力。

AI让边界继续溶解

当生成代码的成本下降，FDE可以更快地从需求走到完整方案，产品工程师也能更直接地面对客户。两类工程师的边界开始模糊。与此同时，软件定价也可能从席位、用量继续走向结果：如果Agent能自主完成工作，客户会更自然地问“我为什么不直接为完成的结果付费？”

代码变便宜之后，原来用于区分岗位的一条边界也变弱了。过去，产品工程师负责写可复用的核心代码，现场团队负责配置、集成和反馈，因为从零构建完整功能的成本太高。编码Agent让FDE有能力直接完成端到端原型乃至生产功能；产品工程师也能用同样的工具更快响应特定客户。两类人的工作不再由“谁能写多少代码”区分，而更多由谁掌握现场上下文、谁对长期平台负责来区分。

Meurer把另一条变化放在商业模式上。传统SaaS通常按席位收费，因为供应商提供的是使用权，客户如何使用、最终产生多少价值，很难精确归因。基础模型常按token或调用量收费，供应商能计量消耗，却仍不能保证用户得到了结果。客服Agent则可能直接完成“解决一次咨询”“促成一次销售”这样的任务，产品对结果拥有更高自主性，结果也更容易测量，于是按结果收费变得可行。

结果定价会把责任推回供应商。有人必须定义结果、度量结果，并在Agent没有交付时解释原因。这个人也许仍叫FDE，也许叫Agent Engineer、Applied AI Engineer、Customer Engineer或别的名称。

例如，“一次问题已解决”到底是Agent给出了回复，还是客户没有再次来电？退款被成功发起算不算完成，还是资金真正到账才算？一次销售由Agent促成，如何排除广告、价格变化和人工销售的影响？当收费单位从席位变成结果，这些不再只是分析团队的指标问题，而会直接进入合同、系统设计和日常运营。FDE需要把模糊的商业承诺翻译成可观察、可审计的系统事件。

Sierra的实践让Meurer修正了自己2024年的判断。Agent Engineering当然有自己的技术对象——提示、工具、状态、评测、护栏和运行时——但它不是一个与FDE平行、边界清晰的新职业。只要工程师要为客户现场的结果负责，它就仍然继承了FDE的核心逻辑。反过来，产品工程、基础设施工程和AI工程也都在更直接地接触客户反馈。不是FDE吞并了所有岗位，而是“离结果更近”正在成为更多工程岗位的共同要求。

因此，Meurer最后说：“FDE已死，FDE万岁。”死去的是把所有客户技术工作塞进同一个职位名称的幻想；留下来的，是贴近现场、承担连续责任、把经验带回产品的组织功能。

第一课留下的悬念是：既然FDE不是一份稳定、统一的职业，企业是否还应该专门成立这种团队？答案不能靠职位热度决定。下一课会把产品复杂度、买方能力和平台经济放到同一张图里，先判断什么公司真的需要FDE。