ARTICLE · 1051085
本体论不是企业 AI 的地基
本体论不是企业 AI 的地基
《当 Agent 开始操作企业：ORYH 的设计探索》· 随笔 最近常听到一种说法：企业要用好 AI，得先建本体（Ontology）。把客户、订单、合同、设备这些业务概念，连同它们的属性、关系和可执行的动作，统一建模成一层语义结构，AI 再在这层结构上工作。没有本体，企业 AI 就是空中楼阁。 我们不同意。本体过去确实解决过真实的问题，但它要解决的那个问题，在 AI 时代已经基本不存在了。继续把它当作地基，等于让一个能读原文的人去读翻译稿。 先问一句：它是为谁设计的？ 今天企业 AI 语境里谈的本体论，主要来自 Palantir。Palantir 从 2000 年代起为情报机构、政府和大型企业整合数据，后来在 Foundry 平台里把这套做法系统化为 Ontology，推出 AIP 以后，又把它定位为企业 AI 的底座。再往前追，计算机领域的"本体"至少可以追溯到 1990 年代初的知识工程，以及后来的语义网。 也就是说，这套方法成形于大语言模型出现之前的二三十年间。 早，并不等于错。但 AI 出现以前形成的软件方法，几乎都默认了同一个前提：计算机读不懂人写的东西。数据库范式、ERP 的字段和状态机、工作流引擎里的条件表达式，还有本体，都建在这个前提上。前提变了，建在上面的东西就都值得重新审视，而不是原样搬进新时代，再贴上"AI 基础设施"的标签。 我们说 AI 时代的 ERP 得重写，而不是加个 Agent，也是同一个道理。 本体翻译的，正是 AI 已经能读的东西 把本体拆开看，它做的其实是翻译。 合同里写着"验收合格后付余下的 10%"，CPU 读不懂这句话。于是建模人员定义一个"付款条件"对象，给它"比例"和"触发事件"两个属性，再把"验收"链接到交付对象。客户在邮件里说"这批先别发，等我们仓库腾出来"，程序也读不懂，于是要设计一个"暂缓发货"的状态。三个系统对同一家客户的叫法各不相同，程序判断不了是不是同一家，于是需要一个统一的客户对象去对齐。 这些工作在过去非常有价值。确定性的程序只能处理确定的结构，人的语言必须先翻译成机器能处理的形式，软件才能查询、统计和执行。本体就是那本翻译词典，比一张张孤立的数据库表多了语义。 可大语言模型改变的恰恰是这一点。它能直接读合同条款，能读懂邮件里的言外之意，能看出"上海某某医疗器械"和"某某医疗（上海）"大概是同一家公司，拿不准时还能提出疑问。以前必须先由人翻译、机器才能读的内容，现在 AI 可以直接读。 为一个读得懂原文的读者预先准备一份翻译稿，这件事本身就该被质疑。 翻译总会丢东西 更麻烦的是，翻译不是免费的。 从原始材料到结构化模型，每一次转换都是有选择的压缩。建模的人要决定保留哪些属性、忽略哪些细节、用几个枚举值覆盖现实。这些决定只能在建模当时作出，依据的是当时想得到的问题。 我们做合同模块时，在测试里放过一段付款条款：签订后三个工作日内付 30%，首批货物发出前付 60%，验收合格后付余下的 10%。压缩成"首付 30%，发货前 60%，验收后 10%"，读起来很顺，结构也整齐。可首付有几天期限？是每批发货前都要付，还是只有首批？恰恰是这两个条件决定下一步该做什么，而它们在压缩中消失了。 换成本体也一样。"付款条件"对象如果没有设计"期限"和"适用批次"两个属性，这些信息根本进不来。不是被记错了，而是没有地方可放。之后 AI 在本体上查询，查得再准，也只能拿到建模人员当初留下的那一部分。 而企业里真正难的问题，往往就出在建模时没想到的地方：例外、附加条件、谈判时的口头让步、客户语气里的不满。越影响判断的信息，越难被预先设计成属性和链接。AI 能从原文里读出更多东西，为什么还要让它去读一个信息更少的副本？ 那 Oryh 里就没有结构了吗？ 有，而且不少。这一点得说清楚，否则这篇文章很容易被读成"数据随便放，AI 自己看着办"。 Oryh 的分工是：软件负责记录，Agent 负责逻辑。订单明细要合计成订单金额，付款不能超额核销，没有权限就不能写，同一个请求重试不能记两次，谁在什么时候做了什么要能追溯。这些结构和约束由代码保证。它们存在，不是因为机器读不懂人话，而是因为钱要对得上、责任要分得清。就算 AI 读得懂一切，这些要求也不会消失。 我们不做的，是把企业的"意义"预先翻译成一层模型。合同原件作为附件保存；Agent 摘录条款时逐字保留原文，记下来自哪个文件、哪一页、第几条；它自己的理解另写成摘要，和原文放在一起。公司的审批规则保存为带版本的自然语言文字，Agent 每次推进前读取，而不是翻译成一套条件表达式。"还剩几天假"也不是一个存好的字段，而是 Agent 在需要时，读当时适用的制度和相关假单算出来的答案。 这里的区别，是索引和替身。条款摘录、页码、经人确认过的商品名称对应关系，都是帮 Agent 更快找到依据的索引，找到以后仍然可以回到原件核对。而本体的设计意图，是成为 AI 理解企业的那一层：AI 通过对象、属性和链接理解业务，原始材料退到了数据管道后面。目录可以有，替身不必有。 难题并没有消失，只是换了位置 直接读原文，不代表问题都解决了。 AI 会读错，所以原文要保留、位置要记下，让人能追问一句"你凭什么这样判断"。材料太多读不过来，所以需要检索和摘录，但它们指向原文，而不是取代原文。规则写得含糊，AI 不该自己补齐，要停下来问制定规则的人。每次都读原文也有成本，这笔账我们还在算。 但这些难题出现在正确的位置上：怎样让 AI 读得准、找得到、可复查。而不是在 AI 和业务之间，再修一层需要建模顾问长期维护的翻译层。本体不只描述数据，还把动作和业务规则也建模进去；企业的做法一变，就得重新开一次建模项目。这和"管理方式一变，就要改一遍 ERP"是同一个老问题，只是换了个名字。 本体论曾经是一座桥，一头是人的语言，一头是读不懂人话的机器。现在机器已经能读人话了。企业 AI 的地基，应该是忠实保存的原始事实、清楚写下的规则，以及一个能直接读懂它们、并愿意把依据摆出来的 Agent。