前沿部署工程师和软件工程师编写的是同一种生产代码。他们的区别在于为谁构建、代码运行在哪里，以及由谁来判定是否成功。
简短回答：前沿部署工程师（FDE）为单一客户构建，通常在客户的环境中工作，并以系统上线和业务成果来衡量。软件工程师为所有客户使用的产品构建，并以交付、可靠性和规模来衡量。
| 前沿部署工程师 | 软件工程师 | |
|---|---|---|
| 为谁构建 | 一次服务一个客户 | 所有客户 |
| 代码运行位置 | 通常在客户的环境或部署层 | 厂商的产品代码库 |
| 完成的定义 | 客户上线并达成约定的业务成果 | 合并、发布，并对每个用户保持稳定 |
| 客户接触 | 每天，常常在现场 | 通常间接，往往经由产品经理过滤 |
| 需求 | 在现场发现，通常没有文档 | 通常通过产品流程形成 |
| 与路线图的关系 | 用一线发现反哺路线图 | 执行路线图 |
要点总结：
- 出差：FDE 招聘启事通常写明 25% 到 50% 的出差比例（在我们样本中写明数字的 52 条招聘启事中，中位数为 40%）。软件工程师的招聘启事很少提及出差。
- 薪酬：在 Levels.fyi 上，美国 FDE 报告的中位数为 216,250 美元，而软件工程师约为 197,000 美元（2026 年 10 月）。FDE 样本较小且偏向高薪公司，因此这一差距作为薪酬溢价的证据并不充分。
- 代码：FDE 的代码只服务于一个客户，项目结束后需要在客户那边找到接手人。能带回产品团队的，是代码背后的模式。
- 最棘手的障碍：一个没有 API、且登录绑定到用户自己机器的客户 Web 应用。
前沿部署工程师和软件工程师有什么区别？
开创并推广了现代 FDE 模式的 Palantir 这样表述：产品工程师是“一项能力，服务众多客户”，而前沿部署工程师是“一个客户，用上众多能力”，引自 The Pragmatic Engineer。
举一个示例性案例（我们的合成案例）：一家 AI 厂商在同一周招聘了两名工程师。第一位加入产品团队，他们的一周被产品所界定：一个熟悉的代码库、提前一个季度排好的路线图，以及以一个能对所有人稳定运行的合并变更为成功标准。第二位被派往孟菲斯的一家货运经纪公司，那里的调度员依赖一个没有 API、且使用硬件令牌认证的承运商门户。需求写着“调度员不再重复录入装载确认”，完成的定义是与运营负责人商定的上线日期，而最难的环节往往是一个等待客户安全团队审批的权限申请。
这两种工作也相互滋养。PostHog 的工程博客用一张图描述了这一点：FDE 修建通往产品目标之地的“碎石土路”，而软件工程师则将其铺成供接下来的十位客户使用的“柏油高速公路”。完整的循环从单个客户的现场延伸回每一位客户：
FDE 尚未成为一个标准化的职位名称，因此两种角色之间的界限因公司而异。有些公司用它指代深度技术性的部署工作，另一些公司则用它指代更接近解决方案工程的工作。The Pragmatic Engineer 对 OpenAI 的报道划出了一条实际的界限：那里的解决方案架构师倾向于使用匿名化数据在线下构建 MVP，而 FDE 则使用客户的工具直接在客户基础设施上编写代码。当职位名称模糊不清时，文章开头提到的三个问题仍然可以厘清这份工作：代码为谁而写、在哪里运行、由谁签字验收。
如果你正在权衡的岗位更接近解决方案工程，售前工程师的对比可以说明这条界线在哪里：
FDE vs 售前工程师
售前演示与售后生产代码的对比：薪酬、差旅、单笔交易中的交接，以及何时该招聘哪一种人。
打开对比
这些答案最清晰地体现在每位工程师一周时间的分配方式上。
前沿部署工程师每天做的事情，哪些是软件工程师不会做的？
前沿部署工程师每周有相当大一部分时间在客户现场或参加客户的会议，而软件工程师几乎不花时间在这些上面。截至 2026 年 10 月，给出具体数字的招聘信息通常将其定在 25% 到 50% 之间：
- 我们的样本：在 2026 年 10 月 7 日收集的 102 条 FDE 招聘信息中，有 52 条给出了百分比，范围从 20% 到 75%，中位数为 40%。
- Palantir：据 The Pragmatic Engineer 报道，FDE 约有 25% 的时间在客户现场。
- OpenAI：差旅比例高达 50%。
- Anthropic：伦敦、慕尼黑和巴黎的岗位为 25% 到 50%。
同一家公司的软件工程师招聘信息中则没有差旅这一项。差旅只是填满 FDE 一周的六项职责之一，而其中只有一项——产品反馈循环——与产品工程师的工作有重叠：
编码工作仍然会发生，在剩余的时间里进行。一位 Palantir 的 FDE 向 The Pragmatic Engineer 描述了这种节奏：
“大多数周里，我会花几天时间在客户现场工作……回到办公室后，我会花一些时间编写小的代码改动、审查 Pull Request。”
把这两位工程师放在第三周某个具有代表性的周二并排比较（这是我们合成的示例，并非实测数据）：
| 时间 | 软件工程师，产品团队 | 前沿部署工程师，孟菲斯 |
|---|---|---|
| 08:00 | 阅读隔夜的 CI 结果，领取下一张工单 | 列席调度交接班，了解货物确认单是如何被重新录入的 |
| 10:00 | 参加检索服务变更的设计评审 | 带货运代理的安全负责人过一遍 AI Agent 所需的权限 |
| 13:00 | 专注编码 | 根据调度员当天早上提取的样本货物，编写承运商门户连接器 |
| 16:00 | 审查两个拉取请求 | 与运营负责人一起运行上周失败的测试用例，并就下一次上线检查点达成一致 |
到周五，两人都已交付代码。这些代码接下来的去向，正是这两个职位再次分道扬镳的地方。
代码归谁所有，项目结束后会怎样？
FDE 通常在贴近客户环境的地方编写针对特定部署的代码，而软件工程师通常编写由供应商维护的通用产品代码。这条边界因公司而异：有些 FDE 直接在客户的基础设施中工作，而另一些则在供应商的平台上构建定制应用。
代码存放在客户账户中，在客户的凭证和安全策略下运行。招聘启事明确了要构建的内容：
- Anthropic：“将在生产工作流中使用的 MCP 服务器、子 Agent 和 Agent 技能。”
- OpenAI：FDE 负责“需求探索、技术范围界定、系统设计、构建和生产上线”。
这就引出了一个产品工程师很少需要问的问题：FDE 离开之后，谁来运行这些代码？如果诚实的答案是“只有供应商”，那么这个项目就建立了一种依赖关系。一次干净的交接，应该把连接器、它的测试以及客户方指定的负责人都留下来。
第二个产出是反馈给产品团队的备忘录。孟菲斯的连接器留在孟菲斯，但它背后的模式——一个在没有任何 API 的第三方门户内行动的 Agent——会被带回去。The Pragmatic Engineer 报道称，直到 2016 年左右，Palantir 的 FDE 数量都多于普通软件工程师，而在 Foundry 推出后，随着平台吸收了他们曾经手工构建的许多模式，很多人转入了产品工程岗位。
两个在代码和人员上交流如此密切的职位，自然会引出一个显而易见的问题：哪一个薪酬更高？
前沿部署工程师和软件工程师，哪个薪酬更高？
截至 2026 年 10 月，Levels.fyi 显示，美国前沿部署工程师的总薪酬中位数为 216,250 美元，比软件工程师约 197,000 美元的中位数高出约 10%。这些数据为自行申报的总额，包含股权和奖金。
| 衡量指标（截至 2026 年 10 月） | 前沿部署工程师 | 软件工程师 |
|---|---|---|
| 美国总薪酬中位数 | $216,250 | 约 $197,000（约 51,000 份提交） |
| 第 25 至第 75 百分位 | $178,750 至 $290,000 | $139,000 至 $282,000 |
| Palantir FDE 中位数 | 约 $255,000（227 份提交；第 10 至第 90 百分位为 $201,000 至 $620,000） | 不适用 |
| Google FDE 中位数 | 约 $404,000（L4 为 $321,000 至 L6 为 $629,000；仅 15 份提交） | 不适用 |
| Anthropic FDE 公布的基本薪资（伦敦职位） | £225,000 至 £255,000 基本薪资 | 不适用 |
| 美国所有软件开发人员的中位数工资（BLS） | 不适用 | $135,980（2025 年 5 月） |
来源：Levels.fyi 关于 FDE 和软件工程师两行的自报数据、Anthropic 伦敦职位的招聘信息，以及美国劳工统计局（U.S. Bureau of Labor Statistics）关于全行业薪资的数据。
请谨慎看待这 10% 的差距。该对比并未控制资历、地点、公司或提交样本的构成。FDE 的样本较小，且偏向 AI 实验室、Palantir 和 Google，这拉高了其中位数。Levels.fyi 的两个中位数也都远高于 BLS 统计的全行业水平。
薪资是看得见的差异。而 FDE 每周都要面对的那种差异，是产品工程师从来无需接触的一类系统。
FDE 会遇到哪些软件工程师很少碰到的阻碍？
将这两种工作区分得最清楚的阻碍，是一条经由客户使用但不拥有的 Web 应用程序运行的工作流——它没有 API，登录还绑定在某个人的机器上。在孟菲斯，这就是承运商门户。承运商拥有代码，每次登录都要经过承运商的 SSO，外加调度员桌上的硬件令牌。产品工程师永远不会遇到这个系统，因为产品测试针对的是 mock 和供应商自己的服务。而 FDE 的上线日期却取决于一个 AI Agent 在其中确认货载。
进入该系统有四种途径：
| 途径 | 会话所在位置 | 需要安装 | 人类可在任务中途接管 | 何时失效 |
|---|---|---|---|---|
| API 逆向工程 | 服务账号 | 否 | 否 | 门户更改其调用 |
| Playwright / 无头浏览器 | 供应商的服务器 | 否 | 否 | 身份验证需要用户的设备 |
| 桌面端 RPA | 用户的机器 | 是，按席位 | 是 | UI 布局发生变化 |
| 用户浏览器中的实时会话 | 用户自己的浏览器 | 否 | 是 | 没有人类会话可用 |
前两种途径在供应商能够持有自己的凭据时可行：服务登录、API 密钥，或脚本可独立开启的会话。它们可扩展、可测试。但当会话属于某个人时，它们就行不通了，因为 SSO cookie、MFA 推送和硬件令牌都存在于调度员的机器上。把这些凭据交给供应商，会在客户下一次安全审查中被记为问题项。
后两种途径则在个人自己的会话内运行。RPA 通过按席位安装以及跟随屏幕布局的脚本来触达它。Webfuse 则在用户活跃的浏览器会话内运行，因此 AI Agent 使用调度员自己的 SSO 和令牌运行，同时调度员可以随时介入。
Webfuse 是我们的产品，所以这是我们亲身了解的架构。它适合需要用户已认证实时会话的用户在场型工作流。对于使用服务凭据的无人值守任务，Playwright 或远程浏览器通常是更好的选择。完整架构在《如何将 AI Agent 连接到实时 Web》一文中有详细介绍。
像承运商门户这样的问题，也是工程师在从一个角色转向另一个角色时必须学习什么的最清晰指引。
哪些技能可以在两种角色之间迁移？迁移方向如何？
工程师在两个方向上都有流动，而代码技能无论哪个方向都能通用。PostHog 对市场的判断是，以“5 年以上工程或技术部署经验”作为入职门槛。变化的是围绕这一共同基础之上的技能形态：
- 软件工程师转 FDE：需要增加广度。在客户的身份提供商中配置 SSO 和基于角色的访问权限，管理工程师自己不掌控的云账户，以及基于客户真实案例构建评测集。
- FDE 转软件工程师：需要增加深度。维护一个系统而不是六个系统，为第十个客户做设计，而不是只为眼前这一个客户。Palantir 在 2016 年之后的转型表明，这个方向可以在大规模上走得通。
既然双向流动都可行，选择第一份工作更多是关于匹配度的问题，而不是职业层级的问题。
哪种职业更适合你？
如果你希望客户在场，选择前沿部署；如果你希望产品在场，选择软件工程。四个问题比一份职位描述更快帮你做出判断：
最后一个问题是大多数人会跳过的。最好的 FDE 工作以交接和一份备忘录收尾，因此你最引以为豪的代码将由别人来维护。如果这听起来像是一种损失，那么产品侧更适合你。如果觉得在换班会议上发掘需求比在工单里阅读需求更有意思，那么前沿部署更适合你。
结论
这两种角色是同一个循环的两半。FDE 弄清楚某一个客户需要什么，并在该客户的工作环境中把它构建出来。软件工程师则把从一线不断反馈回来的东西，转化为每个客户都能获得的产品。
在此过程中，有三点区分了这两种工作：
- 工作内容：FDE 有 25% 到 50% 的时间与客户在一起，并对上线日期负责。软件工程师则专注于一个代码库，并对一次发布负责。
- 代码：FDE 的代码留在某一个客户那里，需要在客户侧有维护者。软件工程师的代码由厂商维护多年。
- 困难之处：FDE 会接触到产品团队永远看不到的系统，比如一个藏在别人登录体系之后、没有 API 的门户。
薪酬水平足够接近，不应成为决定因素，而且工程师可以双向流动。选择你想要度过的一周，以及你希望被评判的成果。
孟菲斯例子中的两位工程师都在做真正的工程。一位在为接下来的十个客户修路。另一位在孟菲斯的一间会议室里，弄清楚这条路应该通向哪里。
方法论与数据来源
上文中的数据来自 2026 年 10 月初查阅的公开资料。文章中有两个部分——孟菲斯的例子和周二的表格——是我们自己的示例。
Levels.fyi 的中位数会随着新提交的数据而变动，因此薪酬数据可能与上文有所不同。
常见问题
Salome Koshadze
Community Manager
Manages content and encourages active participation within Webfuse.
将 AI Agent 连接到任何 Web 应用
无需注册，在浏览器中运行
准备好让你的 AI Agent 在真实网络上行动了吗？
无头浏览器为你的 AI Agent 提供一份网页的副本。Webfuse 则为它提供用户实际所在的会话——通过 MCP 实现，无需安装。
- 无需信用卡
- 永久免费套餐
- 快速设置
相关文章