本文是《拆解 Palantir：企业 AI 与 FDE 架构指南》第 5 篇。
企业落地 AI 时，最危险的假设之一是：先把原来的软件和数据平台全部换掉，再建设一套新的 AI 系统。
现实中的医院不能为了接入 Agent 停止诊疗，制造企业不能暂停产线，航空公司也不能中断航班系统。AI 必须进入正在运行的业务，而不是要求业务为它重新开始。
Palantir 的互操作性正是为此设计：在提供统一体验与治理的同时，保留连接现有及未来系统的模块化能力。
数据互操作
平台建立在开放数据标准之上。数据可以继续保留 CSV、Apache Iceberg、Parquet 等格式，并通过 REST、JDBC、S3 兼容接口等标准方式访问。
转换后的数据默认也使用开放格式，方便其他系统继续消费。企业可以接入已有的数据平台、记录系统和数据服务，不必先把一切迁入新的专有存储。
Virtual Tables 还允许平台在不重复搬运数据的情况下使用 Databricks、Snowflake、BigQuery 等系统中的资产，并把计算下推到已有计算资源。
元数据互操作
数据要进入生产环境，仅有字段和值远远不够。平台还需要理解：
- 数据属于谁；
- 从哪里产生；
- 经过哪些转换；
- 当前是否健康；
- 哪些安全策略必须执行；
- 有哪些业务标签和增强信息。
Foundry 与 AIP 可以将这些元数据暴露给外部数据目录、元数据管理和主数据管理工具。项目、数据集、Ontology 元素、Agent、模型、分析、应用和流水线都能够纳入统一观察范围。
语义互操作
Ontology 对业务对象、链接、行动和函数进行细粒度定义。它表达的不只是字段含义，还包括真实业务流程可以执行的动作。
Ontology 元素可以通过 REST API 访问，并通过 JSON 配置。这使企业能够把现有领域模型、数据目录里的本体和 Palantir Ontology 双向同步，避免重复建立彼此隔离的语义体系。
代码与逻辑互操作
数据转换和分析逻辑可以使用 Python、Java、SparkSQL、R 等开放语言，运行在 Spark、Flink、DataFusion、Polars 等环境中。机器学习模型也能通过 ONNX 等开放格式交换。
代码保存在高可用 Git 服务中，可以从界面导出或通过 API 访问。Compute Modules 则允许团队引入自己的容器化运行时、模型、应用和可执行程序，并让它们参与数据管道、分析、应用和 AI 工作流。
分析互操作
Foundry 与 AIP 自带分析和应用工具，但企业不需要因此放弃原有工作方式。
Power BI、Tableau、Jupyter 和 RStudio 等工具可以继续使用同一批数据，同时获得平台提供的模型、权限和治理能力。Code Workspaces 也能在平台内部提供 Jupyter 和 RStudio 环境。
安全互操作
企业通常已经拥有成熟的身份、授权和审计体系。Palantir 可以对接 SAML 等认证系统，以及 Active Directory 等授权系统。
权限覆盖角色、数据分类和使用目的。通过 Ontology SDK，这些权限还可以延伸到第三方应用与定制系统。安全信息能够被动态查询，操作过程也可以回溯审计。
这对 Agent 尤其重要：Agent 不应获得一个绕开企业权限体系的超级账号，而应该在发起每次读取、计算和动作时接受与人类用户相同甚至更严格的检查。
互操作不等于连接器数量
连接器只能解决系统之间“能否传数据”的问题。真正的互操作还要解决语义是否一致、权限是否延续、操作能否审计、逻辑能否复用，以及写回后是否破坏原有流程。
因此，互操作性的核心不是拥有最多连接器，而是让数据、元数据、语义、代码、分析和安全在同一治理框架下双向流动。
对 AI FDE 的启发
面对客户已有系统，AI FDE 应该优先采用“纳管逻辑”：
- 识别关键业务流程和不可中断系统；
- 通过开放接口连接数据和动作；
- 继承现有权限、身份和审计机制；
- 用 Ontology 建立跨系统的共同语义；
- 在不破坏原流程的情况下逐步引入 Agent；
- 只有在价值明确时，才替换具体旧组件。
小结
互操作性让企业保留既有投资，同时把分散的能力组织成可以被 Ontology、应用和 AI Agent 共同使用的运营系统。对企业 AI 来说，这通常比“推倒重建”更现实，也更容易产生持续价值。
参考资料
中文内容来源：https://x.com/oops073111/status/2095358621123277236
官方资料：https://www.palantir.com/docs/foundry/architecture-center/interoperability