上周，当大多数企业级 AI 的讨论还停留在基准测试和模型发布上时，OpenAI 和 Anthropic 共同为一个一年前在大多数公司还不存在的职位投入了 55 亿美元。
5 月 11 日，OpenAI 宣布成立 OpenAI Deployment Company，这是一家与 TPG、Goldman Sachs、Bain Capital、McKinsey 以及其他十五家合作伙伴共同组建的合资企业。该实体以 40 亿美元的承诺资本起步。第一个动作是一笔收购：Tomoro，一家应用 AI 咨询公司，拥有约 150 名前沿部署工程师和部署策略师，他们从第一天起就加入这家新实体。几天前，Anthropic 宣布与 Blackstone 和 Hellman & Friedman 成立一家类似的合资企业，估值 15 亿美元，由三家各出资 3 亿美元的创始投资人构成。
两家 AI 实验室。同一周。55 亿美元。两个实体都与核心授权业务分离。两者都围绕同一个角色构建。
值得追问的是，这两家公司对自己的产品究竟理解到了什么，才值得为一个不写模型、不训练模型、也不销售模型访问权限的部门投入 55 亿美元。
答案是：在客户那里创造价值的不是模型。模型是容易的部分。真正创造价值的，是坐在客户身边、把模型变成能实际运行的东西的那个人。
这个人如今有了名字。它就是前沿部署工程师。
两家 AI 实验室上周为一个 Palantir 在 2010 年创造的职位投入了 55 亿美元。他们这样做，是因为模型是容易的部分。难的部分，是把模型变成能在客户那里实际运行的东西的那个人。
这个角色并不新鲜。Palantir 在十五年前就发明了它，按照公司以北约音标字母为团队命名的惯例，内部称之为"Delta"。直到不久前，它在 Palantir 之外还只是个新奇事物。到了 2026 年，它已成为企业级 AI 的瓶颈。
这篇文章要讲的就是为什么。
一个无人占据的象限
我想把这个模型梳理出来，就像它如今在我脑海中的样子——这是经过几个月观察这个角色不断出现在各种对话中，以及一周前在旧金山 Propel26 大会上听了 Rippling 创始 FDE Kevin Bai 关于这一主题的分享之后形成的。
这个模型是一个 2x2 矩阵。一个轴是产品复杂度，从简单到技术深度。另一个轴是买方画像，从技术型到非技术型。
这个矩阵有四个象限。其中三个已有众所周知的答案。
技术型买方购买简单产品，走自助服务。他们读文档、自己实现、然后继续前进。
技术型买方购买深度技术产品，走标准工程流程。双方说同一种语言。API、文档和支持就足够了。
非技术型买方购买简单产品，走传统的专业服务。有一套成熟的打法：配置、培训、交接。Workday、SAP、Salesforce CRM，几代企业软件都活在这个象限里，并围绕它建立起了咨询行业。
第四象限是直到最近一直空缺的那个象限：非技术型买家试图采购技术深度极高的产品。买家无法自行实施。由于产品太新、太定制化，标准化的操作手册并不存在。标准工程模式不适用，因为买家无法明确说出自己想要什么。专业服务也不适用，因为目前还没有任何可以配置的东西。
这个象限没有原生的交付模式。而在 2026 年，这个象限恰恰是企业级 AI 所在的位置。
前沿部署工程师正是填补这一空白的角色。
买家确实是非技术型的，而且现在有了数据
“非技术型买家”这种说法听起来可能像是修辞上的托词。但事实并非如此。数据是明确无误的。
根据斯坦福大学和麻省理工学院对四个国家 6,000 名高管进行的调查，近 70% 的 CEO、CFO 和高级管理人员每周使用 AI 的时间不足一小时。28% 的人从不使用。而正是这些人，一边强制要求员工采用 AI，一边为企业级 AI 部署签署合同。
另一项 Foundry 2026 年 CIO 现状调查发现，40% 的 IT 领导者将“缺乏内部人才”列为执行 AI 战略时面临的首要挑战。德勤 2026 年全球技术领导力研究调查了 660 名高级 IT 高管，报告显示 81% 的 CIO 声称对部署和治理 AI 有信心，但其中 75% 的受访者同时表示“运营模式必须在未来的 12 到 18 个月内发生改变”。信心是表演性的，准备度却不是。
归根结底的情况是：签署 AI 合同的人，本人无法明确描述他们所购买的系统。组织内部通常负责将合同转化为现实的人，要么不存在，要么不堪重负。而所购买的系统的变化速度，超过了买家所经历过的任何采购周期。
这就是 2026 年企业级 AI 的结构性处境。几乎所有其他类别的企业软件在同样的采用阶段，买家的技术熟练度都要更高。早期 CRM 的买家懂销售。早期 ERP 的买家懂财务。早期数据仓库的买家懂报表。而早期 Agent 系统的买家不懂 Agent、检索、评测或护栏。他们只知道自己需要结果。
签署 AI 合同的 CEO 每周使用 AI 的时间不足一小时。负责交付的 CIO 说他们没有内部人才。系统的变化速度超过了他们明确需求的速度。
这就是此前无人占据的空白。
本应覆盖这一空白的四种角色，却都没有做到
更深层的结构性问题在于，为什么这个象限空缺了这么久。企业软件生态系统中已有四种成熟的角色，从纸面上看，每一种都应该是填补这一空白的候选者。但没有一种做到了。
内部团队会回避模糊不清的工作。这是理性的。内部工程师的考核标准是交付可规模化扩展的功能。为自家雇主的某一个客户做定制化工作，很少能在绩效评估中体现出色。所以他们回避这类工作。
咨询顾问只提供建议，不负责构建。经典的四大会计师事务所或三大咨询公司的模式产出的是战略、目标运营模式、转型路线图。这些都不是一个能运行的 AI Agent。交付物是一份演示文稿。这份演示文稿也许有用，但它不会把流程编码进软件中。
供应商的产品团队不会优先考虑一次性需求。产品工程的经济逻辑要求每一行发布的代码都要服务于不止一个客户。只有一个客户需要的能力，是对其他所有客户路线图的拖累。所以产品团队会说不行，而且他们说不行是对的。
解决方案工程师负责配置，但不负责创造。他们搭建集成、设置参数、运行演示。他们被训练在产品已有功能的范围内操作。当客户需要产品尚不具备的功能时，解决方案工程师会提交一个功能请求，然后回去准备下一场演示。
前沿部署工程师的定义，既在于他们是什么，也在于他们不是什么。这种对比足够鲜明，值得明确指出，因为这个头衔已经在市场上被滥用了。
FDE 不是：运行演示的人。为别人写工单让他们去构建的人。在客户和产品团队之间充当中间人的人。
这种区别不是表面文章。如果一家供应商只是把解决方案工程师改称为“前沿部署工程师”，却不改变其背后的权限和问责机制，那它卖给你的只是一个换标签的把戏，而不是一种不同的模式。
企业 AI 中投资回报率最高的工作，恰恰位于四种角色之间的空隙地带，而这四种角色都没有合适的激励去占据这个地带。
这是整个趋势中被低估的洞见。前沿部署工程师并不是一个新职能。它是那个愿意栖身于四种旧职能的结构性盲区之中，并愿意为那里发生的事情承担经济责任的人。
三顶帽子，一个人，一个客户
这个角色的运作机制非同寻常。
前沿部署工程师同时身兼三职，而且是在同一位客户面前。当客户被要求“做 AI”却没有具体方向时，他们要像顾问一样，找出组织内部真正的问题所在。当客户无法在三个看似可行的方案之间做出取舍时，他们要像产品经理一样，决定先构建什么。当他们坐下来真正动手构建并交付时，他们就是软件工程师。软件行业的大多数人只能做好这三件事中的一件，少数人能做好两件。而前沿部署工程师能同时做好这三件事，面对同一位客户，在同一个星期内完成。
这个角色的经济结构更加不同寻常。在传统的软件交付模式中，工作被分散到各个职能部门和客户账户之间。一名项目经理协调一个三到十人的团队。团队中的每个人同时服务多个客户。价值来自漫长的规划周期：项目启动、需求收集、设计阶段、构建阶段、测试阶段、上线。这种模式假设构建才是耗时的部分。
在前沿部署模式中，这些都不成立。一名工程师，专职服务一位客户，有时全职，有时兼职，在几周内完成构建和交付。没有项目经理。没有业务分析师。没有独立的设计阶段。工程师深入客户现场，理解内部的政治格局，挑选一个真正重要的问题，编写代码，部署上线，与真实用户一起迭代，然后转向下一个问题。
这之所以可行，是因为有了 AI，构建不再是耗时的部分。一名能力出众的工程师，配上合适的工具，可以在几天内搭建出一个可运行的 AI Agent。真正需要数月时间的，是弄清楚该搭建哪个 Agent：客户内部的政治版图、决策权归属、数据来源、可接受的失败模式、与人类的交接流程。这些都无法在需求文档中写清楚。
Palantir 联合创始人 Joe Lonsdale 直截了当地指出了这种不对称性：
“几名 FDE 在几天内完成的工作，原本需要数百名 IT 服务专业人员数月的劳动。”
传统软件交付模式之所以存在，是因为最初的瓶颈在于构建。如今瓶颈变成了理解该构建什么。模式必须改变。
招聘趋势背后的数字也反映了这一转变。根据 The Pragmatic Engineer 的数据，Indeed 上前沿部署工程师的职位招聘数量在 2025 年比 2024 年增长了十倍以上。同期，上市公司财报电话会议中提及该职位的次数从 8 次跃升至 50 次。Bloomberry 对 1,000 条 FDE 招聘信息的分析发现，基本工资中位数为 173,816 美元，70% 的职位提供股权。顶级实验室中高级职位的总薪酬在 35 万至 55 万美元之间，Palantir 的资深级别 FDE 总薪酬超过 63 万美元。
这是当今软件行业薪酬最高的面向客户的角色。
FDE 到底做什么（以及何时做）
三顶帽子的画像。这个角色在实践中到底做什么？
前沿部署工程师构建三种截然不同的东西，理解这种区别很有价值，因为它会改变你对这个角色的预期。
第一种是分析类工作。FDE 走进一家客户公司，其数据分散在六七个互不连通的系统里，FDE 要把这些数据转化为运营人员真正可以据此行动的报告。Salesforce 的数据在一处，支持工单在另一处，还有一个没人完全信任的财务系统，以及工业传感器的导出数据。FDE 将它们统一起来，构建出一个把原始数据转化为对真实问题之答案的层。这不是一个仪表盘项目，而是对一个组织盲区的解决。
第二种是运营类工作。FDE 把今天存在于某人脑中、或某个脆弱的 Excel 文件里的业务流程，编码成可运行的软件。这正是我上周描述的运营 AI 领域，也是企业 AI 价值最集中的地方。一个如今要占用某人二十个小时的月度业务评审，变成一个 AI Agent 在每月一号自动运行的工作流。一个需要跨三个团队四次交接的客户入驻流程，变成一条确定性的流水线。产出不是一份交付物，而是一个持续运行的系统。
第三种，也是最有价值的，是混合类工作。分析理解与流程自动化的结合。Agent 读取数据、做出推断、采取行动、然后汇报结果。这是 FDE 拿高薪的原因所在。也是企业软件生态系统中没有任何其他角色被设计来产出的工作。
一个关于这在实践中如何运作的具体例子，来自 Gergely Orosz 最近一篇关于 OpenAI 内部 FDE 职能的文章。该团队的前沿部署工程负责人 Colin Jarvis 带着一名 FDE 前往爱荷华州的一个农场，与农民直接合作，为 John Deere 完成一个项目。此前的流程是 John Deere 逐个给农民打电话，人工提供杂草防治建议。客户希望把这种建议规模化，转化为个性化的洞察，以最大化利用一项新的低农药防治技术，并赶在下一个种植季之前上线。
FDE 没有写一份战略文档。他们坐在田间，梳理工作流，构建系统，部署上线，赶在作物播种之前完成。而在这个过程中，这些工作反哺了 OpenAI 的 Realtime API，让所有其他客户的产品都得到改进。一个客户为这次部署付费，而所有客户都从中学到的经验中受益。
这正是让这个角色在经济上站得住脚的闭环：FDE 专职服务于一个客户，但经验教训会回流到产品。Palantir 在他们对这一角色与普通产品工程师区别的描述中，精准地捕捉到了这种不对称性：
“普通开发者的焦点是：一个能力，服务多个客户。Delta 的焦点是：一个客户，构建多种能力。”
Dev 优化的是单一能力，并覆盖每一位购买产品的客户。FDE（在 Palantir 最初称为 "Delta"）则恰恰相反：多种能力，服务一个客户。当这些能力随着时间推移沉淀为可复用的模式，并回流到公司的 Dev 一侧时，这套体系才能运转起来。如果没有这个反馈回路，FDE 只是一个高薪顾问；有了它，FDE 就是连接客户现实与产品路线图之间的桥梁。
这个角色在客户关系内部也有清晰的生命周期。FDE 不是交易达成后才出现的交付工程师。他们存在于交易之前、之中和之后。
在交易达成之前，FDE 会参与售前对话。他们帮助客户界定什么才是真正可行的。他们为项目划定范围，消除那些通常要到合同签署后才会暴露的意外。仅这一点就是竞争优势：一个能在评估阶段把真正的建设者带到谈判桌上的供应商，能拿下那些竞争对手因“我们需要和工程团队确认一下”而输掉的单子。
在交易进行期间，FDE 负责从需求探索到交付的全过程。他们与客户共同构建，交付可运行的系统，并对最初承诺的成果负责到底。
上线之后，FDE 也不会消失。他们在同一客户账户内发掘扩展机会，把观察到的模式反馈给核心产品，并通过让部署随客户的现实持续演进，来推动长期粘性。在 OpenAI 内部，这个循环已经制度化：与 Research 团队每两周进行一次知识分享，每两周与产品负责人进行一次汇报，还有一个所有 FDE 都参与贡献的内部 "FDE Field notes" Slack 频道。这个角色不只是创造营收，它还创造情报。
Palantir 的一份招聘广告用一句值得铭记的话，描述了要做到这一切所需的资历：
“FDE 的职责与创业公司 CTO 相似：小团队，端到端执行高风险项目。”
这不是一个入门级岗位。薪酬水平反映了这一点，合格候选人的稀缺也印证了这一点。
## 买方如今正在付费购买的依赖
六周前，CIO Magazine 发表了一篇文章，其标题本身就概括了这一转变。标题是 "Anthropic's financial agents expose forward-deployed engineers as new AI limiting factor"（Anthropic 的金融 Agent 揭示前沿部署工程师成为 AI 的新限制因素）。
这篇文章的核心观察是：
“鉴于企业自身的数据质量问题以及使用 AI 模型的复杂性，企业 CIO 们越来越多地为 AI 供应商 FDE 的服务付费。”
措辞很重要。FDE 已经不再是隐藏在许可证中、被消化掉的成本。它已经成为一个独立的账单项目。客户知道自己在为工程师付费，供应商也知道自己在就工程师收费。这种关系如今是软件许可证与服务的混合体，而服务部分已不再是可有可无的边角。
这就是 OpenAI 和 Anthropic 刚刚用 55 亿美元明确表达的事实。部署公司不是专业服务部门。它是一个独立的载体，与咨询公司和私募股权共同出资，旨在规模化一个无法融入 AI 实验室原有利润结构的角色。信号是明确的：模型访问本身并不能创造企业价值，实验室现在愿意用资本公开承认这一点。
本文必须包含的质疑
在 2026 年撰写关于前沿部署工程师的文章时，如果不纳入对这一角色最严肃的公开批评，那将是不诚实的。
风险投资公司 Flybridge 发表了一篇题为《为什么 95% 的初创公司完全搞错了前沿部署工程师角色》的文章。其论点很精确。大多数初创公司雇佣 FDE 作为产品市场匹配薄弱、平台脆弱或低价值部署的拐杖。两种失败模式，都有量化数据：
“算上全部成本，一名 FDE 的雇佣成本通常为每年 22 万至 40 万美元。如果这个人大部分时间都花在 10 万美元以下的客户上，单位经济效益几乎立即崩溃。”
以及：
“除非这是一项能够可信地带来 100 万美元以上成果的投资，否则不要为 ACV 低于 100 万美元的交易进行前沿部署。”
Flybridge 所描述的失败模式是真实存在的。一名昂贵的工程师被部署到小客户上，构建脆弱的定制系统。这些定制系统无法泛化。供应商积累了技术债务。客户得到一个无人能够扩展的可用试点。供应商从软件业务滑向服务业务，其毛利率比咨询公司还要差。
以及当你根本不需要一名 FDE 的时候
这个问题的买方与卖方如出一辙。并非每一次部署都能从前沿部署工程师中受益，在情况不需要时要求一名 FDE 本身就是一种错误。三种模式可以识别出其他角色才是正确答案的情形。
如果你需要的是一个定义明确的功能请求，正确的对接团队是供应商的产品团队。功能请求顾名思义就是一项已被明确、排定优先级并纳入日程的工作。它不是探索性的工作，而是在已知范围内执行的工作，而产品团队正是为交付这类工作而构建的职能。
如果你需要的是纯粹的实施工作，即操作手册已经存在、变量已知，那么正确的团队是传统的专业服务部门。配置 CRM、集成已知的数据源、就产品已支持的功能培训用户。这些都不需要构建者，而需要配置者。专业服务项目的单位经济效益以已知的操作手册为前提，这也是它们能在较低 ACV 下运作的原因。
如果你需要的是一个长期可扩展、能在同一垂直行业的众多客户之间复用的系统，正确的团队是供应商的工程职能部门。由 FDE 进行的定制化部署恰恰与你的需求相反。你想要的是能够进入平台、并在未来五年内服务整个客户群的代码。
还有第四个值得理解的区分，因为它更深入地触及了 AI 供应商格局的核心。OpenAI 和 Anthropic 现在都在前沿部署工程职能之外，同时运行着一个解决方案架构师职能。Orosz 精准地描述了二者的区别：解决方案架构师是顾问性质的。他们很少在客户的基础设施上编写代码。他们构建最小可行产品或概念验证，通常使用匿名化或合成数据。而前沿部署工程师则是亲力亲为的。他们在客户的真实基础设施上、使用客户的真实数据、在生产环境中编写代码。
如果你的目标是评估一家 AI 供应商的产品究竟能否解决你的问题，解决方案架构师就足够了。如果你的目标是在生产环境中真正解决问题，你需要的是 FDE。混淆这两者是 2026 年企业 AI 预算中最昂贵的错配之一，而且正在大规模发生。
a16z 在一篇题为《万物 Palantir 化》的文章中表达了同样的观点：
“过度转向前沿部署而缺乏强大产品主轴的公司，可能无法产生规模递增收益和持久护城河。”
这两种警告都是正确的。前沿部署工程师不是一种通用模式。它是对特定象限的结构性回答。它在两个条件同时成立时才有效：底层产品拥有真实的主轴，定制化部署能够反哺其中；并且定制化部署与产品路线图之间存在明确的反馈回路。
Palantir 在 2016 年的“Foundry 时刻”是经典案例。在 2016 年之前，Palantir 的“Delta”工程师（FDE 的最初名称）比“Dev”工程师（构建产品的工程师）还要多。随着 Foundry 的推出，公司跨越了拐点。多年前沿部署积累的经验结晶为一个产品平台。定制化工作变得可复用。该角色在人员构成中的占比从多数转变为少数。
没有这个拐点，一个以 FDE 为主的组织就是一家披着软件外衣的咨询公司。有了它，它就是最具防御性的平台业务。ServiceNow 目前的毛利率为 79%。Workday 为 75%。这两家公司都是通过吸收早期前沿部署工程师的经验才达到这一水平的。
问题不在于这个角色是否存在，而在于每一个采用它的组织是否拥有使其规模化所需的主轴和反馈回路。
这对买方而非供应商意味着什么
大多数关于前沿部署工程师的报道都是写给那些正在决定是否组建团队的供应商看的。对于本通讯的读者而言，更有用的问题是：这对买方意味着什么。
如果您是一位负责在未来十二个月内在组织中部署 AI 的非技术高管，有三个诊断性问题值得向您的供应商提出。
1. Who is sitting on the other side of the table?
如果您交谈的对象是一位解决方案工程师，能够演示产品，却无法构建缺失的功能，那么您面对的是矩阵中典型的专业服务象限。如果您的问题范围明确，且产品已经覆盖了它，这可能已经足够。但如果您的问题需要将业务意图转化为可运行的软件，这就不够了。需要留意的信号是：当您描述一个具体的边缘案例时，对面的人是记下笔记作为功能请求，还是伸手去拿笔记本电脑？
2. Does your vendor have an FDE function, or a Professional Services function?
这两个词越来越多地被混用，但它们不应被混用。专业服务团队是在产品已有功能的范围内进行配置。而前沿部署工程师则被允许构建产品尚不能实现的功能，并将该能力推回产品路线图。前者是实施，后者是共创。请明确地问：“你们将分配给我的部署人员，是否有权编写能发布到你们平台中的代码？”这个答案能立刻区分这两种职能。
3. What are you actually paying for?
如果您的合同结构是许可证加按小时计费的服务，那么您购买的仍然是旧模式。如果您的合同是围绕成果构建的，嵌入式工程师的费用已包含在价格中，那么供应商已经以一种他们一年前不会接受的方式承担了交付责任。谁承担交付风险的不对称性，是判断您的交易实际处于矩阵中哪个位置的最清晰信号。许可证加小时数将风险放在您身上。成果加嵌入式工程师则将风险放在他们身上。
这三个问题不会通过营销材料得到答案。它们会通过对话的结构、供应商带进房间的人，以及合同的撰写方式得到答案。前沿部署工程师从根本上说并不是一种招聘趋势。它是检验供应商是在向您出售软件，还是在向您出售某种真正能在您组织内运行的东西的最清晰可行的测试。
核心要点
如果您只读本文的一个部分，请读这一部分。
过去两周的市场信号清晰可见。OpenAI 向一家部署公司投入了 40 亿美元。Anthropic 向一个类似的业务投入了 15 亿美元。Salesforce 正在明确招聘 1,000 名应届毕业生进入前沿部署岗位。Indeed 上的相关职位发布同比增长了十倍。这个角色在不到二十四个月的时间里，从 Palantir 的独特做法变成了企业级品类。
结构性原因并不是模型变得更好。模型会持续进步，而模型越好，瓶颈已经转移这一事实就变得越明显。
瓶颈在于：一边是拥有真实问题的非技术型买家，另一边是具备潜在能力解决该问题的深度技术型产品，而两者之间需要翻译。这种翻译无法靠一份演示文稿完成，无法靠一个没有动力承担模糊性工作的内部团队完成，也无法靠一个只受过培训、只会配置现有功能的解决方案工程师完成。它只能由一个身处客户内部、对结果负责、并且亲手写代码的人来完成。
Kevin Bai 上周发言时说得很直白：
“未来不仅仅是更好的模型，更是更好的部署。而 FDE 正是通往那里的路径。”
2026 年企业 AI 的未来，不在于谁拥有最好的模型，而在于谁能坐在客户身边，把模型变成真正能运行的东西。瓶颈已经转移，实验室们已用 55 亿美元的资金承认了这一点，而填补这一空缺的角色终于有了名字。
那个空白象限有了它的原生物种。