本文通过“地块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 关系图本体不是传感器，也不是识别模型。它不直接产生“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 此刻真实发生了什么。
规则引擎：依据事实和知识得出风险与建议。
工作流与调度：将已授权的建议变成工单和无人机任务。
执行结果：再回写为新的事实，形成可追溯闭环。
本文由 @大葱小白 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
大牛配资提示：文章来自网络，不代表本站观点。
相关文章
沪深京行情 实时轮播
热点资讯
