在上一篇文章《OAG架构详解》中，我们拆解了OAG（本体增强生成）的四层组成与RAG的本质区别。文章发出后，很多同行和企业客户问了一个非常务实的问题："架构看懂了，但具体落地时，本体建模到底该怎么下手？"
很多技术团队一上来就对着老系统数据库建大而全的知识图谱，结果耗时半年、业务方看不懂、AI也跑不通。西安栈上月明软件科技有限公司（栈上月明）在多个中小企业老系统（ERP、MES、进销存、CRM等）AI化改造的实战中，总结了一套 "轻量级OAG本体建模五步法"。
不重构老代码，只加语义层。今天直接上实操，拆解这五步到底怎么干。
第一步：业务口径梳理（别一上来就看数据库）
本体建模的第一步绝对不是打开数据库看表结构，而是和业务骨干开会。AI听不懂"滞销品"、"高意向客户"这种业务黑话。 这一步要做的，是把模糊的业务规则翻译成明确的逻辑。比如，业务说"找出滞销品"，我们必须和业务确认并定义为："连续60天无出库记录 且 当前库存大于50件的SKU"。规则越清晰、无歧义，后续的本体映射才越准确。
第二步：核心对象提取（克制，先抓主干）
把梳理好的规则拆解成AI能理解的"对象"。不同行业的对象不同：
- 制造业/工厂：工单、物料、BOM、产线、设备。
- 批发/零售：客户、SKU、渠道、仓库、订单。
- 销售型/CRM：联系人、商机、合同、回款、跟进记录。
- 避坑指南：提取对象时切忌贪多求全。第一版本体建模，先抓核心业务流的 3-5 个主对象即可，跑通闭环后再做扩展。
第三步：关系与属性映射（最苦但最核心的一步）
这是老系统AI化改造的分水岭。我们需要把老系统数据库里的物理表结构，映射到第二步提取的本体对象上。 比如，老ERP里可能有 t_order_main、t_order_detail、t_material 三张表，通过外键关联。在本体层，我们要将其映射为"订单-包含-物料"的关系，并把"数量"、"单价"、"批次"映射为属性。 映射完成后，AI面对的不再是冷冰冰的 t_order，而是一张有业务含义的"关系网"。自然语言提问"某产线上月物料消耗是否异常"，即可被解析为沿特定关系的聚合查询，而非全表扫描。
第四步：MCP与受控挂载（守住安全底线）
本体建好后，需要让智能体能"摸"到数据。正如我们之前强调的，绝对不能让大模型直接写 SQL 去连生产库。 正确的工程化做法是：通过 MCP（Model Context Protocol）协议和安全 API 封装，把老系统的数据以"只读"或"受控写入"的方式，挂载为智能体可调用的标准工具（Tool）。同时，必须配合 AIP（Agent权限控制）体系，限定好入参类型和范围，高危操作强制人工确认，确保绝对不搞崩老系统。
第五步：Golden Set 回归测试（交付的底线）
模型会有幻觉，但业务决策不能出错。在交付前，必须建立一套 Golden Set（标准测试集）。 把业务方最关心的 50-100 个真实问题（如"上个月A产线的良品率为什么下降"、"华东区某大客户商机为何停滞"）作为测试题，验证智能体顺着本体关系推理出的答案是否 100% 准确。不通过回归测试，坚决不上线。
结语
OAG 本体建模不是纯技术活，而是"业务翻译 + 工程落地"的结合。对于西安及西北地区的中小企业来说，掌握这五步法，就能在不推翻老系统的前提下，让沉睡的 ERP、CRM 数据真正被 AI 激活。
如果您在老系统 AI 化改造或 OAG 本体建模中遇到卡点，欢迎在评论区留下【行业＋老系统名称】，或搜索"栈上月明"与我们探讨具体场景的落地可行性。本文由西安栈上月明软件科技有限公司整理。