FDE 模式
全球实践研究报告

下列七条结论贯穿全文。若时间有限，读完本节与第二章（银行与金融业案例）、4.6 节（采购与退出机制）即可覆盖决策所需的主要信息。

1. 矛盾已经转移。AI 落地的核心矛盾正在从"模型能不能做"转向"组织怎么用"。模型能力以季度为单位跃升，但超过六成的企业 AI 尝试仍停留在试点阶段。瓶颈不在 Demo，而在接系统、嵌流程、过合规、跑指标。
2. FDE 是交付范式的重组，不是新岗位。它把售前、实施、产品与客户成功的能力重新组合进一个前线小队，让交付与学习同时发生。驱动力是 AI 同时压低了行业知识蒸馏、定制开发与复合型人才供给三道成本门槛。
3. 唯一的分界线是"沉淀"。只留给客户一个系统，是外包；带回经验却无法复用，是项目制；把现场经验转化为 Skill、模板、测试集或产品能力，才是 FDE；沉淀后能显著降低下一次同类交付成本，才是可规模化的 FDE。
4. 2026 年上半年是分水岭。OpenAI 与 Anthropic 在同一周各自成立独立的部署公司（DeployCo 与 Ode），Salesforce 提出千人 FDE 编制并建立伙伴网络，Google Cloud 大规模扩招。模型厂商用真金白银承认：模型再强，不会自己走进客户现场。
5. 金融业是 FDE 最合适、也最危险的战场。高关键性、高客户集中度、强监管与强数据引力——四项条件全部命中，这正是重交付模式成立的象限。但同一批特征也意味着一次错误的代价极高，且极易形成供应商依赖。Gartner 预测到 2028 年，将有七成企业因供应商成本高企与内部无力独立演进，而放弃由 FDE 主导的智能体方案。
6. AI 让工程执行变便宜，让判断能力更稀缺。识别高价值场景、理解行业、推动组织采纳的能力反而更值钱。前线角色正在从"写代码的人"演变为"指挥 AI 完成业务的人"。
7. 对甲方而言，真正要买的不是人天，是能力转移。合同里必须写清知识转移里程碑、资产交付清单与退出标准。判据只有一条：供应商团队撤出后，本机构能否独立运行、监控、质询并安全修改这套工作流。

1.1　能力与采用之间的剪刀差

过去两年，企业对 AI 的关注已经不再停留在模型参数、榜单成绩和演示效果，而是转向一个更现实的问题：如何把大模型能力接入真实系统、嵌入业务流程、满足合规要求，并最终形成可衡量的业务结果。

多家机构的统计指向同一组数字：超过七成的企业已在至少一个职能中尝试生成式 AI，但超过六成仍停留在试点或实验阶段。问题不在模型能力——真正卡住的是最后 20% 的生产化工程。而模型能力仍在快速迭代，每一次升级都在拉大"技术能做到"与"组织用起来"之间的距离。

80／95／99 规律

企业级 AI 落地存在一条经验规律：覆盖 80% 用例的 Agent 可能很快搭出来，达到 95% 已经很难，达到 99% 往往需要专职团队、专用平台和上万级真实业务数据。这解释了为什么很多客户在 Demo 阶段兴奋、在生产阶段失望。

为什么上限是 99% 而不是 100%？大语言模型本质是概率系统，输出空间开放，永远存在不可预见的边缘案例；从 99% 推向 99.9% 的边际成本指数级增长，边际收益递减。在高风险场景中，那 1% 不应交给 AI 覆盖，而应通过人工审核与回滚机制兜底。99% 不是技术妥协，而是工程经济学的最优解：AI 覆盖可规模化的 99%，人工守住不可自动化的 1%。

这条规律对银行尤其重要。客服回答错一次可能只是品牌事故；但反洗钱、授信、合规审查场景中的一次错误，可能直接触发监管风险。系统接入越多，权限、审计、回滚和人工接管的复杂度越高。AI 测试也不同于传统软件测试——传统测试强调确定性输入与确定性输出，AI 测试要面对概率系统和长尾分布，常常出现"改好 A 又坏 B"的情况。

1.2　FDE 的三层定义

FDE（Forward Deployed Engineer，前线部署工程师）这个名字容易造成误导。"前线"容易被理解为人要长期驻在客户现场，"部署"容易被理解为把系统装上、接好、调通。两个词叠在一起，很自然会被套回过去十几年软件项目的旧框架。

更准确的理解需要分三层。

表层：一个复合型的前线角色

深入客户业务现场，把技术能力转化为可运行的业务结果。关键不是物理位置，而是进入客户真实业务问题的一线；关键也不是安装系统，而是把模型、数据、流程、权限、组织责任和业务指标部署成可持续运行的结果。

中层：三种能力的组织化分工

FDE 模式之所以难，是因为它把过去分散在多个岗位上的能力压缩到一个小团队里。Palantir 内部用两个北约音标字母来命名这两类能力，行业已普遍沿用。

Echo 承担的是前线学习的输入侧——把现场的行业知识和业务规则带回组织。不能只听客户说要什么，还要判断客户说的是否是问题本身。很多时候，客户要求的是一个功能，但真正需要的是重构某个流程；客户想买的是一个工具，但真正缺的是一套用起来的组织机制。

Delta 承担的是执行侧——把抽象出来的问题转化为可运行、可验证的系统。AI 编程降低了 Delta 的技术门槛，但没有消除对工程判断的要求：粗糙原型可以，但不能没有质量底线；快速迭代可以，但不能忽视安全、权限和审计。

里层：双向蒸馏与本体层

FDE 的本质可以概括为双向蒸馏。

承载两层蒸馏的共同载体，是本体层（Ontology）。本体的理论并不复杂——实体、关系、属性，本质上就是结构化的业务知识图谱。但它解决的问题非常具体：客户系统里同一个业务对象可能有不同字段名、不同编码、不同流程表达。AI 如果直接面对这些混乱系统，很难稳定理解业务含义。

以金融场景为例，不同机构的系统字段可能完全不同，但背后总有稳定概念：账户、客户、交易、授信、审批、风险事件。客户系统里可能叫"客户编号""用户 ID""主体编码"，本体层需要知道它们在业务语义上对应同一类对象；业务人员说"审核不过要退回修改"，本体层需要知道这背后涉及哪些角色、哪些状态、哪些权限和哪些通知动作。

没有这层语义抽象，AI 只能停留在问答和摘要；有了这层语义抽象，AI 才有可能进入流程执行。

与相邻模式的分界线

1.3　2026 年上半年：模型厂商亲自下场

如果说 2025 年 FDE 还只是一个在创投圈流行的概念，2026 年上半年发生的一系列事件让它变成了资本层面的产业结构调整。

• 2025.09 前 Palantir 高管、前 OpenAI 首席研究官 Bob McGrew 在 YC 播客中系统阐述 FDE 方法论，提出"你的第二用户是 FDE""痛苦就是信号"等原则，并给出核心度量：产品杠杆应随时间增加，单位价值对应的现场投入应下降。
• 2026.01.16 a16z 合伙人 Marc Andrusko 发表《The Palantirization of Everything》，对盲目复制 FDE 模式提出系统性质疑，提出"脚手架而非房子"的约束框架与四维决策矩阵。这是行业内第一份有分量的反面意见。
• 2026.03 Salesforce 公开承诺组建 1,000 人规模的 FDE 团队推动 Agentforce 落地，配套六周入职训练营（Ready in Six）；4 月进一步推出 FDE 伙伴网络，Accenture、Deloitte、PwC、IBM Consulting、Capgemini、KPMG、TCS 等 30 余家机构获得内部 FDE 培训与产品路线图访问权。
• 2026.05.04 Anthropic 与 Blackstone、Hellman & Friedman、Goldman Sachs 宣布成立独立的企业 AI 服务公司，General Atlantic、Leonard Green、Apollo、GIC、Sequoia 组成投资财团。同日，FIS 宣布与 Anthropic 合作推出金融犯罪 AI Agent，Anthropic 的 Applied AI 团队与 FDE 嵌入 FIS 共同设计。
• 2026.05.05 Anthropic 发布 10 个金融服务 Agent 模板，同时扩展 Microsoft 365 集成与 13 家以上数据连接器。这是把 FDE 现场经验产品化的公开样本。
• 2026.05.11 OpenAI 宣布成立 OpenAI Deployment Company（DeployCo），初始资本超 40 亿美元，由 TPG 领投，Advent、Bain Capital、Brookfield 联合领投，共 19 家投资与咨询伙伴；同时收购应用 AI 咨询公司 Tomoro，带来约 150 名有经验的 FDE 与部署专家。
• 2026.07.15 Anthropic 侧的合资公司以 Ode with Anthropic 之名正式发布，估值 15 亿美元，以收购的 Fractional AI 为运营内核，约 100 名工程师，由 Fractional AI 联合创始人 Chris Taylor 任 CEO、Eddie Siegel 任首席技术官。
• 2026.08.03 Palantir 公布 2026 年第二季度财报：营收同比增长 93% 至 19.35 亿美元，美国商业业务同比增长 149%，净收入留存率升至 157%，全年指引上调至 81.5 亿美元以上。FDE 模式的商业可行性在公开市场获得又一轮验证。

1.4　市场规模、人才价格与工作实况

招聘规模

薪酬结构

头部样本方面，字节跳动（火山引擎）豆包大模型 FDE 月薪 3.5 万—7 万元（15 薪，年薪最高约 105 万元），蚂蚁集团 FDE 解决方案工程专家月薪 3 万—6 万元，智谱 FDE 负责人月薪 6 万—8 万元，阿里云智能前沿部署工程师 20—50K×16 薪。腾讯在招聘平台上把该岗位定义为"客户现场的技术 CTO + 全栈 AI 工程师 + 业务咨询顾问"三位一体。

工作实况：FDE 每天到底在干什么

根据对约 1,200—1,500 名 FDE 的行业调查，时间分配与传统软件工程师有显著差异：

• 47% 用于客户对接——发现访谈、现场部署、设计评审
• 31% 用于编写或审查代码
• 22% 用于内部协调与研究综合
• 71% 的 FDE 每月至少出差一次；约 52% 的职位描述中出现"willingness to travel"
• 64% 的主要工作模式是"将现有产品部署到新客户环境并进行大量定制"——而非从零构建全新产品

技能要求也在演变：从 2023—2024 年以 Python、云平台、系统集成为核心的通用软件工程能力，转向以 RAG 架构、Agent 编排、LLM 评估框架为核心的 AI 原生能力。招聘经理将"候选人能够独立主导发现访谈"列为第二大招聘信号——排在技术栈熟练度之前。

1.5　三条组织路径

三条路径并非互斥。较稳妥的节奏是"0 到 1 原厂、1 到 N 伙伴"：原厂 FDE 承担标杆项目、平台验证和经验积累；伙伴调用标准工具和行业模板做规模化交付；客户逐步获得自助构建和持续运营能力。

独立实体型的最大结构性风险在于反馈链断裂。Anthropic 在其合资公司的公开表述中特意强调，该公司的工程师将与 Anthropic 的研究和产品团队紧密协作，以确保交付的实现方案能够随底层模型的演进而演进——这正是对该风险的针对性设计。对采购方而言，这也是一个可以直接提问的问题：你们的现场发现，多久能变成产品能力？

1.6　单位经济学：曲线必须往下弯

FDE 模式成立的根本逻辑，在于延迟收益与规模效应的叠加。

延迟收益意味着，沉淀资产的投入不会在当期项目中回收。第一个项目甚至前几个项目，成本会比纯项目制交付更高——因为除了交付客户系统，还要额外完成知识抽象、结构化和验证。规模效应意味着，如果这个垂直领域有足够多的同类客户，资产的价值会被大规模释放。经验数据显示，一个典型垂直领域里，做完七到八个客户后，本体基本趋向稳定，后续更新幅度显著减小。

两者看似都在客户现场工作，组织逻辑完全不同：前者只关心这一单能不能验收，后者还要关心这一单能不能让下一单更便宜。

Palantir 作为数据锚点

Palantir 之所以长期被视为 FDE 模式原型，不只是因为它派工程师进入客户现场，更因为它把交付过程变成了学习行业、沉淀资产的过程。约 82% 的毛利率意味着这套模式在财务上已经接近纯软件公司，而非人力服务公司。

其 AIP Bootcamp 模式提供了另一个可量化的参照：五天驻场集中交付，FDE 带着工具进入客户现场，使用客户真实数据快速搭建可运行原型。公开数据显示客户转化率约 70%—75%，获客成本反而下降 40%—60%，并把原本 12—18 个月的销售周期压缩到数周。Bootcamp 的关键不是"压缩时间"，而是改变客户决策逻辑：从听方案、看案例，转为在自己的数据和流程上看到可运行结果。

金融业在 a16z 提出的四维决策矩阵上全部命中"适合重 FDE"象限：问题关键性高（关乎合规安全与大额收益）、客户集中度高（少数超大机构、高年合同价值）、领域碎片化低（同业共享相似工作流）、监管与数据引力强。这解释了为什么 2026 年上半年最实质的 FDE 案例集中出现在金融领域。

跨行业观察的价值不在于罗列，而在于确认 FDE 模式的适用边界。以下案例按"离金融业的可迁移程度"排序，每条附上对银行的迁移判断。

3.1　政务与国防：FDE 的起源地

Palantir 的 Gotham 平台服务军方、情报机构与执法部门，最早的 FDE 团队正是在此诞生。FDE 需获得安全许可、进入客户高度保密环境，完成目标追踪、关系分析与态势感知。项目范围可以从反洗钱一路跨到救灾。

这一场景的特殊性在于：客户因安全许可要求天然具有极高迁移成本，这在纯商业场景中并不存在。Palantir 的录用率约 0.3%，这种人才密度也难以批量复制。

对银行的迁移判断：高——合规与审计要求、气隙／私有化部署、权限分级、决策可追溯等工程约束几乎完全同构。国防条线沉淀的部署方法论，比一般商业 SaaS 更接近银行的实际需要。

3.2　企业应用迁移：SAP × Palantir

2026 年 Sapphire 大会的头部用例是 ERP 迁移加速。做法不是直接进行 ECC 到 S/4HANA 的表结构转换，而是先由 AIP 将 ECC 数据抽取进 Foundry，构建语义模型，通过 Foundry 管道施加转换逻辑，生成经过校验、可直接上载的 S/4 数据集，无需双景观并行。

此外，Palantir 的 Apollo 负责在多云、本地、私有网络与完全气隙环境中持续交付与管理平台，处理更新、灰度与回滚，客户侧无需专职 DevOps 团队。

对银行的迁移判断：高——"先建语义模型、再做转换、最后校验"的顺序，同样适用于核心系统升级、数据中台重构与监管报送改造。96% → 99.8% 的两周爬坡曲线，也是一个可以写进项目计划的现实预期。

3.3　制造与能源：Tesla 的现场 FDE

Tesla 的 FDE 岗位工作地为 Austin，出差率约 50%，职责是在 Gigafactory、Megapack 与 Solar 现场快速部署基础设施操作系统，用预测分析与 AI 优化排程与产能。技术栈为 Python／SQL／R、Tableau／Power BI、Kafka／AWS Kinesis、Docker／K8s 及 IoT 与嵌入式。

对银行的迁移判断：低——物理产线的时序约束与设备语义与金融业差异过大。但其"把软件与数据能力部署到物理现场"的组织形态，对银行的网点运营与现金管理类场景仍有参考价值。

3.4　零售、消费与游戏：速度型交付

Tomoro 的客户组合展示了另一类 FDE 工作模式：面向消费级流量的高速交付。最具代表性的是为 Supercell 上线服务 1.1 亿用户的游戏内支持 Agent，用时 12 周；其余客户包括 Tesco、Virgin Atlantic、Red Bull、Mattel、NBA。

对银行的迁移判断：中低——12 周上线的速度在监管环境下不可直接复制。但其"高容错场景先行"的选择逻辑值得借用：先在容错空间大的场景建立组织信心与工程肌肉，再进入低容错的核心业务。

3.5　供应链软件：一个带批评的变体

供应链软件商 Kinaxis 同样采用 FDE 模式，但其管理层（含一位前 Palantir 高管）公开表示，做得更好的关键在于深厚的领域专长，并批评 Palantir 的执行问题在于工程师缺乏领域知识。这一批评本身值得银行采购方记住：FDE 的价值来自领域理解与工程能力的乘积，任一项为零则整体为零。

3.6　教育、传媒与文旅：高容错行业的轻量形态

腾讯云在教育行业探索的"工作营"模式提供了另一种路径：不把工作营理解为集中培训或产品宣讲，而是围绕教师的日常任务设计闭环——从真实教学任务出发，帮助教师选择场景、拆解流程、用 AI 工具形成初版应用，再通过课堂、教研、作业等实践验证效果。传统培训交付知识，工作营交付的是可运行应用、可复用 Skill 和新的使用习惯。陪跑过程中识别出的高频需求，进一步沉淀为教育专属 Skill，最终孵化出面向教育行业的产品。

传媒行业的实践则验证了 Echo + Delta 两人组合的效率：Echo 讲行业案例与客户标杆成果，Delta 现场用平台工具快速搭出原型。这种精干组合在项目竞标中表现出响应更快、成本更低、客户感知更强的优势。

对银行的迁移判断：中高——"工作营"形态几乎可以直接移植为银行的业务条线 AI 陪跑。相比一次性培训，它解决的是"培训完就没人用"这一最常见的失败模式。

3.7　适用性判断矩阵

如果一个场景处于低关键性、客户碎片化、简单集成的象限，更适合产品驱动增长模式而非重 FDE。真正适合 FDE 的，是业务问题尚未被清晰定义、需要共同探索、且探索结果有机会沉淀为可复用资产的场景。

本章是全文操作性最强的部分。4.1 至 4.4 节适用于交付方与甲方共用；4.5 至 4.7 节主要面向银行侧的项目负责人、采购与风险管理部门。

4.1　成熟度模型：L0 到 L4

很多 AI 项目的死法不是"做不出来"，而是停留在 Demo 阶段无法进入生产。以下框架用于评估当前处于哪个阶段、下一步该做什么、以及什么条件下才算通过。

专业性的体现，是能在 L0 阶段就识别出这三个卡点并设计应对方案，而不是等问题出现后再救火。

4.2　组织阵型

没有"全能超人"，只有根据任务紧急程度和资源属性匹配的阵型。

组织归属决定 FDE 最终变成什么

4.3　四层资产模型

对多数组织来说，直接建设完整本体层并不现实。更务实的路径是分层投入、逐级抬升抽象度。

建设顺序不能反：先有项目中的 Skill，再有跨项目的模板，最后才有系统化的本体层。任何行业都可以先做术语标准化和场景清单，把常见问题、业务对象和高频任务整理出来；当同类场景达到一定数量后，再把高频 Skill 组合成模板；只有在场景数量、价值密度和复用率都足够高时，才值得系统建设完整本体层。

4.4　回流机制：让沉淀真的发生

本体层建设是规模化的必经之路，也是最容易被无限延期的事。项目多、人手紧时，团队会优先交付，沉淀永远排在后面；没有沉淀，下一个项目又从零开始；效率低、人更累，于是更没有时间沉淀。这个循环一旦形成，模式就失去了规模化叙事。

访谈中发现的根因是反馈链断裂：一线人员做完项目后，没有利益驱动把现场发现的新业务实体、新流程反馈给后端。考核只看项目是否交付，不考核对资产的贡献；沉淀回来的东西要改、要发布、要培训前线使用，远不如直接在现场用 AI 编程搞定来得快。

破解这个循环需要三项制度同时落地。

机制一：标准化反馈单

每条反馈必须包含五个字段，缺一不可：

1. 发现名称——一句话概括
2. 客户场景——在什么业务环节遇到
3. 当前资产状态——现有 Skill／本体中是否已覆盖，覆盖到什么程度
4. 改进建议——具体到实体、属性或规则层面
5. 通用性判断——预估多大比例的同类场景会遇到

机制二：分级评审

评审节奏同样重要：不是每收到一份反馈就立即改动，而是按月批量评审与版本发布，并明确区分"核心路径"（所有场景共用、不可裁剪）与"扩展点"（可选插件、按需激活）。

机制三：内部结算

内部结算的核心逻辑是双向激励：让交付侧有动力把信息传递给资产侧（反馈可抵扣成本），让资产侧有动力保持资产质量（质量不好就没人用，内部"收入"归零）。

机制四：绩效双轨制

• Delta（交付侧）：项目交付占 85%、经验积累占 15%（反馈数量、采纳率、复用节省工时），随团队成熟逐步提升至 20%—25%
• Echo（资产侧）：资产／平台质量占 70%，前线支持占 30%

参考效果曲线

该案例中，资产冷启动投入约 150 万元（5 人 × 6 个月），到第 8 个场景累计节省交付成本约 300 万元，第 5—6 个场景实现回本。需要强调这是方法论演示用的估算值，具体参数应根据组织规模和业务特征调整。

4.5　金融业特有的实施约束

前四节的方法论跨行业通用。本节列出的六类约束，是银行在照搬通用方法论时最容易漏掉、且漏掉代价最高的部分。

一、数据与权限

• 字段级权限而非表级权限：Agent 的数据访问必须继承调用者的权限上下文，不能因为"Agent 需要完整上下文"而绕过既有权限模型
• 最小必要原则：为每个 Skill 明确列出其所需数据字段清单，作为评审要件
• 跨境数据：涉及香港与内地、或多法域客户数据时，需明确数据落地位置与传输路径；FIS 案例中"客户数据保留在受控基础设施内"的做法可作为参照
• 模型是否接触底层数据：这在房利美案例中被明确列为公民自由层面的核心问题，在银行场景中同样应作为架构评审的必答题

二、可解释与可审计

• 每个结论必须能链回其源数据——这是 FIS × Anthropic 案例中被反复强调的设计目标
• 审计留痕不仅要记录"Agent 做了什么"，还要记录"Agent 看到了什么"与"为什么上浮／不上浮"
• 需保留可重放能力：给定同一输入与同一模型版本，能重现当时的推理路径

三、人在环上

在 AML、授信、合规结论等场景中，最终判断必须由人做出并签署。可参照的边界表述有两组：FIS 案例中"人类调查员保留全部决策权，包括 SAR 报送"；Anthropic 模板文档中"仅产出供合格人员复核的草稿，不执行交易、不批准准入、不写入正式账簿"。

四、模型治理

• 版本管理：模型版本、Prompt 版本、Skill 版本、知识库版本需分别记录并可关联到每次调用
• 评测集：必须由本行拥有，而非依赖供应商。这是判断供应商是否真的完成了知识转移的最硬指标
• 漂移监控：模型升级后，历史评测集须重跑；重点关注"改好 A 又坏 B"型回归
• 回滚机制：模型或 Skill 版本回退的操作路径需在上线前演练

五、供应商与集中度风险

模型厂商既是伙伴也是潜在竞争者：如果模型厂只做平台和 API，生态空间很大；但如果模型厂发现单纯卖 API 定价权不足、开始直接下场做行业方案，就会挤压中间层空间。2026 年上半年 OpenAI 与 Anthropic 同时成立部署公司，正是这一趋势的实证。

还有一层更直接的利益冲突：被雇来解决复杂度的供应商，恰恰也是制造了大部分复杂度的一方。如果 Agent 足够强大到不再需要持续支持，供应商的服务收入就会消失——这一激励结构值得在合同设计中正面应对。

六、监管接口

• 香港：GenA.I. Sandbox++ 已扩展至银行、证券、保险、强积金与储值支付工具，由金管局、证监会、保险业监管局、积金局与数码港共同推动。把项目挂靠沙盒是获取针对性监管反馈的最低成本路径
• 欧盟：AI Act 中高风险系统义务已于 2026 年 8 月 2 日全面适用，涉及透明度、可追溯性与人工监督的具体要求。有欧洲业务的机构需据此校准
• 内地：风控合规类智能体已是落地最广的领域，但国有大行以总行自研为主，公开采购比例低，这影响可参照的公开案例数量

4.6　采购与退出机制

这是本报告认为对银行最具直接价值的一节。

三条判据

1. 成本曲线判据：单位价值对应的现场投入是否逐期下降？如果第一个场景需要 10 人月，第十个同类场景仍需要 10 人月，模式就没有跑通。
2. 自主运营判据（CIO test）：前线团队撤出后，本机构能否运行、监控、质询并安全修改这套工作流？如果答案是否定的，那么这可能是一次成功的实施项目，但还不是一项企业能力。
3. 产品边界判据：供应商的产品边界每个季度是否在向产品侧移动？定制代码是否被持续回收为可复用配置与模板？

合同条款清单

一个容易被忽视的人的因素

自检工具

判定标准综合自：腾讯研究院提出的"FDE 试金石"、a16z 的五项压力测试、Gartner 关于投入平坦度的判据，以及 CIO.com 引述业界专家提出的自主运营测试。

4.7　度量体系

三层指标中，前两层多数机构已有成熟做法，第三层往往完全缺失。若只能新增一个指标，应当是同类交付节省工时——它是成本曲线是否往下弯的直接读数。

本章刻意集中呈现对 FDE 模式的批评。任何一份只讲成功案例的研究报告都不足以支撑采购决策——尤其当这个模式的主要推广者，同时是它的主要受益方时。

5.1　a16z：脚手架不是房子

a16z 合伙人 Marc Andrusko 在 2026 年 1 月的分析中提出了行业内第一份有分量的质疑。其核心判断是：Palantir 是一家"独一类"（category of one）公司，因为它同时做好了三件事——构建集成化产品平台、把精英工程师嵌入客户运营、在关键任务级的政府与国防环境中证明自己。多数公司能做好其中一件、也许两件，但不可能三件同时做到。而大多数只是在模仿其外观的公司，最终会变成"拥有软件估值倍数、却没有复利型竞争优势的昂贵服务公司"。

四条断裂点

• 不是所有问题都是 Palantir 级问题。Palantir 的早期部署都在"不做就什么都不转"的领域：反恐、欺诈侦测、战场后勤、高风险医疗运营，价值以数十亿美元或人命计。如果只是把某个工作流优化 8%，ROI 区间根本支撑不起数月的现场工程。
• 多数客户不想永远当你的研发实验室。Palantir 的客户隐含地接受了与产品共同演进；但在国防与强监管行业之外，多数企业希望的是可预期的实施、与既有工具的互操作性和快速见效。
• 人才密度与文化不可泛化。Palantir 用十余年招募并训练出一批既能写生产代码、又能在官僚体系中周旋、还能与上校、CIO 和监管者同处一室的通才。实践中，"我们要建一支 Palantir 式 FDE 团队"往往退化成三种形态：把售前解决方案工程师换个头衔；让初级通才同时兼做产品、实施与客户管理；由从未近距离见过真实 FDE 部署、只是喜欢这个概念的管理层来领导。
• 服务化陷阱是真实的。Palantir 之所以成立，是因为底下有一个真实的平台。如果只复制"嵌入工程师"这一部分，结果会是成千上万个无法维护、无法升级的定制部署。

5.2　Gartner：依赖而非能力

如 4.6 节所述，Gartner 预测到 2028 年将有 70% 的企业放弃 FDE 主导的智能体方案。这一预测的价值不在于数字本身，而在于它给出的早期识别信号：连续多次部署的投入保持平坦。这个信号在合作的第二、第三个场景就能观察到，远早于合同到期。

5.3　业界高管的分歧

5.4　平台侧的竞争性挤压

本体／语义层曾被视为 Palantir 最深的护城河，但 2026 年出现了正面竞争：Databricks 在其 6 月峰会上推出 Genie Ontology，其 CEO 的表述是——AI 没有智能问题，有的是上下文问题；Snowflake 亦在推进同类能力。这两家公司都不会组建前线部署大军，而且许多 Foundry 部署本身就跑在它们之上。但它们不需要正面对抗，只需要让独立的"操作系统层"显得冗余或不再必要。

对已把数据放在这些平台上的银行而言，这是一个直接的成本比较：是花数月与外部平台做集成，还是花数周打开数据仓库自带的 Agent 工具链。答案取决于场景复杂度，但这个选项在 2026 年之前并不存在。

5.5　中国市场的特有风险

• 经济性：国内项目客单价与海外差一个量级，高成本专家投入难以算平账；解法只能是提高复用率而非提高单价
• 价值定价难以落地：客户习惯买断制或按功能点验收，采购流程要求明确交付物清单和验收标准，"业务结果改善"很难写进合同条款。因此国内的利润率提升更现实的路径是产品化复用——把每次交付成本压低，而非把单次收费抬高
• 晋升拧巴导致一线失血：很多组织把 FDE 视为临时前线岗位，一旦人员表现突出就调回总部做管理或产品。结果是一线永远在换人、新人永远要重新建立业务方信任，标杆经验随人员调动而散失。健康的机制应该让一线本身成为高级职级的主战场，而不是通往总部的跳板
• 数据底座差异：海外大企业的流程、数据、岗位分工与系统治理已多年沉淀，AI 更像在一台精密机器上加装智能大脑；而国内很多组织更接近"对话驱动"——需求常以非结构化方式提出，流程常常不写在系统里。这既增加了落地难度，也带来了跳级机会：自然语言恰恰是这类组织最熟悉的协作方式

5.6　风险总览

6.1　三个战略选择

6.2　起步 90 天路线图

第 12 周的决策关口不应被跳过。若试点数据不支持继续，及时终止的成本远低于让项目在半活状态下持续消耗资源——这也是限时部署机制存在的意义。

6.3　场景优先级

基于本报告收集的全部案例，2026 年金融业 FDE 落地效果最确定的场景集中在中后台，且具备三项共同特征：价值可货币化、基线清晰、失败可控。

6.4　给管理层的七个提问

无论面对内部团队还是外部供应商，以下七个问题足以在一小时会议内判断一个 AI 项目的成色：

1. 这个场景在业务负责人的优先事项里排第几？如果不在前五，为什么我们还在做？
2. 业务指标基线是多少？改善目标是多少？由谁认账？
3. 共享产品能力在哪里结束、本行特定代码从哪里开始？这条边界上个季度移动了吗？
4. 从签约到第一次生产使用需要多少工程人月？其中哪些部分是必须定制的？
5. 第三个同类场景的现场投入，比第一个下降了多少？
6. 评测集在谁手里？我们能不能独立重跑？
7. 如果这支团队明天全部撤走，我们能运行、监控、质询并安全修改这套工作流吗？

6.5　三年演进节奏

第六章的结论是：Echo 能力不可外包。本章回答随之而来的问题——如果一家大型银行决定在内部建一支 FDE 小队，这支队伍应该由哪些角色组成、每个角色需要什么能力、这些能力从哪里来、以及怎么练出来。

7.1　组队之前必须回答的三个问题

问题一：这支团队解决什么？

最常见的组队失败，源自一个含糊的立项目标——"推动全行 AI 应用落地"。这句话无法转化为编制、能力要求与考核标准。

更可操作的定义是：把已经被业务方确认为高价值的少数场景，从可运行原型推到生产运行，并在此过程中沉淀出可复用的资产。注意这个定义排除了三类工作：它不负责挑选模型供应商（那是采购与架构评审的职责）、不负责日常 AI 工具的运维答疑（那是应用运维的职责）、也不负责全行 AI 培训（那是人力与业务条线的职责）。边界不清的团队会在半年内被工单淹没。

问题二：最小可行编制是多少人？

本报告建议的起步编制是 6 至 9 人，理由如下：

• 低于 5 人不成立——银行场景必须同时覆盖业务判断、工程实现、数据集成、评测治理四类工作，少于五人必然出现某一类由外部临时补位，而这恰恰是能力无法沉淀的原因
• 高于 12 人过早——在没有跑通两三个场景、尚未形成交付方法与资产库之前扩编，团队会迅速退化为项目制交付部门，新人无处学习
• 并行场景数决定上限——一个双人舞小组同期只能认真做一个场景。6 至 9 人意味着 2 至 3 条并行线，加上 1 名负责人与 1 至 2 名共享的横向角色

问题三：需要什么授权？

能力可以培养，授权不能。以下四项若不在组队时明确，后期补办的成本极高：

7.2　六维能力框架

银行版 FDE 的能力模型比通用版多出一维。硅谷的 FDE 讨论通常只谈"业务理解 + 工程能力"，但在银行，风险、合规与模型治理不是一项附加要求，而是决定方案能否上线的硬约束，必须作为独立维度显性管理。

能力分级标准

为使能力要求可评估，本报告对每一维采用统一的四级标准。这套分级同时用于招聘评估、培养目标设定与内部认证。

D1 银行经营理解：具体应该懂什么

这一维最容易被泛泛而谈，因此单独展开。达到 L3 意味着能够独立回答以下问题：

D2 机器学习：与存量模型共存

银行不是从零开始做 AI 的行业。评分卡、反欺诈规则与模型、时序预测、生存分析等存量资产已运行多年，且受模型风险管理框架约束。FDE 团队必须理解三件事：

• 存量模型的评估语言——AUC、KS、PSI、Lift 与稳定性监控，是与风险管理部门对话的共同语言。不会这套语言，方案很难通过评审
• 可解释性为何是硬要求——以 SR 11-7 为代表的模型风险管理框架要求模型开发、验证与使用三方独立，且模型逻辑可被独立验证。这解释了为什么"效果更好但说不清"的方案在银行往往推不动
• 何时不该用大模型——需要精确数值计算、需要严格可复现、需要对每个决策给出稳定归因的场景，仍应使用传统模型。大模型的正确定位是处理非结构化信息与编排流程，而不是取代评分卡

D3 LLM 与 Agent 基础设施：技术栈清单

7.3　角色构成与能力矩阵

本报告建议的银行内部 FDE 团队由六个角色构成。其中前三个来自通用 FDE 模型，后三个是银行环境下必须单列的增补角色——在硅谷的 FDE 讨论中，它们通常被合并进 Delta，但在银行的系统复杂度与监管要求下，合并会直接导致项目卡在数据接入或合规评审。

7.4　逐角色详解

7.5　培养方法：什么能力用什么方式练

培养失败的最常见原因，不是投入不足，而是方法与能力类型错配。把 D1 银行经营理解交给课堂培训，或把 D3 技术栈交给轮岗，都会浪费时间。以下映射表给出各维度最有效的培养手段。

八种具体做法

一、业务条线跟岗（培养 D1，不可替代）。科技背景成员到业务条线跟岗 4 至 8 周，要求跟完一个完整周期而非旁听若干会议——例如跟完一笔对公信贷从受理到放款的全过程，或跟完一轮反洗钱告警从生成到结案的处理。跟岗产出物应是一份流程图，标注每个决策点的责任人、判断依据与例外路径。这份产出物本身就是后续本体建模的素材。

二、真实案件跟案（培养 D1 与 D6）。比跟岗更聚焦：选取 20 至 30 份历史案件卷宗，由业务专家逐份讲解判断依据。关键价值在于暴露官方流程与真实流程的差异——4.6 节指出的领域专家激励冲突，最有效的化解方式不是访谈，而是让工程人员自己读完真实卷宗后提问。

三、项目制带教（培养 D5，唯一路径）。交付与推动能力在真实项目中练出来，课堂教不出来。分层路径如下：

四、内部认证（把培养变成可管理的过程）。光统计上课次数没有意义。可操作的机制分四层，与上表对应：

五、把供应商项目当训练场（性价比最高）。这是 C1 案例中最值得直接照搬的做法：Amalgamated Bank 的合规团队被嵌入 Agent 的设计过程，与供应商的产品专家和模型厂商的工程师并肩工作，而不是在末端做验收。

六、沙盒项目练兵（香港机构的现成通道）。如 C8 所述，香港的 GenA.I. Sandbox++ 提供了一个风险受控、且能获得针对性监管反馈的环境。对团队培养而言，其价值在于让成员在真实监管对话中练习 D6，这是任何内部演练都无法替代的经历。

七、红队演练（培养 D6 与 D3 的交叉能力）。每季度组织一次，内容包括提示注入尝试、越权数据访问尝试、幻觉复现与边界案例构造。演练结果直接转化为评测集的新增用例——这使演练本身成为资产沉淀活动，而非一次性合规动作。

八、强制复盘与资产入库。每个场景结束必须产出两份东西：一份复盘报告（做对了什么、什么该早做、下次同类场景可省略哪些步骤），一份反馈单（格式见 4.4 节）。未完成这两份产出的项目不计入结项——这是让沉淀真正发生的最低成本约束。

7.6　选人：内部转任与外部招聘

内部转任的来源画像

核心判断是：大型银行不需要大量新增编制，关键是现有角色的能力转型升级。深耕某一业务域的解决方案架构师，是最接近完整 FDE 能力模型的现有角色；而 Echo 岗位则应优先从业务条线选拔，而非从科技条线培养。

外部招聘的现实约束与应对

1.4 节的薪酬数据显示，头部 FDE 岗位的市场价格已进入年包 60 万至 100 万元以上区间，多数银行的科技薪酬带难以对标。可用的非薪酬补偿包括：

• 数据与场景的真实性——银行能提供的真实业务数据与生产级约束，是多数创业公司无法提供的经验环境
• 职业稀缺性——具备金融业生产级 Agent 落地经验的人极少，这段履历本身具有市场价值
• 职级设计——让一线本身成为高级职级的主战场，而不是通往管理岗的跳板（详见 7.8 节失败模式）

7.7　18 个月建设路线

12 至 18 个月的验收标准只有一条，与全文主线一致：第三、第四个同类场景的交付投入，是否明显低于第一个。若答案为否，问题通常不在人的能力，而在沉淀机制未落地——应回到 4.4 节检查回流制度是否真的进入了绩效。

7.8　六种常见失败模式

A　术语表

B　关键数据速查

C　参考来源