恒川工业已经在 Workshop 里跑通缺料处置采购负责人却提出了一个现实要求供应商协同团队每天都在原有采购门户工作不可能为了看一个缺料事件再切到另一个系统。研发团队很快给出四个答案“用 API。”“生成 OSDK。”“接 MCP。”“做一个 Endpoint。”四句话都可能正确也可能让项目从起步时就走错。因为真正的问题不是“Palantir 有没有接口”而是谁在什么应用里以谁的身份读取哪些Ontology对象又能执行哪些 Action上一篇讨论 AIP 的生产生命周期。本篇把视线移到 Foundry 外部怎样让现有 Web 应用、业务系统和外部 AI client 安全使用 Ontology而不是绕开 Ontology 另造一套语义与权限。先给结论不要从接口名开始从调用者开始一句话定义Developer Console 是管理自定义应用、OAuth、资源范围和 SDK 的入口OSDK 是面向Ontology的类型化应用 SDKAPI是底层程序接口MCP是让 AI client 以工具方式消费受控能力的协议入口。它们不是四个平级产品也不是四种写法不同的同一个接口。在项目里我通常先问三个问题调用者是普通应用代码、后台服务、外部 AI client还是帮助开发者写代码的 AI IDE它要操作的是业务对象与 Action还是 Dataset、Project 等平台资源操作以最终用户身份发生还是以应用身份发生答案决定选型而不是团队熟悉哪种技术。它们在 Palantir 架构中的位置先把几个词放回最小架构图这里的上一级不是“OSDK 产品”而是 Foundry 的 developer toolchain。下一级也不是一个新的数据库而是现有 Ontology 与平台资源。外部应用发起请求后真正决定它能看到什么、能做什么的仍包括应用限制、最终用户权限、对象与属性权限、Function 权限和 Action submission criteria。接口只承载调用不创造业务授权。Developer Console不是写代码的 IDE而是应用控制面Developer Console 是建设者注册和管理 Custom Application 的地方。官方当前文档把应用创建、OAuth、Ontology SDK、application restrictions、usage metrics 与可选托管都放在这里。PalantirDeveloper Console建设者会在其中完成几件关键工作创建应用并选择认证方式选择允许应用使用的 Ontology resources生成 TypeScript/JavaScript、Python 等 OSDK限制 Project resources 和 API operations配置 redirect URL、客户端信息与部署观察应用调用与错误。因此Developer Console 的类型是开发者应用管理工具不是浏览器里的通用代码 IDE也不是业务用户使用缺料处置的页面。恒川为外部采购工作台注册Hengchuan Supplier Recovery Portal。应用范围只包含缺料处置所需的 Object Types、只读 Function 和指定 Action而不是把整个 Ontology 都交给门户。OSDK让应用用业务语言而不是拼 REST 路径Ontology SDK简称 OSDK是根据应用所选 Ontology resources 生成的类型化 SDK。PalantirOSDK overview应用代码可以直接面对 Material、Supply Disruption、Purchase Order Line、Link、Function 和 Action而不是自己维护一堆 JSON 字段名。恒川门户要展示SD-260808-01可以把调用意图写成读取 Supply Disruption → 沿 Link 获取 MAT-0001042 和受影响订单 → 调用 calculateRecoveryOptions Function → 用户确认后提交 Confirm Expediting Plan ActionOSDK 的价值不是“少写几行代码”而是让编译器和开发工具知道对象、属性、参数与返回值。Ontology 发生受支持的定义变化后团队能通过 SDK 更新和编译检查发现影响。但 OSDK 不是所有 Foundry API 的统称。它面向 Ontology若应用还要创建 Dataset、读取 Project 或编排 Pipeline需要相应的 Platform API/SDK。API最底层、最通用也最容易把责任写散Foundry Platform APIs 覆盖 Data、Ontology、Orchestration、Security 等 namespace并提供 REST 与多语言 SDK。PalantirPlatform API直接使用 API 适合这些情形目标语言或运行环境不适合 OSDK要访问 Dataset、Project 等非 Ontology 资源集成框架已有成熟的 REST 客户端、重试和观测规范需要精确控制请求、分页、错误与版本。风险也很明确。团队若直接散落调用很容易在应用里重新发明对象定义、状态翻译、权限判断和 Action 校验。几个月后门户里的“高风险缺料”和 Ontology 里的定义可能已经不同。所以即使使用 APIBA 也要坚持业务语义仍来自 Ontology业务操作仍优先通过 Action不把“接口能更新某个值”误写成“业务允许更新”。Ontology MCP把对象和 Action 交给 AI但只交必要工具Model Context Protocol简称 MCP是 AI client 发现和调用工具的一种协议。Palantir 的 Ontology MCP 能把获准的 Object Types、Functions 和 Action Types 暴露为 MCP tools。PalantirOntology MCP对恒川而言外部采购 Copilot 可以获得搜索高风险 Supply Disruption获取SD-260808-01及其关联订单调用只读 Function 计算恢复选项草拟给供应商的催交摘要。它默认不应获得Approve Allocation Proposal也不应直接修改 ERP 采购订单。若确实暴露某个 Action仍要经过 Action 的参数、criteria、权限、审计和人工确认设计。Ontology MCP 使用 Developer Console 创建的 third-party application 与 OAuth 配置并受 application restrictions 和用户权限约束。PalantirOntology MCP authentication这意味着 MCP 不是“AI 专用后门”。模型说“我需要订单”不等于系统就应该提供订单AI 能否获得某个工具本质上仍是应用范围和业务权限设计。Palantir MCP名字相近服务的是建设者Palantir MCP 与 Ontology MCP 最容易混淆。官方当前把仍标注Beta的 Palantir MCP 定位为面向开发者的 MCP server把 Foundry 的上下文和建设工具接入 AI IDE 或 coding agent用于发现资源、检查数据、编写与部署项目。PalantirPalantir MCP两者可以这样区分名词主要用户主要工具恒川例子Ontology MCP外部业务 Agent / AI clientObject、Function、ActionCopilot 查询缺料并调用获准工具Palantir MCP开发者与 AI IDEFoundry Platform、OSDK、资源建设工具工程师让 coding agent 查资源并生成集成代码前者交付业务能力后者辅助建设 Palantir 解决方案。名字都含 MCP不代表授权模型、工具集合和目标用户相同。Custom Endpoint当你必须提供自己的 HTTP 契约有些外部系统只接受固定 HTTP schema或要把多个内部调用封装成一个稳定 endpoint。这时可以考虑 Custom Endpoint。Palantir 当前支持以 TypeScript/Python Function 或 Code Repository 函数作为后端。公开 endpoint 目前标注 Open Beta并有并发、payload、timeout 和 QPS 等限制。PalantirCustom Endpoints恒川若要向供应商系统提供/recovery-cases/{id}endpoint 可以统一完成对象查询、字段裁剪和响应映射。但它不应复制一套新的审批逻辑涉及业务状态变化时后端仍调用经过治理的 Action。一张表做选择不是谁更先进而是谁更匹配需求优先选择为什么不要这样用Web/移动应用以对象和 Action 工作OSDK类型化、与 Ontology 定义一致、开发体验好把 OSDK 当全部 Platform API后台服务访问平台或 Ontology 资源Platform/Ontology API协议通用、控制细、跨语言在代码里复制业务权限和规则外部 AI client 使用业务工具Ontology MCP原生工具发现复用 Ontology 资源与权限一次暴露全部 Object Types 和 ActionsAI IDE 辅助建设 Foundry 项目Palantir MCP提供开发上下文和建设工具当作业务 Agent 的运行入口对伙伴提供固定 HTTP 契约Custom Endpoint可封装响应与自定义逻辑绕开 Action、审计和限流设计一个项目可以组合使用这些方式。恒川门户前端用 OSDK后台运维用 Platform API采购 Copilot 用 Ontology MCP工程师的 AI IDE 用 Palantir MCP。组合的前提是它们共享同一 Ontology 定义和权限边界而不是各自维护一套业务真相。恒川完整调用链从登录到 Action而不是从页面到数据库外部采购员打开门户后调用链应能被完整解释用户登录 → OAuth authorization code PKCE → Developer Console application restrictions → 用户自身的数据与对象权限 → OSDK 搜索 SD-260808-01 → Function 返回恢复选项与证据 → 用户确认方案 → Action criteria 再校验当前状态 → 提交 Confirm Expediting Plan Action → Writeback / audit / 对账如果采用后台批处理则可能使用 client credentials以应用身份运行。此时必须明确服务身份能看到什么、谁批准凭据、怎样轮换、失败由谁接管不能假装“没有用户所以不需要业务责任人”。AP-2048是否可以批准、WR-2048-*是否可以重试依然由第 20—22 篇建立的 Scenario、Action、Writeback 和 Automate 契约控制。换成外部应用不会降低门槛。生产约束接口通了只完成了最容易的一步1. 应用范围和用户权限是交集Developer Console 的 application restrictions 决定应用最多能访问哪些 Ontology、Project 和 API operation最终用户权限决定这个用户实际能访问哪些数据。PalantirApplication restrictions因此“应用被授权访问 Purchase Order”不代表每个登录用户都能看全部采购订单。2. 工具越多Agent 越难稳定选择Ontology MCP 可为所选对象生成 search、aggregate、get 等工具还可加入 Function 和 Action。把整个 Ontology 暴露出去会带来工具重名、选择错误、上下文膨胀和评测困难。恒川按 use case 建立最小工具面一组对象查询、一个恢复选项 Function、一个需要确认的 Action。工具是否好用要回到第 25 篇的黄金集和 Evals 验证。3. 版本兼容不是 SDK 自动替你解决类型化 SDK 能更早暴露不兼容变化却不能替团队决定什么时候升级。对象重命名、属性类型变化、Action 参数变化和权限收紧都可能影响外部应用。集成契约必须记录 SDK/API 版本、兼容窗口、升级责任人与回退方法。4. 幂等和审计要贯穿调用链门户提交 Action 时应携带稳定的 client request ID 或业务 correlation ID。日志至少能关联用户/应用身份、请求、Action submission、写回请求和最终结果。重试不能只看 HTTP 状态码。网络超时可能发生在 Action 已提交之后盲目再发一次会重复创建业务结果。应先按业务键查询再决定重试、返回既有结果或进入人工对账。BA 交付物一外部应用集成契约集成契约不是接口字段表而是调用方与 Ontology 之间的业务责任合同。字段恒川填写示例调用方与目的Hengchuan Supplier Recovery Portal让采购员在原门户完成缺料恢复用户与角色登录采购员后台对账服务另设 application identity对象范围Supply Disruption、Material、Purchase Order Line、受影响订单允许操作搜索、读取 Link、调用恢复 Function、提交Confirm Expediting PlanAction禁止操作批准AP-2048、直接改库存、绕过 ERP System of Record技术入口前端 OSDK必要的平台运维使用 Platform APIOAuth 模式交互使用 authorization code PKCE后台任务单独评审 client credentials应用限制只选所需 Ontology resources、Project 和 API operations业务权限用户权限与 Action criteria 继续生效幂等correlationId shortageId actionPurpose requestVersion错误与接管401/403 不自动重试未知提交结果先查 Action/业务键失败进入人工对账审计user/app identity、client request、Action、WR-2048-*、结果可关联版本记录 OSDK/API 版本Ontology 变更前执行兼容测试验收结果用户只能看到获准对象重复提交不产生重复业务结果BA 交付物二OSDK、API、MCP 选择矩阵判断问题OSDKAPIOntology MCPPalantir MCPCustom Endpoint主要调用方应用代码服务/集成代码外部 AI clientAI IDE/开发 Agent外部系统/伙伴主要对象Ontology resources平台或 Ontology resourcesObject/Function/Action toolsFoundry 建设资源与工具自定义 HTTP 业务契约需要类型安全高由客户端决定工具 schema工具 schema由 endpoint schema 决定典型身份用户或应用用户或应用OAuth client 用户/应用开发者授权调用方授权最关键风险SDK 版本漂移语义散落工具过多与越权开发权限过宽自定义逻辑复制业务规则恒川选择采购门户主路径平台运维补充采购 Copilot工程师开发辅助伙伴固定接口时才用BA 交付物三权限与审计上线检查应用只选择本用例所需的 Ontology resources、Projects 和 API operations使用真实角色验证“应用范围 ∩ 用户权限”而非只用管理员测试Object、Property、Function 与 Action 的权限分别验收高影响 Action 设置人工确认与 submission criteriaclient secret、redirect URL、token 生命周期和轮换责任明确每次调用可关联 user/app identity、request ID、Action、Writeback 与结果重复、超时、权限拒绝、部分成功和撤销路径均完成测试OSDK/API/MCP 版本变化有兼容测试、发布窗口和回退负责人MCP 工具集合做最小化、命名检查和 Evals外部应用不能成为 ERP/WMS 之外的影子 System of Record。结论开放的不是数据口子而是受控业务能力OSDK 让普通应用以类型化方式使用 OntologyAPI 提供更底层、更广的程序接口Ontology MCP 把业务对象和操作交给外部 AI clientPalantir MCP 辅助开发者建设 FoundryDeveloper Console 则统一管理应用、OAuth 和范围。真正成熟的外部交付不是“接口能调通”而是同一套对象定义、权限、Function、Action、审计和 System of Record 约束跨过应用边界仍然成立。但这会带来下一个生产问题外部门户已经依赖 Property 和 Action 参数Agent 也已经依赖一组 MCP tools。如果我们要修改 Ontology怎样先隔离变更、检查依赖、处理冲突再安全合并