09 简化 Ontology 与业务对象建模
章节目标
用轻量方式识别业务对象、属性、关系、动作和权限，让 Agent 和 Workflow 理解业务世界，而不是只处理散乱文本。
为什么重要
企业流程不是一堆文档，而是由订单、客户、合同、设备、物料、工单、供应商、发票和报表等对象构成。FDE 不需要一开始建设重型 Ontology 平台，但需要把业务对象建清楚。
开篇案例：为什么 Agent 会“听懂话但办错事”
一个供应链 Agent 能理解“帮我看这个客户订单有没有风险”，也能调用库存和物流工具。但它经常给出不稳定建议：有时把客户订单和采购订单混在一起，有时不知道“在途库存”是否能覆盖承诺交期，有时把供应商历史延误当成当前延误。
问题不在模型语言能力，而在业务世界没有被建模。Agent 不知道订单、物料、供应商、风险事件之间的关系，也不知道哪些动作只是查询，哪些动作意味着承诺客户。
轻量 Ontology 的目标不是建一个庞大平台，而是在 PoC 阶段把关键业务对象、属性、关系、动作和权限写清楚，让系统输出更稳定、更可审计。
五类建模元素
业务对象
订单、客户、合同、设备、物料、工单、供应商、发票、报表。
对象属性
金额、交期、状态、责任人、风险等级、更新时间、密级、版本。
对象关系
客户拥有订单，物料影响生产，工单关联设备，合同关联付款，供应商影响交期。
对象动作
查询、生成、审批、通知、创建工单、更新状态、冻结、归档。
权限边界
谁能看哪个对象，谁能执行哪个动作，哪些字段需要脱敏，哪些动作必须审批。
建模示例：供应链风险
| 对象 | 属性 | 关系 | 动作 |
|---|---|---|---|
| 订单 | 金额、交期、客户、状态 | 关联物料和客户 | 查询、标记风险 |
| 物料 | 库存、齐套率、替代料 | 影响订单交付 | 查询、计算缺口 |
| 供应商 | 交期、评级、历史延误 | 供应物料 | 查询、生成建议 |
| 风险事件 | 等级、原因、责任人 | 关联订单 | 创建、审批、关闭 |
建模输出模板
## 业务对象：订单
- 核心属性：订单号、客户、SKU、数量、承诺交期、状态、金额。
- 关联对象：客户、物料、库存、物流单、风险事件。
- 可查询动作：查状态、查交付风险、查关联物料。
- 可建议动作：生成风险解释、生成客户沟通摘要。
- 禁止自动执行：修改承诺交期、取消订单、对外承诺赔偿。
- 权限边界：销售看自己客户，计划看交付字段，财务字段脱敏。
从数据表到业务对象
很多企业已有数据库表，但表结构不等于业务对象模型。FDE 要补上三类信息：
| 数据表里常有 | 业务对象模型要补 |
|---|---|
| 字段名 | 字段业务含义和口径 |
| 外键关系 | 真实流程中的责任关系 |
| 状态枚举 | 哪些状态允许什么动作 |
| 权限表 | 谁能看、谁能改、谁能审批 |
这一步做得越清楚，后面的工具 Schema、Prompt、评估样本和审计日志就越稳定。
实操任务
选择一个场景，列出：
- 5 个业务对象。
- 每个对象 5 个关键属性。
- 关键对象关系。
- 可执行动作。
- 权限和审批边界。
交付物
- 简化业务对象模型。
- 对象动作权限表。
- Agent 可用的业务词汇表。
常见误区
- 只做数据表映射，不理解业务动作。
- 权限只按用户角色，不按对象和动作。
- 把所有字段都交给模型。
- 过早建设重型平台，拖慢 PoC。
检查清单
- 是否明确业务对象和动作？
- 是否知道对象之间的关系？
- 是否能把权限绑定到对象和动作？
- 是否能让 Agent 输出符合业务对象结构的结果？