AIP、Foundry 与 Apollo：Palantir 企业操作系统的三层协作
如果只看产品名称，AIP、Foundry 和 Apollo 很容易被理解成三个独立产品：一个做 AI，一个做数据，一个做部署。Palantir Architecture Center 的核心观点是，三者应被看成一个协同运行的企业操作系统。
本文把三个平台放到 AI Agent 项目里解释：Foundry 负责业务数据和运营语义，AIP 负责生成式 AI 与 Agent 能力，Apollo 负责让整个平台在不同环境中持续交付和运行。
一句话理解三者
Foundry = 让企业数据和业务逻辑可操作
AIP = 让 AI 能理解上下文、调用工具并参与决策
Apollo = 让所有服务持续、安全、可回滚地运行
它们不是线性流水线，而是一个反馈系统：
数据与业务规则 → Ontology → Agent / 应用 / 自动化 → 真实操作
↑ ↓
└──────────── 结果、反馈、审计与新数据 ────────┘
Foundry：从数据资产到业务运营
企业里的数据分散在 ERP、CRM、工厂系统、IoT、财务系统、文档库和自研数据库中。Foundry 的职责不是简单把它们复制到一个新仓库，而是让数据经过连接、转换、治理和建模后服务于实际运营。
Foundry 的五个工作面
数据接入
接入批处理数据、实时流、外部系统和各种文件。接入时需要保留来源、时间、权限和血缘信息。
数据处理
用 SQL、Python、Java、Spark、Flink 或其他运行时完成清洗、转换、聚合和质量检查。
Ontology 建模
把数据映射成对象、属性、链接、动作和函数。它是连接数据与业务决策的中间层。
分析和应用
分析人员、业务人员和开发者在同一基础上构建分析、工作台和运营应用。
回写和工作流
将经过审批或授权的结果写回系统记录、工单、库存、调度或其他外部系统。
对 AI FDE 而言，Foundry 最重要的能力是把模型看到的上下文变成有来源、有状态、有权限的业务上下文。
AIP：不是模型 API，而是 AI 运营层
AIP 负责将生成式 AI 连接到运营领域。它包含模型接入、上下文工程、Agent 构建、自动化、评估、开发环境、应用和企业自动化。
AIP 处理的是一条执行链
一个生产 Agent 可能要完成：
- 识别用户意图；
- 查询 Ontology 中的对象和状态；
- 组合文档、指标、历史事件和规则；
- 选择工具或函数；
- 生成建议或执行动作；
- 写入结果和审计记录；
- 根据后续反馈进行评估和改进。
因此，AIP 的价值在于把模型放进完整执行环境，而不是只让模型生成更长的答案。
Agent 的三类边界
| 边界 | 需要回答的问题 |
|---|---|
| 知识边界 | 它可以读取哪些数据、文档和对象？ |
| 行动边界 | 它可以调用哪些工具和动作？ |
| 责任边界 | 哪些结果需要人工审批、复核或升级？ |
这三类边界应该进入系统设计，而不是依赖系统提示词中的一句“请谨慎操作”。
Apollo：持续交付不是附属能力
AI 产品变化快，企业环境又复杂。一个 Agent 可能同时依赖模型服务、数据管道、Ontology 定义、工具接口、权限配置、前端应用和运行时资源。任何组件更新，都可能改变最终行为。
Apollo 的角色，是把这些服务和资源纳入持续交付和环境管理体系。
为什么 Agent 特别需要持续交付
- 模型版本会变化；
- Prompt、工具 schema 和业务规则会变化；
- 数据管道会增加字段或改变延迟；
- 权限政策会调整；
- Agent 评估结果会触发版本迭代；
- 不同客户或环境可能需要不同配置。
如果没有版本、发布、监控和回滚，Agent 的问题很难定位：到底是模型变了、数据变了、工具变了，还是权限变了？
面向 Agent 的发布单元
数据连接与管道
+ Ontology 定义
+ 工具 / 函数
+ Agent 配置与 Prompt
+ 评估数据集与阈值
+ 权限和治理配置
+ 前端应用与通知
+ 运行时资源
发布时应尽量整体版本化，避免只更新 Prompt，却忘记同步工具 schema 或验收集。
三个平台如何形成企业操作系统
可以把三者简化为四层：
业务资产层
包含数据集、文件、模型、外部系统和业务对象。这里最重要的是来源、质量和权限。
决策语义层
由 Ontology 统一对象、关系、动作、逻辑和安全边界。Agent 不应直接绕过这一层访问一堆没有语义的表。
AI 与应用层
包括 Agent、自动化、分析、工作台、业务应用和 SDK。不同角色可以使用不同交互方式访问同一个运营世界。
平台运行层
包括持续交付、容器、计算、网络、日志、加密、高可用、升级和回滚。Apollo 与 Rubix 在这一层提供基础支持。
安全模型：三层一起看
官方架构可以拆成基础设施安全、平台安全和企业安全。
基础设施安全
关注工作负载隔离、网络、加密、节点、运行时和服务之间的身份认证。
平台安全
关注数据、项目、对象、Agent、动作、模型和应用的访问控制、血缘与审计。
企业安全
关注与现有身份提供商、目录服务、SIEM、权限体系和合规流程的集成。
对 AI Agent 来说，安全不能只看用户能否打开页面，还要看 Agent 是否继承用户权限、工具调用是否有独立权限、代理执行的动作是否比人类操作更宽，以及一次完整执行能否被还原。
一个供应链 Agent 的架构示例
- Foundry 接入订单、库存、物流、供应商和设备数据；
- Ontology 建模订单、物料、仓库、供应商、运输事件和异常对象；
- AIP Agent 读取异常上下文，调用库存查询、交期预测和替代采购工具；
- Agent 生成补货建议，但创建采购单需要人工审批；
- 审批结果回写采购系统，并记录谁批准、使用了哪些数据和模型；
- Apollo 将数据管道、Agent、工具和应用以版本化方式发布；
- 观测系统记录成功率、延迟、成本、拒答率和动作失败率。
这个例子说明：AI 只是其中一环。真正的交付物是数据到决策再到动作的可治理闭环。
AI FDE 实施清单
| 项目 | 最小答案 |
|---|---|
| 业务目标 | 要减少什么等待、错误或人工成本？ |
| 核心对象 | Agent 需要理解哪些对象和状态？ |
| 数据来源 | 每个字段来自哪里，多久更新一次？ |
| 工具动作 | Agent 可以读什么、建议什么、写什么？ |
| 权限 | 用户、项目和 Agent 的权限如何组合？ |
| 验收 | 什么结果算成功，什么情况必须升级人工？ |
| 发布 | 如何版本化、灰度、监控和回滚？ |
常见误区
把 Agent 误解成一个 Prompt
Prompt 只是一个版本化工件，不是完整产品。真实系统还包括数据、工具、权限、评估和部署。
让 Agent 直接连接底层数据库
这样做会绕过语义、权限和动作治理。更稳妥的方式是通过受控的对象查询、函数和工具访问业务能力。
只发布应用，不发布依赖
如果数据管道、Ontology、工具和评估集没有一起版本化，生产问题很难复现和回滚。
参考资料
最值得记住的不是三个产品名，而是三种责任：Foundry 让企业世界可建模，AIP 让 AI 能参与决策，Apollo 让这些能力可以持续运行。
सम्बन्धित गाइड
Palantir 架构中心导读：理解企业 AI 平台的全局地图