Agent 数据架构新范式：Skill + 语义层 + 知识库，让企业 Agent 真正落地
从数据架构角度出发，结合 Skill、语义层和知识库，解决 Agent 落地中的指标口径、实时数据和权限等卡点。
Agent 数据架构新范式：Skill + 语义层 + 知识库，让企业 Agent 真正落地
从数据架构角度出发，结合 Skill、语义层和知识库，解决 Agent 落地中的指标口径、实时数据和权限等卡点。
企业 Agent 从 Demo 到生产，数据架构是关键瓶颈。本文深入剖析 Agent 数据架构新范式，围绕 Skill、语义层和知识库三大支柱，解决指标口径不一致、实时数据接入难、权限控制复杂等核心问题。结合腾讯、Datastrato、OceanBase 等实践，提供从元数据治理到语义层建设的完整方法论，并探讨 Apache Ossie 等开放标准。适合正在构建企业级 Agent 的数据工程师和架构师。
引言：Agent 落地的数据之痛
过去两年，企业 AI 从“要不要做”快速演进到“为什么大多数还做不好”。当 AI Agent 开始进入核心业务，仅仅“能调用数据”已经不够——指标口径混乱、实时数据滞后、权限管控缺失，让 Agent 的准确率长期卡在 70% 左右，而业务方普遍要求 95% 以上的生产可用线。
问题不在模型，而在数据架构。传统数据系统默认使用者是人——人登录 BI、人提交工单、人上班八小时。而 Agent 不登录、不走审批、7×24 小时高频请求，为“人”设计的口径、权限与治理边界正在一项项失效。
本文提出的新范式围绕三个核心支柱：Skill（技能）、语义层（Semantic Layer） 和 知识库（Knowledge Base）。三者协同，让 Agent 不仅能“取到数”，更能“理解业务含义”并“安全合规地执行任务”。
一、Agent 数据架构的三大卡点
1.1 指标口径不一致
同一个“收入”指标，在不同系统中可能对应不同计算逻辑：
sql
-- 订单金额（含税）
SELECT SUM(order_amount) FROM orders WHERE status = 'paid';-- 实收金额（扣除退款）
SELECT SUM(paid_amount - refund_amount) FROM orders;
-- 财务口径（按确认收入）
SELECT SUM(revenue) FROM finance WHERE period = '2026-01';
Agent 在缺乏语义层时，只能根据字段名猜测，极易产生“语法正确但业务错误”的查询。
1.2 实时数据接入难
传统数仓以 T+1 为主，而 Agent 需要实时或近实时数据。以电商场景为例，Agent 回答“当前库存能否支持大促”时，需要秒级响应的实时库存数据，而非昨天的快照。
1.3 权限与安全失控
对人而言，“读一行”和“全表扫描”是同一个读权限；但对 Agent，这两种操作的敏感度截然不同。Agent 还可能因工具调用不当，意外暴露敏感字段。
二、新范式三大支柱详解
2.1 Skill：将数据能力封装为可复用模块
Skill 是 Agent 执行具体数据任务的原子能力单元。它将数据查询、分析、报告等操作封装为标准化模块，包含：
例如，一个“查询销售额”的 Skill 可以定义为：
yaml
name: get_revenue
description: 按时间范围查询公司总收入
parameters:
- name: start_date
type: date
- name: end_date
type: date
- name: region
type: string
optional: true
sql: |
SELECT SUM(revenue) FROM finance
WHERE date BETWEEN :start_date AND :end_date
{% if region %} AND region = :region {% endif %}
output:
type: number
unit: 万元
auth:
required_permission: read_finance
Skill 的核心价值在于：
2.2 语义层：将业务语言翻译为机器可执行逻辑
语义层是连接业务用户与物理数据的桥梁。它通过统一的指标、维度和关系定义，消除口径歧义。
当前业界关注的一个重要项目是 Apache Ossie（Incubating），它由 Snowflake 捐赠给 Apache 基金会，旨在标准化语义模型的交换格式。Ossie 的核心模型包括：
一个典型的 Ossie 语义模型片段：
yaml
semantic_model:
datasets:
- name: orders
source:
type: table
table: prod.orders
fields:
- name: order_amount
type: decimal
ai_context:
synonyms: ["订单金额", "销售额", "营收"]
instructions: "此为含税金额，不含退款"
metrics:
- name: total_revenue
expression: "SUM(order_amount)"
dataset: orders
语义层带来的直接收益：
2.3 知识库：存储业务规则与领域知识
知识库不同于语义层，它存储的是非结构化的业务规则、历史决策、异常处理方案等。例如：
知识库与语义层的关系：
三、架构设计与实践
3.1 整体架构
+-------------------+ +------------------+ +------------------+
用户/Agent --> Agent 编排层 --> Skill 注册中心 3.2 从 Demo 到生产的六轮收敛
参考 Datastrato 在客户现场的实践，Agent 数据架构需要经过六轮迭代：
3.3 实时数据接入
Agent 需要实时数据时，可通过流处理引擎（如 Flink）将实时数据写入 OLAP 系统（如 ClickHouse），并在语义层中标记数据时效性。
yaml
dataset:
- name: realtime_inventory
source:
type: kafka
topic: inventory_updates
freshness: 5s # 数据延迟不超过5秒
fields:
- name: sku
- name: stock_qty
3.4 权限与安全
Agent 权限模型需支持：
四、开放标准与生态
4.1 Apache Ossie：语义层的“Apache 时刻”
Ossie 当前完成的是结构互操作——不同系统可以读写同一份语义模型，但尚未解决概念互操作（不同名称描述同一概念）。其路线图计划增加本体层，定义 Customer、Order 等规范业务概念。
对于企业，Ossie 的价值在于：
4.2 与现有系统的集成
五、落地建议
六、总结
Agent 数据架构新范式的核心，是从“engine centric”转向“metadata centric”。Skill、语义层和知识库三者协同，让 Agent 从“能取数”进化到“懂业务”。
未来，随着 Apache Ossie 等开放标准的成熟，企业将能够构建跨平台、可治理、高可信的 Agent 数据底座。想深入了解 Agent 与多智能体系统，可参考 AI Agent 与多智能体；关于语义层与 RAG 的结合，可阅读 RAG 技术深度解析。
FAQ
Q1: 语义层和知识库有什么区别？ 语义层存储结构化指标、维度和关系，用于消除口径歧义；知识库存储非结构化业务规则和上下文，通过 RAG 检索。两者互补，语义层保证查询正确性，知识库提供业务背景。
Q2: 小团队有必要引入 Apache Ossie 吗？ 如果团队只有单一数据平台（如 Snowflake），Ossie 的互操作优势不明显。但若涉及多个工具（dbt + Looker + Agent），Ossie 可作为中间格式减少适配成本。建议从 YAML 定义语义模型开始，未来再迁移到 Ossie。
Q3: Agent 的实时数据需求如何满足？ 通过流处理（Flink/Kafka）将实时数据写入 OLAP 引擎，并在语义层标记数据时效性。Agent 根据任务类型（实时查询 vs 历史分析）路由到不同数据源。注意实时数据需额外的权限和审计控制。
相关教程
系统拆解 Harness 的概念、架构、与模型的关系，以及如何通过 Harness 实现 Agent 的自进化与可控执行
对比上下文工程、RAG、记忆框架的优劣，并介绍记忆工程的最新实践
从模型驱动到数据与语义驱动，构建企业 AI 落地的核心基础设施
系统讲解 Harness 工程的核心概念、设计模式与自进化机制，帮助读者从模型之外的角度提升 Agent 稳定性与能力上限。
深入解析多智能体系统的编排、记忆共享、冲突解决与安全防护，提供可落地的架构方案
对比主流AI编程工具，剖析架构、Harness、循环工程与企业落地经验