1. FDE 模式到底是什么从一个被误读的岗位说起FDE 这三个字母全称是 Forward Deployed Engineer中文一般译作“前线部署工程师”或“前置交付工程师”。我第一次听到这个词是在一个做企业级 AI 落地的项目群里当时有人发了一句“我们这边 FDE 缺口很大有没有推荐的”底下跟了一串问号。很多人第一反应是“这不就是售前工程师换了个马甲吗”也有人觉得“不就是驻场开发”。这两种理解都不算错但都只摸到了表皮。FDE 的本质是把工程能力直接推到业务最前线让写代码的人和用系统的人坐在同一张桌子上把需求确认、方案设计、原型验证、上线调优这几件事压缩进一个闭环里。它和传统交付模式最大的区别在于传统模式是“需求方提需求—产品经理翻译—研发排期—测试验收—交付上线”中间隔着好几层信息衰减FDE 模式是把这条链路砍到最短工程师自己就是需求翻译器、方案设计者和第一责任人。为什么这两年 FDE 突然被频繁提起核心推手是 AI Agent 和 Skill 体系的爆发。大模型能力再强落到具体业务场景里总有一堆“最后一公里”的问题数据格式对不上、权限体系接不进去、业务术语模型听不懂、输出结果不稳定。这些问题不是靠一个通用产品能解决的必须有人蹲在现场一边理解业务一边改代码。FDE 就是干这个的。这篇文章适合三类人看一是正在考虑转型 FDE 或者组建 FDE 团队的工程师和技术管理者二是想搞清楚 AI Agent 落地为什么这么难的产品和业务同学三是对“前线共创、双向赋能”这套协作模式感兴趣、想在自己团队里试点的实践者。我会从模式设计、核心能力、实操流程、常见坑四个维度展开尽量把我在实际项目里踩过的坑和总结的方法讲透。2. 前线共创的底层逻辑为什么要把工程师推到业务现场2.1 信息衰减定律与“翻译损耗”做过企业级项目的人都有体会一个需求从业务方嘴里说出来到研发手里变成代码中间至少要经过三轮“翻译”。业务方说“我要一个能自动识别合同风险的助手”产品经理翻译成“需要合同文本解析、风险点标注、结果导出三个功能模块”研发再翻译成“调用 OCR 接口、接大模型做实体识别、前端做高亮渲染”。每一轮翻译都会丢信息也会加臆测。我见过一个特别典型的案例某团队做合同审核 Agent产品文档里写的是“识别风险条款并给出修改建议”。研发按这个理解做出来结果业务方一看就炸了——他们真正想要的是“在原文上直接标注风险等级并且按风险等级排序让法务优先处理高风险项”。这个需求在产品文档里完全没体现因为产品经理觉得“排序”是理所当然的没必要写。但研发不知道这个“理所当然”做出来的东西就是不能用。FDE 模式解决这个问题的办法很直接让写代码的人直接听业务方怎么说直接看业务方怎么用。信息不再经过中间层翻译损耗自然就降下来了。这不是说产品经理不重要而是说在 AI 落地这种高度依赖场景理解的领域多一层翻译就多一层风险。2.2 双向赋能不只是工程师教业务业务也在教工程师“双向赋能”这个词听起来有点官方但拆开看很实在。FDE 到业务现场一方面是把工程能力带过去——教业务方怎么用 Agent、怎么提需求、怎么评估效果另一方面是把业务知识带回来——业务方每天在用的流程、术语、例外情况这些是任何需求文档都写不全的。我在一个制造业项目里做过实验让 FDE 在车间跟了三天班记录工人实际使用质检系统的每一个操作步骤。结果发现系统设计时假设的“标准流程”和工人实际操作的“野路子”差了十万八千里。工人会先把图片导到本地用另一个工具预处理再传回系统因为系统自带的预处理效果不好。这个信息如果靠需求调研工人根本不会说因为他们觉得“这不是系统的问题是我自己想办法绕过去”。但 FDE 在现场看到了回来就把预处理模块重写了。双向赋能的另一个层面是FDE 在业务现场积累的场景知识可以反哺到产品迭代里。一个 FDE 发现的共性问题可能代表十个客户都有这个需求。这种从一线来的输入比坐在办公室里拍脑袋想需求要靠谱得多。2.3 FDE 与 AI Agent、Skill 体系的关系AI Agent 的落地本质上是一个“能力编排”问题。大模型提供基础能力Skill 提供具体场景的执行逻辑Agent 负责调度和决策。但 Skill 从哪来不是凭空写出来的是从业务场景里长出来的。FDE 在这个体系里的角色就是“Skill 的催生者”。他们在现场发现某个操作反复出现就把它抽象成一个 Skill发现某个判断逻辑业务方总是要手动做就把它固化到 Agent 的决策流程里。没有 FDESkill 体系就是空中楼阁写出来的东西没人用有了 FDESkill 是从真实需求里长出来的落地率完全不一样。我参与过一个客服 Agent 项目最初产品团队设计了二十多个 Skill覆盖了他们认为客服需要的所有能力。结果上线后客服实际高频使用的只有五个另外十几个几乎没人碰。后来 FDE 进场跟客服坐了一周重新梳理出八个真正高频的场景把原来的 Skill 砍掉一半、重写一半使用率才上来。这个例子说明Skill 的设计不能靠猜必须靠现场观察。3. FDE 的核心能力拆解不是谁都能干这个活3.1 技术能力全栈是底线AI 工程是加分项FDE 的技术要求比普通研发更宽因为他们在现场没有后援。后端要能写 API、能调数据库、能处理并发前端要能改页面、能调交互、能适配不同终端运维要能看日志、能排查网络问题、能临时扩容。这不是说 FDE 要样样精通而是说遇到问题不能只会说“这不是我的模块”。AI 工程能力是这两年新增的硬要求。具体包括理解大模型的基本原理和局限知道什么场景适合用 Prompt 解决、什么场景需要 Fine-tune、什么场景必须上 RAG能写 Skill 脚本把业务逻辑封装成可复用的模块能调 Agent 框架知道怎么编排多个 Skill 的调用顺序和异常处理。我面过不少 FDE 候选人技术能力达标的不在少数但真正能干活的不多。区别在哪在于“能不能在信息不完整的情况下做决策”。现场不会给你完整的需求文档业务方说的和实际要的经常不一致系统环境和你本地完全两回事。这种情况下能不能快速判断“先做什么、后做什么、什么可以暂时绕过”是 FDE 的核心竞争力。3.2 业务理解力三天摸清一个行业的本事FDE 不可能在每个行业都深耕多年但必须有快速摸清一个行业的能力。我的经验是三天时间足够理解一个业务场景的 80%。第一天看流程把业务方每天的操作步骤走一遍第二天看数据搞清楚输入输出是什么、数据从哪来到哪去第三天看例外问清楚“什么情况下这个流程会走不通”。这个过程中最重要的是问对问题。不要问“你们需要什么功能”要问“你们现在怎么做这件事”“哪一步最花时间”“哪一步最容易出错”。业务方对“需要什么功能”的回答往往是模糊的但对“现在怎么做”的回答是具体的。从具体操作里抽象出需求比直接问需求要准确得多。3.3 沟通与协作在技术和业务之间当“人肉翻译”FDE 的沟通能力不是指会说话而是指能把技术语言翻译成业务语言也能把业务语言翻译成技术语言。业务方说“这个结果不准”FDE 要能判断是数据问题、模型问题还是交互问题研发说“这个接口不支持并发”FDE 要能判断是架构问题还是配置问题以及能不能用临时方案绕过。我总结了一个“三层翻译法”第一层把业务描述翻译成技术问题第二层把技术方案翻译成业务影响第三层把双方的分歧翻译成可验证的假设。比如业务方说“Agent 回答太慢”第一层翻译是“响应时间超过阈值”第二层翻译是“如果优化到 2 秒内业务方愿意接受吗”第三层翻译是“我们先测一下是模型推理慢还是网络传输慢用数据说话”。3.4 轮岗与晋升机制FDE 的成长路径怎么设计FDE 的轮岗机制和传统研发不一样。传统研发是在技术栈里轮岗FDE 是在业务场景里轮岗。一个 FDE 今年做金融风控明年可能做医疗问诊后年做工业质检。这种轮岗看起来“不深耕”但实际上是在积累“场景迁移能力”——把一个行业的解决方案抽象成通用模式再迁移到另一个行业。晋升机制也要相应调整。传统研发看代码质量、看技术深度FDE 要看落地效果、看客户反馈、看场景抽象能力。我见过一个团队设计的 FDE 晋升标准分三个维度交付维度项目按时上线、业务方满意度、技术维度Skill 复用率、方案通用性、社区维度经验分享、文档贡献。这个标准比单纯看代码行数要合理得多。4. 实操流程一个 FDE 项目的完整生命周期4.1 进场前的准备别急着写代码FDE 进场前最重要的事不是准备技术方案而是搞清楚“这个项目为什么需要 FDE”。是因为产品功能覆盖不了业务需求是因为业务方不知道怎么用 AI还是因为系统集成太复杂需要现场调试不同的原因进场后的策略完全不一样。我的习惯是进场前做三件事第一要一份业务方的组织架构图搞清楚谁是决策者、谁是使用者、谁是影响者第二要一份现有系统的操作手册哪怕不完整也要至少知道业务方现在用什么工具第三准备一个“最小可演示原型”不用完整但要让业务方看到“AI 能做什么”。这个原型的作用不是交付而是建立信任——业务方看到你能做出东西才愿意跟你说真话。注意不要带着“完整方案”进场。完整方案意味着你已经假设了自己知道业务方要什么而现场往往会推翻这些假设。带一个可调整的框架比带一个完整的方案更有用。4.2 现场诊断用“跟班法”找到真需求现场诊断的核心方法是“跟班”。不是坐在会议室里访谈而是跟着业务方实际工作一天。看他们怎么打开系统、怎么输入数据、怎么处理异常、怎么跟同事沟通。这个过程里你会发现大量“文档里没写、但实际每天都在发生”的操作。我做过一个财务对账 Agent 的项目访谈时财务说“主要需求是自动匹配流水”。跟班一天后发现他们 60% 的时间花在“处理匹配失败的异常”上而不是匹配本身。匹配算法再准异常处理不好整体效率还是上不去。后来我们把重点放在异常分类和自动处理上效果比优化匹配算法好得多。跟班时要注意记录三类信息高频操作每天做很多次的、高耗时操作单次花时间长的、高错误率操作经常出错的。这三类操作是 Agent 最应该优先覆盖的场景。4.3 方案设计与快速验证两天出一个可演示版本现场诊断结束后FDE 需要在两天内出一个可演示版本。这个版本不需要完整但必须覆盖最高频的场景并且能让业务方实际用起来。我的做法是用一个 Skill 解决一个具体问题用 Agent 串起两到三个 Skill形成一个最小闭环。比如做合同审核 Agent第一版可能只做“风险条款识别”这一个 Skill但要做到上传合同后能自动标出风险条款能按风险等级排序能导出标注结果。其他功能先不做让业务方先用这个最小版本收集反馈后再迭代。这个阶段的关键是“快”。不要追求完美不要追求覆盖所有场景先让业务方看到东西、用起来、提意见。业务方的反馈往往比 FDE 自己的判断更准因为他们每天都在用。4.4 迭代与交付把现场经验固化成 Skill迭代阶段的核心工作是把现场验证过的解决方案固化成可复用的 Skill。一个 Skill 应该包含触发条件什么情况下调用、输入输出定义需要什么数据、产出什么结果、异常处理出错时怎么办、效果评估怎么判断做得好不好。我通常会把 Skill 分成三类通用 Skill跨场景复用的比如文本分类、实体识别、行业 Skill特定行业用的比如金融风控规则、医疗术语映射、客户 Skill特定客户定制的比如某公司的审批流程。通用 Skill 和行业 Skill 尽量做到可配置客户 Skill 允许硬编码但要做好版本管理。交付时要注意不是交付一个“完成品”而是交付一个“可维护的系统”。业务方需要知道怎么改配置、怎么加 Skill、怎么排查常见问题。FDE 不可能永远驻场业务方必须有能力自己维护一部分。5. 常见问题与排查技巧实录5.1 Agent 执行中断从日志里找线索Agent 执行中断是最常见的问题之一报错信息往往是“execution terminated due to error”这种模糊描述。我的排查顺序是先看 Agent 框架的日志确认是哪个 Skill 调用失败再看 Skill 的日志确认是输入问题、逻辑问题还是外部依赖问题最后看外部依赖的日志确认是网络问题、权限问题还是服务不可用。有一个容易被忽略的点Agent 的上下文长度限制。如果对话轮次太多上下文超限Agent 可能会在中途“忘记”之前的指令导致执行中断。解决办法是定期清理上下文或者把关键指令固化到 System Prompt 里。5.2 Skill 不生效检查触发条件和优先级Skill 不生效的原因通常有三个触发条件没写对、优先级被其他 Skill 覆盖、输入数据格式不匹配。我遇到过一个案例一个“日期解析”Skill 死活不生效排查半天发现是另一个“通用文本处理”Skill 的优先级更高把日期文本先处理掉了。调整优先级后问题解决。建议在 Skill 设计时加一个“调试模式”可以手动触发某个 Skill 并查看输入输出。这个功能在排查问题时非常有用比看日志快得多。5.3 业务方不配合先解决信任问题FDE 遇到的最大挑战往往不是技术问题而是业务方不配合。业务方不配合的原因通常有三个不信任 AI 的能力、担心被替代、觉得增加了工作量。解决信任问题的办法是“先做一件小事”——找一个业务方觉得麻烦但又不重要的任务用 Agent 快速解决让业务方看到效果。信任是一点点建立的不要指望一次演示就能说服所有人。5.4 常见问题速查表问题现象可能原因排查方法解决思路Agent 执行中断上下文超限、Skill 调用失败、外部依赖不可用查 Agent 日志、查 Skill 日志、查外部服务状态清理上下文、修复 Skill、增加重试机制Skill 不生效触发条件错误、优先级冲突、输入格式不匹配开调试模式手动触发、检查优先级配置、检查输入数据修正触发条件、调整优先级、增加数据预处理响应速度慢模型推理慢、网络延迟、Skill 链路过长分段计时、检查网络、简化 Skill 链路换轻量模型、优化网络、合并 Skill输出结果不稳定Prompt 不够明确、温度参数过高、输入数据波动固定输入测试、调整温度参数、检查数据质量优化 Prompt、降低温度、增加数据校验业务方不使用操作太复杂、效果不明显、习惯难改变跟班观察、收集反馈、简化操作简化交互、先做高频场景、培训激励提示排查问题时永远先从“最简单的可能性”开始。我见过太多人一上来就怀疑模型有问题结果发现是 API Key 过期了。6. 工具选型与团队配置FDE 不是单打独斗6.1 Agent 框架怎么选看场景不看热度Agent 框架的选择没有绝对标准关键看场景。如果场景简单、Skill 数量少用轻量级框架就够了没必要上重型编排引擎如果场景复杂、需要多 Agent 协作就要选支持复杂编排的框架。我的经验是先用最简单的方案跑通一个场景遇到瓶颈再换框架。不要一开始就追求“架构先进”能解决问题的架构才是好架构。选型时要重点看三个能力Skill 注册和调用的灵活性、上下文管理的可控性、异常处理和重试机制。这三个能力决定了 Agent 在实际场景里能不能稳定运行。6.2 FDE 团队配置三个人起步一个最小可用的 FDE 团队三个人就够了一个偏后端的 FDE负责系统集成和数据处理一个偏前端的 FDE负责交互设计和界面适配一个偏 AI 的 FDE负责 Skill 开发和 Agent 调优。三个人可以互相补位遇到问题不至于卡死。如果项目规模大可以按业务场景分组每组配一个 FDE 负责人。但不要按技术栈分组因为 FDE 的核心价值就是“全栈解决问题”按技术栈分组会破坏这个价值。6.3 社区分享机制让经验流动起来FDE 的经验如果只留在个人脑子里团队就永远在重复踩坑。我建议建立三个分享机制周会分享每周每人分享一个现场发现的问题和解决方法、文档沉淀把常见问题和解决方案写成可检索的文档、Skill 市场把可复用的 Skill 放到内部市场其他人可以直接调用。社区分享的关键是“低门槛”。不要要求写长篇报告一句话、一个截图、一段代码都行。分享的人多了经验自然就流动起来了。7. 我踩过的坑和总结的经验第一个坑过度承诺。FDE 在现场容易被业务方的期待推着走答应了很多做不到的事。我的教训是承诺之前先验证验证之前先做最小原型。宁可说“我先试试”也不要说“这个没问题”。第二个坑忽视业务方的学习成本。Agent 做得再好业务方不会用也是白搭。我现在做任何方案都会先问“业务方需要花多少时间学会用这个”。如果学习成本太高就简化方案哪怕功能少一点。第三个坑Skill 设计太“技术化”。Skill 的名字和描述要用人话不要用技术术语。业务方看到“文本实体识别 Skill”不知道是什么看到“自动找出合同里的风险条款”就明白了。Skill 是给人用的不是给机器看的。最后一个经验FDE 的价值不在于写了多少代码而在于让业务方真正用起来。我见过技术很强的 FDE做出来的东西业务方不用也见过技术一般的 FDE做出来的东西业务方天天用。区别就在于有没有把“业务方用起来”当成第一目标。技术是手段落地才是目的。
FDE前线部署工程师：AI Agent落地与Skill体系的前线共创模式
1. FDE 模式到底是什么从一个被误读的岗位说起FDE 这三个字母全称是 Forward Deployed Engineer中文一般译作“前线部署工程师”或“前置交付工程师”。我第一次听到这个词是在一个做企业级 AI 落地的项目群里当时有人发了一句“我们这边 FDE 缺口很大有没有推荐的”底下跟了一串问号。很多人第一反应是“这不就是售前工程师换了个马甲吗”也有人觉得“不就是驻场开发”。这两种理解都不算错但都只摸到了表皮。FDE 的本质是把工程能力直接推到业务最前线让写代码的人和用系统的人坐在同一张桌子上把需求确认、方案设计、原型验证、上线调优这几件事压缩进一个闭环里。它和传统交付模式最大的区别在于传统模式是“需求方提需求—产品经理翻译—研发排期—测试验收—交付上线”中间隔着好几层信息衰减FDE 模式是把这条链路砍到最短工程师自己就是需求翻译器、方案设计者和第一责任人。为什么这两年 FDE 突然被频繁提起核心推手是 AI Agent 和 Skill 体系的爆发。大模型能力再强落到具体业务场景里总有一堆“最后一公里”的问题数据格式对不上、权限体系接不进去、业务术语模型听不懂、输出结果不稳定。这些问题不是靠一个通用产品能解决的必须有人蹲在现场一边理解业务一边改代码。FDE 就是干这个的。这篇文章适合三类人看一是正在考虑转型 FDE 或者组建 FDE 团队的工程师和技术管理者二是想搞清楚 AI Agent 落地为什么这么难的产品和业务同学三是对“前线共创、双向赋能”这套协作模式感兴趣、想在自己团队里试点的实践者。我会从模式设计、核心能力、实操流程、常见坑四个维度展开尽量把我在实际项目里踩过的坑和总结的方法讲透。2. 前线共创的底层逻辑为什么要把工程师推到业务现场2.1 信息衰减定律与“翻译损耗”做过企业级项目的人都有体会一个需求从业务方嘴里说出来到研发手里变成代码中间至少要经过三轮“翻译”。业务方说“我要一个能自动识别合同风险的助手”产品经理翻译成“需要合同文本解析、风险点标注、结果导出三个功能模块”研发再翻译成“调用 OCR 接口、接大模型做实体识别、前端做高亮渲染”。每一轮翻译都会丢信息也会加臆测。我见过一个特别典型的案例某团队做合同审核 Agent产品文档里写的是“识别风险条款并给出修改建议”。研发按这个理解做出来结果业务方一看就炸了——他们真正想要的是“在原文上直接标注风险等级并且按风险等级排序让法务优先处理高风险项”。这个需求在产品文档里完全没体现因为产品经理觉得“排序”是理所当然的没必要写。但研发不知道这个“理所当然”做出来的东西就是不能用。FDE 模式解决这个问题的办法很直接让写代码的人直接听业务方怎么说直接看业务方怎么用。信息不再经过中间层翻译损耗自然就降下来了。这不是说产品经理不重要而是说在 AI 落地这种高度依赖场景理解的领域多一层翻译就多一层风险。2.2 双向赋能不只是工程师教业务业务也在教工程师“双向赋能”这个词听起来有点官方但拆开看很实在。FDE 到业务现场一方面是把工程能力带过去——教业务方怎么用 Agent、怎么提需求、怎么评估效果另一方面是把业务知识带回来——业务方每天在用的流程、术语、例外情况这些是任何需求文档都写不全的。我在一个制造业项目里做过实验让 FDE 在车间跟了三天班记录工人实际使用质检系统的每一个操作步骤。结果发现系统设计时假设的“标准流程”和工人实际操作的“野路子”差了十万八千里。工人会先把图片导到本地用另一个工具预处理再传回系统因为系统自带的预处理效果不好。这个信息如果靠需求调研工人根本不会说因为他们觉得“这不是系统的问题是我自己想办法绕过去”。但 FDE 在现场看到了回来就把预处理模块重写了。双向赋能的另一个层面是FDE 在业务现场积累的场景知识可以反哺到产品迭代里。一个 FDE 发现的共性问题可能代表十个客户都有这个需求。这种从一线来的输入比坐在办公室里拍脑袋想需求要靠谱得多。2.3 FDE 与 AI Agent、Skill 体系的关系AI Agent 的落地本质上是一个“能力编排”问题。大模型提供基础能力Skill 提供具体场景的执行逻辑Agent 负责调度和决策。但 Skill 从哪来不是凭空写出来的是从业务场景里长出来的。FDE 在这个体系里的角色就是“Skill 的催生者”。他们在现场发现某个操作反复出现就把它抽象成一个 Skill发现某个判断逻辑业务方总是要手动做就把它固化到 Agent 的决策流程里。没有 FDESkill 体系就是空中楼阁写出来的东西没人用有了 FDESkill 是从真实需求里长出来的落地率完全不一样。我参与过一个客服 Agent 项目最初产品团队设计了二十多个 Skill覆盖了他们认为客服需要的所有能力。结果上线后客服实际高频使用的只有五个另外十几个几乎没人碰。后来 FDE 进场跟客服坐了一周重新梳理出八个真正高频的场景把原来的 Skill 砍掉一半、重写一半使用率才上来。这个例子说明Skill 的设计不能靠猜必须靠现场观察。3. FDE 的核心能力拆解不是谁都能干这个活3.1 技术能力全栈是底线AI 工程是加分项FDE 的技术要求比普通研发更宽因为他们在现场没有后援。后端要能写 API、能调数据库、能处理并发前端要能改页面、能调交互、能适配不同终端运维要能看日志、能排查网络问题、能临时扩容。这不是说 FDE 要样样精通而是说遇到问题不能只会说“这不是我的模块”。AI 工程能力是这两年新增的硬要求。具体包括理解大模型的基本原理和局限知道什么场景适合用 Prompt 解决、什么场景需要 Fine-tune、什么场景必须上 RAG能写 Skill 脚本把业务逻辑封装成可复用的模块能调 Agent 框架知道怎么编排多个 Skill 的调用顺序和异常处理。我面过不少 FDE 候选人技术能力达标的不在少数但真正能干活的不多。区别在哪在于“能不能在信息不完整的情况下做决策”。现场不会给你完整的需求文档业务方说的和实际要的经常不一致系统环境和你本地完全两回事。这种情况下能不能快速判断“先做什么、后做什么、什么可以暂时绕过”是 FDE 的核心竞争力。3.2 业务理解力三天摸清一个行业的本事FDE 不可能在每个行业都深耕多年但必须有快速摸清一个行业的能力。我的经验是三天时间足够理解一个业务场景的 80%。第一天看流程把业务方每天的操作步骤走一遍第二天看数据搞清楚输入输出是什么、数据从哪来到哪去第三天看例外问清楚“什么情况下这个流程会走不通”。这个过程中最重要的是问对问题。不要问“你们需要什么功能”要问“你们现在怎么做这件事”“哪一步最花时间”“哪一步最容易出错”。业务方对“需要什么功能”的回答往往是模糊的但对“现在怎么做”的回答是具体的。从具体操作里抽象出需求比直接问需求要准确得多。3.3 沟通与协作在技术和业务之间当“人肉翻译”FDE 的沟通能力不是指会说话而是指能把技术语言翻译成业务语言也能把业务语言翻译成技术语言。业务方说“这个结果不准”FDE 要能判断是数据问题、模型问题还是交互问题研发说“这个接口不支持并发”FDE 要能判断是架构问题还是配置问题以及能不能用临时方案绕过。我总结了一个“三层翻译法”第一层把业务描述翻译成技术问题第二层把技术方案翻译成业务影响第三层把双方的分歧翻译成可验证的假设。比如业务方说“Agent 回答太慢”第一层翻译是“响应时间超过阈值”第二层翻译是“如果优化到 2 秒内业务方愿意接受吗”第三层翻译是“我们先测一下是模型推理慢还是网络传输慢用数据说话”。3.4 轮岗与晋升机制FDE 的成长路径怎么设计FDE 的轮岗机制和传统研发不一样。传统研发是在技术栈里轮岗FDE 是在业务场景里轮岗。一个 FDE 今年做金融风控明年可能做医疗问诊后年做工业质检。这种轮岗看起来“不深耕”但实际上是在积累“场景迁移能力”——把一个行业的解决方案抽象成通用模式再迁移到另一个行业。晋升机制也要相应调整。传统研发看代码质量、看技术深度FDE 要看落地效果、看客户反馈、看场景抽象能力。我见过一个团队设计的 FDE 晋升标准分三个维度交付维度项目按时上线、业务方满意度、技术维度Skill 复用率、方案通用性、社区维度经验分享、文档贡献。这个标准比单纯看代码行数要合理得多。4. 实操流程一个 FDE 项目的完整生命周期4.1 进场前的准备别急着写代码FDE 进场前最重要的事不是准备技术方案而是搞清楚“这个项目为什么需要 FDE”。是因为产品功能覆盖不了业务需求是因为业务方不知道怎么用 AI还是因为系统集成太复杂需要现场调试不同的原因进场后的策略完全不一样。我的习惯是进场前做三件事第一要一份业务方的组织架构图搞清楚谁是决策者、谁是使用者、谁是影响者第二要一份现有系统的操作手册哪怕不完整也要至少知道业务方现在用什么工具第三准备一个“最小可演示原型”不用完整但要让业务方看到“AI 能做什么”。这个原型的作用不是交付而是建立信任——业务方看到你能做出东西才愿意跟你说真话。注意不要带着“完整方案”进场。完整方案意味着你已经假设了自己知道业务方要什么而现场往往会推翻这些假设。带一个可调整的框架比带一个完整的方案更有用。4.2 现场诊断用“跟班法”找到真需求现场诊断的核心方法是“跟班”。不是坐在会议室里访谈而是跟着业务方实际工作一天。看他们怎么打开系统、怎么输入数据、怎么处理异常、怎么跟同事沟通。这个过程里你会发现大量“文档里没写、但实际每天都在发生”的操作。我做过一个财务对账 Agent 的项目访谈时财务说“主要需求是自动匹配流水”。跟班一天后发现他们 60% 的时间花在“处理匹配失败的异常”上而不是匹配本身。匹配算法再准异常处理不好整体效率还是上不去。后来我们把重点放在异常分类和自动处理上效果比优化匹配算法好得多。跟班时要注意记录三类信息高频操作每天做很多次的、高耗时操作单次花时间长的、高错误率操作经常出错的。这三类操作是 Agent 最应该优先覆盖的场景。4.3 方案设计与快速验证两天出一个可演示版本现场诊断结束后FDE 需要在两天内出一个可演示版本。这个版本不需要完整但必须覆盖最高频的场景并且能让业务方实际用起来。我的做法是用一个 Skill 解决一个具体问题用 Agent 串起两到三个 Skill形成一个最小闭环。比如做合同审核 Agent第一版可能只做“风险条款识别”这一个 Skill但要做到上传合同后能自动标出风险条款能按风险等级排序能导出标注结果。其他功能先不做让业务方先用这个最小版本收集反馈后再迭代。这个阶段的关键是“快”。不要追求完美不要追求覆盖所有场景先让业务方看到东西、用起来、提意见。业务方的反馈往往比 FDE 自己的判断更准因为他们每天都在用。4.4 迭代与交付把现场经验固化成 Skill迭代阶段的核心工作是把现场验证过的解决方案固化成可复用的 Skill。一个 Skill 应该包含触发条件什么情况下调用、输入输出定义需要什么数据、产出什么结果、异常处理出错时怎么办、效果评估怎么判断做得好不好。我通常会把 Skill 分成三类通用 Skill跨场景复用的比如文本分类、实体识别、行业 Skill特定行业用的比如金融风控规则、医疗术语映射、客户 Skill特定客户定制的比如某公司的审批流程。通用 Skill 和行业 Skill 尽量做到可配置客户 Skill 允许硬编码但要做好版本管理。交付时要注意不是交付一个“完成品”而是交付一个“可维护的系统”。业务方需要知道怎么改配置、怎么加 Skill、怎么排查常见问题。FDE 不可能永远驻场业务方必须有能力自己维护一部分。5. 常见问题与排查技巧实录5.1 Agent 执行中断从日志里找线索Agent 执行中断是最常见的问题之一报错信息往往是“execution terminated due to error”这种模糊描述。我的排查顺序是先看 Agent 框架的日志确认是哪个 Skill 调用失败再看 Skill 的日志确认是输入问题、逻辑问题还是外部依赖问题最后看外部依赖的日志确认是网络问题、权限问题还是服务不可用。有一个容易被忽略的点Agent 的上下文长度限制。如果对话轮次太多上下文超限Agent 可能会在中途“忘记”之前的指令导致执行中断。解决办法是定期清理上下文或者把关键指令固化到 System Prompt 里。5.2 Skill 不生效检查触发条件和优先级Skill 不生效的原因通常有三个触发条件没写对、优先级被其他 Skill 覆盖、输入数据格式不匹配。我遇到过一个案例一个“日期解析”Skill 死活不生效排查半天发现是另一个“通用文本处理”Skill 的优先级更高把日期文本先处理掉了。调整优先级后问题解决。建议在 Skill 设计时加一个“调试模式”可以手动触发某个 Skill 并查看输入输出。这个功能在排查问题时非常有用比看日志快得多。5.3 业务方不配合先解决信任问题FDE 遇到的最大挑战往往不是技术问题而是业务方不配合。业务方不配合的原因通常有三个不信任 AI 的能力、担心被替代、觉得增加了工作量。解决信任问题的办法是“先做一件小事”——找一个业务方觉得麻烦但又不重要的任务用 Agent 快速解决让业务方看到效果。信任是一点点建立的不要指望一次演示就能说服所有人。5.4 常见问题速查表问题现象可能原因排查方法解决思路Agent 执行中断上下文超限、Skill 调用失败、外部依赖不可用查 Agent 日志、查 Skill 日志、查外部服务状态清理上下文、修复 Skill、增加重试机制Skill 不生效触发条件错误、优先级冲突、输入格式不匹配开调试模式手动触发、检查优先级配置、检查输入数据修正触发条件、调整优先级、增加数据预处理响应速度慢模型推理慢、网络延迟、Skill 链路过长分段计时、检查网络、简化 Skill 链路换轻量模型、优化网络、合并 Skill输出结果不稳定Prompt 不够明确、温度参数过高、输入数据波动固定输入测试、调整温度参数、检查数据质量优化 Prompt、降低温度、增加数据校验业务方不使用操作太复杂、效果不明显、习惯难改变跟班观察、收集反馈、简化操作简化交互、先做高频场景、培训激励提示排查问题时永远先从“最简单的可能性”开始。我见过太多人一上来就怀疑模型有问题结果发现是 API Key 过期了。6. 工具选型与团队配置FDE 不是单打独斗6.1 Agent 框架怎么选看场景不看热度Agent 框架的选择没有绝对标准关键看场景。如果场景简单、Skill 数量少用轻量级框架就够了没必要上重型编排引擎如果场景复杂、需要多 Agent 协作就要选支持复杂编排的框架。我的经验是先用最简单的方案跑通一个场景遇到瓶颈再换框架。不要一开始就追求“架构先进”能解决问题的架构才是好架构。选型时要重点看三个能力Skill 注册和调用的灵活性、上下文管理的可控性、异常处理和重试机制。这三个能力决定了 Agent 在实际场景里能不能稳定运行。6.2 FDE 团队配置三个人起步一个最小可用的 FDE 团队三个人就够了一个偏后端的 FDE负责系统集成和数据处理一个偏前端的 FDE负责交互设计和界面适配一个偏 AI 的 FDE负责 Skill 开发和 Agent 调优。三个人可以互相补位遇到问题不至于卡死。如果项目规模大可以按业务场景分组每组配一个 FDE 负责人。但不要按技术栈分组因为 FDE 的核心价值就是“全栈解决问题”按技术栈分组会破坏这个价值。6.3 社区分享机制让经验流动起来FDE 的经验如果只留在个人脑子里团队就永远在重复踩坑。我建议建立三个分享机制周会分享每周每人分享一个现场发现的问题和解决方法、文档沉淀把常见问题和解决方案写成可检索的文档、Skill 市场把可复用的 Skill 放到内部市场其他人可以直接调用。社区分享的关键是“低门槛”。不要要求写长篇报告一句话、一个截图、一段代码都行。分享的人多了经验自然就流动起来了。7. 我踩过的坑和总结的经验第一个坑过度承诺。FDE 在现场容易被业务方的期待推着走答应了很多做不到的事。我的教训是承诺之前先验证验证之前先做最小原型。宁可说“我先试试”也不要说“这个没问题”。第二个坑忽视业务方的学习成本。Agent 做得再好业务方不会用也是白搭。我现在做任何方案都会先问“业务方需要花多少时间学会用这个”。如果学习成本太高就简化方案哪怕功能少一点。第三个坑Skill 设计太“技术化”。Skill 的名字和描述要用人话不要用技术术语。业务方看到“文本实体识别 Skill”不知道是什么看到“自动找出合同里的风险条款”就明白了。Skill 是给人用的不是给机器看的。最后一个经验FDE 的价值不在于写了多少代码而在于让业务方真正用起来。我见过技术很强的 FDE做出来的东西业务方不用也见过技术一般的 FDE做出来的东西业务方天天用。区别就在于有没有把“业务方用起来”当成第一目标。技术是手段落地才是目的。
