一、100亿美元，军方究竟准备买什么？
谈起美国军工企业，许多人首先想到战斗机、航母和导弹。Palantir的核心交付物则是软件：连接数据、组织信息、帮助人们分析问题，并把分析结果带进日常工作。
这类软件能值多少钱？
2025年7月31日，美国陆军宣布与Palantir达成企业级协议，最长期限10年，潜在采购上限100亿美元。陆军同时说明，协议整合了75份合同，包括15份主合同及60份相关合同。
陆军公告写得很清楚：100亿美元代表最高潜在合同价值，不代表已经作出的具体资金义务或采购承诺。
这是一项允许按需采购的协议，实际花多少钱，要继续看具体订单与资金安排。
比金额更值得留意的，是整合合同这件事。多个项目已经与同一家软件供应商发生联系，采购方开始把它们纳入共同框架。软件逐渐成为组织持续运行的一部分，购买方式也随之变化。
但一个疑问仍然存在：美国军方拥有大量数据库、信息系统、专业承包商，为什么还需要Palantir？它究竟补上了哪一块？
可以先想象一个很普通的问题：一台装备明天能否按计划投入使用？答案可能藏在装备台账、维修系统、备件库存和任务安排里。每个系统都有记录，工作人员却仍要打电话、查表格、核对更新时间。
信息已经存在，组织获得答案的过程依然很慢。
Palantir长期面对的，正是这一类问题。理解它，可以沿着一条线往下看：分散数据怎样成为可信的业务对象，业务对象怎样进入分析与协作，AI又怎样在权限和责任边界内参与。
二、为什么它会从情报领域起步？
Palantir成立于2003年。其2025年年报将早期业务描述为：为美国情报界开发软件，辅助反恐调查与行动，随后把业务扩展到面临相似数据难题的商业机构。
公司的共同创始人包括Peter Thiel、Alex Karp和Stephen Cohen。不过，理解技术路线，比记住创始人的履历更有帮助。
一份调查报告里出现的名字，可能与另一份记录中的缩写指向同一个人；一处地点可能有多种拼写；两条看似独立的信息，可能实际来自同一份原始材料。分析人员需要在大量碎片之间建立联系，同时判断来源是否可靠、证据是否独立。
这与早期互联网支付反欺诈有相通之处。In-Q-Tel自己的回顾称，它在2005年首次投资Palantir，并提到这套思路与PayPal利用人类分析人员配合数据识别欺诈的经验有关。
In-Q-Tel是CIA于1999年设立的独立非营利战略投资机构，机构性质可以在其官方介绍中核验。
投资关系、机构背景和客户关系分别说明不同问题。它们能解释Palantir接触早期需求的路径，不能直接证明某项算法拥有特殊能力，更不能据此把公司等同于情报机构本身。
早期需求留下了几项长期特征：数据形态复杂，关联关系重要，权限必须细分，分析结果要能够回到证据。Gotham就在国防、情报等应用中形成自己的侧重点。
当公司进入制造、能源和大型企业时，问题换了一副面孔。采购订单、生产批次、设备故障和交付计划同样分散在不同系统。分析对象发生变化，数据整合、对象关联与协作的工程难题却有许多相似之处。
Foundry因此逐步成为商业领域的重要平台。公司上市披露文件记载，空客在2016年已采用Foundry作为核心数据平台。
部署规模扩大，又带来版本更新和运行环境管理问题，Apollo承担相应的软件交付职责。到2023年，Palantir宣布AIP，把大语言模型与既有平台结合，产品路线进一步延伸到生成式AI。
图1｜从情报分析到数据与AI平台。2016年标注空客采用Foundry，2026年标注TITAN进入生产阶段；均为公开事件，非全部产品的发布日期。
用财务规模校准印象也有必要。2025年全年，Palantir营收约45亿美元，政府业务占54%，商业业务占46%；截至该年末，按公司披露口径有954个客户。
政府客户包含多个国家和不同机构，政府收入不能全部理解成美军收入。
三、数据已经很多，为什么还看不清一台装备？
下面使用一个通用装备保障场景。它用于解释系统工程问题，不对应任何单位的真实内部流程。
假设一台地面设备的运行记录显示“发生告警”，维修系统里写着“故障已处理”，库存系统却显示更换部件尚未出库。任务安排仍按原计划执行。四条记录单独看都能解释，放在一起却产生了疑问。
可能是维修人员使用了现场备用件；可能是工单先关闭、出库记录后补；也可能确实存在未解决故障。软件首先要帮助人们找到差异与依据，不能看到“工单完成”就自动推导出“设备可用”。
困难从对象身份开始。装备台账使用资产编号，维修系统使用机身序列号，任务系统只记录简称。连接数据库之前，需要回答：这些记录是否属于同一台设备？编号发生变更时，历史记录怎样继承？存在不确定关联时，谁来确认？
第二个困难是含义。一个系统中的“可用”指能通电，另一个系统中的“可用”指完成规定检验，还有一个系统把它理解为人员、备件与任务条件同时满足。字段名称相同，业务标准可能完全不同。
如果不先统一口径，把三张表合成一张表，只会把矛盾搬到同一块屏幕上。
来源之间还可能存在重复。两份报告如果都转述同一个人的判断，就不能当成两次独立确认。数据整合需要保留原始出处和处理过程，让使用者知道结论经过了哪些转换。
遇到相互冲突的记录时，系统可以把冲突展示出来，交由有职责的人核实；直接抹平差异，可能同时抹掉最有价值的线索。
第三个困难是时间。传感器记录可能持续刷新，人工工单可能当天补录，仓库盘点可能更慢。昨天确认的状态与几分钟前出现的异常，不能作为同一时刻的事实直接拼接。一个可靠的视图，需要让人看见记录时间、更新时间与过期状态。
第四个困难来自组织边界。维修人员可以读取故障记录，未必有权查看完整任务安排；库存管理员能修改出库状态，未必有权批准设备恢复使用。信息汇聚以后，原有权限仍然需要执行。
数据融合的目标，是在授权范围内建立可以解释、可以追溯的共同认知。
图2｜分散记录经过标识匹配、质量检查和权限约束，围绕同一装备组织起来。技术概念示意，不表示所有原始数据都必须集中复制。
把上述问题处理好，装备就不再只是表格中的一行文字。它可以关联自己的运行事件、维护工单、所需备件和负责人员。管理者发现异常时，能够继续追问：是哪项记录改变了判断，哪项资源存在缺口，下一步需要谁处理？
这也解释了“分析”与“工作流程”的距离。图表可以显示某类备件短缺，但完成保障还需要确认需求、安排调拨、修改工单并等待回执。每一步都有不同责任人，可能还要访问不同业务系统。
现实中，有些系统适合实时连接，有些只能定时同步，有些保留在独立环境中。统一数据组织可以包含复制、查询、映射等多种方式。具体采用哪一种，取决于网络、成本、数据敏感性和业务时效。
Palantir所售卖的价值，很大一部分就在这些细碎的连接、解释和协作工作中。它们不容易成为宣传视频的主角，却直接影响软件进入实际组织后能否长期使用。
四、四个产品，分别解决哪一层问题？
Gotham、Foundry、Apollo、AIP经常同时出现。记忆它们，可以先按工作职责分开，再理解共同架构。
Gotham：让分析人员沿着证据建立联系
Gotham长期面向国防、情报和政府相关需求。它关注多源信息组织、对象关联、空间与时间分析，以及围绕分析结果开展协作。
例如，一份公开报告描述某台设备在某地出现，一组记录提供相关时间信息。分析人员需要把对象、地点、事件与来源放在同一个分析环境中，检查它们是否支持某个判断。这类工作强调“这条关系从哪里来”和“结论是否能追溯”。
关系图里的一根线，可能代表共同出现在一份报告，也可能代表经过核实的组织隶属。两种含义相差很远。好的应用需要把关系类型与证据状态表达出来，使用者也要防止把“有关联”当成“已经证明”。
Palantir的公开资料可以确认Gotham的产品定位与安全控制方向；某个具体部署采用哪些数据、功能和审批规则，仍取决于客户配置。图中的分析场景仅用于解释通用机制。
Foundry：把数据加工成能持续使用的业务系统
Foundry负责的范围包括数据接入、处理、管理、业务模型和应用开发。它要让组织能持续维护数据逻辑，而非每次提问都临时拼出一张表。
以制造场景类比：某个部件交付延迟，采购系统知道供应商，制造系统知道受影响批次，排程系统知道计划。Foundry一类平台把这些信息组织起来后，业务人员可以围绕订单、设备、工序等对象查询和协作。
工程师还要管理数据处理过程。上游字段改名，会影响哪些应用？某项指标的计算方式调整后，历史结果是否还可比较？数据处理失败时，界面能否明确提示信息已经过期？这些问题决定平台能否承受真实业务的变化。
Foundry面向商业企业，也能支持政府组织的数据运营。Gotham与Foundry的区别主要体现业务侧重点与应用组合，不能简单按“军用版”和“民用版”划出两套互不相干的技术。
Apollo：让软件在不同环境里持续运行
一套平台开发完成后，还要部署、更新、配置和监控。云端、本地机房与边缘设备的计算资源、联网条件和变更窗口往往不同。
Apollo负责协调持续交付。可以把它理解成管理软件版本与运行环境的一套工程体系：哪个环境运行什么版本，何时允许更新，更新前需要满足什么条件，出现异常怎样暂停推进。
它处理软件交付问题。至于每个客户采用怎样的网络隔离、审批程序和现场操作，不能仅凭产品名称推断。
AIP：让模型接触业务上下文与受控工具
AIP的全称是Artificial Intelligence Platform。它让大语言模型等AI能力进入组织已有的数据、对象与工作流程，并提供开发、评估和治理工具。
通用模型能够解释“轴承异常可能有哪些原因”，但它天然不知道某台设备最近维修过什么，也不知道当前登录者是否有权查看工单。把模型用于实际工作，需要补上数据上下文、工具接口、访问控制和结果验证。
AIP的价值可以在这层连接上理解。组织选择适合的模型，给它限定的数据与工具，再规定哪些输出只是建议、哪些操作必须审核。模型能力和组织规则都要经过验证，接入平台本身不能保证答案正确。
图3｜依据当前官方架构整理：Foundry、AIP、Apollo协同，Gotham核心应用接入共同架构，Ontology组织业务语义与动作。产品之间无固定先后流水线。
当前官方架构文档有一项容易被旧图解忽略的信息：标准架构由AIP、Foundry和Apollo构成，Gotham的核心多模态应用与工具也已整合进来，并使用Foundry管理的Ontology。
因此，年报中的“四大主要平台”和架构文档中的“三个平台组成标准架构”可以同时成立。前者是在介绍产品，后者是在解释技术组织方式。理解两者的层次，才能避免把产品名字画成四个互相隔离的盒子。
Ontology位于这套解释的中心。它把对象、关系、逻辑、动作和相关规则组织成可以被应用与AI使用的业务模型。后文会用一张维修工单把这个概念展开。
图4｜数据来源、对象关系、事件时间与人工核验共同支持分析。虚线表达待核实关系；这是原创技术概念图，并非Gotham真实界面截图。
与传统军工企业相比，Palantir以数据平台和软件能力为业务中心；与只负责存储和查询的数据库相比，它覆盖更多业务建模与应用流程；
与以训练通用大模型为主要方向的公司相比，它强调把多种模型放进组织的实际工作。几类企业的业务都可能延伸和重叠，这些区别适合帮助理解，不能当成绝对行业边界。
五、三个公开项目，看见三种不同需求
Army Vantage：组织需要一份能够共同使用的数据视图
Army Vantage是观察Palantir国防业务的好入口，因为它把视线带到了人员、资源和管理这些日常问题上。
美国陆军CIO页面将Vantage描述为数据驱动的运行与决策平台，整合大量数据，并为人员战备、财务等工作提供分析工具。
页面称，陆军中包括士兵、工作人员、分析人员和高级领导在内的数千名使用者在用这一平台，并记载项目于2025年5月转入CIO办公室管理。
这些是采购方对平台定位与使用范围的公开说明。供应商关于节省时间、提高效率的宣传数字，还需要对应统计口径、比较基线和独立证据；本文不据此推算整体战斗力提升。
回到装备保障的通用例子：管理人员先找到待维护装备，再查看未关闭工单、所需备件和维修资源。如果某类故障集中出现，可以继续检查批次、使用环境与维修历史。
这里形成的价值有两层。一层是减少重复查询，让相关信息进入同一工作视野；另一层是让问题能够被分配、跟踪和复核。某个部门确认数据有误后，其他应用也应能看到修正后的状态，减少各自保留一份“最新表格”的混乱。
但平台上存在一张总览图，并不意味着原有系统已经被替代。台账、仓储和维修系统仍可能分别负责自己的业务交易。分析平台通过集成建立连接，源系统继续承担原本的责任。具体写回哪些信息，需要相应接口和授权。
图5｜以通用车辆维护场景解释Vantage类组织数据分析：关联台账、工单与库存，辅助安排维护资源。画面不代表该项目的真实内部流程。
TITAN：软件公司进入复杂系统集成的中心
TITAN是Tactical Intelligence Targeting Access Node的缩写，可译为“战术情报目标定位接入节点”。
美国陆军将其描述为利用AI与机器学习处理多来源传感器数据的下一代情报、监视与侦察地面站，服务于态势理解和目标相关情报支持。
公开定位已经足够说明工程难点：来自不同平台的信息，必须经过处理和组织，才能供使用者理解。数据接入、计算软件、现场硬件和操作环境都需要协同。本文讨论这层系统工程关系，不展开具体作战流程。
这里有两组经常混淆的数字。
2024年3月的陆军公告公布，Palantir获授价值1.784亿美元的原型阶段协议，覆盖10套原型系统，包括5套Advanced和5套Basic，以及相关技术集成。
2026年9月1日的公告则宣布项目进入生产阶段：截至8月31日，两笔交付订单合计1.92亿美元，其中Palantir为1.27亿美元，Anduril为6500万美元。
订单覆盖8套初始生产系统，两种型号各4套，计划在随后18个月交付。
同一公告另称，陆军当时保有9套用于实际使用的原型系统。2024年的“10套开发交付范围”、2026年的“9套保有原型”和“8套初始生产系统”描述不同口径；
不能把它们合并成同一批交付，也不能把1.92亿美元全算到Palantir一家头上。
公告明确，Palantir牵头总体生产，Anduril负责关键硬件与方舱集成，其他合作方提供相应能力。由此能够得出的判断是：软件企业在这一项目里承担了重要的系统集成职责。
进一步的分析是，复杂系统的工作效果越来越取决于软硬件之间的连接是否可靠。单个设备性能再好，如果信息无法对齐、版本无法协同，系统就难以稳定运转。
这解释了为什么一家以软件为核心的公司会处在项目中心，也说明它仍需要硬件和工程伙伴。
图6｜依据TITAN公开定位制作的能力概念示意。通用车辆仅表达地面承载环境，不是实车复原；不展示未公开内部结构、接口或性能参数。
Maven Smart System：识别算法之后，还有大量分析工作
Project Maven与Maven Smart System需要分开理解。
美国国防部2017年的公开报道介绍，Project Maven起步时聚焦计算机视觉，用机器学习辅助处理大量影像信息。这是一个更广的项目背景，不能直接等同于Palantir后来的某份合同。
针对Maven Smart System，国防部在2024年5月29日合同公告中披露，Palantir获得4.8亿美元的原型系统合同，工作地点和资金按具体订单确定。
随后，2025年5月21日公告列出对同一合同的7.95亿美元修改，内容为Maven Smart System软件许可。金额属于合同授予或修改口径，不能直接当作已经支付的现金。
后续进展也体现了组织实施的分量。美国海军陆战队2026年8月28日的官方通报介绍，当月Maven专题会议讨论了数据治理、训练、保障和推广框架，并为2027年实施计划提供输入。
公开活动能说明相关整合工作正在推进，尚不足以据此评价所有场景的实际效果。
为什么识别算法之外，还需要系统？可以做一个与实装能力无关的通用推演：模型从大量影像中标出某类对象，分析人员还要知道影像时间、数据来源、重复记录，以及结果是否存在矛盾。
经过复核的信息，还要进入协作、报告或其他授权流程。
单个模型主要回答局部识别问题，分析系统还要处理上下文、证据组织和任务交接。模型输出“疑似某对象”，距离工作人员形成经过核验的判断，中间仍有一段不能省略的工作。
合同可以证明采购关系和采购事项，不能单凭合同金额证明某种战场效果。平台的宣传演示同样不能代替针对真实使用条件的评估。
把三个项目并排看，区别就很清楚：Vantage展示组织数据整合与分析，TITAN展示软件牵引的复杂系统集成，Maven Smart System展示AI相关分析平台的采购与应用方向。
它们涉及的用户、合同和实施条件各有不同。
六、真正连接这一切的，是业务对象与受控动作
Ontology：给数据一个共同的业务含义
Ontology通常译为“本体”。在Palantir的产品语境中，读者可以先把它理解为一套业务对象及其运行规则的模型。官方文档将其放在数字资源与现实对象之间，组织数据、逻辑和行动。
继续看那台待维修设备。数据库里可能有许多记录，Ontology把它们映射到“装备”对象上，赋予资产标识、所属单位、当前状态等属性。维修工单是另一种对象，备件也是。
对象之间通过明确的关系连接：某张工单针对某台装备，某项维修需要某个部件。
“关系”必须能够用一句话说清。两台设备同处一个仓库，与两台设备使用相同部件，对分析的意义不同。画出相连的圆点只是表现形式，真正有价值的是关系语义与背后的可靠记录。
模型还需要描述状态如何变化。工单从待受理变为处理中，再到待复核，每次变化都应有触发条件与责任人。“关闭工单”则是一种动作，需要检查操作者权限及业务规则。
这里有个关键区别：读取信息与改变业务状态，对系统提出的要求不同。读错一条记录会影响理解，错误关闭工单还可能影响后续安排。动作接口必须验证参数和权限，保留失败原因，防止重复提交造成重复业务操作。
这些是通用工程要求。在某个具体部署中，需要实施团队结合平台能力逐项落地。只画好对象关系图，还不能算完成了业务建模。
同样，完成建模以后也要持续维护。一个单位调整职责，某项审批可能随之转移；装备更换部件，适用的维护规则也可能变化。对象模型需要跟着现实更新，并保留历史状态，才能解释过去为什么作出某项决定。
否则，统一模型也会逐渐变成另一份无人维护的旧台账。
图7｜装备、工单、备件和人员通过明确业务关系连接；权限验证后的动作改变对象状态。通用维护模型，不对应真实军事组织。
Ontology也不等同于三维模型。给舰艇建立一个漂亮外形，仍然无法回答哪张工单未关闭、哪个部件正在等待。
它与数据库、知识图谱、数字孪生之间的关系，可以从各自解决的问题继续比较：数据存放在哪里、关系怎样表达、状态如何演变、动作怎样执行。
对AI来说，业务对象提供了相对稳定的语言。模型可以围绕“这台装备关联的未完成工单”调用工具，减少每次都猜测表名和字段含义的负担。但对象映射如果错误，模型得到的上下文同样会错误。
AIP与智能体：一次维护建议怎样进入实际工作
设想维修人员提出：“整理这台设备近期故障，说明还缺什么信息，并准备一份工单更新建议。”
首先，系统识别提问者身份，按权限取得设备对象、相关工单与知识资料。某些字段不能读取时，模型就不应获得这些字段。权限不足也应明确返回，避免模型用猜测补齐。
接着，模型整理材料，列出可能解释，并标记证据缺口。如果需要查询库存，它通过预先定义的工具接口发出请求；工具层再次校验身份、参数和操作范围。
系统可以把建议及来源交给维修人员复核。获准后，再通过受控动作更新工单。写入成功、被拒绝或者执行失败，都要形成结果回执。若执行失败，界面应显示真实状态，不能让一句自然语言回答冒充实际完成。
最后，保留提问、数据访问、工具调用、审核和执行结果的审计记录。这样，组织才能在出现问题时还原过程。
图8｜AI在授权数据和工具范围内形成建议，人工复核后更新工单，结果回传并留痕。此图为受控维护流程示意，不涉及自动武器操作。
AIP公开文档涵盖智能体与工作流开发、模型连接及治理工具；AIP Evals文档进一步说明评估机制。实际采用时，应测试数据缺失、对象重名、越权请求及工具失败等情况。
评估也要与业务后果对应。概括资料时，可以容忍某些措辞差异；更新对象状态时，就要核对具体对象、字段和动作结果。一个总的“回答正确率”，无法完整反映这两种工作之间的风险差异。
Apollo：更新一次，为什么也需要工程体系？
假设维护应用增加了一个必填字段。开发环境测试通过，并不意味着所有现场环境都可以立刻更新。某处依赖旧版接口，某处正在处理重要业务，还有一处网络暂时中断。
Apollo文档围绕软件、环境与部署管理展开。它协调软件应达到的状态与环境实际状态，让版本和配置的变化按设定规则推进。
可以用通用发布流程理解：软件先完成构建与验证，再向满足条件的环境部署，观察健康状态，随后扩大范围。若出现兼容性问题，则暂停后续推进，并按预先设计的方案处理。
受限网络和离线环境还涉及分发条件与现场管理。持续交付描述的是一套工程能力，不能理解成任何隔离环境都能随时联网，或任何更新都不需要审批。
图9｜软件经过验证与部署协调，分别进入云端、本地机房和边缘环境；各环境保留自己的更新条件。技术概念示意，不展示特定军事网络拓扑。
把业务对象、受控动作与部署管理连起来，才能看到完整问题：分析结果依赖正确数据，动作依赖规则，规则运行又依赖软件版本与环境。每一层都可能出错，因此每一层都需要相应的检查和反馈。
七、持续采购，既有工程原因，也有组织原因
至此，军方为什么愿意持续采购这类软件，已经有了较具体的解释。以下是结合公开产品与合同信息作出的分析。
首先是整合经验的积累。一个新系统接入时，技术团队要理解字段、身份、时间和权限。一个业务模型被使用后，还要应对组织调整、流程变更和数据源升级。长期运行积累的知识，会直接影响下一次修改需要多少时间。
其次是平台贴近真实工作。用户真正关心的，往往是“下一步应该由谁处理”“原始依据在哪里”“这次操作成功了吗”。如果软件能把查询、协作和动作放在连贯的流程里，它就更容易进入日常习惯。
Palantir把深入客户场景的交付方式称为Forward Deployed Engineering，可以理解为前线部署工程，即 FDE，目前 FDE 工程师也是市场稀缺人才。
官方架构介绍描述，工程师与实际使用者靠近协作，将现场反馈带回产品开发。其效果仍应按具体项目评价，组织方式本身不保证每个项目都成功。
用装备保障举例，工程师可能发现用户总在平台外补一张表。原因可能是业务对象少了一种关系，也可能是审批规则与实际工作不匹配。真正解决问题，通常需要同时修改软件与流程。
还有一类持续采购因素来自部署。系统已经完成身份对接、权限配置、接口测试和人员培训，替换供应商就要重新做相当一部分工作。迁移还可能影响正在使用的应用，采购方因此会把连续性纳入决策。
这种关系既能反映产品的使用价值，也可能形成供应商锁定。两种因素可以同时存在，外部观察者通常无法仅凭续约判断各自占比。
持续采购能证明采购方作出了继续使用的选择；要评价选择是否划算，还需要成本、替代方案和实际效果的证据。
2025年陆军整合采购框架，能够减少合同管理的重复工作，并提供统一议价条件，这是公告中的采购逻辑。至于最终是否节省预期成本，仍要看后续执行。
研究一家公司的护城河时，也应把这类组织与采购因素纳入，而非只盯着某个算法名字。
八、软件能把问题连接起来，也会把问题放大
数据质量是最直接的限制。设备编号匹配错误，可能把甲设备的维修记录挂到乙设备；旧状态没有标记过期，可能被当成当前事实。界面越整齐，错误越容易获得不应有的可信度。
实施成本也无法消失。梳理业务口径、配置权限、修改接口、培训人员，都需要时间。组织内部对“谁负责维护这项数据”没有共识时，再强的平台也难以替代管理决策。
AI会增加新的不确定性。模型可能遗漏反例，也可能对不完整材料给出流畅解释。人工审核若退化成机械点击，流程里即使存在“审核”按钮，也不足以形成有效监督。关键在于审核者是否看到证据，是否拥有拒绝与追问的空间。
对敏感数据，技术上能够访问与业务上应该使用之间，还隔着用途、授权和责任。角色权限、日志和加密提供了治理工具，实际保护效果取决于配置、执行、监督及使用边界。企业声称具备安全机制，不能直接推导出所有部署都没有风险。
供应商依赖已经成为公开政策讨论的一部分。英国议会2026年2月10日的记录中，议员质询了Palantir合同的竞争程序、供应商锁定与退出安排；
国防部官员回应称，相关数据保留在英国并由国防部控制，系统变更须经同意。
这里应分别看待质询与回应：前者说明公共争议的焦点，后者代表政府对合同控制措施的说明。它们都不能替代对实际执行效果的独立检查，也不能据此宣称已经发生了未经证实的数据外泄。
对任何采购这类平台的组织，长期需要保留几种能力：理解自己的数据模型，明确业务规则的归属，验证关键流程，管理接口和迁移方案。不同国家和机构还面临各自的法规、数据驻留及部署要求，不能照搬另一个客户的方案。
研究Palantir，既要看到技术把工作连起来的能力，也要追问连接之后由谁解释、谁批准、谁承担后果。
九、从公司名字，走向一张技术地图
读到这里，Palantir可以被理解为一家围绕复杂组织构建数据与软件平台的公司。
Gotham提供具有国防情报侧重点的应用，Foundry组织数据与业务，AIP把模型接入真实工作，Apollo支撑软件持续交付；Ontology让对象、关系与动作拥有共同的表达方式。
Army Vantage、TITAN和Maven Smart System，则让我们看见这些能力进入不同项目时的形态。合同证明商业与采购关系，官方文档说明产品设计，效果评价还需要更多来自运行现场的证据。
这条技术路线值得持续研究，因为它触及一个越来越普遍的问题：当组织希望AI参与工作时，数据、权限、业务规则与软件工程需要怎样共同准备？
答案会落在一项项具体连接和验证上。也正因此，后续文章将继续拆开这张技术地图。
参考资料
资料核验截至2026年10月11日。图中维护流程均为通用科普示例；项目数字采用对应公告日期与口径。
1. Palantir 2025年Form 10-K：公司起源、业务及年度财务口径。 2. Palantir官方架构中心与平台关系文档。 3. 美国陆军企业协议公告，2025-07-31。 4. 美国陆军CIO：Army Vantage。 5. TITAN原型协议，2024-03-06与生产阶段公告，2026-09-01。 6. Maven Smart System合同，2024-05-29与合同修改，2025-05-21；海军陆战队Maven会议通报，2026-08-28。 7. Palantir Ontology文档与Ontology系统架构。 8. AIP文档与AIP Evals文档。 9. Apollo核心概念及部署环境。 10. 英国议会：国防部Palantir合同质询，2026-02-10。
