企业 AI Ontology：为什么业务语义层应该是开放协议

先给结论：AI 进企业需要一个受治理的业务语义层；但这一层更适合像 Linux 一样是开放协议、归企业自己所有，而不是锁进某个封闭平台。定义层开放，运行时承担执行、权限、审计和运维责任。

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

某家企业立项做“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 来写，这就不只是营销问题，而是机器可学习性问题。

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

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

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

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

规律其实很整齐：被整个生态依赖的“定义层”最终走向开放——因为没有人敢把自己的资产建立在单一厂商的语法上；而“运行层”可以封闭、可以收费——因为运行意味着持续的运维、性能和责任，这是真实的持续成本。 AWS 自己就是最大的例证：定义归社区，运行收钱。

业务语义层是典型的定义层。你的对象模型、权限规则、审批流程，未来会被你的应用依赖、被你的 agent 依赖、被你的审计系统依赖——依赖的东西越多，它就越不应该锁在某一家的平台数据库里，而应该是你自己仓库里可阅读、可版本管理、可带走的文件。

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

这层“定义”长什么样

说了这么多，看一眼实物。下面是 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 },
  },
};

关键不在语法，在于这几十行就是系统本身。运行时（ObjectOS）读取这份定义，自动生成数据表、REST API、管理界面，以及——AI agent 可以直接调用的受治理工具。折扣超过 30% 要走财务审批？那是一条挂在这个对象上的流程定义，同样是声明式的，同样在版本库里。

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

这带来三个直接后果：

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

协议归社区，运行时做生意

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

Ontology 这个判断是对的，Palantir 已经替行业证明过。但按“定义层开放、运行层收费”的规律，这一层在 AI 时代的健康形态是：业务语义协议像 Linux 一样属于开放生态，治理运行时在你自己的环境里执行它。

这正是 ObjectStack 和 ObjectOS 的分工：

ObjectStack 是描述业务应用的开放协议（Apache 2.0）：对象、关系、权限、流程、API、UI、AI 工具，一次定义。它存在于你的仓库里，可 diff、可迁移、可被任何 agent 读取——也因此存在于公网和未来模型的训练数据里。
ObjectOS 是这些定义的运行时：在你自己的服务器上、你自己的数据库上执行一切，并在运行时强制权限、记录审计。治理不写在提示词里，写在执行引擎里。

一边是任何团队、任何 agent 今天就能用得起、读得懂、带得走的协议；一边是企业愿意为之付费的东西——托管、合规、多环境发布、持续运维。定义归你，运行的麻烦归我们。

结语

那个九个月死掉的 AI 试点，死因从来不是模型不够聪明，而是没有一个能让安全团队签字的业务语义层。行业里最贵的公司用十年证明了这一层的价值；接下来的问题，是让它不再是头部企业的奢侈品。

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

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

五分钟后，定义你的第一个业务对象，然后看着它同时变成数据表、API、管理界面，和一个 AI 可以安全调用的工具——每一次调用都带着权限，记着账。