1. FDE 到底在解决什么问题：从一个真实交付现场说起
第一次听到 FDE 这个词，是在一个做企业智能体落地的项目群里。当时客户提了一个需求：把内部几十份产品手册、售后工单和培训材料，变成一个能回答一线销售问题的助手。团队里有人提议直接买个通用大模型接口套个壳，有人坚持要自研一套 RAG 流程。争论了两周，Demo 做出来了，但一上线就翻车——销售问"这个型号在潮湿环境下保修多久"，助手答的是另一款产品的条款。
问题不在于模型不够强，而在于没有人真正把"业务现场"和"技术实现"这两端接起来。后来项目组调整了分工，专门安排了一个角色：他既懂客户的业务流程，又能写提示词、调工具链、拆解 Agent 的执行步骤，还能把一线反馈快速转成可迭代的 Skill 配置。这个角色，就是现在被反复讨论的FDE（Forward Deployed Engineer，前线部署工程师）。
FDE 模式的核心，不是发明一个新技术，而是重新定义"谁来做交付"。传统做法是产品团队在后方做通用能力，实施团队到现场做配置，遇到定制需求再回传研发排期。这个链路长、损耗大，客户等不起，研发也被碎片化需求拖垮。FDE 的思路是把工程能力直接前置到业务现场，让懂技术的人贴着业务跑，边观察、边定义、边实现、边验证。
这篇内容适合三类人看：一是正在做 AI Agent 落地、被"最后一公里"折磨的工程师；二是想了解 FDE 岗位到底做什么、值不值得转型的从业者；三是团队管理者，想搞清楚这种模式怎么搭、怎么考核、怎么避免变成"高级外包"。我会结合行业里常见的实践，把 FDE 的工作边界、核心技能、协作机制和踩坑经验拆开讲，尽量说人话，也给可直接抄的清单。
提示：FDE 不是一个头衔，而是一种工作方式。把它理解成"会写代码的业务分析师"或者"懂业务的解决方案工程师"，都比理解成"驻场开发"更接近本质。
2. FDE 与传统交付角色的本质差异
2.1 从"需求传递"到"需求共创"
传统交付里，需求是"传"出来的。客户说一句，售前记一句，产品经理解释一句，研发实现一句，测试验证一句。每传一次，信息就衰减一次。我见过最夸张的案例，客户原话是"希望报表能按区域看"，传到研发手里变成了"增加一个 group by 字段"，结果做出来发现客户要的是按大区经理的管辖范围动态聚合，根本不是简单的分组。
FDE 模式把这条链砍短了。FDE 直接坐在客户旁边，看他们怎么用、听他们怎么骂、问他们为什么这么操作。需求不是"收集"来的，是"共创"出来的。客户说"这里不好用"，FDE 会追问：你刚才想完成什么任务？卡在哪一步？如果这一步能自动完成，你下一步会做什么？这种追问方式，能把模糊的抱怨转成可执行的功能点。
这里有个关键区别：传统角色关注"客户要什么"，FDE 关注"客户想达成什么"。前者容易被表面需求带偏，后者才能挖到真实痛点。比如客户说"我要一个导出 Excel 的按钮"，真实需求可能是"我要把数据发给财务对账"，那更好的方案也许是直接对接财务系统，而不是做个导出。
2.2 技术能力与业务语境的"双语"要求
FDE 最稀缺的能力，是能在技术语言和业务语言之间自由切换。跟客户聊的时候，不能说"我们用的是向量检索加 rerank"，要说"您问的问题，系统会先去资料库里找最相关的几段，再挑最准的答给您"。跟研发聊的时候，不能只说"客户觉得不准"，要说"召回率还行，但 top3 里混入了跨产品的条款，需要加一个产品维度的过滤"。
这种双语能力不是天生的，是靠大量现场对话练出来的。我的经验是，每次跟客户开完会，强迫自己用两句话总结：一句给客户听，确认理解无误；一句给研发听，明确要改什么。坚持三个月，切换速度会明显提升。
2.3 交付物从"文档"变成"可运行的 Skill"
传统交付的终点是一份验收报告和一堆配置文档。FDE 交付的终点，是一组能跑起来的Agent Skill——包括提示词模板、工具调用配置、知识库切片规则、异常处理逻辑。客户拿到手就能用，而不是拿到一本说明书再去自己搭。
这意味着 FDE 必须会写"可执行的交付物"。光会画流程图不够，得能把流程变成 Agent 能执行的步骤；光会写需求文档不够，得能把需求变成 Skill 的输入输出定义。这也是为什么热词里反复出现skill、agent skill、skill 脚本、skill 插件——Skill 正在成为 FDE 的核心交付单元。
| 对比维度 | 传统交付角色 | FDE |
|---|---|---|
| 需求来源 | 客户口头描述，层层传递 | 现场观察加追问，直接共创 |
| 核心产出 | 配置文档、验收报告 | 可运行的 Skill、Agent 流程 |
| 反馈周期 | 按迭代排期，周级或月级 | 现场验证，小时级或天级 |
| 能力要求 | 单一领域深度 | 技术加业务双语，广度优先 |
| 成功标准 | 功能上线 | 业务指标改善 |
3. FDE 日常工作的四个核心动作
3.1 现场观察：先看再问，别急着给方案
很多技术出身的人做 FDE，最大的毛病是"手比脑子快"。客户刚说一句，脑子里已经开始设计架构了。这是大忌。FDE 的第一动作应该是观察：看客户怎么操作现有系统，看他们在哪一步停顿、皱眉、反复点击，看他们用什么土办法绕过系统限制。
我自己的习惯是，第一次去现场不带电脑，只带本子。记录三类信息：高频操作路径、明显卡顿点、用户自创的替代方案。第三类最有价值，因为用户愿意自己造轮子，说明现有方案已经痛到无法忍受。比如有客户用 Excel 手动拼接两个系统的数据，那说明系统间的数据打通就是最高优先级的需求。
观察完之后再问，问的时候要具体。"您觉得哪里不好用"这种问题得不到有效答案。要问"您刚才点了三次返回，是在找什么"，或者"这个字段您填完之后一般发给谁"。具体的问题才能得到具体的信息。
3.2 快速原型：用最低成本验证最高风险假设
FDE 做原型，不是为了炫技，是为了验证假设。每个需求背后都有一个高风险假设，比如"用户愿意用自然语言提问""知识库的覆盖度足够回答 80% 的问题""Agent 的响应速度在可接受范围内"。原型的任务就是尽快把这些假设证伪或证实。
原型的成本要压到最低。能用提示词解决的，不写代码；能用现成工具搭的，不自己开发；能手工模拟的，不急着自动化。我见过 FDE 用一张纸画了个对话流程图，让客户扮演用户，自己扮演 Agent，走了一遍流程，十分钟就发现三个逻辑漏洞。这比写两天代码再演示高效得多。
注意：原型阶段最忌讳追求"完整"。一个只覆盖主流程、异常全抛出的原型，比一个覆盖 80% 场景但迟迟做不完的原型有价值得多。先跑通主干，再补枝叶。
3.3 反馈闭环：把现场吐槽转成迭代清单
FDE 的一个核心价值，是建立"现场到研发"的快速通道。但这个通道不能变成传声筒，要有过滤和转化。客户说"这个回答不准"，FDE 不能直接转给研发说"客户说不准"，而要拆解：是召回没找到正确文档，还是找到了但排序靠后，还是模型理解错了问题，还是答案生成时丢失了关键信息。
拆解完之后，按优先级排序。判断优先级的标准不是"客户喊得响"，而是"影响多少用户、影响多核心的流程、修复成本多高"。我常用的一个简单公式：优先级 = 影响面 × 严重度 ÷ 修复成本。影响面大、严重度高、修复成本低的，立刻做；影响面小、修复成本高的，先记录，攒够一批再统一处理。
3.4 能力沉淀：把一次性方案变成可复用 Skill
FDE 最容易被诟病的一点是"每个客户都做定制，做完就散"。避免这个问题的关键，是每次交付后强制做能力沉淀。具体做法是：把这次用到的提示词、工具链、异常处理逻辑，抽象成通用的 Skill 模板，标注适用场景和配置参数。
比如这次给客户 A 做了一个"合同条款问答"的 Skill，下次客户 B 也有类似需求，就不需要从零开始，只需要调整知识库来源和输出格式。沉淀做得好的团队，第二个客户的交付周期能比第一个缩短一半以上。这也是为什么热词里skill 编码、skill 脚本、skill 插件的讨论度这么高——大家都在找让 Skill 可复用的方法。
4. FDE 必须掌握的技术栈与能力地图
4.1 Agent 框架与编排：别被框架绑架
FDE 绕不开 Agent 框架。市面上常见的编排方式有两类：一类是代码优先的框架，用 Python 或 TypeScript 定义 Agent 的思考步骤和工具调用；另一类是可视化编排，拖拽节点连线。两种各有适用场景。
代码优先的框架灵活，适合逻辑复杂、需要精细控制的场景。可视化编排上手快，适合业务人员参与、流程相对固定的场景。我的建议是，FDE 至少要精通一种代码优先的框架，同时了解一种可视化工具。因为现场情况多变，有时候需要快速搭个可视化 Demo 给客户看，有时候需要写代码处理复杂分支。
选框架的时候，重点看三件事：工具调用的稳定性、上下文管理的灵活性、调试信息的可读性。前两个决定能不能做出来，第三个决定出问题能不能快速定位。我踩过的坑是选了一个调试信息极其简陋的框架，Agent 执行到一半报错，只给一句"execution terminated due to error"，排查了两天才发现是某个工具返回格式不对。
4.2 提示词工程：从"会写"到"会调"
提示词是 FDE 的基本功，但很多人停留在"会写"的层面，不会"会调"。会写是指能写出一个让模型完成任务的提示词；会调是指当效果不好时，知道改哪里、为什么改、改完预期是什么。
调提示词的核心是控制变量。一次只改一个地方，改完立刻测。我常用的调试顺序是：先看任务描述是否清晰，再看示例是否典型，再看输出格式是否明确，最后看有没有给模型足够的思考空间。很多"模型不行"的问题，其实是提示词里任务描述含糊，模型只能猜。
还有一个经验：提示词不是越长越好。我见过一个提示词写了三千字，把各种边界情况都列了一遍，结果模型反而抓不住重点。好的提示词是结构清晰、重点突出、示例精准。该说的说透，不该说的不啰嗦。
4.3 知识库与检索：RAG 不是万能药
做企业 Agent，知识库是绕不开的。但 RAG（检索增强生成）不是万能药，它解决的是"模型不知道企业私有信息"的问题，解决不了"信息本身矛盾""信息更新不及时""问题需要多步推理"这些问题。
FDE 要会判断：什么问题适合用 RAG，什么问题适合用工具调用，什么问题适合直接写死在提示词里。简单的事实查询，RAG 最合适；需要实时数据的，用工具调用；固定不变的规则，直接写提示词里最稳。我见过把所有东西都往知识库里塞的项目，结果检索出来的内容互相打架，模型无所适从。
知识库的切片策略也很关键。按固定长度切，简单但容易切断语义；按段落切，语义完整但长度不均；按标题层级切，结构清晰但依赖文档质量。我的经验是，先用固定长度加重叠做基线，再针对效果差的部分做人工调整。别一上来就追求完美切片，先跑起来再优化。
4.4 评测与可观测性：没有度量就没有改进
FDE 交付的 Agent，必须能度量效果。没有度量，客户说"感觉不准"你没法反驳，研发说"已经优化了"你没法验证。度量的核心是建立评测集：一批有标准答案的问题，覆盖主要场景和边界情况。
评测集不用一开始就很大，二三十条就能发现明显问题。关键是持续维护：每次发现新的 bad case，就加进评测集；每次优化完，就跑一遍看有没有回归。我习惯把评测集分成三档：核心场景必须全对，重要场景允许少量错误，边缘场景记录即可。
可观测性是指能追踪每次 Agent 执行的完整链路：用户问了什么、检索到了什么、模型怎么想的、调用了哪些工具、最终输出了什么。出问题时，能顺着链路定位到具体环节。这块很多团队前期不重视，等出了问题才发现两眼一抹黑，只能靠猜。
5. FDE 的协作机制：轮岗、晋升与社区分享
5.1 轮岗机制：让 FDE 不脱离一线也不困在一线
FDE 做久了容易陷入两难：一直待在一线，技术会落后；完全回后方，又失去现场敏感度。轮岗机制就是解决这个矛盾的。常见的做法是 FDE 在一线项目待 6 到 12 个月，然后回产品团队或研发团队待 3 到 6 个月，把现场经验转化成通用能力，再带着新的工具和方法回到一线。
轮岗的关键是"带着任务轮"。回后方不是休息，是要把一线发现的问题抽象成产品需求，把重复出现的方案沉淀成 Skill 模板。我见过做得好的团队，FDE 回后方期间必须产出至少一个可复用的组件或一套标准化的交付流程，否则轮岗不算完成。
5.2 晋升路径：技术深度与业务广度怎么平衡
FDE 的晋升不能照搬纯研发的职级体系，因为评价标准不一样。纯研发看代码质量、架构能力、技术影响力；FDE 要看交付效果、客户价值、能力沉淀。我了解到的实践中，比较合理的评价维度有三个：交付项目的业务指标改善、沉淀的 Skill 被复用次数、带教的新人成长速度。
这三个维度分别对应"能打仗""能沉淀""能传承"。只打仗不沉淀的，是高级外包；只沉淀不打仗的，容易脱离实际；能打仗能沉淀但不能带人的，适合做专家岗而非管理岗。FDE 的晋升通道应该允许专家路线和管理路线并行，不要逼着所有人都去带团队。
5.3 社区分享：让经验流动起来
FDE 最怕的是"各自踩坑，互不交流"。同一个坑，A 项目踩完 B 项目再踩，C 项目还踩，这是巨大的浪费。社区分享机制就是让经验流动起来。形式可以多样：每周一次的技术分享、内部 Wiki 的案例库、跨项目的复盘会。
分享的内容要有结构。我推荐一个模板：背景是什么、遇到什么问题、尝试了哪些方案、最终怎么解决的、如果重来会怎么做。最后一条最重要，因为它是真正的经验提炼，而不是流水账。很多分享只讲"我们做了什么"，不讲"我们本可以怎么做"，价值就少了一半。
提示：社区分享不要只分享成功案例。失败案例往往更有价值，因为成功可能靠运气，失败一定有原因。鼓励 FDE 分享踩坑经历，并且不追责，才能形成真正的学习文化。
6. 实操中容易踩的坑与应对策略
6.1 需求蔓延：从"再加一个功能"到项目失控
FDE 在现场，客户随时可能提新需求。"能不能再加个导出""能不能支持语音输入""能不能对接我们的 OA"。如果每个都接，项目范围会迅速失控，交付遥遥无期。
应对策略是建立"需求缓冲区"。所有新需求先记录，不立刻承诺，每周固定时间和客户一起评审优先级。评审时用业务价值说话：这个需求能解决什么问题、影响多少用户、如果不做会怎样。把"要不要做"变成"先做哪个"，客户更容易接受。
我自己的经验是，项目启动时就明确"本期不做什么"，写进会议纪要，双方确认。这比事后拒绝新需求容易得多，因为规则是提前定好的，不是针对某个人。
6.2 效果波动：为什么昨天好用今天不行
Agent 效果波动是 FDE 最头疼的问题之一。同样的提示词，昨天回答准确，今天就开始胡说。原因可能有很多：模型版本更新、知识库内容变化、用户提问方式改变、检索结果随机性。
排查波动，第一步是固定变量。用同一批评测问题跑一遍，看是普遍变差还是个别变差。普遍变差，查模型和知识库；个别变差，查具体 case 的检索和生成链路。第二步是建立基线，每次变更前记录当前效果，变更后对比。没有基线，就无法判断是"变差了"还是"一直就这样"。
还有一个容易被忽略的点：用户提问方式会随着使用深入而变化。刚开始用户问得简单，用久了会问得更复杂、更口语、更省略。FDE 要定期收集真实问题，更新评测集，否则评测集和实际使用会脱节。
6.3 客户预期管理：别把 Demo 效果当承诺
Demo 阶段效果往往很好，因为场景是精心挑选的，问题是提前准备的。客户看完 Demo，预期就被拉高了，认为上线后也能达到同样效果。结果真实使用中遇到各种边界情况，效果下降，客户觉得被忽悠了。
管理预期的关键是提前打预防针。Demo 演示时，主动说明"这个场景我们优化过，实际使用中可能会遇到 XX 情况，效果会有波动"。同时给出改进路径：上线后我们会持续收集问题，按优先级优化，预计多久能达到稳定状态。
我习惯在 Demo 后给客户一份"效果预期说明"，列出当前能稳定支持的场景、可能出错的场景、暂不支持的场景。白纸黑字写清楚，比口头说更有效。客户有了合理预期，后续优化时也更有耐心。
6.4 知识库质量：垃圾进垃圾出
知识库是 Agent 效果的天花板。文档质量差、内容过时、格式混乱，再好的模型也救不回来。FDE 经常遇到的情况是，客户给了一堆 PDF、Word、Excel，格式五花八门，内容新旧混杂。
处理知识库，第一步是清洗。去掉重复内容、过时内容、无关内容。第二步是结构化。把非结构化文档转成有明确标题层级的格式，方便切片和检索。第三步是标注。给每段内容打上来源、时间、适用范围等标签，检索时可以过滤。
这个过程很枯燥，但省不得。我见过团队跳过清洗直接入库，结果检索出来的内容自相矛盾，模型只能随机选一个，效果惨不忍睹。花在知识库上的时间，最终都会在效果上回报回来。
7. 从 FDE 视角看 AI Agent 落地的未来走向
7.1 Skill 标准化：交付物从"项目"变成"资产"
现在 FDE 交付的东西，很大程度上还是项目制的：这个客户做完了，下一个客户重新来。但随着 Skill 标准化程度提高，交付物会从"项目"变成"资产"。一个精心设计的 Skill，可以配置化地适配多个客户，交付成本大幅下降。
这个趋势已经在发生。热词里skill 编码、skill 脚本、skill 插件、book to skill的讨论，本质上都是在探索 Skill 的标准化和复用。未来 FDE 的核心竞争力，可能不是"能做一个 Skill"，而是"能设计一套可复用的 Skill 体系"。
7.2 人机协作深化：FDE 从"做"转向"教"
现在 FDE 大量时间花在亲手做配置、调提示词、搭流程上。随着工具链成熟，这些操作会越来越自动化，FDE 的时间会更多花在"教"上：教客户怎么用、教业务人员怎么维护、教内部团队怎么复用。
这意味着 FDE 的能力要求会变化。纯技术能力的重要性相对下降，业务理解、沟通表达、教学设计的重要性上升。能把自己的经验转化成别人能学会的方法，会成为 FDE 的核心价值。
7.3 组织形态演变：FDE 团队怎么搭
FDE 团队的组织形态，我观察到几种模式。一种是集中式，所有 FDE 在一个部门，按项目调配；一种是嵌入式，FDE 分散在各个业务线，汇报给业务负责人；还有一种是混合式，核心 FDE 集中管理，同时向业务线派驻。
集中式的好处是经验容易沉淀，坏处是离业务远；嵌入式的好处是响应快，坏处是容易各自为战；混合式试图兼顾，但对管理能力要求高。没有绝对最优，取决于团队规模和业务复杂度。小团队适合集中式，大团队适合混合式。
不管哪种模式，有一点是共通的：FDE 必须有直接接触客户的通道，不能变成"二传手"。一旦 FDE 开始只跟内部人开会、只看二手需求，这个角色就退化成普通的产品经理或实施顾问了，价值大打折扣。
8. 给想转型 FDE 的工程师的几条实在建议
如果你是从纯研发转 FDE，最大的挑战不是技术，是心态。研发习惯追求完美，FDE 要接受"先跑起来再优化"。研发习惯按计划推进，FDE 要适应现场变化。研发习惯跟代码打交道，FDE 要花大量时间跟人打交道。
我的建议是，先从"技术加业务"的混合角色做起，比如解决方案工程师、技术支持工程师，逐步增加跟客户直接接触的比例。同时刻意练习两件事：一是把技术问题翻译成业务语言，二是把业务问题翻译成技术方案。这两件事练熟了，转型就成功了一半。
如果你是从业务转 FDE，挑战在技术深度。不需要成为架构师，但要能看懂 Agent 的执行链路，能改提示词，能配置工具调用，能判断问题出在哪个环节。学习路径建议从提示词工程入手，再到 Agent 编排，最后到知识库和评测。每一步都要动手做，光看教程没用。
最后说一点：FDE 这个角色，短期内会很辛苦，因为要同时应付技术和业务两边的压力。但长期看，它培养的是"端到端解决问题"的能力，这种能力在任何组织里都稀缺。我个人的体会是，做过 FDE 的人，再回去做纯技术或纯业务，视角会完全不一样，能看到别人看不到的连接点。这大概就是这个角色最大的回报。
