AI Agent 时代的 FDE：如何把模型能力落到真实业务里

AI Agent 的讨论越来越多，但企业真正缺的通常不是又一个模型 Demo，而是能把模型能力放进真实业务流程、让一线员工愿意使用，并且在出错时知道如何接管的人。

这正是 FDE（Forward Deployed Engineer，前线部署工程师）要解决的问题。

本文整理自 JODA: Jove On Data and AI 发布的中文访谈视频《和课代表立正的中文访谈：AI Agent 时代的 FDE：把模型能力落到真实业务里》。由于视频字幕在整理时无法稳定获取，本文不是逐字稿，而是围绕公开标题和访谈主题提炼出的实践框架。文中的方法用于帮助读者理解 FDE 与企业 AI 交付，不代表视频嘉宾的逐句原话或特定企业的完整观点。

一、FDE 到底是什么？

FDE 不是“会写代码的人去客户现场”，也不是传统售前、实施或产品经理换了一个新名字。它更像连接业务现场与 AI 工程系统的一种复合角色：

客户的模糊问题
  → 业务流程和数据调研
  → 可验证的 Agent 场景
  → 系统、模型和工具集成
  → 一线用户试用
  → 反馈、修正和持续运营

FDE 的工作对象不是一个静态需求文档，而是一个仍在变化的业务现场。客户可能不知道自己真正的问题是什么，资料可能不完整，流程可能依赖老员工经验，系统可能没有 API，模型也可能无法满足准确率要求。FDE 需要在这些不确定条件下快速找到一个值得验证、可以交付的切入点。

FDE 与普通软件开发的区别

维度	普通软件开发	FDE / 企业 AI 交付
需求起点	产品或业务通常已完成拆解	客户常常只有方向和愿望
工作位置	以研发环境为主	需要进入真实业务现场
数据状态	接口和数据契约相对明确	文档、系统和口传规则可能冲突
迭代方式	按需求、排期和版本迭代	边调研、边验证、边收窄范围
验收方式	功能和技术指标	业务结果、用户采用和人工接管
成功标准	软件上线	能运行、有人用、错了能处理、持续可维护

二、企业需要的不是“万能 Agent”，而是一个具体结果

老板说“我要在公司里上 Agent”，通常不是可以直接开发的需求。它可能代表：

• 想减少客服和售后的重复查询；
• 想把老员工经验沉淀下来；
• 想降低运营人员的手工录入；
• 想让销售更快准备资料；
• 想用 AI 辅助研发、测试或数据分析；
• 想探索组织效率，但还没有明确流程。

FDE 的第一步不是选择模型，而是把愿望转换成业务问题：

1. 现在谁最痛？
2. 哪个环节重复最多？
3. 哪一步最慢、最容易错或最依赖个人经验？
4. 当前流程怎样完成，输入和输出分别是什么？
5. 如果 Agent 做好，哪一个可观察结果会改变？
6. 谁能确认它变好了？

例如：

模糊愿望：做一个企业知识库

可验证场景：
为售后团队提供产品资料问答助手，
覆盖已确认版本的文档，回答必须引用来源，
资料不足时拒答，无法确定的问题转人工。

后者才有机会被设计、开发、测试和验收。

三、FDE 的第一项能力：还原真实工作流

企业流程很少完整存在于制度文档里。它通常分散在：

• 业务系统；
• Excel 和个人表格；
• 邮件和群聊；
• 老员工的记忆；
• 历史例外处理；
• 没有正式记录的口头规则。

因此，FDE 需要和老板、业务负责人以及实际操作者分别访谈。三类人的描述往往不完全一致，而这种差异本身就是项目线索。

访谈流程问题，而不是功能清单

不要只问“你希望 AI 有什么功能”，而要问：

• 谁在什么时间收到什么输入？
• 输入来自哪个系统、文件或人？
• 处理时需要查看哪些资料？
• 哪些判断依赖经验？
• 出现例外时找谁？
• 结果写回哪里，谁继续使用？
• 哪些步骤可以自动化，哪些步骤必须人工确认？
• 出错时损失是什么，谁负责处理？

这些问题最终要画成一条端到端流程：

输入
  → 检索 / 分类 / 判断
  → 工具调用
  → 人工确认
  → 写回系统
  → 通知下游角色

Agent 应该嵌入这条链路中的一个明确节点，而不是被当成独立的聊天窗口。

四、资料正确，不代表业务答案正确

知识库和 RAG 项目最容易忽略的风险，是 AI 可能准确地读取错误资料。

例如，旧产品文档里有一处印刷错误，老员工平时会自动在脑中修正，但这条“例外”没有进入线上知识库。检索、解析和生成全部正常时，Agent 仍然可能给出错误答案。

所以 FDE 需要同时验证两件事：

验证对象	需要问的问题
技术链路	文档能否解析、检索和引用？
业务事实	文档内容是否仍然有效、完整且符合实际？

进入企业现场后，应建立知识治理清单：

• 当前有效版本是哪一份？
• 历史版本是否应该归档？
• 谁负责确认事实？
• 哪些规则只存在于个人经验？
• 资料冲突时采用什么优先级？
• 信息不足时是拒答、引用冲突，还是转人工？

AI 能自动化问答，但不能替企业自动决定哪份资料是真实的。知识治理和责任归属仍需要业务人员参与。

五、场景选择：优先做低风险、高频、可验证的环节

第一阶段不宜追求“全公司 AI 化”。一个适合 POC 的场景通常具备：

• 使用频率高；
• 输入和输出相对明确；
• 有可取得的真实数据；
• 出错影响可控；
• 有业务负责人参与；
• 几周内能够完成一次验证；
• 结果可以通过规则或人工判断。

常见的第一批场景

场景	适合的 Agent 能力	主要风险
内部资料问答	检索、引用、摘要、拒答	知识版本和权限
客服辅助	查询、草拟回复、分类	错误承诺和隐私
销售资料准备	检索、对比、生成初稿	资料过期和事实错误
运营流程助手	表单理解、规则判断、写入草稿	重复写入和边界条件
研发辅助	代码搜索、测试生成、问题归纳	代码质量和权限
告警分诊	聚合上下文、推荐处理路径	漏报、误报和升级责任

第一阶段尽量先做“辅助”，再考虑“自动执行”。让 Agent 先生成建议、草稿或候选动作，由人确认后写入，能更快获得真实反馈，也更容易控制风险。

六、模型只是系统的一部分

企业 AI 项目中，模型选择重要，但模型并不等于完整系统。一个能交付的 Agent 至少还需要：

模型
  + 业务上下文
  + 检索与知识版本
  + 工具和系统接口
  + 权限与审批
  + 日志与可观察性
  + 人工接管
  + 测试与回归

对于 GPT88 API 接入的 Agent，可以先使用 GPT88 快速开始 完成基础请求，再逐步增加工具和业务上下文。模型 ID、价格、配额和可用能力应从当前 模型导航 或 API 返回中确认，不应依赖旧截图或静态文章。

模型选型要基于真实样本

不要只比较公开榜单。应准备与目标业务相似的测试集，比较：

• 正确率；
• 引用准确性；
• 拒答质量；
• 工具调用成功率；
• 延迟；
• 超时和重试；
• 每个通过任务的实际成本；
• 人工修改和复核时间。

一个单次调用价格更低的模型，如果经常需要返工或人工纠错，最终成本可能更高。反过来，简单提取、分类和格式化任务也不一定需要最强模型。

七、Agent 的核心不是自动化，而是可接管

企业不会接受一个“答错以后不知道怎么办”的系统。FDE 要在设计阶段明确：

• 什么情况下 Agent 可以直接回答；
• 什么情况下必须引用来源；
• 什么情况下应该拒答；
• 什么情况下交给人工；
• 什么情况下禁止调用工具；
• 什么情况下需要二次审批；
• 什么情况下要记录完整审计信息。

可以把一次 Agent 操作拆成：

理解请求
  → 判断是否在范围内
  → 准备上下文
  → 提出动作
  → 权限与参数校验
  → 人工审批（如需要）
  → 执行
  → 验证结果
  → 记录并可恢复

尤其是写文件、修改业务数据、发送外部消息、部署和支付等高风险动作，不应只依赖模型判断。需要 allow-list、参数校验、预览、幂等键和人工确认。

八、测试验收不能靠“感觉不错”

企业 AI 项目必须在开发前设计测试集。至少包含三类用例：

正向用例

正常输入是否能给出正确、完整、符合格式的结果？

反向用例

资料不足、越权请求、恶意输入或不支持的问题，Agent 是否会拒答或转人工？

边界用例

文档版本冲突、工具失败、接口超时、重复提交、长上下文和模型切换时，系统是否仍然可控？

验收表可以这样设计：

测试项	预期结果	通过条件	证据
已知事实问答	返回正确答案和来源	事实与业务标准一致	请求记录、答案和引用
资料不足	明确说明无法确定	不编造	日志和人工复核
越权请求	拒绝或脱敏	不泄露受限数据	权限日志
工具失败	有限重试或转人工	不产生重复写入	工具调用记录
版本冲突	显示冲突或使用有效版本	不静默覆盖	知识版本记录

技术团队负责把系统做出来，业务专家负责定义什么叫真正答对。两者缺一不可。

九、交付之后，FDE 还要关注采用率

项目上线不等于项目成功。企业员工是否真正使用、是否愿意反馈、是否知道什么时候不该相信 Agent，同样是交付的一部分。

上线后应观察：

• 有多少目标用户实际使用；
• 哪些问题被重复询问；
• 哪些回答经常被人工改写；
• 哪些流程仍然回到旧工具；
• 哪些错误导致用户失去信任；
• 哪些功能使用成本高于带来的收益；
• 业务负责人是否能独立维护资料和规则。

Agent 的持续改进循环是：

采集真实请求
  → 分类成功与失败
  → 找到知识、Prompt、工具或权限问题
  → 修正一个变量
  → 回归测试
  → 发布并观察采用率

不要一次性修改模型、Prompt、知识库和工具，否则无法知道变化带来了什么效果。

十、FDE 项目的最短成功路径

如果你正在为企业设计第一单 AI 项目，可以按下面的顺序推进：

1. 找到一个正在产生真实成本的问题；
2. 访谈老板、业务负责人和实际使用者；
3. 画出当前流程和数据流；
4. 明确第一批用户和第一阶段范围；
5. 检查资料版本、权限和系统接口；
6. 用真实样本建立 POC 测试集；
7. 先做辅助建议，再开放自动执行；
8. 定义拒答、转人工和高风险审批边界；
9. 用正向、反向和边界测试验收；
10. 上线后持续收集反馈、成本和失败样本。

每一步都应该产出可审查结果，而不是只留下一个演示视频。

十一、验收清单

• 第一阶段对应一个具体业务结果；
• 已经访谈实际使用者，而不只听决策人描述；
• 输入、输出、系统和责任人明确；
• 资料版本和知识真实性有人负责；
• 模型选择基于真实样本，而非只看榜单；
• 目标场景有正向、反向和边界测试；
• 资料不足时会拒答或转人工；
• 工具调用具备参数、权限和幂等校验；
• 高风险写操作需要人工确认；
• 上线后能看到使用量、错误、成本和人工修改；
• 需求变更会同步影响预算、周期或范围；
• 项目结束后沉淀模板、测试集和失败案例。

总结：FDE 是把 AI 变成业务系统的人

AI Agent 时代的 FDE，不是单纯把模型部署到客户服务器，也不是把一个聊天机器人交给企业就结束。它需要把模糊愿望变成可验证场景，把真实流程转成上下文、工具和权限，把模型输出放进测试与人工接管体系，再通过持续运营让系统真正被使用。

企业最终关心的是：

它能不能解决真实问题？
错了谁来处理？
做到哪里算完成？
上线以后谁能维护？

模型决定能力上限，FDE 决定能力能否进入真实业务。对于 GPT88 用户和 Agent 开发团队，最值得借鉴的不是某个固定模型或工具，而是这套从现场调研、场景收窄、POC、测试验收，到上线运营的完整闭环。

本文整理自 JODA: Jove On Data and AI 的公开视频《和课代表立正的中文访谈：AI Agent 时代的 FDE：把模型能力落到真实业务里》。由于整理时未取得可核验的完整字幕，本文为基于公开主题的结构化方法总结，不是逐字稿；具体嘉宾观点、案例和原视频表达请以视频原内容为准。