本文通过“地块A发现稻飞虱”案例，清晰区分对象类型与实例、阈值与规则、行动与执行，揭示本体定义业务世界、规则解释条件、工作流执行业务动作的核心逻辑，为AI数据管理提供可落地的建模思路。

本文基于华为出品的《本体驱动的AI数据管理》，在阅读过程中对于经常出现的“智慧农业”案例做了本体的理解和拆解，并做了如下的案例本体构建，如有兴趣，大家可以一起学习交流

1. 本文要解决什么问题

以“地块 A 发现稻飞虱虫口密度超标，系统建议并执行防治”为例，说明以下概念各自是什么、放在哪里、怎样共同运行：

• 本体中的对象类型、属性和关系
• 运行时的事实数据
• 阈值和业务规则
• 行动类型、工单与无人机任务
• 规则引擎、工作流、调度系统和 AI Agent

最重要的结论是：本体定义业务世界；规则解释业务条件；工作流执行业务动作。 本体可以记录规则和行动的业务定义，但不会自行接收传感器数据、计算比较结果或让无人机起飞。

2. 先区分五种东西

不要把“对象类型”和“对象实例”混在一起：

对象类型：地块、作物、害虫、无人机任务

对象实例：地块 A、水稻、稻飞虱、无人机任务 D-001

3. 本体中的对象类型

3.1 核心业务对象

地块

作物

害虫

生育期

监测记录

防控阈值

风险判定

防控方案

防治工单

无人机

无人机任务

对象类型首先是业务世界中的独立实体，不是数据库表名。例如，“无人机任务”有独立编号、状态、责任和执行过程，且能够关联工单、设备、地块和结果，所以它是独立业务对象。

3.2 对象类型之间的关系

下列是关系类型定义。它们规定哪些类型可以建立什么关系；不是某次实际发生的数据。

地块 –种植–> 作物

监测记录 –发生于–> 地块

监测记录 –监测对象–> 害虫

防控阈值 –适用于–> 作物

防控阈值 –适用于–> 害虫

防控阈值 –适用于–> 生育期

风险判定 –依据–> 监测记录

风险判定 –引用–> 防控阈值

防治工单 –针对–> 地块

防治工单 –针对–> 害虫

防治工单 –采用–> 防控方案

防治工单 –依据–> 风险判定

无人机任务 –执行来源–> 防治工单

无人机任务 –作业对象–> 地块

无人机任务 –使用设备–> 无人机

无人机任务 –使用方案–> 防控方案

运行时才会产生具体关系：

地块 A –种植–> 水稻

记录 M-102 –发生于–> 地块 A

记录 M-102 –监测对象–> 稻飞虱

任务 D-001 –执行来源–> 工单 W-001

任务 D-001 –使用设备–> 无人机 U-01

3.3 对象类型不等于单独建表

不要用“是否单独存储”判断是否是本体对象。数据库表是技术实现；本体对象是业务语义。 例如，无人机每秒产生一个定位点。为了存储和查询性能，系统很可能单独建立 position_points 表；但这些定位点通常只是无人机任务的技术明细，并不是需要独立管理的业务对象。 反过来，“无人机任务”即使它的数据来自工单系统、调度系统和设备 API 的多个表或接口，仍然是一个本体对象，因为业务人员会独立地查询、审批、取消和追溯一项任务。 判断一项东西是否应成为对象，问的是：

它是否需要独立编号？

它是否有自己的状态变化、责任人或审批？

它是否需要被其他业务对象独立引用？

业务人员是否需要单独查询、解释或管理它？

多数回答为“是”，才适合建成对象；否则优先作为某个对象的属性、附件或技术明细。

3.4 关系图

4. 事实：系统如何知道“地块 A 超标”

本体不是传感器，也不是识别模型。它不直接产生“48 头/百丛”这个数值。事实来自传感器、人工巡田、诱捕器、无人机影像或 AI 视觉识别模型。 例如，数据接入后可生成一条监测记录：

监测记录 M-102

– 发生地块：地块 A

– 监测对象：稻飞虱

– 指标：虫口密度

– 数值：48

– 单位：头/百丛

– 采样时间：2026-08-03 09:20

– 来源：人工调查 / 图像识别模型

– 可信度：0.92

同时，系统还会查询或接入其他事实：

地块 A 当前生育期：抽穗期

未来 24 小时降雨概率：10%

未来作业窗口平均风速：4 m/s

无人机 U-01 状态：可用

这些事实按本体定义的类型和关系存储，才可以被统一查询和组合使用。

5. 阈值到底是什么

阈值既不是监测事实，也不是行动。它是“规范知识”或“政策参数”：由技术规程、植保专家、当地政策或企业策略确定，并且应当有来源、版本和生效时间。 建议在本体中建模为 防控阈值 对象：

防控阈值 T-01

– 害虫：稻飞虱

– 作物：水稻

– 生育期：抽穗期

– 指标：虫口密度

– 比较符：>=

– 阈值数值：40

– 单位：头/百丛

– 来源：当地植保技术规程

– 版本：2026.1

– 生效期：2026-01-01 至 2026-12-31

这样，系统不会将 40 写死在程序代码里。政策变化时，专家可更新阈值对象；历史判定仍能追溯当时使用的是哪个版本。

6. 规则：定义“如何判断”，不是“如何执行”

规则是条件与结论的组合。它引用本体中定义的对象、关系、属性和阈值，但通常由专门的规则引擎、DMN 决策表或业务代码来执行。

6.1 检测规则

规则 R-01：稻飞虱超阈判定

如果：

监测记录的害虫 = 稻飞虱

且 地块种植作物 = 水稻

且 地块当前生育期 = 抽穗期

且 监测值 >= 当前有效且适用的防控阈值

那么：

创建风险判定，风险等级 = 高

并记录依据的监测记录和阈值版本

将 M-102 的 48 头/百丛 与 T-01 的 40 头/百丛 代入后，规则引擎得出：48 >= 40，生成“地块 A 稻飞虱高风险”的判定。

6.2 决策规则

规则 R-02：推荐防控方案

如果：

风险等级 = 高

且 处于抽穗期

且 未触发药剂禁限用约束

那么：

推荐方案 = 生物防治方案 S-01

建议动作 = 创建防治工单

6.3 执行准入规则

规则 R-03：无人机作业准入

如果：

工单已审批

且 无人机状态 = 可用

且 风速 <= 允许上限

且 降雨条件满足要求

且 作业区域允许飞行

那么：

允许下发无人机任务

将这三类规则分开很重要：发现风险，不等于直接飞防；推荐方案，也不等于有权限立即执行。

7. 行动：定义“能做什么”，不是一次实际发生的执行

行动类型可视为本体中的一种业务能力定义。它描述动作名称、输入、前置条件、产出、责任人和外部影响。

7.1 行动类型 A-01：创建防治工单

输入：地块、害虫、风险判定、推荐方案、作业窗口

前置条件：存在有效的高风险判定

输出：一张待审批防治工单

责任人：农技员或自动化工作流

外部影响：无，仅创建业务记录和通知

7.2 行动类型 A-02：下发无人机任务

输入：已审批工单、无人机、航线、作业窗口

前置条件：满足无人机作业准入规则

输出：一条无人机任务

责任人：调度系统

外部影响：调用无人机调度平台 API

行动类型是定义；一次实际执行是行动实例：

工单 W-001：A-01 的执行结果

无人机任务 D-001：A-02 的执行结果

作业轨迹、作业面积、实际用量、完成时间和效果记录，在初版系统中都可以先作为“无人机任务”的属性、附件或外部数据链接，不必另建本体对象。

8. 为什么还需要各类引擎

本体是声明式知识，描述“是什么”和“应满足什么约束”；而执行真实世界动作属于命令式行为，需要身份权限、审批、消息重试、失败补偿、设备协议、审计与安全控制。

因此，“规则和行动在引擎中”这句话不准确。正确说法是：

本体中保存规则和行动的业务定义及其语义关联；引擎负责解释这些定义，并将其作用于实时事实或外部系统。

9. 一次完整运行示例

1. 诱捕器/人工调查/图像识别产生监测记录 M-102：

地块 A 的稻飞虱密度为 48 头/百丛。

2. 系统从知识层查到：

地块 A 种植水稻，处于抽穗期；

阈值 T-01 要求抽穗期稻飞虱密度 >= 40 时启动防控。

3. 规则 R-01 得到结论：

创建风险判定 D-001，等级为高；记录依据 M-102 和 T-01。

4. 规则 R-02 得到结论：

推荐生物防治方案 S-01；建议执行 A-01“创建防治工单”。

5. 工作流实例化 A-01：

创建工单 W-001，交农技员审批。

6. 农技员审批通过后，调度系统检查 R-03：

风速合格、无降雨、U-01 可用、作业区允许飞行。

7. 工作流实例化 A-02：

创建并下发无人机任务 D-001。

8. 无人机完成作业后回传：

实际轨迹、实际用量、覆盖面积、完成状态和异常信息，写入或关联至 D-001。

9. 这些作业完成后的数据继续与后续监测数据关联：

用于评价防治效果、复盘规则和更新方案。

一句话总结

本体：把农业对象、关系、规则定义和行动定义说清楚。

实时数据：告诉系统地块 A 此刻真实发生了什么。

规则引擎：依据事实和知识得出风险与建议。

工作流与调度：将已授权的建议变成工单和无人机任务。

执行结果：再回写为新的事实，形成可追溯闭环。