第一部分 从 RAG 到 OAG：为什么企业 Agent 需要新的知识增强方式

重点回答三个问题：

为什么 RAG 已成为企业 AI 的基础能力；

为什么仅有 RAG 仍不足以支撑企业级 Agent；

OAG（Ontology Augmented Generation）为什么会成为下一阶段企业知识工程的重要方向。

这一部分首先介绍 RAG 的价值。RAG（Retrieval-Augmented Generation）通过将外部知识库与大语言模型结合，有效缓解了模型知识过时、幻觉（Hallucination）和领域知识不足等问题，因此成为当前企业知识问答、Copilot 和 AI Agent 的主流技术路线。大量研究表明，RAG 能够显著提升知识密集型任务的回答准确率和可追溯性，因此已成为企业部署生成式 AI 的事实标准。

但随着 Agent 从"回答问题"走向"执行业务"，RAG 的局限也逐渐显现。传统 RAG 更关注"找到相关内容"，却无法理解这些内容之间的业务关系。例如，在金融行业，RAG 可以检索授信政策文档，却不知道客户属于哪种授信类型；在制造业，RAG 可以找到设备手册，却无法理解设备之间的依赖关系；在 CRM 场景中，RAG 可以返回客户资料，却不知道客户当前所处的销售阶段。这意味着，RAG 能找到知识，却未必能理解业务。

因此，越来越多企业开始探索在 RAG 之上引入企业本体（Ontology）作为统一语义层。微软在 Fabric IQ 中提出，企业应通过 Ontology 建立统一的业务语义模型，将业务实体、关系、规则和上下文绑定到真实数据之上，使 AI Agent 在生成答案时不仅检索知识，还能够理解企业业务。Fabric IQ 将 Ontology 定义为企业共享的 Business Context Layer（业务上下文层），为 AI Agent 提供一致的业务语言、上下文和推理基础。

因此，OAG（Ontology Augmented Generation）可以理解为 RAG 的一次企业级升级：RAG 负责"找到知识"，Ontology 负责"理解知识"，两者共同让 Agent 从"会说话"升级为"懂业务"。

图一：RAG → OAG 的能力演进

第二部分 OAG 的核心机制：让知识按照企业业务逻辑组织，而不是按照文档组织

RAG 解决的是"知识从哪里来"的问题，而 OAG（Ontology Augmented Generation）进一步解决的是"知识如何被理解和组织"的问题。两者最大的区别，并不在于是否进行了知识检索，而在于检索之后是否拥有一套统一的业务语义来组织这些知识。 在传统 RAG 中，大模型通常依据向量相似度或关键词召回相关文档，再结合 Prompt 完成回答；而在 OAG 中，模型获得的不仅是一组文档片段，还包括这些知识所属的业务实体、实体之间的关系、业务规则以及当前业务上下文。

因此，OAG 可以理解为 RAG + Enterprise Ontology（企业本体），即在检索增强的基础上，再增加一层业务语义增强，使 Agent 不只是"引用知识"，而是真正"理解知识"。微软在 Fabric IQ 中提出，Ontology 的核心价值就在于为 AI Agent 提供统一的 Business Context Layer（业务上下文层），使所有知识、数据和业务规则都围绕同一套企业语义组织，从而支撑更准确、更一致、更可治理的智能推理。 

从工程流程来看，传统 RAG 的执行链路通常是"用户问题 → 向量检索 → 文档召回 → Prompt 拼接 → LLM 回答"。整个过程中，模型更多依赖文档内容本身进行推理，如果不同文档之间存在概念冲突、规则差异或业务上下文缺失，模型只能依靠概率进行判断，因此容易产生回答不一致、逻辑跳跃甚至业务错误。而 OAG 在检索之后增加了一个Ontology Grounding（本体语义锚定）过程。

系统首先识别当前任务涉及哪些业务实体（如客户、订单、合同、产品），再依据企业本体自动扩展相关关系、业务规则和上下文信息，最后才将经过语义组织后的知识输入大模型生成答案。这意味着，大模型面对的不再是一组零散文本，而是一个经过企业业务逻辑重构的知识上下文。

例如，微软 Fabric IQ 支持从现有语义模型和业务数据中构建 Ontology，将实体、关系、规则和可执行动作统一纳入语义层，使 Agent 能够围绕企业业务对象进行推理，而不是围绕数据表和文档进行检索。 

企业本体在 OAG 中主要承担三项关键职责。

第一，是提供统一的回答结构（Semantic Structure）。 传统 RAG 每次回答都可能根据检索结果自由组织内容，而 OAG 会按照企业本体定义的业务实体和关系组织答案。例如回答"某客户为什么不能享受当前促销政策"时，Agent 会自动围绕客户等级、合同类型、活动规则、历史订单等业务对象进行解释，而不是简单摘录促销文档。这样不仅提升了回答的一致性，也使回答更加符合企业业务逻辑。

第二，是提供业务规则校验（Business Rule Validation）。 企业本体能够定义审批权限、授信额度、折扣政策、合规约束等规则，在生成答案之前自动检查是否违反企业制度。例如金融授信说明不能突破风险控制规则，合同解释不能与最新版本条款冲突，价格建议不能超出授权范围，使生成结果具备可治理能力。微软 Fabric IQ 明确提出，业务规则与约束应作为 Ontology 的组成部分，使 AI Agent 能够在推理过程中遵循企业定义的规则，而不仅依赖模型自身判断。

第三，也是 OAG 最重要的能力，是提供持续的业务上下文导航（Business Context Navigation）。 企业中的业务任务通常不是一次性的问答，而是围绕某个业务对象持续推进。例如销售 Agent 正在处理一个重点客户，客服 Agent 正在跟进同一客户的售后问题，合同 Agent 又在审核该客户的新合同。

如果没有统一上下文，不同 Agent 很容易形成彼此割裂的理解。而 OAG 会根据企业本体持续维护"当前处理的是哪个客户、处于哪个业务流程、关联哪些订单、涉及哪些审批规则"，使多个 Agent 在同一个业务语义空间中协同工作。

这也是微软提出 Enterprise Intelligence Layer 的原因——所有 Agent 都共享统一业务上下文，而不是各自维护独立记忆，从而实现跨系统、跨部门的一致决策。

近年来，学术界对于 Ontology 与 RAG 融合的研究也进一步验证了这一方向。2024 年提出的 OG-RAG（Ontology-Grounded Retrieval-Augmented Generation） 表明，通过本体组织检索内容，可以显著提升复杂领域问答中的事实一致性、业务推理能力和可解释性，尤其适用于医疗、法律、金融、工业等规则密集型场景。研究显示，相较传统 RAG，基于 Ontology 的知识组织能够提高事实召回率、回答正确率以及推理链完整性，同时使生成结果更容易追溯到具体业务知识来源。 

因此，OAG 的真正价值，并不是替代 RAG，而是让 RAG 从"知识检索引擎"升级为"业务推理引擎"。 RAG 负责把知识带到模型面前，而企业本体决定模型如何理解这些知识、如何组织这些知识以及如何依据企业规则生成最终答案。当知识开始围绕业务对象组织，回答开始遵循业务规则生成，Agent 也就真正具备了"懂业务"而不仅是"会回答"的能力。

图二：OAG 工作机制——从知识检索到业务推理

第三部分 OAG 如何真正落地企业业务：让 Agent 的回答专业、一致、可治理

如果说第二部分回答了 "OAG 是如何工作的"，那么企业真正关心的问题则是：OAG 如何落地到真实业务场景，并真正提升 Agent 的业务能力？

 对于企业而言，评价一个 Agent 是否优秀，并不只是看回答是否流畅，而是看它能否像一名熟悉业务的员工一样，理解当前业务对象、遵循企业制度，并给出一致、可靠、可执行的建议。传统 RAG 在知识问答场景已经能够取得不错效果，但当 Agent 开始参与授信审批、合同审核、营销决策、客户服务等复杂业务时，仅依赖文档检索已经难以满足要求。

OAG 的价值，正是在企业本体的支持下，让 Agent 从"引用知识"升级为"理解业务"，从而真正进入企业核心业务流程。近年来，包括微软 Fabric IQ、Palantir Foundry Ontology 以及 OG-RAG 等研究，都将 Ontology 视为企业 Agent 从知识助手走向业务助手的重要基础设施。

首先，OAG 能够让 Agent 按照业务对象组织回答，而不是按照文档组织回答。传统 RAG 检索到的是一组相似文档，因此回答往往受到文档结构影响。例如，询问"某客户为什么无法享受当前促销政策"时，模型可能分别引用促销制度、客户等级说明和销售手册中的不同内容，再自行组织答案。而 OAG 会首先识别当前业务对象是"客户"，随后围绕该客户关联的会员等级、历史订单、合同类型、活动规则、渠道政策等业务实体构建完整上下文，再生成回答。因此，回答逻辑不再来源于文档顺序，而是来源于企业业务关系，解释过程也更符合业务人员的思维方式。这种"Entity-first（以业务实体为中心）"的组织方式，也是近年来企业语义系统的重要发展方向。

其次，OAG 能够让 Agent 始终遵循企业业务规则，而不是依赖模型自由发挥。企业经营中存在大量规则密集型场景，例如金融授信额度、保险理赔条件、零售促销政策、合同审批权限、医疗诊疗规范等。传统 RAG 可以检索这些规则，但无法保证模型在回答时严格遵守所有约束，因此不同时间、不同 Prompt 甚至不同模型版本可能给出不同结果。OAG 则将这些业务规则作为企业本体的一部分，在生成之前完成语义校验。

例如，当销售 Agent 为客户申请折扣时，系统首先依据 Ontology 判断客户等级、订单金额、授权范围和审批流程，再决定是否允许生成优惠方案；当合同 Agent 解读合同条款时，也会优先依据当前生效版本及业务规则生成解释，而不是简单摘录历史文档。这样，业务规则从"隐藏在文档里"变成"运行在 AI 推理过程中"，Agent 的输出也因此更加一致、可审计、可治理。美国国家标准与技术研究院（NIST）在制造业 Ontology-RAG 研究中同样指出，引入 Ontology 后，生成过程能够围绕领域规则构建上下文，从而显著提升解释准确性和分析透明度。

第三，OAG 能够让多个 Agent 共享同一业务上下文，实现真正的人机协同和多智能体协同。随着企业开始部署 Marketing Agent、Sales Agent、Service Agent、Finance Agent 等不同角色，最大的挑战已经不是单个 Agent 是否聪明，而是多个 Agent 是否理解同一个业务对象。例如，一个销售 Agent 正在推进重点客户签约，客服 Agent 同时处理售后问题，财务 Agent 正在审核付款条件。如果每个 Agent 都依赖各自检索的文档，就容易出现业务理解不一致、状态不同步甚至决策冲突。而 OAG 将所有 Agent 锚定到同一企业本体，使它们共享客户、订单、合同、产品等业务实体及其关系网络，并共同感知当前业务流程所处阶段。这意味着，多智能体协作建立在统一业务语义之上，而不是建立在多个独立 Prompt 之上。微软提出的 Enterprise Intelligence Layer 和近年来的 OG-RAG、HEAR 等企业推理框架，都强调共享语义上下文是 Agent 协同的重要前提，也是企业 AI 从单点应用走向组织级智能的重要基础。

从行业实践来看，OAG 已经能够覆盖大量规则复杂、知识密集的业务场景。

在金融行业，授信 Agent 可以围绕客户主体、风险评级、授信政策、历史交易和监管要求生成可解释的审批意见；

在零售行业，营销 Agent 可以结合会员等级、促销规则、库存状态和渠道策略自动生成个性化营销建议；

在 B2B 企业中，合同 Agent 能够依据合同模板、法务规则、审批流程和客户信息解释条款差异，并自动提示潜在风险；

在制造业，运维 Agent 则可以围绕设备、工艺、零部件、维修记录和操作规范进行故障分析，而不是仅返回维修手册。

这些场景的共同特点是，Agent 不只是回答问题，而是在统一业务语义下完成理解、推理和决策。OG-RAG 的实验结果也表明，相比传统 RAG，基于 Ontology 的生成方式在事实召回、回答正确率和推理完整性方面均取得显著提升，尤其适用于复杂业务流程和专业知识密集场景。

对于 Marketingforce 而言，OAG 的落地路径同样十分清晰。企业首先通过 KnowForce 企业知识平台将制度文档、产品资料、业务规则、流程规范以及 CRM、ERP 等结构化数据统一挂载到企业本体；随后由 GenAIOS 提供统一语义运行环境，确保所有知识围绕业务实体组织；Marketing Agent、Sales Agent、Service Agent 则基于统一 Ontology 理解客户、产品、订单、合同和业务流程，在生成回答和执行任务时自动遵循企业规则；当多个 Agent 协同工作时，MAS 多智能体平台 再负责共享上下文、协调任务和同步状态。最终，企业获得的不再只是一个"能够回答问题"的 AI，而是一套能够理解业务、遵循规则、协同执行、持续优化的企业智能体系。

图三：OAG 在企业业务中的运行机制

第四部分 从 RAG 到 OAG：企业如何建设下一代知识平台

（以 Marketingforce 为例）

对于大多数企业而言，从 RAG 升级到 OAG，并不是推翻已有知识库重新建设，而是在现有知识体系之上增加一层企业语义层（Enterprise Semantic Layer）。事实上，经过多年数字化建设，企业已经拥有大量知识资产，包括制度文档、产品资料、项目案例、FAQ、CRM 数据、ERP 数据、业务字典、标签体系以及数据仓库。这些资源的问题并不是数量不足，而是缺乏统一的业务组织方式。传统 RAG 通常将这些内容切分为大量文本 Chunk，再通过向量检索完成召回，因此知识仍然以"文档"为中心存在；而 OAG 的目标则是把这些知识重新组织到"业务对象"之上，让知识围绕客户、产品、订单、合同、工单等企业核心实体建立关联，使 Agent 获得完整、连续且符合业务逻辑的上下文。

微软 Fabric IQ 提出的 Ontology 正是承担这一角色：通过统一业务概念、关系、规则和事件，将企业已有数据和知识整合为 AI 可理解、可推理的共享语义层，而不是重新建设一套新的知识库。(微软学习)

从工程实践来看，企业建设 OAG 通常可以分为四个阶段。

第一阶段是知识统一（Knowledge Consolidation）。企业需要打通知识库、CRM、ERP、数据湖以及业务系统，将结构化数据和非结构化文档统一纳入知识平台，解决知识孤岛问题。这一阶段对应的是传统 RAG 的数据准备过程，也是后续语义建模的基础。

第二阶段是企业本体建模（Ontology Modeling）。企业围绕客户、产品、渠道、订单、合同等核心业务对象建立统一语义模型，并定义实体之间的关系、生命周期、业务规则和约束条件。微软 Fabric IQ 支持基于现有语义模型（Semantic Model）和 OneLake 数据快速生成 Ontology，再由业务专家进一步完善业务关系和规则，大幅降低企业构建本体的成本。(微软学习)

第三阶段是OAG 推理引擎（Ontology-Augmented Generation Engine）。这一阶段也是 RAG 与 OAG 最大的区别所在。系统不再简单检索文档，而是首先识别当前业务对象，依据企业本体自动扩展关联知识、业务规则和流程上下文，再生成最终回答。例如，销售 Agent 回答"为什么该客户不能申请更高折扣"时，不仅检索促销政策，还会自动关联客户等级、合同类型、历史成交金额、审批权限以及当前营销活动，再依据企业规则完成推理。这意味着，回答过程已经从"检索文档"升级为"理解业务对象"。近年来发布的 OG-RAG（Ontology-Grounded Retrieval-Augmented Generation） 研究同样验证了这一思路。

研究表明，通过 Ontology 对检索结果进行语义组织，可以显著提升事实召回率、回答正确率和推理完整性，在复杂规则场景中，相较传统 RAG 获得更高质量、更具可解释性的生成结果。(arXiv)

第四阶段则是让 OAG 成为企业 AI 操作系统（AIOS）的共享能力。当企业建立统一的 Ontology 后，OAG 不再只是知识问答组件，而成为所有 Agent 的公共基础设施。Marketing Agent、Sales Agent、Service Agent、Finance Agent 等不同角色，都基于同一企业本体理解业务对象、调用知识和执行任务；多智能体之间共享同一业务上下文，不再因为知识来源不同而产生理解偏差；业务规则、权限模型和合规要求也统一运行在 Ontology 之上，使整个企业形成一致、可治理、可持续优化的智能体系。微软将这一能力称为 Enterprise Intelligence Layer，认为未来企业 AI 的竞争优势，不再来自单个模型，而来自统一的数据、语义和上下文，使所有 Agent 在同一个业务世界中协同工作。(微软)

对于 Marketingforce 而言，OAG 的落地路径也可以形成完整的产品能力闭环。企业可以通过 KnowForce 企业知识平台 对制度文档、业务规范、产品知识、客户案例以及 CRM、ERP 等数据进行统一管理，并围绕企业本体完成知识挂载；GenAIOS 企业 AI 操作系统 则提供统一的语义运行环境，将模型、知识、工具和业务流程连接起来；Marketing Agent、Sales Agent、Service Agent 等业务智能体在执行任务时，不再直接面对零散文档，而是基于 OAG 自动获取符合业务上下文的知识，并依据企业规则生成回答和执行动作；MAS 多智能体平台 则进一步协调多个 Agent 的协同运行，使营销、销售和服务围绕同一客户对象共享知识、同步状态、持续优化。

这样，企业获得的不只是一个升级版 RAG，而是一套能够支撑业务理解、智能协同和持续运营的企业级知识基础设施。

回顾全文可以看到，RAG 解决的是"知识获取"问题，OAG 解决的是"业务理解"问题。 RAG 让 AI 能够引用企业知识，而 OAG 则让 AI 能够理解企业业务；RAG 建立的是知识检索能力，OAG 建立的是企业智能能力。

未来真正优秀的企业 Agent，不会因为掌握更多文档而更智能，而是因为拥有统一的企业本体、更完整的业务上下文以及更严格的业务规则，从而做到回答专业、推理一致、执行可控、持续进化。这也意味着，企业知识平台正在从"文档管理系统"演进为"企业语义基础设施"，而 OAG，将成为 AI Native 时代企业知识工程的重要方向。