1. FDE 到底在解决什么问题从一个被反复追问的现场说起第一次听到 FDE 这个词是在一个做企业智能体落地的项目群里。有人问我们买了平台、买了模型额度为什么业务部门还是用不起来群里沉默了几秒然后有人回了一句因为缺一个既懂业务现场、又能动手改代码的人。这句话基本就是 FDEForward Deployed Engineer前线部署工程师这个角色存在的全部理由。传统交付链条是这样的售前讲方案产品做功能研发写代码实施做配置最后交给客户。链条一长信息就衰减。业务现场那句我要的不是这个往往传到研发那里已经变成了客户希望优化交互体验需求被磨平了棱角交付出来的东西自然对不上。FDE 模式的核心动作是把一个工程能力过硬的人直接放到业务现场让他同时承担需求翻译、方案设计、原型开发、效果调优这几件事把反馈—修改的循环从几周压缩到几小时。这篇内容适合三类人看一是正在做 AI Agent、大模型应用落地的工程师想知道自己离 FDE 还差什么二是团队管理者在纠结要不要设这个岗、怎么设三是刚入行、看到FDE 工程师学习路线FDE 解决方案工程师这类词但搞不清它和普通开发、普通售前的区别的人。我会把 FDE 的能力结构、和 Agent/Skill 这些技术概念的关系、轮岗与晋升机制、以及实际落地中踩过的坑按我自己的理解完整拆一遍。需要先说明一点FDE 不是一个新发明的职位名称它更像是一种工作方式的命名。不同公司叫法不同有的叫解决方案工程师有的叫交付架构师有的干脆就叫驻场开发。名字不重要重要的是它背后那套前线共创、双向赋能的逻辑——前线拿到真实场景反哺产品产品能力增强又让前线交付更快。这个循环转起来才是 FDE 模式真正值钱的地方。2. FDE 的能力结构为什么它既不是纯开发也不是纯售前2.1 三种能力的交集而不是三种能力的叠加很多人对 FDE 的误解是要求太高了又要会写代码又要会沟通还要懂业务。这个理解方向就错了。FDE 不是把三个岗位的活全干一遍而是站在三者的交集上做事。我画不出图但可以这样描述纯研发关注这个功能怎么实现纯售前关注这个方案怎么讲清楚纯业务关注这个流程能不能跑通。FDE 关注的是这个场景里用现有技术能力最快能跑出什么可验证的结果。注意关键词是可验证和最快。这意味着 FDE 的编码能力不需要达到架构师级别但必须能独立写出可运行的原型沟通能力不需要达到金牌销售级别但必须能把业务语言翻译成技术约束业务理解不需要成为行业专家但必须能识别出哪些需求是真痛点、哪些是伪需求。能力维度纯研发纯售前FDE代码能力深追求工程质量浅或无中追求快速验证业务理解弱靠需求文档中靠话术强靠现场观察沟通方式技术语言商务语言翻译型语言交付节奏按排期按签单按现场反馈成功标准功能上线合同签订场景跑通这张表是我自己总结的不一定严谨但能说明问题。FDE 的成功标准是场景跑通不是功能上线也不是合同签订。这个标准决定了 FDE 的所有行为逻辑。2.2 为什么翻译能力是 FDE 最稀缺的技能我见过不少技术很强的人转 FDE 失败卡点几乎都在翻译能力上。业务方说这个报表能不能自动生成技术人第一反应是数据源在哪、字段怎么映射、用什么模板引擎。但 FDE 的第一反应应该是你现在这个报表是给谁看的多久看一次生成之后要做什么决策这两个反应的区别在于前者在解一个技术题后者在解一个业务题。技术题的答案往往有很多种业务题的答案往往只有一两种是真正有用的。FDE 的价值就在于他能判断出哪种技术方案对应的是真正有用的那个业务答案。举个具体的例子。某团队做合同审核 Agent业务方一开始提的需求是帮我把合同里的风险条款标出来。如果直接按这个需求做就是做一个条款识别加分类的模型。但 FDE 到现场看了一圈发现法务真正花时间的不是找风险条款而是找完之后要写一段解释说明给业务部门。所以真正该做的是识别风险条款 生成解释话术后者才是省时间的地方。这个判断不是靠技术能力做出来的是靠现场观察和追问做出来的。这就是为什么 FDE 必须在前线远程开会问不出这种细节。2.3 技术底子要扎实到什么程度虽然 FDE 不追求架构师级别的深度但技术底子必须扎实到能独立排错。我个人的判断标准是给你一个 Agent 框架你能在半天内跑通一个带工具调用的 demo给你一份 API 文档你能在一小时内写出可用的调用脚本给你一个报错日志你能定位到是模型输出格式问题还是工具参数问题。这个标准听起来不高但实际能达到的人不多。因为大部分工程师习惯了在成熟框架里做业务开发一旦要自己搭环境、自己调 prompt、自己处理模型输出的不确定性就会卡住。FDE 面对的技术栈通常包括这几块大模型调用层不只是调 API还要理解 temperature、top_p 这些参数对输出稳定性的影响知道什么时候该用结构化输出、什么时候该用自由文本。Agent 编排层理解 Agent 和 Skill 的区别后面会细讲知道什么场景该用单 Agent、什么场景该用多 Agent 协作。工具集成层能把业务系统封装成 Agent 可调用的工具处理好鉴权、限流、异常返回。效果评估层能设计一套简单的评估方法判断这次改动是变好了还是变差了。这四层里最容易被人忽略的是第四层。很多 FDE 做完改动之后凭感觉说好像好了一点但没有量化依据。时间一长改动越堆越多效果反而下降因为没人知道哪个改动是有效的。3. Agent、Skill、ADPFDE 必须理清的几个技术概念3.1 Agent 和 Skill 的区别以及为什么这个区分很重要热词里出现了agent skillskill和agent的区别skill插件skill脚本这些词说明很多人在这两个概念上犯迷糊。我用一个类比来解释。Agent 像一个员工Skill 像这个员工会的一项技能。一个员工可以会多项技能一项技能也可以被多个员工掌握。Agent 负责决定做什么Skill 负责具体怎么做。放到技术实现上Agent 通常包含一个决策循环——观察当前状态、选择下一步动作、执行动作、观察结果、继续循环。Skill 则是被 Agent 调用的一个具体能力单元比如查询订单状态生成摘要调用某个 API。为什么这个区分重要因为它决定了你的系统怎么扩展。如果你把每个业务动作都写成一个独立的 Agent系统会变得极其臃肿因为每个 Agent 都要维护自己的决策逻辑。正确的做法是把通用能力抽成 Skill让 Agent 去编排这些 Skill。我见过一个反例某团队做客服系统把查订单改地址退款分别做成了三个 Agent。结果用户说我要改地址顺便看下订单到哪了系统就懵了因为没有一个 Agent 能同时处理这两件事。后来改成一个客服 Agent 三个 Skill问题立刻解决。3.2 ADP 在 FDE 工作流里的位置ADP 这个词在不同语境下含义不同在 Agent 开发语境里我理解它指的是 Agent 的开发平台或编排协议层。不管具体指什么FDE 需要关心的是ADP 这类东西解决的是Agent 怎么被定义、被部署、被管理的问题。FDE 在前线做原型时往往不会一上来就用重型平台而是先用脚本把流程跑通。等场景验证有效了再考虑迁移到平台上做标准化。这个顺序不能反。我见过太多团队一上来就搭平台结果平台搭好了场景还没验证最后平台成了摆设。提示原型阶段用脚本验证阶段用框架规模化阶段用平台。跳过任何一步都会付出代价。3.3 从能跑到稳定跑之间隔着什么Agent 系统最容易被低估的难度是从 demo 到生产之间的那段路。demo 阶段你输入一句话Agent 返回一个结果看起来很美。生产阶段你要面对的是用户输入千奇百怪、工具调用偶尔超时、模型输出格式偶尔跑偏、并发上来之后响应变慢。FDE 在前线最常处理的不是能不能做而是为什么昨天能跑今天跑不了。这类问题的排查链路通常是先看模型输出是否格式异常——最常见的原因是 prompt 里某个约束被模型忽略了。再看工具调用是否失败——常见原因是鉴权过期或参数类型不匹配。再看上下文是否超长——长对话场景下历史消息把窗口撑爆了。最后看是否是并发问题——多个请求同时操作同一份状态。这个排查顺序是有讲究的从概率高的往概率低的排。我自己的经验是前两类问题占了八成以上。4. 前线共创怎么落地一个可复现的工作循环4.1 驻场第一周该做什么不该做什么很多 FDE 一到现场就开始写代码这是大忌。第一周的正确动作是观察和记录不是开发。我自己的做法是第一天跟着业务人员完整走一遍他们的工作流程不做任何打断只记录。第二天开始追问针对记录里出现的每一个手动操作复制粘贴来回切换系统的点问清楚为什么要这么做、多久做一次、做错了会怎样。第三天开始画流程图把观察到的流程和系统实际支持的流程做对比找出差距。第四天和业务方确认哪些差距是真正值得解决的。第五天再开始动手做第一个原型。这个节奏看起来慢但比上来就写代码快得多。因为上来就写大概率写的是你以为的需求不是真实的需求返工的时间远超观察的时间。4.2 原型该做到什么程度就可以拿出去原型的目的是验证方向不是交付产品。所以原型的标准是能让业务方用真实数据跑一遍并且给出对或不对的判断。具体来说原型需要满足三个条件一是能处理真实数据不能只用假数据演示二是能覆盖主流程不需要覆盖所有边界情况三是能在一分钟内跑完不能让业务方等太久。我见过有人把原型做得非常精致UI 漂亮、交互流畅但用的是假数据。业务方看完说挺好的然后就没有然后了。因为假数据跑出来的结果没有说服力业务方无法判断这个东西在真实场景下有没有用。反过来原型丑一点没关系只要真实数据跑出来的结果是对的业务方立刻就能给出有价值的反馈。4.3 双向赋能里的反向那一半双向赋能这个词大部分人只关注了赋能业务这一半忽略了赋能产品那一半。但后者才是 FDE 模式对公司的真正价值。FDE 在前线看到的场景是产品团队坐在办公室里想象不出来的。哪些功能被反复需要、哪些设计被反复吐槽、哪些边界情况反复出问题这些信息如果能系统性地回流到产品团队产品的迭代方向会精准得多。我见过做得好的团队FDE 每周会写一份前线观察不是写项目进度而是写这周我听到业务方抱怨了三次 XX 问题有三个不同客户都问到了 YY 功能。这种信息比任何用户调研都真实。反过来如果 FDE 只顾着在前线救火不往回传信息那这个模式就退化成了高级外包价值大打折扣。5. 轮岗、晋升与社区分享FDE 的成长路径怎么设计5.1 为什么 FDE 需要轮岗热词里出现了fde 的轮岗 晋升 社区分享机制说明这是很多人在关心的组织问题。轮岗对 FDE 来说不是福利是必需。原因很简单FDE 的核心能力是快速理解一个新场景而这个能力只有在不断接触新场景的过程中才能保持。如果一个人在一个行业待太久他会变成这个行业的专家但会失去跨场景迁移的能力。而 FDE 的价值恰恰在于迁移能力。轮岗的节奏我看到的比较合理的做法是一个 FDE 在一个行业深耕 6 到 12 个月把场景做透然后轮换到相邻行业。相邻很重要跨度太大前期学习成本太高跨度太小又起不到锻炼作用。5.2 晋升标准不该看交付数量如果用交付了多少个项目来考核 FDE会导向一个坏结果FDE 会倾向于做简单、快速能交付的项目避开那些难但价值高的场景。更合理的考核维度应该包括场景验证的成功率、原型到生产的转化率、回流到产品的有效需求数量、以及在前线沉淀下来的可复用 Skill 数量。最后一项特别重要。一个 FDE 如果每做一个项目都能沉淀出几个可复用的 Skill那他的价值是复利增长的。反过来如果每个项目都是从零开始那他的价值就是线性的。5.3 社区分享机制为什么不能省FDE 是分散在各个前线的如果不做社区分享每个人踩过的坑其他人还会再踩一遍。分享的形式可以很轻比如每周一次线上同步每个人讲一个这周遇到的最奇怪的问题和怎么解决的。不需要准备 PPT不需要正式汇报就是口头讲。这种轻量分享的频次比质量更重要因为频次高了信息流动才快。我自己的体会是FDE 之间最有价值的分享不是我做了什么而是我以为是这样结果发现是那样。前者是成果展示后者是认知修正后者对听的人帮助大得多。6. 实操中踩过的坑与排查链路6.1 需求翻译错误的典型表现最常见的坑是业务方说我要 AFDE 做出来 A业务方说这不是我要的。问题出在我要 A这句话本身是模糊的。我遇到过一个典型案例。业务方说我要一个能自动分类工单的系统。FDE 做出来一个基于文本分类的 Agent准确率 85%。业务方说不行。追问之后才发现业务方真正要的不是分类准确而是分类错误的时候能快速纠正。因为工单分类错误的代价很高分错了会导致处理延迟。所以正确的方案不是提高分类准确率而是做一个分类 人工快速纠正的流程。这个需求如果不在现场追问是问不出来的。排查这类问题的方法当业务方说不对的时候不要问哪里不对要问你原本打算拿这个结果做什么。后一个问题才能挖出真实需求。6.2 Agent 输出不稳定的排查顺序Agent 输出不稳定是 FDE 最常处理的技术问题。我的排查顺序是这样的排查步骤检查内容常见原因第一步prompt 约束是否明确约束太模糊模型自由发挥第二步输出格式是否强制没有用结构化输出模型格式漂移第三步上下文是否超长历史消息堆积关键信息被淹没第四步工具返回是否异常工具报错但被静默处理第五步模型参数是否合适temperature 过高导致随机性大这个顺序是从改动成本低到高排的。前两步通常改 prompt 就能解决成本最低。后两步可能要改代码成本高。所以先查前面。我自己的经验是把 temperature 调到 0 能解决相当一部分不稳定问题但会牺牲一些创造性。对于需要稳定输出的场景这是值得的。6.3 从原型到生产的环境差异原型跑在本地生产跑在服务器这中间的差异能坑死人。最常见的三个差异一是网络环境本地调 API 很快生产环境可能有延迟二是并发本地一个人用生产可能几十个人同时用三是数据量本地测试用几百条数据生产可能是几百万条。FDE 在原型阶段就要考虑这些差异至少要做一次模拟生产环境的测试。比如用并发脚本压一下用真实规模的数据跑一遍。这一步花的时间不多但能避免上线后才发现问题。7. 我对 FDE 模式的一点个人判断做了几个项目之后我越来越觉得 FDE 模式的核心不是人而是循环。一个 FDE 再强如果前线的信息不能回流到产品产品的能力不能反哺到前线那这个模式就是不可持续的。判断一个团队适不适合搞 FDE我会看三个信号一是产品团队愿不愿意听前线的坏消息二是 FDE 有没有时间做沉淀而不是被项目排期填满三是公司是否容忍原型阶段的不完美。这三个信号里任何一个缺失FDE 都会退化成普通交付。另外分享一个小技巧FDE 在前线做原型时尽量把每个 Skill 都写成独立可测试的单元。这样即使整个 Agent 流程还没跑通单个 Skill 也能拿给业务方看提前收集反馈。这个习惯能显著缩短反馈循环是我自己踩了不少坑之后才养成的。