Palantir FDE模式拆解：企业AI交付如何沉淀为可复用产品

企业级 AI 项目做久了你会发现一个很拧巴的现象Demo 阶段惊艳全场POC 报告写得天花乱坠可一旦要往生产环境推、要交付给客户、要让非技术同事真正用起来进度就卡住了。Palantir 的 AI FDEForward Deployed Engineer前置交付工程师模式这两年频繁被拿出来讨论本质上就是因为它回答了一个所有做企业 AI 交付的团队都绕不开的问题——为什么同样一套模型能力有人能做成可复用的产品有人只能一次次重做项目我自己带过几个从零到一的 AI 交付项目也踩过每个客户都当新项目做的坑。这篇文章不打算复述 Palantir 的官方宣传而是想把它那套 FDE 打法拆开结合 Ontology、Coding Agent、多智能体协作这些当下最热的工程实践聊清楚一件事企业交付到底怎么沉淀成产品。适合正在做 AI 落地、被定制化需求拖垮、或者想搭一套可复用 Agent 框架的工程师和产品同学看。全文会围绕交付与产品的边界Ontology 为什么是核心Coding Agent 在交付中的真实角色多智能体协作的工程规范这几条主线展开尽量给到能直接抄作业的思路。1. 先搞清楚 FDE 到底在解决什么交付难题1.1 传统企业 AI 交付的三个死结大部分团队做企业 AI路径都差不多销售拿到需求解决方案团队出方案研发团队做定制开发交付上线然后进入漫长的维护期。这个链条在传统软件时代勉强能跑但放到 AI 项目上三个死结会同时收紧。第一个死结是需求无法被准确翻译。客户说我想要一个能自动分析合同风险的助手这句话背后可能是法务想省审阅时间也可能是风控想抓合规漏洞还可能是业务想加速签约流程。三种诉求对应的数据源、判断逻辑、输出形态完全不同。销售和研发之间隔着好几层转述等代码写完客户说这不是我要的返工成本极高。第二个死结是数据与业务语义的鸿沟。AI 模型只认向量和 token但企业里真正有价值的是这个订单属于哪个客户这笔款项对应哪份合同这个设备属于哪条产线这类业务关系。没有一层把业务语义显式建模出来的东西模型再强也只能做表面文本处理做不了真正的业务推理。第三个死结是每个项目都在重复造轮子。客户 A 做了个合同审阅 Agent客户 B 要做工单分类 Agent客户 C 要做知识问答 Agent三个项目的数据接入、权限控制、日志审计、人工兜底流程几乎一模一样但因为交付时都是项目制没人有动力去抽象公共层结果就是三份代码、三套运维、三次踩坑。Palantir 的 FDE 模式之所以被反复研究就是因为它把这三个死结当成设计前提而不是事后补救。FDE 不是驻场外包工程师而是一个同时懂业务、懂数据、懂工程的角色他的核心产出不是一次性交付的代码而是把客户业务逻辑沉淀进一套可复用的平台能力里。1.2 FDE 和普通交付工程师的本质区别很多人把 FDE 理解成高级实施顾问这个理解偏了。普通交付工程师的目标是这个项目按时上线FDE 的目标是这次交付能让下一次交付更快。两者的 KPI 完全不同。普通交付工程师的典型动作是接需求、写代码、联调、上线、撤场。项目结束知识留在个人脑子里下一个项目从零开始。FDE 的典型动作是深入客户业务现场把业务对象、业务流程、业务规则抽象成平台上的模型用配置和少量代码把需求实现然后把这次抽象出来的通用部分反哺到平台。这里有个关键判断FDE 交付的不是功能是业务语义的建模结果。功能会过时但业务语义模型是可以跨项目复用的。比如客户合同订单设备这些实体以及它们之间的关系在同一个行业里高度相似。FDE 把第一个客户的这些实体建模好第二个客户就能直接复用只需要调整字段和规则。我自己的体会是判断一个团队有没有 FDE 思维看一个指标就够了第二个相似客户的项目周期是不是明显短于第一个。如果还是差不多长说明第一个项目根本没沉淀下东西只是做完了而已。1.3 从项目制转向产品制的组织前提FDE 模式要跑通光靠个人能力不够组织层面得先松绑。最核心的一条是交付团队和产品团队不能是两拨互不往来的人。传统组织里交付团队负责满足客户产品团队负责做通用能力两边经常打架——交付嫌产品不灵活产品嫌交付需求太定制。FDE 模式的做法是把这两个角色合并或者强绑定FDE 在客户现场发现的需求有权限直接推动产品迭代产品团队做的通用能力必须经过 FDE 在真实客户场景里验证过才算数。另一个前提是度量方式要改。如果只考核项目交付数量和客户满意度没人会去做沉淀。得加上复用率平台能力新增数第二个客户交付周期这类指标让沉淀这件事有正向激励。这一点说起来简单做起来最难因为它动的是考核体系。2. Ontology把业务语义变成 Agent 能理解的东西2.1 Ontology 不是知识图谱别搞混了一提到 Ontology很多人第一反应是知识图谱。这两个东西有关系但不是一回事。知识图谱侧重实体和关系的存储与查询Ontology 侧重业务概念的定义和约束。用大白话讲知识图谱是存了什么Ontology 是这些东西按什么规则存在、能怎么被操作。Palantir Foundry 里的 Ontology核心是把企业里的对象Object、属性Property、关系Link、动作Action显式定义出来。比如定义一个合同对象它有合同编号签署方金额生效日期这些属性它和客户对象之间有属于关系它上面可以执行审批作废归档这些动作。为什么这对 AI Agent 至关重要因为 Agent 要做的不是回答一个问题而是完成一个任务。完成任务需要知道有哪些对象、对象之间什么关系、能对对象做什么操作、操作的约束是什么。这些信息如果只存在数据库表结构里Agent 是理解不了的只有被显式建模成 OntologyAgent 才能基于它做推理和决策。2.2 Ontology 如何成为 Agent 的业务操作系统把 Ontology 理解成 Agent 的业务操作系统这个类比很贴切。操作系统给应用程序提供文件、进程、内存这些抽象应用程序不用关心底层硬件Ontology 给 Agent 提供对象、关系、动作这些抽象Agent 不用关心底层数据存在哪张表、用什么 SQL 查。具体来说Ontology 给 Agent 提供了三层能力。第一层是语义 grounding。用户问上个月华东区哪些合同快到期了Agent 不需要去猜华东区对应哪个字段、快到期是几天因为 Ontology 里已经定义了区域划分规则和到期预警阈值。Agent 只需要把自然语言映射到 Ontology 上的查询。第二层是动作约束。Agent 想执行作废合同这个动作Ontology 里定义了作废需要什么权限、什么前置状态、会产生什么副作用。Agent 不会乱来因为动作的边界是显式定义的。第三层是可解释性。Agent 做出一个决策可以追溯到它用了哪些对象、走了哪些关系、触发了哪个动作。这对企业场景太重要了因为企业不接受模型说这样就这样必须能审计、能复盘。2.3 用 Ontology 做 RAG比纯向量检索强在哪现在做企业知识问答主流做法是 RAG检索增强生成把文档切块、向量化、检索、拼进 prompt。这套做法在找相似段落上有效但在回答需要跨文档推理的业务问题上很吃力。举个例子用户问我们和供应商 X 的框架协议里关于延期交付的违约金是怎么算的最近一次修订是什么时候改的。纯向量 RAG 会检索到几段相关文本但很难准确回答最近一次修订时间这种需要结构化信息的问题因为它不知道修订是一个有版本、有时间的动作。用 Ontology 做 RAG 的思路不一样先把合同、条款、修订记录建模成对象和关系检索时先定位到供应商 X 的框架协议这个对象再沿着条款修订记录这些关系取数据最后把结构化结果喂给模型生成自然语言回答。这样检索的准确性和可解释性都高一个量级。我实测下来的经验是纯文本类问答用向量 RAG 够用涉及业务对象、状态、关系的问答必须上 Ontology。两者不是替代关系是互补关系——Ontology 负责结构化 grounding向量检索负责非结构化补充。2.4 建模 Ontology 的实操顺序和常见坑建模 Ontology 最容易犯的错是一上来就追求大而全想把企业所有对象都建出来。结果建了三个月一个能用的场景都没有。正确的顺序应该是从场景倒推对象。具体步骤我一般这么走锁定一个高频、边界清晰的业务场景比如合同到期预警不要选全面提升法务效率这种模糊目标。列出这个场景涉及的所有业务对象合同、客户、负责人、提醒记录先不管关系。定义每个对象的关键属性和状态机合同有草稿-审批中-生效-到期-作废这些状态状态之间的流转条件要写清楚。定义对象之间的关系合同属于客户、合同有负责人、提醒关联合同。定义可执行动作创建提醒、发送通知、标记已处理。用真实数据跑一遍看模型能不能基于这套 Ontology 完成场景任务。常见的坑有这么几个。一是属性定义太技术化直接照搬数据库字段名导致 Agent 理解不了业务含义属性名要用业务语言。二是状态机不完整只定义了正常流转没定义异常和回退Agent 遇到边界情况就卡住。三是动作没有权限约束Agent 能执行它不该执行的动作这在企业场景是事故。四是忽略时间维度很多业务对象是有历史版本的Ontology 里不体现版本Agent 就回答不了什么时候改的这类问题。3. Coding Agent 在交付流程里的真实定位3.1 Coding Agent 不是替代工程师是压缩翻译损耗现在 Coding Agent 很火从命令行工具到 IDE 插件一大堆。很多团队一上来就想让 Agent 把代码全写了这个预期是错的。Coding Agent 在企业交付里真正的价值是压缩从业务需求到可运行代码之间的翻译损耗。传统流程里业务需求要经过产品经理翻译成 PRDPRD 翻译成技术方案技术方案翻译成代码每一层翻译都会丢信息。Coding Agent 如果接入了 Ontology就能直接理解业务对象和动作跳过中间几层翻译直接从我要一个合同到期前 30 天自动提醒的功能生成对应的实现。但注意这不意味着工程师没事干了。工程师的角色从写代码变成定义约束和验证结果。Agent 生成的代码对不对、边界处理全不全、性能扛不扛得住还是得人来把关。我自己的做法是让 Agent 做第一版人做 review 和边界补全效率比纯手写高但绝不是撒手不管。3.2 把 Coding Agent 接进 Ontology 的工作流Coding Agent 要真正在企业交付里发挥作用必须和 Ontology 打通。孤立的 Coding Agent 只能基于通用知识写代码接上 Ontology 之后它知道这个企业有哪些对象、哪些动作、哪些约束生成的代码才贴合实际。一个可落地的工作流大概是这样需求输入FDE 用业务语言描述需求比如给合同对象加一个到期预警动作。Ontology 查询Agent 先查 Ontology确认合同对象存在、有哪些属性、现有动作有哪些。方案生成Agent 基于 Ontology 约束生成实现方案包括需要新增的属性、动作、触发条件。代码生成Agent 生成对应的代码和配置。人工 reviewFDE 检查方案是否符合业务预期代码是否处理了边界。部署验证在测试环境跑真实数据验证行为。回写 Ontology如果新增了对象或动作同步更新 Ontology供后续复用。这个流程里最关键的是第 2 步和第 7 步。第 2 步保证 Agent 不瞎编第 7 步保证这次交付能沉淀。很多团队只做了 3、4、5、6忽略了 2 和 7结果 Agent 用起来了但沉淀没发生还是项目制。3.3 交付场景下 Coding Agent 的边界与风险Coding Agent 在企业交付里有几条边界必须守住。第一条是数据边界。Agent 能访问哪些数据、不能访问哪些数据必须在 Ontology 层面就约束好。不能让 Agent 为了完成任务去读它不该读的表。这在多客户场景下尤其重要客户 A 的数据绝不能出现在客户 B 的 Agent 上下文里。第二条是动作边界。Agent 能执行的动作必须是白名单。生成代码、写配置文件这些低风险动作可以放开但涉及生产数据修改、权限变更、对外发送的动作必须有人工确认环节。第三条是审计边界。Agent 做的每一步都要留痕它查了什么、生成了什么、谁批准的、部署到哪了。企业场景下Agent 自己干的不是免责理由出了事还是要人负责所以审计链路必须完整。我踩过的一个坑是早期让 Agent 直接改生产配置结果它把一个字段的默认值改了导致一批历史数据解析异常。后来改成所有生产变更必须走Agent 生成 diff 人工确认 灰度发布三步再没出过类似问题。这个教训值不少钱希望你别重复踩。4. 多智能体协作交付规模化的工程规范4.1 什么时候该上多 Agent什么时候不该多 Agent 协作是这两年的热词但我要泼盆冷水大部分交付场景单 Agent 加好的工具链就够了上多 Agent 往往是过度设计。判断标准很简单如果一个任务可以被一个 Agent 用清晰的工具调用序列完成就别拆成多个 Agent。多 Agent 带来的通信开销、状态同步、错误传播往往比它解决的问题还多。真正需要多 Agent 的场景通常有这几个特征任务可以清晰分解成职责不同的子任务比如一个负责检索、一个负责推理、一个负责执行子任务之间需要不同的工具集和权限子任务可以并行以提升效率。比如一个复杂的合同审阅流程检索 Agent 负责找相关条款分析 Agent 负责判断风险执行 Agent 负责生成审阅意见这三个职责差异大、工具集不同拆开是合理的。4.2 多 Agent 协作的通信与状态管理多 Agent 一旦上马通信和状态管理就是最大的工程挑战。我见过太多团队把多 Agent 做成几个 Agent 互相喊话结果状态乱成一锅粥出了问题根本不知道是哪个 Agent 的锅。比较稳的做法是引入一个显式的共享状态层所有 Agent 读写这个状态层而不是互相直接传消息。这个状态层可以基于 Ontology 构建每个 Agent 的输入输出都是 Ontology 上的对象和动作。这样做的好处是状态可审计、可回放、可干预。通信协议上我建议用结构化消息而不是自然语言。Agent A 给 Agent B 传我找到了三份相关合同不如传一个结构化的对象列表包含合同 ID、相关度、关键字段。自然语言消息看起来灵活实际上不可靠容易产生歧义而且难以程序化处理。状态管理还有个容易忽略的点是超时和失败处理。多 Agent 协作里一个 Agent 卡住会导致整条链路挂起。必须给每个 Agent 设置超时超时后要么重试、要么降级、要么转人工。我见过一个案例检索 Agent 因为一个慢查询卡了十分钟整个审阅流程就停在那用户体验极差。4.3 从单点交付到可复用 Agent 平台的演进路径回到文章的核心问题交付怎么变成产品。多 Agent 协作如果做得好本身就是产品化的载体。演进路径我总结成三个阶段。第一阶段是单点交付。针对一个客户的一个场景做一个 Agent跑通就行。这个阶段不要想复用想多了反而做不出来。第二阶段是能力抽象。做完两三个相似场景后把公共部分抽出来数据接入层、Ontology 层、工具调用层、审计层。这时候开始有平台的雏形。第三阶段是平台化交付。新客户来了FDE 基于平台配置 Ontology、组装 Agent、调整工具而不是从零写代码。交付周期从几个月压缩到几周这才是产品化的标志。这三个阶段不能跳。我见过一些团队第一阶段还没跑通就想做平台结果平台做出来了没有真实场景验证全是空中楼阁。平台是被交付逼出来的不是设计出来的。4.4 Agent 记忆体系在交付场景的落地Agent 记忆是另一个绕不开的话题。企业交付场景下记忆分三层比较合理。短期记忆是单次会话内的上下文比如用户这次问了一串问题Agent 要记住前面问了什么。这层用会话 buffer 就行简单直接。长期记忆是跨会话的业务知识比如这个客户的历史偏好、常见问题、特殊规则。这层要落到 Ontology 或者专门的记忆存储里不能只放在向量库里因为需要结构化查询和更新。永久记忆是几乎不变的基础知识比如行业规范、公司制度、产品手册。这层适合做静态索引更新频率低。落地时最容易出问题的是长期记忆的写入策略。什么信息该记、什么不该记、记了之后怎么更新、怎么删除这些规则不定义清楚记忆库很快就会变成垃圾场。我的做法是只有被验证过的、可复用的信息才写入长期记忆单次会话的临时信息不写。这样记忆库保持干净检索质量也高。5. 把交付沉淀成产品的几个硬约束5.1 复用不是自然发生的得设计出来很多团队以为做多了自然就复用了这是幻觉。复用是设计出来的不是涌现出来的。如果每个项目都独立立项、独立排期、独立考核没人会主动去复用因为复用意味着这次要多花时间抽象收益却算在下个项目头上。要打破这个局面得在流程上强制。比如规定任何新项目启动前必须先盘点现有平台能力能复用的必须复用不能复用的要说明理由。再比如把抽象出的公共能力计入本次项目的产出让做抽象的人有回报。5.2 交付与产品的边界怎么划边界划不清楚要么交付被产品拖死要么产品被交付需求淹没。我的经验是划三条线。第一条线是数据模型。客户特有的数据模型归交付跨客户通用的数据模型归产品。判断标准是这个模型换个客户还能不能用。第二条线是业务规则。客户特有的规则归交付行业通用规则归产品。比如合同金额超过 100 万需要法务审批是客户规则合同审批需要留痕是通用规则。第三条线是交互形态。客户特有的界面和流程归交付通用的 Agent 交互框架归产品。这三条线不是一成不变的随着客户数量增加原本客户特有的东西可能变成通用的这时候就要从交付侧迁移到产品侧。迁移的时机判断很重要太早迁移产品不稳定太晚迁移交付负担重。5.3 度量体系怎么知道交付真的在变产品没有度量就没有管理。判断交付是否在向产品演进我一般看这几个指标。指标含义健康值参考复用率新项目中直接复用平台能力的比例逐项目上升交付周期从启动到上线的天数相似项目逐次缩短平台能力新增数每个项目反哺到平台的通用能力数量稳定大于 0定制代码占比项目中客户特有代码的比例逐项目下降二次交付成本同客户新场景的交付成本明显低于首次这几个指标里我最看重的是复用率和定制代码占比。复用率上不去说明平台能力不够定制代码占比下不来说明抽象没做到位。两个指标一起看基本能判断团队是在做项目还是在做产品。5.4 团队能力结构的调整最后说个容易被忽略的点FDE 模式对团队能力结构的要求和传统交付完全不同。传统交付团队是金字塔结构大量初级工程师做执行少量高级工程师做设计。FDE 模式需要的是纺锤形结构中间层要厚——需要大量既懂业务又懂工程、能独立面对客户、能抽象建模的 FDE。初级工程师在 FDE 模式里价值有限因为交付的核心不是写代码量而是建模质量和抽象能力。这意味着招聘和培养策略都要变。招人时不能只看编码能力要看业务理解力和抽象思维。培养时不能只做技术培训要让工程师真正下到业务现场理解业务怎么运转。这一点做起来慢但一旦成型团队的交付效率和产品化能力会有质的变化。我自己带团队的经验是一个成熟的 FDE 至少需要经历三到五个完整项目才能形成稳定的建模直觉。急不来但值得投入。因为最终决定交付能不能变成产品的不是工具多先进而是有没有一批能把业务语义抽象出来的人。工具会迭代模型会升级但这种抽象能力是真正的护城河。