前阵子参加过一次本体项目的验收会。

汇报人讲了四十分钟。对象、属性、关系、规则、动作，十几张图，一张比一张漂亮。

讲完，领导问了一句：那系统跑起来的时候，谁在用它？

会议室安静了三秒。

然后有人接话：这个模型主要是给后续开发做支撑的。

那句话我记到现在。因为"给后续开发做支撑"翻译过来就是——现在没人用。

一、本体的标准结局，是变成一份很漂亮的文档

这个行业里，本体项目的收尾动作几乎都一样。

出一份建模文档。截几张图谱的图。写一份验收报告。开个会，拍照，散会。

然后就没人再打开它了。

不是做得不好。有些项目做得很认真，对象拆得细，关系理得清。

问题在于，它被当成了"设计成果"。

设计成果的价值，是在交付那天兑现完的。验收通过，价值清零。

后面系统怎么跑，跟它没关系了。

二、后来我看到一个说法，把这件事说清了

看本体这件事，不要只看它在设计阶段定义了什么，要看它在运行阶段参与了什么。

这句话给了一个很硬的判断标准。

Agent 每一步是否回头查它。

查，它是运行时服务。

只在启动时读一遍，它是一份说明书。

说明书没人看。服务却不能不查。

这个区别听着小，实际是两个东西。

一个是交付物。一个是基础设施。

三、真正的差别，在一个很小的动作上

拿一个具体的活说：找出华东区逾期超 30 天的客户，并创建跟进任务。

没有本体的时候，Agent 得自己搞清楚好几件事。

查哪张表。怎么关联。逾期从哪天算——到期日还是最后还款日。华东怎么划——按分行、按区域码、还是按客户所在城市。跟进任务写到哪个库，字段怎么填。

它其实是在写查询语句，只是换了个说法。

每一步都可能出错，而且错了以后，它不知道错在哪儿。

有本体的时候，Agent 只说一句：我要 PendingFollowUp 这批客户。

剩下的交给本体。

它去查，去算，返回一批业务对象。顺便给一条依据：这三个客户是因为什么被判定为逾期的。

差别不在能不能查出来。

差别在 Agent 知不知道自己在查什么。

它不需要知道表结构。它需要知道业务概念。

这句话再往下说一层：它不需要懂数据库，它需要懂业务。

这两件事，过去都压在人身上。现在压在本体身上。

也正因为这样，出问题时能查。它给出的那条依据，就是"我为什么这么判"。

人看到依据，才知道该不该信它。

四、把这条链路走完，位置就清楚了

模型负责推理，把人的目标拆成动作。

Harness 负责调度，管状态、管重试、管什么时候停。

本体负责四件事：定义（这是什么）、身份（这是谁）、规则（能不能做）、行动（怎么做）。

业务系统负责执行，也负责给出真实回执。

这五层里，最容易搞混的是中间两层。

Harness 管"怎么把这件事做完"。本体管"这件事算不算对"。

一个管流程，一个管判断。

它跟 MCP 的分工也是一句话：MCP 解决够得着，本体解决该不该。

模型能打电话给任何系统，这是 MCP 的事。打过去之后这句话该不该说，那是本体的事。

能力可以买，判断买不到。

五、这条路真正的难点，不在技术

技术链路是通的。上面那些步骤，任何一家有积累的银行都做得出。

难的是另外三件事。

第一件：客户号是统一的，但别的号不是。

这一点容易被想当然。

银行有客户信息统一系统，同一个客户，核心系统、信贷系统、客户关系系统里用的是同一个号。这层主数据，十几年前就做完了。

但它统一的只是"客户"。

合同、保函、凭证、单据、账户、机构、产品、科目——这些实体没有统一的身份。

举一个具体的：一笔进口开证，国结系统给一个业务号，单证系统给一个单据号，影像系统给一个档案号。

三套号，对的是同一件事。

本体要把它们串起来，就得先建一层映射。这一层没有现成的，只能一家一家对。

而且它有个麻烦：映射是会变的。业务改版、系统换代、机构调整，编号规则跟着变一次，映射就得重做一遍。

这是八成的活，也是最不出彩的活。做好了没人看见，做漏了整条链路就断在第一步。

第二件：改口径。

规则写错了要改，改了之后历史数据怎么看，报表怎么追溯，谁批准。

改口径这件事，在组织里等于当众认错。

所以大部分时候没人改。规则就这么错着用，大家心里都清楚。

第三件：谁维护。

本体是活的。业务变了，规则要跟着变。

但这份活不进任何人的考核。做好了没人看见，做差了立刻出事。

没人愿意接。

技术的坑能填，组织的坑填不了。

这句话我越来越信。因为技术上的问题，总能找到一个人解决。组织上的问题，找不到那个人。

最后

判断一个本体项目成没成，别看建了多少个对象，画了多少张图。

看一件事：系统跑起来之后，还有没有人回头查它。

查，它活着。

不查，它只是很漂亮的一份文档，躺在某个共享盘的某个文件夹里。

那个文件夹的名字，通常叫"项目交付物"。