本文是《拆解 Palantir:企业 AI 与 FDE 架构指南》第 7 篇。

AIP 是 Palantir 把生成式 AI 接入运营领域的平台。它与 Foundry 共享服务网格,由 Apollo 持续交付,并运行在 Rubix 基础设施上。

如果把企业 AI 中台理解成一个统一调用大模型的网关,就会忽略生产落地中最困难的部分:上下文、安全、工具、评估、自动化、版本和运营。AIP 的架构恰好提供了一份更完整的能力清单。

1. 安全连接各种模型

AIP 能连接商业模型、开源模型、企业自有模型、微调模型和领域模型。

平台需要控制模型提供商是否能够留存请求数据、数据是否被用于再训练、哪些用户能访问哪些模型,以及模型调用能够消耗多少令牌和计算资源。

模型选择不应写死在单个应用中,而应成为可治理、可替换的平台能力。

2. 端到端可观测性

Agent 的最终回答不足以解释系统发生了什么。平台还需要记录:

  • 使用了哪些上下文;
  • 调用了哪些模型和工具;
  • 每一步由谁触发;
  • 执行链在哪里分支或失败;
  • 消耗了多少令牌和资源;
  • 是否执行了影响现实业务的动作。

可观测性既用于排障,也用于安全审计、成本管理和效果改进。

3. 上下文工程

企业 Agent 的质量很大程度取决于上下文。AIP 通过无代码、低代码和专业代码工具,把数据、逻辑和动作持续接入 Ontology。

批处理、流处理和 CDC 实时复制可以共同提供上下文,同时遵循统一的安全、治理和来源追踪规则。

上下文工程不是一次性准备一批文档,而是持续维护业务世界的最新状态。

4. Ontology 系统

Ontology 把分散的数据、逻辑、动作和安全策略组织成企业决策的统一表达。

它的 Language 定义业务中的名词与动词,Engine 支持大规模查询和业务动作,Toolchain 则帮助开发者构建并治理 AI 应用。

有了 Ontology,Agent 面对的不再是缺少结构的文本集合,而是一个可理解、可查询、可执行且受权限保护的业务世界。

5. 向量服务

平台需要生成、存储和管理嵌入向量,为语义检索、相似度匹配和多模态应用提供基础。

向量能力应与业务权限和 Ontology 对象结合,避免检索层绕开原有数据访问规则。

6. 计算服务

不同任务需要不同计算方式。平台既要支持 Spark、Flink 等多节点引擎,也要支持 DuckDB、Polars 等高效单节点引擎,还要允许企业接入自己的容器化运行时。

Agent 因此可以调用优化器、领域模型、传统程序和数据处理任务,而不是只能调用大语言模型。

7. 工具服务

工具是 Agent 影响业务世界的接口。它可以是查询函数、计算模块、工作流动作或外部系统 API。

工具不应散落在提示词和项目代码里,而要形成可复用、可测试、可授权和可观测的能力集合。

8. 安全与治理

人和 Agent 的每项操作都应遵循角色、数据分类和用途控制。安全范围需要覆盖基础设施、平台和企业系统,并支持动态查询与审计。

Agent 继承用户权限,不能因为“自动化执行”而获得不受限制的系统访问权。

9. Agent 生命周期

生产 Agent 需要完整生命周期管理:

  • 构建与编排;
  • 测试和调试;
  • 评估与模型对比;
  • 上线与版本管理;
  • 运行观测;
  • 失败分析;
  • 持续迭代。

Evals 不是上线前的一次考试,而应贯穿整个生命周期。

10. 运营自动化

自动化既可以定时触发,也可以由实时事件或 API 请求触发。它们复用 Ontology 中已经治理的数据、逻辑和动作。

系统可以根据风险决定由 Agent 自动执行、请求人工确认,还是只提供决策建议,实现从辅助到自治的渐进升级。

11. 开发环境与人机协作应用

平台需要同时服务专业开发者、数据科学家、业务分析师和一线用户。

VS Code、JupyterLab、SDK、低代码工具和业务应用各自承担不同角色,但共享同一套对象、权限和变更管理机制。

这种共同基础使 AI 能力能够进入真实应用,而不是永远停留在聊天窗口中。

12. 打包、发布与企业自动化

一个完整 AI 产品往往同时包含数据管道、Ontology 定义、模型配置、Agent、自动化和用户应用。

平台需要把这些组件作为一个整体进行打包、测试、发布和更新,并允许在不同客户环境中进行末端定制。

进一步地,专业 Agent 还能帮助不同角色建立数据管道、编写逻辑、训练模型、构建 Ontology、制作分析和开发应用。人与 Agent 使用同一套基础设施和变更管理体系。

一个企业 AI 中台的检查清单

如果正在建设自己的 AI 中台,可以用下面的问题进行检查:

  1. 是否能够安全接入并替换不同模型?
  2. 是否拥有持续更新的企业上下文?
  3. Agent 是否能调用受控的业务动作?
  4. 权限能否延伸到数据、工具和每次执行?
  5. 是否能观察完整执行链和成本?
  6. 是否具备系统化评估与版本管理?
  7. 是否支持人在回路与自动执行的切换?
  8. 是否能够把数据、逻辑、Agent 和应用作为产品整体交付?
  9. 是否能运行在客户要求的云、本地或边缘环境?
  10. 是否能够持续升级,而不是完成一次演示就结束?

小结

AIP 的重点不是单独调用模型,而是围绕 Ontology 建立从模型接入、上下文工程、工具服务、Agent 生命周期和运营自动化,到产品交付的完整闭环。

安全、治理、评估和可观测性不是外围能力,而是贯穿每一步的基础。只有补齐这些环节,AI 才能真正进入企业生产环境。

参考资料

中文内容来源:https://x.com/oops073111/status/2095360085690327309
官方资料:https://www.palantir.com/docs/foundry/architecture-center/aip-architecture

上一篇:Rubix · 系列总览