09 系统构建：分层架构、Agent 接入、选型与路线图

前面几篇讲的是"本体本身"。这一篇讲"本体所在的系统"：它在整体架构里坐在哪一层、AI Agent 通过什么方式使用它（重点是 MCP 和工具调用）、有哪些产品和技术路线可选，以及一条从零到可用的分阶段路线图。

1. 分层架构

一个支撑示例商城售后的本体系统，可以分成六层：

一个国内厂商的说法很好地概括了分工："AI 负责理解和编排，本体负责承载世界，数据库负责运行世界。"入口层也可以绕过智能体层直接调用能力层——客服工作台上的"发起退款"按钮，和 AI 客服调用的是同一个动作，这正是本体的价值之一。

1.1 两种流派：本体做"大脑"，还是也做"肌肉"

在本体服务层要不要自己执行事务这件事上，业内有两种主张：

示例商城选择语义中枢型：业务数据留在原系统，本体保存语义、映射和轻量索引，动作最终通过售后系统和支付网关的接口落地。

1.2 一次请求穿过六层

用第 03 篇那句"外套不要了，退到原卡"走一遍，看每一层各做了什么：

注意两点：一是身份从入口层一路传下去，每一层都知道"这是在替谁办事"；二是判断集中在本体服务层，智能体层只负责理解和组织语言，不自己判断"能不能退"。

1.3 本体服务层里面有什么

本体服务层是整个系统的核心，内部通常包含六个组件：

1.4 本体不必换数据库：逻辑层与查询改写

很多团队一听"本体"，第一反应是"是不是要上图数据库，把数据搬一遍"。不一定。1.1 节说的"语义中枢"路线里，本体就是一层逻辑模型：它定义"客户""订单行""售后单"是什么，再说明每个概念在现有数据里由哪些表、字段实现。数据留在原处，查询时再翻译过去。

这条路有成熟的标准和理论基础：

• 映射标准 R2RML：W3C 在 2012 年发布的推荐标准，用来描述关系数据库里的表、视图或一段 SQL 查询，怎样映射成本体里的对象、属性和关系。规范特别说明，映射是概念性的：实现方既可以把结果物化成一份数据，也可以提供虚拟访问，在查询时再去查底层数据库。规范里还有一个很实用的例子：用 SQL 的 CASE 语句把数据库里的代码翻译成有意义的标识——示例商城把 status=5 翻译成"待退款"，用的就是同一种办法。
• 基于本体的数据访问（OBDA，Ontology-Based Data Access）：用户和 Agent 按概念模型提问，系统借助映射把问题改写成对底层数据库的 SQL。开源系统 Ontop 是一个典型实现，它把这种做法称为"虚拟知识图谱"：数据留在数据源里，面向图的 SPARQL 查询被翻译成 SQL，交给关系数据库执行。按其官方文档，它支持 R2RML 映射和 OWL 2 QL 本体，可以连接 PostgreSQL、Oracle、Snowflake、BigQuery 等多种数据库。
• 为"可改写"做的取舍：OWL 2 QL：OWL 2 规范定义了几个"剖面"（Profile，即为效率裁剪过的子语言）。其中 OWL 2 QL 以 DL-Lite 描述逻辑为基础，设计目标是让存放在普通关系数据库里的数据，可以通过简单的改写机制、在不改动数据的前提下经由本体查询。代价是表达能力受限：传递属性、属性链、基数限制、"两个个体是同一个"这样的断言都不支持；但它保留了 UML 类图、ER 图里大多数常用的建模特征。换句话说，它有意放弃一部分推理能力，换来"语义查询最终能高效落到数据库上执行"。

放到示例商城看一个例子。Agent 想知道"客户 C-88 有哪些处理中的售后单"。在本体里，这只是沿着"客户—下单→订单—包含→订单行—被申请→售后单"走一遍，再筛选状态属于"处理中"。映射负责告诉系统：客户对应账号表（取归并后的客户编号），订单行对应 order_item，售后单对应 refund_apply，"处理中"对应几个状态码。查询改写后得到一条带几次连接的 SQL，交给订单库的只读副本执行。售后单的映射写成 R2RML，大致是这样（示意，省略了前缀声明）：

# 示意：把售后申请表映射成"售后单"
<#AfterSaleCaseMap>
  rr:logicalTable [ rr:tableName "refund_apply" ] ;
  rr:subjectMap [
    rr:template "https://shop.example/after-sale/{id}" ;
    rr:class shop:AfterSaleCase
  ] ;
  rr:predicateObjectMap [
    rr:predicate shop:forOrderLine ;
    rr:objectMap [ rr:template "https://shop.example/order-line/{order_item_id}" ]
  ] .

实际项目里，你不一定要用 R2RML 和 SPARQL；很多平台用自己的映射格式和查询接口。但"概念—映射—改写—执行"这四步是共通的。虚拟化和物化也不是二选一：

这就是本体与 SQL 的分工：本体解释世界，SQL 负责计算。本体决定"问的是什么、谁能看什么、沿哪条关系走"，数据库负责把数算对、算快。动作（写操作）不走这条路，仍按第 2 节通过业务系统的接口执行。

1.5 语义在上游，产品语义在下游

很多企业其实已经有好几套"语义"：BI 里有一套指标，数据目录里有一套业务术语表，知识库里有一套概念，图数据库里有一套实体，Agent 的提示词里有一套上下文，API 又定义了一套对象。每一套都号称"单一事实来源"，结果一个企业里有五六个"单一事实来源"（第 08 篇反模式 20）。

更稳妥的架构是反过来：先有一份规范语义模型（Canonical Semantic Model），再从它生成多个技术投影（Multiple Projections）：给 BI 的指标定义、给 API 的数据结构、给 Agent 的工具说明、给图查询的模型、给人看的文档和自动测试。"定义一次、到处使用"真正难的不是定义一次，而是让所有系统都用同一份定义，而不是各自复制一份，再慢慢走样。

要做到这一点，这份上游模型至少需要六项能力：

小团队不必一开始就造一个"编译器"。最低限度的做法是：所有定义集中放在 1.3 节的模型仓库里；指标层、工具说明、文档在发布流程中从这里生成，或者至少和它自动比对；任何下游想新增一个概念，先回到模型仓库登记。这里讲的是原则，不是某个产品。有厂商文章把它概括为"语义在上游，产品语义在下游"，并借此介绍自家平台（见参考引用），读者取其思路即可。

2. Agent 怎样接入本体

2.1 MCP 是什么

MCP（模型上下文协议）是一种让 AI 应用以统一方式发现和调用外部工具与数据的开放协议。在它的规范里，服务端通过"列出工具"接口告诉客户端有哪些工具，每个工具有名称、说明和输入参数的结构定义（也可以声明输出结构）；客户端通过"调用工具"接口执行，执行出错时返回带错误标记的结果，供模型调整后重试。

规范对安全有明确要求：服务端必须校验所有输入、实施访问控制、对调用限流；客户端应当在敏感操作前向用户确认、记录工具调用以便审计；并且应当始终有人能够拒绝工具调用。规范还提醒，工具上声明的"只读""破坏性"等提示信息，除非来自可信的服务端，否则不应被信任。

2.2 工具设计的六条原则

原则一：暴露业务工具，不暴露原始查询语言。有工程实践者在 OWL 本体之上做数据 Agent 时发现，让模型直接拼写图查询语句很危险：在没有开启推理的情况下，查询"某类商品"可能静默漏掉它的子类，"语法正确、结果不完整"。他的做法是提供语义明确、参数化的高层函数，把"是否包含子类"这类细节封装在工具内部。

原则二：先发现，后调用。不要一次性把几十个工具的完整说明塞给模型。一种做法是"两级暴露"：先给一份轻量能力目录（工具编号、能力描述、涉及的对象类型、风险级别），模型选中后再查询该工具的详细参数和前置条件。

原则三：读写分离，标注风险。查询类工具和动作类工具分开，动作类再按风险分级。模型看到的风险标注只是提示，真正的拦截必须在服务端完成。

原则四：写操作两段式。先"试算/校验"（不产生任何修改，只返回是否通过、为什么），再"提交"。12306 对比实验里的本体工具组就包含"动作校验（干跑）"和"动作执行"两个独立工具。

原则五：返回结构化的理由。被拦截时，返回规则编号、级别和证据，而不是一句"失败"。这样模型能向用户解释，也能决定是否转人工。

原则六：工具不比人大。工具以"当前用户"的身份执行，权限由业务系统判断；接入层只负责把 Agent 用户映射到真实账号，不复制权限规则（见第 08 篇反模式 11）。

2.3 示例商城的工具清单

{
  "name": "validate_action",
  "description": "对本体中已定义的动作做干跑校验，不产生任何修改。返回是否通过、命中的规则编号与证据、是否需要审批。",
  "inputSchema": {
    "type": "object",
    "description": "按动作分支：不同动作的 target_id 含义和参数各不相同",
    "oneOf": [
      {
        "properties": {
          "action": { "const": "create_case" },
          "target_id": { "type": "string", "description": "订单行编号，例如 L-2" },
          "params": {
            "type": "object",
            "properties": {
              "case_type": { "type": "string", "enum": ["no_reason_return", "quality_return"] },
              "quantity": { "type": "integer", "minimum": 1 },
              "amount": { "type": "number", "multipleOf": 0.01, "description": "申请退款金额，单位元" }
            },
            "required": ["case_type", "quantity", "amount"]
          }
        }
      },
      {
        "properties": {
          "action": { "const": "initiate_refund" },
          "target_id": { "type": "string", "description": "售后单号，例如 AS-2045" },
          "params": {
            "type": "object",
            "properties": {
              "amount": { "type": "number", "multipleOf": 0.01, "description": "退款金额，单位元" },
              "method": { "type": "string", "enum": ["original_route"] }
            },
            "required": ["amount", "method"]
          }
        }
      }
    ],
    "required": ["action", "target_id", "params"]
  }
}

上面只列了两个分支，"关闭工单"等其他动作同理各占一个分支。要点有三：一是 target_id 的含义随动作而变（创建售后单时是订单行，发起退款时是售后单），必须按动作分别写清；二是参数要有类型和单位，而不是一个笼统的 object；三是 submit_action 的参数与此相同，另加一个 request_id 作为幂等键——它在"决定办这件事"时生成一次，之后的重试都带同一个值。MCP 规范还允许为工具声明输出结构（outputSchema）和行为注解（如只读、破坏性等提示）；但规范同时要求，除非来自可信的服务端，客户端不应信任这些注解，真正的拦截仍在服务端完成。

注意 AI 客服在这里提交的是"创建售后单"，而不是"发起退款"：按第 07 篇的权限矩阵，它对"发起退款"只有建议权，submit_action 收到它提交的 initiate_refund 会直接按权限拦截。退款要等售后单审核通过、退货验收、进入"待退款"之后，由客服发起。比如客服小林在工作台上对售后单 AS-2045 发起 899 元退款时，validate_action 会返回"通过 R01；命中 R04 v2，需主管审批"，submit_action 之后动作实例进入"待审批"、参数冻结，主管老周批准后才经支付网关执行。

2.4 智能体层的三道判断

工具设计好了，智能体层自身也要守住分寸。一篇讨论意图识别的文章给出了一个清晰的分层：意图层回答"用户想做什么"，权限层判断"用户能不能这样做"，执行层确认"这个动作是否应该立即发生"。三者不能混为一谈，否则很容易把"理解成功"误当成"授权完成"。相应地，智能体每一轮都应在四种出口中选一个：执行、追问（缺参数或有歧义时）、拒识（超出范围时）、确认（高风险动作前）。

放到示例商城：客户说"把那件外套退了"，意图层识别为"申请退货退款"；本体解析出对应的订单行，权限层确认 AI 客服对"创建售后单"只有"申请"权（对"发起退款"只有建议权）；执行层判断这是会产生业务后果的动作，于是选择"确认"出口——先向客户复述要退的商品、数量和金额，客户确认后再提交申请。和本体配合时，意图和槽位最好直接映射到本体里的动作和参数类型，这样意图识别的结果可以原样交给干跑校验。

2.5 安全设计要点

把本体暴露给 Agent，等于开了一扇新的门。MCP 官方的安全最佳实践和 OWASP 的大模型安全清单里，有几条与本体系统直接相关：

代表谁：三种身份要分清。同一个能力暴露层可能同时服务三类调用。一是面向客户的 AI 客服"小售"，它代表已登录的客户（如会员 C-88），只能看这位客户自己的订单，只能以客户名义提交申请。二是面向员工的助手，例如客服小林工作台上的助手，它代表员工，按员工的角色和数据范围行事。三是 Agent 应用自身的身份（如"小售"这个应用），用于限流、审计和区分是哪个应用在调用。一次调用的实际权限，是"被代表的用户能做的"和"这个应用被允许做的"两者的交集：客户本人可以申请售后，但"小售"应用对"发起退款"只有建议权，所以它不能替客户提交退款。RFC 8693 把这种情况称为"委托"：新令牌的主体是用户，代理方（actor）另行记录，审计时两者都能查到。

2.6 可观测与审计

出了问题时，要能回答"Agent 为什么这样做"。建议每次工具调用至少记录这些字段：

这些记录有三个用途：排查问题、做影子模式对比、在审计时还原决策过程。注意日志本身也包含敏感信息，要设置访问权限和保留期限。

2.7 工具说明怎么写

工具说明是 Agent 在运行时读到的"操作手册"，写得好不好直接影响它选对工具、填对参数。一位作者把它概括为"工具说明是 Agent 的运行时知识"。比较一下同一个工具的两种写法：

写工具说明的几条经验：

• 说清楚参数用的是哪种编号。"客户 ID"可能是会员号、小程序编号或手机号，必须写明，并提示"不确定时先调用 resolve_customer"。
• 说清楚调用顺序。例如"先干跑、后提交"，"先解析对象、后查询详情"。
• 说清楚结果的几种可能。成功、需审批、被拦截、需人工，各自返回什么。
• 说清楚不能做什么。明确写出边界，能减少模型"试探性"调用。
• 与本体定义同源生成。工具说明里的对象名、属性名、枚举值都应从本体定义自动生成，避免两边不一致。

2.8 平台里的现成做法

商业平台已经在提供类似能力。Palantir 的 Ontology MCP 把应用范围内的对象类型、动作类型和查询函数暴露为 MCP 工具，外部 Agent 可以读取对象、执行预先定义的动作、调用查询函数，并受应用层面的范围限制；它与另一个面向开发者、用于搭建和修改本体结构的 Palantir MCP 是两回事。Palantir 文档还展示过一种配置：让 AI 提出的修改只是"暂存"，由人审查后才生效，并记录决策的来龙去脉——这是可以选择的配置方式，并不是所有场景的默认行为。微软 Fabric IQ 的本体也把"供 AI Agent 使用同一套业务词汇"作为主要目标之一（目前为预览版）。

3. 选型

选型时建议回答六个问题：

1. 需要写回和业务动作，还是以只读分析为主？
2. 现有数据主要在哪个平台？能否就近建设？
3. 是否有私有化部署、数据不出境、完全离线的要求？
4. 团队熟悉的是 SQL、图查询还是语义网技术？
5. 预算和持续运维能力如何？
6. 将来想换平台时，本体定义能否导出？（尽量让本体定义以文本形式保存在版本库里）

对示例商城这样的场景，一条务实的路线是：先用自研薄层（YAML 定义本体、规则表、少量 MCP 工具）跑通退货退款闭环，验证价值和团队能力之后，再决定是否迁移到商业平台。

3.1 演练：示例商城的打分表

把六个问题变成可打分的维度，按业务需要设权重。下面是一次演练性质的打分（满分 5 分，分数代表"与示例商城需求的匹配度"，不是对产品的客观评价）：

按权重计算，自研薄层在这个演练中得分最高。但请注意：打分的前提是示例商城有工程团队、有可用接口、范围小。换一家系统老旧、团队薄弱的公司，结论可能完全相反。打分表的价值不在分数，而在于逼着团队把"我们最在意什么"说清楚。另外，这张表没有单列"上线周期"和"持续运维负担"：自研薄层起步快，但动作引擎、审计、权限对接都要自己长期维护；商业平台起步慢、运维多由厂商承担。如果这两项对你很重要，应当加进来重新算。

3.2 概念验证怎么做

不论选哪条路线，正式投入前都应做一次概念验证。建议把它设计成一次"用能力问题考试"：

1. 准备考题：从第 06 篇的能力问题里挑 8 到 10 个，覆盖查询、判断、动作三类，每题准备标准答案。
2. 准备考场：用脱敏的真实数据，至少包含身份重复、部分退款、遗留状态码这些"脏"情况。
3. 考三件事：答案对不对（结果正确率）、过程对不对（工具和参数是否正确、是否越权）、改起来难不难（现场改一条规则，例如把审批阈值从 500 改成 800，看需要多久、影响哪些地方）。
4. 看非功能：查询耗时、并发表现、日志是否完整。
5. 写结论：哪些能力问题过了、哪些没过、没过的原因是平台限制还是建模问题。

第 3 点里的"现场改规则"特别能看出差别：有的方案改一条配置即可，有的需要改代码、重新部署。

4. 路线图

扩展阶段有一个值得提前规划的结构：把客户、商品、订单这些跨场景共用的定义放在公共核心模型（注意它不是第 05 篇说的指标语义层），售后、营销、风控等场景应用只声明自己需要用到哪些对象、关系、工具和权限。这样新场景接入时复用而不是复制。

4.1 每个阶段最容易出的问题

5. 非功能要求清单

6. 常见问题

问：一定要用 MCP 吗？

不一定。MCP 的好处是标准化，同一套工具可以被不同的 Agent 框架和客户端使用。如果你的 Agent 只在一个内部框架里运行，用普通的函数调用或内部接口也可以。关键是本篇第 2.2 节的那些设计原则，而不是协议本身。

问：本体服务会不会成为性能瓶颈？

如果交易数据都实时回源查询，确实会增加延迟。常见的缓解办法是：主数据和关系建索引，交易数据只按主键查询，并对热点查询做短时缓存。对客服场景来说，正确性通常比几百毫秒的延迟更重要。

问：本体服务层和业务中台是什么关系？

可以互补。业务中台提供可复用的业务服务（如统一的退款服务），本体在其上提供统一的语义、规则和面向 Agent 的动作入口。如果中台的服务已经很规范，本体的动作可以直接编排中台服务。

问：本体服务出故障时，客服还能工作吗？

应该能。设计时就要保留"降级通道"：本体服务不可用时，AI 客服停止办理动作、只做安抚和转人工；客服工作台退回到原有业务系统的操作界面。等服务恢复后，再核对故障期间人工办理的单据，必要时补录审计记录。

问：要不要一开始就支持多个 Agent？

不必。先服务好一个 Agent 和一个人工入口（如客服工作台），证明"人和 Agent 用同一套动作"可行。多 Agent 接入时，主要的新增工作是为每个 Agent 应用单独注册、单独授权和单独记录日志。

本篇要点

• 六层架构：入口、智能体、能力暴露、本体服务、数据接入、源系统；人和 Agent 调用同一套动作。
• 本体可以只做语义中枢，也可以自持数据并执行；已有成熟业务系统的企业通常选前者。
• 本体可以是数仓之上的逻辑层：用 R2RML 一类映射指向现有表，按基于本体的数据访问（OBDA）的思路把语义查询改写成 SQL；OWL 2 QL 为此有意牺牲部分表达能力。本体解释世界，SQL 负责计算。
• 语义在上游，产品语义在下游：一份规范语义模型具备稳定身份、可执行定义、物理映射、关系一等公民、指标同体系、多技术投影六项能力，再投影给 BI、API、Agent 和文档。
• 通过 MCP 接入时：暴露业务工具而非原始查询、先发现后调用、读写分离、写操作两段式、返回结构化理由、工具不比人大。
• 选型从写回需求、现有数据平台、部署要求、团队技能、预算和可迁移性六方面判断；可先用自研薄层验证。
• 路线图按准备、只读、建议、有限执行、扩展五个阶段推进，每阶段都有明确的进入条件；本体服务层内部可拆为模型仓库、查询、规则、动作、索引、审计六个组件。
• 安全上不做令牌透传，而是通过令牌交换代表用户调用，并分清客户、员工和应用三种身份；权限范围最小化、每个请求都校验身份、授权由下游完全中介；每次工具调用都留下可还原决策的日志。
• 概念验证应当是一场"能力问题考试"：考结果、考过程、考修改成本。

参考引用

1. 《Model Context Protocol Specification: Tools（2025-11-25 版）》，Model Context Protocol 官方规范。原文
2. 《Model Context Protocol Specification: Security Best Practices（2025-11-25 版）》，Model Context Protocol 官方规范。原文
3. 《LLM06:2025 Excessive Agency》，OWASP Gen AI Security Project。原文
4. 《Ontology MCP (OMCP): Overview》，Palantir Foundry 官方文档。原文
5. 《Why create an Ontology?》，Palantir Foundry 官方文档。原文
6. 《Ontology building: Overview》，Palantir Foundry 官方文档。原文
7. 《What is ontology (preview)? — Microsoft Fabric IQ》，Microsoft Learn。原文
8. 《Cube MCP Server》，Cube 官方文档（经本项目调研报告收录）。原文
9. 《neo4j/mcp》，Neo4j 官方 GitHub（经本项目调研报告收录）。原文
10. 《一文读懂怎么让 Agent 理解业务，别一上手就写 Prompt！》，陈思州 Datawhale。Cubox，原文
11. 《AI FDE 从一句话到运行系统：本体平台背后的真实架构》，OntoFlow本体平台 AbutionGraph。Cubox，原文
12. 《什么是Palantir本体论？不难理解，在12306买一次车票就懂了》，月夜烛峰。Cubox，原文
13. 《Palantir平替-“平民级”本体应用开发平台：4个步骤完成交付》，OntoOS-本体智能 AbutionGraph。Cubox，原文
14. 《Ontology（本体）Part 3：Ontology (OWL) 驱动的数据分析智能体设计与实战》，Fan 技术与艺术认知。Cubox，原文
15. 《LLM Wiki + Ontology：让企业知识从“可检索”走向“可行动”》，划小船。Cubox，原文
16. 《分享一个Ontology本体论的AI实操演示，从实际业务看懂本体价值》，月夜烛峰。Cubox，原文
17. 《WorkBuddy+金蝶云星空落地一席谈：权限怎么管》，老丁 老丁AI。Cubox，原文
18. 《我做了一套本体Ontology工程系统，让Agent能读懂企业数据》，windom Yu 硅基斥候S01。Cubox，原文
19. 《分享一个 AI 本体智能应用开发平台设计方案》，月夜烛峰。Cubox，原文
20. 《自称开源版 Palantir：一张图让每个 AI 决策都查得到来龙去脉》，AhaAaron Hey AI Coder。Cubox，原文
21. 《RFC 8693: OAuth 2.0 Token Exchange》，IETF，2020。原文
22. 《R2RML: RDB to RDF Mapping Language》，W3C Recommendation，2012-09-27。原文
23. 《OWL 2 Web Ontology Language Profiles (Second Edition)》，W3C Recommendation，2012-12-11。原文
24. 《Ontop Guide: Introduction》，Ontop 项目官方文档（自由大学博尔扎诺与 Ontopic 支持）。原文
25. 《企业AI真正缺的不是 SQL，而是Semantic Layer》，本体论应用 AbutionGraph（厂商文章：作者团队开发 OntoFlow 等本体产品，文中观点带有产品立场）。Cubox，原文