1. FDE 模式到底在解决什么问题第一次听到 FDE 这个词是在一个做企业数字化交付的朋友群里。有人甩了张截图说“我们这边开始搞 FDE 了前端交付工程师直接驻场跟客户共创”。当时群里反应两极分化一拨人觉得这不就是高级外包换了个马甲另一拨人觉得这才是 AI 落地该有的样子。我自己前后参与过三个 FDE 性质的共创项目从最开始的手忙脚乱到后来慢慢摸出点门道这篇就把我踩过的坑、总结出来的流程、以及对这个模式的理解完整摊开讲一遍。FDE 全称是 Forward Deployed Engineer直译过来叫“前线部署工程师”或者“前沿交付工程师”。这个角色最早在数据平台类公司里比较常见核心逻辑是不把产品做完再卖给客户而是把工程师直接派到客户现场跟客户一起把方案磨出来。放到 AI Agent 这个语境下FDE 要做的事情就更具体了——帮客户把大模型能力、Agent 框架、Skill 插件这些东西真正落到他们的业务流里跑起来。为什么这个模式最近突然被频繁提起因为 AI 落地遇到了一个很尴尬的局面。大模型能力很强Agent 框架也越来越多但企业客户拿到这些东西之后往往卡在“最后一公里”业务场景太碎、数据太脏、流程太特殊标准产品根本覆盖不了。传统的做法是产品经理调研需求、研发排期开发、测试验收交付一轮下来三个月过去了客户业务可能都变了。FDE 模式就是把交付周期压缩到以周为单位工程师在现场直接改、直接调、直接跑客户看到效果再迭代。这个模式适合谁来参考如果你是做 AI 解决方案交付的工程师FDE 会是你未来几年绕不开的工作方式如果你是团队负责人正在头疼 AI 项目交付周期太长、客户满意度上不去FDE 的组织方式值得认真研究如果你是个体开发者想接一些 AI 落地的小项目FDE 的思路也能帮你用更少的沟通成本拿到更好的交付结果。2. FDE 模式的核心设计与选型逻辑2.1 为什么是“共创”而不是“交付”传统交付的逻辑是“我做好你验收”。FDE 的逻辑是“我们一起做边做边验收”。这个转变背后有三个现实原因。第一AI 能力的不确定性太高。你没法像卖一套 ERP 那样提前把所有功能点列清楚。Agent 在不同数据、不同提示词、不同工具组合下的表现差异巨大很多效果必须跑起来才知道。如果坚持先定义再开发大概率定义出来的东西跟实际能跑出来的东西对不上。第二客户自己也不知道要什么。我遇到过不止一个客户一开始说“我要一个智能客服”聊了两周才发现他们真正的问题是工单分类不准导致派单效率低。如果按智能客服去做做完了也解决不了核心痛点。FDE 驻场的好处就是能快速识别“客户说的需求”和“客户真正的需求”之间的差距。第三交付即培训。AI 系统跟传统软件不一样客户团队需要理解 Agent 的能力边界、Skill 的触发条件、提示词的调整方法。FDE 在现场把这些东西一点点教给客户团队交付完成的时候客户已经具备基本的自主运维能力了。这一点在热词里提到的“fde 的轮岗 晋升 社区分享机制”里也能看出来FDE 不只是技术角色还承担着知识转移的职能。2.2 FDE 与 ADP、Skill、Agent 的关系拆解这几个概念经常被混在一起说我按自己的理解理一下。Agent是执行主体你可以把它理解成一个能自主决策、调用工具、完成任务的数字员工。Skill是 Agent 的能力插件比如一个“查订单”的 Skill、一个“发邮件”的 Skill。ADP在不同语境下含义不同在 AI 交付场景里通常指 Agent Development Platform也就是用来编排 Agent、管理 Skill、监控执行过程的平台层。FDE则是把这些东西串起来、落到客户业务里的人。用一个类比Agent 是厨师Skill 是菜谱和厨具ADP 是厨房管理系统FDE 是那个带着厨师去客户家里、根据客户冰箱里的食材现场调整菜谱的人。客户要的不是一个标准化的厨师而是能用手头材料做出一顿合口味饭菜的人。2.3 方案选型的几个关键取舍在实际项目中FDE 面临的选型决策比想象中多。我列几个最常遇到的。自研 Agent 框架还是用开源框架如果客户业务场景比较标准用成熟的开源 Agent 框架能省很多时间。但如果涉及客户内部系统的深度集成、特殊的数据权限控制自研轻量级框架反而更可控。我的经验是先评估客户 IT 团队的维护能力如果客户团队连基本的 Python 环境都搞不定千万别选自研后期运维会变成你的噩梦。Skill 用现成的还是定制开发热词里提到的“skill 插件”“skill 编码 247”“codex skill”这些说明市面上已经有大量现成 Skill 可用。但现成 Skill 的问题是通用性强、针对性弱。我的做法是核心业务逻辑相关的 Skill 一定定制边缘辅助功能尽量用现成的。比如“发送通知”这种 Skill 直接用现成的“计算客户信用评分”这种必须定制。部署在客户内网还是云端这个决策往往不由 FDE 决定但 FDE 需要提前搞清楚。内网部署的坑在于环境隔离、依赖安装、模型调用链路都可能出问题。我一般会在项目启动前做一次完整的环境勘察把客户内网的 Python 版本、GPU 资源、网络策略全部摸清楚避免进场之后才发现跑不起来。3. FDE 实操流程与核心环节拆解3.1 进场前的准备工作FDE 项目最怕的就是“裸奔进场”。我现在的习惯是进场前必须完成三件事。第一业务场景摸底。跟客户业务负责人做一次深度访谈重点问三个问题你们现在最耗人力的环节是什么这个环节每天大概处理多少条数据如果这个环节效率提升 50%对业务意味着什么这三个问题能帮你快速判断哪些场景值得做、哪些场景做了也没人用。第二技术环境勘察。列一张环境清单让客户 IT 团队填包括服务器配置、操作系统版本、Python/Node 版本、数据库类型、内网访问策略、可用的模型 API 列表。这张清单越细越好我甚至会把“服务器有没有外网访问权限”这种问题单独列出来因为很多内网环境完全隔离模型调用需要走本地部署。第三成功标准对齐。跟客户明确“什么叫做成了”。是准确率达到某个阈值是处理时间缩短到某个范围还是业务人员愿意主动用我一般会建议客户把成功标准定得保守一点比如“先让业务团队愿意用起来”而不是一上来就定“准确率 95%”。AI 项目的第一目标是跑通闭环第二目标才是优化指标。3.2 共创工作坊的组织方式FDE 的核心动作是共创工作坊我一般按“两天一轮”的节奏来组织。第一天上午是场景拆解。把业务人员、IT 人员、FDE 拉到一起把目标场景的完整流程画出来。注意这里不是画理想流程而是画实际流程——包括那些“系统里查不到就微信问一下”的灰色环节。这些灰色环节往往是 AI 最能发挥作用的地方。第一天下午是快速原型。FDE 现场用 Agent 框架搭一个最小可跑通的版本哪怕只是把数据读进来、调一次模型、输出一个结果。这个原型不需要好看但必须能跑。我试过用两个小时搭一个“合同关键信息提取”的原型虽然准确率只有 60%但客户看到结果的那一刻讨论立刻从“能不能做”变成了“怎么做得更准”。第二天上午是反馈迭代。把原型给业务人员实际用收集反馈。这里有个技巧不要让业务人员提“你们应该加什么功能”而是让他们说“我刚才用的时候哪里卡住了”。前者会把你带偏后者才是真实痛点。第二天下午是方案确认。基于反馈调整方案明确下一轮的开发范围和验收标准。每一轮工作坊结束都要有一个可演示的版本和一份明确的待办清单。3.3 Agent 与 Skill 的落地配置具体到技术实现我以最常见的“文档处理 Agent”为例讲一下配置过程。首先是 Agent 的基础设定。你需要定义 Agent 的角色、可用工具、执行流程。以下是一个简化的配置示例agent_config { name: document_processor, role: 文档处理助手, model: gpt-4, tools: [read_file, extract_entities, write_result], max_iterations: 5, system_prompt: 你是一个文档处理助手负责从上传的文档中提取关键信息。 }然后是 Skill 的注册。每个 Skill 需要定义输入参数、输出格式、异常处理逻辑。比如“提取实体”这个 Skilldef extract_entities(text, entity_types): 从文本中提取指定类型的实体 entity_types: [人名, 公司名, 金额, 日期] prompt f从以下文本中提取{entity_types}以JSON格式返回\n{text} result call_llm(prompt) return parse_json(result)这里有个关键细节Skill 的异常处理一定要做。模型调用可能超时、返回格式可能不对、输入可能为空。我一般会在 Skill 里加三层保护输入校验、超时重试、降级返回。降级返回的意思是如果模型调用失败至少返回一个空结构而不是直接报错这样 Agent 还能继续往下走。3.4 交付后的持续运营FDE 项目交付不是终点而是起点。我一般会在交付后做三件事。第一留一份“运维手册”。不是那种官方文档而是手把手教客户团队怎么改提示词、怎么加新 Skill、怎么看日志排查问题。我甚至会录几个短视频把常见操作演示一遍。第二建一个反馈群。客户业务人员在使用过程中遇到问题直接在群里说。我一般会承诺 24 小时内响应但实际能做到 4 小时内响应的话客户满意度会高很多。第三定期回访。交付后第一个月每周回访一次第二个月每两周一次之后每月一次。回访的目的不是修 bug而是发现新的可优化点。很多客户用着用着就会提出新的需求这些需求就是你下一期项目的来源。4. 常见问题与排查技巧实录4.1 Agent 执行中断的排查思路热词里有个“agent execution terminated due to error”这是 FDE 最常遇到的问题。Agent 跑着跑着突然停了日志里就一行报错根本看不出哪里出了问题。我总结了一套排查流程。先看是不是模型调用超时。Agent 执行过程中如果某一步模型响应太慢超过了框架设定的超时时间整个执行链就会断掉。解决办法是给每个模型调用单独设超时并且加一次重试。再看是不是 Skill 返回格式不对。Agent 依赖 Skill 的返回结果做下一步决策如果 Skill 返回了非预期格式Agent 解析失败就会终止。我一般会在 Skill 里加一个格式校验不符合预期格式就返回标准错误结构。最后看是不是迭代次数超了。Agent 框架一般会设一个最大迭代次数防止无限循环。如果任务比较复杂Agent 可能需要更多轮才能完成。这时候要么调大迭代次数要么把任务拆成多个子任务。4.2 模型输出不稳定的应对方法同一个提示词今天跑出来是对的明天跑出来就偏了。这个问题在 FDE 项目里特别常见因为客户业务数据本身就在变化。我的应对方法是“三层稳定策略”。第一层是提示词稳定把提示词里的变量和固定部分严格分开固定部分不要轻易改。第二层是输出格式稳定强制模型按 JSON 格式返回并且在提示词里给出明确的格式示例。第三层是结果校验稳定对模型输出做规则校验不符合规则的直接重试或降级。还有一个技巧是“温度调低”。如果业务场景对准确性要求高把模型温度调到 0.1 甚至 0输出会稳定很多。代价是创造性会下降但对于文档处理、信息提取这类任务来说稳定性比创造性重要得多。4.3 客户团队不配合怎么办这个问题听起来不像技术问题但实际上是 FDE 项目失败的主要原因之一。客户业务团队觉得“又来个系统给我添麻烦”IT 团队觉得“你们搞的东西我维护不了”两边都不配合项目就卡住了。我的经验是找到那个“最痛的人”。每个业务团队里都有一个人他每天被重复劳动折磨得最厉害他最希望有个工具能帮他省事。找到这个人让他成为你的“内部支持者”。你帮他解决一个小问题他在团队里帮你说话比你自己说一百句都管用。另一个技巧是“先做减法再做加法”。不要一上来就让业务人员学新系统而是先看能不能把他们现有流程里的某个环节自动化掉。比如他们现在用 Excel 处理数据你先做一个自动填 Excel 的小工具让他们感受到“确实省事了”再慢慢引导他们用更完整的 Agent 方案。4.4 常见问题速查表问题现象可能原因排查动作解决方向Agent 执行中断模型超时、Skill 格式错误、迭代超限查看执行日志最后一步加超时重试、格式校验、调大迭代次数输出结果不稳定温度过高、提示词有歧义、输入数据变化对比多次执行的输入输出调低温度、固定提示词模板、加输入预处理Skill 调用失败参数缺失、权限不足、依赖未安装单独测试 Skill 函数补参数校验、检查权限配置、安装依赖客户不愿使用操作太复杂、看不到价值、习惯难改观察业务人员实际操作简化交互、先做单点自动化、找内部支持者交付后问题反复客户团队不会排查、文档不清晰回访时让客户演示操作补运维手册、录操作视频、建反馈群5. FDE 工程师的能力模型与成长路径5.1 技术能力什么必须会什么可以学FDE 工程师的技术栈跟纯研发不一样不需要在每个方向都深挖但需要“广而够用”。必须会的东西Python 基础能写脚本、能调 API、Agent 框架的基本使用LangChain、AutoGPT 这类至少熟悉一种、提示词工程知道怎么让模型稳定输出、基本的数据库操作能查数据、能写简单 SQL。可以边做边学的东西前端基础能改简单页面就行、Docker 基础能看懂 Dockerfile、能跑容器、模型微调知道概念即可实际项目中很少用到。我见过一些 FDE 新人花大量时间学模型原理、学深度学习结果到了客户现场发现最需要的是“怎么把 Excel 里的数据读出来”。所以我的建议是先保证能跑通一个完整的小项目再根据项目需要补技术短板。5.2 业务理解比技术更重要的能力FDE 跟纯研发最大的区别是你需要理解业务。不是理解业务的所有细节而是理解业务的“痛点结构”。我一般用“三个问题”来快速理解一个业务场景这个环节的输入是什么输出是什么中间经过了哪些人的手这三个问题能帮你画出业务流程图也能帮你找到 AI 可以介入的节点。还有一个能力是“翻译”。业务人员说的是“我想要一个智能助手”你需要翻译成“你需要一个能自动分类工单、提取关键信息、推送给对应处理人的 Agent”。这个翻译能力决定了你能不能做出客户真正需要的东西。5.3 沟通能力FDE 的隐形门槛FDE 每天要跟三种人打交道业务人员、IT 人员、自己的研发团队。跟业务人员要说人话跟 IT 人员要说技术方案跟研发团队要说清楚现场的真实需求。我踩过的一个坑是在客户现场答应了一个需求回来跟研发团队说“客户要这个”研发团队问“为什么要这个”我答不上来。后来我学乖了每次答应需求之前先问清楚“这个需求解决了什么问题”把问题带回来而不是把需求带回来。还有一个沟通技巧是“可视化”。能用图说清楚的不要用文字。我一般会用白板画流程图把 Agent 的输入、处理、输出画出来客户一看就明白。这比写十页需求文档都管用。6. 这个模式后续可以怎么扩展FDE 模式目前还在快速演化中。我观察到几个方向值得关注。一个是“FDE 社区化”。热词里提到的“fde 的轮岗 晋升 社区分享机制”说明已经有人在尝试把 FDE 的经验沉淀下来形成可复用的知识库。如果这个机制跑通了新人 FDE 的成长速度会快很多。另一个是“FDE 与 ADP 的深度结合”。现在很多 FDE 项目还是手工作坊式的每个项目都从头搭。如果 ADP 平台能提供更多开箱即用的能力FDE 就能把更多精力放在业务理解上而不是重复造轮子。还有一个是“FDE 的标准化交付包”。我最近在尝试把常见场景的 Agent 配置、Skill 组合、提示词模板打包成标准交付包新项目来了先看能不能复用不能复用再定制。这样能把交付周期从两周压缩到一周以内。最后分享一个我自己的小技巧每次 FDE 项目结束后花半天时间写一份“项目复盘”重点写三件事——哪些做对了、哪些做错了、下次怎么改。这份复盘不用给任何人看就是给自己积累经验。我写了十几份之后发现很多问题其实是重复出现的有了复盘记录第二次遇到就能快速定位。这个模式还在早期很多做法没有标准答案。我上面写的这些都是自己在实际项目中摸出来的不一定对但至少是真实跑过的。如果你也在做类似的事情欢迎交流踩过的坑越多路就越清晰。