过去两年，AI 公司在招聘中频繁出现一个新岗位：前线部署工程师（Forward Deployed Engineer，简称 FDE）。他们不坐在总部写通用产品，而是带着模型和平台走进客户企业，和业务人员一起把 AI 接进真实的数据、流程和系统里。FDE 的走红说明了一件事：AI 落地最难的部分不在模型本身，而在客户企业内部的“最后一公里”。
那么，FDE 到底做什么？为什么 OpenAI、Anthropic 这样的模型公司也要大规模组建这类团队？在这篇文章中，我们将介绍FDE 的含义和起源、AI 公司组建 FDE 团队的背景、AI 落地为什么需要这种角色、FDE 与几类相近岗位的区别和所需能力，以及企业如何与 FDE 合作、培养自己的“内部 FDE”。
什么是前线部署工程师（FDE）？
FDE 是一种“驻扎在客户身边的软件工程师”。他们写代码、搭数据管道、配置系统，但服务对象不是“所有客户”，而是一个具体客户，衡量标准是这个客户的业务问题有没有被解决。普通工程师把一个功能做给很多客户，FDE 则为一个客户组合运用很多功能。
这一岗位最早因数据分析软件公司 Palantir 而广为人知（来源）。Palantir 在官方博客《Dev versus Delta》中区分了两类工程师：属于产品研发部门的软件工程师（内部称为“Dev”）负责打造平台的某个组件，关注“一种能力，服务众多客户”；属于业务拓展部门的前线部署软件工程师（内部称为“Delta”）则以一个客户为单位组队，关注“一个客户，用上多种能力”，成败看的是客户的业务结果，例如生产线上的缺陷是否减少（来源）。文中受访的 Delta 每周有相当一部分时间待在客户现场。
Palantir 的另一篇博客列出了 FDE 的日常工作：为客户设计、开发和部署专属的业务流程与数据模型；搭建和维护支撑业务运行的大规模数据管道；按照监管和合规要求配置访问权限；负责生产系统的稳定、升级和监控，出现故障时排查根因；同时把在客户现场学到的东西反馈给产品团队，把有普遍价值的方案沉淀进平台（来源）。
值得注意的是，Palantir 特意把 FDE 和咨询顾问区分开来。它的说法是：FDE 用的是现成的软件平台和组件，目标是为客户搭建长期可用的系统，而不是做一次性的分析报告或为每个客户拼凑一套定制方案。这正是 FDE 与传统咨询最根本的区别：交付的是能持续运行的系统，而不是建议。
为什么 AI 公司纷纷组建 FDE 团队？
模型公司原本最像“卖标准产品”的公司，但它们也开始把工程师派到客户那里。原因很直接：客户买了模型，却未必能把它用起来；用不起来，订单就难以续约和扩大。
几条公开信息可以说明这一趋势：
- 岗位需求快速上升。 eWeek 2025 年 11 月援引《金融时报》的报道称，OpenAI、Anthropic、Cohere 等公司都在扩充 FDE 团队；招聘网站 Indeed 的数据显示，2025 年 1 月至 9 月，FDE 岗位的招聘信息增长了 800% 以上（来源）。需要说明的是，这是相对增幅，不代表这类岗位的绝对数量已经很大。
- 模型公司在扩编。 同一篇报道提到，OpenAI 在 2024 年初组建 FDE 团队，计划在 2025 年扩充到约 50 人；Anthropic 则计划在 2025 年把包括 FDE 在内的应用 AI 团队扩大到原来的五倍。
- 部署被单独做成了一门生意。 2026 年 5 月，OpenAI 宣布成立独立运营的部署公司（OpenAI Deployment Company），初始投资超过 40 亿美元，由 TPG 牵头、联合 19 家投资机构、咨询公司和系统集成商共同参与；同时宣布收购应用 AI 咨询公司 Tomoro，预计将带来约 150 名 FDE 和部署专家（来源）。按 OpenAI 的描述，这些 FDE 会进入客户组织，找出 AI 最能发挥作用的环节，围绕它重新设计流程和基础设施，并把模型接入客户的数据、工具和业务流程。
- 招聘要求写得很具体。 Anthropic 当前的 FDE 招聘页面写明，这一岗位隶属应用 AI 团队，要嵌入重点客户内部，基于 Claude 构建能投入生产的应用，并有 25% 到 50% 的时间出差到客户现场（来源）。
投资机构 a16z 在 2025 年 6 月的一篇文章中，把这种做法称为“服务驱动增长”（services-led growth）：企业级 AI 产品需要大量实施工作，初创公司不妨接受早期较低的毛利率，先用深度服务把客户的流程和数据接进来（来源）。换句话说，FDE 既是交付手段，也是 AI 公司在客户内部扎根的方式。
为什么 AI 落地需要 FDE 这样的角色？
大模型是通用的，而企业的业务是具体的。模型知道“退货”是什么意思，却不知道你公司的退货要经过几道审批、数据存在哪个系统里、哪些客户享有例外政策。 把这些具体知识接进来，就是 AI 落地的“最后一公里”。
这最后一公里通常卡在三个地方：
- 数据。 企业的数据分散在 ERP、CRM、仓储系统、表格和邮件里，口径不一致，权限各不相同。AI 要回答“这张订单为什么还没发货”，就得能安全地读到订单、库存和物流数据。
- 流程。 真实的业务流程里有大量没写在文档上的规则和例外。例如，同样是采购申请，金额超过一定额度要总经理签字，某些供应商需要额外比价。这些规则只有在现场和一线人员一起梳理才能摸清。
- 系统。 AI 的建议要变成行动，就得写回业务系统：创建工单、更新库存、生成发票。接口是否稳定、失败时怎么处理、谁有权限执行，都需要工程上的判断。
a16z 的文章也指出，AI 智能体需要安全地连接企业内部的数据库、接口和工作流，还需要了解业务逻辑和历史记录；让一个智能体上岗，很像带一位新员工入职（来源）。传统的分工方式在这里往往不够用：产品团队离客户太远，看不到具体问题；实施顾问懂流程，但不一定能写代码、调模型；企业自己的 IT 团队懂系统，却未必熟悉大模型的特性和局限。FDE 的价值，就在于把“懂业务、懂系统、懂模型”这三件事放进同一个人或同一个小团队里。
例如，一家批发分销企业想让 AI 自动处理客户通过邮件发来的订单。演示时，模型能从一封格式规范的邮件里准确提取商品和数量；但到了现场，FDE 会发现客户用的是各自的商品简称，部分订单附带手写扫描件，还有一些订单需要先核对信用额度。只有把商品对照表、信用规则和异常转人工的流程都接进来，这个 AI 才真正能用。
FDE 和软件工程师、实施顾问、售前工程师有什么不同？
FDE 容易和几类相近岗位混淆。简单说，FDE 像实施顾问一样贴近客户，又像软件工程师一样亲手构建系统，而且对上线后的业务结果负责。
下表从几个维度比较这四类角色：
| 对比项 | 传统软件工程师 | 实施顾问 | 售前工程师 | 前线部署工程师（FDE） |
|---|---|---|---|---|
| 主要目标 | 把产品功能做好 | 按方案把系统配置上线 | 帮助客户做出购买决定 | 让 AI 在客户的真实业务中产生结果 |
| 服务对象 | 所有客户 | 签约项目中的客户 | 潜在客户 | 一个或少数重点客户 |
| 工作地点 | 公司内部 | 客户现场或远程 | 以拜访和演示为主 | 大量时间在客户现场 |
| 典型产出 | 产品代码和功能 | 配置、培训、上线文档 | 演示、概念验证、技术方案 | 生产级应用、数据管道、系统集成 |
| 写代码的程度 | 很深 | 较少，以配置为主 | 中等，偏演示 | 很深，且面向生产环境 |
| 成功标准 | 功能质量与稳定性 | 按时按预算上线 | 赢单 | 客户业务指标改善、用量增长 |
| 与产品的关系 | 构建产品 | 使用产品 | 展示产品 | 使用产品，并把现场经验反馈给产品 |
不同公司对这些岗位的定义并不完全一致，上表反映的是常见分工，仅供参考。
一名合格的 FDE 需要哪些能力？
FDE 的能力要求是“T 型”的：工程能力要深，业务理解和沟通能力要宽。最稀缺的不是某一项技能，而是在模糊、多变的客户环境里独立把事情推进下去的能力。
从 Palantir 的岗位描述和 Anthropic 的招聘要求来看，可以归纳为五类能力：
- 扎实的工程能力。 能写面向生产环境的代码，能搭数据管道、做系统集成。Anthropic 的招聘页面要求有在生产环境中使用大模型的经验，包括提示词设计、智能体开发和评估方法，并熟练使用 Python（来源）。
- 快速学习陌生领域。 今天面对的是制造企业的质检流程，下个月可能是物流公司的调度系统。Palantir 把“快速掌握不熟悉的系统、领域和代码库”列为 FDE 需要具备的能力之一（来源）。
- 把业务问题翻译成技术方案。 能听懂业务人员的抱怨，追问出背后的真实问题，再判断哪些交给 AI、哪些用规则、哪些干脆不做。
- 沟通与信任建立。 FDE 要同时面对一线员工、IT 部门和管理层，还要协调自己公司的产品团队。Anthropic 的招聘页面明确期待 FDE 能自主工作、在不确定中保持状态，并具备良好的沟通能力。
- 对结果负责。 FDE 的工作不在演示成功时结束，而是要跟踪系统上线后的稳定性和业务效果，并把可复用的做法总结成方法，反馈给产品团队。
企业如何与 FDE 合作，或培养自己的“内部 FDE”？分步指南
对大多数中小企业来说，模型公司的 FDE 未必会直接上门。但 FDE 的工作方式完全可以借鉴：无论是与外部团队合作，还是从内部培养，核心都是让懂业务的人和懂技术的人在同一个具体问题上并肩工作。
第 1 步：先选一个具体、可衡量的业务问题。 不要从“我们要用 AI”出发，而是从“订单录入每天占用三个人”“月底对账要花一周”这样的具体痛点出发。OpenAI 对其部署服务的描述也是先做聚焦的诊断，再集中攻克少数几个优先流程（来源）。
第 2 步：提前准备好数据和系统访问。 FDE 最常见的等待，是等数据和权限。合作开始前，就应明确需要接入哪些系统、由谁审批访问权限、哪些数据不能出企业，避免工程师到场后无事可做。
第 3 步：指定一位业务负责人，全程参与。 外部 FDE 再能干，也不了解你的例外规则和潜规则。企业需要一位熟悉流程、有决策权的业务负责人，每周和 FDE 一起看进展、回答问题、拍板取舍。
第 4 步：在现场共同构建，小步快跑。 让 FDE 坐到业务部门旁边，先做一个能处理真实单据的最小版本，再根据一线反馈逐步完善。每一轮迭代都应该用真实数据检验，而不是只看演示效果。
第 5 步：上线时同步建立运维与交接机制。 明确系统出问题时谁来处理、模型或流程调整由谁决定、操作日志放在哪里。外部团队撤离前，应完成文档、培训和权限交接，确保系统不依赖某一个外部人员。
第 6 步：从合作中培养内部 FDE。 挑选一两位既懂业务又愿意学技术的员工（例如 IT 部门里常跑业务现场的工程师，或熟悉数据的业务骨干），让他们全程跟随外部团队，从第二个项目开始逐步主导。内部 FDE 的价值在于，下一个 AI 项目不必再从零开始。
关于前线部署工程师（FDE）的常见问题
FDE 和外包开发有什么区别？ 外包开发通常按需求文档交付功能，需求由客户写清楚；FDE 则和客户一起发现和定义问题，对业务结果负责，并依托现成的平台和产品构建方案，而不是从零开发。
中小企业需要专门招聘 FDE 吗？ 不一定。中小企业更现实的做法是在与外部团队合作时，让内部骨干深度参与，逐步培养出一到两位兼具业务和技术能力的“内部 FDE”。
FDE 岗位需求增长这么快，会是一时的热潮吗？ 岗位名称可能会变化，但这一角色背后的需求很难消失：只要模型是通用的、业务是具体的，就需要有人把两者接起来。随着工具成熟，部分集成工作会变得更容易，但理解业务和对结果负责的部分仍然离不开人。
评价一次 FDE 合作是否成功，应该看什么？ 关键看三点：系统是否真正投入日常使用、约定的业务指标是否改善、外部团队离开后企业能否自行维护和扩展。只看演示效果或交付了多少功能，往往会高估成果。
参考资料
- Dev versus Delta: Demystifying engineering roles at Palantir，Palantir 官方博客，页面未标注发布日期（2026 年 11 月访问）
- A Day in the Life of a Palantir Forward Deployed Software Engineer，Palantir 官方博客，页面未标注发布日期（2026 年 11 月访问）
- Why Forward-Deployed Engineers Are in High Demand，eWeek，2025 年 11 月
- OpenAI launches the Deployment Company，OpenAI，2026 年 5 月
- Forward Deployed Engineer（招聘页面），Anthropic，2026 年 11 月访问
- Services-Led Growth，a16z，2025 年 6 月
