方法论 · 本体
AI 需要的不是更多文档，而是一个业务世界模型。
本体（Ontology）把企业里真实存在的东西——客户、订单、物料、设备——以及它们之间的关系和可以发生的动作，组织成一个 AI 能精确查询、能安全执行的模型。它是大模型与企业生产系统之间缺失的那一层。
什么是本体
三种定义，描述整个企业。
本体不是一份文档，也不是一张图。它是一个带类型、带规则、可执行的业务模型，数据从业务系统持续同步进来，人和 Agent 通过同一个接口使用它。
订单 SO-8812
- 状态已确认
- 金额¥186,400
- 交期11-06
同一个问题，四种答案
当业务问题需要事实，差别就出现了。
向四种架构问同一个真实的供应链问题。它们都能「回答」，但只有一种给出的答案可以直接拿去做决策。
RAG
相似度检索把文档切块向量化，检索与问题最相似的几段文本交给模型。
GraphRAG
推断的关系用模型从文档中抽取实体与关系构成图，再结合社区摘要回答。
LLM Wiki
3 周前更新让模型把资料整理成 Markdown 页面并自行维护，Agent 读取这些页面。
Ontoxiom 本体
实时 · 已授权沿着从 ERP 实时同步的对象关系精确遍历，每一步都经过 Governor 授权。
全面对比
它们解决的是不同的问题。
| RAG | GraphRAG | LLM Wiki | Ontoxiom 本体 | |
|---|---|---|---|---|
| 知识来源 | 文档片段 | 从文档抽取的图 | 模型整理的页面 | 业务系统 + 文档，统一建模 |
| 数据新鲜度 | 取决于重新索引 | 取决于重建图谱 | 取决于模型重写 | 按集成持续同步 |
| 精确统计与枚举 | 不能 | 有限 | 不能 | 能：查询、遍历、聚合 |
| 关系从何而来 | 没有关系 | 模型推断 | 页面间链接 | 显式声明，带基数与方向 |
| 权限粒度 | 文档级 | 文档级 | 页面级 | 对象、属性、关系、动作级 |
| 能否执行业务动作 | 不能 | 不能 | 不能 | 能：检查 → 审批 → 执行 |
| 可审计 | 检索日志 | 检索日志 | 页面修订历史 | 每次读写与决策完整留痕 |
| 最适合 | 政策、手册问答 | 文档集合的主题探索 | 个人与团队知识沉淀 | 需要事实与行动的生产业务 |
完全支持部分支持不支持
为什么重要
进入生产的 AI，需要四件文档给不了的东西。
精确
「本月下降超过 20% 的客户有哪些」需要的是查询与聚合，不是相似度检索。本体给出可枚举、可核对的答案。
实时
订单状态每分钟都在变。本体由数据管道从业务系统持续同步，模型读到的是今天的事实，而不是上次整理的摘要。
可行动
从「回答问题」到「推进流程」，需要定义好的动作、前置条件与审批。只有本体能把行动和事实放在同一个模型里。
可治理
薪资字段谁能看、哪个动作需要审批，权限必须落在对象与属性上。文档级权限对企业来说太粗了。
不是替代 RAG，而是给它一个事实底座。
文档检索在制度、手册与经验问答上依然有用。在 Ontoxiom 中，Agent 可以同时使用文档与本体：解释性的内容来自文档，事实与行动以本体为准——并且两者都受同一套权限约束。
常见问题
关于本体的常见问题
LLM Wiki 让模型把资料整理成 Markdown 页面并自行维护，Agent 阅读这些页面来回答问题。它非常适合沉淀个人或团队的经验与说明。
但 Wiki 是模型写的摘要：它可能已经过时，不能精确统计或枚举，没有字段级权限，也不能执行业务动作。Harness 里的 Agent 面对的是从业务系统持续同步的类型化对象，答案可以精确到每一张订单；每一次读写都经过 Governor，动作需要检查与审批，并完整留痕。
两者可以共存：Wiki 适合承载「怎么做」，本体负责「是什么」和「去做」。