Palantir 产品矩阵不是四张产品卡：从 Foundry、Ontology、AIP 到 Apollo 的运营系统解剖

Palantir 很容易被讲成一家“数据平台公司”，也容易被讲成一家“国防 AI 公司”。前一种说法会把 Foundry 近似理解为数据湖仓，把 Ontology 当成语义层，再把 AIP 看成接在上面的聊天框；后一种说法则会让 Gotham 的任务应用遮住其底层数据、逻辑、权限与交付体系。这两种概括都捕捉到一部分事实，却不足以解释 Palantir 为什么同时谈对象、应用、Agent、模型、流程和跨环境部署，更不足以帮助企业判断自己需要其中哪一部分。

研究 Palantir 产品矩阵，第一步不是收集更多产品名称，而是先识别公司在不同语境下展示的是哪一张地图。在面向投资者的法律披露中，Palantir 把 Gotham、Foundry、Apollo 和 AIP 称为四个主要软件平台；在面向企业架构师的官方架构中心里，它又把 AIP、Foundry 和 Apollo 视为跨行业的标准架构；在解释技术内核时，Ontology 被称为整个架构的心脏；在面向行业客户时，页面上还会出现 Warp Speed、医院运营方案、ShipOS、Maven Smart System、AIP Now 与大量 Marketplace 产品。名称没有互相否定，只是分别服务于商业披露、系统设计和场景交付。

这篇文章要做的不是给官网菜单写一份中文说明书，而是回答五个更实际的问题：Palantir 到底把什么作为独立产品出售；四个平台在一条生产链上怎样协同；Ontology 为什么既不是第五个平台，也不是传统知识图谱的同义词；AIP 怎样让模型获得受治理的上下文和动作能力；以及一家企业在什么条件下值得购买整套运营系统，而不是用湖仓、语义层、图数据库、Agent 框架和 GitOps 自己组合。

文章以 2026 年 9 月 14 日仍可访问的资料为时间截面。商业口径以 Palantir 的2025 财年 Form 10-K为主，技术口径以其架构中心和现行产品文档为主。官方资料能够证明产品如何定义自己，却不能单独证明客户一定获得相同结果。因此，文中会把“文档确认的能力”“厂商公开的主张”“基于架构的推断”和“公开资料无法确定的事项”分开。尤其是价格、实际实施强度、客户定制比例和长期退出成本，公开材料不足以给出统一数字，不能用想象补齐。

为了不让研究停在抽象层，本文会一直使用 Amazon Ads 运营系统作为检验场景。这个场景同时具备批量报表、近实时消息、隐私安全分析环境、广告对象层级、预算与竞价动作、归因延迟、商品库存和多账户权限，足以暴露平台矩阵中多数关键责任。它不是 Palantir 官方 Amazon Ads 方案，也不代表使用 Palantir 是该场景的唯一实现；它只是一把架构标尺，用来检查“数据进入、语义绑定、策略计算、人工协作、Agent 决策、动作执行、结果回读和版本发布”能否闭合。

Palantir 真正出售的不是一组彼此独立的功能，而是一条把数据转成受控行动、再把行动结果写回系统的运行链。四个平台只是商业入口，Ontology 是运行时核心，Apollo 则让这条链能够长期存在。

先画三张地图：产品矩阵为什么总被讲错

如果把 Palantir 的所有名称铺在同一层，产品矩阵很快会失去意义。Gotham 是平台，Workshop 是应用构建工具，Ontology 是跨平台运行系统，AIP Logic 是 LLM 工作流工具，Warp Speed 是面向制造业的组合方案，Rubix 是基础设施基底。它们可以同时出现在一张官网图里，却不是同一类别。合理的阅读方式是并排放置三张地图。

图 1：四个平台、三平台标准架构和运营能力栈回答的是不同问题（概念示意）

第一张是商业产品地图。Palantir 在 10-K 中明确列出 Gotham、Foundry、Apollo 和 AIP 四个主要软件平台。这张图回答“客户和资本市场如何识别公司的主要产品”。Gotham 起源于政府、国防和情报任务；Foundry 面向商业及政府组织的数据运营；Apollo 管理软件在复杂环境中的交付和运行；AIP 把生成式 AI 模型接入组织数据与运营。四者有清晰品牌，但商业合同是否拆分、各客户获得哪些模块、服务与平台费用怎样构成，仍要以具体报价和合同为准。

第二张是技术架构地图。Palantir 当前的标准架构说明使用 AIP、Foundry 和 Apollo 三个平台：Foundry 提供 Data Operations，AIP 提供 Generative AI，Apollo 负责持续交付并支撑前两者。AIP 与 Foundry 不是两套隔离系统，而是在共享服务网格中共同运行；Rubix 为这些服务提供一致的 Kubernetes 基底。Gotham 及防务应用已经与这套标准架构集成，因而不需要在每张底层技术图里都作为第四列重复出现。

第三张是运营能力地图。它从业务闭环而不是品牌名出发：数据服务负责连接、转换、虚拟化、存储与健康；逻辑服务承载规则、模型、优化器和 LLM；工作流服务承载分析、应用、自动化和交互计算；Ontology 以 Language、Engine、Toolchain 把数据、逻辑、动作和安全组织成同一个可操作世界；Apollo 负责把这一世界所依赖的软件和配置持续送到目标环境。对使用者而言，这张图最有价值，因为它能把“某个业务能力缺什么”映射到具体责任，而不是直接跳到购买某个品牌。

以 Amazon Ads 为例，广告负责人看到的商业入口可能是 Foundry 与 AIP；架构师看到的是 Data Connection、Pipeline Builder、Ontology、Workshop、AIP Evals 和 Apollo；投手真正关心的却是“某个 Campaign 为什么被建议增加预算，谁可以批准，变更何时生效，七天后怎样判断效果，出现库存风险能否撤回”。只有第三张地图能够直接回答这个问题。

三张地图不能互相替代。只看商业地图，会误以为购买 AIP 就能绕过数据治理；只看技术地图，会低估 Gotham 和行业方案里已经封装的任务经验；只看运营地图，又可能忽略 Apollo、支持服务、许可与环境约束。成熟的产品分析应该先确定讨论层级，再比较能力。

“Palantir 有几个产品”没有唯一答案。四个是法律披露中的主要平台数量，三个是当前标准技术架构的核心平台数量；Ontology 是贯穿平台的运行系统，不应再被计成一张同级产品卡。

四个主要平台各自守住什么边界

图 2：四个平台不是线性上下游，Gotham 与行业方案复用统一底座（概念示意）

Gotham：任务空间，不是 Foundry 的军用换皮

Gotham 最早围绕情报整合、调查分析和任务协同发展。官方白皮书强调多源数据融合、对象和关系分析、地理空间操作、跨层级协同、模型接入及在云端、本地和战术边缘运行。它面对的核心不是“给一张表做报表”，而是让不同角色在高时效、高权限敏感度的任务空间中形成共同态势，并把分析推进到受控任务动作。

把 Gotham 简化为“军用 Foundry”会遗漏任务应用、地理空间交互、作战工作流和既有防务系统集成；把它描述成完全独立的旧平台也不准确。现行架构中心指出，防务产品的早期组件早于 AIP + Foundry + Apollo 标准架构，但如今已经与标准架构完整集成。更合适的判断是：Gotham 是面向政府、国防与情报任务的产品和应用体系，其底层越来越复用统一的数据、AI、Ontology、安全与交付能力。

Amazon Ads 并不需要 Gotham。广告活动、搜索词、商品、受众和预算虽然也能画成关系图，却没有必要借用军事任务语言。本文讨论 Gotham，是为了看清 Palantir 的产品模型：通用平台之上可以存在深度垂直的任务空间，但行业应用的存在不意味着底层能力需要重新建设一遍。

Foundry：数据运营平台，不等于数据仓库

Foundry 的入口最接近企业数据平台，因此也最容易被拿来与 Snowflake、Databricks、传统 ETL、BI 或数据目录逐项比较。官方文档把它定位为 Data Operations 平台，覆盖数据连接、转换、质量、血缘、模型开发、Ontology、分析、应用和产品交付。它可以连接现有仓库，也可以存储和计算数据；它的边界不由“数据是否存进 Palantir”单独决定，而由数据资产能否进入受治理的分析和运营工作流决定。

对 Amazon Ads 团队，Foundry 可以承担 Amazon Ads API 批量报表、Marketing Stream 小时消息、Seller Central 订单与库存、成本表、汇率、商品主数据和 AMC 聚合输出的连接与变换。这里最重要的不是连接器数量，而是这些来源能否保留数据血缘、版本、粒度、时间角色和质量状态。只有这样，后续“增加预算”才知道基于哪一版事实。

Apollo：软件交付与 Day 2 运营平台

Apollo 经常在产品矩阵图里被放在最下方，因而被误解为 Palantir 内部使用的部署工具。官方 Apollo 文档给出的范围更宽：它用 Hub-Spoke 架构管理分布在公有云、私有云、本地、边缘和隔离网络中的软件环境，通过产品、版本、发布通道、约束、计划、健康信号、审批、召回和回退完成持续交付与 Day 2 运营。Palantir 自身用 Apollo 交付 Foundry、AIP 及行业产品，同时也把 Apollo 作为可供客户管理其软件的独立平台。

广告系统通常不需要战术边缘或气隙网络，但仍会遇到多区域、客户隔离、合规审批、模型版本、策略函数和连接器升级。若一套 Agent 只在开发环境里表现良好，却不能安全地把模型、函数、Ontology 变更和应用版本发布到生产，运营闭环仍然不完整。Apollo 在此承担的不是业务决策，而是“什么版本的决策系统正在什么环境运行”。

AIP：把模型能力送进运营，不是一个模型品牌

AIP 不提供一个名为“Palantir 大模型”的单一智能来源。官方文档列出的能力包括连接商业和开源 LLM、BYOM、模型目录、上下文与检索、AIP Logic、AIP Chatbot Studio、AI FDE、Evals、Evolve、平台内嵌助手、开发 SDK 和 Agent 工具链。它的产品价值在模型之上：让不同模型在既有数据权限、Ontology 对象、函数、动作、审计和资源管理框架中被使用。

这也意味着 AIP 的边界不能只用回答质量评价。一个投放 Agent 能否解释预算异常只是第一步；它是否只读取当前操作者有权查看的账户，是否把候选变更写成可审批 Action，是否在归因未成熟时拒绝扩大预算，是否比较不同模型和提示版本，是否能回溯每次工具调用，才决定它能否进入生产运营。

四个平台的交集很大，但责任仍可区分。Foundry 让数据、模型和业务对象可用；AIP 让生成式 AI 和 Agent 能在这个世界中工作；Apollo 让整套软件在复杂环境中持续、安全地演进；Gotham 把这些能力组织成高要求任务应用。任何“一个平台取代另外三个”的描述都需要非常谨慎。

标准架构：AIP 与 Foundry 共用网格，Apollo 负责让它活着

Palantir 的架构中心把 AIP 与 Foundry 的能力组织成九组：Ontology Language、Ontology Engine、Ontology Toolchain；Data Services、Logic Services、Workflow Services；Analytics & Applications、Automations、Product Delivery。这九组能力共同使用 Storage、Compute、Networking、Security、Governance 和 Workspace 六类网格基础组件，并由 Apollo 持续交付。

图 3：AIP 与 Foundry 共享能力网格，Apollo 贯穿软件交付，Rubix 承载运行（概念示意）

这种画法透露出一个重要产品判断：数据平台与 AI 平台并不是先后购买的两栋楼。模型调用、向量化、工具服务、对象查询、动作写入、可观察性和应用运行共享同一套安全与治理边界。AIP 不是通过公开 API 隔着网络“调用 Foundry 的数据”，而是与 Foundry 在统一服务网格中协作。对需要把模型输出继续推进为业务动作的企业，这种共用运行时减少了身份、权限、血缘和审计在平台边界处重新翻译的次数。

Rubix 位于更底层。官方称其为安全、弹性、高可用的 Kubernetes 实现，用来让核心服务在 AWS、Azure、Google Cloud、Oracle Cloud 或本地环境获得一致运行特征。Rubix 与 Apollo 的关系类似“运行基底”与“交付控制面”：前者解决工作负载隔离、调度、加密、身份验证和资源效率，后者决定哪些产品版本在何种约束下进入哪些环境。两者都很重要，但它们不是同一个产品名称。

如果把这套结构翻译到 Amazon Ads 运营，可以得到一条具体链路：Data Services 接入报表、消息和零售数据；Logic Services 计算归因成熟度、利润边界、预算节奏和候选策略；Ontology 把 Profile、Marketplace、Campaign、Ad Group、Target、Search Term、ASIN、Inventory Snapshot 与 Decision Proposal 绑定；Workflow Services 驱动定时观察与审批；Workshop 或定制应用为投手提供工作台；AIP 生成解释、候选和异常归因；Apollo 管理各客户环境中策略函数、应用和 Agent 版本。

这条链不是必须由 Palantir 独家完成。现有湖仓可以继续存储事实，外部模型可以继续训练和推理，外部应用可以通过 OSDK、API 或 MCP 消费对象和动作。Palantir 的主张是把互操作组件纳入统一治理，而不是要求所有计算都改写为某一种专有语言。是否真的降低锁定，仍要通过数据导出、逻辑可迁移性、动作协议、身份模型、运行依赖和合同条款逐项测试，不能只接受“开放 API”四个字。

标准架构的核心不是技术栈更长，而是把身份、权限、血缘、动作和发布版本放进同一条控制链。若这些控制仍在五套外部系统中靠人工对齐，企业拥有的只是工具集合，不是统一运行时。

三条横向控制面比产品边界更重要

纵向看产品容易理解，横向看控制面更接近真实运行。第一条是身份与授权控制面：用户、服务身份、应用范围、对象权限、属性标记、Action 权限和环境角色要形成连续判断。第二条是版本与分支控制面：dataset、Pipeline、Ontology、函数、Logic、模型配置、应用和 Release 需要知道各自版本以及组合关系。第三条是观测与审计控制面：数据构建、模型调用、Agent 轨迹、对象编辑、外部动作和软件部署都要留下可以关联的记录。

这三条控制面解释了为什么某些单点工具能力很强，组合后仍难以成为运营系统。模型网关可以管模型密钥和调用日志，却不知道某个工具动作修改了哪个业务对象；数据目录能追踪表血缘，却不知道一条预算 Proposal 最终由谁批准；GitOps 系统能记录镜像版本，却不知道该版本使用哪一版业务政策作出了什么决定。Palantir 的产品意图，是用共享身份、Ontology 与平台元数据让这些记录互相指向。

产品不是按用户角色一刀切开的

Foundry 不只给数据工程师，AIP 也不只给 AI 工程师。数据工程师在 Foundry 建 Pipeline，也会在 Ontology 里确认对象；业务分析师使用 Contour 或 Quiver，也会在 Workshop 提交 Action；应用开发者使用 OSDK，却继承 Ontology 范围与权限；Agent 开发者使用 Logic、Evals 和 Model Catalog，同时依赖 Foundry 数据与 Apollo 发布；平台管理员则跨越身份、安全、环境和更新。

如果采购后按传统组织结构把产品拆给不同部门，烟囱会在新平台内重新出现：数据团队只负责供表，AI 团队另做向量库，应用团队复制业务逻辑，运维团队只看容器，业务团队仍在表外审批，最终没有共享对象与动作。更合理的团队边界是围绕闭环建立跨职能产品小组：业务所有者定义目标和风险；数据负责人保证事实；Ontology 负责人维护对象与合同；应用与 Agent 工程师实现交互和计划；平台负责人保证发布、权限和观测。

Rubix 说明平台一致性也有基础设施成本

Rubix 是 Palantir 标准架构的 Kubernetes 基底，官方架构将其描述为支持在云和本地环境运行平台的底座。它负责让上层服务拥有相对一致的调度、网络、存储、身份和运维基础，再由 Apollo 处理持续升级。这个设计提高了环境可移植性，也意味着平台不是一套没有基础设施重量的 SaaS 页面。

企业评估部署时要问具体问题：计算与存储由谁提供；数据驻留在哪里；平台控制面与客户环境如何连接；网络中断时哪些功能继续；升级和漏洞修复怎样进入；遥测离开环境的边界是什么；隔离环境如何更新；资源配额怎样影响 Pipeline、模型推理与应用。官网上的“可部署到任何环境”是一种能力声明，实际拓扑仍需按安全和运维条件设计。

九类能力应被映射到一条可验收链

Architecture Center 将能力归纳为数据集成、Ontology、应用、AI、模型、分析、开发者工具、安全与平台基础设施等类别。产品分析若只按这些类别逐项勾选，很容易得到一张所有企业平台都“基本支持”的对比表。真正有区分度的验收，需要让同一个业务对象穿过这些能力。

例如选择一个 Campaign：能否从 Amazon 源数据追到它的标准事实；能否映射到稳定 Ontology 对象；能否在分析工具中解释指标；能否在 Workshop 和 OSDK 应用看到同一状态；能否由 Logic 和 Agent 读取同一政策；能否通过 Action 修改预算；能否按身份和客户范围限制；能否将每次运行、批准和外部回执关联；能否将策略与应用作为版本发布。穿透测试比功能清单更接近产品真相。

Palantir 的矩阵不是四个互相调用的孤立产品，而是横向控制面贯穿多个纵向能力。分析它时，最有效的方法是选择一个业务对象，检查身份、版本和审计能否陪它走完事实到行动的全过程。

Foundry 的纵向能力：从来源连接到运营对象

理解 Foundry，最好不要从应用菜单开始，而要沿一条数据责任链向上看。数据进入平台之前，来源系统仍然拥有各自的事务语义；进入 Data Connection 后，连接凭据、同步任务、虚拟表、流和出站策略成为可治理资源；进入 Pipeline Builder 或 Code Repositories 后，转换逻辑、模式检查、分支和构建历史开始形成可复现数据产品；进入 Ontology 后，数据才被绑定为业务对象、关系、动作和权限；最终由分析、应用、自动化和 Agent 消费。

图 4：数据进入 Foundry 后仍要经过版本、质量和对象绑定才能参与决策（概念示意）

Data Connection 负责把来源变成受管入口

Data Connection 不只是“选择数据库并导入”。它管理来源凭据、同步配置、代理式连接、云端摄取、虚拟表和出站连接。对于 Amazon Ads，官方 API 需要应用审批和授权，Marketing Stream 通过 AWS SQS 或 Firehose 推送小时指标与活动变更，AMC 则在隐私安全环境中返回满足聚合要求的分析结果。三个入口的时效、粒度、权限和可重放性完全不同，不能进入同一张宽表后只留下一个 date 字段。

合理的数据接入会同时保存来源身份、广告 profile、marketplace、请求参数、报告类型、窗口、生成时间、摄取时间、版本、分页或消息位点、原始载荷位置和校验状态。Data Connection 解决连接生命周期，业务团队仍需定义这些字段如何解释。连接成功证明“数据可以到达”，不证明“数据可以支持调价”。

Pipeline Builder 与 Code Repositories 服务不同复杂度

官方文档把 Pipeline Builder 称为 Foundry 的主要数据集成应用，支持图形化输入、转换、预览、检查和输出；Code Repositories 则在 Git 服务器之上提供 Python、Java、SQL 等代码化转换和协作治理。两者不是简单的初级版与高级版。图形流水线适合让数据工程师和熟悉业务的分析人员共同审查结构，代码仓库适合复杂算法、可测试模块、依赖管理和工程化复用。

投放数据的基础清洗、字段标准化、站点币种绑定、主键检查和轻量聚合可以在 Pipeline Builder 表达；复杂的归因成熟模型、增量实验、预算优化器和异步 API 对账更适合进入代码、模型或容器。平台价值不在强迫所有逻辑使用一种工具，而在不同工具的输出仍能进入统一血缘、分支、构建和权限体系。

Lineage、Data Health 与 Builds 让“哪一版事实”可回答

广告指标经常回填。当天的点击和花费较快稳定，归因销售会随着窗口推进发生变化，退款和取消还可能继续改变净结果。如果流水线每天覆盖昨日数据而不保留观察时间、报告版本和构建证据，后续无法解释为什么系统当时做出某个决策。

Foundry 的 Data Lineage 用资源图展示来源、数据集、转换、Ontology 与应用之间的连接；Data Health 管理质量检查和监控；Builds 展示构建执行、历史成功率和底层运行信息。它们共同回答“决策使用了哪条管线的哪次结果”。但这些产品能力仍需要团队配置业务检查，例如 Campaign 花费不可为负、profile 与 marketplace 必须匹配、搜索词报告不能冒充关键词配置、库存快照不能跨日求和。

Modeling 与逻辑服务不是数据层的附属插件

Foundry 支持无代码和代码化模型开发、Modeling Objectives、模型适配器、批量或在线推理、函数集成和外部模型。AIP 又扩展了 LLM 的连接与运行。把传统机器学习与生成式 AI 分开治理仍有必要：预算预测、转化率估计和库存风险评分通常需要稳定特征、离线验证和数值指标；文本解释、异常归因和策略草案可以由 LLM 协助。二者最终都应把输入、版本、输出和适用范围绑定到运营对象。

所以，Foundry 与仓库、ETL、目录、模型平台或 BI 都有重叠，却不能被其中任意一个词完整覆盖。它的纵向价值来自这些能力共用资源身份、权限、血缘和交付机制。反过来，如果企业只使用 Data Connection 和 Pipeline Builder 把数据汇总成报表，从未建立对象、动作和反馈链，那么得到的依然主要是一套数据工程平台，并没有自动获得“运营系统”。

Ontology 不是第五个平台：它是四类责任的共同运行时

“Ontology”是 Palantir 讨论中最容易产生歧义的词。知识表示领域通常用本体表达概念、类别、关系、公理和约束；图数据库强调节点、边和遍历；BI 语义层强调指标、维度、聚合与查询。Palantir 当前的官方架构文档甚至直接说明，其 Ontology 不是一个薄语义层，而是由 Language、Engine 和 Toolchain 组成的多模态系统，用来整合 data、logic、action 和 security。

图 5：Palantir Ontology 同时表达业务世界、执行变化并控制访问（概念示意）

这并不意味着 Palantir 拥有对“本体”一词的唯一解释。更准确的做法，是按它自己的产品定义分析其运行时责任，再与 OWL、RDF、SHACL 或图数据库比较。Palantir Ontology 的对象类型、属性、链接、接口构成语义部分；Action Type、Function、Automation 构成动力部分；对象存储、查询、事务、流、订阅和物化由 Engine 支撑；OSDK、Developer Console、MCP、应用构建和 DevOps 由 Toolchain 暴露；安全策略贯穿所有部分。

Language：对象是名词，动作是带条件的动词

Ontology Language 不只给表和字段换业务名称。Object Type 定义一种实体或事件，Property 定义其特征，Link Type 定义对象关系和基数，Interface 为不同对象提供共享能力形状。Action Type 则定义用户或系统能够提交的业务变化，包括参数、规则、提交条件、对象修改和副作用；Function 承载复杂读取、计算和写入逻辑。

在 Amazon Ads 场景中，Campaign 不是 campaign 报告的一行，而是拥有 profile、marketplace、状态、预算、竞价策略、版本和外部标识的运营对象。SearchTermObservation 是某个时间窗口内的观察事实，不等于可修改的 KeywordTarget。IncreaseCampaignBudget 不是把某列加 10%，而是一种带前置条件、审批阈值、幂等键、最大变更幅度、执行目标和回执要求的 Action Type。把这些差异写进语言层，Agent 才不会因为两个字符串相同就把观察对象当成配置对象。

Engine：让对象可以被高规模读写，而不只被展示

若 Ontology 只有模型图，它最多是一份可读文档。Engine 需要让对象和链接可查询、订阅、物化和更新，让动作能够原子、持久地修改状态或协调外部系统，并在实时流、批量变化与变更数据捕获之间保持一致的对象世界。Palantir 的架构说明把高规模 SQL 查询、对象读取、实时状态订阅、事务更新、批量变更、流和 CDC 都归入 Engine 的责任。

对广告系统而言，Engine 的难点不是能否查询一百万个 Target，而是当批量报告、Marketing Stream、库存流和人工修改以不同速度到达时，系统能否明确当前对象状态、观察版本和动作后状态。一个预算变更写入 Amazon Ads API 后，Ontology 中不能立即把“请求已接受”当成“平台最终状态已确认”；它需要保留 Proposal、Approval、Execution Attempt、External Receipt 和 Reconciliation 的状态迁移。

Toolchain：让 Ontology 成为应用后端，而不是封闭画布

OSDK 可以针对选定的 Ontology 资源生成 TypeScript、Python 或 Java 客户端，应用使用对象类型、函数和动作，而不是直接拼接底层表。Developer Console 管理应用范围、客户端与文档；Platform SDK 访问数据、构建、健康、流、审计等平台能力；Compute Modules 容纳自带代码和容器；Custom Endpoints 允许以自定义 API 形状暴露后端能力。到 2026 年，Palantir 还区分 Palantir MCP 与 Ontology MCP：前者更偏平台构建和开发工作流，后者把选定的对象、动作和查询函数暴露给外部 Agent 消费。

工具链的价值是类型和权限跟随 Ontology 向应用传播。风险也在这里：一旦大量应用、自动化和 Agent 都依赖专有对象 API、动作定义和运行服务，迁移成本不再只来自数据格式，而来自业务行为。评估开放性时，必须验证数据可导出、对象标识可映射、动作合同可重建、函数逻辑可迁移、权限语义可还原、历史决策可解释。

Security：读取、推理、建议和执行是四种不同授权

Palantir 的安全设计不是一个附加列。数据集、对象、属性、函数、动作、项目和应用都有权限边界，标记和分类访问控制还承担下游传播。AIP Logic 文档特别提醒，行列读取控制会限制模型代表用户看到的内容，但读取时控制不会自动保护模型输出或其建议的 Ontology 编辑；要保护信息继续传播，需要结合 marking 或分类访问控制。

这个细节很关键。某个广告分析师有权读取客户 A 的 Campaign，并不代表他有权提高预算；Agent 有权调用“生成预算建议”函数，也不代表它有权提交变更；执行服务有权调用 Amazon Ads API，也不代表它能越过客户授权和变更窗口。把四种授权压缩为一个“用户已登录”，是多数自动化事故的根源。

Ontology 的产品价值不在“关系图画得更丰富”，而在相同对象定义能否同时约束查询、逻辑、应用、动作、Agent 和权限。只建对象与链接、不建动作和回执，得到的是知识模型；只有把受控写入接上，才接近运营本体。

它与指标语义层、知识图谱和数字孪生分别差在哪里

“语义层”“知识图谱”“本体”“数字孪生”在企业软件中经常混用，Palantir 也使用 Ontology 和 operational digital twin 描述产品。为了避免把营销词当作等价概念，需要按能力而不是名称比较。

指标语义层主要统一可计算口径：维度、度量、实体键、关系和查询规则。它能保证 ACOS 在不同看板中按相同公式聚合，也能为 BI 或 NL2SQL 提供受控查询模型。但指标语义层通常不负责对象生命周期、写操作、审批和外部副作用。它回答“怎样一致地算”，不完整回答“哪个运营对象现在可以做什么”。

知识图谱主要表达实体、关系和可查询知识。RDF/OWL 路线还可以通过形式语义、约束与推理表达类别、公理和一致性；属性图更适合高效遍历具体关系。知识图谱可以成为 Ontology 的重要实现或证据来源，但单独的图存储不会自然产生 Action、应用、权限继承、模型工具和软件交付。反过来，Palantir Ontology 也不等于 W3C OWL 标准实现；它是面向平台运营的专有对象与动作系统，评估时不能因为名称相同就假定拥有相同形式逻辑能力。

数字孪生强调现实资产或过程在数字空间中的状态映射，经常用于设备、工厂、供应链和仿真。Palantir 所称 operational digital twin 将范围扩展到人员、订单、风险、决策和动作，更接近“组织当前可操作状态”。其关键不是三维可视化或高保真物理模拟，而是让多源事实与运营对象、逻辑和行动连接。若业务需要物理仿真、控制系统实时闭环或工程模型，仍可能需要专门数字孪生平台与 Ontology 协作。

企业 Ontology 提供更宽的业务合同：对象是什么、怎样关联、由哪些数据支撑、有哪些派生逻辑、允许哪些动作、谁可以执行。它可以引用指标层的度量、图谱的关系和孪生的状态，但还要负责将这些语义送到应用与 Agent。Palantir 的差异就在于把这个更宽的 Ontology 直接放进应用和动作运行时。

“数据加逻辑加行动加安全”不是简单相加

数据决定对象当前状态，逻辑从状态产生判断，行动改变对象或外部世界，安全限定谁能观察和改变。这四项存在反馈关系。动作改变预算后，新预算成为数据；数据触发新逻辑；逻辑可能要求再次行动；权限又因对象状态和风险而改变。若四项由不同系统维护而没有共同身份和版本，循环很快失真。

以否定搜索词为例，数据层记录 search term 的点击、花费与订单；逻辑层判断样本是否成熟、是否与品牌策略冲突、是否存在其他 target 覆盖；行动层创建 negative exact 或 negative phrase；安全层限制谁能影响某个 portfolio。动作执行后，搜索词不再获得流量，未来数据发生结构性变化。评估策略时必须知道“零点击是市场变化还是系统自身执行了否定”。Action 因此既是副作用，也是后续分析的因果上下文。

对象接口让应用与 Agent 不必复制底层表结构

OSDK 的意义不只是提供 SDK。应用开发者面向生成的对象类型、属性、链接、函数和 Action 编程，平台再根据当前用户与应用范围处理访问。底层 Pipeline 可以调整，只要 Ontology 合同保持兼容，应用不必跟着每张表变化。Agent 也通过受控工具使用相同合同，而不是自行猜测表名和连接路径。

这类抽象会带来治理责任。Ontology 变更必须区分兼容与破坏性影响：新增可选属性通常风险较低；改变对象主键、关系基数、状态含义或 Action 参数可能影响多个应用和 Agent。上线前需要影响分析、测试和分支，不能把 Ontology 当成业务人员随手拖拽的无代码画布。

Ontology 不能替代源系统的权威责任

对象层可以统一视图和动作，但不应模糊系统记录边界。Amazon Ads 是 campaign 预算和竞价是否生效的外部权威；订单系统是订单状态权威；库存系统是可售库存权威；财务系统是成本和结算权威。Ontology 可以形成当前运营状态并协调动作，却需要明确哪些属性是源系统事实、哪些是派生判断、哪些是用户编辑、哪些是暂存 Proposal。

如果允许多个路径修改同一属性，还要定义冲突策略。例如运营人员在广告控制台手工修改预算，同时 Agent 基于旧快照提交动作。系统不能简单以“最后写入为准”；应识别外部变化、使旧 Proposal 失效，并要求重新判断。所谓数字孪生不是一个永远正确的副本，而是一套持续对账、标记未知和处理冲突的机制。

Palantir Ontology 可以吸收指标语义、图关系和数字孪生思想，但不能与其中任何一个直接画等号。它的产品边界落在“可操作合同”：同一对象的事实、逻辑、行动和安全能否共同进入应用与 Agent。

应用矩阵：同一个 Ontology 为什么需要多种工作表面

Palantir 的应用很多，名称也频繁演进。把它们理解为互相竞争的前端会变得混乱；按“使用者需要多大表达能力、决策离动作有多近”排列，关系就清楚得多。Object Explorer 和 Object Views 用于发现与理解对象，Contour、Insight 和 Quiver 用于分析，Workshop 用于构建对象驱动的运营应用，Slate 和 OSDK 用于高度定制的应用，AIP 工具则把自然语言、LLM 函数和 Agent 嵌入这些表面。

图 6：应用工具不是功能重复，而是共享对象合同上的不同表达层级（概念示意）

Object Explorer 与 Object Views：先让对象拥有稳定入口

Object Explorer 提供跨 Ontology 的搜索、类型组、关系图、对象集合和探索入口。Object Views 则为具体对象提供统一视图，呈现属性、链接对象、指标、分析和可用动作。它们看起来像基础浏览器，却承担一个重要产品职责：让用户不必先知道数据来自哪张表，仍能以 Campaign、商品、供应商、患者或设备的身份进入工作。

在 Amazon Ads 中，一个 Campaign 视图应该同时显示广告状态、预算、竞价策略、所属 Portfolio、近七日成熟花费与销售、库存约束、待审批 Proposal 和最近动作，而不是只复制控制台字段。一个 Search Term Observation 视图则应明确它来自哪个报告窗口、关联哪些 Target、是否已成为关键词、是否被否定以及证据成熟度。对象视图把身份放在分析之前，这是减少跨报表误解的第一步。

Contour、Insight 与 Quiver：表、对象和时间序列各有分析入口

官方分析文档把 Contour 用于大规模表格数据分析，把 Insight 用于 Ontology 对象探索与对象集合，把 Quiver 用于高级对象分析、时间序列和可嵌入仪表盘。这个分工说明 Palantir 没有强迫所有数据先进入 Ontology。一次性文件、中间流水线结果或超大规模表格可以继续在 Contour 中分析；需要沿对象关系、复用对象集合或进入运营应用的分析更适合 Insight 与 Quiver。

这类边界对实施很重要。若把每个原始广告报表字段都提升为 Ontology 属性，模型会被来源结构淹没；若所有分析都停留在表层，又无法复用对象身份和动作。更稳妥的做法是让原始、过渡和审计数据保留在数据层，把稳定业务对象、可复用状态和决策所需关系提升到 Ontology，再通过对象分析验证其意义。

Workshop：把分析结果变成可提交的运营动作

Workshop 是低代码运营应用构建器。它从 Object Data Layer 读取数据，以变量、事件、布局和组件组织交互，通过 Function 计算，通过 Action 写回。官方文档强调 Workshop 应用比一般仪表盘更具交互性，并将任务收件箱、告警处置和共同运营图列为典型模式。

一个 Amazon Ads 预算工作台可以把“异常 Campaign 收件箱”放在左侧，将成熟指标、库存、利润与 Placement 表现放在中间，把 Agent Proposal、反证和 Action 表单放在右侧。用户批准的不是一段自由文本，而是 ApproveBudgetChange；其参数和可见性来自 Action Type，提交前由规则检查最大幅度、客户授权、实验状态和并发版本。页面只是入口，真正的业务合同位于 Ontology。

Slate、OSDK 与 Compute Modules：在低代码边界之外继续构建

Workshop 适合对象驱动的标准运营交互，却不适合所有视觉、算法和集成要求。Slate 允许使用 HTML、CSS 与 JavaScript 构建定制应用；OSDK 让外部 Web、移动或服务端应用以类型安全方式访问对象、动作和函数；Compute Modules 允许把自有代码和容器运行在平台中；Custom Endpoints 则为外部系统提供定制 API。

从产品架构角度看，低代码与专业开发并不是二选一。关键在于二者是否共用同一个对象和动作合同。若 Workshop 中的“调整预算”与 React 应用中的“调整预算”分别维护校验和权限，平台很快会产生两套运营语义。OSDK 的价值正是让外部体验仍调用同一 Action，而不是绕过 Ontology 直接写底层 API。

应用矩阵也带来治理成本。团队需要规定哪些分析可以停留为个人草稿，哪些对象集合可以被应用复用，哪些函数必须有测试，哪些 Action 属于高风险写入，哪些应用需要产品所有者。工具越丰富，越不能依赖“大家自己知道该用什么”。Palantir 提供 Application Reference、Use Cases、Projects、Marketplace 和 DevOps 等组织机制，但最终的信息架构与发布纪律仍由客户承担。

AIP 产品面：模型接入只是最下游的一小部分

AIP 的产品故事很容易被市场热词覆盖。把它拆成生产责任，可以得到七层：模型接入与路由、企业上下文、LLM 函数与工具、交互式助手、Agent 开发与自动化、评测和可观察性、系统演进与交付。这七层共享 Foundry 和 Ontology，却有不同的使用者与失败模式。

图 7：AIP 的生产责任从模型接入逐步上升到受控行动与平台建设（概念示意）

模型接入：选择模型，不把模型等同于系统

AIP 支持 Palantir 管理的商业模型、开放模型和 Bring Your Own Model。Model Catalog 帮助用户发现、试验和选择 Palantir 提供的 LLM；注册模型可以连接客户自己的模型服务、云账户或自托管模型。AIP 还提供兼容部分主流 LLM Provider API 的代理入口，使现有 SDK 能够经过平台的速率、使用量和数据处理控制。

多模型能力解决的是供给与治理，不解决业务正确性。某个模型更擅长归纳搜索词，不代表它知道企业的利润口径；某个模型工具调用成功率更高，不代表它有权改变预算。模型应作为 Logic 或 Agent 的可替换依赖，业务对象、动作和评价标准不应被埋在某个供应商的系统提示词里。

上下文：Ontology、文档和函数输出承担不同证据

AIP Chatbot 可以使用 Ontology 对象、文档、应用状态和自定义函数作为 Retrieval Context。结构化对象适合表达 Campaign、Target、库存和 Proposal 的当前状态；文档适合承载投放政策、客户合同、操作手册和例外说明；函数适合计算实时或受控结果。把三者都称作“知识库”会掩盖数据新鲜度、权限、可验证性和写入能力的差异。

对投放 Agent，可以把客户策略手册作为文档上下文，把当前 Campaign 和库存作为对象上下文，把 calculateMarginalReturn 作为函数工具。Agent 的回答还应显示证据来源和时间。若只把几十份 PDF 向量化，而没有绑定当前 profile、marketplace 和动作权限，它可能解释得很专业，却无法对某个账户给出可执行建议。

AIP Logic：把 LLM 放进可发布函数，而不是让 Prompt 漂在聊天里

AIP Logic 是无代码 LLM 函数构建环境。函数可以接受文本或 Ontology 对象，串联查询、条件、循环、计算、函数调用和 LLM 等块，返回值、对象或 Ontology 编辑。Logic 支持调试、版本比较、分支、自动化、指标和 AIP Evals。需要修改 Ontology 时，已发布的 Logic 函数还要通过 Action 调用；自动编辑可以直接应用，也可以先暂存供人工审查。

这套设计把 Prompt 从个人聊天提升为有输入输出、版本、测试和调用者的产品资产。一个“解释预算异常”的 Logic 可以读取 Campaign、小时花费、库存和历史 Action，输出结构化原因及证据；一个“生成预算候选”的 Logic 可以输出 Proposal，但不应直接获得 Amazon Ads 写权限。Logic 负责生成和计算，Action 负责把变化纳入业务控制。

AIP Chatbot Studio：交互式助手，而不是所有 Agent 的总代名词

2026 年 4 月，原 AIP Agent Studio 更名为 AIP Chatbot Studio，原 AIP Agents 相应称为 AIP Chatbots。官方说明其功能本身没有因更名改变：用户可以构建基于 LLM、Ontology、文档和工具的交互式助手，并部署到 Workshop 或外部应用。这个变化提醒读者，Palantir 自己也在收紧产品术语——一个对话助手可以调用工具，但不应因此自动代表所有自动化和长时程 Agent。

Chatbot 适合人在回路的调查、解释、对象查找和任务发起。若工作需要定时启动、跨天等待、处理部分失败、保存检查点、恢复和升级，则还需要 Automate、Machinery、函数、外部编排或专门的 Agent Harness。聊天界面是控制面之一，不是耐久执行引擎。

AI FDE：把 Agent 放到平台建设过程

AI FDE 是“AI-powered forward deployed engineer”。它不主要服务终端业务用户，而是通过自然语言和原生工具帮助构建与维护 Foundry：创建或修改流水线、代码仓库、Ontology、函数、评测、OSDK 应用和治理配置。文档说明其默认在 Global Branch 或代码仓库 Pull Request 中提出变更，并遵守当前用户的权限。

这使 AI FDE 与 AIP Chatbot 的责任明显不同。前者面向建设平台的开发者和数据团队，能够修改系统资产；后者面向使用具体业务上下文的交互。AI FDE 的价值不只在写代码更快，而在能够让“修改 Ontology—运行测试—检查构建—发起提案”成为可审查轨迹。它的风险也更高：工具范围、分支隔离、上下文选择和审查责任必须清楚。

Palantir MCP 与 Ontology MCP：建设者和消费者的两条接口

Palantir MCP 面向外部 AI IDE 和 Agent，让它们获得 Foundry 工具与平台上下文，更接近开发和运维接口。Ontology MCP 面向 Ontology 消费者，把选定的对象类型、Action Type 和查询函数暴露为 MCP 工具，使外部 Agent 可以在应用授权范围内读取和写入生产对象。官方样例还展示了反方向：Foundry 内的编排 Agent 可以作为 MCP 客户端调用外部云中的服务。

协议统一并不会自动产生业务安全。Ontology MCP 暴露哪些对象与 Action，由 Developer Console 应用范围决定；外部 Agent 使用何种身份、是否代表用户、工具参数如何验证、动作是否需要审批、调用结果如何审计，都需要运行时配置。MCP 解决工具发现和调用交换，不替代 Ontology、权限或 Action 合同。

AIP 的最小正确理解不是“企业 ChatGPT”，而是模型供应、上下文、函数、工具、Agent、评测和平台治理的组合。模型可以更换；真正难迁移的是围绕 Ontology 形成的动作合同与运营轨迹。

长时程任务：Chatbot、Logic、Automate 与 Machinery 不能互相冒充

Agent 演示通常在一个会话里完成：接收问题、调用几个工具、返回答案。运营任务却可能跨越数小时、数天甚至数周。等待报告归因成熟、等待审批、等待外部 API 恢复、等待库存到仓、等待下一次预算周期，都会使任务离开单次模型调用。若把所有状态留在聊天历史或模型上下文中，系统无法可靠恢复，也无法解释为什么任务停在某一步。

Palantir 的产品面提供了不同抽象。Chatbot Studio 适合交互式调查和人在回路的工具使用；AIP Logic 适合将模型、函数、分支与 Ontology 读写组织成可发布逻辑；Automate 适合根据对象变化、时间或条件触发工作流；Machinery 的公开定位则覆盖流程发现、状态管理、多 Agent 编排与人工干预。它们有重叠，但选择应由任务状态和失败语义决定，而不是由“是否用了大模型”决定。

一次模型调用不应拥有跨天状态

假设运营团队希望在七天内逐步提升一组新品 campaign 的预算。任务每天检查预算消耗、搜索词、库存和利润，达到阈值时提案，数据异常时暂停，周末由负责人复核。这个任务不能靠每天重新问 Chatbot 并让模型回忆昨天发生了什么。它需要持久 Task、阶段、下一次唤醒时间、已完成动作、待审批事项、失败计数和取消原因。

Ontology 可以保存 OptimizationRun 与步骤对象，Automate 或 Machinery 驱动状态迁移，Logic 在具体步骤产生判断，Chatbot 提供解释和人工操作入口。模型调用是某个步骤的实现，不是任务状态的唯一容器。即使更换模型、Prompt 或 Logic 版本，历史运行仍应引用当时版本并从确定检查点恢复。

等待是业务状态，不是线程睡眠

等待归因成熟与等待 API 重试具有不同语义。前者是正常业务门禁，任务应记录预计成熟时间和所需报告版本；后者是技术异常，需要指数退避、最大次数与升级。等待人工审批又涉及超时、代理人和撤销。若工作流只提供一个通用 delay，运营人员无法判断任务为何停住，系统也无法为不同等待配置服务目标。

Amazon Ads 运营中常见的等待还包括预算变更传播、促销开始、库存入仓、Featured Offer 恢复、退款窗口、客户确认和市场时区切换。每种等待都应该对应明确状态、唤醒事件、超时动作和可见负责人。长时程 Agent 的用户体验很大一部分不是聊天，而是任务列表、状态解释、暂停、继续、取消和升级。

重试必须知道工具是否产生了副作用

读取报告失败通常可以安全重试；创建预算变更超时则可能已经在 Amazon 生效。Agent Harness 需要知道工具的幂等性和副作用等级：PURE 表示纯计算，READ 表示只读外部状态，PROPOSE 只创建内部候选，WRITE 会改变对象，EXTERNAL_WRITE 会改变外部系统。不同等级使用不同重试、审批和补偿策略。

对 EXTERNAL_WRITE，最安全的流程是先生成稳定幂等键和预期状态，提交后保存请求，再通过查询或后续报告对账。若外部接口不支持幂等键，连接器需要用业务键、原值快照和状态查询尽量避免重复。模型不参与判断“超时是否等于失败”，这由工具合同与状态机处理。

多 Agent 不是把一个任务拆成更多聊天

Machinery 提到多 Agent 编排，并不意味着每个业务角色都应变成一个会说话的 Agent。拆分的依据应是能力、权限、上下文和评测边界。例如 Evidence Agent 只能读取并组织证据；Strategy Agent 生成候选；Risk Agent 使用独立政策检查；Execution Service 不使用 LLM，只执行已批准 Action。它们通过类型化对象交换结果，不通过自由文本互相说服。

多 Agent 的代价是状态、成本和故障面增加。若一个确定性函数能完成利润计算，就没有必要增加“财务 Agent”；若一个单 Agent 能在受限工具内完成调查，也不需要为了展示协作而拆成五个。分工应让责任更清晰，而不是让轨迹更热闹。

人工介入必须能够改变任务，而不是只点同意

人在回路不仅是批准按钮。负责人可能修改预算幅度、排除对象、补充原因、要求重新计算、延迟到促销后或终止任务。系统应把这些操作记录为结构化决定，使后续步骤使用新约束，并在评测中区分 Agent 建议与人工修订。

当同类建议长期被修改，说明策略或上下文存在缺口。可以把修订样本汇总为 Evals 数据，交由 Evolve 生成候选改进；但某次人工操作不应立即改写全局策略。个案处置、政策变更和模型优化属于三个不同治理层。

生产 Harness 至少需要十类状态

一个可靠的长时程任务需要记录：目标与范围、输入快照、当前阶段、使用的策略与模型版本、工具调用、预算与资源消耗、待审批事项、外部回执、下一唤醒条件、结果与补偿状态。还要支持取消、超时、暂停、恢复、重放和升级。仅有 Prompt、memory 和循环次数限制，无法满足这些责任。

Palantir 产品矩阵的优势，是很多状态可以直接绑定 Ontology 对象、Action 与平台审计；不足是企业仍需设计自己的任务协议和业务状态。Machinery、Automate、Logic 或外部 Harness 提供执行机制，不会替团队定义什么叫“归因成熟”“可安全重试”或“需要客户批准”。

长时程 Agent 的核心不是更长的上下文，而是可持久、可恢复、可审批、可补偿的任务状态。模型负责某些认知步骤，状态机和工具合同负责让任务跨越时间与故障。

Evals 与 Evolve：Agent 演进不是让生产系统在线改写自己

Agent 产品进入运营以后，演示成功没有统计意义。一次正确回答可能来自偶然采样，一次成功工具调用也可能掩盖错误的对象选择。AIP Evals 为 Logic、Chatbot 函数和代码函数提供测试集、目标函数、评价函数、指标、版本比较、多次运行和实验；它还可以评价 Ontology 编辑，而不仅是文本相似度。

图 8：Evals 提供比较证据，Evolve 生成候选，人工与发布门禁控制进入生产（概念示意）

对于 Amazon Ads 预算 Agent，一套有效测试至少要覆盖：正确选择 profile 和 marketplace；拒绝归因未成熟数据；按花费与归因销售重新计算聚合 ACOS，而不是平均行级比率；检测库存和 Featured Offer 风险；限制预算增幅；保持幂等；在 API 部分失败时不重复成功动作；生成可供人工批准的 Proposal；执行后等待回执和对账。文本风格评分只能放在这些确定性门禁之后。

Evals 的 Experiment 可以组合模型、提示词和参数运行网格比较，观察效果、成本和方差。这里的关键不是追求一个总分，而是按责任层拆分指标：对象绑定准确率、策略约束通过率、工具参数正确率、动作可逆性、业务指标改善、成本和延迟。若把它们压成一个 LLM Judge 分数，系统无法知道失败发生在知识、计划、权限还是执行。

Evolve 是有边界的候选改进流程

AIP Evolve 的官方流程要求用户先定义 target、goal、validation strategy 和 limits，然后由多个 AI FDE Agent 检查工作流、创建测试用例、修改模型或提示、运行评测，并提交 Proposal 和活动轨迹供人工审查。官方示例允许限定最大迭代次数，并在基线与候选之间比较成本和测试结果。

这不等于生产 Agent 在运行时自行修改源代码、立即发布并继续操作业务。更准确的表述是：Evolve 把“发现改进机会—生成候选—验证—审查”自动化，而批准、分支合并和生产发布仍属于治理链。文章和演示若把它叫作“Agent 自进化”，必须把这个边界说清楚，否则读者会把离线受控优化误解为无监督在线自改。

轨迹比最终答案更适合评价运营 Agent

投放 Agent 最终可能只输出“预算增加 8%”，但这个数字之前应该有完整轨迹：读取了哪些对象；选用哪一版利润和归因口径；发现哪些反证；调用何种模型和工具；哪些规则阻断过候选；谁批准；提交哪个幂等键；Amazon API 返回什么；平台状态何时对账；七天后怎样判断业务影响。没有轨迹，正确结果也不能被组织复用。

Evolve 的长期价值取决于这些轨迹能否沉淀为训练和验证资产。失败的工具参数可以变成回归用例，被人工否决的 Proposal 可以形成政策边界，API 部分失败可以成为恢复测试，归因成熟后的业务结果可以校准策略。Agent 不是因为“记住了更多对话”而进步，而是因为系统把生产后果转成了版本化证据。

可以自动化的是候选改进和验证，不应被省略的是责任批准。Agent 的“进化”只有在基线、测试集、限制、审查和回退同时存在时才是工程能力，否则只是不可追责的配置漂移。

Apollo：产品矩阵中最容易被低估的一层

多数数据和 AI 产品演示在“应用已经运行”之后开始，因此部署系统显得像后台基础设施。Palantir 把 Apollo 提升为主要平台，是因为其客户软件需要长期运行在环境差异极大的地方：标准公有云、客户私有云、本地数据中心、边缘节点以及连接不稳定或完全隔离的网络。若产品无法持续升级、安全修复、审计和回退，前面的 Ontology 与 AIP 只能停留在一次性交付。

图 9：Apollo 管理软件舰队的目标状态，业务动作仍需要独立补偿链（概念示意）

Hub-Spoke 让控制与执行适应不同连接条件

Apollo Hub 保存产品目录、环境信息、策略和编排逻辑；Spoke Environment 运行控制平面并汇报遥测，执行 Hub 下发的 Plan。一个 Hub 可以管理多个 Spoke，环境可以有不同网络、维护窗口、合规和稳定性要求。Apollo 不假定所有环境时刻在线，也不假定所有环境必须运行相同版本。

这一点区别于最简单的 CI/CD 流水线。CI 可以构建镜像并推送，CD 可以部署到几个已知集群；Apollo 还要持续解析产品与环境约束、依赖、发布通道和健康状态，为每个 Entity 决定可接受的版本与下一步计划。它管理的是长期软件舰队，而不是一次 Kubernetes apply。

Product、Release、Channel、Entity 构成部署语义

Apollo 把可部署软件表示为 Product，每个版本成为带代码和元数据的 Release；Release 进入不同 Channel，环境或 Entity 订阅满足稳定性要求的通道；维护窗口、依赖、数据库版本、批准与健康检查共同约束升级。出现问题时可以 Recall Release，阻止继续推出，并选择前滚到更高安全版本或允许降级到已知良好版本。

对于一个多客户 Amazon Ads 平台，可以把 API Connector、Report Normalizer、Budget Policy、Ontology Package、Agent Service 和 Operator App 作为不同产品或发布单元。高风险客户环境订阅 stable 通道，内部验证环境订阅 develop；新模型或策略先进入 canary；当某个版本产生错误预算 Proposal 时，召回的不只是 Prompt 文本，而是包含代码、依赖和部署说明的完整 Release。

合规变更是产品功能，不是交付附件

Apollo 能集成身份提供商，配置变更请求、批准者和团队角色，并把变更历史用于审计。官方材料还描述与 Prometheus、Datadog 等观察系统的集成、漏洞扫描和软件物料清单。对于受监管环境，这些能力决定“谁能让哪个版本进入哪个网络”；对于一般商业系统，它们同样决定紧急修复能否在不绕过审计的情况下完成。

Apollo 不替代业务动作回滚

需要区分两个回滚层次。Apollo 可以回退一个错误的 Agent Service 或策略函数版本，但无法自动撤销已经提交到 Amazon Ads 的预算、竞价或否定关键词变更。业务动作需要自己的补偿 Action、原值快照、幂等键和外部对账。软件回滚恢复“谁在做决策”，业务回滚恢复“系统已经改了什么”。两者必须在事故处理流程中衔接。

Apollo 解释了 Palantir 为什么把“软件交付”放进企业操作系统定义。只要 Ontology、应用和 Agent 会持续变化，发布版本本身就是运营事实。忽略 Apollo 的产品分析，只看 Foundry 与 AIP 的构建体验，会漏掉 Palantir 最难被普通数据栈直接复制的一部分。

Gotham：不是另一套 Foundry，而是面向任务空间的工作方式

Gotham 是 Palantir 最早形成市场认知的产品，但用“政府版 Foundry”概括它并不准确。两者共享数据整合、对象建模、搜索、分析和协作能力，差别主要体现在工作对象、任务节奏、连接环境与交付界面。Foundry 从企业经营、生产和供应链问题出发；Gotham 更强调把多源情报、地理空间、时间线、实体关系、告警和现场反馈放进同一个任务空间，支持分析人员与行动人员围绕正在发生的事件协作。

图 10：任务空间的重点是证据与行动连续性，不是地图或关系图本身（概念示意）

这一区别不是行业标签，而是产品设计约束。普通经营分析允许次日修正一条报表，任务系统可能需要在数据不完整、来源冲突、时间有限的情况下做出可追溯判断。对象是否来自可靠来源、某条关系是事实还是分析推断、谁在什么时刻看到了什么、一个结论被哪些证据支持，都会改变界面和权限模型。Gotham 的价值因此不只在图谱可视化，而在把分析对象、证据、任务和决策状态组织成连续工作流。

任务空间的五层结构

从产品责任看，一个 Gotham 式任务空间至少包含五层。第一层是多源数据及其来源，既保留原始记录，也保留解析、实体消歧和变换轨迹。第二层是任务对象，例如人员、组织、地点、事件、资产和观察。第三层是时空与网络分析，通过地图、时间线、关系图和搜索把对象放回具体环境。第四层是协作与任务状态，让团队能够共享调查、标注分歧、交接事项并追踪处置。第五层才是受控行动：在明确权限和证据的前提下，把分析结果送入外部系统或现场流程。

这五层可以借鉴到 Amazon Ads，但不能照搬国防术语。广告运营也有来源、对象、时间、关系和行动：搜索词报告、广告活动、商品、订单、库存、促销、Featured Offer、预算、竞价与否定关键词构成一个不断变化的运营空间。运营人员真正需要的不是“看见一张图”，而是确认异常从哪里开始、影响哪些目标、是否存在反证、该由谁处置，以及动作执行后怎样确认结果。

例如某个 ASIN 的广告转化率突然下降。传统看板会提示 CVR 下跌；任务空间还要把下降时段与价格调整、库存覆盖、商品详情页变更、Featured Offer 状态、搜索词结构、placement 流量以及竞品活动放到同一时间轴。运营人员可以看到：流量没有减少，点击成本也稳定，但 Featured Offer 丢失发生在转化下降之前。此时提高竞价并不是优化，而是在放大无法成交的访问。对象关系、时间顺序和证据来源共同改变了行动。

Gaia、地图和关系图只是界面，不是产品本体

Gotham 常被截图中的地图、节点和连线代表，容易让采购方误以为购买一套图数据库或 GIS 就能复制其能力。地图负责空间上下文，关系图负责网络上下文，时间线负责过程上下文，但真正困难的是同一个对象在不同界面保持相同身份、权限、状态和证据。若地图上的“广告活动”与预算系统里的 campaign、报表里的 campaignName 不是同一对象，界面再精致也只是并排展示。

因此，Gotham 对企业产品设计最有价值的启发是“任务空间先于组件清单”。先定义使用者在一个持续变化的问题里需要识别什么、判断什么、协同什么和执行什么，再决定地图、图谱、表格、模型或 Agent 的位置。把组件堆在门户里，不会自然形成任务空间。

Gotham 的可迁移能力不是“情报图谱”，而是以任务为单位组织来源、对象、证据、协作和行动。企业若只复制可视化界面，便复制了最容易的部分，遗漏了决定可信度的对象身份与责任链。

Warp Speed、医院方案与 AIP Now：垂直产品如何进入矩阵

Palantir 的官网还会出现 Warp Speed、FedStart、医院运营、保险、能源、汽车制造和 AIP Now 等名称。它们会让“产品矩阵到底有几层”再次变得模糊。判断方法仍然是问责任边界：它是否提供独立的基础运行时，还是把四个平台的能力按某类任务预先装配。

图 11：垂直方案缩短场景装配，但不形成第五套基础平台（概念示意）

Warp Speed 面向制造与供应链，把产品生命周期、采购、质量、生产、库存、供应商和工厂运营组织在同一套对象与应用中。医院方案会预置患者流、床位、人员、排班、供应链和容量等工作流。AIP Now 更接近一组按职能交付的 AI 方案，加快客服、销售、采购或运营场景起步。这些方案可能包含行业数据模型、Ontology 模板、Pipeline、Workshop 应用、Logic、Agent、指标和实施方法，但底层仍由 Foundry、Ontology、AIP 与 Apollo 承担。

垂直方案真正缩短的是语义发现周期

企业实施数据平台最慢的环节通常不是安装软件，而是把数据列翻译成可运营的对象、状态和动作。一个成熟的制造方案知道“物料短缺”不是库存表的一个筛选条件，而是采购承诺、生产计划、替代料、质量状态、运输时间和客户订单共同形成的业务状态；医院方案知道“床位可用”不能只读一列布尔值，还取决于清洁、设备、护理能力、科室与患者转运状态。

垂直方案的价值在于提供这种已经经过场景验证的语义起点、应用骨架和实施问题库。它减少的是从空白 Ontology 到第一个可用工作流的探索成本，而不是免除企业自己的数据映射、政策选择和责任确认。企业仍要决定本组织如何定义缺货、风险、利润、授权和升级条件。

预制行业对象不等于行业真相

模板越完整，越容易造成“供应商已经替组织定义业务”的错觉。两个 Amazon Ads 经营团队可能对同一个“可扩量商品”给出不同条件：一个要求库存覆盖 45 天、TACOS 不超过目标且 Featured Offer 稳定；另一个处于新品期，允许短期亏损但限制总现金消耗。平台可以预制对象和策略接口，却不能替代经营者选择目标函数。

因此，垂直方案应作为可修改的参考模型，而不是不可讨论的最佳实践。验收时至少要追问：预制对象的数据依赖是什么；指标口径由谁批准；Action 会修改哪些外部系统；默认策略在什么条件下失效；行业模板升级时如何处理本地扩展；供应商实施团队离开后，内部团队能否解释每一条关键决策。

Bootcamp 是销售与交付机制，也是产品证据

Palantir 以 AIP Bootcamp 在短周期内让客户使用自己的数据构建实际工作流。这种方式的合理之处是把产品讨论从功能清单推进到具体决策：选一个业务问题，接入必要数据，建立对象与动作，形成可操作原型，再根据结果决定是否扩大范围。它比持续数月的抽象平台规划更容易暴露数据权限、动作风险和使用者真实需求。

但 Bootcamp 的成功不能直接等同于生产成功。原型可能依赖小样本、人工清洗、宽松权限或供应商专家；生产系统还要处理全量性能、历史回放、异常输入、连接故障、版本升级、审计、值班和内部所有权。短周期验证应证明一条价值链存在，不应被用来跳过生产门禁。

垂直方案最有价值的资产是经过场景验证的语义、工作流和实施顺序，而不是又一个产品名称。模板能缩短发现周期，不能替企业决定经营目标、风险偏好和责任归属。

把整套矩阵放进 Amazon Ads：一条可审计的运营闭环

只有把四个平台、Ontology、应用与 Agent 放进同一个业务闭环，产品矩阵才不再是官网导航。下面以“在利润和库存约束下调整 Sponsored Products 预算与竞价”为参考场景。它不是对 Amazon 或 Palantir 现成功能的声称，而是依据两边公开接口构造的可实施架构。

图 12：从多速率数据到对象、策略、Proposal、批准、执行和结果观测的参考架构（概念示意）

输入不是一张广告报表，而是多条不同时间语义的数据流

广告 API 提供 campaign、ad group、target、keyword、budget、bid 与报告对象；Amazon Marketing Stream 以小时级推送部分广告表现与预算使用事件；Amazon Marketing Cloud 在隐私安全环境中支持跨广告、受众和转化分析；Seller Central 或其他授权接口提供订单、商品、价格、库存和 Featured Offer 等经营事实。财务系统还会提供 COGS、物流、退款、促销和汇率。

这些输入不能直接横向拼表。报告有生成延迟与归因窗口，Stream 事件接近实时但覆盖范围和用途不同，订单会退款，销售额不等于利润，广告归因订单也不等于全部订单。系统首先需要保留事件时间、到达时间、报告日期、归因成熟度、来源和版本，随后才能形成可比较的运营事实。

Foundry 在这里承担连接、解析、质量、谱系、调度与数据产品责任。原始层保留 API 响应和文件；标准层统一 profile、marketplace、currency、time zone、campaignId、adGroupId、targetId、ASIN 与 SKU；事实层分别保存点击、花费、归因转化、自然订单、退款、库存快照和价格状态；决策层再生成满足时点和口径约束的特征。任何直接把广告报表覆盖为“当前真相”的设计，都会失去重算和追责能力。

Ontology 把数据表翻译成可管理的运营对象

参考 Ontology 可以包含 Advertiser、Marketplace、Portfolio、Campaign、AdGroup、Target、SearchTerm、ASIN、SKU、Offer、InventoryPosition、BudgetPolicy、BidPolicy、AttributionWindow、OptimizationRun、Proposal、Approval、ExternalChange 和 OutcomeObservation。对象属性来自数据，但对象身份不应依赖会变化的名称。

关系用来表达业务边界：Campaign 属于 Portfolio 和 Advertiser；Target 位于 AdGroup；ASIN 与 Target 之间可能有投放关系；SKU 在具体 marketplace 与仓储网络中形成库存位置；Proposal 引用一组 EvidenceSnapshot；ExternalChange 记录执行回执；OutcomeObservation 连接动作前后的可比窗口。关系不是为了画图，而是为了限定计算、权限和影响范围。

逻辑层至少包含四类内容。第一类是指标逻辑，如 spend、attributedSales、ACOS、TACOS、contributionMargin、inventoryDays。第二类是状态逻辑，如 ATTRIBUTION_PENDING、OUT_OF_BUY_BOX、LOW_INVENTORY、BUDGET_CAPPED、READY_FOR_REVIEW。第三类是政策逻辑，如预算日增幅上限、利润底线、探索预算、品牌保护和禁止时段。第四类是决策逻辑，将状态、政策和预测组合成候选动作。

行为层通过 Action Type 公开少量受控能力：CreateBudgetProposal、ApproveProposal、RejectProposal、ApplyCampaignBudget、ApplyTargetBid、AddNegativeKeyword、PauseTarget、RollbackExternalChange。每个 Action 定义允许修改的对象、输入、校验、权限、副作用、通知和审计字段。Agent 不直接获得一个“执行 SQL”或“调用任意 HTTP”的万能工具，而是只能使用这些业务合同。

AIP 负责提出、解释与评价，而不是重新定义事实

运营人员可以在 Workshop 或专用 OSDK 应用中选择优化范围、目标和风险上限。AIP Logic 读取当前 Ontology 对象，调用预测模型、政策函数和必要的外部工具，生成多个 Proposal。Chatbot 可以解释为什么某个 campaign 被排除、哪些证据支持候选、如果把利润底线降低两个百分点会发生什么。Evals 在发布前和定期回归时验证对象选择、计算、工具参数、拒绝路径和业务约束。

大模型适合处理意图解释、非结构化上下文、候选计划与自然语言说明，不应该承担精确金额汇总、权限判断和最终写入。ACOS 与利润由确定性函数计算，策略边界由政策函数执行，对象权限由平台强制，外部动作通过明确 Action 提交。模型可以建议把预算从 500 元提高到 550 元，但平台必须独立验证增幅、库存、归因成熟度、账户权限和幂等状态。

Apollo 负责让闭环在不同客户环境中持续一致

同一套投放能力可能部署给多个品牌、代理商或地域团队。不同环境有不同 Amazon profile、市场、财务口径、模型、维护窗口和批准流程。Apollo 可以把 Connector、Ontology Package、Policy Functions、Agent Logic 和 Operator App 分别版本化，通过通道逐步推出，并在遥测异常时停止传播或召回版本。

这种版本治理使业务事故能够定位到“哪一个环境、哪一版策略、哪一版 Ontology、哪一次 Agent 运行”。如果一版 currency normalization 函数导致预算计算错误，可以召回软件 Release；如果错误预算已经提交，则由 ExternalChange 保存原值，通过 RollbackExternalChange 执行业务补偿。软件发布与业务动作在审计中相遇，但不混成同一个概念。

为什么必须同时保留实时、归因和经营三条时间线

投放决策最常见的错误之一，是把“刚发生的流量信号”与“已经成熟的业务结果”当作同一时点事实。Marketing Stream 可以快速揭示预算消耗、点击和部分转化变化，适合节奏控制和异常发现；报告和 AMC 提供更完整的归因观察，适合效果分析；订单、退款、成本和库存形成经营结果，决定增长是否可持续。

因此，决策对象需要明确三条时间线。操作时间线回答平台现在发生什么，例如预算即将耗尽；归因时间线回答某一投放窗口最终带来多少广告归因结果；经营时间线回答订单是否退款、毛利是否兑现、库存是否被消耗。实时控制不能等待所有归因成熟，但也不能拿未成熟数据宣布策略胜利。系统应为不同动作设定不同证据门槛。

预算节奏可以使用近实时信号，但日预算上调仍要检查稳定基线和库存；搜索词迁移需要足够点击和转化样本，并考虑自然流量与品牌词；大规模否词需要更长观察和人工复核；利润策略必须等待成本、退款和汇率进入可接受成熟状态。这些不是“模型参数”，而是业务语义和风险政策。

从发现到执行：一次预算动作的完整时序

假设系统在下午两点发现一个高利润 campaign 按当前速度会在傍晚前耗尽预算。事件处理函数创建 BudgetPacingAlert，并记录观测窗口、数据到达状态和预算剩余。策略函数通过 Ontology 追踪到该 campaign 所推广的 ASIN、对应 SKU、库存覆盖、Featured Offer、利润政策以及当天已发生的其他变更。

图 13：Agent 只参与时序中的候选与解释，平台门禁贯穿读、批、写、验（概念示意）

若归因尚未成熟，系统不会用当天 ROAS 证明扩量正确，而是读取过去 14 个已成熟日的 placement、点击、转化和边际利润分布，结合当天流量节奏构造保守候选。AIP Logic 可以提出三个 Proposal：保持预算；提高 8% 以延长有效时段；提高 15% 并降低低价值 placement 竞价。确定性函数分别计算最大现金暴露、库存消耗和利润下界。

政策检查排除超过日增幅上限或库存安全线的候选，Evals 运行针对参数、对象范围和工具调用的在线前检查。Agent 生成解释，列出支持证据与反证；拥有 portfolio 权限的运营负责人批准第二个 Proposal。ApplyCampaignBudget Action 再读取最新对象版本，若预算或 Featured Offer 已被其他操作改变则拒绝执行，避免基于过期快照写入。

连接器提交 Amazon Ads API，请求使用幂等键并保存响应。成功后 ExternalChange 标记为 APPLIED；部分失败则拆分已成功和待重试对象，不重复提交成功项。数小时后系统确认新预算生效；归因成熟后创建 OutcomeObservation，将动作前基线、动作后结果、外部干扰与置信区间关联到 Proposal。结果既进入运营复盘，也成为下一版评测数据。

一个生产级投放 Agent 的最小输出不是建议文本，而是 Proposal：明确对象、证据快照、策略版本、预期收益、最大风险、批准要求、执行合同和回退路径。缺少其中任何一项，所谓智能都无法进入运营责任链。

安全：Agent 获得的应该是能力租约，不是超级账号

把生成式 AI 接进运营系统以后，安全问题不再只是“模型能否看见某份文档”。一个 Agent 可能读取对象、调用函数、创建 Proposal、触发 Action、等待回执并启动后续流程。每多一层能力，就增加一类可造成实际后果的权限。Palantir 的产品矩阵把安全放进 Ontology、应用、AIP 和 Apollo 各层，原因正是读取、推理、执行与发布不能由一个开关统一决定。

图 14：每一层都减少 Agent 能造成的最大影响，并保留独立审计证据（概念示意）

数据权限、对象权限和动作权限是三件事

数据权限回答用户能否访问底层 dataset 或文件；对象权限回答用户或应用能否看见某类对象、某个对象以及其中的敏感属性；动作权限回答当前身份能否在满足条件时执行某种业务变更。它们可以相关，但不应互相替代。

一个代理商分析师可以查看 campaign 的公开绩效，却未必能看见品牌的商品成本；他可能有权创建预算 Proposal，但无权直接执行；财务负责人可以查看利润与现金约束，但不能修改关键词；自动化服务身份只能执行已批准、金额受限、位于特定 portfolio 的 Action。若系统只做页面角色控制而不在对象和 Action 层强制，Agent 或外部 API 很容易绕过界面边界。

属性级安全标记解决同一对象中字段敏感度不同的问题。Campaign 对象的名称、状态和预算可以对运营团队开放，内部成本、利润下界或合同返点可以只允许财务角色读取。大模型构造上下文时应继承调用者权限，不能先读取完整对象再要求 Prompt “不要透露敏感字段”。安全过滤必须发生在检索和工具执行层，而不是生成答案之后。

应用范围决定 Agent 能够接触的业务表面积

OSDK 与 Ontology MCP 都强调应用需要声明 Ontology 范围。这个范围是一份能力清单：应用能访问哪些对象类型、函数和 Action Type。生产 Agent 不应接入整个企业 Ontology，只应获得完成当前任务所需的最小对象与动作。例如预算 Agent 可以读取 Campaign、Target、InventoryPosition 和 BudgetPolicy，创建 BudgetProposal，并在批准后调用 ApplyCampaignBudget；它不需要修改商品价格、供应商合同或员工信息。

范围仍然不是全部。相同 Action 在不同对象、金额、时间和状态下风险不同，因此执行前还要做对象实例权限、条件校验、额度、频率、维护窗口和批准检查。可以把一次授权理解为“能力租约”：谁在什么上下文中，于多长时间内，对哪些对象，以多大影响上限，使用哪一版工具。租约到期或上下文变化后重新判断，而不是给 Agent 一张长期万能密钥。

读时控制与写时控制必须闭环

读时控制避免 Agent 接触无权数据；写时控制避免它对错误对象产生副作用。两者之间还需要证据绑定。Agent 生成 Proposal 时记录所读对象的版本或快照；Action 执行前执行乐观并发检查。如果库存、预算、Featured Offer 或策略版本已经变化，旧 Proposal 应被判定过期，要求重新计算。否则权限虽然正确，行动依据却已经失效。

外部系统写入增加了第二个状态源。Amazon Ads API 返回成功不代表下游报告已经反映变更，超时也不代表写入失败。连接器必须保存请求、幂等键、响应、重试和后续查询，区分 SUBMITTED、APPLIED、REJECTED、UNKNOWN 和 RECONCILED。UNKNOWN 状态不应盲目重试有副作用的请求，而应先查询外部系统或交给人工处理。

分支、Proposal 与审批不是拖慢智能，而是隔离不同责任

Foundry 的 branching、AI FDE 的 Pull Request 或 Proposal、Logic 的暂存写入以及 Action 的审批，共同表达一个原则：生成候选的人或模型不必拥有让候选进入生产的最终权力。对于低风险、高频、可逆动作，可以在策略范围内自动批准；对于大额、跨账户、难撤销或证据不足的动作，必须升级给责任人。

这不是要求所有 Agent 永远停留在“只建议”。自动化程度应由风险决定，并且能够逐级提高。一个新策略可以先影子运行，只记录本来会做什么；通过历史回放后进入 Proposal 模式；积累足够准确率、稳定性和业务结果后，对小额动作开放自动执行；遇到数据质量下降、模型漂移或外部故障时自动降级回人工审批。自治是一条可撤回的授权曲线，不是产品上线时的一次性选择。

发布权限和业务权限要由不同控制面管理

AI FDE 或工程师可以修改 BudgetPolicy 函数，不代表他有权批准某个客户的预算；运营负责人可以批准预算，不代表他有权把未测试代码发布到生产。Apollo 管软件版本、发布通道和环境合规，Ontology Action 管业务对象与动作。把两个控制面分开，才能在事故中回答：错误来自策略版本、模型版本、数据版本，还是一次在正确软件上作出的错误业务判断。

Prompt 不是安全边界，聊天窗口也不是权限系统。生产 Agent 的权限应表现为可审计、可到期、受对象和影响范围约束的能力租约，任何外部副作用都必须留下可对账状态。

Palantir 能不能用开源和云服务拼出来

从单项能力看，几乎每一层都有成熟替代。数据连接可以使用 Airbyte、Fivetran 或云原生服务；批流处理可以使用 Spark、Flink、dbt 与仓库计算；目录和血缘可以使用 OpenMetadata、DataHub 或云治理产品；图存储可以使用 Neo4j、RDF 数据库或属性图；语义层可以使用 dbt Semantic Layer、MetricFlow、Cube 或定制 DSL；应用可以用 React 与低代码平台；Agent 可以用主流编排框架；评测和观测也有独立产品；部署则有 GitHub Actions、Argo CD、Flux、Kubernetes 与云厂商平台。

图 15：替代组件并不稀缺，稀缺的是跨组件保持一致的运营语义（概念示意）

所以问题从来不是“有没有替代组件”，而是这些组件之间是否共享同一套身份、对象、策略、动作和版本语义。自行组装的成本主要发生在连接处，而且连接成本不会在第一版上线后结束。

数据目录不能自动成为运营 Ontology

目录擅长登记表、列、负责人、质量、血缘和术语；指标层擅长定义聚合口径；图数据库擅长存储和查询关系。它们都可能参与 Ontology，但不会自动提供对象编辑、Action 合同、应用权限、函数运行、分支、变更审计和外部写回。若企业选择组合式架构，需要明确由谁承担这些缺口，而不是把多个“语义”产品名称相加。

一个可行的替代架构可能使用仓库保存事实，语义层管理指标，知识图谱保存对象关系，策略服务执行业务规则，工作流引擎处理长时程状态，权限服务授权，Agent Harness 编排模型和工具，应用层承载人工审批，事件总线传播状态，GitOps 管理版本。它能工作，但必须建立一致的对象 ID、Schema 合同、策略版本、Action API、幂等协议和审计事件。

集成成本集中在六个接缝

第一个接缝是身份：数据源主键、图节点、应用对象和外部 API 对象能否稳定对应。第二个是时间：批表、流事件、归因结果和动作回执能否在同一决策快照中解释。第三个是权限：仓库行列权限、图权限、应用权限和工具权限是否保持一致。第四个是事务：对象修改与外部副作用如何处理部分失败、重试和补偿。第五个是版本：数据、指标、规则、Prompt、模型、应用和部署能否共同回放。第六个是所有权：跨团队故障由谁值班，升级哪一层，如何判定恢复。

Palantir 的集成优势就在这些接缝已经被产品化，至少在供应商定义的平台边界内拥有统一约定。它并不意味着接入外部系统没有集成成本，也不意味着 Ontology 会自动正确。企业支付的价格，很大一部分是在购买一套已经协调过的控制面、实施经验和责任模型。

开放接口降低锁定，不会消除语义迁移

Palantir 提供开放数据格式、SQL、API、OSDK、Platform SDK、MCP 和多种计算互操作路径，公开 OSDK 代码也改善了客户端透明度。这些能力使数据和部分应用逻辑能够与外部工具协作，是退出评估的重要正面因素。

但真正难迁移的资产不是文件，而是 Ontology 中的对象定义、派生逻辑、Action Type、权限、Workshop 应用、Logic 工作流、评测、运营轨迹和团队习惯。把 Parquet 导出不等于恢复原有运营系统。采购前应要求构建可验证的退出清单：原始和派生数据如何导出；对象 ID 与 Schema 如何保留；策略函数能否在外部运行；Action 审计怎样迁移；应用依赖哪些专有组件；多长时间可以恢复关键闭环。

自建和采购之间还有混合路线

组织不必在“全部 Palantir”和“全部自建”之间二选一。可以让 Foundry 与 Ontology 承担高价值运营闭环，继续使用现有仓库与 BI；可以只通过 OSDK 构建外部应用；可以把外部模型接入 AIP；可以让 Ontology MCP 为其他 Agent 平台提供受控工具；也可以将 Apollo 用于独立软件舰队。混合路线的前提是先画清系统记录、决策记录和执行记录分别在哪里。

若企业已经有成熟数据平台、统一身份、策略服务、工作流引擎和应用工程团队，Palantir 的增量价值可能集中在 Ontology 与交付速度；若企业的数据和责任长期碎片化，平台可能带来更大整合价值，也可能因组织无法提供真实所有者而失败。产品选择应由现有能力缺口决定，而不是由供应商演示的完整度决定。

Palantir 的主要护城河不在某个算法或画布，而在把数据、对象、动作、权限、评测和发布的接缝产品化。自建方案的可行性取决于组织能否长期拥有这些接缝，而不是能否列出功能相似的开源项目。

产品验证：不要看一场顺滑演示，要做六组破坏性测试

产品矩阵越完整，演示越容易沿一条准备好的理想路径运行。买方真正需要验证的是边界：数据迟到会怎样，身份冲突会怎样，动作只成功一半会怎样，模型换版会怎样，环境断网会怎样，关键人员离开会怎样。破坏性测试不是为了证明产品失败，而是确认失败能否被看见、限制和恢复。

测试一：故意制造两种粒度和三种时间

准备 campaign 日报、target 小时报表与订单行级数据，让同一销售结果分别按事件时间、报告日期和到达时间出现。要求平台计算行级与聚合 ACOS、解释未成熟归因、在回填后重算历史，并指出受影响的 Proposal。若演示只能在预先汇总的宽表上完成，Foundry 的血缘和构建价值尚未得到验证。

接着故意让部分 profile 使用不同时区、币种与 marketplace 映射，观察系统是否在模型层显式处理，而不是由分析师在查询里临时修正。验收结果应包含原始记录、转换版本、质量门禁、对象状态和最终指标之间的可追踪路径。

测试二：制造对象身份冲突

让两个 Campaign 使用相同名称，让一个 ASIN 对应多个 SKU，让 SKU 在不同 marketplace 具有不同库存和价格，并让一个 target 在历史上被删除后重建。要求 Object Explorer、Workshop、OSDK 应用和 Agent 始终选择正确对象，且关系基数与有效时间可解释。

这个测试验证 Ontology 是否真的提供稳定身份，而不是给报表字段套别名。还要修改底层 Pipeline 的字段与表结构，在保持 Ontology 合同兼容的前提下重新构建，观察应用是否继续工作。若每次数据变化都要求修改页面和 Prompt，对象抽象没有发挥作用。

测试三：让权限在链路中间发生变化

用三个身份运行相同任务：只能查看绩效的分析师、可以创建 Proposal 的运营负责人、可以批准一定额度动作的客户管理员。让其中一个对象含受限成本属性，并在 Agent 已生成候选、尚未执行时撤销批准者权限。预期结果不是页面隐藏按钮，而是工具调用和 Action 提交在服务端被拒绝，轨迹记录拒绝原因，敏感属性从上下文中消失。

还应检查外部 OSDK 与 Ontology MCP 客户端是否继承相同边界，避免 Foundry 内部应用安全、外部 Agent 却使用宽权限服务账号。若必须给所有 Agent 共用一个超级账号，产品方案不满足生产要求。

测试四：让外部动作出现部分失败和未知状态

选择十个预算变更，使其中六个成功、两个明确拒绝、两个请求超时但实际已生效。要求系统不重复提交六个成功项，不把超时直接标为失败，能够查询外部状态、拆分重试、保存原值并对已生效动作执行补偿。运营人员应在一个任务中看到每个对象的状态，而不是只收到“8/10 成功”。

这个测试同时检验 Action、连接器、Workflow 和 Ontology 状态模型。若系统需要人工到广告控制台逐项对账，再在聊天里告诉 Agent 结果，行动闭环并未建立。

测试五：让新版本在小范围制造回归

准备一版会错误处理币种的策略函数、一版成本更高但文本表现更好的模型配置，以及一版改变 Action 参数的 Ontology。要求平台通过分支和测试发现不兼容，在 canary 环境部署候选，Evals 显示对象、工具、成本和业务护栏差异，Apollo 阻止问题 Release 扩大，并能召回版本。

随后验证业务动作是否另有补偿。若软件回退成功，但已错误提高的预算仍留在 Amazon，必须由独立的 ExternalChange 与 Rollback Action 处理。这个测试可以迅速区分“代码部署治理”和“运营后果治理”。

测试六：断开环境与供应商人员

在允许的测试环境中模拟 Hub 与 Spoke 连接中断，确认本地工作负载、身份、日志和队列怎样表现，恢复连接后怎样对账。对于计划部署在本地、边缘或隔离网络的客户，这比观看多云架构图更重要。还要验证遥测、模型调用、外部 API 和更新分别依赖哪些网络路径。

最后让非原实施人员完成一次策略修改、对象扩展、评测、发布和事故回滚。要求只使用交付文档、代码、Ontology 说明和平台轨迹。若任务只能由供应商 Forward Deployed Engineer 完成，平台技术可能可用，但客户所有权尚未建立。

验收证据应被保存为可复用资产

每组测试需要保存输入、预期、实际结果、截图或日志、版本、运行者、异常和修复，不应只留在采购会议纪要。通过测试的路径成为回归套件，失败路径进入实施待办，高风险未知项进入合同和上线门禁。未来升级 AIP、Ontology 或 Apollo 时重复执行同一组测试，才能判断产品变化是否破坏本地运营模型。

这套方法也适用于自建替代方案。对比双方时使用相同对象、数据、故障和验收指标，才知道差别来自平台能力、实施质量还是演示准备。若 Palantir 方案通过六组测试，而替代方案只比较许可证和功能列表，结论没有可比性；反之亦然。

产品尽调的单位不应是功能，而应是受压后的闭环。只有当事实错误、身份冲突、权限变化、部分失败、版本回归和环境中断都能被限制与恢复，产品矩阵才从演示架构变成可运营系统。

商业与交付：产品矩阵为什么离不开 Forward Deployed 模式

Palantir 的产品边界很难只通过公开价目表理解。年报把软件平台、云基础设施、持续运营支持和专业服务放在整体客户关系中披露，并说明合同结构、取得客户与扩展部署具有复杂性。对买方而言，这意味着“购买 Foundry 或 AIP”往往不是订阅一个标准席位，而是围绕环境、容量、范围、实施和支持形成组合合同。

前线工程不是附带实施，而是语义翻译机制

Forward Deployed Engineer 或类似交付角色之所以重要，是因为平台接近业务动作以后，需求无法由通用连接器完整表达。工程师需要与运营人员共同识别对象、状态、规则、例外、权限和动作，把隐性业务知识转为 Pipeline、Ontology、应用与测试。AIP Bootcamp 把这一过程压缩到短周期，让客户用自身数据验证一个具体用例。

这种模式创造了速度，也产生依赖风险。若关键逻辑只存在于顾问脑中，客户无法独立维护；若为了快速演示而绕过数据质量、权限和异常路径，原型越成功，后续返工越大。合同和项目计划应把知识转移设为明确交付物：对象词典、Action 合同、数据责任、评测集、发布手册、事故流程和退出映射都要由内部人员验收。

Land-and-expand 与 Ontology 扩展天然相互强化

从一条高价值闭环开始，平台可以复用数据、对象、权限和应用能力扩展到相邻流程。Amazon Ads 的预算闭环稳定后，可以增加搜索词治理、库存协同、促销规划和利润预测；Campaign、ASIN、SKU、Marketplace 与 Proposal 等对象无需重建。每个新场景增加 Ontology 的覆盖，已有场景又为新场景提供数据与动作基础。

这形成很强的扩展效应，也形成切换成本。对象、应用和决策轨迹越丰富，平台越有用，迁移越复杂。买方不必把这种效应一律视为负面锁定，但应主动管理：保持源数据可导出，关键计算有独立测试，Action 合同有外部描述，业务标识不依赖页面名称，定期演练关键闭环的降级路径。

价格比较必须统一责任范围

拿 Palantir 平台报价与单一数据仓库、图数据库或 Agent 框架的许可证直接比较，没有意义。若 Palantir 方案包含数据集成、对象运行时、应用、模型治理、评测、发布与实施，替代方案也要把这些责任的产品、云资源、集成工程、长期维护和事故成本计算进去。反过来，不能因为矩阵能力完整，就把尚未使用的能力都算作已实现价值。

更可操作的做法是为目标闭环建立五年责任清单：每项能力由哪个产品和团队承担，首年建设和后续变更分别需要多少投入，关键人员离开是否可接替，故障恢复需多久，扩展到第二个场景可以复用多少资产。比较的是承担同一责任的总成本与风险，而不是页面数量。

采购合同应把产品承诺翻译成可测条款

“支持多云”“开放”“安全”“可扩展”和“快速交付”都需要具体化。多云要落到支持的环境、控制面依赖和升级路径；开放要落到导出格式、API 范围、速率和退出协助；安全要落到身份集成、审计保留、属性权限和响应责任；可扩展要落到数据量、并发、延迟和测试方法；快速交付要落到目标闭环、前置条件和双方投入。

产品矩阵越大，合同中的责任空白越可能被双方用不同方式理解。买方应把六组破坏性测试、关键架构、数据驻留、模型供应、发布窗口、支持等级和退出要求附到验收与治理机制中。这样，产品研究才真正进入采购，而不是停留在技术欣赏。

Palantir 的交付模式本身就是产品的一部分：平台提供统一运行时，前线工程把组织隐性语义装进运行时。价值取决于该次语义翻译能否沉淀为客户拥有的资产，而不是长期依赖少数外部专家。

采购判断：什么组织适合，什么组织不适合

Palantir 的销售材料倾向展示复杂组织如何快速形成高价值应用，这是真实的产品目标，但不能替代买方尽调。平台越完整，实施对业务所有权、数据访问和变革能力的要求越高。一个组织若连预算由谁负责、利润口径由谁批准、错误动作由谁承担都无法确定，引入 Ontology 只会把未解决的组织分歧搬进软件。

更可能获得价值的组织

第一类是决策闭环跨越多个数据域和系统。以 Amazon Ads 为例，投放动作同时依赖广告、订单、价格、库存、成本、促销和现金流，单一广告 SaaS 无法拥有完整经营上下文。第二类是决策需要协作与审计，建议必须经过运营、品牌、财务或客户审批。第三类是应用会持续演进，组织需要让数据、逻辑、应用和 Agent 一起版本化。第四类是部署环境复杂，存在多云、本地、边缘、隔离网络或严格变更要求。第五类是单个闭环的业务价值足够高，可以覆盖平台和实施成本。

这些条件并不要求企业规模一定巨大。一个管理大量广告账户的服务商，若每次预算错误都产生显著损失，且需要在客户权限、策略版本和操作审计之间保持一致，也可能有类似需求。相反，一家大型企业若只想做几个只读问答助手，也未必需要完整矩阵。

不应优先选择的情形

若需求只是统一报表、少量 NL2SQL、文档问答或一个内部审批页面，成熟仓库、BI、语义层和轻量 Agent 组合通常更直接。若数据源少、动作风险低、部署环境单一，Apollo 与复杂 Ontology 的价值难以兑现。若组织没有愿意长期负责对象和策略的业务所有者，平台会依赖外部实施团队维持，知识无法内化。

另一个风险是把采购目标写成“建设企业级 AI 平台”。这句话没有可验收的业务结果，容易让范围覆盖所有数据、所有部门与所有 Agent。更好的起点是一条窄而重要的决策链，例如“在库存与利润约束下，把预算调整从两天缩短到两小时，同时将错误动作率控制为零并保留完整回放”。平台是否合适，应由这条链的效果、维护和扩展证据决定。

成本不能只算许可证

总成本至少包括平台订阅、云和计算、实施、数据接入、对象建模、应用开发、模型调用、内部人员、变更管理、值班、测试与退出准备。收益也不能只算节省工时，还应包含决策周期缩短、错误损失减少、库存与现金改善、软件交付稳定性以及新策略复用速度。

对于 Amazon Ads 闭环，可以建立具体基线：运营人员每周处理多少异常；从发现到执行耗时多久；多少动作因数据延迟或对象错误被撤回；预算浪费和缺货损失有多少；策略跨账户复用需要多久；事故定位需要多久。试点后对这些指标做前后比较，远比统计“创建了多少 Agent”更能说明价值。

供应商主张与客户证据应分开

本文大量使用 Palantir 官方文档，因为产品责任、命名和接口边界应以一手资料为准；但性能、投资回报、实施速度和行业成效不能只凭供应商材料确认。正式采购还需要客户访谈、合同条款、架构验证、负载测试、安全审查、退出演练和价格模型。官方文档可以证明“产品声称提供什么”，不能自动证明“它在你的数据、人员和流程中会产生相同结果”。

实施路线：先交付一个闭环，再扩展 Ontology

产品矩阵庞大时，最危险的实施方式是先把所有数据接入、所有对象建完、所有术语统一，再寻找业务应用。Ontology 不应成为无限期建模工程。它需要由具体决策牵引，在使用中发现缺少的对象、关系和动作，然后以兼容方式扩展。

第零阶段：定义决策合同

在接数据之前，先写一页决策合同：谁在什么频率下，为哪些对象作什么决定；需要哪些事实；允许的动作是什么；最大影响是多少；谁批准；怎样知道执行成功；多长时间后评价结果；怎样回退。以预算调整为例，必须先明确目标是销售、广告归因收入、贡献利润还是现金周转，不能用“提高 ROAS”代替经营目标。

合同还要列出拒绝条件。归因未成熟、库存不足、Featured Offer 丢失、成本缺失、当日已发生人工修改、账户处于促销冻结期、API 状态未知，都可能要求停止自动化。拒绝路径不是异常补丁，而是业务功能。

第一阶段：建立证据链，不做自动写入

接入最少数据，建立稳定对象身份、时间语义、质量检查和指标口径。系统只生成 EvidenceSnapshot 与 Proposal，由运营人员在现有广告控制台执行。此阶段验证数据是否足以支持判断，以及系统建议与人的实际操作是否一致。任何无法解释的差异都应回到对象、粒度、时间或政策层处理。

影子运行至少覆盖正常、高峰、促销、缺货和归因延迟等周期。团队要记录误报、漏报、对象绑定错误、计算误差和不可执行建议，并把它们转为回归测试。只看平均准确率会掩盖高影响长尾，因此还要按账户、marketplace、策略类型和影响金额分层。

第二阶段：把动作变成受控合同

为一到两个低风险动作建立 Action Type、幂等、原值快照、权限、审批和外部回执。系统进入 Proposal 模式，由人批准、平台执行。此时重点不是提高自动化比例，而是证明任何一次动作都能回答谁、为什么、改了什么、外部是否接受、后果如何、能否补偿。

只有当执行链稳定，才允许对小范围对象自动批准，例如预算调整不超过 5%、账户当日总影响不超过阈值、库存和利润状态正常、策略已通过指定评测版本。自动批准必须带到期时间与熔断条件，数据质量、错误率或外部 API 状态恶化时立即降级。

第三阶段：引入 AIP 与 Evals

将大模型放在它真正能增加价值的环节：理解运营意图、汇总非结构化背景、组织候选计划、解释证据和辅助异常调查。确定性计算、权限与写入保持在工具层。建立离线历史回放、合成边界样本、在线前检查和生产后评估四类测试。

版本比较不能只评价答案。一个候选 Agent 可能解释更流畅，却选择了错误 campaign；可能工具参数正确，却违反客户策略；可能短期销售提高，却消耗了断货前最后库存。Evals 要把结果、过程、可靠性和业务护栏拆开，失败样本自动进入数据集，但模型或 Prompt 的更新仍经过分支与审查。

第四阶段：扩展应用与多账户复用

当一条闭环稳定后，才将对象和动作扩展到竞价、搜索词、placement、否定关键词与促销协同。扩展时复用接口和策略模式，不复制整套应用。OSDK 可以构建面向客户的门户，Workshop 服务内部运营，Chatbot 支持调查，Automate 或 Machinery 处理跨时程流程。

多账户复用需要把共同语义与本地策略分开。Campaign、Target、Spend 等对象和指标可以共享；利润底线、探索预算、品牌词政策、审批额度与市场时区必须按租户配置。若为了复用而抹平差异，Ontology 会成为最低公分母；若每个客户都复制一套，升级和评测无法集中。

第五阶段：把平台交给内部所有者

生产所有权至少包括数据、Ontology、策略、应用、Agent、发布和业务运营七类责任。小团队可以一人承担多项，但不能无人负责。每类资产需要变更流程、质量指标、值班路径和退出方案。供应商或服务商可以帮助建设，关键对象和政策的最终解释权必须留在使用组织。

实施完成的标志不是 Bootcamp 演示、应用数量或 Ontology 对象数，而是关键闭环在没有原实施人员现场支持时仍能稳定运行、解释、升级和回退。

常见失败模式：产品能力齐全，运营系统仍然失败

把所有数据接进来，却没有决定要改变什么

平台团队容易以数据覆盖率衡量进度，结果构建大量 Pipeline 和对象，却没有一条可执行 Action。数据越多，建模和权限越复杂，业务使用者反而不知道从哪里开始。修正方式是以决策合同裁剪输入，只接入改变当前判断所需的证据。

把对象名称统一，当作语义已经统一

将多个系统的 campaign_name 映射为“广告活动”并未解决粒度、身份、时区和版本。真正的语义统一必须说明对象在何时存在、如何唯一识别、状态怎样变化、指标在哪个粒度计算、哪些 Action 可以作用于它。命名是入口，不是完成。

把 LLM 放在确定性计算和权限判断上

让模型读取一堆行并计算 ACOS、利润或预算上限，会引入不可必要的误差；让模型自己决定是否有权限，更是把安全交给概率输出。正确分工是模型形成意图与候选，函数计算，政策验证，平台授权，Action 执行。

只记录最终答案，不记录中间轨迹

当 Agent 建议错误时，团队无法判断是检索错、对象错、计算错、Prompt 错还是工具错；当建议正确时，也不知道能否复现。轨迹需要记录输入快照、工具调用、策略与模型版本、门禁结果、批准和外部回执。可观察性不是请求耗时图，而是决策证据链。

用软件回滚代替业务补偿

发布上一版 Agent 不会自动把广告预算改回原值。任何有副作用的 Action 都要设计原值快照、补偿动作和对账。不可逆动作则需要更高审批和更小自动化范围。没有业务补偿的“可回滚架构”只完成了一半。

把 Evolve 误解为生产自改

如果 Agent 根据当天结果直接修改 Prompt、工具或策略并立刻上线，数据延迟、归因偏差和短期波动会被放大。Evolve 的公开设计强调目标、验证、限制、候选 Proposal 和人工审查。即使未来自动化程度提高，基线、隔离环境、评测和发布门禁仍不能省略。

依赖实施专家，却没有内部产品负责人

Forward deployed 模式能快速跨越业务和技术边界，但也可能让关键语义停留在外部团队。内部负责人必须能够解释对象、策略、动作和评测，参与每次重要设计。否则平台上线后会变成昂贵、无人敢改的黑箱。

未来：从应用集合走向受治理的 Agent 舰队

Palantir 当前产品方向显示出一个清晰趋势：Ontology 不只服务人类应用，也成为 Agent 的工具和上下文层；AI FDE 参与平台建设；MCP 连接外部 Agent 与工具；Evals 与 Evolve 把轨迹转为受控改进；Apollo 把不同版本持续送到不同环境。过去由人通过页面串联的工作，正在变成由人和 Agent 共同运行的流程。

自然语言会成为入口，但不会成为系统记录

Pilot、AI FDE、AIP Logic 与 Chatbot 都提高了自然语言参与构建和运营的程度。用户可以描述应用、查询对象、生成逻辑或发起任务。然而系统最终仍需要 Schema、函数、Action、权限、测试和版本。自然语言降低表达门槛，不消除工程资产；越接近生产副作用，越需要把模糊意图编译成确定合同。

这也解释了 NL2SQL 为什么只是早期形态。查询回答“发生了什么”，Ontology 和 Action 进一步回答“这些结果属于哪些运营对象、当前处于什么状态、可以做什么、谁能做、后果如何记录”。未来智能产品的差异不会只看能否生成 SQL，而要看它能否在企业语义和治理边界内完成一条长时程任务。

MCP 会扩大工具生态，也会放大授权问题

MCP 让外部 Agent 发现和调用 Palantir 能力，也让 Foundry Agent 使用外部服务。协议降低适配成本，却会让工具数量与组合迅速增加。未来治理重点将从单个工具权限转向调用链权限：一个只读工具的结果可能进入写工具；外部服务可能保存敏感上下文；多个低风险动作组合后可能形成高影响结果。

因此，企业需要为工具声明数据分类、允许调用者、影响等级、幂等性、人工门禁、可观测字段和补偿方式，并对跨工具计划做整体风险计算。Ontology 可以提供业务对象和 Action 语义，Agent Harness 还要负责长时程状态、预算、重试、暂停、恢复与升级。

评测将从模型质量扩展到运营质量

未来 Agent 评测不会停留在问答准确率。系统要评价任务是否选对对象、是否遵守政策、是否在正确时间行动、是否处理并发和部分失败、是否改善真实结果，以及改善是否来自 Agent 而不是季节或促销。评价窗口可能跨越数天甚至数周，需要把运行轨迹与成熟业务结果重新连接。

这会使 Ontology 中的 OptimizationRun、Proposal、ExternalChange 和 OutcomeObservation 成为一等对象。没有这些对象，Evolve 只能优化离线文本；拥有它们，组织才能用生产结果更新测试集、调整策略和逐步扩大自治范围。

产品边界会继续变化，责任模型比名称更稳定

Agent Studio 更名为 Chatbot Studio、Pilot 与 AI FDE 扩展构建入口、Machinery 强化流程编排，都说明产品菜单仍会变化。分析时不必追求记住每一个名称，而应持续追踪九类责任：数据、对象、逻辑、动作、安全、应用、AI、评测与交付。新产品出现时，看它承担哪一类责任、是否形成新的运行时，以及与已有控制面如何衔接。

总结：用六道门判断 Palantir 是否形成完整运营系统

回到开头的问题。Palantir 的商业披露列出 Gotham、Foundry、Apollo 和 AIP 四个主要平台；当前技术架构把 AIP、Foundry 与 Apollo 组成标准架构；Ontology 位于核心；Workshop、OSDK、Logic、Chatbot、AI FDE、Evals、Evolve、Machinery、Pilot 和行业方案则是构建、使用、评测与交付能力。三个口径可以同时成立，因为它们回答不同问题。

图 16：六道门既是产品解剖框架，也是采购、试点和生产验收清单（概念示意）

真正理解产品矩阵，不需要背完整菜单。可以用六道门检查一条业务链是否闭合。

第一道是事实门：原始数据、粒度、时间、质量、谱系和版本能否被重算。第二道是对象门：数据是否被组织成有稳定身份、状态、关系和责任人的运营对象。第三道是决策门：指标、规则、模型和 LLM 是否各自承担合适责任，并形成明确 Proposal。第四道是行动门：Action 是否约束对象、参数、权限、副作用、幂等、回执和补偿。第五道是学习门：轨迹、评测、生产结果和候选改进能否被版本化审查。第六道是交付门：整套能力能否跨环境持续发布、观察、召回和恢复。

Amazon Ads 预算场景说明，任何一扇门缺失都会改变系统性质。没有事实门，它是不可重算的建议器；没有对象门，它是一组松散报表；没有决策门，它是规则或 Prompt 拼盘；没有行动门，它只能给人复制粘贴；没有学习门，它无法安全演进；没有交付门，它只能维持一次演示。

Palantir 最值得研究的不是四个品牌名，而是一种产品组织方法：让数据、业务语义、决策、行动、学习和软件交付共享一套可治理的运行时。企业是否需要它，取决于这条闭环的复杂度与价值，而不是是否想拥有一套更完整的 AI 平台。