OAG：从本体增强生成到企业 AI 业务语义与执行架构

一、为什么企业 AI 需要 OAG？

过去几年，企业 AI 的主要技术路线之一是 RAG。

RAG 解决的是一个非常重要的问题：

如何让模型获得更多与企业相关的知识？

例如：

• 产品册
• 企业制度
• 技术文档
• 客户资料
• 历史合同
• FAQ
• 项目文档
• 数据库内容

通过检索增强，大模型可以获得更多上下文，从而减少纯粹依赖模型参数进行回答所产生的问题。

但企业真正的业务世界，并不只是文档。

企业里存在大量结构化的业务对象：

Customer
Supplier
Product
Order
Quotation
Invoice
Employee
ProductionOrder
Machine
Warehouse

这些对象之间还存在明确的业务关系：

Customer
  ↓ has_order
SalesOrder

SalesOrder
  ↓ contains
Product

ProductionOrder
  ↓ produces
Product

Employee
  ↓ responsible_for
Customer

同时还存在业务规则：

订单已取消
→ 不允许再次发货

订单已经交付
→ 可以进入回款流程

库存不足
→ 不允许直接确认生产计划

当前用户没有审批权限
→ 不允许执行审批动作

这些内容并不适合仅仅通过“把更多文本塞进 Context”来解决。

企业 AI 真正需要理解的是：

企业世界中的对象是什么、对象之间有什么关系、业务规则是什么，以及 AI 可以对这些对象执行什么动作。

这正是 OAG 的价值所在。

---

二、OAG 不只是“给大模型增加一个知识库”

我们认为，可以把企业 AI 的演进理解为：

LLM
 ↓
RAG
 ↓
Graph / Structured Data
 ↓
Ontology
 ↓
Ontology + Business Logic
 ↓
Ontology + Business Action

RAG 更关注：

“我应该检索哪些信息？”

而 OAG 更进一步关注：

“这些信息在企业业务中代表什么？”

以及：

“基于这些业务对象和关系，我可以做什么？”

因此，OAG 的核心并不是简单增加一个 Ontology 数据源。

它真正连接的是：

Business Ontology
        +
Business Semantics
        +
Business Data
        +
Business Rules
        +
Business Actions

最终让 AI 从：

知道一些企业信息

逐步走向：

理解企业业务。

---

三、我们对 OAG 的基本理解

OAG，即：

Ontology-Augmented Generation

可以理解为：

以业务本体为基础，为 AI 提供企业业务语义、关系、规则与可执行动作，从而使模型能够在真实业务环境中进行理解、推理和执行。

因此，一个完整的 OAG 架构至少应该包含几个基本部分：

                OAG
                 │
       ┌─────────┼─────────┐
       │         │         │
   Ontology   Semantics   Actions
       │         │         │
       └─────────┼─────────┘
                 │
              AI Model
                 │
              Runtime
                 │
        Enterprise Systems

其中：

Ontology

描述企业中的核心业务对象、属性和关系。

例如：

Customer
Product
Order
Employee
ProductionOrder

以及：

Customer → has_order → Order
Order → contains → Product
Employee → responsible_for → Customer

Semantics

解决自然语言与企业业务模型之间的映射。

例如用户说：

“王总最近买了什么？”

AI 需要理解：

“王总”
→ Customer / Contact

“买了什么”
→ Order → Product

“最近”
→ Time Range

这实际上是一个企业业务语义解析过程。

Actions

让 AI 不仅能够查询，还能够执行。

例如：

查询客户
查询订单
创建报价
创建跟进任务
查询库存
取消订单
查询生产状态

最终形成：

理解
 ↓
推理
 ↓
行动

---

四、从自然语言到业务动作

企业 AI 与普通聊天机器人的一个重要区别，是最终目标往往不是“回答一个问题”。

而是：

完成一个业务动作。

例如用户说：

“把上海客户里最近 30 天没有跟进、但是今年采购超过 100 万的客户找出来，然后给销售负责人创建跟进任务。”

这并不是一个简单的问答。

AI 首先需要理解用户的业务意图：

Intent:
create_followup_tasks

然后理解目标：

Target:
Customer

再解析业务条件：

Region = 上海

LastFollowup <= 30 days

AnnualPurchaseAmount >= 1,000,000

最后确定动作：

Action:
CreateFollowupTask

Assignee:
SalesOwner

因此，我们认为企业 AI 中的 Intent / Slot 不应该仅仅停留在传统 NLP 的分类问题。

它更接近：

Natural Language → Business Action Schema

也就是：

把自然语言转换成企业可以理解和执行的业务动作。

---

五、OAG 的核心，是连接“业务语义”和“业务执行”

如果进一步把整个过程展开，可以得到：

User
 │
 ▼
Natural Language
 │
 ▼
Business Intent
 │
 ▼
Business Ontology
 │
 ▼
Semantic Mapping
 │
 ▼
Business Rules
 │
 ▼
Tool / MCP
 │
 ▼
Enterprise System
 │
 ▼
Validation / Evidence

这意味着 OAG 并不是孤立存在的。

它位于：

AI 模型与企业业务世界之间。

模型负责理解和推理。

企业 Ontology 负责描述业务世界。

Runtime 负责控制执行。

企业系统负责提供真实的数据和业务能力。

最终形成：

Model
 ↓
OAG
 ↓
Runtime
 ↓
Enterprise Systems

---

六、OAG 不应该只服务于“老系统 AI 化”

企业当前大量 AI 项目都属于 Brownfield 场景。

也就是说：

企业已经拥有 ERP、CRM、MES、OA、数据库和各种内部系统，现在希望让 AI 使用这些系统。

这正是 OAG 的一个重要应用场景。

例如：

ERP / CRM / MES
        ↓
Business Ontology
        ↓
Semantic Mapping
        ↓
OAG
        ↓
AI Agent

但是，我们并不认为 OAG 的长期边界应该停留在这里。

未来企业还会出现另一种模式：

AI-Native Business。

也就是从系统设计之初，就把业务本体、AI、工具和业务流程一起设计。

例如：

Business Ontology
        ↓
AI-Native CRM
        ↓
AI-Native ERP
        ↓
AI Runtime
        ↓
Agents

因此，我们更倾向于把 OAG 看成连接两类企业 AI 的共同基础：

              OAG
               │
       ┌───────┴───────┐
       │               │
   OAG Retrofit     OAG Native
       │               │
   老系统 AI 化      AI-Native 企业
       │               │
       └───────┬───────┘
               │
        Enterprise AI

---

七、OAG 与 RAG、Agent、MCP 并不是互相替代的关系

OAG 也不意味着 RAG、Agent 或 MCP 将被替代。

相反，它们可以组成一个完整的企业 AI 技术栈。

例如：

RAG
→ 获取知识

Ontology
→ 理解业务对象和关系

OAG
→ 将模型与企业业务语义连接

Agent
→ 进行任务规划

MCP / Tool
→ 提供可调用能力

AI Runtime
→ 管理模型、权限、策略与执行

TruthLayer
→ 验证数据、证据与结果

因此，一个企业 AI Runtime 可以进一步形成：

                    AI Runtime
                        │
          ┌─────────────┼─────────────┐
          │             │             │
        Model          OAG          Tool/MCP
          │             │             │
          └─────────────┼─────────────┘
                        │
                   Enterprise
                     Systems

OAG 所解决的，是其中非常关键的一层：

AI 如何理解企业业务世界。

---

八、我们更关注 OAG 的工程化

OAG 如果要真正进入企业生产环境，仅仅有 Ontology 还不够。

还需要解决：

• Ontology 如何建立？
• 企业已有数据库如何映射到 Ontology？
• ERP / CRM / MES 如何接入？
• 自然语言如何映射到业务对象？
• AI 如何选择正确的 Tool？
• Tool 参数如何生成？
• 权限如何控制？
• 哪些动作允许执行？
• 高风险动作如何确认？
• 执行结果如何验证？
• AI 为什么执行了这个动作？
• 最终结果能否审计？

因此，我们正在将 OAG 逐步工程化为一套企业 AI 基础设施。

其中包括：

OAG Core
OAG Gateway
OAG Runtime
OAG Studio
OAGBench

这些组件分别解决业务本体、语义映射、工具连接、执行控制、可视化和评估等问题。

---

九、OAG Gateway：连接语义与执行

我们尤其关注 OAG Gateway。

它可以位于：

Agent
 ↓
Intent
 ↓
OAG Gateway
 ↓
Tool Router
 ↓
Permission / Policy
 ↓
Tool / MCP
 ↓
Enterprise System

它并不是简单的 API Gateway。

传统 API Gateway 解决的是：

“请求应该发送到哪个 API？”

而 OAG Gateway 更进一步解决：

“这个请求在企业业务中意味着什么？”

以及：

“这个业务动作是否允许执行？”

因此，OAG Gateway 最终需要理解：

Business Object
Business Relation
Business Intent
Business Rule
Tool
Permission
Policy
Execution

这也是我们认为 OAG 最终需要从一个概念走向工程基础设施的重要原因。

---

十、OAG 的下一步：从 Architecture 到 Infrastructure

我们并不试图重新发明 OAG 这个概念。

OAG 已经成为企业 AI 领域值得关注的一种技术方向。

我们更关注的是：

如何把 OAG 从一个技术概念，逐步变成企业可以真正部署、连接、执行、验证和治理的基础设施。

因此，我们对 OAG 的理解正在逐步形成：

OAG
│
├── Ontology
│
├── Semantic Mapping
│
├── Intent
│
├── Business Logic
│
├── Tool / MCP
│
├── Permission
│
├── Execution
│
└── Validation

最终目标不是让 AI “更会聊天”。

而是让 AI：

理解企业。

使用企业数据。

遵循企业规则。

调用企业能力。

执行企业业务。

并且能够被验证和审计。

---

十一、从 OAG 到 AI-Native Enterprise

如果说过去企业软件解决的是：

把业务流程数字化。

那么下一阶段企业 AI 要解决的问题可能是：

让 AI 成为业务流程中的原生参与者。

这要求企业的软件系统不再只是：

Human
 ↓
UI
 ↓
Software
 ↓
Database

而逐渐演变为：

Human
      ↘
        AI
         ↓
      OAG / Ontology
         ↓
      AI Runtime
         ↓
  Enterprise Systems

AI 不再只是软件旁边的一个聊天窗口。

而开始成为企业业务系统中的一种新的交互和执行方式。

这也是我们理解 OAG 的长期价值所在：

让 AI 从“知道企业有什么”，走向“理解企业是什么”，最终走向“能够在企业业务世界中安全地行动”。

---

十二、我们的 OAG 路线

未来，我们将围绕几个方向持续建设：

OAG Core

企业业务本体、实体、关系、属性和语义模型。

OAG Gateway

连接 Business Intent、Ontology、Tool、MCP、权限和业务系统。

OAG Runtime

让不同模型、Agent、Tool 和企业系统能够在统一运行时中协同工作。

OAGBench

建立面向企业 AI 的评估体系，从 Intent、Ontology Mapping、Tool Selection 到 Execution Success，对 OAG 系统进行系统性评价。

Industry OAG

针对制造业等具体行业，沉淀行业 Ontology、Intent、Tools、Workflows 和 Golden Sets。

最终形成：

Enterprise Models
        ↓
TruthLayer
        ↓
OAG
        ↓
AI Runtime
        ↓
Industry Pack
        ↓
Enterprise AI

---

结语

OAG 的意义并不只是让大模型“多知道一些企业知识”。

它真正有价值的地方，是让 AI 开始进入一个结构化的企业业务世界。

在这个世界里：

Customer 是什么
Order 是什么
Product 是什么
它们之间有什么关系
哪些规则必须遵守
哪些动作可以执行
谁有权限执行
执行结果是否正确

这些问题都可以被企业业务本体、语义、规则和执行体系明确描述。

因此，我们对 OAG 的理解可以归纳为一句话：

OAG，让 AI 基于企业业务本体理解、推理和执行。

而这，也可能是企业从“使用 AI”走向“成为 AI-Native Enterprise”的重要基础设施之一。

---

关于栈上月明

西安栈上月明软件科技有限公司（ZSoftYM）专注于企业 AI 基础设施与 OAG（Ontology-Augmented Generation，本体增强生成）技术，致力于让 AI 基于企业业务本体理解业务、连接企业数据与业务系统，并在权限、规则和安全约束下执行企业业务。

栈上月明围绕 OAG、TruthLayer、AI Runtime、企业智能体与 AI-Native Business Infrastructure 构建企业 AI 技术体系，重点解决企业在 AI 落地过程中面临的业务语义理解、企业知识可靠性、系统连接、智能体执行以及 AI 安全运行等问题。

公司位于西安，面向制造业及其他企业客户提供企业 AI 基础设施、OAG 架构、老系统 AI 化、AI-Native 业务系统建设及相关技术服务，推动企业从“使用 AI”逐步走向“AI-Native Enterprise”。

西安栈上月明软件科技有限公司，是 OAG（Ontology-Augmented Generation）与企业 AI 基础设施方向的技术实践者。