导读企业的数据平台可以计算指标规则引擎可以识别异常大模型可以生成文字说明。但如果这些能力彼此分离用户仍然需要自己判断异常对应哪个业务对象、依据是什么、该由谁处理。业务本体与Agent的协作可以把数据、指标、规则和对象关系组织为可解释的经营事项。本文以库存风险为例拆解一条从数据更新到待办生成的实现链路。1. 先定义要解决的业务目标不要从“建设一个Agent”开始而应先明确它服务什么目标。以库存管理为例目标可以定义为降低高库存占用同时减少关键物料缺货风险围绕该目标系统需要识别哪些物料或商品需要关注当前可用库存是多少哪些产品、订单或生产任务会消耗库存近期消耗速度和补货周期如何什么条件代表库存偏高或存在缺货风险判断成立后应由哪个角色进一步处理。只有目标和对象明确后后续语义建模和Agent设计才有清晰边界。2. 本体如何组织业务语义本体可以将库存场景中的对象和关系表达为商品 --由-- 物料组成 订单 --需求-- 商品 物料 --存在于-- 仓库 物料 --具有-- 可用库存 物料 --适用-- 安全库存规则 缺货风险 --关联-- 补货动作 高库存 --关联-- 调拨或减采动作这里的关系不仅用于展示还要连接具体指标和数据来源。例如“可用库存”可能由现存量扣除锁定量得到“缺货风险”可能同时考虑预测需求和补货周期。本体负责告诉系统应该沿哪些业务关系寻找信息指标和规则负责计算当前状态。3. 从原始数据到运行结果一条经营待办的产生可以抽象为以下流水线业务数据更新 ↓ 指标计算 ↓ 规则判断 ↓ 生成带有对象和证据的运行结果 ↓ Agent读取并组织为待办规则输出不应只有一个布尔值。为了支持解释和追踪可以采用类似结构{ subject: material_10086, riskType: shortage_risk, status: active, metrics: { availableStock: 120, expectedDemand: 180, leadTimeDays: 7 }, ruleVersion: stock-rule-v3, evaluatedAt: 2026-10-08T09:00:0008:00 }示例数值仅用于说明结构。真实系统还需要附加数据来源、权限标签和质量状态。4. Agent如何把运行结果变成待办Agent不应重新判断业务规则而应在已形成的运行结果基础上组织信息。一条待办至少包含对象具体物料、商品、客户或订单问题当前识别到的风险或异常依据关键指标、规则和数据时间建议企业已经定义的候选处理方式责任角色谁需要确认或办理状态待确认、处理中、已完成或已关闭。面向不同角色Agent可以调整表达。管理者更关心风险影响和优先级业务人员需要明细和处理入口数据人员则需要查看计算和数据质量信息。Agent负责组织和传递不应在缺少依据时自行补出一个原因。5. 用户追问时解释链从哪里来用户收到“某物料存在缺货风险”后可能继续询问现在还有库存为什么已经出现风险Agent可以沿本体关系查询当前可用库存未来订单或生产任务相关商品对该物料的消耗关系近期消耗或预测需求补货周期命中的规则及其版本。返回结果应区分数据事实和解释。例如“库存为120”是事实“按照未来需求和补货周期判断可能不足”是规则结果。如果某项数据延迟Agent应直接提示限制而不是用其他信息填补空缺。6. 本体、Agent和业务系统的职责边界可以用下表概括三者的分工组件主要职责数据与指标系统提供当前事实并计算指标业务本体组织对象、关系、规则和动作语义Agent读取结果、生成说明、支持追问和任务编排业务流程系统负责审批、执行、状态更新和异常恢复业务人员确认重要判断并承担决策责任如果让Agent直接依据自然语言猜测规则结果会缺乏稳定性如果只建设本体而不连接运行数据也无法生成当前待办。7. 权限和时效必须贯穿整个链路Agent能看到什么不能只由最终界面决定。数据查询、指标结果、关系展开和待办分发都需要继承用户权限。同时每条结论应保留数据时间。库存和订单变化较快昨天正确的提醒今天可能已经失效。Agent读取待办前可以重新检查状态避免把已经解除的问题继续推送。可解释不仅是说明计算逻辑还要说明使用了哪一时点的数据和哪一版本的规则。8. 如何验证这套协作是否有效验收时不要只看Agent生成的文字是否通顺还应检查是否定位到正确业务对象是否引用正确指标和规则版本是否能够回溯数据来源信息缺失时是否停止推断是否发送给正确角色追问后是否保持同一业务上下文风险解除后是否能结束或更新待办。小结业务本体与Agent的组合不是让模型替代指标平台或规则引擎而是让企业已经拥有的数据、规则和关系能够被持续调用。本体提供结构化业务语境Agent提供面向人的交互与任务组织。当一条异常能够找到对象、说明依据、送达责任人并支持后续追问时数据分析才真正进入日常经营流程。
