OODER 三模式体系结构设计——AI 原生系统需要本体论的重构

🏛️第一部分：体系结构设计 —— 三模式的本体论框架

1.1 引言：AI 原生系统需要本体论的重构

1.1.1 传统 IT 系统的本体论缺陷

传统 IT 系统建立在"数据—逻辑—表现"的三层架构之上。这一架构在本质上是一种 单一本体论——所有实体、关系、操作都被压缩进同一个关系模型，由同一个运行时承载。这在确定性业务中工作良好，但面对 LLM 带来的不确定性时暴露出三个结构性缺陷：

缺陷一：知识无本体

传统系统的知识散落在数据库记录、代码注释、文档中，没有形式化的知识表示层。LLM 接入后，"知识从哪来、如何被检索、如何被验证"成为空谈。

缺陷二：设计与运行时耦合过紧

传统系统的"设计"发生在编译期，"运行"发生在部署后。LLM 要求在运行时动态生成新的系统产物，传统架构没有"生成时"这个运行时阶段。

缺陷三：运营缺乏人机协同的本体位置

传统系统的运营（审批、协作、审计）是代码固化的业务逻辑，不是可插拔的人机交互层。LLM 需要"人的意志"的介入点，但传统架构没有这个插槽。

1.1.2 本体论：AI 原生系统的理论基石

本体论（Ontology）源自哲学——研究"存在"的本质和分类。在信息科学中，Gruber（1993）给出了被广泛接受的定义：

本体论是对共享概念化（conceptualization）的形式化、显式化规范说明。

一个本体由五个要素构成：

AI 原生系统的核心挑战，不是"把 LLM 接进来"，而是 在同一套骨架中容纳三种不同性质的本体，并让它们可以相互引用、相互喂养。

1.2 三模式的本体论分类

1.2.1 总览：三种本体

图 1：三种本体论分类对比 ｜ 描述性本体（知识）· 生成性本体（设计）· 程序性本体（运营）

1.2.2 描述性本体（Knowledge / CHAT）—— 回答"What is"

描述性本体是对领域知识的形式化表达，包括概念体系、分类框架、实体关系、实例数据。在 OODER 中，它的核心载体是 6 个场景组（scene-group）知识层：

📕 关键设计决策

CHAT 是降级默认值（normalize(null) → "chat"）。从本体论角度看，这意味着 描述性本体是系统的基础层——当系统无法确定一个意图属于生成性本体还是程序性本体时，它退回到描述性本体，先"理解"再"行动"。这不只是技术默认值，而是一个本体论承诺：知识是另外两种本体的前提。

1.2.3 生成性本体（Design/Dev / ARCHITECT）—— 回答"What could be"

生成性本体是对系统可产物的规范表达，包括组件结构、生成规则、变换逻辑、校验标准。它的核心是 四分离（Four Separation）——对 UI 组件的本体论分解：

图 2：四分离架构 —— 对 UI 组件的本体论分解，四个正交的分类轴

这四层不是物理分层，而是 本体论上的分类轴——任何 UI 组件都可以在这四个轴上投影。LLM 在生成组件时，不是自由发挥，而是按照这四个本体维度填充属性。

1.2.4 程序性本体（Operation / BUSINESS）—— 回答"What happens"

程序性本体是对系统行为与治理的形式化表达，包括流程编排、路由规则、决策节点、人机协同契约。它的核心机制是 HUMAN 一等公民：

🔄 HUMAN 不是"异常处理"，而是第一类实体

每个 HUMAN 节点都有明确的契约（requiredInputs → producedOutputs）、超时策略（timeoutBehavior）、委托路径（H2A/H2H/H2T）和回退目标（returnTargets）。这意味着人的意志在系统本体中有一个 显式的位置，而不是被当作"特殊 case"塞进代码逻辑。

1.3 统一意图分发：元本体论桥接

三种本体覆盖了不同维度的系统行为，但它们必须在一个统一的入口处被"对齐"和"路由"。这就是 元本体（Meta-Ontology）——关于本体选择的本体。OODER 的 intent-dispatch 流程就是这个元本体。

图 3：意图分发流程 —— 元本体论的三步操作：本体对齐 → 本体实例化 → 本体切换

本体论承诺（Ontological Commitment）

意图分发中的 HUMAN/CONFIRM 节点不是普通的"确认对话框"，它在本体论上对应 本体论承诺（Ontological Commitment, Gruber 1993）。当系统将一个意图映射到某一种本体时，它做出了一个不可逆的承诺——后续所有推理、生成、决策都将在这个本体的框架内进行。用户对意图的确认，就是对这个承诺的背书。

共享语法：阶段（Phase）作为通用本体模式

1.4 体系结构总览

图 4：OODER 三模式体系结构总览 —— 元本体层 → 三层本体 → 通用基础设施层

三种本体的核心差异对比

🔍第二部分：业务功能分析 —— 三模式的功能分解

2.1 业务功能分析方法论

采用"本体 → 功能域 → 功能点"的三层分解方法：

1. 本体层：每种本体对应一个抽象功能域（Knowledge / Design / Operation）
2. 功能域：每个本体内部按业务逻辑切分为多个子功能域
3. 功能点：每个子功能域对应具体的流程/活动/工具

2.2 知识管理功能域（CHAT 模式）

📚

知识库构建

批量上传引导（knowledge-init-pipeline）、DocView 批量转换、导游培训知识库（4场景专业知识库）

知识检索

场景组知识检索（6个scene-group RAG路由）、知识绑定查询、相似度检索（threshold=0.7）

知识问答

通用对话（chat-pipeline → GeneralChatScene）、垂直领域问答、降级兜底（chat作为降级默认值）

知识绑定

流程级绑定（每条流程的knowledgeBindings）、阶段级绑定（INTENT/ENTITY/DESIGN/QUALITY/INTEGRATE层）、作用域控制（scopeKeys）

2.3 设计开发功能域（ARCHITECT 模式）

架构师协同设计

多Agent HARNESS模式：architect_agent（方案生成）↔ reviewer_agent（方案评审），交替推理直到共识（consensusThreshold=0.85）

四分离生成

FourSeparationEnhancedStep：视图层/工具层/分页层/数据层 → genJson → .cls + .java（NlpBuildComponentTool）

质量校验 + 最终审批

llm-fallback-subflow：LLM兜底 + 质量校验 + 数据飞轮持久化；human_final_approval：HUMAN/APPROVAL 节点

多建模策略

DBFirst / DesignerFirst / ChartFirst / SvgPaperFirst 四种入口策略，按建模起点分叉

2.4 运营管理功能域（BUSINESS 模式）

流程编排

bpm-scene：ProcessDef 设计、Activity 编排、Route 配置、回退机制、会签机制

业务集成

business-integrate-subflow：配置管理、组件生成事件（BROADCAST）、流程结束

表单创建引导

form-creation-guide：HUMAN 节点引导选择（上传模板/描述构建/直接开始），路由到对应子流程

垂直业务

专利审查（patent-review-scene）：形式审查 + 实质审查，知识库驱动

2.5 跨本体功能协同

共享子流程

跨本体事件协同

architect-pipeline 生成组件
  ↓
component_generated 事件（BROADCAST）
  ↓
bpm-scene（订阅）→ 流程定义更新可用组件列表
page-debug-scene（订阅）→ 页面调试工具可测试新生成的组件

⚡第三部分：通用基础设施

3.1 通用基础设施总览

三种本体共享的通用基础设施包括 6 大模块：流程引擎、六层上下文模型、FC-Loop 与 HUMAN 一等公民、Guard 防护体系、知识绑定、数据飞轮。

3.2 流程引擎 —— 统一执行骨架

流程引擎是三种本体的 统一执行骨架。无论哪种本体，其实例化都通过同一条路径：ProcessDefinition → ProcessInstance → ActivityInstance → ActivityDispatcher。

图 5：流程引擎生命周期 —— 双层架构 + 路由决策 + Guard 防护

双层架构：场景流程与子流程

路由决策协议

1. 收集所有 outgoing transitions，按 priority 降序排列
2. 遍历 transitions，匹配 condition 表达式
3. 如果匹配 → 执行该路由
4. 如果均不匹配 → 执行 priority=1, condition="" 的默认降级路由
5. 如果无默认路由 → 触发 noMatchPolicy（WAIT / SKIP / RETRY / ESCALATE_HUMAN）

3.3 六层上下文模型 —— 统一认知框架

图 6：六层上下文模型 —— 静态层（长期记忆）+ 动态层（工作记忆）

加载策略

{
  "defaultLoadLevel": "standard",
  "loadLevels": {
    "standard":    { "maxHistoryRounds": 10, "tokenBudget": 32000 },
    "deepDesign":  { "maxHistoryRounds": 20, "tokenBudget": 64000, "deepDesignMode": true }
  }
}

3.4 FC-Loop 与 HUMAN 一等公民 —— 统一人机协同契约

图 7：FC-Loop（Function Calling Loop）—— LLM 工具调用的闭环

HUMAN 节点的三种委托模式

3.5 Guard 防护体系 —— 统一安全边界

流程级 Guard（ProcessLevel）
├── maxLlmRounds: 100      // 流程级 LLM 最大轮数
├── maxTotalTokens: 500000  // Token 总预算
├── maxBackwardCount: 3     // 最大回退次数

活动级 Guard（ActivityLevel）
├── maxLlmLoopCount: 3      // 活动级 LLM 循环次数
├── fcLoopMaxRounds: 5      // FC-Loop 最大轮数
├── maxTokensPerCall: 32000 // 单次调用 Token 上限
└── tokenBudgetPerActivity: 64000 // 活动级 Token 预算

⚡ 默认降级路由 —— 防卡死最后防线

每个路由节点必须有默认降级路由（priority=1, condition=""），防止条件未命中时卡死。这是"流程不能卡死"的工程铁律。

3.6 知识绑定 —— 统一知识注入

knowledgeBindings 是连接流程与知识的桥梁，定义在每条流程的 definition.json 中：

{
  "bindingId": "kb_architect-pipeline_understand",
  "swimLaneId": "SG-UNDERSTAND",
  "layer": "INTENT",
  "scopeKeys": ["intentKeywords", "intentTypeMap", "sceneDispatch", "buildLevelKeywords"]
}

即使是在代码生成管线 architect-pipeline 中，也绑定了 5 层知识：INTENT（意图识别）、ENTITY（实体识别）、DESIGN（设计生成）、QUALITY（质量校验）、INTEGRATE（集成编译）。知识不是被查询的数据库，而是参与每一次推理的上下文。

3.7 数据飞轮 —— 统一反馈循环

图 8：数据飞轮闭环 —— 三位一体的循环喂养工程实现

数据飞轮是三种本体之间"循环喂养"的工程实现：

设计（ARCHITECT）→ 生成组件
  ↓
组件生成完成事件（BROADCAST）
  ↓
运营（BUSINESS）→ 使用组件，沉淀业务规则
  ↓
知识（CHAT）→ 沉淀为知识库内容
  ↓
知识绑定 → 约束下一次设计
  ↓
设计（ARCHITECT）→ 更精准的生成

📎附录 A：本体论映射表

A.1 本体论要素与 OODER 实现的完整映射

A.2 本体论视角的关键设计决策

A.3 关键源码索引

OODER Studio — 知识 / 设计 / 运营三位一体的 AI 原生技术体系