OKFDE｜认识 Palantir，企业本体怎样接上真实业务（上）【Teardown001】
OKFDE 首篇公司拆解【Teardown系列】，从 Palantir 的产品与企业本体讲起，看看前线部署工程师（FDE）怎样把数据和 AI 接进真实业务。模型能给建议，订单谁来改、出错谁来管？沿着这些问题，拆开它的解法与交付方式。
OKFDE TEARDOWN· COMPANIES #001 · Palantir 研究系列第一期
大家好，依然是 Zoe，在 OKFDE 负责产业公司与研报。
OKFDE 首篇公司拆解【Teardown系列】，从 Palantir 的产品与企业本体讲起，看看前线部署工程师（FDE）怎样把数据和 AI 接进真实业务。模型能给建议，订单谁来改、出错谁来管？沿着这些问题，拆开它的解法与交付方式。
一家企业已经买了 ERP，建了数据平台，现在又接上了大模型。为什么处理一张有问题的订单，仍然要找几个部门确认？
这个问题很适合用来认识 Palantir。
模型可以解释订单为什么可能延期，可以写出一份措辞周到的处理建议。接下来，谁有权调整库存，哪个系统里的数量可信，操作失败后要不要再提交一次，都需要确定的安排。建议写得越流畅，这些问题有时越容易被忽略。毕竟，文章读起来很像事情已经办完了。
Palantir 的产品与交付方式，围绕的就是数据如何参与实际业务。
我对照了公司的年度报告、产品文档和招聘说明，希望把这件事讲到具体工作上。公开资料能够解释产品机制与岗位职责，却无法还原每个项目的驻场人数、客户配置和实施成本。下面使用的订单场景是技术示意，帮助理解这些机制，不对应某家客户的真实项目。
01 / 公司与产品 PRODUCTS
一家公司，几组容易混淆的名字
Palantir 成立于 2003 年。公司在 2008 年推出 Gotham，早期服务情报领域客户；2016 年推出 Foundry，处理大型企业面对的数据与业务问题。2023 年，公司开始部署 AIP，将生成式 AI 接入已有平台。
这条时间线值得记住。它在大模型热潮之前，已经做了多年数据整合和业务应用。研究早期案例时，也不能把后来出现的 AI 能力一起算进去。
先把几组名字分清，后面就容易读了。
Gotham | 面向情报、防务等任务，支持数据分析与行动决策。 |
Foundry | 整合数据，建立业务模型，并开发分析和操作应用。 |
Apollo | 管理软件在不同环境中的部署、更新与配置。 |
AIP | 将大模型等 AI 能力接入数据与业务流程。 |
它们之间有配合关系。Foundry 为业务应用提供数据和工具，AIP 在此基础上加入模型能力；Apollo 处理软件怎样交付到云端、客户本地等环境并持续更新的问题。
产品名字听上去颇有气势，工作内容却很实际。软件放在哪里，谁能访问，版本怎样更新，出了问题怎样恢复。企业软件的许多难处，就在这些不太适合放进宣传片的工作里。
本文主要讨论 Foundry、AIP，以及把它们接到客户现场的人。
02 / 数据与业务 DATA
数据接进来了，业务还要继续往前走
Foundry 提供数据连接与处理工具。团队可以接入数据源，建立处理管道，再安排更新和质量检查。
但接通接口，并不会自动解决业务定义。
以订单为例。销售系统关注客户承诺，仓储系统记录库存状态，财务系统还可能要求检查信用条件。这些信息都与发货有关，使用者需要知道它们怎样影响同一张订单。
数据库能够保存每条记录。企业还要定义，一张订单怎样关联客户，哪些库存可以用于履约，以及当前状态允许什么操作。
Palantir 用 Ontology，也就是企业业务本体，组织这些业务含义和操作规则。它建立在已经接入的数据、模型等资源之上，将它们映射为业务对象，并与应用结合。
这里最费时间的工作，往往是把定义说清楚。
所谓可用库存，是否包含已预留的数量？客户变更交货日期后，旧承诺还算不算有效？这些问题没有天然统一的答案，需要企业指定规则和负责人。
软件可以记住决定。至于哪位负责人愿意作出决定，软件暂时还得等人开会。
03 / 企业本体 ONTOLOGY
从一张订单理解企业本体
先看对象。
在本体中，订单可以是一类对象，每张订单有识别标记，并包含客户、数量和交货日期等属性。客户和库存也可以各自成为对象，应用围绕这些对象读取信息、展示状态。
对象的价值，来自企业愿意让它承担一个明确的业务含义。定义得含糊，界面做得再漂亮，使用者仍然要去原系统查第二遍。
接着是对象之间的关系。
订单关联哪个客户，需要什么物料，哪些库存记录与履约有关，这些关系让使用者能够沿着业务问题继续查看。关系存在以后，团队还要处理来源差异与更新频率。昨天同步的库存，在今天的发货操作中还能不能采用，要由具体方案回答。
然后才轮到动作。
Foundry 的动作类型允许使用者按照规则创建、修改或删除对象及其关系。它可以由平台应用触发，也可以通过接口调用。
沿用订单示意，团队可以定义一个调整承诺日期的动作，规定输入参数，以及允许修改哪些信息。动作提交时，还可以检查权限和其他条件。
这使业务操作有了明确入口。使用者能够看见自己在提交什么，系统能够按配置检查是否允许提交。
不过，本体里的状态改变与客户原有系统的状态改变，必须分别确认。把这两件事混在一起，是企业 AI 演示里很容易被忽略的一步。
04 / 外部写回 WRITEBACK
按钮显示成功，订单真的改了吗
Palantir 的文档对外部调用有一段很值得细读。
当动作配置为写回调用时，外部请求先执行；请求失败，后续本体修改不会继续。但外部请求成功以后，本体修改仍然可能失败。另一种附带效果的调用发生在本体修改之后，使用者可能先看到成功提示，外部调用随后才执行。
这意味着，一次成功提示需要有准确的解释。
它可能表示平台里的对象已经更新，却还不能证明客户 ERP 已经完成同一项修改。具体行为取决于采用哪种调用方式，以及客户系统怎样处理请求。
再考虑一个明确标注的故障示意。目标系统已经处理请求，网络却没有把结果传回来。调用方看到超时，此时直接重试，就需要先回答目标系统会不会重复处理。
处理这个问题，通常要设计请求识别、状态查询或后续核对机制，选择哪种方法则取决于接口能力。平台提供的调用工具不能替项目团队作出全部决定。
因此，采购时要追问失败路径。哪些状态可以查明，哪些情况必须由人确认，恢复操作会不会再次产生业务效果，都应该进入验收。
最顺利的一次演示，只能证明最顺利的那一次。企业付钱之后，还得过那些网络不太配合的日子。
05 / 模型接入 AIP
AI 接进来以后，怎样安排它的工作
AIP 提供模型接入、工作流与 Agent 开发工具，也包括评估模型表现的能力。它支持将这些能力接入 Ontology 和应用环境，具体功能的可用性可能因客户而异。
这给订单流程增加了一些可能。
模型可以参与理解非结构化内容，生成分析或处理建议。团队再根据业务风险，决定哪些结果只供人参考，哪些可以进入后续操作。
权限与审批需要具体配置。不能一概宣称模型永远只提出建议，也不能因为接上 Agent，就认为它获得了任意操作业务系统的权限。设计方案要说明模型可以使用哪些信息、调用哪些工具，何时需要人工确认。
模型评估也得进入这项工作。
如果某个流程要求模型识别客户邮件中的日期变更，就应准备代表实际任务的测试材料，检查它对含糊表达或缺失信息怎样处理。识别结果会影响业务操作时，还需要规定无法确定的内容怎样交给人。
这是根据产品机制提出的实施建议，不能冒充 Palantir 每个客户项目都采用的固定步骤。
企业需要根据风险选择自动化范围。生成一段内部摘要，与修改一笔真实交易，错误发生后的代价差得很远。二者用上同一个模型，也不会因此拥有同一套验收条件。
06 / 前线交付 FDE
FDE 到客户现场，具体负责什么
产品机制解释到这里，还有大量工作需要有人完成。
Palantir 对前线部署工程师的公开岗位说明，包括与客户一起理解问题、参与架构设计，并开发客户所需的应用和生产方案。有的岗位也明确包含出差与现场工作要求。
这个岗位强调对客户结果负责。它要求工程人员理解业务现场，又能实际构建软件。工作可能从一个开放的问题开始，团队需要把它缩小到可以实施的范围。
Palantir 同时设置 Deployment Strategist，也就是部署策略岗位，其职责涉及理解业务流程、探索数据，并推动方案被使用。
所以，不必把所有能力都写成一个工程师的个人绝技。项目需要技术工作，也需要业务沟通和客户参与。角色怎样组合，要看任务，公开资料无法支持一个适用于全部客户的固定小组人数。
客户自身也得承担工作。
企业需要安排业务负责人确认规则，授权相关数据访问，并让 IT 团队参与接口与维护设计。厂商可以帮助发现口径冲突，却不能替客户决定哪一个部门拥有最终确认权。
如果客户提供的唯一资源，是一位负责转发消息的项目联系人，工程师即使很能干，也得花时间找真正能作决定的人。会议纪要可以写得很完整，权限仍然不会自己批下来。
FDE 模式把工程力量放得更靠近这些问题。它的效果取决于团队能力，也取决于客户是否给了足够的参与条件。
07 / 实施与上线 DELIVERY
从产品能力到上线，工作怎样接起来
根据前面的机制，可以归纳一条实施顺序。它用于理解这类项目，不代表 Palantir 的统一交付规范。
项目首先需要缩小范围。
对订单流程，可以先选一种异常处理，而非承诺一次改造全公司。明确由谁使用、影响什么业务，以及怎样判断改善，才有条件讨论接哪些数据和开发哪些功能。
随后确认来源与定义。
哪个系统提供订单状态，信息多久更新一次，使用者发现错误后找谁处理，都要有安排。对象建好以后，需要用实际记录检查关系是否正确，尤其关注例外和缺失信息。
应用开发再把这些内容交给使用者。
业务人员需要看见与任务有关的信息，并按权限提交操作。界面设计也应交代数据更新时间和处理状态，避免使用者对系统的确定性产生过高预期。
生产上线前，还要测试异常并安排接管。
接口超时怎么处理，规则修改由谁审核，系统升级以后怎样验证，属于长期运维工作。Apollo 能帮助管理软件交付与更新，但客户专属业务规则仍然需要责任人。
这几步讲起来像一张简洁的流程图，执行时可能来回修改。看见真实数据以后，团队可能需要调整对象定义；业务人员开始使用以后，也可能发现原先遗漏的条件。
范围清楚的试点有助于让这些问题尽早出现。企业可以用较小的投入，观察产品能力怎样与自身条件配合。
08 / 现场与产品 PRODUCT
现场经验怎样回到产品里
对企业服务团队来说，还有一个值得研究的问题。
客户专属开发多了以后，公司怎样继续维护共同的平台？
Palantir 在架构文档中，将前线部署工程视为平台持续发展的方法。其面向早期人才的介绍，也区分了产品工程与前线工程的关注范围，前者围绕能够服务多个客户的能力，后者组合能力解决某个客户的问题。
这些材料支持现场工作与产品研发之间存在联系。但具体哪段代码能够复用、怎样审核并入平台，仍需要更直接的资料。不能将它写成项目结束后所有通用代码都会自动回流的制度。
我的判断是，值得学习的部分在于有人负责这项取舍。
客户专属规则可以保留在项目里；反复出现的技术需求，则值得评估能否做成共同能力。共同能力也需要维护和支持，复用不会在复制代码的那一刻完成。
传统实施团队同样可能建立这种机制。评价一家公司时，应该检查它实际复用了什么，以及下一次交付少做了哪些工作。把岗位名称改成 FDE，不会直接减少接口调试的时间。
这笔投入怎样回收，我们留到第三期结合财务材料讨论。
EXECUTIVE MEMO / 李总的管理备忘录
李总的立项备忘录
如果我准备采购这样的方案，会先把业务问题写具体。
谁每天遇到这个问题，现有处理方式花了多少时间，错误造成什么影响，至少要能核实。大到全公司智能化的目标，很难直接用来验收一份合同。
我也会先确认自己能够提供什么。
业务负责人需要愿意作决定，IT 团队要有时间参与。数据授权若迟迟无法落实，项目计划再漂亮，也只能等。
供应商拿出方案以后，我希望看一次有异常的演示。目标系统没有明确返回结果时，操作人员能不能知道接下来该做什么；查不清的情况，是否能够停止自动处理并交给人。
试点结束前，再让自有团队维护一次。修改一条规则，核实一次异常，看看文档是否足够，哪些步骤仍然必须依赖厂商。持续依赖可以付费购买，费用和责任都应提前讲清。
这些材料准备好，再批准更大的范围。让一个真实流程先跑稳，企业才有依据决定下一笔钱花在哪里。
NEXT / 下一篇
下一期将围绕空客与 Skywise 的公开合作资料，追踪项目从内部业务走向航空公司的过程，分别检查平台覆盖、业务成果和客户投入。
关于 OKFDE
我们关注 FDE，更关注 AI 真正落地之后发生的真实事件。
如果你也关注AI，关注产业，欢迎建联。
微信：okai-leo
公众号：OKFDE-AI不止Demo
参考材料 / REFERENCES
1. Palantir 年度报告及官方产品介绍。
2. Palantir Foundry 文档，涉及企业本体、动作机制与外部写入。
3. Palantir AIP 文档，涉及模型接入、工作流与评估。
4. Palantir 官方招聘与职业介绍，涉及 FDE 和部署策略岗位。
⬆Zoe：梳理对大公司的拆解，其实一点都不简单。
大量资料需要核实阅读 (ง・̀_・́)ง