Palantir：从现场工程到AI FDE

一辆车已经买来，却还不能出租；车已经修好，却不在有订单的门店；门店有人值班，却赶不上实际需求。对租车公司而言，这些都是同一件事：资产还在花钱，却没有及时进入能产生收入的工作。

Hertz在2022年10月19日公布与Palantir的多年合作。客户公告描述，Foundry将租赁状态、服务订单、位置和车辆注册资料关联起来，帮助判断车辆何时可以出租。¹

这个入口比“企业需要一个更聪明的模型”具体得多。Palantir要进入的，是资料分散、动作相互等待、局部安排难以形成共同结果的工作。找到这种约束，再把它变成能持续改变的软件，是理解其实施方法的一条主线。

Palantir也是理解FDE早期形成与传播时不可绕过的公司。名称与工作方式的历史已经区分早期词证、当事人回忆和更早的客户工程；现场问题怎样进入产品解释了组织分工与反馈。这里把问题往前推进：这些经验怎样组成今天的实施体系，又怎样让AI承担其中一部分工程？

每次升级，都在处理前一种方式的限制

把FDE理解成“派出优秀工程师”，只看到第一层。一个人能在陌生环境里找到办法，组织还要让这个办法可靠运行、支持下一位使用者，并减少下一次重复劳动。

先分清三个名字：Foundry承载企业数据与应用，Apollo管理软件部署，AIP是把AI模型接入企业资料、工具和工作流程的平台。后面的AI FDE是平台内的软件产品名称，与真人FDE岗位分开理解。

读这条演进线，可以先抓住四个问题：现场知识怎样留下，软件怎样可靠部署，投入是否值得怎样尽早验证，AI的改动怎样检查。下面的时间表把这些问题与可核对的转折相连；它不是公司的正式版本分期，早期的共同工程也没有随新产品发布而消失。

沿这条线看，变化并非只有模型越来越强。现场认识需要有地方保存，操作需要有可靠工具，修改需要能检查，运行需要能持续。任何一层缺失，都可能让后面的自动化重新遇到前面的困难。

Ontology保存的不只是资料，还包括可以做什么

Ontology可译作本体，在这里表示用业务对象、关系和动作组织工作：一辆车是对象，车辆与服务订单有关系，状态更正或发起处置是动作。Palantir文档将其定位为连接数字资料与真实业务的运行层，同时包含动作、函数和控制。¹¹

这与把各部门文件放进一个问答库不同。问答库可以帮助找到一项维修规定；运行中的对象还要说明具体是哪辆车、它现在是什么状态、谁可以改变，以及变化要回到哪个系统。资料能被检索，是理解工作的一部分；工作能被改变，还需要动作与控制。

以下是解释这一机制的教学情境，不是Hertz已经公开的实现细节。一辆车的维修记录显示完成，注册状态却未确认。业务负责人规定只有两项都满足才可出租。系统就需要把“维修完成”和“可出租”保留为不同状态，而不能让Agent看到前者便自动推断后者。

FDE在这里的价值，是把一句看似简单的业务要求追到可执行条件：哪份记录为准，资料多旧仍能使用，谁裁定缺失，满足条件后怎样改变状态。工程师可以提出表达方式，不能凭平台能力替客户制定安全与经营政策。

一旦对象、动作和条件被正确整理，它们就有机会被不同应用复用。门店安排、车辆调度和维修计划可以围绕同一业务对象协作。但这不是“企业已被完整复制进软件”。新业务、资料迟到和规则变化仍会产生例外；共用一个错误定义，反而可能把错误传播得更远。

因此，本书所说的经验沉淀，不是把所有现场故事都存成文档，而是让下一次建设少猜一项含义、少补一个接口、少依赖一个人的记忆。哪些内容确已减少劳动，需要看下一项工作，不能由平台名称自动证明。

Bootcamp把投入判断提前，正式运行仍要接上

Palantir在2023年10月12日解释AIP Bootcamp：客户围绕真实用例与工程师共同构建，将业务事件通过Ontology接入模型处理，把专家使用反馈带回改进，并学习后续自己建设的办法。其一到五天措辞描述初始用例推进，不是全企业生产上线承诺。¹²

这项安排改变了讨论的顺序。先拿真实资料和一个重要任务动手，客户较早看见哪些条件缺失；工程师也较早知道模型输出是否有用。一个界面展示得漂亮，却无法处理客户实际例外，应当成为缩小范围或停止投入的理由，而不是继续扩大演示。

Bootcamp的价值，需要在结束时落到一个决定。继续前，应说明原型已经覆盖什么、还有哪些运行条件没完成、下一阶段由谁补齐。生产接入、权限确认、异常恢复、使用者培养和长期维护，并不会因为原型出现得快而省略。年报也提示Bootcamp或试用未必转成收入；销售转化、客户采用和经营收益是不同结果。⁵

反过来，若共同动手说明一个标准产品已经足够，就可以减少专门工程。这并不否定Bootcamp。尽早发现更简单的办法，本身就是有用的投入判断。

Hertz：从车辆资料走向规划与排班

回到开头的客户，时间线还能再往下追。2026年5月7日电话会上，Hertz管理层称已推出新的车队规划引擎，将决策优化与Palantir Foundry结合，目标是让车辆在合适时间位于合适地点。材料所述后续运营收益仍有前瞻性质，不能把目标记成已经完成的结果。¹³

到了8月6日，客户进一步说明Palantir支持的劳动规划模型用于使排班与实时需求对齐，并指出车辆召回仍是显著阻碍。¹⁴

三组记录让读者看到能力如何扩展：2022年的基础资料与可租状态，2026年的车队规划，再到需求与人员安排。它们不是一份披露了全部步骤的工程日志；公开材料没有证明三个阶段共用同一套实现，也未说明真人FDE或AI FDE各投入多少。这里采用的是客户可核对的工作变化，不补写实施者的职衔。

这些变化值得研究，是因为资料没有停在一张看板上。知道哪辆车不可用，要影响下一次分配；知道门店需求，要能影响人员安排。若观察只停在预测更准，却不追到谁改变下一步，便看不清实施方的作用。

又该怎样判断这种作用值多少钱？可以按客户材料启发，提出一项实际核验任务：选择一类车辆停租原因，追踪状态何时确认、安排何时改变、何时重新可以出租；同时记录人员投入和错误处置。这个办法是本书建议，不是Hertz已披露的测量程序。它比将全公司收入或利润改善都记给Palantir更有解释力，也能发现等待是否只是从一个部门移到了另一个部门。

车辆召回则划出了软件的能力边界。更好的协调可以帮助安排资源，却不能使尚未安全修复的车辆凭空恢复出租。不能为了利用率目标，让模型的经营建议越过安全条件。一个有效的行动系统，既应推进可以完成的工作，也应让不可越过的限制清楚可见。

制造篇中的Airbus提供另一种早期现场协作背景。本章不重讲其生产案例；Hertz在这里承担的是持续扩展的客户记录，AI FDE接下来承担的是产品机制说明，两者不能拼成“Hertz已由AI FDE自主运营”的故事。

AI FDE怎样把请求变成可以审查的改动

真人FDE是一种工作角色；Palantir的AI FDE是Foundry内能调用工具推进任务的交互式Agent产品。它能借助原生工具进行平台操作，并不因此拥有一位工程师的全部客户关系、判断和责任。

本书2026年10月2日所读产品文档描述的过程是：理解请求与上下文，选择Foundry操作，调用工具，观察结果，再解释所做的工作。它能运行变换或函数预览、查看代码检查，并默认通过分支提案或仓库PR提交修改。¹⁵ “能操作”与“修改可以接受”，仍要分别检查。

这套设计的关键，可以沿一次任务看清。继续前面的教学车辆情境，客户要求“把尚未完成注册确认的车辆挡在可租清单之外”。首先提供相关对象定义、当前规则和经授权的样本；不能只给一句目标，就期待Agent自己猜出所有业务条件。

随后收窄工作。AI FDE的模式为当前任务提供相关文档和工具，例如本体编辑或函数编写；细能力对应具体操作。¹⁶ 本例只需读状态、修改规则和运行检查，就不应同时开放无关的发布、删除或财务操作。这里的范围安排是教学建议，不是对该客户实际配置的描述。

接着在分支中准备改动。至少检查两组输入：维修完成且注册确认的车辆仍可进入清单；维修完成但注册未确认的车辆必须被挡住。若Agent只是把所有车辆排除，后一组可能通过，前一组却会发现它没有完成任务。成功条件必须同时保留正确行为和禁止行为。

4月的更新把评估套件创建、运行、读取失败、修改后重跑接入AI FDE，当时仍有部分评估类型尚未支持。⁸ 这使反馈更容易成为下一步输入，却也带来一个要点：Agent能够修改测试，不代表它可以为了通过而改变验收要求。如何区分修改程序与修改验收条件，见AI参与交付。

7月的依赖图能力又帮助检查当前资源与下游的关联。⁹ 对本例而言，可租清单变化可能影响调度与门店看板；只看一段函数正确，未必够。图能帮助寻找检查位置，未记录的外部流程仍须由现场人员补查。

权限也不是靠Agent自觉遵守。AI FDE使用当前用户的Foundry会话，操作继续接受原有权限检查与审计；没有独立的超级账号。修改需要逐次确认或有边界的会话授权，特性分支和受保护分支的规则不同。¹⁷ 有技术权限仍不等于有业务决定权。拥有编辑权限的人可以生成候选，是否改变出租条件应由有权承担相应责任的人决定；审计记录以用户身份归属，也不能代替判断改动是否正确。

2026年10月12日，Palantir又说明了一项可由管理员配置的数据标记白名单：AIP会检查当前会话可访问的全部强制标记，只要其中有标记不在批准范围内，就会阻止该会话向模型发出请求；这也适用于AI FDE。需要更窄范围的人可在条件允许时切换受限会话。¹⁸ 这是可配置的控制，不应假定每个环境都已启用，也不能代替检查具体任务是否有业务授权。举个教学例子：管理员允许标记A进入模型、不允许标记C；某次会话同时可访问A和C，即使这次请求只用普通资料，仍会因会话能访问C而被挡下。若允许切换到只能访问已批准标记的受限会话，就可以在该范围内继续请求。

这解释了为何AI FDE不是在任何企业数据上都能直接复制的万能工程师。业务对象、工具接口、反馈与权限已经被平台组织，模型才有可操作的工作环境。缺少这些条件时，企业仍需先把条件建起来。

Evolve把一次操作推进到受约束的迭代

AI FDE可以完成一项修改，Evolve进一步组织多个Agent寻找改进候选。使用者先指定目标资源、改进目标、验证方式和限制，再查看修改建议、活动和验证证据；9月8日公告给出了正式可用范围。¹⁰

其概览允许成本、延迟、评估表现或自定目标，并要求有目标资源与验证资料的访问权。文档展示的成本下降是示例，不是具名客户经营结果。¹⁹

假如前面的可租判断中包含一项AI资料核对，客户想更换模型降低成本，就需要把目标写完整：可调整模型与提示，但不能删掉注册确认条件；低置信度仍转人工；正常、资料缺失、互相冲突的请求都要比较。它可以自动探索工程实现，却不应自行决定哪种安全条件现在不重要。

提案有用，正是因为它把“我改好了”展开成几个可检查的问题：由什么改成什么，哪些样本保持一致，出现了哪些差异，收益采用什么成本口径，尚未覆盖什么。减少模型调用费，却使客户复核翻倍，可能不是值得接受的改进。

接受候选以后，还要观察真实运行。评估通过说明所检验条件下符合要求，不能证明以后所有请求都正确。旧规则和恢复办法应当保留；业务资料或权限变化时，重新判断现有方案，而不能一直使用第一次的通过结论。

值得学习的优势，以及必须付出的代价

Palantir值得放在本篇首个公司章，因为它将长期现场工程与平台建设、短周期共同验证、受治理的AI操作接在一起。这是一个有影响的实施范式，不能由此宣布所有公司的FDE都采用相同组织，更不能仅凭厂商文档给出全球领先排名。

值得借鉴的首先是选题方式。找到昂贵的等待和跨部门约束，再决定需要什么技术。其次是沉淀方式：把已经确认的含义、动作和检查变成下一次可用的资产。最后是自动化方式：先让工具能够可靠操作，再让模型借助反馈改进，并把接受决定留在有权负责的位置。这些是本书对前述材料的分析，不是客户合同中的共同保证。

三项优势也各有成本。重要约束往往需要业务负责人持续参与；共同资产需要有人维护定义和版本；更快生成候选可能增加核验负担。不能只计算工程师少写了多少代码，而忽略客户提供资料、确认例外和运行系统的时间。

平台复用还有另一面。对象、动作、应用和控制在同一环境中积累，建设更方便，迁移时也需要逐项恢复这些含义。数据能够导出，不等于业务规则和运行能力已经迁走；与其预先断言锁定程度，不如让实施方与客户一起检验一项具体接手或迁移任务。退出与客户能力提供进一步检查办法。

这家公司的实施也没有止于自有工程师。2025年12月16日的Accenture合作公告明确包括Palantir专属FDE、具备Palantir技能的Accenture人员和Accenture FDE；合作网络扩大不等于每项预期结果已实现。²⁰ 接下来的公司章会观察伙伴怎样承担流程改造、集成和评估。阅读时应继续分清平台能力、具体团队与客户自己的决定。

最有价值的学习，不是要求每家公司复刻Palantir，而是检查自己的交付有没有积累：第二次遇到相近问题时，团队是否少猜了一项含义，客户是否能独立修改一条规则，AI生成的候选是否更容易验证。如果答案仍是否定的，增加驻场人数或Agent数量，都还没有解决复制能力的问题。