语义层 on DataAgentX

Data Agent 周报｜从 DACon26 看落地难题

Sun, 25 Oct 2026 00:00:00 +0000

覆盖北京时间 2026 年 10 月 18—24 日。本期重点是从 DACon26 北京站的 19 场分享中提炼六个工程问题，其余进展按产品与开源分类整理。

10 月 23—24 日，DataFun 主办 DACon26 北京站。下面的六个问题是从相关官方议题中归纳的，文中的点评为编辑技术分析，代表分享使用简题，完整官方题目与讲者见文末来源中的 DataFun 官方议程链接。

六个工程问题

① 模型运行：网关、路由与缓存

PPIO、敦煌网、LMCache 分别讨论网关、路由和缓存。三者的共同点是：模型不再是单次调用，而是一个需要调度、复用和成本控制的运行层。

选型要看完整任务的质量与成本，而不是单次推理的延迟。

② 企业语义：指标、业务对象与评测

蚂蚁、360、OceanBase 连接指标、业务对象与评测。语义资产既要能执行，也要持续维护——这两件事的难度不同，前者靠工程，后者靠归属。

③ 数据底座：从平台升级到研发交付

高德、OPPO、得物把数据平台的能力延伸到研发与分析交付。底座的价值不在于多存了多少数据，而在于能否支撑从发现问题到交付结果的全流程。

④ 数字员工：运行、协作与动作约束

阿里、腾讯、京东科技讨论 Agent 的运行、流程协作与动作约束。当 Agent 从“给建议”走向“执行动作”，约束机制的重要性超过能力本身。

⑤ 业务决策：洞察、研判与金融可信

快手、高德推进洞察与经营研判，蚂蚁、XTransfer 强调金融可信性。同一套技术，在金融场景里首先要回答的是“错了会怎样”。

⑥ 改进闭环：评测、错误定位与优化

高德、美团、润和软件连接评测、错误定位与优化手段。闭环的关键不是“能不能改”，而是“知不知道改哪里”。

我的判断

数据 Agent 落地，要把业务语义、执行边界和反馈循环接起来。

先找到失败发生在哪一环，再决定改知识、改工具，还是改模型。这个顺序很重要：如果失败来自语义缺失，换更强的模型只会让它更快地算错；如果失败来自权限设计，补知识也无济于事。

本周其他进展

腾讯云 DataBuddy 私有化版上线（10/19）

官方宣布支持私有化部署，以本体统一业务对象、指标和关系；通过脱敏与抽样沙箱验证数据任务。数据工程模块将接入、Schema 处理、清洗和作业编排封装为可组合 Skills。操作、资产、数据三层权限沿用用户身份，查询和执行保留审计记录。

yimindev DatI v0.9.0（10/23）

引入 schema_scope，将数据源授权、元数据发现和 MCP 暴露从整库细化到 Schema。list_tables 合并导入表和授权 Schema 中的物理表，按 Schema 与表名去重，导入元数据优先，并设置物理表发现数量上限。

Agent 语义层的 2W1H：为什么需要、是什么、怎么做

Fri, 23 Oct 2026 00:00:00 +0000

接上数据库、写出 SQL，Agent 就能答对业务问题了吗？

同样问“上季度收入是多少”，不同工具会给出不同答案：BI 可能把税费、运费算进去了，Notebook 可能没扣折扣和退货，财务按发货日确认，Agent 还在重新猜表之间怎么关联。

问题藏在“收入”两个字背后。本文基于堵俊平在 DACon 2026 的分享《开放语义、Ontology 与元数据：Agent Context 的三重支柱》整理。

Why：为什么需要语义层

Agent 需要知道三件事：收入怎么算、时间按哪一天、该连哪些表。

当它进一步参与决策和执行，还要知道当前用户有没有权限、操作需要满足什么条件。

把这些业务知识整理成能共享、可维护的上下文，才能减少每次从头猜测。这就是语义层的起点：不是给模型更多资料，而是给模型一个稳定的解释框架。

What：三重支柱分别解决什么

统一元数据

让 Agent 找到真实资产：数据在哪里、结构是什么、如何访问。

关键点是“不必把所有数据搬到一处”。元数据提供的是地图和通行证，而不是把地图上的东西都搬进一个房间。

开放语义层

把指标、维度、时间口径和关联定义统一起来，让 BI、应用与 Agent 使用经过确认的业务定义。

这是解决“收入口径不一致”的核心一层。它约束的不是数据形态，而是计算含义：分子分母是什么、时间按哪个字段、哪些 Join 合法。

Ontology

表达业务实体、关系和约束。比如“个人数据”包括邮箱和电话，再把这些概念连接到真实字段，检查权限与脱敏策略。

这一层的作用在权限和合规场景里最明显：当问题从“收入多少”变成“这个人的信息能不能给这个角色看”，需要的不是指标定义，而是概念之间的关系。

三者合起来，才构成较完整的 Agent Context。做收入分析和查个人数据，调用的上下文路径并不相同——这一点很重要：上下文不是一份静态文档，而是按任务组合的路径。

两条路径的对比

维度	收入分析	个人数据保护
起点	业务术语解释	业务域
主要依据	指标与维度定义	本体关系
落点	指标 → 资产 → 查询执行	概念 → 字段 → 权限与脱敏
关键约束	口径一致、时间口径	最小必要、可审计

同样一套底座，支撑两种完全不同的路径。这正是“共享”与“统一”的区别：共享底座，不意味着所有问题走同一条链。

How：怎么开始构建

分享给出的路径很务实：

先选一个高价值问题，比如收入分析。
业务与工程一起确认定义。
绑定真实资产。
用参考问题和不同角色验证。
确认可用后，发布成共享对象。
根据使用反馈修订。

场景帮助我们验证价值，共享底座让这些知识被下一个应用复用。

腾讯云 DataBuddy：Data Agent 的 RSI 初现

Tue, 20 Oct 2026 00:00:00 +0000

腾讯云 DataBuddy 团队在 DataFunTalk 视频号直播发布了新版 DataBuddy。资料未明确直播日期，本文于 2026 年 10 月 20 日整理。

最值得注意的是两点：DataBuddy 可以接入外部已有的数据源，而不只是腾讯云上的数据源；模型未来也可以接入自有 API，比如 Claude、ChatGPT 的模型。

本文基于发布会直播内容整理。厂商自述的准确率和上线周期未做独立评测，文中区分了发布信息与编辑判断。

四类任务

发布会把 DataBuddy 的能力分成四类：

类别	做什么
数据工程	从自然语言需求生成、编排数据管道
数据治理	巡检元数据、血缘、质量和安全
数据分析	对话取数、报表、看板和异动归因
数据科学	把数据准备接到模型训练与部署

前三类在 Data Agent 产品里比较常见。第四类值得单独注意：它把分析结果直接接到模型构建和线上服务，而不是停在看板和报告。

工程和治理之间还有一条迭代链：随着任务执行与治理变更，系统自动更新相关的数据血缘、Catalog 等信息，让数据上下文跟着实际工作持续更新，再服务后续任务。

发布会演示链路

演示围绕“经营怎么样、复购为什么弱、接下来做什么”展开，串起三段：

数据工程：构建 ETL 数据流，为分析和建模供数。
经营分析：配置经营报表，分析复购等业务问题。
数据科学：构建模型，部署线上推荐服务。

这个顺序说明了产品的定位：不是单点问答工具，而是把发现问题、验证假设和落地改进接在一条链上。

三块基石

Unity Semantics

用 Catalog、指标与维度、本体模型，把数据结构和业务口径连起来。

这与语义层建设的通用思路一致：元数据负责找到资产，语义层负责统一口径，本体负责表达关系和约束。

Agent Runtime

包括用户身份绑定、高危 SQL 拦截、行列权限、动态脱敏、沙箱隔离与审计。

安全能力的介绍值得关注，但不能等同于安全认证。评估时仍应设计冲突任务，观察系统是在计划阶段阻止、工具阶段拒绝，还是执行后才过滤。

OneOps

把 DataOps、MLOps、AIOps 接在同一底座，减少分析与模型开发之间的搬数和衔接。

这一块是“数据科学”能力的基础：如果分析和建模分属两套环境，改进点很难顺畅地走到线上。

两条接入路径

发布会给出两种方式：

直连已有 OLAP：接入企业现有数据系统，从分析切入，沿用原有存算。
迁入统一存算：覆盖更完整的四类任务。

这个选择本身反映了产品的现实定位：不是要求所有客户先做数据平台改造，而是允许从分析场景逐步进入。

Data Agent 周报｜国内外团队在补什么？

Sun, 18 Oct 2026 00:00:00 +0000

覆盖北京时间 2026 年 10 月 11—17 日。这一周先看 4 条国内动态，再看全球进展。

整理下来，10 条消息指向同一个方向：Data Agent 的竞争正在从“能不能回答”转向“能不能持续、可信地参与工作”。具体表现为应用可复用、上下文可继承、语义先于执行、验证内建在流程里。

国内：把分析路径变成可复用资产

01 阿里云 Quick BI：归因思路与作品复用（10/13）

v7.0.1 新增指标拆解树与拆解公式链，图表可保存自定义归因思路；AI 报表支持协同编辑，作品广场让报表、报告和 HTML 看板在组织内复用。

意义在于：分析路径可以随图表沉淀，业务团队能接着修改和使用 Agent 生成的作品，而不必每次从零开始。

02 衡石科技：沿现有看板继续分析（10/12）

Data Agent 沿当前看板的指标、筛选与时间范围继续追问，辅助图表和指标创作；查询、编辑、保存分别管理。

这类“看板上下文”的设计解决了一个具体问题：连续追问时，哪些指标与过滤条件被继承、替换或新增，必须明确。否则追问越多，口径漂移越远。

03 大应科技：业务语义先于执行（10/15）

Aloudata 作者提出，先整理指标、关系和计算规则，让 Agent 据此选择与组合；遇到口径缺口时准确反问。

文章以净销售额、财务收入、客户映射及订单关联为例，指出企业知识可能藏在历史 SQL 和报表中，需要整理成当前任务可用的上下文。面对支付、发货、财务确认等不同口径，Agent 应提出具体澄清，再据确定的规则执行。

04 yimindev：DatI 新增游客试用（10/14）

DatI v0.8.0 加入游客试用入口。项目用业务术语、元数据和参数化 SQL 工具，将数据库封装为 Agent 可调用的 MCP 服务。

降低试用门槛本身不构成能力突破，但它让“语义网关”这个配置路径更容易被评估。

全球：应用、验证与评测同时推进

05 Google Cloud：Looker Data Apps 进入 Preview（10/12）

Agent 生成的交互式应用进入 Looker 原生托管环境，复用 LookML 语义模型、行级安全和访问控制，用户可调参数、比较情景并触发下游工作流。生成后的交互没有运行时 LLM token 消耗。

Data Agent 怎么做：把 23 篇内容收成一张工作地图

Sun, 04 Oct 2026 00:00:00 +0000

看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。

这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。

下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。

一、先决定它接手哪类工作

企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。

不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。

二、正确答案从找对数据开始

SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。

数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。

三、七层架构服务于一个任务

一条完整链路可以概括为：

接入与路由找到相关、授权、足够的数据；
语义层绑定业务定义和关系；
规划与编排把目标变成可恢复状态机；
受控执行校验、授权并运行 SQL、代码和工具；
验证与评测检查来源、语义、程序、分析和交付；
治理与安全贯穿身份、策略、缓存、文件和动作；
交付与行动把声明、证据、制品、审批和反馈连接起来。

这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。

四、自治升级等于责任转移

L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。

同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。

五、公开榜单只能帮你找候选

Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。

最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。

产品案例应该变成检查问题

不同厂商案例最有价值的部分，不是功能名单，而是设计线索：

内部 Data Agent 提醒我们，数据发现和组织上下文可能比 SQL 生成更难；
Skills 模式说明分析经验可以变成可复用、可评审的工作协议；
云平台产品展示了数据、语义、身份和运行时如何复用现有控制面；
只读设计说明查询与业务动作应拥有不同权限边界；
多 Agent 架构只有在职责、上下文或权限需要隔离时才有意义。

把每条线索变成自己的 POC 问题，而不是照抄厂商架构。

DataBuddy 架构拆解：Agent 为什么需要一套数据底座

Tue, 29 Sep 2026 00:00:00 +0000

分析 Agent 算出“新增用户 12 万”，经营看板却显示 10.8 万。两边都能解释自己的 SQL，也都声称使用了最新数据。此时团队面对的并不是一次问答错误，而是一个更根本的问题：Agent 和传统数据产品是否建立在同一套资产、语义和权限之上？

这正是 DataBuddy 架构里最值得研究的部分。它表面上提供数据工程、数据分析和数据治理三类 Agent，底层设计却不是给三个聊天入口分别接工具，而是把数据接入、湖仓、Catalog、统一语义和 AI-Ready 知识组织成一条共享主链，再用 Agent Harness 把上下文、工具、安全和评估接起来。

如果只关注“三个 Agent 能做什么”，很容易错过这个产品真正的架构主张：先把数据平台改造成 Agent 可以理解、调用和约束的系统，再让 Agent 参与生产。

先读懂官方架构图

腾讯云 DataBuddy 产品架构图。图中 OLAP 引擎在 2026 年 8 月版本标注为规划中，实际可用范围应以当前产品控制台和文档为准。点击查看原图。来源：腾讯云产品文档

这张图可以沿两个方向阅读。

纵向是一条数据主链：多模态数据接入后进入湖仓和资产管理体系，经 Catalog、统一语义与知识加工，最终由 Agent 或看板消费。横向是两组贯穿能力：Agent Harness 负责上下文、记忆、工具、安全和评估，数据治理 Agent 则让标准、质量、元数据和权限不再只是后台配置。

图的上半部分是业务交付，中间是能力平台，底部是引擎与存储。它们不是三个彼此独立的产品层，而是同一次任务的不同责任边界。

数据主链：从“能接入”到“能被 Agent 正确使用”

企业数据通常散在数据库、消息系统、文件、日志和业务应用里。把数据同步到湖仓，只解决了可访问性，并没有解决可理解性。Agent 还需要知道表之间如何关联、字段代表什么、哪个指标定义被批准、某项资产是否新鲜，以及当前用户能否使用它。

DataBuddy 把这条加工链连续画出来：多模态集成、资产管理、统一语义、AI-Ready 数据知识，再到 Agent 与看板。这里的顺序很重要。

所谓 AI-Ready，不应该被理解为“把文档转成向量”这么简单。对数据任务而言，它至少包括四类对象：

结构知识：表、字段、血缘、分区、数据质量和更新状态；
业务知识：指标、维度、实体关系、同义词和适用范围；
执行知识：可信查询、工具参数、工作流和失败处理；
治理知识：所有者、权限、敏感级别、用途与审计要求。

只有这些对象能被检索、引用并约束执行，Agent 才不是在一堆 Schema 名称上猜答案。

Data Agent 如何真正读懂“客单价”

Mon, 28 Sep 2026 00:00:00 +0000

“近 30 天各品类的客单价是多少？”模型很容易写出语法正确的 SQL，也很容易在业务上完全错掉。客单价可能是支付金额除以支付订单数，也可能排除退款、按买家数计算，或者只看签收订单。

这不是 SQL 技巧问题，而是业务术语尚未绑定到可执行语义。

一个指标至少有五组约束

实体与人群定义谁被统计；分子和分母规定公式；时间说明事件时间、窗口和时区；粒度决定按订单、用户还是商品聚合；有效期和版本说明这套口径何时生效。

指标名只是入口，指标契约才是可执行对象。契约还应包含允许关联、默认过滤、空值处理、Owner、验证查询和已知例外。

为什么需要读取代码和元数据

数据开发代码包含真实的派生、过滤和关联逻辑，表元数据描述字段、分区和血缘。二者结合可以生成语义模型草稿，再由业务和数据 Owner 编辑确认。只读 Schema 很难发现“已支付但未取消”这样的隐含条件。

阿里云 DataWorks 的相关路线值得关注，正因为它把语义生成放在数据开发与分析工作流之间：语义不是旁边的一份说明文档，而是 Agent 查询时要加载的约束。

生成语义模型后还要验证

可编辑 YAML 或其他语义定义只是载体。上线前应使用已知问句与可信查询做双向测试：同义表达是否绑定同一指标；边界日期是否一致；跨表 Join 是否改变粒度；新版本是否破坏历史结果。

一个可落地的最小闭环

先从十个高频指标开始，提取代码与元数据，生成草稿，由 Owner 确认后写入版本化语义仓库；查询时记录命中的指标版本；结果异常时，把修正回写为新的测试，而不是临时提示词。

Data Agent 真正理解“客单价”，不是因为模型见过这个词，而是因为词被绑定到了有版本、有 Owner、可验证的计算契约。

语义层还需要运行时观测

上线后应统计每个指标契约被哪些问题命中、哪些同义词频繁无法解析、哪些查询在 Join 后产生异常膨胀，以及用户在哪些答案上反复追问。它们能揭示语义定义缺口，比单纯统计问答满意度更接近根因。

契约变更也要区分兼容更新与破坏性更新。增加一个同义词通常可以直接发布；改变分母、默认过滤或时间窗口，则需要新版本、影响分析和历史回放。语义层不是一张静态指标表，而是一套面向 Agent 执行的变更管理系统。

对跨部门指标，还应显式声明适用组织与展示名称，避免销售口径覆盖财务口径。若用户问题没有足够信息选择版本，Agent 应展示候选定义并请求确认，而不是依赖语料中的多数用法替用户决定。

语义命中记录也可以反哺治理：高频歧义进入术语清单，反复失败的 Join 进入禁止规则，常用且稳定的问句沉淀为验证样例。每次失败都应改善契约，而不是只修补当次回答。

参考：阿里云 DataWorks 产品文档

Google Cloud Data Agent：三类上下文如何共同收敛

Tue, 22 Sep 2026 00:00:00 +0000

Agent 知道表在哪里，不等于知道怎样回答业务问题。Google Cloud 的 Conversational Analytics 把 Data Agent 描述为“上下文 + 工具”的组合：上下文提供业务信息和数据，SQL、Python 与可视化工具负责执行。

三类上下文承担不同责任

数据上下文说明可查询对象、字段、关系与数据位置；业务上下文解释术语、指标、过滤规则和经过验证的查询；会话上下文保存用户在多轮对话中的范围、假设和追问。

把三者混成一个“知识库”会带来问题。字段元数据不能代替指标定义，历史对话也不应覆盖受治理语义。数据 Agent 应明确每类上下文的来源、有效期和优先级。

已保存 Agent、内联上下文与会话状态

API 支持引用已保存的数据 Agent，也可以在请求中直接提供上下文。多轮交互又可选择有状态会话，或由应用在无状态模式下自行管理历史。选择哪种方式，取决于复用、隔离、审计和数据驻留要求，而不只是开发便利。

语义资产怎样减少歧义

在 BigQuery 或 Looker 场景中，团队可以补充表字段元数据、解释指令和 verified queries。比如“top performers”究竟按收入还是订单数排序，应由业务语义约束，而不是让模型临场猜测。

生产边界

身份与访问仍由 IAM 和数据源权限控制。数据库数据源和部分能力的成熟度不同，可视化支持也不是所有来源完全一致。Google 官方明确提醒生成结果可能看似合理但事实错误，重要输出仍需验证。

适合的试点不是“让所有人随便问所有数据”，而是选择一个语义稳定的主题，为常见问题准备 verified queries，记录生成的 SQL、工具调用和结果，并把失败归因到上下文、执行或呈现层。

Google Cloud 的路线说明：上下文越多不一定越好。真正有效的是相关、授权、可追踪且能在多轮状态中保持一致的上下文。

建议的评测切片

同一问题至少要在四种条件下测试：语义信息完整、字段说明缺失、会话中途改变范围、用户权限不足。分别记录 Agent 选择的数据源、生成的查询、最终答案和拒绝原因。这样可以看出系统是在可靠使用上下文，还是只在理想演示里表现良好。

对有状态会话还要测试“上下文污染”：前一轮对某个地区或时间窗口的限定，是否被错误带入新的主题。对无状态集成则要检查应用是否完整传回必要历史，并避免把敏感内容带到不相关请求。状态管理本身也是数据治理的一部分。

参考：Conversational Analytics API 概览、BigQuery Conversational Analytics

OpenAI Data Agent 发布：把企业数据变成答案、看板与行动

Fri, 11 Sep 2026 00:00:00 +0000

2026 年 9 月 10 日，OpenAI 在 ChatGPT Work 中发布 Data Agent。它不是单独增加一个 Text-to-SQL 对话框，而是把企业数据源、业务上下文、分析工作流、交互式看板和批准后的行动接入同一条会话链。

这项发布值得关注，因为它把 Data Agent 的竞争从“模型能否写查询”推向了“组织能否让更多员工在现有权限内完成一项可复核的数据工作”。

数据连接和业务上下文同时进入分析

官方列出的获批数据源包括 Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB 和 Snowflake，也可将 Google Drive、SharePoint 中的文件与文档带入分析。

连接器只解决“数据可达”。Data Agent 还会使用组织已有的业务术语、指标定义、自定义计算和数据关系，相关上下文可来自 Databricks Genie Ontology、dbt、GitHub、Snowflake Horizon 与 BI 看板等可信来源。

这两类输入必须分开理解：数据源提供记录，语义资产规定这些记录如何变成业务含义。若组织没有稳定定义，Agent 只会更快暴露口径冲突。

分析过程变成可继续追问的工作区

用户可以在同一会话中要求 Agent 调查变化、比较历史时期、检查证据并调整范围。结果不仅是文字回答，还可以形成可编辑、分享和刷新的交互式看板；官方同时列出 Tableau、Power BI、Sigma 和 ThoughtSpot 等 BI 生态合作伙伴。

这里最重要的产品变化，是中间过程不再完全隐藏。用户可以沿着问题、证据和制品继续迭代，而不是每次重新提交一个孤立查询。

Skills 把常见分析方法拆成工作协议

Data Agent 背后包含指标设计、业务背景收集、数据上下文、质量分析、诊断、Notebook、可视化、看板和报告等分析 Skills。连接器回答“可以访问什么”，Skill 回答“这类任务应该怎样做、怎样验证、什么时候完成”。

Skill 不等于已经证明的产品性能。它描述的是工作方法和验收边界，实际效果仍取决于数据质量、语义资产、权限配置和具体任务。

从发现到行动，多了一道批准边界

Agent 可以建议下一步、识别需要参与的人，通过 Slack 或邮件分享发现，并使用连接工具执行用户批准的行动。这里的“批准”非常关键：分析建议、动作提案、授权执行和执行后回读应被视为不同状态。

Agent 越强，为什么越需要语义层

Tue, 08 Sep 2026 00:00:00 +0000

把订单表、支付表和客户表的 Schema 交给模型，它很快就能写出一条可运行的 SQL。可当用户问“上个月收入是多少”，真正的问题才开始：收入是下单金额、实收、净收款还是财务确认收入？按下单时间还是确认时间？退款归属哪个月？

这些不是模型应该自由推断的常识，而是企业自己的业务合同。Agent 能力越强、执行链越长，一个错误定义被传播到报告和动作中的代价就越大。

Schema 描述数据的形状；语义层规定数据在什么条件下代表什么事实、允许怎样聚合。模型可以帮助发现冲突、起草定义，却不能替指标负责人决定口径。

语义层、本体和目录各管什么

资产目录回答“有什么、在哪里、谁负责”；语义层回答“怎么算、能按哪些维度分析”；业务本体回答客户、账户、订单等概念如何识别和关联。执行与治理系统则强制实施权限、预算和审计。

本体不一定要从复杂知识图谱起步。一个受治理的实体关系模型，能明确主键、基数、有效期和身份映射，就已经解决很多 Join 放大和概念混用问题。重要的是定义可引用、可版本化、可被查询编译或验证，而不是图画得多复杂。

六类语义资产缺一不可

资产	至少要明确	缺失后的典型错误
指标	公式、单位、时间口径、粒度、聚合、版本、负责人	把支付金额当确认收入；比率直接平均
实体	主键、唯一性、关系方向、基数、有效期	一对多 Join 放大金额；账户与客户混用
维度	层级、合法取值、适用指标、历史归属	用当前地区解释历史业绩
同义词	业务域、语言、候选概念与不可等同项	把营收、销售额和回款无条件合并
业务规则	状态过滤、币种、财务周期、用途、生效区间	测试订单进入正式报表
验证样例	问题、口径、查询、快照、预期结果、验证人	旧 SQL 被当成永久正确答案

这些资产可以分布在词汇表、指标服务、目录和样例库中，但必须通过稳定 ID 与版本关联。复制多份自然语言说明，通常只会制造新的漂移。

“收入”案例：先绑定定义，再写 SQL

假设团队同时维护交易总额、实收金额和财务确认收入。用户只说“收入”时，可靠流程是：

检查当前报表或会话是否已绑定某个指标；没有明确上下文就澄清。
将“上个月”转换为指定时区的具体区间，确定支付时间还是确认时间。
读取退款、税费、币种和内部账户排除规则。
先形成指标、维度、过滤与版本组成的语义计划，再编译查询。

一个最小指标契约可以长这样：

{
 "metric_id": "commerce.period_net_receipts",
 "version": "1.0",
 "definition": "期间成功收款减期间成功退款",
 "expression": "sum(receipt_cny) - sum(refund_cny)",
 "time_fields": {"receipts": "paid_at", "refunds": "refunded_at"},
 "timezone": "Asia/Shanghai",
 "grain": "calendar_day",
 "unit": "CNY",
 "allowed_dimensions": ["channel"],
 "missing_input_policy": "unknown_not_zero",
 "effective_from": "2026-08-01",
 "test_suite_ref": "tests/net-receipts-v1"
}

缺失输入记为未知，而不是零；退款与收款应先按兼容粒度聚合，再对齐计算，不能直接连接两张明细表造成乘积。最终答案还应带出采用的指标版本、时间字段、数据水位和限制。

语义如何进入运行链路

语义资产只有进入执行与验证，才不只是文档：

Data Agent 的七层架构：从数据接入到可信交付

Mon, 07 Sep 2026 00:00:00 +0000

业务负责人问：“这个月新客转化为什么下降了？”

如果系统立刻吐出一条 SQL，这通常不是效率高，而是跳过了最危险的部分。它还不知道“新客”按注册时间还是首购时间认定，不知道转化窗口是 7 天还是 30 天，也不知道本月渠道口径是否刚刚调整。SQL 可以运行成功，结论仍然可能是错的。

一个可用于生产的数据智能体，必须把这类模糊问题变成一条可检查的证据链：确认意图，找到被批准的数据和定义，制定分析计划，在受控环境里执行，验证结果，最后把结论和限制交给有权限的人。模型只负责其中一部分。

下面这张图把这条链路拆成七层。它不是厂商产品清单，而是一张职责地图：当结果不可信时，团队可以据此定位究竟是哪一层失守。

Data Agent 七层职责地图。点击查看原图。

先看清三张相互叠加的网

七层并不是一条只能从上往下走的流水线。一次分析会在规划、执行和验证之间多次往返，而权限、审计与评估贯穿始终。更准确的理解，是三张网叠在一起：

数据面负责让智能体找到数据、理解业务语义并运行工具；
控制面决定智能体可以看到什么、调用什么、在什么成本和风险范围内行动；
评估面检查单次答案，也持续衡量系统在一组真实任务上的表现。

很多原型只有数据面最显眼的一小段——“问句转 SQL”。一旦进入生产，真正拉开差距的往往是另外两张网：系统能否拒绝不该做的事，能否说明结论从何而来，失败后能否定位和修复。

第一层：接入与任务入口

入口可以是聊天框、Notebook、BI 侧边栏、API，也可以是定时触发的工作流。它的责任不是“做一个像 ChatGPT 的界面”，而是收集完成任务所需的最小上下文：用户身份、业务范围、时间窗口、期望输出和风险等级。

仍以转化率下降为例。一个合格的入口至少要知道提问者能看哪些地区的数据，并在定义不明确时主动追问：“这里的新客按注册还是首购计算？”

这一层的典型失败，是系统流畅地解决了另一个问题。产品设计上应允许用户低成本纠正假设，而不是把澄清隐藏在一长段回答之后。

第二层：语义、本体与可信上下文

物理表告诉模型有哪些字段，语义层告诉它这些字段在业务上意味着什么。这里需要管理指标、维度、实体关系、同义词、时间口径、Join 路径、负责人和版本。

例如，“新客转化率”可能被定义为：首个有效触点后 14 天内完成首购的新用户数，除以符合条件的新用户数。这个定义还要说明排除哪些渠道、退款如何处理、历史版本何时失效。只有把这些知识变成可检索、可引用、可执行的对象，智能体才不必每次凭字段名猜测。

上下文也不等于把所有文档塞进提示词。系统需要按任务路由：指标问题优先取指标定义和血缘，客户问题取实体关系和权限，重复出现的分析则可参考已验证的历史查询。上下文越多不一定越好；过期定义和相似但错误的 SQL 会把错误包装得更像答案。

第三层：规划与编排

规划器把目标拆成有依赖关系的步骤。对“新客转化下降”这类问题，一份可检查的计划可能是：

确认指标版本和比较周期；
先复算整体指标，确认下降确实存在；
按渠道、地区、设备和新客来源做贡献分解；
对主要异常分组检查漏斗步骤与数据质量；
运行替代口径或对照查询，排除定义变更；
汇总证据，标出不能从现有数据确认的部分。

规划的价值不在于写出一段漂亮的步骤说明，而在于让依赖、预算和停止条件显式化。某个分组样本过小，就不该继续生成强结论；关键数据延迟，系统应停止并提示，而不是用昨天的数据补齐今天的故事。

单智能体配工具、Planner–Executor–Verifier、多智能体协作都可以实现这一层。角色越多，协调和状态管理成本越高。先把计划、工具契约和验证点做扎实，通常比先增加 Agent 数量更重要。

第四层：工具与受控执行

智能体通过 SQL 引擎、Python 沙箱、Catalog、文档检索、可视化组件和业务 API 把推理变成证据。每个工具都应该像一个受约束的服务，而不是给模型一把万能钥匙。

一个可上线的工具契约至少应写清：输入参数、输出结构、身份传递、数据范围、超时、成本上限、幂等性和失败码。查询默认只读；大扫描、敏感字段和写操作需要单独的审批或策略门槛。代码在隔离环境运行，产物和日志可追溯。

这也是 Agent Harness 的核心工作：把模型调用、上下文装配、工具选择、策略检查、状态与记忆连接起来。模型可以替换，Harness 中积累的权限、工具契约和失败处理才是系统工程的主体。

第五层：验证、反思与修正

“工具调用成功”只说明系统得到了一份结果，不说明结果值得相信。验证层需要同时检查计算和结论。

计算侧可以做 SQL 编译、空值与基数检查、时间范围检查、与可信总数对账、替代查询比较；结论侧要检查每个判断能否回到数据证据，相关性是否被误写成因果关系，以及样本量和数据延迟是否足以支撑措辞。

当验证失败时，系统应回到规划或执行层修正，而不是简单地“再生成一次”。例如两个渠道的合计对不上整体，正确动作是检查重叠归因或 Join 扩张；让模型换一种说法，并不会修复数字。

五条 Data Agent 技术路线：别用同一把尺子比较不同产品

Sat, 05 Sep 2026 00:00:00 +0000

同样叫 Data Agent，有的系统把一句业务问题翻译成 SQL，有的会连续运行查询和 Python、写出一份分析报告，还有的直接修改数据管道。这些产品共享了一个名字，却不应共享同一套验收标准。

判断路线时，我更愿意先看一个具体工作流，而不是厂商首页上的产品名称：它接收什么输入，替人完成哪段工作，最终交付什么，以及失败后会影响谁。按这四个问题，Data Agent 大致可以分为五条路线。

这张图有两个刻意的设计。第一，五条路线是并列的任务类型，不是从低到高的成熟度等级；第二，路线决定系统“做什么”，语义上下文、运行时、权限和评测共同决定它“能否可靠地做”。

一、企业问数与语义层：把业务语言变成可信查询

这条路线解决的是高频、相对标准化的业务问题，例如“华东区上周新增付费客户是多少”“下降主要来自哪个渠道”。Agent 需要把业务词汇映射到指标、维度、表和连接关系，再生成查询并解释结果。

它看起来像 NL2SQL，真正的难点却通常不在 SQL 语法，而在语义：什么算“新增”，退款是否回冲，订单按支付日还是发货日归属。没有指标定义、实体关系、权限和可复用的正确样例，模型越会写 SQL，越可能快速给出一个格式正确但口径错误的答案。

Snowflake Cortex Analyst要求通过语义模型描述业务概念，并继承 Snowflake 的访问控制；其 Verified Query Repository 用经过验证的问句—SQL 对提升稳定性。Microsoft Fabric Data Agent也把自然语言问题转成面向 Fabric 数据源的查询，并按调用者权限执行。它们说明了这条路线的核心：不是聊天界面，而是“语义约束下的只读数据访问”。

验收重点：业务口径命中率、查询执行正确率、权限不越界、无答案时能否拒答或澄清。仅用 SQL 字符串与标准答案逐字比较，往往会低估等价查询，也会漏掉“SQL 正确但业务答案错误”的情况。

二、端到端分析与报告：从一个问题走到可复核的判断

如果问题变成“为什么本月留存下降，应该先排查什么”，单次查询就不够了。Agent 要拆解假设、选择比较基线、运行多轮查询或代码、制作图表，并把证据与结论组织成报告。

这条路线的产品价值来自缩短分析闭环，但也最容易制造“看起来很专业”的错觉。一份排版完整的报告可能用了错误分母，忽略了样本结构变化，或者把相关性写成因果关系。因此系统应保存分析计划、查询与代码、关键中间结果、图表数据和引用，让读者能够沿证据链回查。

验收重点：问题拆解是否覆盖关键假设，结论能否由已执行的证据支持，统计方法是否适用，重跑是否得到一致结果。报告文笔只是最后一层，不是核心质量。

三、自动化数据科学：让实验可运行，也让失败可解释

数据科学 Agent 会参与探索性分析、特征处理、统计检验、模型训练与评估。它与报告型 Agent 的区别，是交付物不只有洞察，还包括可运行代码、数据切分、模型指标和实验记录。

Google Data Science Agent把自然语言目标转成 Colab Enterprise 笔记本中的分析计划、代码与结果。这类系统可以显著减少搭脚手架的时间，但仍无法替代对标签泄漏、时间穿越、抽样偏差和评估设计的专业判断。

验收重点：环境与依赖能否复现，训练/验证边界是否正确，指标是否匹配业务成本，异常和失败是否被暴露。一个能跑通的 notebook 只是起点，不是模型可上线的证明。

四、异构与多模态分析：在多种证据之间建立连接

真实调查常同时涉及数据库、Excel、PDF、网页、图片、日志甚至音视频。此时 Agent 的主要工作不再是生成某一种查询，而是检索、解析、实体对齐、跨源聚合，并说明每个判断来自哪里。

例如排查供应商履约问题，既要读仓库里的交付数据，也要从合同 PDF 提取时限条款，再从工单文本识别异常原因。任何一个实体匹配或时间对齐错误，都可能让最后的综合结论失真。

验收重点：解析覆盖率、实体链接准确率、来源定位、冲突证据处理与引用完整性。系统应把“没有找到”“无法确认”和“推断得到”分开，而不是用流畅文字抹平证据缺口。

五、数据治理与数据工程：从回答问题走向改变系统

这条路线面向元数据维护、质量规则、血缘与影响分析、数据模型开发、管道排错和运维。它的输出可能是一份变更建议，也可能是 Dataform、dbt 或编排系统中的代码和配置。

SQL 写对了，答案为什么还会错？

Fri, 04 Sep 2026 00:00:00 +0000

数据分析里最危险的结果，往往不是一条报错的 SQL，而是一条顺利运行、数字精确、图表漂亮，却回答了错误问题的 SQL。

假设运营问：“本月新增客户是多少？”系统找到 customer 表，按 created_at 统计去重 ID，返回 12,486。查询没有语法错误，结果也能复现。但销售团队口中的“新增客户”是首次付费客户，财务还要求排除退款和内部测试账户。12,486 只是“本月新建客户记录”，不是提问者准备据此做预算的指标。

SQL 没有错。错误发生在 SQL 之前。

正确性不是一个开关，而是一条链

一项数据结论至少要通过四层正确性：

语法正确：查询能被数据库解析和执行。
数据正确：表、Join、粒度、时间和质量状态符合任务要求。
口径正确：计算使用了组织认可、在当前时间有效的业务定义。
解释正确：结论没有超出证据，限制条件和不确定性被如实表达。

大多数 Text-to-SQL 指标首先测的是前两层的一部分。企业真正承担决策风险的，却是后两层。

五种常见的“正确地算错”

1. 同一个词，在不同团队代表不同事件

“客户”可能是注册用户、通过认证的企业、首次付费账户或签署合同的主体。“收入”可能是下单金额、支付金额、确认收入或扣除退款后的净收入。字段名相似，并不能证明业务含义相同。

Agent 如果静默选择一个定义，会让偶然的猜测看起来像确定事实。更好的行为是检索权威定义；存在多个有效口径时，把候选项和数字影响展示给用户确认。

2. 时间窗口没有对齐

“本月”可能指自然月、最近 30 天、财务账期，也可能受用户时区影响。同比还隐含工作日、节假日和完整周期是否可比。SQL 中一个看似无害的 CURRENT_DATE - 30，就可能改变管理层对趋势的判断。

3. Join 改变了数据粒度

订单表是一行一单，商品明细是一行一个 SKU。两表直接 Join 后对订单金额求和，会把多商品订单重复计算。查询能运行，抽样看起来也合理，只有先声明目标粒度并检查 Join 前后的行数和唯一键，才容易发现问题。

4. 状态过滤散落在历史 SQL 里

是否排除取消单、退款单、测试账户和风控交易，经常没有写在字段说明里，而是藏在某张看板或某位分析师维护的查询中。只给 Agent schema，相当于只给它词典，没有给它组织的会计规则。

5. 定义已经改变，答案仍在引用旧版本

指标口径会随业务发展而调整。文档、看板、语义层和历史 SQL 如果不同步，同一问题在不同入口会出现多个“官方答案”。这类版本漂移必须通过负责人、生效时间和弃用状态处理，不能靠模型选择看起来最新的一段文字。

为什么把更多 schema 塞进上下文仍不够

Spider 2.0 把 Text-to-SQL 放进更接近企业的环境：632 个工作流问题，数据库经常包含上千列，任务还需要检索元数据、方言文档和项目代码。论文发布时的基线结果显示，经典基准上的高分并不会直接迁移到这种复杂环境。

什么是 Data Agent：判断它是不是智能体的四个标准

Thu, 03 Sep 2026 00:00:00 +0000

“为什么本周转化率下降了？”

一个 NL2SQL 工具可以把这句话翻译成查询。一个真正的 Data Agent 则要先问清楚：是哪条业务线、哪个转化漏斗、自然周还是滚动七天、当前用户有权查看哪些数据。随后，它还要找到可信的数据集，调用指标定义，拆解异常，运行查询，检查样本量和数据新鲜度，最后把结论连同证据交给使用者。

二者都可能有聊天框，也都可能生成 SQL。区别不在界面，而在于谁对完整任务闭环负责。

一个可以落地的定义

Data Agent 是运行在受治理数据环境中的自主或半自主软件系统。它接受自然语言或高层任务，在权限边界内完成上下文装配、规划、工具执行和结果验证，交付可追溯的数据答案、洞察或行动。

这里的每个限定词都有用：

数据环境意味着系统面对的是真实表、指标、文档、元数据和访问策略，而不是一组预设答案。
自主或半自主意味着它能维护任务状态，根据中间结果继续、修正或停止，而不是只完成一次生成。
受治理意味着模型不能绕开身份、权限和审批规则；高风险操作必须有边界。
可追溯意味着使用者能看到结论依据了什么数据、口径和执行过程，也能复核关键结果。

近年的 Data Agent 研究也反复指出：这个名称同时被用于查询助手和自主系统，术语混用会掩盖能力差异。《A Survey of Data Agents》因此提出了从 L0 到 L5 的分类；后续的《Data Agents: Levels, State of the Art, and Open Problems》则把数据管理、准备和分析都纳入同一个工具使用框架。定义的价值，不是再造一个新名词，而是让产品承诺可以被检验。

Data、Model 和 Harness 缺一不可

只看大模型，很容易把 Data Agent 理解成“更会推理的聊天机器人”。实际系统更接近三个部分的乘积。

Data：不只是数据库连接

数据侧至少包含三类上下文：

事实数据：仓库、湖仓、业务数据库、文件和 API。
业务语义：指标定义、维度层级、实体关系、同义词和计算规则。
治理上下文：身份、行列权限、数据分级、新鲜度、血缘和使用限制。

能连上 Snowflake 或 BigQuery，只解决了“数据在哪里”。如果不知道“有效订单”是否排除退款，也不知道财务口径何时生效，系统仍然会稳定地产生错误答案。

Model：提供推理，不拥有权限

模型擅长理解意图、提出假设、生成 SQL 或 Python，并把结果组织成人能读懂的说明。但模型参数不是企业事实库，也不应该成为权限系统。把业务定义塞进提示词，只能暂时改善某个问题，无法替代版本化的语义层和强制执行的访问策略。

Harness：把能力组织成可靠过程

Agent Harness 是最容易被低估的部分。它负责装配上下文、保存状态、安排步骤、选择工具、传递身份、限制执行、校验结果并记录轨迹。模型可以替换，工具可以增加；只要 Harness 的契约稳定，系统仍能按同一套治理规则工作。