AI 岗位图谱：FDE 与大模型应用工程师
一句话定位：把 AI 落地时代最热的两个工程岗——FDE（Forward Deployed Engineer，前线部署工程师） 和 大模型应用工程师（LLM Application Engineer）——讲清楚：各自干什么、和相近岗位怎么区分、值不值得去、怎么分辨好岗和坑岗；并把它们与本知识库已有的「Agent 架构师」讨论接成一张岗位 title 对照图。适合正在看 JD（Job Description，招聘岗位描述）、考虑转岗、或想知道”AI 到底在哪儿真赚钱”的人。
怎么来的：2026-09 与 AI 的两轮问答（“AI 的 FDE 工程师是干什么的""大模型应用工程师这个岗位如何”）沉淀而成。落盘前按本知识库”先评分再吸收”的规矩打了分（8 / 10，见 § 6），并用公开报道核实、补充了 2025–2026 年的关键事实：OpenAI 与 Anthropic 在 2026 年 5 月各自成立 FDE 型合资公司、a16z 关于”用毛利换护城河”的争论、Palantir 的”碎石路到高速公路”反馈回路。
目录
- 0. 先看一张岗位 title 对照图
- 1. FDE：扑到客户现场的工程师
- 2. 大模型应用工程师：把发动机装进车里的人
- 3. 三种站位：应用工程师 / FDE / Agent 架构师
- 4. 常见误区
- 5. 与本知识库其他章节的关联
- 6. 来源与局限性
0. 先看一张岗位 title 对照图
同一件事——“把大模型能力做成能用的系统”——在不同语境下有一堆叫法。先把它们摆到一张表里，后面两节就不会被名字绕晕：
| 站位 | 海外常见 title | 国内常见 title | 培训圈造词 | 核心差异 |
|---|---|---|---|---|
| 在总部做产品里的 AI 功能 | AI Engineer / Applied AI Engineer / LLM Engineer | 大模型应用工程师 / 大模型应用开发工程师 / AI 应用工程师 | ”AI 全栈工程师” | 面对 PR 和需求文档，交付产品功能 |
| 扑到客户现场把 AI 落地 | Forward Deployed Engineer（FDE） / Forward Deployed AI Engineer / Deployment Specialist | 前线部署工程师 / 驻场 AI 工程师（国内 title 未固定，常混在”解决方案工程师”里） | —— | 面对客户脸色，交付能跑的系统并对结果负责 |
| 设计整套 Agent 系统 | LLM Systems Engineer / Staff AI Engineer / AI Platform Engineer | 高级大模型应用工程师 / AI 平台架构师 | ”Agent 架构师” | 设计可控、可观测、可恢复、可扩展的自治系统（详见 Agent 架构师能力地图） |
| 训练、微调、评测模型本身 | ML Engineer / Research Engineer | 算法工程师 / 大模型算法工程师 | ”大模型训练师” | 要数学与科研底子 |
| 推理框架、部署、GPU | ML Infra Engineer / Inference Engineer | AI 基础设施工程师 / 推理优化工程师 | —— | 底层与系统方向 |
| 定义做什么 | AI Product Manager | AI 产品经理 | ”AI 产品架构师” | 不写代码，靠业务嗅觉 |
💡 看表的方法：前三行用的是同一套技术栈（Prompt、RAG、Function Calling、Agent、Eval），差别只在站在哪儿、对什么负责。所以本文把”大模型应用工程师”和”FDE”放一起讲，§ 3 再把”Agent 架构师”接上——三者是一条职业路径上的三个站位，不是三个行当。
术语先解释（后文直接用）：
| 术语 | 大白话 |
|---|---|
| JD（Job Description） | 招聘网站上那段”岗位职责 + 任职要求” |
| PR（Pull Request） | 代码合并请求，总部研发的日常工作单位 |
| SDK（Software Development Kit） | 厂商打包好的开发工具包，比如各家模型的官方调用库 |
| Prompt | 给模型的指令文本；Prompt 工程就是把指令写到模型稳定听话 |
| few-shot（少样本提示） | shot 在这里是”例子”：在 prompt 里先给几个示范再让模型做。对应 zero-shot（不给例子直接问）、one-shot（给一个）。例如判断评论情绪，先列三条”评论 → 正面 / 负面 / 中性”，再放待判断的那条。模型不仅学到任务是什么，还学到你要的输出格式和判断尺度（“包装破了但东西没坏”算中性），比用文字描述规则更管用，代价是 prompt 变长、多花 token。本知识库里叫”少样本提示”，完整讲法与黄金法则见 02 提示词工程 § 3.1 |
| RAG（Retrieval-Augmented Generation，检索增强生成） | 先从你自己的资料库里查出相关段落、再让模型照着答，模型就不会瞎编公司内部的事 |
| Function Calling / Tool Use | 让模型能”调用工具”——查数据库、发请求、跑代码，而不只是输出文字 |
| MCP（Model Context Protocol） | 一套让模型接工具的通用插头标准（详见 Function Calling 与 MCP 工程指南） |
| Agent | 能自己规划、调工具、看结果、再决定下一步的 AI 程序（详见 什么是 Agent） |
| Eval（evaluation，评测） | 给 AI 系统出一套考卷加一套评分标准。大模型每次输出都可能不一样，光靠感觉说不清”改完变好了没”，Eval 把感觉变成分数。类比：单元测试之于普通代码，区别是 AI 的答案不是精确匹配、需要打分（详见 Eval 测评体系）。下面五行是它的分支，按”考试在什么时候、谁判卷”串起来 |
| ↳ 离线测试集（Offline Eval Set） | 上线前在开发机上考：事先准备好一批题目和标准答案（比如 200 个用户问题 + 业务专家认可的回答），每次改动都重考一遍。类比：驾校模拟考题库（详见 Eval § 2.1） |
| ↳ 自动打分 / LLM-as-Judge | 谁判卷：两百道题人工看太慢，所以自动判。有唯一答案的用精确匹配，格式类用规则检查，开放式回答（客服话术等）就把问题、标准答案、AI 回答一起发给另一个强模型让它打 1~5 分——这就是 LLM-as-Judge（用 AI 当裁判）（详见 Eval § 2.3） |
| ↳ 回归测试（Regression Test） | 防老毛病复发：修好一个 bug 别把别的弄坏。做法是把历史上答错过的题都存进回归集，每次改动重跑。AI 应用里尤其重要——改一句 prompt 可能让二十个原本答对的问题突然答错（详见 Eval § 7.2） |
| ↳ A/B 测试 | 上线后在真实用户身上考：随机分两组，一组用老版本 A、一组用新版本 B，比业务指标（解决率 / 人工转接率 / 点击率）。类比：一家店开两个收银口跑新旧流程，看哪边排队短（详见 Eval § 2.2） |
| ↳ 数据闭环（Eval 与数据闭环能力） | 把上面几样串成一个圈：线上跑出来的真实提问 → 记下答错的、用户不满意的 → 加进离线集和回归集 → 改 prompt / 换模型 → 再上线。没闭环的团队测试集永远是上线前那两百题，线上新问题测不到；有闭环的团队每周都在长新题、越用越准。它”最保值”的原因：模型厂商能替你把调用变简单，却不知道你的用户在哪些问题上被答错了，这份数据只有你有（详见 Eval § 6、数据飞轮） |
| POC（Proof of Concept，概念验证） | 先做个小样证明”这事能成”，还没上线 |
| P95 延迟 | 100 次请求里第 95 慢的那次用了多久，比平均值更能反映用户的真实体验 |
| benchmark（基准测试 / 公开跑分） | 统考：学术界和厂商准备的固定公开题库（数学题集、代码题集、常识问答集），所有模型考同一套、发排名。新闻里”某模型某测试 90 分超过 GPT”说的就是它。和 Eval 的区别：benchmark 考通用能力，Eval 是你公司自己出的卷子，考在你的业务上能不能用——统考第一的模型接进客户的 SAP 之后照样可能答不对客户的问题，而客户付钱是为后者。另有通病：题库公开后厂商会拿题去训练，分数虚高，行内只当参考 |
| CRUD | 增删改查，普通业务系统的基本功 |
| ERP（Enterprise Resource Planning，企业资源计划） | 管一家公司”钱和货”的大型软件：财务、采购、库存、生产、人事都在里面。可以理解成公司的总账本 + 总仓库 |
| SAP | 德国软件公司，也是它那套 ERP 的名字，大公司几乎都在用；FDE 说”打通 SAP”，意思是把客户的财务 / 库存数据从这套系统里取出来喂给 AI |
| Oracle | 美国软件公司，最出名的是它的数据库；很多企业的核心数据（银行账户表、订单表）就存在 Oracle 数据库里，它也卖 ERP |
| 自研系统 | 客户公司自己的程序员写的内部系统（订单系统、客服后台、审批流），外面买不到、只有这家有；常见状态是文档不全、写它的人已离职。这三样合起来就是”客户的老系统”——AI 要回答”这个客户上月买了什么”就得从里面取数，而它们往往有二十年历史、字段命名混乱、接口没文档、还在内网里，所以”打通数据”是 FDE 最花时间的一步 |
| SA（Solutions Architect，解决方案架构师） | 给客户画架构图、讲方案的人，通常不亲手写生产代码 |
| HITL（Human-in-the-Loop，人在回路） | 关键步骤让人来确认，AI 不能自己拍板 |
| playbook | 打法手册——把一次成功交付的套路写成下次能照抄的流程 |
1. FDE：扑到客户现场的工程师
1.1 一句话定义与词源
FDE 不坐在总部做通用产品，而是”扑到客户现场”，把公司的通用 AI 能力（模型、平台、SDK）亲手改造成这家客户真正能用起来的东西，并对最终跑通负责。
词源：“Forward Deployed”是军事用语，指部队前出部署到前线而不是待在大本营。这个岗位名由 Palantir 在 2010 年代初发明——它的客户是情报和国防机构，需求不能公开说、数据不能拿出来，Palantir 只能把有安全许可的工程师直接派进客户机构里干活。Palantir 内部把这批人叫 “Delta”，把负责识别客户最值钱问题的领域专家叫 “Echo”；在 2016 年前后，Palantir 的 FDE 人数一度多于传统软件工程师。
生活类比：总部研发像中央厨房——按标准菜谱批量出品；FDE 像派到客户家里的驻店厨师——用客户冰箱里现有的食材（脏数据、老系统）、按客户的口味（业务流程）、当场把菜做出来，还要教客户家的阿姨以后自己做。
中文叫法：前线部署工程师 / 前置部署工程师 / 前向部署工程师 / 驻场 AI 工程师，目前国内没有统一译名，本文统一写 FDE。
1.2 日常七件事
| 阶段 | 具体工作 | 一句话点评 |
|---|---|---|
| ① 挖需求 | 不是听客户说”我要个 AI 助手”，而是坐到客户工位旁看他一天怎么干活，找出真正值钱的那个环节 | 对应 Palantir 的 “Echo” 工作：先找到最值钱的问题 |
| ② 出原型 | 几天内做出能点的 demo（不是 PPT），当场给业务方看效果 | 原型是用来激发需求的——客户往往不知道大模型能干什么 |
| ③ 打通数据 | 对接客户的老系统、脏数据、内网数据库、SAP / Oracle / 自研系统 | 最花时间的一步，客户的真实数据和系统几乎从不和当初约定的一样 |
| ④ AI 工程调优 | Prompt 设计、Function Calling / Tool Use、RAG 检索链路、Agent 编排、上下文管理 | 和 § 2.2 大模型应用工程师的技术栈完全重合 |
| ⑤ 建评估集 | 和客户业务专家一起做 Eval——定义”什么叫答对了” | 交付能不能验收的命门；OpenAI 的 FDE 团队把”建评估框架 + 加护栏”列为标准动作 |
| ⑥ 上线运维 | 部署、监控、处理线上翻车、培训客户员工用起来 | 上线不是终点，“用起来”才是——Morgan Stanley 部署 GPT-4 的案例以 98% 采用率作为成功指标 |
| ⑦ 反哺产品 | 把多个客户现场的共性需求抽象出来，推动总部做成平台能力 | 见 § 1.6 |
按公开报道的经验，一个 FDE 的时间大致一半写代码（集成、数据转换、上线应用），一半面对客户（需求会、现场演示、和客户团队结对编程），前沿实验室的 FDE 岗位普遍写明最多 50% 出差。
1.3 和相近岗位的区别
| 对比对象 | 区别 |
|---|---|
| vs 解决方案架构师（SA） | SA 画架构、讲方案；FDE 亲手写生产代码 |
| vs 售前工程师 | 售前负责签单；FDE 负责签单后真的跑起来 |
| vs 普通后端 / 算法 | 普通研发面对 PR 和需求文档；FDE 直面客户脸色，业务优先，容忍”不够优雅但能解决问题”的方案 |
| vs 咨询顾问 | 顾问交付报告和建议；FDE 交付能跑的系统，并且要留到它在生产环境跑稳 |
| vs 国内”实施 / 交付工程师” | 实施是按手册装系统；FDE 定位更高——有权改架构、写新模块、甚至否掉原方案 |
| vs 总部核心研发 | Palantir 的原话：“Dev 是一种能力服务很多客户，Delta 是很多能力服务一个客户” |
1.4 能力画像
- 全栈够用：Python / TypeScript、API、SQL、Docker、云，前端能糊出界面
- LLM 应用工程：Prompt、RAG、Agent、Eval、成本与延迟优化
- 沟通与业务理解：经常占掉 40%~50% 的精力，听不懂客户业务就做不对东西；OpenAI 的 FDE 面试把沟通能力和客户同理心放在与编码同等的权重
- “快糙猛”与”工程洁癖”的平衡感：知道什么时候该硬编码、什么时候必须抽象
- 抗压 + 能出差 / 驻场
⚠️ 诚实的另一面（来自从业者的匿名吐槽）：这份工作有时像**“专业救火队”**——很多工作是被动响应的，你在让一个不是你造的产品、为一群不是你选的客户跑起来，客户那边一出事就得放下手头一切去救。
1.5 为什么 AI 公司特别需要这个角色
四个原因，前三个是技术性的，第四个是商业性的：
| 原因 | 展开 |
|---|---|
| 模型能力是通用的，落地极度场景化 | ”最后一公里”比想象中长十倍——同一个模型，接进银行风控和接进车间排产是两个完全不同的工程 |
| 客户根本不知道大模型能干什么 | 需要有人现场演示才能激发需求；先有 demo 才有需求，而不是先有需求再做 demo |
| 真实数据和评估标准只存在于客户现场 | 拿不到客户的脏数据就调不准，问不到业务专家就不知道”什么叫答对” |
| 大单成败取决于交付确定性，不是 benchmark 分数 | 企业买的是”这套东西能在我这儿跑起来”，不是排行榜第几名 |
一个数据把这四条串起来：MIT NANDA 项目 2025 年 8 月发布的报告《The GenAI Divide: State of AI in Business 2025》称，企业投入 300~400 亿美元做生成式 AI，95% 的试点没有产生可衡量的回报；报告把根因归为工具与组织的”学习鸿沟”和糟糕的企业集成，而不是模型质量。OpenAI FDE 团队负责人 Colin Jarvis 的说法与之呼应：ChatGPT 出来后客户很兴奋，但”从模型里拿到价值其实挺难”，唯一稳定有效的办法就是把工程师直接嵌进客户里，学他们的工作流、和他们的员工并肩干。
FDE 模式的扩散时间线（从 Palantir 特色到前沿实验室标配）：
| 时间 | 事件 | 意味着什么 |
|---|---|---|
| 2010 年代初 | Palantir 发明 FDE（内部称 Delta / Echo） | 起源于情报国防客户”需求不能公开、数据拿不出来”的约束 |
| 2025-01 | Colin Jarvis 宣布牵头组建 OpenAI 的 FDE 职能；到 2025-11 已 39 人、计划年底 52 人，在旧金山、纽约、都柏林、伦敦、巴黎、慕尼黑、新加坡招人 | 模型厂商亲自下场做落地；代表项目：Morgan Stanley 部署 GPT-4、John Deere（在爱荷华州农场现场） |
| 2025-06 | a16z 发文《Trading Margin for Moat》，称 FDE 是”创业公司最热的岗位”；当时 OpenAI 311 个在招岗位里 22 个是 FDE / 解决方案工程师 | 风投开始为”服务型增长”背书（争议见 § 1.7） |
| 2025-09 | YC 的 Lightcone 节目里提到 YC 招聘板上有 100+ 家创业公司在招 FDE，三年前几乎没有；有报道称 2025 年 1~9 月 Indeed 上 FDE 岗位增长 800% 以上（二手转引，量级参考） | 从大厂扩散到应用层创业公司 |
| 2025~2026 | Anthropic 挂出 “Forward Deployed Engineer, Applied AI”（最多 50% 出差）；Salesforce 宣布 FDE 团队要扩到 1000 人（围绕 Agentforce） | 岗位名开始标准化 |
| 2026-05-04 | Anthropic 与 Blackstone、Hellman & Friedman、Goldman Sachs 成立 15 亿美元合资公司（后命名 Ode with Anthropic），把工程师嵌进中型企业重构工作流 | 模型厂商把 FDE 从”内部团队”升级为”独立公司” |
| 2026-05-11 | OpenAI 成立 OpenAI Deployment Company，从 TPG 领投的 19 家机构募资 40 亿美元，并收购应用 AI 咨询公司 Tomoro，第一天就带来约 150 名 FDE 与部署专家 | 同上；Reuters 报道两家合资公司都在洽购 AI 服务公司，大部分资金将用于收购工程服务与咨询公司 |
💡 怎么读这条时间线：2026 年 5 月那两周是分水岭——两家最强的模型公司同时承认”只有模型改变不了客户的工作流”（Goldman 高管原话），并且愿意为”人+服务”这件事各掏几亿美元成立公司。对个人来说，这意味着 FDE 不再是 Palantir 的小众岗位，而是一条被资本和模型厂商共同押注的职业赛道；同时也意味着竞争者会从”创业公司的几个人”变成”被收购进来的成建制咨询团队”。
1.6 碎石路到高速公路：FDE 反哺产品的回路
FDE 模式最重要的设计不是”派人驻场”，而是现场经验流回产品的那条回路。Palantir 把它叫 “gravel road to paved highway”（碎石路到高速公路）：
客户 A 现场 客户 B 现场 客户 C 现场
┌──────────┐ ┌──────────┐ ┌──────────┐
│ FDE 用最快 │ │ FDE 用最快 │ │ FDE 用最快 │
│ 方式铺一条 │ │ 方式铺一条 │ │ 方式铺一条 │
│ "碎石路" │ │ "碎石路" │ │ "碎石路" │
└─────┬────┘ └─────┬────┘ └─────┬────┘
│ 三家都要"把 PDF 合同抽成结构化字段 + 人工复核" │
└──────────────────────────┬──────────────────────────┘
▼
┌──────────────────────────────┐
│ 总部把共性抽象成平台能力： │
│ "高速公路"（产品功能 / SDK / 模板）│
└──────────────┬───────────────┘
▼
下一家客户直接上高速，FDE 只需修最后一段碎石路
- 碎石路：为一个客户快速铺的、粗糙但能走的定制方案——快、务实、只解决眼前问题
- 高速公路：多个客户都需要的模式被产品化成标准功能，以后谁都能直接用
- 回路健康的标志：Colin Jarvis 说 OpenAI 的 FDE 团队刻意回避”服务收入”，专注于产出产品 playbook——也就是说，衡量 FDE 团队的不是”卖了多少人天”，而是”多少现场经验变成了产品”
💡 对个人的意义：这条回路也是 FDE 对抗”代码复用度低”的解药——你在客户 A 写的东西也许 B 用不上，但你从 A、B、C 三家提炼出的模式会变成公司的产品，和你自己的判断力。
1.7 争议：用毛利换护城河，还是不可规模化的外包？
FDE 模式不是没有反对声音。把两边的论点都摆出来：
| 立场 | 论点 |
|---|---|
| 反方（传统 SaaS 视角） | 靠专业服务推进的生意规模化受限（一个人只能驻一家）；毛利低说明产品本身是大路货；服务应该交给合作伙伴（系统集成商）做，而不是自己养人 |
| 正方（a16z，2025-06《Trading Margin for Moat》） | 接受早期薄毛利，换来掌控客户的核心工作流，最终成为客户的”记录系统”；举例 ServiceNow 上市时毛利 63.2%、Workday 54.1%，到 2024 年分别升到 79% 和 75%——先当”服务公司”，后来都成了高毛利软件公司 |
| 正方补充（a16z，2025-08《Questioning Margins is a Boring Cliché》） | 质疑 AI 应用毛利低是老生常谈，但作者也承认”低毛利有时会是致命的” |
| 对正方的质疑 | 例子只挑了赢家（当年养驻场团队但死掉的公司不会出现在文章里）；这些都是投资人观点，不是被证明的规律 |
对个人的实际含义——面试 FDE 岗时多问三句：
- 这个团队的考核是产品化比例还是可计费人天？（前者是 OpenAI 式的 FDE，后者其实是咨询公司）
- 你们 FDE 做出来的东西，有没有回流到产品的机制和例子？
- 出差比例、驻场时长、一个人同时背几家客户？
⚠️ 如果一家公司的 FDE 纯粹是服务收入中心，那么你的个人成长曲线更接近咨询顾问，而不是工程师——这没有对错，但你要知道自己签的是什么。
1.8 职业取舍
好处
- 薪资通常高于同级普通研发（补偿出差和压力；量级见下表）
- 行业知识积累快，一年能看清”AI 到底在哪儿真赚钱”
- 转产品负责人 / solutions lead / 创业都顺——Ode with Anthropic 的团队据报道一半以上是前创始人，反过来说明这个岗位和创业者画像高度重合
薪资量级参考（美国公开数据，2025-11 ~ 2026-05，仅供量级判断）：
| 来源 | 数字 | 口径 |
|---|---|---|
| OpenAI 招聘页（Business Insider 2025-11 转述） | 美国岗位基本工资最高约 34.5 万美元 + 股权 | 官方 JD |
| OpenAI 医疗方向 FDE 招聘页（2026） | 基本工资 19.8 万 ~ 28 万美元 | 官方 JD |
| Palantir FDSE（Levels.fyi） | 总包中位数约 21.5 万美元 | 第三方汇总 |
| 前沿实验室中高级 FDE（多家薪酬报告） | 总包 35 万 ~ 55 万美元 | 第三方汇总，口径不一，只看量级 |
⚠️ 国内 FDE / 大模型应用工程师没有可靠的公开薪资数据，招聘网站的统计样本极小，本文不引用。
代价
- 代码复用度低（这家写的东西下家可能用不上，解药见 § 1.6）
- 常年在别人办公室，前沿实验室岗位普遍要求 25%~50% 出差
- 技术深度容易被业务琐事稀释，需要主动经营自己的技术沉淀
- “专业救火队”体验：被动响应多，客户一出事就得放下一切
适合谁 / 不适合谁
| 适合 | 不适合 |
|---|---|
| 沟通强、抗压、喜欢看到自己的东西被真实业务用起来 | 只想安静写代码、讨厌开会和出差 |
| 想快速积累行业知识、以后转产品或创业 | 想在某个技术方向钻得很深 |
| 能忍受”不够优雅但能解决问题” | 有工程洁癖、见不得硬编码 |
2. 大模型应用工程师：把发动机装进车里的人
2.1 结论先行
- 值得去：这是普通研发进入 AI 行业性价比最高的入口，比转算法 / 预训练现实得多
- 但要挑岗：同一个岗位名下，好岗和坑岗的差距可以有 3 倍（经验判断，无统计数据）——分辨方法见 § 2.6
生活类比：算法工程师是造发动机的人；大模型应用工程师是把发动机装进车里、让车能上路、还得省油不抛锚的人。前者少而贵，后者多而刚需——但”装发动机”这门手艺，一半会随着发动机越来越智能而被吃掉（见 § 2.4 第 1 坑）。
title 说明：国内叫法有大模型应用工程师 / 大模型应用开发工程师 / AI 应用工程师 / LLM 应用工程师；海外对应 AI Engineer（这个叫法 2023 年由 swyx 的文章《The Rise of the AI Engineer》带火）、Applied AI Engineer、LLM Engineer。都是一回事。
2.2 这个岗位干什么
核心是把模型能力变成可靠产品。典型工作栈：
| 工作块 | 内容 | 本知识库对应笔记 |
|---|---|---|
| Prompt 与上下文工程 | system prompt、few-shot、上下文压缩与裁剪 | 02_提示词工程、上下文窗口与 Token 计费 |
| Function Calling / Tool Use / MCP 接入 | 让模型能调工具、接外部系统 | Function Calling 与 MCP 工程指南 |
| RAG | 切分、embedding、向量库、混合检索、重排 | RAG 学习笔记、 向量数据库 |
| Agent 编排 | 多步任务、状态机、失败重试、人工兜底（HITL） | 什么是 Agent、Harness 工程与 Agent 解剖 |
| Eval 体系 | 离线测试集、自动打分、回归测试、A/B | Eval 测评体系 |
| 生产化 | 成本控制、延迟优化、限流、缓存、降级、可观测性、幻觉兜底 | Agent 可观测性与成本工程 |
| 业务系统集成 | 后端 API、数据库、消息队列、权限 | 软件工程产品研发 SOP |
📌 注意：不训模型、不写 CUDA、不推公式。这是它门槛低于算法岗的根本原因，也是它容易被外行低估的根本原因。
2.3 优势面
| 维度 | 情况 |
|---|---|
| 需求量 | 几乎所有行业都在做 AI 应用，岗位数远多于算法岗 |
| 入行门槛 | 后端 / 全栈背景 3~6 个月可转（经验估计），不要求论文和数学功底 |
| 薪资 | 普遍高于同级普通后端（原讨论估计上浮 20%~50%，未经数据验证，一线大厂 / 明星创业公司更高） |
| 成长速度 | 直接接触业务与用户，一年能看清”AI 在哪儿真赚钱” |
| 可迁移性 | 工程 + 业务 + AI 三合一，转产品、转 FDE、创业都通 |
2.4 五个真实的坑
① 技术护城河会被模型吃掉
两年前的手艺现在有一半失效了：复杂的 RAG 拼装被长上下文和原生检索吃掉一部分，手写的 Agent 循环被官方 SDK 和 tool runner 吃掉一部分。只会”调用技巧”的人最容易被贬值。
类比：早年”会调汽化器”是修车师傅的核心手艺，电喷普及后这门手艺一夜归零——但”会诊断车为什么不走”的能力没有归零。
② Demo 十分钟，生产十个月
做个能演示的东西太简单，导致外行（包括你的老板）低估这个岗位的难度，容易变成”你这不就是调 API 吗”。要学会用数据证明工程价值：上线前后业务指标变化、幻觉率下降多少、单次成本压了多少。
③ 项目死亡率高
AI 项目上不了线是常态——效果不达标、成本算不过、合规卡住、业务方不用（MIT 那个 95% 的数字，见 § 1.5）。简历上可能出现一串”做过但没上线”。
④ 岗位名被滥用
有些”大模型应用工程师”实际是：包了 AI 皮的普通 CRUD、纯手工调 prompt 的标注工、或者给领导做 PPT demo 的。
⑤ 容易只做胶水，不做系统
长期接管道、拼 SDK，技术深度会被稀释。“能跑 ≠ 对”的坑在这里最多（详见 LLM 典型失败模式 和 Vibe Coding 与技术债治理）。
2.5 护城河怎么建：按保值程度排序
| 排序 | 能力 | 为什么保值 | 本知识库对应笔记 |
|---|---|---|---|
| 1. Eval 与数据闭环能力 | 会定义”什么叫答对了”、会搭自动评测、会用线上数据反哺迭代 | 模型再升级，这套方法论不过期，而且大部分人不会 | Eval 测评体系、数据飞轮 |
| 2. 生产化工程能力 | 成本 / 延迟 benchmark、并发安全、缓存策略、失败降级、可观测性 | 这是普通研发硬功底在 AI 场景的延伸，别丢 | Agent 可观测性与成本工程、上下文窗口与 Token 计费 |
| 3. 领域深度 | AI + 一个具体行业（法律、医疗、制造、金融风控…） | 行业知识比 prompt 技巧难被替代得多；这也是 FDE 最快积累的东西 | —— |
| 4. 系统设计能力 | 能设计一个多 Agent、多数据源、有权限和审计的完整系统，而不只是写好一个 prompt | 这就是从”应用工程师”到”Agent 架构师”的那一步 | Agent 架构师能力地图（8 大能力域）、Harness 工程与 Agent 解剖 |
💡 一句话记忆：模型会替你把”怎么调”越做越简单，但不会替你回答”做得对不对、值不值、在这个行业里该怎么做”。护城河全在后半句。
2.6 好岗还是坑岗：面试五问
面试时直接问这五个问题，答不上来的基本可以排除：
| # | 问题 | 好答案长什么样 | 坏答案长什么样 |
|---|---|---|---|
| 1 | 现在这套 AI 系统的线上真实调用量是多少？ | 有具体数字和增长曲线 | ”还在内测""正在推广” |
| 2 | 你们的 Eval 是怎么做的？有没有回归测试集？ | 有离线集、有自动打分、上线前必跑 | ”主要靠人看几个 case” |
| 3 | 这个功能上线后业务指标变化了多少？ | 说得出具体指标（转化率 / 处理时长 / 人力节省） | “领导挺满意的” |
| 4 | 团队里 AI 应用是独立方向，还是某个业务组的附属实验？ | 有独立的目标、预算和上线路线 | ”先做个 POC 看看” |
| 5 | 单次请求的成本和 P95 延迟是多少，谁在管这个数？ | 有人盯、有看板、有预算线 | 没人算过 |
问出「有量、有 Eval、有指标、有预算」的，是好岗；答「我们还在探索阶段 / 在做 POC」的，大概率是给你练手也可能给你陪葬。
💡 本文补一问（原讨论没有）：用户的使用数据有没有回流成评测样本或训练样本？ 这是判断团队有没有数据飞轮意识的最快办法——有飞轮的团队半年后会甩开没飞轮的团队。
3. 三种站位：应用工程师 / FDE / Agent 架构师
把本文两个岗位和本知识库已经讨论过的「Agent 架构师」放到一起看——同一套技术栈，三种站位，一条路径：
| 维度 | 大模型应用工程师 | FDE | ”Agent 架构师”级别 |
|---|---|---|---|
| 站在哪儿 | 总部 / 产品团队 | 客户现场 | 总部，但面向多客户 / 多业务线 |
| 对什么负责 | 一个产品功能能上线 | 一家客户的系统能跑起来并被用起来 | 一套可控、可观测、可恢复、可扩展的系统 |
| 技术栈 | Prompt / RAG / Tool Use / Agent / Eval / 生产化 | 同左 + 数据打通 + 现场演示 | 同左 + 架构分层 + 多 Agent 协同 + 安全治理 |
| 额外要求 | —— | 沟通与业务理解占 40%~50%、能出差、抗压 | 系统设计、成本账、失败模式预案 |
| 典型 title | AI Engineer / 大模型应用工程师 | Forward Deployed Engineer | LLM Systems Engineer / Staff AI Engineer（“Agent 架构师”是培训圈叫法） |
| 适合谁 | 后端 / 全栈想进 AI 的人 | 沟通强、抗压、能出差 | 做过 2~3 个上线系统、会算账、会救火的人 |
| 本知识库笔记 | 本文 § 2 | 本文 § 1 | Agent 架构师能力地图、Agent 发展轨迹四阶段 § 10 |
转岗路径图：
后端 / 全栈研发
│ 3~6 个月补 LLM 应用工程（Prompt / RAG / Tool Use / Eval）
▼
大模型应用工程师 ────── 沟通强、抗压、能出差 ──────▶ FDE
│ │
│ 做过 2~3 个上线系统 │ 多客户共性 → 抽象成平台
│ 会算成本账、会处理线上翻车 │（碎石路 → 高速公路）
▼ ▼
"Agent 架构师"级别（LLM Systems / Staff AI Engineer）◀────┘
│
├──▶ AI 产品负责人 / Solutions Lead
└──▶ 创业（FDE 出身尤其顺：见过真实付费场景）
💡 三个站位的护城河是同一套（§ 2.5：Eval 与数据闭环 > 生产化 > 领域深度 > 系统设计），只是权重不同：应用工程师先把前两层打牢，FDE 靠现场把第三层堆起来，架构师级别靠第四层拉开差距。
4. 常见误区
| 误区 | 为什么错 | 更好的理解 |
|---|---|---|
| ”FDE 就是实施 / 外包 / 驻场外派” | 实施按手册装系统；FDE 有权改架构、写新模块、否掉原方案，且要把现场经验回流产品 | 看团队考核的是产品化比例还是可计费人天（§ 1.7） |
| “大模型应用工程师不就是调 API” | Demo 十分钟、生产十个月——难的是 Eval、成本、降级、集成、合规 | 用上线前后的业务指标和成本数字证明价值（§ 2.4） |
| “会写 prompt 就够了” | prompt 技巧是最先被模型升级吃掉的一层 | 护城河在 Eval、生产化、领域、系统设计（§ 2.5） |
| “FDE 薪资高，所以一定是好岗” | 薪资补偿的是出差、压力和被动救火；纯服务收入中心的 FDE 成长曲线接近咨询顾问 | 面试多问产品化机制、出差比例、同时背几家客户（§ 1.7） |
| “Agent 架构师是一个可以投简历的岗位” | 招聘网站上几乎搜不到这个 title，它是一个级别 / 站位，不是一个岗位名 | 对应真实 title 见 § 0 与 Agent 发展轨迹四阶段 § 10.3 |
| ”JD 里写了 RAG / Agent / MCP 就是好岗” | JD 谁都会抄，关键看有没有量、Eval、指标、预算 | 面试五问（§ 2.6） |
| “AI 项目没上线是我能力不行” | 95% 的企业试点没有可衡量回报是行业常态，多数死于集成、合规、业务方不用 | 简历上把”没上线的原因和学到的东西”写清楚，比藏起来强 |
5. 与本知识库其他章节的关联
| 关联文档 | 关系 |
|---|---|
| Agent 架构师能力地图与学习路线 | 职业视角的姊妹篇：那篇讲”Agent 架构师该会什么、按什么顺序学”，本文讲”这些能力在招聘市场上对应哪些岗、站在哪儿、怎么挑岗”；本文 § 3 把它接成三种站位 |
| Agent 发展轨迹四阶段 § 10 | 那节批判”Agent 架构师”这个造词并列出真实 title，本文 § 0 把真实 title 逐一对应到岗位；§ 10.7.2 的数据飞轮是本文护城河第一层的理论基础 |
| Eval 测评体系 | FDE 日常第 ⑤ 步”和客户业务专家建评估集”是交付验收的命门；大模型应用工程师护城河排序里 Eval 排第一 |
| Agent 可观测性与成本工程 | 面试五问第 5 问（单次成本与 P95 延迟谁在管）的技术内容；护城河第二层”生产化工程能力”的展开 |
| LLM 典型失败模式 | ”能跑 ≠ 对”——只做胶水不做系统的坑，以及项目死亡率背后的失败模式 |
| Vibe Coding 与技术债治理 | 应用工程师”只拼 SDK 不理解系统”时技术债怎么堆起来 |
| Function Calling 与 MCP 工程指南 | 两个岗位共用技术栈里”工具调用”这一块 |
| RAG 学习笔记 | 共用技术栈里”检索”这一块；也是”被长上下文吃掉一部分”的那门手艺 |
| LLM-API 选型方法论 | 成本控制与模型分级的前置：先认识各家模型的能力 / 价格档位 |
| 上下文窗口与 Token 计费 | 成本工程的物理基础，也是”P95 延迟和单次成本”的计算起点 |
| 软件工程产品研发 SOP | FDE 七件事本质上是一套压缩到客户现场的产品研发 SOP（需求 → 原型 → 集成 → 验收 → 上线 → 反馈） |
| 程序员黑话速查 | CRUD、Indie Hacker、OPC 等本文顺带提到的行话 |
6. 来源与局限性
6.1 来源
- 原始材料：2026-09 与 AI 的两轮问答——“AI 的 FDE 工程师是干什么的""大模型应用工程师这个岗位如何”。本文 § 1.1~1.4、§ 1.8 的”好处 / 代价”、§ 2 全部主干、§ 0 的岗位对比均源于此，措辞有整理。
- 落盘时用公开报道核实并补充（按本知识库”先评分再吸收”规矩，补充部分已在正文标明日期与出处）：
- Business Insider（2025-11）：Colin Jarvis 在 Altimeter Capital 播客谈 OpenAI FDE 团队（39 人、计划 52 人、Morgan Stanley 案例、“避免服务收入、专注产品 playbook”、美国岗位薪资上限）
- OpenAI 官方公告（2026-05-11）《OpenAI launches the OpenAI Deployment Company》：19 家机构、TPG 领投、收购 Tomoro 带来约 150 名 FDE
- CNBC / TechCrunch（2026-05-04）、Axios（2026-05-05）、Reuters（2026-05-05）：Anthropic 与 Blackstone、Hellman & Friedman、Goldman Sachs 的 15 亿美元合资公司；两家合资公司洽购 AI 服务公司；TechCrunch（2026-07-15）：该合资公司命名 Ode with Anthropic，团队一半以上为前创始人
- a16z：Joe Schmidt《Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups》（2025-06-04）；Sarah Wang & Martin Casado《Questioning Margins is a Boring Cliché》（2025-08-21）
- Fortune（2025-08-18）转述 MIT NANDA《The GenAI Divide: State of AI in Business 2025》的 95% 数字
- The Pragmatic Engineer（2025-08）FDE 深度报道：Palantir “Delta”、2016 年前 FDE 多于传统工程师；fde.academy 关于 Echo / Delta 分工与”碎石路到高速公路”回路的整理
- Salesforce Ben（2026）：Salesforce FDE 团队目标 1000 人；Dexity《Forward Deployed Engineer — The Complete 2026 Guide》：Anthropic JD 的 50% 出差、从业者”专业救火队”吐槽
- swyx《The Rise of the AI Engineer》（2023）：AI Engineer 这个 title 的来源
6.2 对原讨论的评分（8 / 10）
| 维度 | 评价 |
|---|---|
| ✅ 说对了 | Palantir 起源、日常七件事、与 SA / 售前 / 咨询 / 实施的区分、“最后一公里”判断、护城河四层排序、面试五问——公开报道均能印证 |
| ⚠️ 漏了（本文已补） | 2026-05 两家模型厂商成立 FDE 型合资公司；a16z 关于毛利与护城河的争论；“碎石路到高速公路”这个回路的名字与机制；Palantir 的 Echo / Delta 分工；“专业救火队”的另一面 |
| ⚠️ 可商榷（本文已标注） | “薪资上浮 20% |
| 处理方式 | 完整吸收 + 补充：保留原讨论的框架与判断，补事实、补争议、补与本知识库的连接 |
6.3 局限性
| 维度 | 局限 |
|---|---|
| 时效性 | 薪资数字与招聘规模是 2025-11 ~ 2026-05 的快照；两家合资公司 2026-05 才成立，成败未知；FDE 岗位定义仍在快速演化 |
| 覆盖范围 | 以美国前沿实验室与创业公司为主；国内 FDE 岗位形态与薪资几乎没有可靠公开数据，本文关于国内的判断均为经验推断 |
| 实战验证 | 整理者未亲身做过 FDE 或大模型应用工程师，全部为二手信息与 AI 问答整理；面试五问等方法未经真实面试验证 |
| 立场 | 引用的 a16z、OpenAI、Anthropic 材料都有自身利益（推广 FDE 模式），§ 1.7 已列出反方观点，但反方材料的数量少于正方 |
最后更新：2026-09-21（术语表补 SAP / Oracle / 自研系统 / ERP / few-shot / Eval 五分支 / benchmark 展开）