一个 MCP 服务器管全公司：Palantir 内部用本体驱动的规划工作流

摘要

Palantir 内部团队负责人 Mike 与架构师 Chad 展示了「吃自己的狗粮」的最新成果：Ontology MCP（OMCP）——一个把公司全部业务接入 AI 工具的 MCP 服务器。Palantir 已把几乎所有内部系统建模进一个庞大而稳健的本体，Foundry 本身成了许多工作流的源系统；今年他们上线 OMCP，把 Claude Code、Codex、Copilot、Gemini 等任意 AI 工具接到这一个本体上。

理念是「一个 MCP 服务器 + 业务过程模型」优于「每个系统一个 MCP 服务器」：对象类型之间的互联关系已被建模，分析可以近乎一次性完成，不再需要反复消解冲突、烧 Token。安全上，工具继承用户的全部访问控制与安全标记，还能做「标记白名单」——例如 PII 数据一律不许流出。

演示的规划场景（每年三次的内部规划）令人印象深刻：几天的复盘数据收集压缩成几句话；Claude 起草、Codex 交叉检查「是否现实」；一键发布 T3 计划，自动在本体中创建目标与关键结果。本体的意义正如 Chad 总结：「不管用什么工具，本体是那个单一后端层——无论你在哪个环境，带着正确的智能与你相遇。」

正文

一、一个 MCP 服务器，而不是二十个：OMCP 的理念

Mike 负责 Palantir 内部驱动 Foundry 使用的团队。他介绍：公司已经建成了一个相当庞大、稳健的本体，覆盖几乎所有互联的内部系统，Foundry 本身成为许多内部工作流的源系统；人们还在 Workshop、自定义应用、OSDK 上建了大量内部应用。过去两年又陆续接入了几个 AI 工具——今年他们上线了 OMCP，也就是本体 MCP 服务器，把 AI 工具里的工作流与内部 Foundry 实例连接起来，效果「非常有价值」。

Chad 点出关键差异：与其给每个系统配一个 MCP 服务器，不如把一切建模进本体、给一个 MCP 服务器——这样不仅编码了系统本身，还编码了跨系统的实际业务流程与它们如何交互，对终端用户有用得多。「一个承载业务流程与底层系统的 MCP 模型，比每个系统二十个 MCP 服务器有效得多。」Mike 补充：最直接的感受在对象类型之间的互联建模上——如果你有五个不同的 MCP 服务器，把 AI 工具扔过去让它「消解冲突、找模式」，它每次做得都不一样、容易出错、耗时、烧 Token；而一切建模在 OMCP 里，分析可以接近「一次命中」，返回的数据直接可用，最终输出也漂亮。

Mike 也提到一个现实收益：个人化配置的 MCP 服务器群容易让大多数人不愿参与，而 OMCP 让他们只需连接一个东西——所有需要的数据已经在那里、已经建模好，直接用，还能写回。

二、设置与安全：从 Foundry 开发控制台到标记白名单

设置对管理员来说「令人兴奋又简单」：全部发生在 Foundry 开发控制台里——与构建自定义 OSDK 应用同一个地方。第一步是本体 SDK：定义要让 MCP 服务器暴露哪些对象。可以走广度路线全加上，也可以做针对具体用例的窄版本——他们偏向广度，系统导航对象的能力很好。演示用的是精简版规划本体：代表组织的对象（开发者、团队）、规划对象（计划、目标、关键结果 OKR）、以及源系统对象（聊天消息、支持工单、GitHub 拉取请求与议题）。

Mike 强调：这不只是数据——数据、逻辑、动作、对象间的连接、安全，全都一起给你。「这不是只能做检索的 MCP，这是完整的运营组件：能采取动作、能跨链接导航。」底部的动作类型包括创建议题（真实世界会直接写回外部源系统）、编辑与创建目标与关键结果——全部作为工具暴露在 MCP 工具链里给 AI 智能体用。然后在 MCP 标签页一键开启，就得到一个 MCP 服务器。

它对工具完全无关：可以用 VS Code 里的 Claude Code、终端里的 Codex，也能用在 Claude Desktop、Gemini、Copilot——「要点是你把一个东西连接到所有这些，大家都说同一种语言」。Chad 分享：他曾把 Copilot 接在 MCP 之上，客户爱不释手——企业数据突然在 Copilot 里变得有意义了；还能在写 Word、PowerPoint 时用上本体支撑的能力。「目标是把本体的力量带到人们已经在工作的地方。」Mike 回忆第一次在 Claude Code 里使用时的感受：「有点魔幻」——接上后随便问一些很泛的问题，返回的都是真正有用的东西；而在你编辑代码、做真实开发的既有工作流里，这一切都在手边，是大幅增强的工作流，团队里已经出现大量自发使用。

安全模型是关键卖点：MCP 服务器出来的所有东西都带着作用域收窄的 Token，继承你作为用户拥有的全部访问权限——行级、列级访问控制与安全标记全部如实反映。更酷的是「标记白名单」（marking whitelisting）：如果某个 AI 工具（比如云端的、第三方的）的数据存储信任级别低于 Foundry，可以动态只放行一部分数据——「凡是标记为 PII 的一律不许通过 MCP 服务器」。这让以前从 InfoSec 角度很难论证合理的接入变得可行：「你能把人们真正需要的 99% 的数据放出去，同时把自己从困境里解放出来。」

三、规划工作流：从复盘到 T3 计划的一站式生成

Palantir 每年做三次季节性规划。常见的第一步是复盘（retrospective）：上个周期怎么样？目标达成没有？与实际进来的支持信号对不对得上？关键指标如何？把这些材料收集起来——聊天数据、议题、工单——过去要花一个人好几天。现在只需在一个代码工作区（真实世界会接入你真正的代码仓库）里问一句：把 Slack、工单、GitHub 的历史数据都看一下，给技术支持团队跑一次复盘。它返回一个本地 Markdown 文件，格式不满意很容易迭代，做第二个团队的复盘也同样简单——作为组织负责人，Mike 常在自己做功课：「给我看看网络工程团队类似的复盘。」它会在本体里找到网络工程团队、找到团队负责人，拉出目标、关键结果、GitHub 议题，然后做分析。

这些数据不是死数据：工单系统本身就在本体与 Foundry 里，全是活的系统记录——「这是我们 Palantir 如何运转的本体：工单流程映射进产品组件，再映射到所有这些。我可以在工作的地方用 AI 智能体随时盘问它、构建计划、迭代。」Mike 第一次用时被震撼：「我一整天都在问这个团队怎么了、那个团队怎么了——那是我从未有过的可见性级别。」

复盘之后是制定计划：把上次计划里的经验、支持数据里的共性趋势交给它，「给我做一份计划」。草稿锚定在真实数据上，再人工迭代。演示里，Claude 直接起草了网络工程团队的 T3 计划初稿：给出信息来源、按主题归纳总体计划，然后直接进入 OKR——例如第一个目标「让自动化停止静默失败」。它把目标与关键结果的结构、对象导航全部处理妥当。

四、跨工具协作与「检查工作的智能体」

Mike 的下一招很有工程师风格：让另一个智能体检查 Claude 的工作。在另一个窗口里打开 Codex（之前已用它做过一些规划工作，能访问 Claude 写的同一批文件），对它说：「看看这份计划草稿，给我反馈——现实吗？是不是太激进了？」Codex 不仅访问文件，也访问本体——你能看到它做了一堆本体调用、抓取正确信息。即使初稿看起来挺正常，它通常也会给出非常好的反馈（昨天那份草稿被评「极其不现实」，今天这份被评为「现实」——「看来我们在进步」）。

确认无误后发布：让工具「发布这份计划」——它会调用之前展示的那些动作：发现 T3 计划属于网络工程团队、技术支持还没有 T3 计划、拉取 Markdown、发布。需要一点人工监督，但完成得很漂亮：导航本体、正确创建所有关键结果与目标、发布。「我没点过一堆表单，零时间花在发布与排版上，全部时间都花在真正的规划上。」发布后，计划出现在 Workshop 应用里，全公司都能消费；也可以继续用自由问题盘问：「技术支持团队在网络工程团队那里被什么卡住了？」——它会梳理团队间依赖、哪里需要互相提工单、哪里被阻塞——这种事平时极其繁琐，现在直接问就行。

Chad 强调协作的底层逻辑：一个团队可能爱用 Claude Code，另一个用 AI FDE，还有用 Codex、Copilot 的——「我不在乎，本体是那个跨企业、跨工作流的单一后端层」。而且不仅能交互式使用：一旦你通过手动跑通几个 AI 工具学会了最有价值的流程版本，就可以在 Foundry 里用 AI FDE 把整个工作流固化——每个季度自动发复盘、你批注后它发布、再跑每周的去冲突与趋势分析。「从原型到固化非常顺滑：先用手动方式走一遍，然后它自己发生。」这种「探索期用 AI 工具、定型期回到平台」的来回切换，正是他们越来越依赖的节奏。

五、从原型到工作流：把探索固化进 Foundry

Mike 指出工具本身流动性的价值：这是动态的行业，新东西不断落地，开发者对工具的好恶几乎每天在变——「不把自己困在任何特定配置或工具集里，非常解放」。有时最好的答案就是在 Foundry 内部完成，有时则是在用户所在之处、用今天最好的工具。除了 Ontology MCP，还有 Platform MCP——可以通过 MCP 在平台里交互、构建东西，再通过 Ontology MCP 消费——「单一本体承载业务流程，然后用你需要的一切方式与它交互」，这就是核心。

Chad 提到一个强大的模式：把发现阶段的上下文蒸馏后，接上另一个 MCP 服务器直接在 Foundry 里开建——「每次走过这个流程，能力门槛都会抬高」。Mike 补充真实本体的广度：演示用的本体与内部真实相比只是冰山一角——员工历史数据、做过的工作、技能类型、更智能的资源调度（某位开发者在做什么？拉取请求什么样？专长结构如何？）——规划、资源、招聘这些技术加运营的工作，现在有一个地方可以问通用问题、构建分析；他经常做的是问几个问题、摸清「该盯住哪些事」，然后把它做成一个带仪表盘的 Workshop 应用持续引用——「从探索到固化的提升流」。

收尾时 Chad 把这套做法推广到所有组织：规划业务活动、销售数据、供应链、制造——同一个概念可以到处发生。「这种敏捷性、在人们所在之处用他们正在用的工具把事情讲通，正是 Palantir 开放与全面集成的方式。」而 Mike 的总结带着自豪：「人们会爱上这个东西。」