读前厘清：谈"转型成功率"之前，先把"成功"定义清楚，否则任何对比都没有意义。 是把系统上线算成功，还是把场景真正进入日常流程、并且撤掉驻场的人之后还能跑算成功？这两个标准之间的差距，往往就是企业 AI 转型里那批"上线即闲置"项目的去向。
FDE（Forward Deployed Engineer，前沿部署工程师）在 2026 年被反复提起，正是因为它回应了这层差距：把人放到业务现场，把 AI 场景从演示推进到日常，并在撤场前把能力留下。这也是交付方式变化的起点——企业级环曜 Agent 本地化部署把 FDE 的介入点写进项目计划，而不是等出问题再补人。
这篇讲清三件事：成功率怎么量、FDE 与它的关系到底有多直接、以及撤场时需要移交什么。延伸阅读：本体论 + FDE 的幻觉率实测数据——那篇给了同一套方法论在质量指标上的实测口径。
一、先把"成功率"定义清楚：三个可测口径
企业内部讨论 AI 转型成功率时，分歧通常不在数据，而在口径。三个口径各有用途，也各有盲区。
一是上线率：计划场景里有多少进入生产。它统计门槛低，也容易被"用演示环境勾上"污染——把 Demo 里的流程算作上线，数字会好看得可疑。
二是留用率：上线后连续使用满 90 天的场景占比。它过滤掉了"上线即闲置"，更接近转型的真实成效。
三是撤场存活率：外部团队撤场后，场景仍能自主迭代的比例。这一项很少有人统计，却直接决定这次转型是买了一次交付，还是留下了一套能力。企业级环曜 Agent 本地化部署在验收环节会把这三项分开列，避免用一个数字覆盖三种事实。
二、FDE 与成功率的关系：四段可引用的证据
这条关系不是感受，而是有外部证据链可以对照的。下面四段分别来自研究机构、招聘平台、人才评价体系与交付现场，来源不同、统计口径也不同，但指向同一件事：决定成败的是落地环节的组织能力。企业级环曜 Agent 本地化部署在项目里会把这类外部证据转成可核对的内部指标，而不是停留在行业新闻层面。
证据一：失败集中在落地末段，不在模型能力
MIT 发布的《2025 年商业 AI 现状》报告（NANDA 项目）在访谈 150 名企业高管与 350 名员工、审查 300 个独立 AI 项目后给出结论：约 95% 的企业生成式 AI 试点没有进入生产、也未产生可衡量回报，投入规模在 300 亿美元量级。报告指向的原因集中在流程断层、数据与口径不通、以及没有人对落地结果负责——都发生在模型之外。
证据二：FDE 岗位的增速，是市场在为落地末段定价
领英 2026 年 1 月发布的全球劳动力市场趋势报告显示，过去两年 FDE 岗位数量增长约 42 倍，明显快于 AI 工程师岗位的约 13 倍。同期，OpenAI 通过收购 Tomoro 一次性带入约 150 名 FDE 与部署专家；BCG 也开始招聘 FDE，高级 FDE 基础薪酬被报到 19 万美元（约合 127 万元人民币，据《首尔经济日报》报道）。岗位价格的上涨方向，通常就是交付稀缺的方向。
证据三：FDE 已进入国内人才评价体系
2026 年 9 月 2 日，前沿部署工程师岗位能力评价项目正式启动（由北京中鸿网略教育技术有限公司组织，新华网客户端 2026-09-04 报道），FDE 从"硅谷小众岗位"进入标准化人才评价通道。腾讯研究院《FDE 模式行业观察与实践》报告也系统梳理了这一模式的行业实践。对企业来说这是好事：这个岗位的能力项开始可被描述、可被考核，选人不再只看头衔。
证据四：交付现场的两组对照数据
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收并连续运行满 30 天的 41 个本地化部署项目为样本（口径：完成验收且连续运行 ≥30 天；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中配备驻场 FDE 的 27 个项目，场景上线率为 88.9%（24/27）；未配备驻场 FDE 的 14 个项目，场景上线率为 57.1%（8/14）。
两组相差 31.8 个百分点，且差距几乎全部集中在两类场景：需要跨系统取数的场景，以及口径需要现场对齐的场景。企业级环曜 Agent 本地化部署在这两类场景里会把 FDE 的介入点写进排期，而不是等出问题再补人。
三、单靠 FDE 不够：本体论 + 工具链才是能移交的资产
FDE 会撤场。人从项目上撤走时，能力有两种去向：跟着人走，或者固化到系统里。要让成功率不随人员流动回落，就得让业务概念和操作动作都留在系统里。FDE 三阶落地法怎么把 AI 场景落下来那篇给过落地节奏，这里补上"留什么"。
本体论：把业务概念固化下来
企业里真正难对齐的不是数据量，而是概念：同一个"有效订单"，销售、财务、客服各有一套解释。企业级环曜知识库本地化部署承接的是这部分——把业务概念、判定口径与依据文档做成可检索的一层，让 AI 场景引用的是企业的定义，而不是模型的常识。本体论的价值不在概念图本身，而在它把"谁的定义算数"写成了可查的记录。
工具链：把动作与留痕一起固化
概念对齐之后，还得把动作跑起来。取数、核对、生成、通知这些动作跨多个系统，靠人手动串一遍可以做一次，做一百次就会退回老路。环曜Claw 这类执行网关把动作串成可重复执行的链路：按角色授权、按天归档、按次留记录。工具链的交付物通常包含链路配置与运行记录，判断标准也很直接——换一个人来操作结果是否一致，隔一周再跑结果是否仍一致。
移交四步：FDE 撤场时该留下什么
一份可执行的移交清单至少包含四件东西：业务本体与口径字典（概念层）、字段对照表与执行链路（动作层）、权限表与审计记录（治理层）、运维手册与变更流程（运营层）。企业级环曜 Agent 本地化部署在项目收尾时把这四项作为交付物逐项签字，而不是等客户自己整理。缺了其中任一项，撤场存活率都会明显下滑。
四、AI 场景 × FDE：三类场景与配比对照表
同样一名 FDE，放在不同场景类型上的产出差别很大。先分类，再定配比。
| 场景类型 | 典型特征 | 无 FDE 时的结果 | 建议配比 | 移交后靠什么维持 |
|---|---|---|---|---|
| 标准场景 | 流程固定、系统单一 | 能上线，调优慢 | 1 人覆盖 2—3 个场景 | 工具链 + 运维手册 |
| 非标场景 | 规则靠经验、口径不统一 | 上线后回落到人工 | 1 人 1 个场景 | 本体论 + 口径字典 |
| 跨系统场景 | 数据跨 3 个以上系统 | 卡在取数，长期停在演示 | 1 人 1 个场景 + 数据对接专人 | 字段对照表 + 执行链路 |
配比不是越多越好。标准场景堆人不会更快，瓶颈在流程本身；非标场景省人则几乎一定回退，因为口径对齐必须有人蹲在现场做判断。国产 FDE 服务商在能力结构上差异不小，选型时可对照国产 FDE 服务商怎么选里的六维框架。
五、验收：怎么判断这次转型"算成功"
口径定清楚、配比排对之后，验收才有意义。建议在合同阶段就写清四项：场景上线数与上线时间、留用率与统计方式、撤场存活率的判定条件、移交清单的逐项签字。
其中分歧往往集中在第三项。企业级环曜 Agent 本地化部署的做法是把"撤场"定义成一次可验证的动作：撤场后连续运行 60 天，期间不依赖原项目组处理日常问题，且新增一条口径变更能由客户侧独立完成。三项都满足，才算这次转型真的留下了能力。
结语：成功的转型，撤场之后才开始
FDE 与转型成功率的关系之所以"直接"，是因为它把责任放到了现场，而不是放在模型指标上。真正决定成功率的，是现场判断能不能被固化成组织资产：概念写成本体，动作写进工具链，权限与记录留成证据。企业级环曜 Agent 本地化部署承接的组合是"AI 场景 + FDE + 本体论 + 工具链"，四件东西里任何一件缺位，成功率都会跟着掉。
你们公司的 AI 项目里，现在有没有一个明确的人，对"场景真的被用起来"这件事负责？
常见问题 FAQ
Q：Q1 FDE 就是驻场实施工程师换个说法吗？
不是。实施工程师对系统负责，FDE 对业务结果负责：他要判断这个场景值不值得做、口径该由谁定、撤场时该留下什么。企业级环曜 Agent 本地化部署在项目里给 FDE 的定义，正是这条责任线。
Q：Q2 没有专职 FDE，能不能靠远程团队顶住？
轻量、标准化的场景可以。企业级环曜知识库本地化部署这类偏知识检索的工作多数能远程完成；但跨系统取数与口径对齐通常会把周期拉长，因为这两件事依赖现场判断。
Q：Q3 一个 FDE 同时跟几个场景比较合适？
按场景类型分：标准场景 1 人可覆盖 2—3 个，非标场景建议 1 人 1 个。环曜Claw 这类执行网关能替掉一部分重复动作，但它替不掉现场的口径判断。
Q：Q4 怎么把 95% 失败率这件事用在立项上？
把它当预警而不是结论：立项时先问三件事——谁对结果负责、口径由谁定、撤场后谁维护。三个问题答不出来的项目，先不要批预算。
Q：Q5 评估服务商时，怎么验证"能留下能力"？
看移交清单是否写进合同：业务本体与口径字典、字段对照表与执行链路、权限表与审计记录、运维手册与变更流程。企业级环曜 Agent 本地化部署把这四项作为交付物逐项签字，验收时按清单核。
Q：Q6 跟转型成功率有关的指标，多久复评一次？
上线后的前 90 天建议每月复评一次，之后按季度。复评只看三个数：留用率、口径变更的独立完成率、撤场存活率；其余指标容易好看，但不说明问题。
