从异常识别到闭环执行：用业务本体连接规则、Agent与工作流

导读

很多数据项目已经能够发现异常，却仍然停留在看板和消息提醒阶段。用户看到库存偏高、交付延期或设备风险后，还要在线下判断应该做什么、找谁处理，以及问题是否真正解决。

要形成决策闭环，需要把业务对象、判断规则、候选动作、执行流程和结果复查连接起来。本文给出一套适合企业场景的职责划分和实现思路。

1. 为什么"发现问题"不等于"解决问题"

以库存风险为例，系统发现某项物料低于安全库存，只完成了问题识别。后续还需要判断：

是否存在在途库存；
哪些订单或生产任务会受到影响；
可以补货、调拨还是使用替代物料；
谁可以确认处理方案；
采购、调拨或生产调整是否已经执行；
执行后缺货风险是否真正解除。

如果这些环节没有统一对象和状态，提醒、工单和业务结果就会分散在不同系统中，无法形成连续跟踪。

2. 用本体连接"问题---依据---动作"

业务本体可以表达问题与处理方式之间的语义关系：

复制代码

物料A --出现--> 缺货风险
缺货风险 --依据--> 可用库存、未来需求、补货周期
缺货风险 --候选动作--> 补货、调拨、替代
补货动作 --需要--> 采购确认
调拨动作 --需要--> 库存与物流校验

这里的"候选动作"并不代表自动执行。它只是说明在当前业务语境下有哪些可选路径，以及每条路径需要满足什么条件。

本体负责表达关系，规则负责形成判断，工作流负责执行，人员负责重要确认。

3. 将判断结果转换为决策任务

规则命中后，可以创建一个结构化决策任务：

复制代码

{
  "taskType": "inventory_risk_handling",
  "subject": "material_10086",
  "finding": "shortage_risk",
  "evidence": [
    "available_stock_metric",
    "demand_forecast_metric",
    "lead_time_rule"
  ],
  "candidateActions": [
    "replenish",
    "transfer",
    "use_substitute"
  ],
  "status": "pending_confirmation"
}

Agent可以根据任务内容生成摘要，说明风险、依据和可选动作，并把任务发送给相应角色。

与直接生成一段自然语言相比，结构化任务更容易进行权限校验、状态追踪和系统集成。

4. 建议、授权和执行必须分开

Agent可以推荐动作，但能否执行取决于影响程度和企业制度。

4.1 低风险、可撤回动作

例如创建草稿、补充待办说明或发送内部提醒，可以在规则允许范围内自动完成。

4.2 中等影响动作

例如生成采购申请或调拨建议，可以由Agent填写必要信息，再交由负责人确认。

4.3 高影响或不可逆动作

涉及资金支出、客户承诺、订单状态和关键生产安排时，应通过正式审批和权限校验。

技术上能够调用接口，不代表业务上已经获得授权。把三个环节分开，能够明确Agent做了什么、人员确认了什么、系统最终执行了什么。

5. 办理完成不等于问题已经解决

企业经常把"工单关闭"当成闭环完成，但流程状态和经营状态是两件事。

例如：

复制代码

采购单已提交        → 办理状态发生变化
物料已经到货入库    → 业务数据发生变化
缺货风险已经解除    → 经营状态发生变化

因此，系统应同时跟踪：

办理状态：待确认、已审批、执行中、已完成；
经营状态：风险持续、风险降低、风险解除或产生新异常。

Agent可以持续读取两类状态。如果任务已经完成但指标没有改善，应继续保留关注，而不是自动关闭问题。

6. 新数据如何触发下一轮判断

一次行动会改变业务数据。补货入库后，库存增加；调整交期后，订单计划发生变化；设备检修后，运行状态被更新。

新的数据进入指标和规则计算后，可以重新评估原问题：

复制代码

数据更新
  → 指标重新计算
  → 规则重新判断
  → 更新经营状态
  → Agent同步任务进展

已经改善的事项可以结束本轮跟进，未改善的事项继续保留，新出现的问题则进入下一轮处理。

这形成了"数据---判断---行动---新数据---再判断"的循环。

7. 版本和证据如何支持复盘

决策闭环不仅要记录最终结果，还应保留当时使用的：

数据快照或数据时间；
指标定义；
规则版本；
Agent生成的建议；
人工确认内容；
实际执行记录；
执行后的指标变化。

如果规则后来调整，系统仍需要使用旧版本解释历史决策。否则，当前规则可能无法还原当时为何产生某项提醒或建议。

8. 异常场景必须提前设计

完整闭环还需要考虑：

接口调用失败后是否重试；
同一任务重复触发时如何避免重复下单；
部分步骤成功、部分失败时如何恢复；
数据延迟时是否暂停执行；
人员拒绝建议后如何记录原因；
业务条件变化后如何取消未完成任务。

这些处理应由工作流和业务系统承担。Agent可以识别状态并组织说明，但不能依靠自然语言生成代替确定性的事务控制。

9. 从一个目标清晰的场景开始

企业可以选择高库存、订单延期或设备异常等场景进行最小闭环验证：

确定业务目标与评价指标；
建立对象、指标、规则和动作关系；
生成带证据的结构化决策任务；
按影响等级设置确认和执行方式；
跟踪办理状态与经营状态；
使用新数据重新验证结果；
复盘判断、建议和执行效果。

小结

从异常识别到闭环执行，不能只依靠一个能够调用工具的Agent。企业需要本体提供业务语义，指标和规则提供判断依据，Agent负责任务组织与交互，工作流负责确定性执行，人员负责关键决策。

真正的闭环不是"动作已经完成"，而是"原问题经过行动后得到重新验证"。当每个环节都能回到同一业务对象、规则和证据上，数据洞察才能持续转化为可执行、可复盘的经营行动。