FDE · 企业AI落地 · 架构治理
FDE进场前，先谈退场：最贵的不是服务费，是换不掉的架构
FDE能帮企业跨过从Demo到生产的鸿沟。企业也要提前回答另一道题：工程师离场、模型换代、供应商涨价以后，这套系统还能不能继续运行？
FDE能帮企业跨过从Demo到生产的鸿沟。企业也要提前回答另一道题：工程师离场、模型换代、供应商涨价以后，这套系统还能不能继续运行？
一个很值得企业管理者关注的变化正在发生。
模型公司不满足于把 API 文档交给客户了。它们开始把工程师送到客户身边，一起选场景、拆流程、写代码、做评测，再把系统推到生产环境。
OpenAI 已经成立专门的部署公司，官方把这类嵌入企业、处理复杂问题的工程师称为 Forward Deployed Engineer，也就是 FDE。Anthropic 的招聘页面同样出现了 Forward Deployed Engineer 职位，并通过埃森哲等合作伙伴把熟悉 Claude 的工程师带进客户环境。
Palantir 很早就采用了这种工作方式。它对 FDE 的描述很形象：工程师尽可能靠近问题，再把现场反馈带回产品团队。
三家公司共同说明了一件事。
模型能力已经很强，企业仍然需要一个人坐到现场，把通用能力翻译成具体系统。
但企业接受 FDE 之前，还应多问一个问题。
他进场以后能帮你建成什么？
他离场那天，你手里又剩下什么？
企业买的不是API，是翻译能力
一家制造企业说"想用 AI 提高质量"，这句话离技术方案还很远。
质量问题发生在哪道工序？输入是图片、传感器数据还是质检记录？系统只能给建议，还是可以拦停设备？错误判断由谁复核？历史数据能不能用于训练？现场网络是否允许访问外部模型？
每一个答案都会改变方案。
懂模型的人未必听得懂工厂的语言。懂业务的人也未必知道，哪些判断适合交给模型，哪些必须保留规则和人工确认。
FDE 的价值，就在这段翻译工作里。
他需要走进业务现场，看数据如何产生、流程如何流转、异常由谁处理、权限掌握在谁手里，再把这些信息写成工作流、知识检索、工具调用、评测集和上线标准。
API 文档只能告诉你接口怎么调。它不会告诉你，这家公司里哪份制度已经过期，哪个部门不愿共享数据，哪个审批节点不能自动越过。
所以，FDE 的兴起没有证明 AI 变简单了。它证明企业交付比模型演示复杂得多。
厂商FDE很强，也天然带着平台立场
厂商 FDE 往往拥有外部团队难以替代的优势。
他更了解自家模型的能力边界，可以接触最新接口、内部实践和产品路线，也能把现场问题快速反馈给核心研发。遇到模型行为、性能或安全限制，厂商团队通常能更快找到原因。
企业应该利用这份技术深度。
同时也要看清一项结构性事实：厂商 FDE 的工作目标，是帮助客户成功采用自家平台。
这不代表工程师缺乏职业操守。任何公司都会围绕自己的产品、能力和商业目标配置资源。
OpenAI 的部署团队自然熟悉 OpenAI 的模型、接口和生态；Anthropic 的团队自然会围绕 Claude 设计方案。长期共同开发以后，提示词、工具格式、评测基线、日志体系和运维流程都会逐渐贴近当前平台。
问题通常不会在项目上线时出现。
真正的考验发生在一年后：成本变化了，模型表现变了，合规要求变了，或者另一家供应商在某个任务上明显更合适。
这时企业才发现，换模型远远不止修改一个 API 地址。
原来的结构化输出格式可能不同，工具调用协议可能不同，安全策略需要重做，评测集针对旧模型校准，提示词里藏着大量供应商特性。外围代码、监控和员工操作习惯也可能跟着绑定。
这种依赖并不一定来自某个蓄意设计。项目为了赶进度，会自然选择最顺手的专有能力。一个个合理的局部选择叠在一起，最后就形成了很高的迁移成本。
判断锁定风险，看离场成本
企业经常用采购价格衡量供应商成本。
AI 系统还要加上另一笔账：如果半年后必须更换模型或合作伙伴，需要重做多少工作？
可以在项目启动时设计一个简单的"离场测试"。
从系统里挑一个真实任务，让另一种模型在隔离环境中完成同样的输入和输出。如果需要重写整条工作流，说明抽象层还不够清楚。
再让内部团队根据现有文档独立部署一次。如果关键配置只存在 FDE 的电脑、私人脚本或口头说明里，企业并没有真正接住系统。
最后检查评测集。更换模型以后，企业能否用同一套业务样本比较准确率、成本、速度和风险？没有稳定评测，所谓"可以换模型"只是一句架构口号。
三种角色，各自守住一条边界
一个成熟的企业 AI 项目，很难靠单一角色完成。
厂商FDE负责把技术做深
让最懂平台的人解决最难的技术问题，缩短从原型到生产的距离。
他的优势集中在平台深度、疑难问题处理和产品反馈。企业不应要求他假装完全中立，也不必因此拒绝他的帮助。
独立评审负责把选择看全
独立顾问或架构评审团队不负责销售某一款模型。他们要检查模型选择、数据边界、成本假设、接口设计和迁移方案。
"独立"也不能只靠自我介绍。评审方是否从供应商获得佣金，是否具备其他平台的真实项目经验，意见是否写进正式评审报告，都需要明确。
内部团队负责把系统接住
企业自己的业务和技术人员最了解数据、权限、例外情况与组织现实。
项目上线以后，知识更新、故障处理、成本监控和业务调整都要由内部团队长期承担。如果内部人员只在最后一天参加培训，交接大概率会失败。
最稳妥的方式，是让内部负责人从需求定义阶段就与 FDE 结对工作。交付的不只是系统，还包括文档、评测、运维能力和决策记录。
FDE进场前，把五件事写进合同
模型可换
业务逻辑不要散落在某一家模型的专有调用里。
可以使用厂商特性，但要明确哪些模块依赖它、替代方案是什么、切换需要多少时间。关键任务至少保留一次替代模型验证记录。
数据归我
企业应掌握原始数据、清洗结果、知识库内容、反馈样本和运行日志。
合同要写清楚数据存放位置、访问权限、留存期限、删除机制，以及供应商能否把数据用于其他目的。
评测复用
评测集属于企业的重要资产。
它应描述业务问题和验收标准，而不是只描述某个模型的表现。换模型、换提示词或升级系统时，都能用同一组样本重新比较。
接口标准
模型调用、工具调用、身份权限和日志记录之间要有清楚的边界。
专有能力可以封装在适配层里，业务流程尽量只依赖稳定接口。未来替换供应商时，改动集中在适配层，而不是重写整套系统。
团队接手
交付完成的标准不能只有"系统已经上线"。
还应包括源代码和配置归档、部署文档、故障手册、成本说明、权限清单、培训记录，以及内部负责人独立完成一次发布和回滚。
FDE 离场后，企业仍能处理日常问题，项目才算真正交付。
"模型无关"也不是越多越好
谈到供应商锁定，很容易走向另一个极端：所有能力都必须抽象，任何平台特性都不能使用。
这样会牺牲开发速度，也可能放弃某个模型最有价值的能力。
合理的目标不是零依赖，而是可见、可算、可退出。
企业可以主动选择一项专有能力，只要知道它带来了什么收益，迁移时要付出多少成本，谁批准了这项选择。
架构成熟不等于永远可以无痛切换。它意味着企业没有在不知情的情况下把选择权交出去。
写在最后
FDE 的复兴传递了一个清晰信号。
企业 AI 的竞争已经从"谁能调用模型"走向"谁能把模型嵌进真实业务"。翻译流程、整理数据、设计评测、处理组织约束，这些工作越来越值钱。
厂商 FDE 会成为重要力量，独立评审和内部 AI 团队也不会因此消失。三者解决的是不同问题：平台深度、选择中立和长期所有权。
企业接受 FDE 时，不必先把对方当成潜在对手。
只需要在项目启动会上多留一把椅子，给未来那个负责接手、评审或者更换供应商的人。
然后问清楚：如果合作明天结束，我们能否拿着自己的数据、评测、接口和文档继续往前走？
这道题有答案，FDE 才值得进场。
资料来源：
- OpenAI，《OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence》：https://openai.com/index/openai-launches-the-deployment-company/ - OpenAI，Forward Deployed Engineer 招聘说明：https://openai.com/careers/forward-deployed-engineer-%28fde%29-seattle-seattle/ - Anthropic，招聘职位列表：https://www.anthropic.com/careers/jobs - Anthropic，《Accenture and Anthropic launch multi-year partnership》：https://www.anthropic.com/news/anthropic-accenture-partnership - Palantir，Architecture Center Overview：https://www.palantir.com/docs/foundry/architecture-center/overview
— 完 —