上一篇文章中，我们简单描述了 AI 采购智能体被本体层拦截——供应商的认证证书还有 18 天到期，操作被阻断，重新路由给人工审批的流程。

那个场景是简化过的。它展示了本体层"能做什么"，却没有说清楚：这套本体是怎么建起来的？业务规则怎么梳理出来的？如果自己实现，从哪里开始？

本篇专门处理这些问题，不写代码，只讲建模和建模前后需要做的事。

场景比你想的复杂

上一篇的采购场景经过了简化：AI 发起操作，本体层检查条件，触发审批。但真实的采购协作是一条链——需求提报、供应商评估、询价比价、合同审批、发起订单、入库验收，背后是四套各自独立的系统。Agent 要回答的问题也不只是"能不能下单"，还包括：从哪家采综合最优、这张订单走哪条审批路径、入库量和订单量不符时该怎么处理。这才是本体层真实要面对的环境。

第一步：先界定问题，再确定范围

建模不能从"有哪些数据"开始。正确的起点是：现在的做法在哪里出了问题，这些问题集中在哪个业务范围内。

以采购场景为例，存在三类问题：

信息没法汇聚。 供应商信息分散在四个系统，各有各的同步时间，Agent 做决策时拿到的是不同时间点的拼凑结果，不一致是常态。

规则无法被执行。 "认证有效期不足 30 天须升级审批"写在 SRM 前端校验和 ERP 审批流里。Agent 走后端接口时绕过了所有前端校验，规则没有失效，只是从来没有在这条路径上被执行。

决策无法还原。 系统日志记录的是接口调用，但业务上发生的事是 Agent 代理采购经理发起了一笔 28 万元的备料采购。事后如果有争议，从接口日志里看不出为什么做这个决定。

确定范围。 清楚问题之后，还需要划定 MVP 边界。以上述三个问题为边界，本期先覆盖"供应商评估到发起采购订单"这段链路，暂不处理入库验收。这个判断决定了后续需要建哪些对象、连接哪些系统。

第二步：基于业务语义建模

范围确定后才开始建模。起点是业务语言，而不是系统字段。要回答五个问题：业务里有哪些独立存在的实体、它们之间有哪些有意义的关联、哪些指标需要计算才能得出、哪些约束必须始终成立、哪些操作需要被明确记录。

识别对象（Object）

判断一个概念是否应该成为独立对象，看三点：有没有自己的生命周期、有没有独立的属性集、是否被其他对象引用。

识别关联（Link）

关联描述对象间的联系，可以携带属性，且有方向（依据"从哪边查更自然"来选择）。

识别函数（Function）

有些指标需要汇聚多个对象的数据计算得出，定义为函数。函数只读，是规则和操作校验的"数据来源"。

制定规则（Rule）

规则是全局约束——无论通过哪个入口操作，规则都会在操作完成后被校验，违反则回滚。

定义操作（Action）

操作是业务上有名字的、需要被审计的动作，携带业务意图，执行时记录当时的上下文。

第三步：确定数据来源，做好治理准备

模型建完，才能确定需要从哪些系统取数据。顺序不能反过来——先看数据再建模，很容易被现有系统结构带着走，建出来的模型反映的是"系统长什么样"，而不是"业务是什么样"。

对照本体定义，逐个属性追溯来源系统：

在接入数据前，有几个治理问题需先解决：供应商在 SRM 和 ERP 各有一套编号，需要建对照表；认证证书过期日期存在 PDF 里，需要开发解析管道或人工补录；历史订单状态不完整的，只导入近两年有完整状态的记录即可。

建模决定了本体层能回答什么问题，数据治理决定了它能支撑多少场景。

怎么判断建对了

用三个问题来检验，不需要复杂指标：

信息汇聚有没有实现？ Agent 了解一家供应商时，能在本体层一次性拿到完整信息，还是仍需人工去多个系统查找拼凑？

规则有没有真正在执行？ 更值得警惕的是误拦截：合规操作被错误阻断。误拦截比漏拦截更需要优先处理——持续的误拦截会让业务人员绕过本体层直接操作，一旦形成习惯，整套约束就失去意义。

决策能不能说清楚？ 当一个 Agent 决策引发质疑时，能不能当天给出完整解释：Agent 看到了什么、依据了哪条规则、为什么这样判断？

这三个问题在建模阶段就应该想好如何收集答案，不要等系统上线后再补。

按什么顺序工作

四个有先后依赖的阶段，不建议并行启动：

第一阶段：调研与建模（最需要业务专家参与，工程师单独做往往跑偏）

与采购、供应链、合规团队开展工作坊，逐一梳理核心实体、关联关系、约束规则和需要记录的操作。结果用文档呈现（不是代码），请业务人员逐条确认。

完成标志：一份经业务确认的本体定义文档或者原型，包含核心对象、关联定义、函数逻辑和规则列表。

第二阶段：数据盘点与治理（模型建完后再确认数据来源）

对照本体文档，逐个属性找来源系统，评估同步方式和数据质量，优先处理阻塞系统运行的质量问题。

完成标志：每个属性有明确来源和同步方式，主键统一有可行方案，关键函数的数据可以被正确计算。

第三阶段：引擎搭建与数据接入（前两个阶段产出文档或原型，这个阶段才开始写代码）

完成标志：本体层 API 可被 Agent 调用，能执行对象查询、触发操作、校验规则，每次操作后留下可追溯的决策记录。

第四阶段：场景验证与调优（贯穿全程，引擎上线后做系统性回测）

用典型场景逐一验证，与业务人员走查规则边界，根据三个判断问题收集反馈并调整。

完成标志：业务团队确认本体层的行为满足业务规则——知道它会在什么情况下拦截，被拦截时能看到清晰原因，每个 Agent 决策事后都可以被完整还原。

结语

本篇把建模这一步完整走了一遍：先界定问题和范围，再基于业务语义推导出对象、关联、函数、规则和操作的定义，然后根据模型决定数据来源和治理工作，最后整理出一条有先后顺序的工作路线。

这个过程里最值得反复提醒的认知是：本体建模是把业务知识变成可执行定义的过程，而不是软件开发本身。 最难的环节不是选技术栈，而是和业务人员一起把那些"大家都知道但没有人写下来"的规则，变成能被系统执行的精确描述。