Palantir AIP 架构总览：企业 Agent 的完整能力地图

前面的文章分别介绍了 AIP、Foundry、Apollo、Ontology、多模态数据平面、互操作性和 Rubix。AIP 架构总览则从 AI 视角把这些能力重新串起来，回答一个更直接的问题：一个企业 Agent 从模型接入到生产运行，平台需要提供哪些能力？

本文不逐字翻译官方页面，而是把相关能力转成 AI FDE 和企业 Agent 项目可以直接使用的架构清单。

总体链路

模型接入
  ↓
上下文工程与 Ontology
  ↓
工具、函数与 Agent 构建
  ↓
自动化、应用与人机协作
  ↓
评估、观测、治理
  ↓
打包、发布、部署与持续迭代

Agent 不是一个 Prompt 文件，而是一种从上下文到行动、从行动到反馈的生产系统。

1. Secure LLM integration：安全接入模型

企业可能使用 GPT、Gemini、Claude、Grok、Llama、自研模型、微调模型或领域模型。模型接入需要处理凭证和密钥、输入数据保护、协议和参数差异、访问权限、项目配额、模型版本、路由以及失败降级。

“能发出请求”只是连通性验收。真正的模型接入验收还包括敏感数据边界、输出稳定性、工具兼容性、成本和可替换性。

2. End-to-end observability：观察每一步

Agent 的结果经常由多个步骤共同产生：检索、对象查询、模型调用、工具调用、外部 API、人工审批和回写。

因此日志不能只记录最后一段文本。至少应记录：

请求身份
→ Agent 版本
→ 模型与参数
→ 上下文来源
→ 工具选择
→ 工具参数与结果
→ 外部副作用
→ 最终输出
→ 人工修正与业务结果

还要关注 Token、延迟、队列、失败率、重试率和每次任务的真实成本。

3. Context engineering：上下文工程

上下文工程不是简单地把更多文本放进 Prompt，而是设计 Agent 在何时、以什么格式、从哪里获取哪些信息。

上下文来源可以包括 Ontology 对象和关系、结构化指标、文档和媒体、实时事件、业务规则、用户权限、工具返回结果、历史执行和人工反馈。

优秀的上下文工程具有三个特点：来源可追踪、权限可验证、内容与当前任务相关。“把所有数据都塞给模型”既昂贵又不安全，应优先提供与当前对象、状态和动作有关的最小充分上下文。

4. Ontology system：让上下文变成决策语义

Ontology 把企业数据、逻辑、动作和安全组织成统一表示。对于 Agent，它提供的不只是检索结果，还包括当前有哪些对象、对象之间如何关联、状态如何变化、哪些动作可用、动作需要什么参数，以及当前用户和 Agent 拥有哪些权限。

它使 Agent 的工作从根据文本猜测，转变为在业务状态和动作模型中操作。

5. Vector、compute、tool services：工具工厂

企业 Agent 往往需要向量检索、批处理、流处理、单机分析、优化器、计算模块和各种业务工具。这些能力应做成可管理、可发现、可复用的服务，而不是每个 Agent 单独写一套连接器。

工具应包含什么

• 清晰名称和描述；
• 输入和输出 schema；
• 权限要求；
• 是否有副作用；
• 超时和重试策略；
• 幂等和回滚方式；
• 版本与所有者；
• 观测字段。

工具数量不是越多越好。工具越多，选择错误和权限配置错误的概率越高，应按业务动作和责任边界拆分。

6. Security & governance：让人和 Agent 遵守同一套规则

AIP 架构强调角色、标记和用途等控制方式，并将治理能力延伸到 API、SDK、开发活动和平台操作。

企业 Agent 至少要回答：它代表谁，读取了什么，为什么可以读，要执行什么，谁批准了动作，发生问题后谁负责。

安全设计要覆盖数据、Prompt、工具、模型、输出和外部写入，不能只保护数据库。

7. Agent lifecycle：从构建到评估再到生产

Agent 生命周期可以表达为：

定义 → 构建 → 测试 → 评估 → 灰度 → 观测 → 迭代 → 退役

评估不应只问这次回答对不对，还要比较不同模型、Prompt 版本、工具集合、上下文和多次执行差异，并记录工具调用成功率、业务结果和人工返工量。

8. Operational automation：自动化有多种节奏

企业自动化不只有定时任务，还包括按计划运行、响应实时事件、根据 API 操作触发、在工作流中等待人工审批，以及按通知、队列和优先级执行。

Agent 应根据任务风险选择自动化模式。低风险摘要可以定时运行；涉及付款、生产停机或客户沟通的动作，应引入审批和限额。

9. Development environments：让开发者在熟悉的工具中工作

AIP 的开发能力可以延伸到 VS Code、JupyterLab、Platform SDK、Ontology SDK 和插件生态。重要的是保持开发体验与平台治理一致。

开发者不应为了使用现有工具而绕过权限和评估，也不应因为平台治理而失去代码版本控制、测试和调试能力。

10. Human + AI applications：增强而不是替代所有人

企业 AI 应支持从人机协作到自动化的渐进路径：

人看结果
→ 人确认建议
→ Agent 执行低风险动作
→ Agent 自动处理并升级异常

不同角色需要不同应用：操作人员看当前任务，合规人员看权限和审计，工程师看日志和版本，管理者看业务指标和资源。

11. Package、release、deploy：把 AI 产品作为整体交付

一个可生产化的 AI 产品通常包括数据管道、Ontology 定义、工具和函数、Agent 配置、应用界面、评估集、权限和治理、监控和通知。

如果只发布 Agent Prompt，其他依赖仍然不可追踪。完整发布单元应支持版本、审批、灰度、回滚和不同环境的最后一公里配置。

12. Enterprise automation：让 AI 帮助构建 AI 系统

AIP 架构进一步把 AI 用于数据管道、业务逻辑、Ontology、分析、模型和应用开发。AI FDE 或分析 Agent 可以帮助团队从需求到实现推进工作。

但让 Agent 构建系统并不意味着取消治理。它仍然要遵守同样的数据访问权限、变更管理、测试评估、人工审批和版本回滚规则。

12 类能力映射到一个真实项目

以客户服务 Agent 为例：

AIP 能力	项目落点
模型接入	选择通用模型和备用模型
观测	记录会话、工具、Token 和转人工
上下文工程	客户、订单、合同、工单和知识库
Ontology	Customer、Order、Ticket、Contract 对象
工具服务	查询订单、创建工单、退款申请
安全治理	客户隔离、字段脱敏、动作审批
Agent 生命周期	Prompt、工具和评估版本
自动化	事件触发和人工升级
开发环境	SDK、代码仓库和测试脚本
人机应用	客服工作台和主管复核
交付	灰度发布和回滚
企业自动化	自动生成报表、规则和流程草稿

AI FDE 的最小架构模板

业务需求
  ↓
对象与状态建模
  ↓
数据 / 文档 / 事件接入
  ↓
上下文工程
  ↓
Agent + 工具 + 业务逻辑
  ↓
人工审批 / 自动动作 / 外部回写
  ↓
评估 + 观测 + 成本统计
  ↓
灰度发布 + 反馈迭代

任何缺失的环节，都会在上线后变成新的风险：没有对象模型就会上下文混乱，没有工具治理就会越权，没有评估就无法升级模型，没有观测就无法解释失败，没有发布体系就无法安全迭代。

常见误区

把 Agent 生命周期缩短为 Prompt 调优

Prompt 只是一个版本化工件，不是完整产品。真实系统还包括数据、工具、权限、评估和部署。

只评估文本质量

业务 Agent 的成功标准还包括动作正确率、人工接管率、时效、成本和副作用。

把自动化理解为无人工

高质量自动化往往是把人工放到最有价值的判断点，而不是让 Agent 在所有地方自由执行。

忽略退役

模型、工具和业务流程都会变化。旧 Agent 应有下线、迁移和数据归档策略。

参考资料

• Palantir AIP architecture
• AIP Evals
• Palantir AIP Overview

AIP 架构的核心启示是：企业 Agent 不是模型加 Prompt 加一个工具，而是一个包含上下文、语义、工具、权限、生命周期、评估、观测和交付的完整系统。