企业 AI Ontology：为什么业务定义与运行时都应该开放

先给结论：本文在 2026 年 6 月主张，类型化应用定义与执行它的运行时都应该开放。此后行业自己让出了其中一部分：Palantir 的 Ontology MCP 在 2026 年 6 月 16 日当周正式可用——距本文发布只有四天——任何 agent 都能通过一个开放协议调用 ontology 里的对象与动作；到 8 月，Palantir 又开始把本体定义搬进带版本的代码仓库。决定可移植性的是三层——接口层、定义层、运行时——2026 年打开了第一层，开始打开第二层，而第三层原地未动。运行时就是最后一层没有打开的地方，也是这场争论里唯一还值得争的一半。

先讲一个你大概率亲眼见过的过程。

某家企业立项做“AI 助手”。第一周，演示惊艳：把客户数据导出一份给模型，它真的能回答“华东区哪些客户续约风险高”。高管看完当场拍板扩大试点。

第三个月，要接生产数据了，安全团队进场，问了三个问题：

AI 能看到哪些数据？销售 A 问“全公司业绩排名”，它会不会把别人的提成也答出来？
它要执行动作——改折扣、发合同——权限按什么算？出错了算谁的？
审计要查“这笔折扣是谁批的”，AI 参与的那部分，记录在哪？

项目组答不上来。不是态度问题，是架构里根本没有能回答这些问题的层。数据散在十几个系统里，权限写在各个应用的代码里，“折扣审批”这个业务规则只存在于某个资深员工的脑子里。AI 面对的是一堆裸表和裸接口，它再聪明，也没有地方去“看懂”这家企业的规则。

第九个月，试点悄悄结束。模型没有输给能力，输给了没有人敢签字。

这件事行业里有一个名字，叫缺一个 Ontology（业务本体）：一个结构化、机器可读的语义层，把“这家企业有哪些业务对象、它们之间什么关系、谁能对它们做什么、做了之后记在哪”显式地定义出来。

Palantir 把这件事做成了可验证的企业架构

把 Ontology 从论文概念变成企业架构实践的代表，是 Palantir。值得认真看一下它为什么成立——看得越公道，后面的问题才越清楚。

Palantir Foundry 的核心动作是两个。第一，把企业散落各处的数据集成进一个统一的本体层：客户、设备、订单不再只是几十张表，而是有类型、有关系、有属性的业务对象。第二，把写操作收敛成受控的 Actions——每个动作带校验、带权限、带完整审计。AIP 把这套架构直接对准了大模型：LLM 不直接碰数据库，而是调用本体层暴露出来的受治理工具。 模型可以换，边界不动。

这套东西为什么贵？因为它解决的问题确实贵。把一家大企业多年积累的系统梳理成一个干净的本体，需要团队一个系统一个系统地啃，一个概念一个概念地对齐——这是实打实的人力密集型工程。政府、国防、金融、能源这类客户，对“AI 每一步都在权限之内、都有记录”的要求是硬性的，也愿意为交付质量、责任边界和长期支持付费。

所以这里真正值得吸取的，不是某家公司的估值故事，而是一个架构判断：AI 要进入企业，必须先有一个受治理的业务语义层。

需要重新想的是下一个问题：这一层应该以什么形态存在？因为有几件事正在变。

软件正在变成 AI 写的

第一件事最直观：应用本身越来越多是 AI 写出来的。

过去“给 50 人的团队定制一套报销审批系统”在经济上不成立——开发费比痛点贵。现在一个 AI agent 几个小时就能交付一个可用雏形。定制业务软件正在从稀缺品变成更日常的产物，长尾需求会明显增加。

注意这个增长发生在哪：发生在长尾。发生在那些很少出现在企业软件销售名单上的团队里——他们没有采购流程，没有实施预算，不开 POC 评审会。他们只是让 agent “搭一个能用的”，下午就开始用了。

一个靠驻场工程师和百万美元合同运转的模式，结构上够不到这个市场。这不是谁对谁错，是两个市场。但这个新市场里的每一套系统，同样会撞上开头那三个安全问题——只是撞上的时候，旁边没有 FDE。

下一个做技术选型的，是 agent

第二件事更隐蔽，但影响更深：技术选型这个动作本身，正在从人手里转移到 AI 手里。

今天你让一个 agent “搭一个客户管理系统”，它大概率会选 Next.js 加 Postgres。为什么？不是因为有人给它做了广告，而是因为这些技术开放、文档完整、大量存在于它的训练数据里。它见过几十万个用法，知道每个坑怎么绕。

这意味着一件以前不存在的事：对开发者工具来说，公开的协议文本和开源代码就是分发渠道本身。 一个协议越开放、越多人讨论、越多代码可学，下一代模型就越懂它，agent 就越倾向于选它——这是一个会自我强化的循环。

封闭平台面对这个循环有两条出路。贵的那条是把格式本身开放，让模型学会它、让 agent 不用被提示就想到它。便宜的那条是格式照旧封闭，只在边缘采用一个开放协议——agent 于是能调用这个平台，尽管仍然学不到它。

本文最初的写法是：封闭平台进不了这个循环。不到一周，这个说法就被证明太强了——在位厂商走了便宜的那条路，而且走通了。留下来的是更窄、也更要紧的一句：agent 能调用的接口不等于 agent 能学习的定义，而这两样都不等于一个你能带走的运行时。在位厂商为此做了什么、又唯独没做什么，见下文。

等等——封闭平台不是也赢过很多次吗？

到这里，一个聪明的反驳应该出现了：开放未必赢。云计算时代赢的是 AWS，移动时代赢的是 iOS，都是封闭的。

这个反例值得认真接，因为接完恰好能看清规律。

看一眼 AWS 是怎么赚钱的：它托管的是 Linux、Kubernetes、Postgres——清一色的开放标准。iPhone 封闭，但它跑的网络是 TCP/IP 和 HTTP。再往前数：数据库厂商杀成红海，SQL 这个语言本身是公共的；容器编排打了三年，最后大家都跑在开放的 OCI 镜像格式上。

规律其实很整齐：被整个生态依赖的可移植底座最终会走向开放——既包括定义，也包括解释和执行这些定义的基础运行时。 厂商仍然可以获得持续收入，但卖的是托管运营、升级、安全封装、性能、支持和责任。AWS 自己就是最大的例证：Linux、Kubernetes、Postgres 保持开放，AWS 为可靠运营它们收费。

业务语义层正是这种底座。对象模型、权限规则、审批流程，以及强制执行它们的运行时语义，未来会被应用、agent、审计系统共同依赖。依赖越多，定义与运行时就越不应该只存在于某个供应商的平台里。定义应是你仓库中可读、可版本化的文件，兼容运行时则应可自托管、可替换。只能由一家付费引擎执行的“开放文件”，并不真正可迁移。

企业花了二十年把数据从一个个封闭系统里解放出来，不应该在 AI 时代把比数据更核心的资产——业务的定义本身——再锁进去一次。

Ontology MCP 打开了接口层，运行时依旧关着

这个规律几乎立刻被检验了一次，而检验结果比当初的预测更有说服力。

本文发布四天后，Palantir 的 Ontology MCP 在 2026 年 6 月 16 日当周面向 Foundry 环境正式可用（Palantir 官方文档）。对象类型、动作类型和函数被投影成 Model Context Protocol 工具，任何兼容 MCP 的 agent 都能读取这套 ontology 并驱动它的业务流程，不必再为每个 agent 框架各写一份对接代码。微软也在 Fabric IQ 上预览同样的接口。

随后在 8 月，Palantir 推出了 beta 阶段的「本体即代码」：对象类型、链接、接口与动作用 TypeScript 声明在一个 monorepo 里，这些代码定义就是唯一事实源。

把这两步放在一起看，上一节那个「底座终将开放」的判断成立了——但成立的理由和当初写下它时不一样。底座确实在开放。它之所以开放，是因为在位厂商自己把它打开了，而且是按对自己代价最小的顺序打开的：

层	它是什么	2026 年把它留在哪
接口层	agent 如何调用 ontology	已开放。 MCP，由平台厂商自己采用
定义层	对象、动作与权限	形式上在开放。以代码入库，仍要落到单一厂商的平台上
运行时	执行动作、并在执行时强制规则的那一层	原地未动。没有厂商交出一个你能换个地方跑的运行时

第三行值得慢慢读，因为整个论点就在那里。

开放的接口让 ontology 可被调用；放进仓库的定义让它可读、可评审。但这两样都不能让它换个地方跑起来。可移植的定义不等于可移植的系统：一个装满本体代码的 monorepo，最终仍要落在一套 Foundry 环境上。而且工具面是从定义投影出来的，谁运行这次投影，谁就决定了工具是什么。定义文件自己不执行任何东西。

这就是这次更新真正依赖的那个数字。把 Palantir 那套写进文档的投影规则套到一个中等规模的应用上——12 个对象类型、30 个动作类型、6 个对外函数——你会得到37 个说着开放协议的 MCP 工具，而底下只有一台引擎能回答其中任何一个。接口变得可移植了，依赖一寸也没动。

三层结构决定可移植性：接口层通过 MCP 开放，定义层以代码入库的形式开放，而负责强制权限、事务与审计的运行时原地未动

把最有力的反驳如实摆出来：团队真正想从可移植性里拿到的东西，如今大半已经拿到了。你可以读自己的模型、以 diff 的方式评审它、把任何 agent 指向它；分析型语义还能通过一份 2026 年进入 Apache 孵化器的中立规范来交换。如果你的 ontology 只需要回答问题，那已经接近够用了，本文不该假装不是。

而回答它的那条线，和「语义层」与 ontology 的分界线是同一条：它一直成立，直到有事情必须真的发生。当一个对外暴露的动作真的改写了一条记录，你在意的一切——权限校验、事务、超过阈值时的审批、那一行审计记录——都是引擎的性质，而不是文件的性质，也不是协议的性质。你能导出那句话，导不出那道强制。

把这个缺口叫作最后一层没有打开的地方。这不是指控，而是对这个赛道停在哪里的描述。九个月里有两层开放了，而且多半是靠自身惯性；第三层一动没动——因为那是平台生意在不改变自己卖什么的前提下无法打开的一层。

这层“定义”长什么样

说了这么多，看一眼实物。下面是 ObjectStack 类型化应用定义里的一个商机对象（节选自真实示例）：

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: '商机',
  fields: {
    name: Field.text({ label: '商机名称', required: true }),
    account: Field.lookup('crm_account', { label: '客户', required: true }),
    amount: Field.currency({ label: '金额', min: 0 }),
    probability: Field.percent({ label: '赢单概率', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: '预期收入',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: '折扣', max: 100 }),
  },
});

// 权限同样是声明的：销售可读写商机，但不能删除
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

关键不在语法，在于这几十行就是系统本身。开源 ObjectStack 运行时读取这份定义，派生数据表、REST API、管理界面、MCP 工具，并强制执行权限与审计。折扣超过 30% 要走财务审批？那是一条挂在这个对象上的流程定义，同样是声明式的，同样在版本库里。ObjectOS 在同一应用外增加商业生产体验——浏览器内 Build 与 Ask、团队审阅和审批、托管云或私有部署运营、SSO 与支持——但不会把定义或执行引擎重新变成专有依赖。

一份元数据定义，同时生效为 API、界面、AI 工具和审计权限

这带来三个直接后果：

开头那三个安全问题，有了结构性的答案。 AI 能看什么——权限集里写着；它执行动作按什么权限算——它以登录用户的身份行动，由 ObjectStack 运行时强制执行，而不是靠提示词约束；审计记录在哪——人和 agent 的每一次读写共用同一本账，谁、什么、何时、为什么，合规团队只看一本。
业务变更变成了代码评审。 AI 要给系统加一个“续约提醒”？它提交的是一份元数据 diff，改了什么字段、动了什么权限，一目了然。出问题可以回滚，因为定义是版本化的。
整个系统装得进一个 agent 的上下文窗口。 一个典型的企业模块，从几万行 CRUD 和胶水代码收敛成几百行声明——小到 AI 可以完整读懂每一处依赖，然后跨数据、API、界面、权限做一次安全的整体重构。这是“AI 当共同维护者”和“AI 当代码补全”的分界线。

定义与可移植运行时归社区，生产运营做生意

现在可以把整个论证收拢了。

Ontology 这个判断是对的，Palantir 已经替行业证明过。本文最初写下时，“定义开放、独家引擎收费”还是一种值得提前警告的失败形态。九个月过去，它不再是警告，而是对这个赛道最终落点的如实描述——由一群把除了自己所卖之外的一切都开放了的厂商，一个个合理决定累积而成。这反倒让另一条路更好讲了：类型化业务定义与可移植的治理运行时都属于开放生态；收费产品提供围绕它们的生产运营体验。

这正是 ObjectStack 和 ObjectOS 的分工：

ObjectStack 是一套开放业务本体（open business ontology）：类型化的应用定义，加上执行它的开源运行时（Apache 2.0）。对象、关系、权限、流程、API、UI、AI 工具在你的仓库里一次定义；运行时从中派生数据库、REST API、渲染界面与 MCP 服务，并在每次调用上强制权限与审计。定义和引擎都可 diff、可自托管、可迁移——而后一半，正是这个赛道其余玩家留着没开的那一层。
ObjectOS 是围绕同一 ObjectStack 应用的商业生产平台。它销售浏览器内 Build 与 Ask、团队审阅和审批、托管云或私有部署运营、SSO、企业控制与支持，而不是一台把业务本体重新锁回厂商手里的封闭执行引擎。

一边是任何团队、任何 agent 都看得懂、可自托管、带得走的应用定义与可移植运行时；另一边是企业真正愿意付费的生产体验：协作编写、审批、托管、私有部署、SSO、支持、升级和运营责任。应用及其基础运行时归你，为团队可靠运营它们才是生意。

结语

那个九个月死掉的 AI 试点，死因从来不是模型不够聪明，而是没有一个能让安全团队签字的业务语义层。行业里最贵的公司用十年证明了这一层的价值；而 2026 年只用九个月证明了一件更窄、也更有用的事：这一层里便宜开放的部分，现在都已经开放了。接口是一个公开协议，定义是一份你能读的文件。剩下的，是那台把定义变成接口、并在变的过程中强制规则的引擎——而这一层，什么都没打开。

所以本文在 6 月提出的问题，现在有了更锋利的形式。不再是「本体该不该开放」——那已经有了答案，而且是厂商自己给的。而是：当最后一层没有打开的，恰好是执行你业务规则的那一层，你希望那台引擎是谁的？

如果你想验证这套东西是不是真的：

npm i -g @objectstack/cli && os start

五分钟后，定义你的第一个业务对象，看开源 ObjectStack 运行时把它变成一张表、一个 API、一个管理界面和一个 AI 可以安全调用的工具。每次调用都带权限，每次调用都记账。如果团队需要浏览器内 Build 与 Ask、共享审阅和审批、托管云或私有部署、SSO 与支持，ObjectOS 运营的仍是同一份 ObjectStack 应用，不会换成专有格式或独家引擎。