业务系统本体抽取：实体到策略清单

2026-06-11阅读 0热度 0

人工智能

# 无法忽视的本体构建前几篇始终围绕一个核心论点：本体由实体、属性、关系、动作四大要素构成。但光讲概念不够，这次直接上干货。我们拆解一个真实的企业软件，逐类列出可自动抽取的内容，以及每类内容对AI操作系统到底意味着什么。先给个参照物：活字格低代码平台内置的库存管理系统demo。这套系统覆盖采购、入库、出库、库存查询等核心流程，规模适中，用来解构刚刚好。 --- ## 实体：系统里都有哪些“对象” 实体是整个本体结构的骨架，所有其他要素都依附其上。没有实体，一切都是空中楼阁。从这套工程中能抽取两类实体。 **技术实体**对应系统内部的数据结构。说白了，每一张数据表就是一个技术实体，它的名字来自开发者在平台里配置的表名。库存管理系统里的“物品表”“供应商表”“入库单表”“出库单表”“盘点表”……每一张表的名称，直接告诉AI这个实体承载的是哪类业务数据。服务端命令的输入参数集和输出参数集也各自构成一个技术实体。拿“创建出库单”这个命令来说：输入参数（物品ID、出库数量、仓库ID、经办人）是一个参数实体，输出参数（出库单ID、创建状态）则是另一个。为什么要把参数集单独抽出来？因为AI只有看到这些“参数实体”时，才能明确知道执行一个命令需要哪些信息。没有这个参照，它只能靠猜。 **业务实体**对应用户在系统里实际操作的界面。每个页面就是一个业务实体。这里有个有意思的点：页面名称通常比表名更贴近业务语言。“物品_库存”这个页面名，就比“物品表”更直接地告诉AI“这是个看库存的地方”。页面上的表格控件名称同样作为业务实体的别名被抽取——“库存物品信息表格”这个控件名所提供的业务语境，比页面名更具体。两类实体共存于本体里，它们之间的对应关系完成了一次技术名称到业务名称的桥接。用户说“帮我查库存”，AI怎么走？先通过业务实体找到“物品_库存”页面，再通过页面和表的绑定关系找到对应的“物品表”，最终定位到查询接口。这条路径如果没有本体支撑，AI只能自己猜；有了本体，就是一个确定性的查找过程。 --- ## 属性：实体长什么样？每张表的列定义构成了该表实体的属性清单。每个属性包含的内容很丰富：列名（中文业务名称）、数据类型（文本、数字、日期、枚举……）、是否必填、是否唯一、默认值，以及开发者填写的备注。这里要敲黑板了：属性的质量差异会在这个环节被放大。我们用库存管理系统的物品表来看几个典型字段： - “库存”：数字类型，当前在库数量 - “库存上限”：数字类型，触发补货的上界 - “库存下限”：数字类型，触发补货的下界 - “可用库存”：数字类型，库存减去已预订数量 - “供应商ID”：关联供应商表的主键这些字段的名称已经包含了足够的业务语义。AI看到“库存下限”就能理解这是判断是否需要补货的阈值，看到“供应商ID”就知道这是指向另一个实体的外键。可是，假如这些字段叫`qty`、`max_qty`、`min_qty`、`a vail_qty`、`vnd_id`……AI就需要额外推断，而且推断还有可能出错。用数值来表示枚举值，这种做法很常见。但类型的字段在抽取本体时需要特别处理。比如一个叫“出库类型”的字段，备注里写了“1=销售出库，2=调拨出库，3=报废出库”，抽取出来的属性描述就包含了完整的取值范围和业务含义。如果备注是空的，那抽取出来就只剩字段名和数据类型——AI不知道能传什么值，只能靠瞎猜，猜对的概率完全取决于字段名有多直白。 --- ## 动作：能对实体做什么？这是本体里最直接影响AI执行能力的部分。从这一类开始，本体的抽取与技术实现方案紧密相关。以元数据驱动的活字格低代码平台为例，能抽取两类动作。 **内置动作**来自平台提供的标准数据服务。这里面最有价值的是TableBinding——活字格页面上表格控件绑定数据表时产生的查询接口。每个TableBinding实例包含：绑定的表名、可用的筛选字段、排序字段、分页参数。AI通过TableBinding查询数据不需要调用任何自定义代码，这是成本最低的数据读取方式。库存管理系统有47个页面绑定，意味着47个数据查询入口被自动抽取出来，覆盖了从物品查询到销售记录到盘点历史的各类查询需求。 **自定义动作**来自开发者创建的服务端命令。这个系统有51个服务端命令，覆盖采购、入库、出库、盘点、供应商管理等各类业务操作。每个命令的抽取内容包括：命令名称、功能描述、输入参数列表（参数名、类型、是否必填、业务含义备注）、输出参数列表。命令名称的质量在这里至关重要。51个命令里，“采购单通过”“出库审核拒绝”“新建出库单_私有”“更新预订库存”这类谓宾结构的命名，AI能从名字直接推断用途；但“执行操作_003”这种命名，AI只能依赖描述字段来理解——如果描述也是空的，那这个命令对AI来说就是一个黑盒。 --- ## 关系：实体之间怎么连接？关系是本体里信息密度最高的部分，也是最难从文档里完全恢复的部分。通常只能抽取出一部分关系，其余的得依赖LLM的自然语言理解和处理能力来自动补全。活字格工程提供了三类可以直接抽取的关系。 **表关联**是最基础的实体间关系。物品表通过“物品类目ID”字段关联物品类目表，出库单表通过“物品ID”字段关联物品表，供应商客户产品关系表同时关联供应商表和物品表。这些关联关系在工程配置里是显式存在的，抽取工具可以直接读取。有了表关联，AI在面对“查询某个供应商的所有采购记录”这类需求时，就能自动推导出需要跨采购订单表和供应商表做关联查询，而不是只查其中一张表然后发现结果不完整。 **数据绑定关系**连接业务实体（页面）和技术实体（表）。“物品_库存”页面上的“库存物品信息表格”控件绑定了物品表——这条关系告诉AI：当用户在“物品_库存”页面上操作时，背后的数据来源是物品表，查询应该走这个页面对应的TableBinding。 **服务端命令的参数关系**连接命令动作和数据实体。“创建出库单”命令的输入参数包含“物品ID”，这就建立了这个命令和物品表之间的依赖关系。AI知道：调用这个命令之前，需要先有一个有效的物品ID，而物品ID可以通过查询物品表获得。这条推导链如果没有关系信息，AI只能靠猜；有了关系信息之后，就是一个确定性的推导过程。 --- ## 策略：操作的边界条件策略是约束动作执行的规则，对应本体里的Policy层。从活字格工程里能抽取几类策略信息。最常见的是参数校验规则。服务端命令的参数可以设置必填约束、数据类型约束、取值范围约束。这些约束被抽取进本体后，AI在组装调用参数时可以提前校验——不符合约束的参数在发送给系统之前就被拦截，避免了一次无效调用。备注和描述字段是另一类策略来源。一个服务端命令的描述里写了“仅在库存低于下限时调用”，这本身就是一条执行前提条件。AI在决定是否调用这个命令时，需要先检查库存状态。这类信息无法从命令的接口定义里推断，只能来自开发者的文字描述。这也是为什么业务逻辑复杂的命令更需要写好描述——描述质量直接决定了AI能否正确判断调用时机。白名单标记是一类特殊的策略，用于控制哪些命令对AI开放。在服务端命令的描述里加入`[HOB_INCLUDE]`标记，抽取工具只输出带有这个标记的命令。这让团队可以渐进式地开放AI的操作权限：先治理一批命令、验证AI能正确使用，再开放下一批，而不是一次性把所有命令都暴露给AI。 --- ## 把这些拼在一起一个抽取完整的本体，最终呈现为一组Markdown文件。索引文件列出系统的整体概况和所有实体的目录，每个实体有独立的详情文件，每个服务端命令有独立的详情文件。AI加载这组文件，得到的是一张完整的系统地图：有什么数据、在哪里、怎么查、怎么写、操作的前提条件是什么、参数传什么值。这不是文档，是结构。文档需要AI阅读和理解，结构需要AI查找和匹配。两者对AI的认知负担不同，产生的调用准确率也不同。活字格低代码平台内置的库存管理系统、设备管理系统和葡萄城市场上的RAG知识库应用，项目的治理投入均为小时级别，主要工作集中在枚举值的备注说明。治理完成、本体生成、注册到工作台之后，主流程的调用准确率在测试中达到了可用水平。这不是说本体能解决所有问题，而是说——当工程治理达到基准线之后，自动抽取的本体已经足以让AI完成大多数常规业务操作。本文聚焦面向AI调用的应用本体，不展开权限、流程、审计等运行时治理维度，但原理类似。

业务系统本体抽取：实体到策略清单

相关阅读

最新教程

最新资讯