Agent 浪潮下的 FDE：把模型实力转化为业务成果
FDE · 系列第 4 篇
前面三篇文章，我们对 FDE 做了整体梳理：第一篇讲它为何是未来十年最关键的风口，第二篇讨论该招聘什么样的人、归属哪个部门、薪酬如何设计，第三篇对比了中国模式与硅谷路径的异同。但始终有一个悬而未决的问题：我们反复强调 FDE 是“把 AI 嵌入真实业务”，那 AI 究竟以什么方式嵌进去？
答案是 Agent。而“让模型能力在真实业务中落地”这件事，在 Agent 时代与过去截然不同——难度发生了根本性的变化。
原因何在？过去两年，大家实现的是“模型能力”：搭个知识库、做个对话窗口、让 AI 可以回答问题。你提问，它回应，这件事相对简单。但 Agent 不同——Agent 是“执行者”，它会自主查询数据、调用系统、推进流程、做出判断。Chatbot 时代，挑战在于让 AI 回答准确；Agent 时代，挑战在于让 AI 持续把事做对。这两件事之间的鸿沟，远超多数人的想象。
这一篇，我们将沿着“Agent 时代的难点 → FDE 具体职责 → 部署如何成为一门生意”这条脉络，把 Agent 时代的 FDE 讲明白。
先看一个令人警醒的案例。Cresta 的 FDE 负责人 Jove 提到，他许多客户“连自身目标都描述不清，SOP 也梳理不明”——更普遍的情况是，管理者设想的 SOP 与一线坐席实际执行的 SOP 存在巨大偏差。管理者脑海中的或许是理想状态，但 Jove 坦言：“随便抽 5% 的样本，你的顶尖坐席根本不是这样操作的。”
这句话点明了 Agent 落地与 Chatbot 落地的本质差异。回答问题，只需掌握提问技巧；但要让 Agent 真正干活，你首先需要将工作流抽象出来——这个流程包含哪些环节、每个环节的判定准则是什么、出现偏差由谁负责。对许多企业而言，这是一道从未触及的难题，因为过去这些经验从未被记录，仅存于资深员工的经验之中。
因此 Agent 时代的 FDE，首要任务往往不是编写代码，而是“共同定义”：协助客户将脑海中模糊的流程，转化为 Agent 可执行的步骤。这正契合崔牛会白皮书中的观点——FDE 不仅承担实现职责，还需协助客户厘清需求。
从 Jove 与 Oliver（Invisible Technologies 企业业务 VP）的实战经验拆解，Agent 时代的 FDE 可归纳为五项核心任务。它们恰好衔接第一篇文章中的五步框架，但每项都落地到 Agent 的具体形态。
这是首道难关。客户提出“帮我构建一个客服 Agent”，FDE 需将其拆解为：识别问题归属 → 对接相应数据与系统 → 触发匹配流程 → 模糊或高风险情形转接人工。阿里巴巴的雅迪项目便是如此实践：FDE 直接入驻客服席位旁听真实通话，发现“我买了车，充电有问题”和“我的车出故障了，怎么修”听起来相似，背后却对应完全不同的意图、知识库与服务流程。不深入一线，这类差异永远无法被捕捉。
Oliver 提出了一个极具实操价值的框架：将一条工作流拆解为十步，其中五步必须确定性执行——涉及数值计算、合规约束的，不容偏差；三到四步可由 AI 处理——允许适度弹性；还有两步需人工审核。他指出，这才是“真正借助 AI 重塑业务的正确路径”。
反之则是最常见的陷阱：盲目追求全面 AI 化，将本应确定性的环节（如账目核对）也交由 AI 处理。Oliver 强调，最大的两个陷阱，“一是数据问题，二是把本该确定性的任务也交给 AI”。对人机分工的判断力，正成为 FDE 的核心能力。
为什么 Agent 时代的 FDE 仍需深入一线？Jove 直言：核心在于信任。客户是否愿意开放数据、API 变更时是否配合、出现摩擦时是否采纳你的建议——这些通过喝咖啡、关掉 Zoom 闲谈建立的信任，AI 无法达成。“人永远只能覆盖边缘环节”，但恰恰是这个边缘，决定了 Agent 能否获取真正所需的上下文。
他还给出一个精妙的比喻：人是 AI 的延伸触手。白天与客户开会、共进午餐、喝咖啡交流，晚上将这些 AI 永远无法自主获取的信息，整理为 AI 的上下文。在真实业务场景中，大量要素并未记录在文档中——数据存储位置、口径定义、决策者的真实意图。这正是“AI 体现的是书本智慧，而中国商业场景中存在大量模型无法习得的街头智慧”——只有深入其中，上下文才能有效衔接。
Agent 上线仅仅是起点。Jove 反复强调，后续还需大量测试与打磨：确保 Agent 不会犯错、不触碰政治或敏感话题、具备刹车机制、信用卡信息需脱敏处理。为阿拉斯加航空、美联航打造的界面面向乘客，一旦失误就会引发投诉、用户流失、资金错算。雅迪的数据提供了最佳佐证：热线机器人智能解决率从 20% 多提升至 42%，文本机器人达 78%，单个案例处理时长从 3 分钟缩短至 1.5 分钟——这些成果并非上线当日达成，而是反复以真实通话为测试样本，逐轮打磨而来。
这是 Agent 时代最值得关注的趋势。Cresta 将大量部署经验沉淀为 Skill——一份详尽的 Markdown 文档、配套脚本与参考材料。完成两三个类似项目后，即可提炼为可复用的 Skill；如今 30 个 FDE 中新增了 20 个，新人甚至无需培训，“加载即可使用”。这便是滚雪球效应：每次部署都在为下次加速。他们甚至为此自主研发了 IDE 与工具链——部署本身，正演变为一项软件业务。
最后这一点需要单独阐述，因为它可能对创业者最具启示：Agent 时代的 FDE，本质上是产品工程师，而非外包人员。
Jove 坚决秉持这一观点。他认为 FDE 不应归属于 Professional Service——因为若是按人头、按时长计费的交付模式，你整天关注的都是如何排项目、算工时，产品出现缺陷你只能提交工单请求他人修复，修复完成可能已是数月之后。而真正的 FDE 是“开发软件的，只是大量时间与客户并肩”，他们直接对产品负责，将现场洞察转化为产品能力。
这也是他强调模型公司做 FDE 与 Cresta 这类应用公司做 FDE 存在本质差异的原因：模型公司销售的是 Token，逻辑是“让我的模型被更多使用”；而应用公司“销售的是成果，而非 Token”——因此它会针对特定场景，从二十多个模型中筛选最适配、最经济、最合规的那一个。方向不同，FDE 的工作模式便截然不同。
还有一个组织层面的细节值得记录：Cresta 一个项目通常配置“一个 FDPM（前线部署产品经理）搭配两到三个 FDE”。FDE 类似 Forward Deployed CTO，承担技术实现与经验回馈产品的职责；FDPM 类似 Forward Deployed CEO，负责与客户长期协作、培养信任、把控需求，乃至推动增购。这并非为了制造花哨的岗位头衔，而是避免要求个体面面俱到——“理想状态当然是全能型选手，但这类人才难以招募，精力也有限”。
落到个人实践层面，三件事需要关注：
第一，切勿急于上线 Agent，先协助客户厘清工作流。抽取 5% 的真实样本进行比对：客户管理者设想的 SOP，与一线实际执行的是否一致？若不一致，Agent 上线必败。清晰定义流程，远比优化 prompt 更为关键。
第二，培养“人机分工”的判断力。每条工作流先拆解为十步，明确哪些必须确定性执行、哪些可借助 AI、哪些需人工审核。最大陷阱有二：数据整合不足，以及将本应确定性的任务交由 AI。
第三，将每次部署视为产品迭代契机。完成一个项目后，反思：本次经验能否提炼为 Skill、沉淀至平台？若同类项目仍需同等人力与时间，那你不是 FDE，而是外包。
结语：Chatbot 时代，AI 是答疑工具；Agent 时代，AI 是执行员工。将模型能力转化为真实业务成果的，正是那些既深谙技术、又扎根一线、还能将经验回馈产品的人——他们从事的并非服务交付，而是软件创造。