FDE能否在日本扎根——真正的考验在AI概念验证之后

客户服务部门针对有限范围的咨询试用AI智能体。演示很顺利。智能体检索信息、拟定回复，并建议下一步应采取的措施。管理层批准扩大应用范围。

然而，一旦接入实际业务，问题就出现了。

客户记录中存在相互矛盾的信息。有些咨询需要特殊处理，而资深员工一直凭经验应对。智能体可以建议退款，但还没有人决定是否应赋予它实际执行退款的权限。回答出错时，业务部门和IT部门又对应该由谁负责调查产生分歧。

模型的能力足以支撑演示，但仅凭这一点，还不足以投入生产环境。

被寄予厚望、用来弥合这一差距的角色，就是Forward Deployed Engineer，简称FDE。这个角色将亲自承担技术实现的工程工作与直接参与客户业务相结合，从问题定义到系统上线后的改进，全程参与。

在日本，关键问题是企业能否向这类工程师提供推进工作所需的信息、接触业务现场的机会，以及相应权限。仅仅设立一个新头衔，并不能让AI项目进入正式运行阶段。

FDE为何受到关注#

所提供的ZDNET Japan文章报道，Salesforce Japan正携手9家合作伙伴，在日本推广Forward Deployed Engineering Partner Network。这项举措旨在帮助客户从Agentforce的试点部署转向正式运行。

根据文章引用的Salesforce说明，在海外，已有三分之一的Agentforce成功部署案例由参与这项计划的合作伙伴负责。这是供应商公布的数据。所提供的资料没有说明Salesforce如何定义成功，以及将哪些部署案例纳入统计，因此不应将其视为证明业务成效的独立证据。

尽管如此，其商业方向十分明确。AI供应商需要客户在日常工作中使用产品。即使演示成功，如果系统没有融入业务流程，也无法形成持续需求。

文章中，埃森哲高管田村广亮介绍了从执行客户需求的工程师，转向致力于实现客户成果的合作伙伴这一转变。两者的区别在于如何界定工作完成：是完成分配的任务，还是创造可衡量的业务成效。

这是一个有益的目标，但也需要谨慎理解。工程师无法保证那些受人员配置、客户企业政策和管理层行为影响的成果。FDE能够承担的责任，是识别并明确呈现这些依赖关系，而不是交付软件后，就把后续问题留给客户自行解决。

这是一个有用的角色，但并非全新的职业#

FDE有时被介绍为AI时代诞生的新职业。然而，其基础工作并没有那么新。

深入客户组织的工程师、实施顾问和技术专家早已存在。优秀的从业者一直在研究业务、重新审视需求、构建系统集成，并帮助系统融入日常工作。

AI智能体改变的是需要承担的职责组合。智能体可能会解读含糊的请求、选择工具并发起操作。必须在各种情境下评估它的行为，包括它应当停止处理、向人求助的场景。

因此，相关工作远不止软件配置。

理解员工如何作出判断，包括如何处理例外情况。
设置适当权限后，将智能体连接到数据和系统。
根据真实案例和可能导致失败的条件，评估智能体的行为。
监控生产环境中的使用情况，并随情况变化调整工作流。

最能说明FDE必要性的一点，是持续参与这些活动能够带来价值。理解某个例外为何存在的人，应当继续参与实现和测试。

而最流于形式的做法，则只是给人员派驻机制换了个名字。工程师接收工单，在客户现场工作，却无权重新审视业务流程。这或许仍然有助于开发和实施，但无法实现人们对FDE所期待的更广泛价值。

在日本的普及程度，取决于能多深入地参与组织内部工作#

在所提供的文章中，埃森哲指出，企业在实施能力、响应速度和技术选择的灵活性方面存在不足。这些被列为日本企业难以将AI实验转化为业务成果的原因。

这一判断具有说服力，但并不能证明所有日本企业都面临同样的问题。考虑引入FDE的企业，应先审视自身停滞的项目，再决定是否将这一新角色作为解决方案。

当技术决策和业务决策反复相互阻碍时，FDE就比较适合。例如，业务负责人尚未就由谁处理不确定情况达成一致，导致工程师无法设计升级处理路径；与此同时，由于还没有人验证这类情况的发生频率，业务负责人也无法确定处理政策。

深入组织的工程师，可以通过小规模、结果可验证的部署，帮助打破这一循环。不过，相比身处同一地点，能够接触必要的业务现场和信息更为重要。

工程师需要获得观察实际工作、与用户交流、查看相关数据并提出修改建议的权限。如果客户只提供需求文档和每月一次的进度会议，就很难获得预期成效。

企业内部也需要有负责人。不能让供应商的工程师成为唯一理解业务流程运作方式的人。客户一方需要有人负责业务政策，也需要有人能够维护技术系统。对于小规模部署，这些职责可以由一个小团队承担。

衡量业务改善，而不是部署数量#

“对成果作出承诺”是一种很有说服力的表述。但当合同需要明确“什么才算成果”时，其含义就会受到检验。

以辅助处理客户咨询的AI智能体为例。统计部署数量、生成回复的数量和员工登录次数，可以看出系统是否有人使用，却无法判断服务是否得到改善。

更合适的评估方式，是使用以下四项指标，对比部署前后的实际表现。

| 指标 | 能够了解什么 | |---|---| | 处理时间 | 工作流是否减少了工作负担 | | 问题解决质量 | 回复是否准确，是否涵盖必要内容 | | 升级处理与返工 | 自动化是否只是将工作转移到了其他环节 | | 每解决一项咨询的成本 | 将运行成本计入后，是否仍然有效益 |

各方需要事先就这些指标的定义达成一致。如果处理速度提高了，但员工之后需要花费额外时间纠正错误，就不能称之为改善。

开发前，应使用具有代表性的样本记录基线。同时，就改善目标和不可接受的失败条件达成一致。对于能够修改客户记录的智能体，即使平均表现良好，一旦出现越权操作，也可能需要立即停止运行。

与客户共同设计这套评估，也是FDE价值的一部分。一个团队如果无法解释如何衡量结果，就还没有资格声称自己能够对结果负责。

供应商锁定会在日常决策中不断加深#

所提供的摘录将供应商锁定列为一项担忧，但详细讨论位于未包含在资料中的页面。因此，以下风险是对这一实施模式的分析，并非对缺失内容的复述。

供应商及其合作伙伴的深入参与，可以加快部署。另一方面，也可能让该供应商的平台成为解决所有问题的默认答案。

依赖会通过日常选择逐步累积。例如，工作流规则存放在哪里、如何连接工具、使用哪些监控功能，以及客户能否导出评估数据。

但这本身并不构成放弃采用FDE的理由。任何平台都存在一定的切换成本。实际需要考虑的是，能否理解并接受这些成本。

采购方应要求交付以下四项成果。

1. 客户可以查阅的工作流和系统集成文档。 2. 基于真实业务案例、可重复使用的评估集。 3. 明确数据、配置和定制代码的权利归属及导出条件的条款。 4. 记录平台特有依赖关系及替代方案的文档。

一种有效的验收方式，是让内部团队利用交付资料修改一条工作流规则，并诊断一个人为设置的故障。如果离开外部工程师，两项任务都无法完成，就说明交接尚未结束。

从范围有限的生产项目开始#

FDE支持应从一项范围足够小、便于评估，同时又足够重要、值得投入的业务开始。应避免一开始就追求能够跨整个部门运行的智能体。

假设支持周期为90天，可以分为四个阶段。以下时间安排只是一个规划示例，并非行业标准。

第1至15天：观察业务，定义目标成果。 与员工一起审查真实案例。识别例外情况、所需数据，以及需要人工批准的操作。记录基线，指定内部业务负责人。

第16至40天：构建并评估。 实现最小且实用的工作流。除常规案例外，还要测试信息缺失、记录矛盾，以及超出智能体权限的请求。在查看结果之前，先就投入生产环境的判断标准达成一致。

第41至70天：限定范围投入生产环境。 使用适合该业务的生产环境权限。确保有升级处理路径和停止智能体运行的手段。在扩大部署范围前，以足以识别反复出现的问题的频率检查错误。

第71至90天：评估并移交责任。 将结果与基线比较，同时计入返工和运行成本。完善文档，完成维护操作演练。决定扩大、调整还是终止部署。

最终决定不应预先设定。即使获得的可靠证据表明不宜扩大部署，这项支持仍然能够帮助客户避免更大规模的投资失败。