当 Agent 要「看懂」你的数据：从数据库到本体论

一、一场讨论的缘起

最近，老冯写了一篇探讨 Palantir 的文章，观点依旧犀利，我 98% 认同。唯独对文末那句结论，我想提供一个不太一样的视角。

Palantir 干的事，无非是把写 ETL、建表、配权限这些成千上万工程师每天都在做的苦力活，套上了一个亚里士多德式的名词，卖出了一个 AI 时代的估值。

冯若航，公众号：老冯云数 Palantir 的 “本体论骗局”

我的看法是：

在前 AI 时代，数据库主要是通过前端 UI 给「人」用的。因此，底层表结构的「语义」往往没有被认真、集中地维护——它们散落在前端文案、产品文档、培训材料，甚至老员工的口耳相传里。

但在 AI 时代，一旦要在数据库层面面向 Agent 准确维护「这张表、这个字段到底在说什么」，这件事的价值就陡然放大了——因为只有跨越了这道语义鸿沟，很多业务的真正自动化才成为可能。

在我们的交流中，老冯的回复：

「你给我看代码，我不一定知道你的业务是干什么；但你给我看数据库表结构，我一眼就知道你的业务是干什么。」

我进一步补充的是：人类专家看一眼表结构，确实能知道业务在做什么；但这其中的精度，往往达不到 Agent 的正确性要求。

典型场景比如用 NLP2SQL 做数据统计：遇到多个同义字段（如 status / state / phase），Agent 该用哪一个？字段取值 1, 2, 4, 5, 8 分别代表什么？往往要人类去翻文档、翻代码、重新整理，才能保证 Agent 不跑偏。

老冯的这篇文章，标题就叫《Palantir 的“本体论骗局”》。顺着他抛出的“本体论（Ontology）”这个概念，下面我想用这篇短文，把「本体论在概念层面和数据库一致，在实践层面却更纯粹」这个视角梳理清楚，供大家参考。

二、先把事实摆到桌面上

老冯在文章中有一个极具价值的洞察，值得先单独拎出来看。

事实是： Palantir Ontology（本体）有四个核心概念：Object Type（对象类型）、Property（属性）、Link（关联）、Action（操作）。翻遍他们所有的文档、白皮书和路演材料，这四个概念是一切的起点。

现在，请看这张表：

哲学、数据库、面向对象与 Palantir 概念对照表：事物的类型、特征、关联、操作与具体事物

四列，四种术语体系，描述的却是同一件事。这不是「可以类比」，也不是「有点像完」，而是全重叠，严格同构。

不仅如此，Palantir 在文档里还定义了 Interface（接口多态）、Function（代码逻辑）、Virtual Table（虚拟表）等子概念。翻译过来，其实就是数据库里的 View（视图）、UDF（用户定义函数）和 Materialized View（物化视图）。

可以说：如果你学过数据库建模，你就已经完整掌握了 Palantir 所谓的「本体论」。

老冯把这一点说透，其巨大的价值在于：我们不必被「亚里士多德」、「本体论」这些高大上的词汇唬住——在概念体系的层面，大家讨论的本来就是同一套东西。

而我后面想补充的，是在「概念一致」之后的另一层思考：在实践中，为什么同样是这套东西，数据库和本体论会走出两条截然不同的路？而 AI 时代，又为什么会让「对语义较真」的那条路变得越来越值钱？

三、实践层面：数据库面向应用，本体论面向「语义完备」

真正的分歧，出在实践落地上。

1. 数据库：为「当前应用」服务

在真实的工程项目里，数据库的 Schema 几乎总是面向具体应用长出来的：

表名、字段名往往跟着某一版的业务需求、某一套前端页面或报表来命名；
同一个业务概念，可能在不同的表里用着不同的名字（比如 user_id / uid / owner_id）；
一张表里往往堆砌了多个相似的业务时间字段让人一头雾水（比如同时存在 start_time / begin_time / create_time，或多个结束时间 end_time / finish_time / expire_time，外人根本不知道该以哪个为准）；
枚举值 1, 2, 4, 5, 8 的具体含义通常被写在接口文档或代码注释里，而不是在 Schema 中进行显式约束；
历史包袱或性能考量会导致大量的冗余表和冗余字段，其背后的真实语义往往散落在后端代码逻辑、前端展示文案、技术设计文档、产品需求说明，以及团队成员的「口口相传」之中。

所以，数据库在实践层面是「应用开发导向」的——只要能跑通、能查询、能上线就行。语义是否完备、是否一致、是否方便被「机器理解」，往往不是第一优先级。

老冯说的「看表结构就能知道业务在干什么」，在人类专家身上完全成立；但对于 Agent 来说，中间还缺了一层至关重要的映射：缺乏对「这张表、这个字段、这个取值在概念上到底对应什么」的显式、无歧义的说明。

2. 一个熟悉的场景：数据分析师的「调研」

做过数据分析的同学一定深有体会：接到一个报表需求，真正写 SQL 的时间也许很短，但搞清楚「相关表的精确定义」往往占了工作量的大头。

哪个字段代表当前状态？哪个代表历史状态？order_amount 和 pay_amount 究竟差在哪里？在这张表里 type = 3 是代表退货还是换货？——为了搞清这些，你需要去翻文档、问业务、读代码。经过一轮漫长的「调研」，才能确信自己写出的 SQL 不会出错。而且调研的结果，并不会完备本身的表结构语义信息，而是沉淀在了数据分析的文档、代码中了。

数据分析师的做法是典型的「按项目调研」：每来一个需求，就针对性地搞清楚这次会用到的那几张表、那几个字段的精确含义，够用了就开工。其他没涉及的表先不管。

这种模式在「人力驱动」时完全合理——毕竟人力成本高，不可能「先把全库所有表的语义都理清了一遍再开始干活」。

然而，本体论的思路恰恰相反：它要求在最开始就把所有概念、属性、关系的精确定义做好。 不管当下有没有报表需求，有没有具体的分析项目。

这在过去看起来「太重了、没必要」，应用的快速开发上线是第一位的。反正每次有需求的时候分析师调研一次就行。但如果换成 Agent 来做数据分析呢？

Agent 没办法主动「发起一轮调研」，也没办法「找个老员工问一嘴」。它需要的是事先就准备好的、覆盖全局的精确语义——这恰恰是本体论一直在做的事。

3. 本体论：为「语义」服务，难建但更完备

本体论在实践中的设计目标截然不同：它追求的是概念本身的清晰、一致与可推理。

概念必须有明确的定义，不能依赖某一个前端页面的文案或某一份内部文档；
同义、近义概念需要显式声明（比如它们是等价、子类，还是部分重叠）；
取值集合（如状态枚举）会在本体中被定义为独立的「概念」或「枚举类型」，而不是硬编码藏在业务代码里；
关系（谁是谁的一部分、谁依赖谁）也会被清晰界定，便于逻辑推理和校验。

当然，代价也很明显：本体论通常更抽象、前期构建更「难」。团队需要先把领域概念理清、命名统一、关系写全，才能建好一个像样的本体。它不直接服务于「这个按钮点下去该查哪张表」，而是服务于「这个领域里到底有哪些核心概念、它们究竟是什么意思」。

正因如此，过去很多团队会觉得它「用不上」、「太重」，宁可继续采用「弱语义表结构 + 文档 + 口耳相传」的实用模式来维护语义——毕竟对于传统的 CRUD 应用来说，这种方式往往是最轻量且高效的。

换句话说：在实践层面，数据库是「应用开发友好、语义松散」；而本体论是「语义严谨、对应用开发不直接友好」。前者容易落地，后者则更接近「业务概念本身该有的样子」。

四、AI 时代，为什么「语义完备」突然值钱了？

在前 AI 时代，使用数据库的是人：人可以通过看表名、看注释、问同事、翻文档，自行脑补出所需的业务语义。Schema 不必、也往往没有做到「语义完备」。

但在 AI 时代，使用数据库的变成了 Agent：它没有「问同事」「翻文档」的能力，只能依赖你显式喂给它的那点信息——表结构、字段说明、取值含义、同义关系。

这时候，两者的差距就显现了：

如果仅靠 Schema + 命名：人类能猜个大概，Agent当然也能猜个大概，但很容易在「该用哪个同义字段」、「这个枚举值什么意思」上犯低级错误，导致输出的结果错误、不可信，进而使得整个 Agent 在真实业务场景中根本不可用。
如果在数据库之上（或之外）有一层本体：把「业务概念 ↔ 表/字段/取值」的对应关系、同义关系、取值语义都显式维护好，Agent 就可以先在「概念层」做逻辑推理，再精准映射到具体的表结构上。这样一来，正确率和可信度都会有质的飞跃。

有了这层完备的语义，Agent 才能真正走向规模化的高级应用。 比如：

Agent 数据分析（Text2SQL）：Agent 能精准区分「订单金额」与「实付金额」，明确知晓哪个枚举值代表「退货」，从而自动写出业务上 100% 正确的查询，无需人类前置调研。
Agent 自动化运营：当你下达“给本月无退货的 VIP 用户发优惠券”时，Agent 能顺着本体图谱，准确找到“VIP 用户”的概念定义，关联到正确的业务表，并自动触发绑定的“发券操作（Action）”。
Agent 异常归因与决策支持：当业务大盘出现异常时，Agent 可以基于本体中的逻辑关联（Link），一层层顺藤摸瓜，排查是流量、库存还是履约哪个节点出了问题。

很多人觉得数据库表结构和本体论在概念上一样，在日常人工开发时实践中感觉也差不多。但对于 Agent 而言，正是差的这“一点点”确定性，会导致商业价值的巨大鸿沟：一个是偶尔犯错、只能当做玩具的 Demo（因为即使80% 的准确率在真实业务中往往等同于不可用）；另一个则是能真正规模化落地、值得信赖的数字员工。

也许有人会说：“那所谓的本体论，本质上不就是在数据库层面强加了一个语义层吗？”

技术上确实如此。但实践中的根本差别，在于对「语义」的重视程度。 在过去，这种重视被认为是吃力不讨好的；而在今天，它关乎 Agent 的成败。这其实已经超出了单纯的技术范畴，变成了一个项目管理、甚至企业文化（对数据治理的敬畏感）层面的挑战。

本文来自公众号「深流AI」。阅读微信原文