一文看懂企业建模新范式：ER、DDD、工作流之后，Ontology 凭什么成为底座？

企业 AI 缺的不是能力，而是一个让它可以理解、判断、行动、验证的企业业务世界——这就是 Ontology（本体）的核心价值。

传统企业软件设计中，ER 图定义数据结构，DDD 封装领域逻辑，Workflow 编排业务流程。这些方法成熟且有效。然而，当 AI Agent 需要从“回答问题”进化到“理解业务、调用系统、修改数据并推动执行”时，单纯的数据库查询或 API 调用已不足以支撑。

例如，面对“客户 A 订单延迟，需优先发货且不影响其他承诺”的指令，Agent 需解决客户身份统一、订单状态归因、库存占用冲突、业务规则判定、审批权限校验及结果验证等一系列复杂问题。这些问题涉及数据、语义、规则、动作与权限的深度交织。Ontology 的出现，旨在将散落在各系统中的业务对象、关系、状态、规则、动作和权限统一起来，构建一个供软件和 AI 共同理解的“业务世界”。

ER 描述数据结构，DDD 组织领域代码，Workflow 编排执行过程，而 Ontology 试图统一业务语义，连接上述所有层级。

核心看点

首先明确各技术的定位：

它们并非被取代关系，而是在统一业务语义下协同工作。Ontology 不一定建立在 Workflow 之上，也不替代 DDD 或数据库，而是通过映射与组合，解决“每种方法描述了什么，又遗漏了什么”的问题。

以“订单”为例，不同视角下的表达截然不同：

• ER / 数据库：关注数据结构、主外键关联。但字段 status=2 的具体业务含义（待支付/待审核/待发货）无法仅凭数据模型得知。
• DDD：关注聚合根、实体与领域服务，保护业务不变量（如取消订单的逻辑）。
• Workflow：关注任务执行顺序、分支与异常处理。
• 知识图谱：关注实体间的关系网络。

Palantir 将 Ontology 定义为组织的 operational layer（业务运行层），它将数据映射为现实世界的对象，并纳入动作、函数及动态权限。这标志着思维从“给系统建模”转向“给业务世界建模”。

ER 关注数据结构，Ontology 关注业务对象及其含义。

1. ER 的局限：字段关联不等于业务事实

数据库中 Order.customer_id = Customer.id 仅表示数据引用。但在业务层面，这意味着订单交付、付款等行为受客户属性（如信用、等级）影响。此外，不同系统对同一概念（如“客户”、“订单状态”）的定义可能不一致，单纯的数据关联无法解决语义歧义。

2. Ontology 的优势：统一业务语义

Ontology 定义企业中的业务对象（Customer, Order, Product, Warehouse）、业务关系（Link）、规则与动作。它不要求废弃现有数据库，而是通过映射，让 ERP、CRM 等系统在统一的业务语义下被理解。

例如，Ontology 不仅知道订单关联了客户，还明确：该客户是否有特殊交付约定？订单是否可取消？取消后是否触发退款及库存释放？哪些操作需审批？这些业务规则与状态变化，是 ER 图无法直接表达的。

1. DDD 解决领域内部复杂性

DDD 通过聚合、领域服务等确保领域内业务规则的一致性（如订单取消的逻辑保护）。这是代码实现的基石，AI Agent 的执行也依赖清晰可靠的领域规则。

2. Ontology 解决跨领域语义统一

企业中，订单、库存、物流、财务等领域模型分散在不同限界上下文中，对同一概念（如“完成”）定义各异。DDD 强调边界隔离，而 Ontology 致力于构建跨领域的统一业务视图，让 Agent 能同时理解多个领域的对象及其关系。

结论：Ontology 负责跨领域语义统一，DDD 负责领域内部规则实现。两者协同而非替代。切忌将 Ontology 做成另一个庞大的业务应用平台，重复实现底层逻辑，而应明确职责边界。

许多企业认为给 Agent 设计完善的 Workflow 即可，但在业务状态复杂、条件多变时，纯流程编排容易陷入“分支爆炸”。

1. Workflow 的困境：规则耦合

若将 VIP 优先、紧急审批、跨仓调拨、库存占用等所有业务规则写入流程，流程图将变得极其复杂且难以维护。一旦业务规则变更，所有相关流程均需修改。

2. Ontology 的思路：声明性规则

Ontology 将规则围绕业务对象组织。系统不再仅询问“下一步去哪”，而是基于当前业务状态判断：

• 订单是否具备发货条件？
• 是否存在可用库存？
• 调拨是否违反其他承诺？
• 用户是否有权发起？

Workflow 告诉系统“怎么走”，Ontology 帮助系统理解“当前是什么情况”以及“哪些路走得通”。二者结合：声明性规则提供判断依据，Workflow 组织执行步骤。

1. 知识图谱：连接知识

知识图谱擅长发现实体间的关系（如谁负责哪个客户，订单包含哪些商品），支持检索与推理。但它主要解决“知识如何连接”，而非“业务如何执行”。

2. Ontology：面向业务运行

当 Agent 需要执行“优先发货”时，仅有关系不够，还需判断：

• 订单当前能否发货？
• 库存是否已被占用？
• 调整顺序是否违规？
• 谁有权批准？

Ontology 在对象和关系基础上，进一步组织业务状态、规则、动作、权限和治理机制，将知识转化为可执行的业务模型。

AI Agent 时代，执行主体从固定程序扩展到动态规划，业务规则的存放位置至关重要。

1. 过去：规则散落各处

规则分散在数据库约束、领域服务、Workflow 分支、API 校验、权限系统及员工经验中，缺乏一致性，导致人类需凭经验判断，AI 则易产生幻觉或错误推测。

2. 未来：规则明确归属

Ontology 为规则建立统一的业务语义入口，但不一定实现底层逻辑。例如：

通过将条件抽象为声明性规则（如 urgent_allowed = order_is_eligible AND ...），业务规则变化时只需更新定义，无需修改所有流程分支。

企业 AI 的目标是从“找到答案”扩展到“在正确条件下做正确的事”。

1. 知道怎么做 ≠ 有权去做

即使 Agent 推理出最优解（如跨仓调拨），也必须经过权限校验。企业需区分事实问题、决策问题和授权问题。权限必须由可信的后端系统实施，不能依赖 Agent 的自觉。

2. Action 不只是 API

传统 Tool Calling 仅关注函数调用。Ontology 驱动的 Action 包含明确业务语义：

Agent 应理解操作的业务对象、条件及影响，而非仅仅知道某个 API 可调用。

构建一个处理订单延迟、分析库存并推动发货的企业 Agent，各层职责如下：

• ER：设计清楚的数据结构（Customer, Order, Inventory 等）。
• DDD：划分领域上下文（Order, Inventory, Shipping Domain），实现各自业务逻辑。
• Workflow：编排任务步骤（查询、判断、申请、审批、执行、核验）。
• 知识图谱：连接跨系统对象关系（Customer owns Order, Order contains Product 等）。
• Ontology：统一定义 Object/Property, Link, Logic, Action/Security, Audit。Agent 基于此理解业务世界，执行受控操作。

1. 普通 Agent 架构的局限

LLM + RAG + Tools 架构中，RAG 检索到的碎片信息缺乏统一业务模型，Tools 仅提供技术能力，无法自动解决数据一致性、业务授权和执行核验问题。

2. Ontology-driven Agent

Agent 围绕统一业务对象工作：识别目标 -> 利用 Ontology 获取 Data/Logic/Action -> 权限校验 -> 执行 -> 验证。Ontology 提供了可共享的业务基础，避免每次开发新 Agent 时重新拼接语义。

需警惕三种情况：

1. Ontology Fragmentation（碎片化）

各团队自建模型，缺乏映射。解决之道：明确哪些核心概念（如客户、订单）需共享统一标识，哪些保留在领域内部。

2. Model Drift（模型漂移）

业务变化快，模型滞后。需建立业务负责人、变更流程、版本管理及持续验证机制。

3. Over Modeling（过度建模）

勿从“所有对象”开始，应从具体业务问题（如订单延迟处理）入手，逐步沉淀共享能力。

简单问答或单一系统自动化无需 Ontology。建议从以下三个条件判断：

1. 跨系统共享业务语义：多系统需围绕统一对象协同，多应用/Agent 需复用定义。
2. 动作需严格权限和审计：AI 需修改业务状态、发起审批或有业务影响的操作。
3. AI 参与决策与执行：Agent 需跨领域理解状态、应用规则、选择动作并核验结果。

若遇到传统模型难以解决的跨系统业务问题，Ontology 便值得进入架构讨论。

• ER / Database：保证数据存储可靠。
• DDD / Domain Services：保证领域规则正确实现。
• Workflow：保证任务按步骤推进，处理异常。
• Knowledge Graph：连接实体与关系，支持检索推理。
• Ontology：形成可供多应用与 Agent 共同使用的业务语义基础。

对于成熟企业，Ontology 更合理的切入方式是从跨系统业务场景入手，逐步沉淀共享语义，而非推倒重建。

ER 管数据，DDD 管代码，Workflow 管流程，知识图谱管关系，而 Ontology 尝试把企业世界统一起来。这不是替代，而是企业从“让软件处理数据”走向“让 AI 在业务世界中受控地行动”时，必须思考的架构演进。