1. FDE 模式到底在解决什么问题第一次听到 FDE 这个词是在一个做企业数字化交付的朋友群里。有人甩了张截图说“我们团队现在不叫实施顾问了改叫 FDE”底下立马有人接话“这不就是售前加售后合体吗”。当时我也没太当回事直到后来连续接触了几个 AI Agent 落地项目才发现 FDE 这个角色被反复提起背后其实藏着一套挺实在的交付逻辑。FDE全称 Forward Deployed Engineer直译过来就是“前线部署工程师”。这个叫法最早在数据智能和 AI 基础设施领域流行起来核心意思很直白工程师不坐在后方等需求而是直接扎到客户现场跟业务方一起把问题定义清楚再当场把方案搭出来。它跟传统实施工程师最大的区别在于传统实施是“产品已经定型你去装、去配、去培训”而 FDE 是“需求还没完全定型你带着工程能力去现场共创”。为什么这两年 FDE 突然被频繁讨论因为 AI Agent 这类东西的落地方式和传统软件完全不一样。传统软件卖的是功能清单客户知道自己要什么你按单交付就行。但 Agent 不一样客户往往只知道“我想让 AI 帮我处理这块业务”具体怎么拆任务、怎么设计工具调用、怎么控制幻觉、怎么跟现有系统对接这些在签合同的时候根本说不清楚。这时候如果还按老流程走——销售签单、产品经理写 PRD、研发排期、测试验收——等做出来黄花菜都凉了需求早变了。FDE 模式解决的就是这个“需求模糊期”的交付问题。它把工程能力前置到销售和方案阶段让懂技术的人直接跟客户业务方对话边聊边画原型边验证边调整。我见过一个比较极端的例子一个做供应链金融的团队FDE 在客户现场待了两周每天跟风控、运营、IT 三个部门的人泡在一起最后交付的 Agent 工作流跟最初销售承诺的完全不是一回事但客户满意度反而更高因为真正解决了他们“合同审核要来回切换五个系统”的痛点。这套模式适合谁来参考如果你在做 AI Agent 相关的项目交付不管是乙方实施团队还是甲方内部创新部门FDE 的思路都值得借鉴。哪怕你不叫这个 title把“工程能力前置、现场共创、快速验证”这三个原则用起来交付成功率会明显不一样。接下来我会从模式设计、核心能力、实操流程、常见坑几个角度把 FDE 这套东西拆开讲清楚。2. FDE 模式的核心设计与角色定位2.1 为什么传统交付流程在 Agent 项目上容易翻车传统软件交付的经典链路是销售签单 → 需求调研 → 方案设计 → 开发排期 → 测试验收 → 上线运维。这条链路在标准化产品上跑了很多年没什么大问题。但放到 AI Agent 项目上它有三个致命伤。第一个是需求传递失真。销售跟客户聊的时候客户说“我想要一个能自动处理客诉的 AI”销售理解成“做一个工单分类机器人”产品经理写成“基于 NLP 的工单意图识别模块”研发做出来一个分类准确率 92% 的模型。结果上线后客户说“我要的是它能直接回复客户不是只给我打个标签”。每一层传递都丢信息最后交付的东西跟客户脑子里的东西差了一大截。第二个是验证周期太长。Agent 的效果高度依赖具体业务数据和场景细节你不把真实数据跑一遍根本不知道行不行。但传统流程里研发在后方开发客户在现场等着中间隔了好几周甚至几个月。等第一版出来给客户看客户说“这个场景我们上个月已经改了”或者“这个数据格式跟我们实际的不一样”返工成本极高。第三个是责任边界模糊。Agent 项目里效果不好到底是模型问题、数据问题、流程设计问题还是客户使用方式问题传统交付模式下乙方说“我按需求文档做的”甲方说“这不是我要的效果”扯皮扯不清楚。FDE 模式通过现场共创把这些问题在过程中就暴露和解决掉而不是等到验收时才爆发。2.2 FDE 的角色定位不是售前也不是售后很多人第一次接触 FDE会把它理解成“售前工程师”或者“解决方案架构师”的变体。实际上 FDE 的定位更偏“带着工程能力的业务共创者”。我画个表对比一下几个容易混淆的角色。角色主要职责介入阶段核心能力交付物售前工程师讲方案、做 Demo、答标销售阶段表达、方案包装PPT、Demo解决方案架构师设计整体技术架构方案阶段架构设计、技术选型架构图、技术方案传统实施工程师部署、配置、培训交付阶段产品操作、环境搭建部署文档、培训材料FDE现场共创、快速验证、闭环交付售前到交付全程工程能力业务理解沟通可运行的 Agent 工作流FDE 最特殊的地方在于他既要能跟客户业务方聊明白“你们这个审批流程到底卡在哪”又要能当场打开编辑器写一段工具调用代码验证想法。这种“上下兼容”的能力组合在传统分工体系里是缺失的。售前不懂代码研发不懂业务中间就出现了一个真空地带FDE 就是来填这个真空的。2.3 双向赋能FDE 模式对甲乙双方的价值“双向赋能”这个词听起来有点虚但放到 FDE 场景里其实很具体。对客户方来说FDE 带来的最大价值是降低试错成本。Agent 项目最怕的是“做了半年发现方向错了”。FDE 在现场用真实数据快速搭原型一两周就能让客户看到“这个方向行不行”。行就继续深入不行就换方向试错成本从几个月压缩到几天。另外FDE 在共创过程中会把一些工程思维和方法论传递给客户的业务团队比如怎么定义任务边界、怎么设计人机协作流程这些知识会留在客户组织里。对交付方来说FDE 模式的价值是提高交付成功率和客户粘性。传统项目交付完客户觉得“也就那样”续约率低。FDE 在现场跟客户一起把问题解决掉客户会觉得“这帮人真懂我的业务”后续扩展新场景时第一个想到你。而且 FDE 在現場积累的业务理解会反哺到产品团队让产品迭代更有方向。我认识一个做 AI 客服 Agent 的团队他们的 FDE 在客户现场发现“客户最需要的不是自动回复而是自动生成回复建议给人工审核”这个洞察直接改变了产品路线图。3. FDE 核心能力拆解与实操要点3.1 业务翻译能力把模糊需求变成可执行任务FDE 第一项核心能力是“业务翻译”。客户说“我想让 AI 帮我处理合同”这句话信息量几乎为零。FDE 要做的是通过追问和观察把它拆成可执行的任务链。我通常会用一套“五问拆解法”触发条件是什么合同从哪里来邮件、系统推送还是人工上传输入是什么格式PDF、Word 还是扫描件有没有固定模板处理动作有哪些提取关键字段、比对条款、生成摘要还是直接审批输出给谁用结果给法务看、给业务看还是直接进系统异常怎么处理识别不了怎么办有歧义怎么办谁来兜底这五个问题问完一个模糊的“处理合同”就变成了“从邮箱监听新邮件 → 下载 PDF 附件 → 提取甲乙方、金额、付款条款 → 与标准模板比对差异 → 生成差异报告 → 推送给法务企业微信 → 法务确认后回写合同系统”这样一条清晰的任务链。注意FDE 在翻译需求时不要追求一次问全。客户往往说不清楚你需要先搭一个粗糙的原型给他看他看到具体的东西才能给出有效反馈。先做出来再问比一直问不做效率高得多。3.2 快速原型能力用 Agent 框架搭出可验证的 DemoFDE 的第二项能力是快速把想法变成可运行的原型。这里涉及 Agent 框架选型和 Skill 编排。目前主流的 Agent 开发框架有几种路线。一种是代码优先的比如用 Python 写 Agent 逻辑灵活但开发速度慢一种是配置优先的通过可视化编排工具拖拽节点上手快但复杂逻辑受限还有一种是混合模式核心逻辑用代码写外围用配置。FDE 在现场通常时间紧我建议优先选配置优先或混合模式先把流程跑通后面再优化。Skill 的设计是原型阶段的关键。一个 Skill 就是一个可复用的能力单元比如“提取 PDF 文本”“调用企业微信 API”“查询合同数据库”。FDE 在现场要快速判断哪些 Skill 可以直接用现成的哪些需要现场写。我的经验是通用能力用现成的业务特有逻辑现场写。比如文件解析、HTTP 请求这些通用 Skill 直接用但“根据公司合同模板比对差异”这种就要现场写一个。# 一个简单的 Skill 示例提取合同关键字段 # 实际项目中会根据具体业务调整 prompt 和校验逻辑 def extract_contract_fields(text): prompt 从以下合同文本中提取 - 甲方名称 - 乙方名称 - 合同金额 - 付款方式 - 签约日期 以 JSON 格式返回找不到的字段填 null。 result llm_call(prompt text) return validate_json(result)这个 Skill 看起来简单但现场写的时候有几个细节要注意。一是输出格式要严格约束不约束的话模型返回的 JSON 可能带 markdown 代码块标记后面解析会报错。二是要有校验和重试模型偶尔会漏字段或格式错误加一层校验和重试能显著提高稳定性。三是prompt 里要给出字段的边界定义比如“合同金额”是含税还是不含税不写清楚模型会猜。3.3 现场沟通能力跟业务方泡在一起的本事FDE 第三项能力是沟通但这个沟通跟销售式的沟通不一样。销售沟通是为了签单FDE 沟通是为了把业务逻辑挖干净。我自己的做法是“跟班观察 即时追问”。不要只坐在会议室里问要坐到业务人员旁边看他实际操作。他打开哪个系统、点哪个按钮、复制什么数据、粘贴到哪里这些动作里藏着大量他没说出来的信息。看到不懂的就当场问“这一步为什么要复制到 Excel 里”“这个字段你一般怎么判断”往往能挖出关键的业务规则。还有一个技巧是用他们的行话。每个行业都有自己的黑话比如金融行业说“头寸”“敞口”物流行业说“落货”“分拨”。FDE 如果能用客户的行话交流客户会觉得“你懂我”信任建立得快很多。我刚入行的时候不懂这个用技术术语跟业务方聊对方一脸茫然后来我强迫自己学他们的说法沟通效率翻倍。实操心得现场沟通时带一个笔记本把客户说的关键规则、例外情况、人名系统名都记下来。不要依赖记忆Agent 项目细节太多漏一个例外条件后面就可能出大问题。4. FDE 项目实操全流程拆解4.1 进场准备前三天要搞定的事FDE 进场不是到了就开始写代码前三天要做几件关键的事。第一天对齐目标和边界。跟客户的项目发起人聊清楚这次共创要解决的核心问题是什么成功标准是什么哪些不在范围内。这一步很重要不然后面容易范围蔓延。我见过一个项目本来只做合同审核结果客户业务方不断加需求最后变成了要做整个法务系统FDE 累死也做不完。第二天摸清数据和系统。要拿到真实的数据样本了解数据存在哪里、什么格式、质量如何。同时要搞清楚 Agent 需要对接哪些系统有没有 API权限怎么开。这一步经常卡住因为客户 IT 部门走流程慢所以要提前启动。第三天搭建开发环境和最小原型。把 Agent 框架跑起来用真实数据跑通一个最简单的流程。哪怕只是“读取文件 → 调用模型 → 输出结果”这样一条线先跑通再说。跑通之后拿给客户看客户马上就能给出反馈。时间关键任务产出物常见卡点第1天对齐目标、边界、成功标准项目范围说明客户内部意见不统一第2天数据摸底、系统对接调研数据样本、接口清单IT 部门排期慢第3天环境搭建、最小原型跑通可运行的 Demo环境依赖冲突4.2 共创迭代两周一个循环的节奏FDE 项目的核心节奏是“两周一个共创循环”。每个循环包含需求细化 → 原型开发 → 现场演示 → 反馈收集 → 调整优化。第一个循环通常最粗糙可能只覆盖主流程的 60%但一定要让客户看到东西。客户看到具体的东西之后反馈会非常具体比如“这个字段提取错了”“这个审批节点应该跳过”“这个提示语太生硬”。这些反馈比任何需求文档都有价值。第二个循环开始补异常处理和边界情况。Agent 项目最花时间的不是主流程而是各种异常。比如合同扫描件模糊怎么办、系统返回超时怎么办、模型输出格式不对怎么办。这些要在第二个循环里集中处理。第三个循环做集成和优化。把 Agent 跟客户的实际系统对接优化响应速度和准确率准备上线。注意每个循环结束都要有明确的“可演示成果”不要闷头开发两周然后说“还没做完”。FDE 的价值就在于持续可见的进展客户看到进展才会有信心继续投入。4.3 交付与交接让客户能自己跑起来FDE 项目最终要交付的不只是一个能跑的 Agent还包括客户团队能自己维护和扩展的能力。交付物通常包括Agent 工作流配置文件、Skill 代码库、部署文档、操作手册、常见问题排查指南。但光有文档不够FDE 要走之前要做几场培训让客户的 IT 人员和业务人员都能上手。我自己的做法是“影子运行”一周。FDE 还在现场但让客户团队自己操作FDE 在旁边看着有问题当场解决。这一周下来客户团队基本就能独立跑了。另外要留一个“扩展指南”告诉客户如果想加新场景应该改哪里、怎么测试、注意什么。这样客户后续自己就能迭代不用每次都找原厂。5. 常见问题与排查技巧实录5.1 Agent 执行报错怎么快速定位Agent 项目最常见的报错是“agent execution terminated due to error”这个报错信息极其模糊可能是模型调用失败、工具调用超时、输出格式解析错误、权限不足等任何原因。我的排查顺序是看日志Agent 框架一般会记录每一步的输入输出先看报错发生在哪一步。单独测 Skill把出错的 Skill 单独拿出来跑排除是 Skill 本身的问题还是编排的问题。检查输入很多时候是输入数据格式跟预期不符比如 PDF 解析出来是空字符串。检查权限调用外部 API 时 token 过期或权限不足也会报这个错。加超时和重试如果是偶发的超时加超时和重试机制通常能解决。报错现象可能原因排查方法解决方案execution terminated模型调用失败看模型 API 日志检查 key、配额、网络execution terminated工具调用超时单独测工具加超时、重试、降级execution terminated输出解析失败打印原始输出加格式约束、校验重试execution terminated权限不足检查 token 和权限重新授权或换凭证结果不稳定模型幻觉对比多次输出加约束、加校验、换模型5.2 客户说“效果不好”时怎么接客户说“效果不好”是最常见的反馈但这句话本身没有可操作性。FDE 要做的是把它拆成具体问题。我会问三个问题哪些 case 不好不好在哪里期望是什么让客户举出具体例子然后一起看这个例子的输入输出定位是哪个环节出了问题。是提取错了、判断错了还是格式不对定位到具体环节之后解决起来就快了。还有一种情况是客户期望本身不合理。比如客户期望 Agent 100% 准确这在当前技术条件下不现实。这时候 FDE 要管理期望说明“我们会做到 90% 以上剩下的 10% 需要人工兜底”并且设计好人机协作流程。把“AI 全自动”变成“AI 辅助人工”客户接受度会高很多。5.3 FDE 自己的避坑清单做了几个 FDE 项目之后我总结了几条自己的避坑经验不要承诺做不到的事现场气氛热烈的时候容易上头客户说什么都答应。但 Agent 的能力边界要心里有数做不到的当场说清楚比后面翻车好。不要跳过数据摸底我吃过亏进场第三天就开始写代码写到一半发现客户数据格式跟预想的完全不一样返工重来。数据摸底再花时间也值得。不要一个人扛FDE 在现场压力很大技术、沟通、项目管理都要管。背后要有一个支持团队遇到搞不定的技术问题能快速求助。不要忽略文档现场节奏快容易只顾着写代码不写文档。但 FDE 走了之后客户要维护文档不全后面全是坑。每天花半小时整理当天的工作后面省很多事。不要忘记轮岗和社区分享FDE 长期在外容易跟公司内部脱节。定期回公司做分享把现场经验沉淀成可复用的 Skill 和方案对自己和团队都有价值。6. FDE 工程师的成长路径与学习建议6.1 从哪个方向切入比较现实如果你现在做的是传统实施、售前或者开发想转 FDE我建议从自己最熟悉的领域切入。做金融实施的先做金融行业的 FDE做电商开发的先做电商 Agent 的 FDE。行业知识是 FDE 的核心壁垒不要轻易丢掉。技术方面需要补的主要是 Agent 框架的使用、Prompt 工程、基础的数据处理能力。不需要成为算法专家但要能理解模型的能力边界知道什么能做、什么做不了、大概怎么做。吴恩达的 Agent 教程、主流 Agent 框架的官方文档都是不错的起点。6.2 现场快速学习的技巧FDE 经常要面对自己不熟悉的行业快速学习能力很重要。我的方法是“三遍法”第一遍让客户讲一遍业务流程我只听不打断第二遍我复述一遍让客户纠正第三遍我画成流程图让客户确认。三遍下来基本就能把业务逻辑搞清楚。另外要善用 AI 辅助。遇到不懂的行业术语当场用 AI 查写 Skill 的时候让 AI 帮忙生成初版代码再改。FDE 的核心竞争力不是什么都懂而是快速搞懂并落地的能力。6.3 长期发展的几个方向FDE 做久了有几个发展方向。一是行业专家型 FDE深耕某个行业成为这个行业 Agent 落地的首选人选。二是平台型 FDE把现场经验沉淀成可复用的 Skill 库和方案模板提高整体交付效率。三是转产品或解决方案把一线洞察带回产品团队影响产品方向。不管走哪个方向FDE 阶段积累的“现场感”都是宝贵资产。知道客户真正需要什么、知道方案落地会卡在哪里这种判断力是坐在办公室里学不到的。我在实际项目里最大的体会是FDE 这个角色本质上是在填一个“技术与业务之间的翻译层”。AI Agent 的能力越来越强但客户不会因为技术强就买单他们买单是因为问题被解决了。FDE 就是那个把技术能力翻译成业务价值的人。这个角色累但成就感也强每次看到客户说“这个东西真省了我好多事”就觉得值了。
FDE模式解析：AI Agent落地交付与前线部署工程师实践
1. FDE 模式到底在解决什么问题第一次听到 FDE 这个词是在一个做企业数字化交付的朋友群里。有人甩了张截图说“我们团队现在不叫实施顾问了改叫 FDE”底下立马有人接话“这不就是售前加售后合体吗”。当时我也没太当回事直到后来连续接触了几个 AI Agent 落地项目才发现 FDE 这个角色被反复提起背后其实藏着一套挺实在的交付逻辑。FDE全称 Forward Deployed Engineer直译过来就是“前线部署工程师”。这个叫法最早在数据智能和 AI 基础设施领域流行起来核心意思很直白工程师不坐在后方等需求而是直接扎到客户现场跟业务方一起把问题定义清楚再当场把方案搭出来。它跟传统实施工程师最大的区别在于传统实施是“产品已经定型你去装、去配、去培训”而 FDE 是“需求还没完全定型你带着工程能力去现场共创”。为什么这两年 FDE 突然被频繁讨论因为 AI Agent 这类东西的落地方式和传统软件完全不一样。传统软件卖的是功能清单客户知道自己要什么你按单交付就行。但 Agent 不一样客户往往只知道“我想让 AI 帮我处理这块业务”具体怎么拆任务、怎么设计工具调用、怎么控制幻觉、怎么跟现有系统对接这些在签合同的时候根本说不清楚。这时候如果还按老流程走——销售签单、产品经理写 PRD、研发排期、测试验收——等做出来黄花菜都凉了需求早变了。FDE 模式解决的就是这个“需求模糊期”的交付问题。它把工程能力前置到销售和方案阶段让懂技术的人直接跟客户业务方对话边聊边画原型边验证边调整。我见过一个比较极端的例子一个做供应链金融的团队FDE 在客户现场待了两周每天跟风控、运营、IT 三个部门的人泡在一起最后交付的 Agent 工作流跟最初销售承诺的完全不是一回事但客户满意度反而更高因为真正解决了他们“合同审核要来回切换五个系统”的痛点。这套模式适合谁来参考如果你在做 AI Agent 相关的项目交付不管是乙方实施团队还是甲方内部创新部门FDE 的思路都值得借鉴。哪怕你不叫这个 title把“工程能力前置、现场共创、快速验证”这三个原则用起来交付成功率会明显不一样。接下来我会从模式设计、核心能力、实操流程、常见坑几个角度把 FDE 这套东西拆开讲清楚。2. FDE 模式的核心设计与角色定位2.1 为什么传统交付流程在 Agent 项目上容易翻车传统软件交付的经典链路是销售签单 → 需求调研 → 方案设计 → 开发排期 → 测试验收 → 上线运维。这条链路在标准化产品上跑了很多年没什么大问题。但放到 AI Agent 项目上它有三个致命伤。第一个是需求传递失真。销售跟客户聊的时候客户说“我想要一个能自动处理客诉的 AI”销售理解成“做一个工单分类机器人”产品经理写成“基于 NLP 的工单意图识别模块”研发做出来一个分类准确率 92% 的模型。结果上线后客户说“我要的是它能直接回复客户不是只给我打个标签”。每一层传递都丢信息最后交付的东西跟客户脑子里的东西差了一大截。第二个是验证周期太长。Agent 的效果高度依赖具体业务数据和场景细节你不把真实数据跑一遍根本不知道行不行。但传统流程里研发在后方开发客户在现场等着中间隔了好几周甚至几个月。等第一版出来给客户看客户说“这个场景我们上个月已经改了”或者“这个数据格式跟我们实际的不一样”返工成本极高。第三个是责任边界模糊。Agent 项目里效果不好到底是模型问题、数据问题、流程设计问题还是客户使用方式问题传统交付模式下乙方说“我按需求文档做的”甲方说“这不是我要的效果”扯皮扯不清楚。FDE 模式通过现场共创把这些问题在过程中就暴露和解决掉而不是等到验收时才爆发。2.2 FDE 的角色定位不是售前也不是售后很多人第一次接触 FDE会把它理解成“售前工程师”或者“解决方案架构师”的变体。实际上 FDE 的定位更偏“带着工程能力的业务共创者”。我画个表对比一下几个容易混淆的角色。角色主要职责介入阶段核心能力交付物售前工程师讲方案、做 Demo、答标销售阶段表达、方案包装PPT、Demo解决方案架构师设计整体技术架构方案阶段架构设计、技术选型架构图、技术方案传统实施工程师部署、配置、培训交付阶段产品操作、环境搭建部署文档、培训材料FDE现场共创、快速验证、闭环交付售前到交付全程工程能力业务理解沟通可运行的 Agent 工作流FDE 最特殊的地方在于他既要能跟客户业务方聊明白“你们这个审批流程到底卡在哪”又要能当场打开编辑器写一段工具调用代码验证想法。这种“上下兼容”的能力组合在传统分工体系里是缺失的。售前不懂代码研发不懂业务中间就出现了一个真空地带FDE 就是来填这个真空的。2.3 双向赋能FDE 模式对甲乙双方的价值“双向赋能”这个词听起来有点虚但放到 FDE 场景里其实很具体。对客户方来说FDE 带来的最大价值是降低试错成本。Agent 项目最怕的是“做了半年发现方向错了”。FDE 在现场用真实数据快速搭原型一两周就能让客户看到“这个方向行不行”。行就继续深入不行就换方向试错成本从几个月压缩到几天。另外FDE 在共创过程中会把一些工程思维和方法论传递给客户的业务团队比如怎么定义任务边界、怎么设计人机协作流程这些知识会留在客户组织里。对交付方来说FDE 模式的价值是提高交付成功率和客户粘性。传统项目交付完客户觉得“也就那样”续约率低。FDE 在现场跟客户一起把问题解决掉客户会觉得“这帮人真懂我的业务”后续扩展新场景时第一个想到你。而且 FDE 在現場积累的业务理解会反哺到产品团队让产品迭代更有方向。我认识一个做 AI 客服 Agent 的团队他们的 FDE 在客户现场发现“客户最需要的不是自动回复而是自动生成回复建议给人工审核”这个洞察直接改变了产品路线图。3. FDE 核心能力拆解与实操要点3.1 业务翻译能力把模糊需求变成可执行任务FDE 第一项核心能力是“业务翻译”。客户说“我想让 AI 帮我处理合同”这句话信息量几乎为零。FDE 要做的是通过追问和观察把它拆成可执行的任务链。我通常会用一套“五问拆解法”触发条件是什么合同从哪里来邮件、系统推送还是人工上传输入是什么格式PDF、Word 还是扫描件有没有固定模板处理动作有哪些提取关键字段、比对条款、生成摘要还是直接审批输出给谁用结果给法务看、给业务看还是直接进系统异常怎么处理识别不了怎么办有歧义怎么办谁来兜底这五个问题问完一个模糊的“处理合同”就变成了“从邮箱监听新邮件 → 下载 PDF 附件 → 提取甲乙方、金额、付款条款 → 与标准模板比对差异 → 生成差异报告 → 推送给法务企业微信 → 法务确认后回写合同系统”这样一条清晰的任务链。注意FDE 在翻译需求时不要追求一次问全。客户往往说不清楚你需要先搭一个粗糙的原型给他看他看到具体的东西才能给出有效反馈。先做出来再问比一直问不做效率高得多。3.2 快速原型能力用 Agent 框架搭出可验证的 DemoFDE 的第二项能力是快速把想法变成可运行的原型。这里涉及 Agent 框架选型和 Skill 编排。目前主流的 Agent 开发框架有几种路线。一种是代码优先的比如用 Python 写 Agent 逻辑灵活但开发速度慢一种是配置优先的通过可视化编排工具拖拽节点上手快但复杂逻辑受限还有一种是混合模式核心逻辑用代码写外围用配置。FDE 在现场通常时间紧我建议优先选配置优先或混合模式先把流程跑通后面再优化。Skill 的设计是原型阶段的关键。一个 Skill 就是一个可复用的能力单元比如“提取 PDF 文本”“调用企业微信 API”“查询合同数据库”。FDE 在现场要快速判断哪些 Skill 可以直接用现成的哪些需要现场写。我的经验是通用能力用现成的业务特有逻辑现场写。比如文件解析、HTTP 请求这些通用 Skill 直接用但“根据公司合同模板比对差异”这种就要现场写一个。# 一个简单的 Skill 示例提取合同关键字段 # 实际项目中会根据具体业务调整 prompt 和校验逻辑 def extract_contract_fields(text): prompt 从以下合同文本中提取 - 甲方名称 - 乙方名称 - 合同金额 - 付款方式 - 签约日期 以 JSON 格式返回找不到的字段填 null。 result llm_call(prompt text) return validate_json(result)这个 Skill 看起来简单但现场写的时候有几个细节要注意。一是输出格式要严格约束不约束的话模型返回的 JSON 可能带 markdown 代码块标记后面解析会报错。二是要有校验和重试模型偶尔会漏字段或格式错误加一层校验和重试能显著提高稳定性。三是prompt 里要给出字段的边界定义比如“合同金额”是含税还是不含税不写清楚模型会猜。3.3 现场沟通能力跟业务方泡在一起的本事FDE 第三项能力是沟通但这个沟通跟销售式的沟通不一样。销售沟通是为了签单FDE 沟通是为了把业务逻辑挖干净。我自己的做法是“跟班观察 即时追问”。不要只坐在会议室里问要坐到业务人员旁边看他实际操作。他打开哪个系统、点哪个按钮、复制什么数据、粘贴到哪里这些动作里藏着大量他没说出来的信息。看到不懂的就当场问“这一步为什么要复制到 Excel 里”“这个字段你一般怎么判断”往往能挖出关键的业务规则。还有一个技巧是用他们的行话。每个行业都有自己的黑话比如金融行业说“头寸”“敞口”物流行业说“落货”“分拨”。FDE 如果能用客户的行话交流客户会觉得“你懂我”信任建立得快很多。我刚入行的时候不懂这个用技术术语跟业务方聊对方一脸茫然后来我强迫自己学他们的说法沟通效率翻倍。实操心得现场沟通时带一个笔记本把客户说的关键规则、例外情况、人名系统名都记下来。不要依赖记忆Agent 项目细节太多漏一个例外条件后面就可能出大问题。4. FDE 项目实操全流程拆解4.1 进场准备前三天要搞定的事FDE 进场不是到了就开始写代码前三天要做几件关键的事。第一天对齐目标和边界。跟客户的项目发起人聊清楚这次共创要解决的核心问题是什么成功标准是什么哪些不在范围内。这一步很重要不然后面容易范围蔓延。我见过一个项目本来只做合同审核结果客户业务方不断加需求最后变成了要做整个法务系统FDE 累死也做不完。第二天摸清数据和系统。要拿到真实的数据样本了解数据存在哪里、什么格式、质量如何。同时要搞清楚 Agent 需要对接哪些系统有没有 API权限怎么开。这一步经常卡住因为客户 IT 部门走流程慢所以要提前启动。第三天搭建开发环境和最小原型。把 Agent 框架跑起来用真实数据跑通一个最简单的流程。哪怕只是“读取文件 → 调用模型 → 输出结果”这样一条线先跑通再说。跑通之后拿给客户看客户马上就能给出反馈。时间关键任务产出物常见卡点第1天对齐目标、边界、成功标准项目范围说明客户内部意见不统一第2天数据摸底、系统对接调研数据样本、接口清单IT 部门排期慢第3天环境搭建、最小原型跑通可运行的 Demo环境依赖冲突4.2 共创迭代两周一个循环的节奏FDE 项目的核心节奏是“两周一个共创循环”。每个循环包含需求细化 → 原型开发 → 现场演示 → 反馈收集 → 调整优化。第一个循环通常最粗糙可能只覆盖主流程的 60%但一定要让客户看到东西。客户看到具体的东西之后反馈会非常具体比如“这个字段提取错了”“这个审批节点应该跳过”“这个提示语太生硬”。这些反馈比任何需求文档都有价值。第二个循环开始补异常处理和边界情况。Agent 项目最花时间的不是主流程而是各种异常。比如合同扫描件模糊怎么办、系统返回超时怎么办、模型输出格式不对怎么办。这些要在第二个循环里集中处理。第三个循环做集成和优化。把 Agent 跟客户的实际系统对接优化响应速度和准确率准备上线。注意每个循环结束都要有明确的“可演示成果”不要闷头开发两周然后说“还没做完”。FDE 的价值就在于持续可见的进展客户看到进展才会有信心继续投入。4.3 交付与交接让客户能自己跑起来FDE 项目最终要交付的不只是一个能跑的 Agent还包括客户团队能自己维护和扩展的能力。交付物通常包括Agent 工作流配置文件、Skill 代码库、部署文档、操作手册、常见问题排查指南。但光有文档不够FDE 要走之前要做几场培训让客户的 IT 人员和业务人员都能上手。我自己的做法是“影子运行”一周。FDE 还在现场但让客户团队自己操作FDE 在旁边看着有问题当场解决。这一周下来客户团队基本就能独立跑了。另外要留一个“扩展指南”告诉客户如果想加新场景应该改哪里、怎么测试、注意什么。这样客户后续自己就能迭代不用每次都找原厂。5. 常见问题与排查技巧实录5.1 Agent 执行报错怎么快速定位Agent 项目最常见的报错是“agent execution terminated due to error”这个报错信息极其模糊可能是模型调用失败、工具调用超时、输出格式解析错误、权限不足等任何原因。我的排查顺序是看日志Agent 框架一般会记录每一步的输入输出先看报错发生在哪一步。单独测 Skill把出错的 Skill 单独拿出来跑排除是 Skill 本身的问题还是编排的问题。检查输入很多时候是输入数据格式跟预期不符比如 PDF 解析出来是空字符串。检查权限调用外部 API 时 token 过期或权限不足也会报这个错。加超时和重试如果是偶发的超时加超时和重试机制通常能解决。报错现象可能原因排查方法解决方案execution terminated模型调用失败看模型 API 日志检查 key、配额、网络execution terminated工具调用超时单独测工具加超时、重试、降级execution terminated输出解析失败打印原始输出加格式约束、校验重试execution terminated权限不足检查 token 和权限重新授权或换凭证结果不稳定模型幻觉对比多次输出加约束、加校验、换模型5.2 客户说“效果不好”时怎么接客户说“效果不好”是最常见的反馈但这句话本身没有可操作性。FDE 要做的是把它拆成具体问题。我会问三个问题哪些 case 不好不好在哪里期望是什么让客户举出具体例子然后一起看这个例子的输入输出定位是哪个环节出了问题。是提取错了、判断错了还是格式不对定位到具体环节之后解决起来就快了。还有一种情况是客户期望本身不合理。比如客户期望 Agent 100% 准确这在当前技术条件下不现实。这时候 FDE 要管理期望说明“我们会做到 90% 以上剩下的 10% 需要人工兜底”并且设计好人机协作流程。把“AI 全自动”变成“AI 辅助人工”客户接受度会高很多。5.3 FDE 自己的避坑清单做了几个 FDE 项目之后我总结了几条自己的避坑经验不要承诺做不到的事现场气氛热烈的时候容易上头客户说什么都答应。但 Agent 的能力边界要心里有数做不到的当场说清楚比后面翻车好。不要跳过数据摸底我吃过亏进场第三天就开始写代码写到一半发现客户数据格式跟预想的完全不一样返工重来。数据摸底再花时间也值得。不要一个人扛FDE 在现场压力很大技术、沟通、项目管理都要管。背后要有一个支持团队遇到搞不定的技术问题能快速求助。不要忽略文档现场节奏快容易只顾着写代码不写文档。但 FDE 走了之后客户要维护文档不全后面全是坑。每天花半小时整理当天的工作后面省很多事。不要忘记轮岗和社区分享FDE 长期在外容易跟公司内部脱节。定期回公司做分享把现场经验沉淀成可复用的 Skill 和方案对自己和团队都有价值。6. FDE 工程师的成长路径与学习建议6.1 从哪个方向切入比较现实如果你现在做的是传统实施、售前或者开发想转 FDE我建议从自己最熟悉的领域切入。做金融实施的先做金融行业的 FDE做电商开发的先做电商 Agent 的 FDE。行业知识是 FDE 的核心壁垒不要轻易丢掉。技术方面需要补的主要是 Agent 框架的使用、Prompt 工程、基础的数据处理能力。不需要成为算法专家但要能理解模型的能力边界知道什么能做、什么做不了、大概怎么做。吴恩达的 Agent 教程、主流 Agent 框架的官方文档都是不错的起点。6.2 现场快速学习的技巧FDE 经常要面对自己不熟悉的行业快速学习能力很重要。我的方法是“三遍法”第一遍让客户讲一遍业务流程我只听不打断第二遍我复述一遍让客户纠正第三遍我画成流程图让客户确认。三遍下来基本就能把业务逻辑搞清楚。另外要善用 AI 辅助。遇到不懂的行业术语当场用 AI 查写 Skill 的时候让 AI 帮忙生成初版代码再改。FDE 的核心竞争力不是什么都懂而是快速搞懂并落地的能力。6.3 长期发展的几个方向FDE 做久了有几个发展方向。一是行业专家型 FDE深耕某个行业成为这个行业 Agent 落地的首选人选。二是平台型 FDE把现场经验沉淀成可复用的 Skill 库和方案模板提高整体交付效率。三是转产品或解决方案把一线洞察带回产品团队影响产品方向。不管走哪个方向FDE 阶段积累的“现场感”都是宝贵资产。知道客户真正需要什么、知道方案落地会卡在哪里这种判断力是坐在办公室里学不到的。我在实际项目里最大的体会是FDE 这个角色本质上是在填一个“技术与业务之间的翻译层”。AI Agent 的能力越来越强但客户不会因为技术强就买单他们买单是因为问题被解决了。FDE 就是那个把技术能力翻译成业务价值的人。这个角色累但成就感也强每次看到客户说“这个东西真省了我好多事”就觉得值了。
事件驱动架构深度解析)
