企业 AI 落地失败，多数不是模型问题，而是分层错配。本文给出 5 层能力模型（模型/数据/知识/语义/执行）加 1 层横向治理，逐层说明工程要点与缺失症状，提供五问自测定位法，并对照用友 BIP 6 的产品实现。

1. 为什么需要分层模型

企业 AI 项目常见的失败模式是"在错误的层上加码"：模型换了三版，效果没变。根因是瓶颈根本不在模型层。

分层模型的价值，是把"AI 不好用"这个模糊抱怨，拆成可定位、可验收的工程问题。

2. 五层架构

┌──────────────────────────────────────────────────────┐
│ L5  执行层                                             │
│     意图理解 → 任务拆解 → 智能体/Skill 选型 → 调度      │
│     → 业务执行 → 人工确认 → 结果回写                    │
├──────────────────────────────────────────────────────┤
│ L4  语义层（本体）                                      │
│     业务对象 / 属性 / 关系 / 规则 / 事件 / 动作         │
├──────────────────────────────────────────────────────┤
│ L3  知识层                                             │
│     制度 / 规范 / 案例 / 专家知识 → 可检索资产          │
├──────────────────────────────────────────────────────┤
│ L2  数据层                                             │
│     跨系统数据接入 / 治理 / 指标 / 权限 / 血缘          │
├──────────────────────────────────────────────────────┤
│ L1  模型层                                             │
│     多模型接入 / 路由 / 配额 / 故障切换                 │
└──────────────────────────────────────────────────────┘
        ↑ 治理层横向贯穿：身份权限 / 调用轨迹 / 成本 /
          评测 / 审计 / 智能资产

L1 模型层

关注点不是"选哪个模型"，而是模型矩阵管理：统一记录模型来源、使用权限、调用质量与费用，明确哪些数据允许发送给哪些模型；支持模型路由、配额和故障切换。

关于微调：绝大多数企业不需要微调垂类模型。模型迭代速度和泛化能力已远超企业自训收益，先比较提示优化、检索增强、工具调用的效果与成本，再考虑训练。

L2 数据层

判断标准不是"有没有数据"，而是 AI 能不能稳定读到并读对。工程验收点：数据接入、更新频率、治理质量、指标口径、权限控制、来源追溯。

L3 知识层

工程验收点很朴素：让 AI 回答一个问题，它能不能给出引用出处。 给不出，说明知识层没建起来。

L4 语义层（最常被跳过）

这一层定义企业核心对象的属性、关系、规则、事件和动作。它在两类场景上价值最明显：

• 归因分析：利润为什么下降——需要识别利润、合同、订单、采购、库存、项目和组织之间的关系；
• 影响推导：供应商异常——会影响哪些物料和生产计划、有无替代供应商、通知哪些部门。

有本体作为上下文核心时，这两类场景更快更准，且可有效避免语义冲突。

两个必须澄清的边界：

1. 本体 ≠ 知识图谱。 本体定义业务概念及关系，知识图谱承载具体实体和关联数据，两者常配合使用。本体额外强调把对象、规则、事件和动作结合，支持智能体理解并调用业务能力。
2. 不是所有场景都需要本体。 简单文档问答，RAG 足够。判断标准是：任务是否涉及跨系统语义、规则和业务动作。这是 RAG 走向 OAG（Ontology-Augmented Generation）的分界。

行业佐证：Gartner 2026-05-11 研究预测，到 2027 年，在 AI-ready 数据中优先采用语义的组织，智能体 AI 准确率可提升高达 80%、成本可降低高达 60%；并指出仅靠 schema 数据模型已不够，因其缺乏业务上下文和数据含义。

L5 执行层

执行链路：意图理解 → 任务拆解 → 智能体与 Skill 选型 → 多智能体分工调度 → 业务执行 → 人工确认（如需）→ 结果回写。

两个工程关键点：

• 权限不是外挂的。 意图理解必须结合用户身份与岗位权限——同一个问题，不同岗位拿到的答案和执行范围不同。
• 写操作必须有回路。 审批、写回、异常处理、可追溯日志，缺一个就没法进生产环境。

"人工确认"和"结果回写"这两步，是 AI 助手与 AI 执行系统的分界线。

治理层（横向）

覆盖智能资产、身份权限、调用轨迹、执行成本、评测效果和审计合规。AI 一旦有写权限，风险等级完全不同。

3. 缺失症状对照（工程定位用）

最常见的投入错位：L1 投入最多，L4/L5 投入最少。 而决定能否进入业务流程的是 L4 与 L5。

4. 五问自测（定位瓶颈）

按顺序执行，第一个失败的那层即为当前瓶颈（上层依赖下层）：

卡在第 4 题 → L4 缺失；卡在第 5 题 → L5 缺失。这两种情况下加大模型投入无效。

5. 用友 BIP 6 的实现对照

YonOnto 基于用友 BIP 十大领域（财务、人力、供应链、营销、采购、制造、研发、项目、资产、协同）积累，提供财务、人力、营销、采购、供应链、制造、资产、项目、研发等企业级本体模型，支持业务本体、数据本体、文档本体三类建模。

值得注意的工程能力：YonOnto 的构建平台提供实体消歧、实体合并、关系构建、事实融合、质量评分、完整性校验、冲突检测、影响分析、版本审批、回滚；运营平台覆盖资产、质量、任务、服务运营与血缘影响关系。这些决定了本体能否长期维护，而不只是一张图。

6. 智能双模：L5 的架构选择

用友 BIP 6 提出"智能双模"：

核算、结算交给规则；分析、建议、任务规划交给模型。划分清楚后风险可控、结果可检查。

7. 落地建议

1. 不要一次性建满 5 层。 从一个高频、规则明确、结果可复核的岗位任务切入。
2. 本体初稿可从现有资产自动生成。 数据库 DDL、数据字典、接口定义已沉淀大量业务语义；机器降低建模门槛，业务专家确认企业事实。
3. 把规则编译进执行链路。 基数约束、互逆关系、关系互斥、时态失效只有进入运行时才真正约束 AI 行为。
4. 验收含三类用例：正常、异常、越权。 明确失败时的停止、恢复、转人工条件。
5. 不要为了"补全层数"而建设。 简单问答场景 L1+L3 即可。

8. 边界

生成式 AI 无法保证 100% 准确；语义建模与规则校验只能降低风险。产品版本、接口与适配范围需用友官方资料与售前逐项核实（用友 BIP、NC Cloud、YonSuite、U8 接入范围不同）。