Palantir 互操作性：企业 Agent 如何连接 API、数据与外部系统
企业 AI 项目很少从零开始。客户通常已经有数据仓库、湖仓、ERP、CRM、BI、身份系统、消息平台、自研模型和遗留程序。一个 Agent 如果只在新平台内部运行，很容易变成新的信息孤岛。
Palantir Architecture Center 的 Interoperability 章节强调，互操作性不是提供几个 API 这么简单，而是要让数据、元数据、语义、代码、分析和安全在平台之间双向流动，同时保持治理能力。
互操作性的六个层次
数据 → 元数据 → 语义 → 代码与逻辑 → 分析工具 → 安全与身份
只打通数据，不打通元数据，接入后会失去血缘和权限；只打通 API，不打通语义，Agent 仍然不知道字段意味着什么；只打通身份，不保护动作，最后仍然会形成安全漏洞。
一、数据互操作性
开放格式和标准接口
企业应尽量保留 CSV、Parquet、Iceberg 等开放格式，并通过 REST、JDBC、S3 兼容接口或平台 SDK 访问。这样既有 SQL、Notebook、BI 和数据工程工具可以继续使用，新应用和 Agent 也能使用统一的治理入口。
虚拟表和数据连接
当外部湖仓已经存在时，优先考虑受控引用、虚拟表或计算下推，而不是无条件复制。选择哪种方式，应看数据新鲜度、网络成本、外部权限、查询性能、合规和失败恢复。
Agent 的数据访问原则
Agent 不应直接获得整个数据仓库的万能查询权限。更好的设计是提供面向业务对象或业务问题的接口：
错误：Agent → 任意 SQL → 全库数据
更稳妥：Agent → 受控函数 → 过滤、聚合、审计 → 业务结果
这样既减少越权风险，也能控制上下文大小和调用成本。
二、元数据互操作性
数据本身只是内容，元数据决定它能否被安全使用。企业至少要维护：
- 数据来源和所有者；
- 更新时间和质量状态；
- 字段含义与业务口径；
- 访问标记和敏感等级；
- 血缘和转换历史；
- 关联项目、模型、Agent 和应用。
对 AI FDE 来说，元数据应进入 Agent 的上下文，而不是只放在管理员界面。Agent 选择指标时应知道更新时间、来源和适用范围；生成建议时应能说明引用了哪些数据和版本。
三、语义互操作性
不同系统可能都存在客户、订单和设备字段，但含义和主键并不一致。语义互操作性要解决的不仅是字段映射，还包括对象、链接、动作和函数之间的关系。
从字段映射到对象映射
字段映射只是把名称对齐：
crm.customer_id → customer_id
erp.client_no → customer_id
对象映射则把多个系统的概念统一成可运营对象：
CRM 客户 + ERP 客户 + 工单联系人
↓
Customer 对象
↓
订单、合同、服务事件、联系人
对象映射更接近业务决策，也更适合 Agent 使用。
API、Webhook 与 MCP
语义互操作性通常需要多种接口：
- REST API：适合系统集成和资源访问；
- SDK：适合应用和工作流开发；
- Webhook：适合状态变化和事件通知；
- MCP：适合以工具和资源形式向 Agent 暴露能力。
无论使用哪种协议，都要把权限、输入校验、幂等、超时、错误码和审计纳入设计。
四、代码与逻辑互操作性
企业不会只使用一种语言。数据工程可能使用 Python、Java、SQL 或 Spark，数据科学可能使用 Python、R、ONNX，基础设施还可能依赖 Go、Rust 或专用二进制。
互操作性设计应尽量让这些代码使用开放语言和运行时，存放在版本控制系统中，能通过 API 或 SDK 访问，保留测试和依赖信息，并可以被安全地封装成计算模块。
Compute Modules 的意义
Compute Modules 允许团队将容器化运行时、模型、优化器、应用或遗留程序接入平台，并让它们参与数据管道、分析、应用和 AI 工作流。
这比把所有代码重写成某个低代码表达式更现实，尤其适合已经验证过的行业模型、需要特殊系统库的程序、只能在 GPU 环境运行的服务，以及不能轻易修改的第三方组件。
五、分析互操作性
企业的分析生态通常已经很成熟。Power BI、Tableau、Jupyter、RStudio、SQL 客户端和自研数据应用都有既有用户。
新平台应允许既有 BI 工具访问受控数据，Notebook 使用平台对象和数据，分析结果进入应用和工作流，Agent 使用分析指标和模型结果，业务用户则无需理解底层数据工程即可消费结果。
分析工具适合探索、解释和验证；Agent 适合在明确边界内执行重复或多步骤任务。不要让 Agent 代替所有探索式分析，也不要让人工把每次重复判断都重新做一遍。
六、安全互操作性
企业安全系统往往包括 SAML、Active Directory、RBAC、分类标记、用途限制、设备健康、密钥管理和审计平台。新的 AI 平台应该接入这些体系，而不是另起炉灶。
三个必须打通的身份
人类身份
谁发起了请求，所属团队和角色是什么？
Agent 身份
它是继承用户权限，还是使用项目或服务身份？
外部系统身份
Agent 调用 ERP、CRM 或工单系统时使用哪个凭证，允许做什么？
一次完整调用链应能够回答：
谁发起 → 哪个 Agent → 读取了什么 → 调用了什么工具
→ 做了什么判断 → 写入了哪里 → 谁批准 / 谁接管
用户可能可以查看库存，但不能修改库存；可以模拟采购方案，但不能直接创建采购单。Agent 的工具设计也应遵守这种分离。
一个跨系统 Agent 集成模板
以客户流失预警 Agent 为例：
- CRM 提供客户、合同和服务记录；
- 数据平台提供使用量、付款和产品行为；
- BI 系统提供经营指标；
- Ontology 统一 Customer、Contract、Ticket、Usage 对象；
- Agent 调用风险评分、客户历史和推荐动作工具；
- Agent 只能生成联系建议，发送正式通知需要客服确认；
- 结果通过 CRM API 写回并创建任务；
- 后续客户反馈用于评估预警质量。
接口不是重点，重点是每个系统的能力经过语义、权限和动作边界后再暴露给 Agent。
API 设计的最小要求
一个供 Agent 使用的工具至少要定义名称、描述、输入 schema、输出 schema、权限要求、是否有副作用、超时和重试策略、幂等和回滚方式、版本与所有者以及观测字段。
动作类工具还应补充幂等键、审批要求、回滚策略和外部写入结果。工具越万能，越难做权限、测试、审计和错误恢复，应围绕清晰的业务动作拆分。
AI FDE 的验收清单
- 外部数据能否保持来源和血缘？
- Agent 是否读取了正确的数据版本？
- 外部系统权限是否被正确继承？
- 读操作和写操作是否分离？
- 工具失败是否可重试且不会重复写入？
- 是否能还原完整调用链？
- 能否替换底层模型、计算模块或 BI 工具？
常见误区
只做单向导入
只把数据导入新平台，不设计结果回写，最终仍然需要人工复制。
忽略元数据
Agent 能读到数据，但不知道来源、更新时间、口径和权限，生成的答案看似合理却无法用于决策。
用一个万能 API 代替所有工具
接口越万能，越难做权限、测试、审计和错误恢复。面向 Agent 的工具应该围绕清晰的业务动作拆分。
为了统一而屏蔽既有工具
真正的互操作性应让企业逐步迁移，而不是强迫所有团队立刻改变工作习惯。
参考资料
互操作性的终点不是把所有系统变成一个系统，而是让不同系统在数据、语义、权限和动作边界清晰的前提下协作。