SUP-001 和 sup_001 是同一家公司吗？一个开源本体项目给的答案，只有三行代码

你公司里有三份数据。

采购系统写供应商编号，写作 SUP-001。仓储那套没人敢动的老系统，同一家写成 sup_001。法务柜子里那份合同 PDF 上，它叫「上海某某贸易有限公司」。

人扫一眼就知道这是同一家。机器不知道。机器看到的是三个毫不相干的字符串。

企业数据这摊事，八成的痛苦卡在这儿——不是数据不够多，是数据之间那根线断了。谁想在公司里真把 AI 用起来，迟早撞上这堵墙：模型再聪明，喂给它的也只是三张互不认识的表。

Palantir 对这堵墙的解法叫 Ontology，本体。说人话：先别急着分析，先在数据之上把「什么叫供应商、什么叫采购单、谁跟谁有关系、什么情况下允许做什么动作」这一整套重新建一遍。建完之后，人和 AI 看到的不再是表，是一张有名有姓、能推理、能落到动作上的知识网。

这东西 Palantir 卖得很贵。GitHub 上有个叫 nano-ontoprompt 的项目，想把它做成一个你自己就能跑起来的开源最小版。

我把源码从头读了一遍，两万一千行 Python，一万两千行 TypeScript，五月底开的坑，上周还在提交。

有意思的是：最见功力的地方，几乎都跟大模型无关。

先说它把本体拆成了什么

四块积木，不多不少：

实体——从一份清洗过的数据集里长出来的概念，一行数据一个节点。供应商、采购单、合同。

关系——实体之间的边。「这张采购单的供应商是谁」。这条边不用你手画，靠外键和跨表取值重叠自己推。

规则——金额必须大于零、库存状态只能这么流转。

动作——审批、改状态、把两个东西链起来。带提交准则，带审计快照。

前两块决定「这世界长什么样」，后两块决定「在这世界里能干什么」。少了后两块，你只得到一张好看的图；有了后两块，AI 才有地方落脚——它不再是给你写段总结，而是能真的按规矩去动一条记录。

那三行代码

在一个 79KB 的大文件深处，藏着这个：

def _normalize_fk_value(value: str) -> str:
    return re.sub(r'[\s\-_]', '', str(value)).upper()

去空格、去横杠、去下划线，全转大写。就这点事。

SUP-001、sup_001、SUP001——归成同一个键。开头那道题，这三行解掉了大半。

不写代码的人可能觉得，这也配叫见功力？

恰恰配。做过数据集成的都清楚，真实世界的脏，大头不是缺胳膊少腿，而是这种「明明是一个东西，写法各异」的碎屑。你当然可以上大模型做实体消歧，一次调用几分钱，一百万行烧到肉疼；也可以先拿三行正则把最常见的那七成扫干净，剩下真需要动脑子的——比如「上海某某贸易有限公司」怎么对上 SUP-001——再交给模型。

它选了后者。语义链接那个开关它留着，默认关掉。

省钱只是顺带的。更要紧的是：能用确定性代码解决的，就别丢给概率机器。正则错了你能复现，模型错了你只能重新求它一次。

重跑一遍，图不会炸

第二个不起眼的细节：所有实体和关系的 ID，不是随机生成，是拿「本体 ID + 实体类型 + 业务标识」算出来的固定值。同样的输入，永远同样的 ID。

这意味着什么？今天跑一遍，明天数据更新了再跑一遍，同一家供应商还是同一个节点，不会分裂成两个。

做过数据管道的人都被这事咬过：重跑一次，图里凭空多出一堆孤魂野鬼，然后你花一整天写去重脚本。

幂等两个字说起来轻巧，很多项目就是不做——因为「跑一次能出结果就行」。而这个项目从一开始就假设你会跑很多次。这是两种完全不同的心态。

它一个字都不敢直接信大模型

让模型吐 JSON，是所有 AI 应用的日常噩梦。它可能在外面裹一层 markdown 代码围栏，可能在里面塞控制字符，可能括号少一个。

这项目的解析函数，一层一层往下兜：先剥围栏，再洗控制字符，再上专门的修复库，还不行就从字符串里硬截第一个 { 到最后一个 }。四层。

更狠的是关系类型。中文语境下，模型特别爱吐「关联」这种词——听着像回事，实际什么都没说。你满图都是「关联」，等于没建关系。所以它在系统提示里直接下禁令：不许用模糊词，只能从这份英文清单里挑。

这一条我看了觉得亲切。这不是设计出来的，是被幻觉咬过之后留下的疤。

那个审计智能体，八个工具一个都不调模型

项目里有个质量审计的 AI 智能体，跑 ReAct 那套：想一步、动一下、看结果、再想。

它有八个工具：查本体概况、找孤立实体、检查关系引用、检查规则引用、检查动作引用、算实体覆盖率、找缺失关系、提交结论。

八个，全是纯 Python 写的，一个都不调大模型。

我认为这是整个项目最值得抄的一处。

分工被切得干干净净：大模型只负责「现在该看哪儿」这个判断，所有真正的数据操作，落在确定性代码里。于是每一步都能测、能复现、能在出错时精确定位是谁的问题——是模型判断偏了，还是工具本身算错了。

反过来，如果工具内部也在调模型，那你就套了两层不确定性。出了事，你连该骂谁都不知道。

想跑起来？什么都不用装

Neo4j、MinIO、ChromaDB、Redis——听着就头大的一串。这项目的态度是：全部可选。

没有图数据库，退回本地库存图；没有对象存储，就写本地文件；没有向量库，改用关键字搜；没有消息队列，管道同步跑。健康检查挨个探一遍，谁不在就标个「不可用」，绝不因此崩掉。

对开源项目而言，这是能不能被人真正试用的生死线。多数人的耐心只够 git clone 之后跑两条命令。你要求他先起五个中间件，他就走了。

顺带一提，它还有条硬规矩：生产环境下，如果密钥、管理员密码这些还是默认值，直接拒绝启动。不是打个 warning——是起不来。带默认密码上线这种祸事，光靠提醒是防不住的。

诚实的部分：野心跑在实现前头

它仓库里有份两千七百行的中文架构文档，讲本体该怎么设计：对象、链接、函数、治理、事件总线；权威数据和参考投影要分层；动作分「自动执行」和「需人确认」两级；租户隔离怎么贯穿全链路；甚至写到临床场景怎么处理知情同意和危机事件。

写得非常好。好到有点超前——文档里画的那套，代码只落地了一部分。

这不算骗人，作者也没吹已经做完。但你要用之前得揂量清楚：那两千七百行是北极星，不是验收单。分清楚「它说自己想成为什么」和「它现在是什么」，这本来就是读任何开源项目该有的基本功。

其他坑也有：那个 79KB 的单文件迟早要拆；前端选了相当激进的新版本，生态兼容有风险；异步队列那条路声称可选，多半是没在真实压力下跑透。

所以值不值得看

如果你手上有一堆 Excel、CSV、合同 PDF，想把它们变成一张能查、能推理、还能挂动作的图——值得。至少值得跑一遍它的完整管道，用你自己的真实数据，别用它的 demo。

但我更想说的其实不是这个项目本身。

这两年做 AI 工程，最容易走的岔路是：什么都想交给模型。数据不干净？模型清。关系找不到？模型推。结果不对？换个更大的模型。

这个项目从头到尾在做相反的事——能用三行正则解决的不调模型，能算出来的 ID 不随机生成，能用纯函数写的工具不套第二层模型。模型只被放在真正需要判断力的那一小块地方。

把确定的事情做确定，才配把不确定的事情交出去。

这句话不新鲜，但在 2026 年，愿意这么写代码的人，比会写 prompt 的人稀缺得多。

#知识图谱 #AI工程