20260420-ontology-enterprise-ai-agent
编译摘要
1. 浓缩
- 核心结论1: 企业级 AI Agent 的根问题不是没有数据或工具，而是缺少稳定的业务语义层。
- 关键证据: 制造业订单场景中，ERP/OMS 与 APS/MES 都出现
ALLOCATED，但一个可能表示原材料锁定，另一个可能表示产能排入计划。LLM 如果按通用语言理解，会把同词误判为同义，进而错误承诺可加急发货。
- 文章把问题归纳为幻觉风险、语义不一致、上下文理解缺失、逻辑推理不足、决策难解释和 Agent 协作困难。共同根源是：系统能访问数据，却不知道这些数据在业务世界里意味着什么。
- 核心结论2: Skills、RAG 和 agentic workflow 可以止痛，但无法单独承担企业语义治理。
- 关键证据: Skills 和 RAG 能提供流程说明、状态解释和知识片段，但本质仍是提示与上下文，不是可执行约束；当上下文长、规则多、技能碎片化时，Agent 仍可能理解错。
- Workflow 通过固定步骤降低自由发挥，但关键节点仍可能要求 LLM 判断业务规则。若把所有规则硬编码进流程，系统会陷入规则爆炸，正确但难以维护。
- 核心结论3: 本体的定位是企业 AI 的语义层，把"什么是什么、如何关联、什么条件成立"结构化表达出来。
- 关键证据: 最小订单本体包含 Order、InventoryAllocation、Shipment 等概念，hasAllocation、dependsOn、fulfills 等关系，以及"有库存占用才可发货"这样的约束。Agent 可以基于本体和事实推理，而不是凭通用语言猜测。
- 本体带来的收益包括统一概念与关系、支撑多跳推理、提升可解释性、让规则变更集中在语义层，而非散落在 prompt、流程和代码里。
- 核心结论4: 文章用六块积木解释本体工程：类、实例、关系、属性、约束/公理、推理。
- 关键证据: 类表示稳定业务对象类型，实例表示具体事实，关系连接对象，属性记录数量、时间、等级、状态等数据，约束/公理表达业务规则，推理则基于事实与规则得出新结论。
- 文章还区分本体与知识图谱：本体偏稳定语义和规则，知识图谱偏事实数据集合。前者是"语义与规则"，后者是"事实与数据"。
2. 质疑
- 关于"终极王牌"表述的质疑: 本体是强语义基础设施，但不是所有企业 Agent 都需要本体。规则少、流程稳定、风险低的场景，Skills、RAG、工作流和普通代码可能已经足够。
- 关于形式化前提的质疑: 本体假设关键业务概念和规则可以被显性化、结构化，但很多企业规则是隐性的、经验性的、政治性的或例外密集的。建模过程本身就是组织治理问题。
- 关于数据质量的质疑: 本体只能根据输入事实推理。如果 ERP、MES、CRM 等系统里的事实不准、不同步或缺关键字段，本体会给出形式上正确但业务上错误的结论。
- 关于维护成本的质疑: 文章批评 prompt、Skills 和 workflow 的维护成本，但本体也需要版本治理、概念变更评审、规则测试、推理性能监控和业务专家参与。它是把维护集中化，不是让维护消失。
3. 对标
- 与类型系统对标: 本体像企业业务的类型系统，防止 Agent 把同名不同义的状态混用，并让某些判断从自由生成变成受约束的分类。
- 与领域驱动设计对标: 本体和 bounded context、ubiquitous language 有相似目标，都是让业务语言、系统模型和执行逻辑对齐。差别在于本体更强调机器可读、推理和形式化约束。
- 与规则引擎对标: 本体不是把规则写成一堆脚本，而是先定义业务概念及其关系，再用推理判断事实属于哪个概念。优势是统一口径，代价是建模门槛更高。
- 与 LLM Wiki 对标: 两者都把非结构化知识转成可维护语义层。LLM Wiki 面向研究知识复利，本体面向企业执行与业务规则约束。
关联概念