企业官网建设流程全解析

导读

企业的数据平台可以计算指标，规则引擎可以识别异常，大模型可以生成文字说明。但如果这些能力彼此分离，用户仍然需要自己判断：异常对应哪个业务对象、依据是什么、该由谁处理。

业务本体与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:00+08:00" }

示例数值仅用于说明结构。真实系统还需要附加数据来源、权限标签和质量状态。

4. Agent如何把运行结果变成待办

Agent不应重新判断业务规则，而应在已形成的运行结果基础上组织信息。

一条待办至少包含：

• 对象：具体物料、商品、客户或订单；
• 问题：当前识别到的风险或异常；
• 依据：关键指标、规则和数据时间；
• 建议：企业已经定义的候选处理方式；
• 责任角色：谁需要确认或办理；
• 状态：待确认、处理中、已完成或已关闭。

面向不同角色，Agent可以调整表达。管理者更关心风险影响和优先级，业务人员需要明细和处理入口，数据人员则需要查看计算和数据质量信息。

Agent负责组织和传递，不应在缺少依据时自行补出一个原因。

5. 用户追问时，解释链从哪里来

用户收到“某物料存在缺货风险”后，可能继续询问：

现在还有库存，为什么已经出现风险？

Agent可以沿本体关系查询：

1. 当前可用库存；
2. 未来订单或生产任务；
3. 相关商品对该物料的消耗关系；
4. 近期消耗或预测需求；
5. 补货周期；
6. 命中的规则及其版本。

返回结果应区分数据事实和解释。例如：“库存为120”是事实，“按照未来需求和补货周期判断可能不足”是规则结果。

如果某项数据延迟，Agent应直接提示限制，而不是用其他信息填补空缺。

6. 本体、Agent和业务系统的职责边界

可以用下表概括三者的分工：

如果让Agent直接依据自然语言猜测规则，结果会缺乏稳定性；如果只建设本体而不连接运行数据，也无法生成当前待办。

7. 权限和时效必须贯穿整个链路

Agent能看到什么，不能只由最终界面决定。数据查询、指标结果、关系展开和待办分发都需要继承用户权限。

同时，每条结论应保留数据时间。库存和订单变化较快，昨天正确的提醒今天可能已经失效。Agent读取待办前，可以重新检查状态，避免把已经解除的问题继续推送。

可解释不仅是说明计算逻辑，还要说明使用了哪一时点的数据和哪一版本的规则。

8. 如何验证这套协作是否有效

验收时不要只看Agent生成的文字是否通顺，还应检查：

• 是否定位到正确业务对象；
• 是否引用正确指标和规则版本；
• 是否能够回溯数据来源；
• 信息缺失时是否停止推断；
• 是否发送给正确角色；
• 追问后是否保持同一业务上下文；
• 风险解除后是否能结束或更新待办。

小结

业务本体与Agent的组合，不是让模型替代指标平台或规则引擎，而是让企业已经拥有的数据、规则和关系能够被持续调用。

本体提供结构化业务语境，Agent提供面向人的交互与任务组织。当一条异常能够找到对象、说明依据、送达责任人并支持后续追问时，数据分析才真正进入日常经营流程。