AI 需要一个 Ontology，但它应该是开放协议，而不是封闭平台
Palantir 用十年证明了 AI 进入企业需要一个受治理的业务语义层，这个判断是对的。但当软件越来越多由 AI 写出来、技术选型越来越多由 agent 完成，这一层的形态值得重新想一遍：哪一层应该开放，哪一层适合收费。
先给结论：Palantir 已经证明 AI 进企业需要一个受治理的业务语义层；但这一层该像 Linux 一样是开放协议、归你所有，而不是锁进某个封闭平台——定义层开放，运行时收费。
先讲一个你大概率亲眼见过的过程。
某家企业立项做“AI 助手”。第一周，演示惊艳：把客户数据导出一份给模型，它真的能回答“华东区哪些客户续约风险高”。高管看完当场拍板扩大试点。
第三个月，要接生产数据了，安全团队进场，问了三个问题：
AI 能看到哪些数据？销售 A 问“全公司业绩排名”，它会不会把别人的提成也答出来？
它要执行动作——改折扣、发合同——权限按什么算？出错了算谁的？
审计要查“这笔折扣是谁批的”，AI 参与的那部分，记录在哪？
项目组答不上来。不是态度问题，是架构里根本没有能回答这些问题的层。数据散在十几个系统里，权限写在各个应用的代码里，“折扣审批”这个业务规则只存在于某个资深员工的脑子里。AI 面对的是一堆裸表和裸接口，它再聪明，也没有地方去“看懂”这家企业的规则。
第九个月，试点悄悄结束。模型没有输给能力，输给了没有人敢签字。
这件事行业里有一个名字，叫缺一个 Ontology（业务本体）：一个结构化、机器可读的语义层，把“这家企业有哪些业务对象、它们之间什么关系、谁能对它们做什么、做了之后记在哪”显式地定义出来。
Palantir 把这件事做成了千亿美元的生意
把 Ontology 从论文概念变成商业事实的，是 Palantir。值得认真看一下它为什么成功——看得越公道，后面的问题才越清楚。
Palantir Foundry 的核心动作是两个。第一，把企业散落各处的数据集成进一个统一的本体层：客户、设备、订单不再是几十张表，而是有类型、有关系、有属性的业务对象。第二，把所有写操作收敛成受控的 Actions——每个动作带校验、带权限、带完整审计。2023 年之后的 AIP 把这套架构直接对准了大模型：LLM 不碰数据库，只能调用本体层暴露出来的受治理工具。 模型可以换，边界不动。
这套东西为什么贵？因为它解决的问题确实贵。把一家大企业二十年攒下的烂系统梳理成一个干净的本体，需要 Palantir 的驻场工程师（Forward Deployed Engineer）一个系统一个系统地啃，一个概念一个概念地对齐——这是实打实的人力密集型工程。它的客户是政府、国防、金融、能源，这些客户对“AI 每一步都在权限之内、都有记录”的要求是硬性的，预算也配得上。单个合同百万美元起步，客户照样续约，因为它真的回答了 CIO 最关心的那三个问题——就是开头安全团队问的那三个。
所以 Palantir 的市值证明的不是销售能力，而是一个架构判断：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 时代把比数据更核心的资产——业务的定义本身——再锁进去一次。