本文是《拆解 Palantir：企业 AI 与 FDE 架构指南》第 2 篇。
Palantir 的标准架构由 AIP、Foundry 和 Apollo 三个平台组成。它们分别处理生成式 AI、数据运营和持续交付，但最终共同服务于一件事：让企业的软件系统能够理解业务、参与决策并持续演进。
三个平台的分工
Foundry：数据运营平台
Foundry 提供数据连接、数据管理、逻辑编写、Ontology 开发、分析和工作流开发能力。
它不是单纯的数据仓库。数据进入 Foundry 后，会继续被组织成业务对象和可执行流程，为应用、自动化和 AI Agent 提供稳定上下文。
AIP：生成式 AI 平台
AIP 负责安全连接大语言模型，并提供构建 Agent 和自动化所需的工具链。企业可以使用商业模型、开源模型、自有模型或经过微调的领域模型。
AIP 还提供生产治理能力，例如评估不同模型的表现、追踪 Agent 的执行链、观察令牌与资源消耗，以及管理上线后的版本迭代。
Apollo：持续交付平台
Apollo 管理承载 Foundry 和 AIP 的基础设施，并负责大量服务的安装、升级与回滚。
对企业软件而言，上线不是终点。客户环境可能分布在不同公有云、本地机房和边缘节点，并受到严格的安全与合规约束。Apollo 的任务，是让同一套软件能够持续、安全地抵达这些不同环境。
为什么称为企业操作系统
AIP 与 Foundry 的能力可以归纳为九组：
- Ontology 语言；
- Ontology 引擎；
- Ontology 工具链；
- 数据服务；
- 逻辑服务；
- 工作流服务；
- 分析与应用；
- 自动化；
- 产品交付工具链。
这些能力共享存储、计算、网络、安全、治理和工作区等基础组件，并由 Apollo 持续交付。
因此，Palantir 的目标不是让企业多买一个 SaaS，而是形成一套可以承载业务运行的数字系统。医院可以用它协调护理资源，航空公司可以规划航班网络，公共事业公司可以响应灾害，制造企业可以管理生产和供应链。
统一安全架构
安全不是一个独立插件，而是横跨三个层面：
- 基础设施层：采用零信任原则，根据身份、设备状态和验证结果控制访问，并假设攻击随时可能发生。
- 平台层：为人和 Agent 提供角色、分类标签和用途级权限，并记录数据血缘与操作审计。
- 企业层：接入组织已有的身份、授权、日志和安全工具。
当 AI 能够调用工具并执行业务动作时，权限必须精确到“谁能对什么对象执行什么动作”，传统的应用级登录控制远远不够。
平台如何扩展
Compute Modules 允许企业把容器化模型、优化器、数据处理运行时和定制应用接入 Palantir 的计算网格。
这意味着平台不要求所有能力都由 Palantir 提供。企业可以保留自己的算法和系统，只把它们纳入统一的编排、安全和治理体系。
追求 Alpha，而不是标准答案
Palantir 把标准化、所有客户都能使用的基础能力称为 Beta。真正产生竞争优势的 Alpha，则来自围绕客户独特业务进行的可维护定制。
企业需要把自己的对象、流程、约束和决策方式写入 Ontology，再围绕它构建应用、集成和 Agent。平台提供共同底座，但最终系统应该体现组织自身的运营特点。
FDE 如何连接现场与平台
FDE 工程师深入工厂、医院、作战环境或运营中心，与客户一起观察系统如何真正运行，再把现场反馈转化为产品能力。
这很像机器学习里的反向传播：前线不断产生误差和反馈，核心产品团队据此调整系统。每个客户部署既拥有自身差异，又能从平台的整体演进中受益。
小结
Foundry 负责组织数据和运营逻辑，AIP 让 AI 在安全边界内参与业务，Apollo 保证整套系统能够持续部署和升级。FDE 则把真实任务现场的反馈带回这个闭环。
三者结合后，AI 不再是悬浮在业务之外的问答工具，而会成为企业操作系统中的一类受控执行者。
参考资料
中文内容来源：https://x.com/oops073111/status/2095351043156754614
官方资料：https://www.palantir.com/docs/foundry/architecture-center/platforms