Data Agent技术介绍（下）

技术干货 · 共四个阶段本文为系列下篇涵盖阶段三从 Skill 到本体语义层与阶段四团队技术进展。上篇已介绍阶段一语义层接入探索与阶段二从查数到决策。系列上篇在这里Data Agent 技术介绍上在上篇中我们介绍了指标语义层如何解决查得准的问题以及 Skill 体系如何让 Agent 从查数走向决策。然而随着 Skill 数量的增长一个更深层的问题浮出水面当业务规则散落在数十个 Skill 的 Prompt 中时谁来保证这些规则的一致性本文将从 Skill 体系的边界出发深入探讨本体化语义层的必要性——它不仅是语义层的升级更是 Agent 从能干活走向值得信赖的关键一跃。阶段三从 Skill 到本体语义层1、Skill 能力边界为什么会查数不等于懂业务阶段二中我们通过 Skill 让 Agent 从初级分析师走到了策略师。Agent 能做异常检测、趋势预测、四象限诊断甚至能给出最后的决策建议。但这里有一个不能回避的问题Skill 的天花板本质上是它能拿到什么材料。如果把Data Agent比作一个医生Skill相当于诊断流程望闻问切 → 开处方语义层相当于化验报告。如果化验报告本身——指标口径、维度关系、业务规则——散落在各个Skill的Prompt里各自维护那么同一个销售额metric-query用的口径和inventory-strategy用的口径可能不一致新增一个渠道要同时改5个Skill的Prompt业务规则如到店超过1000天的商品算滞销只在某个Skill里硬编码换一个Skill就不知道。Skill越做越多口径管理和知识复用就会越来越重要。这便是从Skill探索自然走向本体语义层的动因。2、两类语义层指标语义层 vs 本体化语义层今天行业里都在讲语义层但大家讲的并不是同一件事。我们可以将语义层分为两类2.1 指标语义层阶段一、二所用核心问题这个数到底怎么算以指标、维度、口径为核心单位。解决的是销售额含不含税、退不退货新客按注册还是按首单算华东区包含哪些省市同比对齐到哪个时间窗口。优势对于标准化、高频的问数场景统一口径、固定报表、管理驾驶舱投入产出比极高。阶段一的NL→MQL→SQL链路和阶段二的六个Skill本质上都建立在指标语义层之上。边界当问题从看什么走到为什么指标语义层开始吃力。例如问为什么华东区女装销售额下降系统需要知道销售发生在什么业务事件里下单、退款还是缺货女装是产品对象上的哪层分类属性销售额下降是订单量下降、客单价下降还是退款/折扣/渠道变化造成的哪些对象和事件值得继续被追问。这些内容单靠指标公式是表达不出来的。2.2 本体化语义层核心问题这个数背后的业务世界是什么样的以对象、事件、关系、规则为核心单位。它的主张是企业不是由一堆指标组成的而是由对象、事件和关系构成的业务世界。客户、订单、商品、门店、渠道、仓库、组织——是对象下单、支付、发货、签收、退款、入库、出库——是事件客户下订单、订单包含商品、商品参与活动、活动投放于渠道——是关系事件改变对象状态状态影响指标指标反映运行结果。指标语义层回答了这个数怎么算本体化语义层还要回答这个数对应的是哪个业务事实这些事实涉及哪些对象和关系某个变化是沿哪条业务链路传导出来的如果往下分析该看哪些对象、哪些事件、哪些规则。2.3 六维对比维度指标语义层本体化语义层建模单位指标、维度、口径对象、事件、关系、规则表达能力聚合分析聚合分析 跨对象筛选 事件链路 状态变化 动态分组问题覆盖标准化问数问数 → 归因 → 解释 → 建议 → 动作系统可解释性这个指标怎么算出来的为什么是这些对象和事件共同导致了这个结果维护重心指标池、维度池、公式、别名映射业务对象建模、事件链路、关系网、规则显性化天花板取决于能把多少问题收敛成指标表达取决于能把业务世界表达得多完整关键认知本体化语义层不是不要指标层而是把指标层纳入更大的业务世界表达中。指标仍然重要口径仍然要统一只是它们不再是语义层的全部。3、为什么本体化语义层是 Agent 时代的数据基建新地基3.1 行业共识2026年主流厂商的路线殊途同归厂商动作微软 Fabric IQ将 Ontology 作为 Fabric 预览能力entity/property/relationship 与数据资产绑定Snowflake Cortex Analyst强调 Semantic ViewsDatabricks Genie要求领域专家维护 datasets、sample queries、text guidelines、knowledge storedbt Semantic Layer继续把指标定义、semantic graph、MetricFlow 往统一语义层推进Google Looker把 Looker semantic layer 通过 MCP 接给 Gemini CLI 和其他 Agent方向一致大模型要进入企业数据生产不能只靠模型自己猜模型之外必须有一层机器可读、可治理、可复用的业务语义基座。3.2 传统数仓为什么能用因为人在替系统补洞过去十几年分析师靠经验知道哪个表是月结口径业务同学靠默契知道新客默认按首单算。人是会脑补的隐性知识填补了系统的语义缺失。但 Agent 不会继承这些默契。如果系统没告诉它某字段虽叫amount却已扣过退款、某宽表只能用于日报不能用于月结、某客户标签市场部能用风控部门不能用——Agent就会在这些缺口上产生幻觉。3.3 只做 Prompt 和 Harness本质上是在用胶带修地基很多项目的做法Schema扔进去 → 补一段Prompt → 答错了继续加Prompt → 某部门口径特殊再加规则 → 角色权限不同再加约束。短期Demo能跑长期生产大概率失控。因为Prompt和Harness解决的是过程控制你应该怎么做但解决不了输入材料本身对不对。3.4 本体化语义层真正解决的Agent 的世界模型当对象、事件、关系、规则被显性化以后Agent拿到的就不再是一堆表和字段而是一套业务世界的地图。这张地图的价值降低幻觉源材料本身更明确、更可信、更结构化。收敛推理空间模型在已定义的对象、关系、指标、权限和动作空间里做规划不用在无限Schema里乱猜。支撑角色差异财务、运营、销售需要不同口径、不同路径、不同权限放进语义模型里比写进超长Prompt更可维护。支持归因与行动只看指标只能回答掉了多少理解对象和事件才能回答为什么掉、影响了谁、下一步能做什么。与RBAC、审计、数据血缘形成工程闭环每次回答都可追溯到哪些对象、哪些关系、哪些指标、哪些权限约束。4、技术路线的演进NL2SQL → NL2MQL2SQL → NL2LF2SQL直接让模型在复杂Schema上生成SQLNL2SQL一旦Schema变大、Join变多、口径变杂准确率和稳定性会急剧下降。阶段一我们走的NL2MQL2SQL指标语义层方案是在中间加一层MQL抽象——LLM负责将自然语言转为指标查询描述MQL确定性引擎再把MQL编译成SQL。这一跳已经大幅提升了稳定性但它仍然以指标维度条件时间为表达单元难以表达对象关系和事件链路。本体化语义层的技术路线进一步升级为NL2LF2SQL关键设计把语言理解和结构化执行拆开。模型负责意图理解语义层负责约束和映射引擎负责稳定翻译。一旦结果不对企业能知道错在意图理解、语义映射、指标口径、Join路径还是底层数据质量——而不是面对一个也不知道为什么错的黑盒。5、企业落地的现实路径不建议一上来就搞全集团、全域、全流程的超级本体工程。更现实的路径是从一个高价值业务域切入第一步梳理领域内的核心对象、事件、关系和指标销售经营域客户、订单、商品、活动、渠道、组织是对象下单、支付、发货、退款是事件GMV、毛利、复购率、客单价是指标。明确财务/运营/销售分别用什么口径哪些数据能看哪些不能看。第二步沉淀成可维护的语义模型表字段和业务概念绑定指标公式和口径版本化。对象关系显性化角色权限联动。关键业务规则能被查询链路和Agent运行时读取。第三步建立中间逻辑表达Logical Form让模型先把问题翻译成可检查的业务逻辑表达再由确定性引擎映射到查询和动作。第四步建立评估体系沉淀黄金问题集、标准答案、典型追问、异常样例和回归测试。参考Snowflake verified examples、Databricks Inspect的做法。第五步在可信语义基座上接入Harness工程Plan、Tool Calling、MCP、Skill、Prompt、Guardrail——这些站在可靠材料上才能真正发挥作用。6、三层架构总览结合阶段一到阶段三的探索Data Agent的完整架构演化为7、一句话总结指标语义层让AI会查数本体化语义层让AI开始理解业务。Skill将领域认知编码为可执行方法论但若没有本体化语义层作为统一的事实基座Skill体系迟早会陷入口径分散、规则重复、知识不可复用的维护黑洞。从Skill到本体语义层不是换一个更高级的词而是让Agent从能干活走向值得信赖。团队技术进展已上线模块状态说明指标语义层版 Data Agent✅ 已上线阶段一的 NL→MQL→SQL 全链路已在生产环境运行支持智能问数、口径统一、权限校验、结果可解释Skill 体系✅ 已上线查数、归因、异常检测、趋势预测、分析报告、定时调度等 Skill 已在实际业务中投入使用本体化语义平台✅ 已上线对象模型、事件模型、关系模型、规则引擎等核心能力已完成搭建支持 Logical Form 中间表达与确定性映射进行中渐进式演进路线当前团队正推进一条渐进式演进路线而非一次性推倒重来核心思路已将本体化语义平台作为新地基搭建完成。后续业务规则的表达逐步从 Skill Prompt 迁移到本体语义层。今天部分规则写在 Skill 的 Prompt 里部分硬编码在代码里明天业务规则逐步收敛到本体化语义层中的规则模型Skill 变为编排器不再自己携带口径最终Skill 本身被大幅简化甚至消解语义层从查数接口升级为 Agent 可直接理解的业务世界模型不是一夜之间停掉 Skill、切换本体层。而是让本体层先把 Skill 里的领域知识吃进去——每收敛一条规则Skill 就轻一点每建模一类关系Agent 就准一点。最终状态是本体的归本体、编排的归编排、执行的归执行各层职责清晰、不再互相补洞。