数据治理 on DataAgentX

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 名称上猜答案。

Microsoft Fabric Data Agent 为什么坚持只读

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

Agent 一定要能改数据、发工单，才算有价值吗？Fabric Data Agent 选择了更窄的边界：生成并执行只读的 SQL、DAX 和 KQL 查询，把跨系统写操作留给外部编排。

身份先于查询

数据访问沿用用户的 Microsoft Entra ID 与数据权限。Agent 能看到 Schema，不代表用户能读数据；对 Power BI 语义模型的访问还受 Read 权限、RLS 和 CLS 约束。这使权限检查落在数据平台，而不是交给提示词判断。

不同资产走不同查询语言

Lakehouse、Warehouse 和 SQL Database 通过 SQL 查询；Power BI 语义模型使用 DAX；Eventhouse/KQL Database 使用 KQL。一个 Agent 可以组合多种来源，但语言路由只是第一步，跨源口径、粒度和时间仍需业务定义约束。

只读降低了什么风险

只读阻止 Agent 直接创建、更新或删除数据，也不会从 Eventhouse 触发 Notebook 或其他动作流。这减少了误操作的爆炸半径，并让分析组件更容易嵌入 Copilot Studio 等上层编排。

但只读不等于安全或正确。错误查询仍会误导决策，过宽权限仍会暴露数据，Purview DLP 也可能让结果被截断或阻断。当前聊天输出还有行列限制，不适合被当作完整数据导出接口。

生产设计的三个检查点

第一，验证用户身份和每个数据源的实际权限，而不是只看工作区角色。第二，为关键问题提供示例查询和语义说明，并记录生成查询。第三，把“分析建议”与“业务动作”分开：若外部 Agent 要据此写回系统，必须重新审批目标、参数与接收者。

Fabric 的只读路线说明，一个 Agent 不必包办闭环中的全部动作。把受治理问数做成可靠组件，再由显式编排承担写操作，往往比给同一个模型无限工具更容易审计。

只读 Agent 也需要回归集

可以从真实高频问题构造一组覆盖 SQL、DAX 和 KQL 的任务，记录预期数据源、关键筛选、行级权限和可接受的汇总结果。每次模型、语义模型或数据源结构变化后回放，重点检查错误路由、静默截断和权限差异，而不是只看自然语言答案是否流畅。

企业落地 Data Agent，第一步不是选模型

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

企业做 Data Agent，第一步往往不是选最强模型，也不是搭多 Agent。先找一段频繁发生、答案可复核、失败影响可控的工作，把“做对了长什么样”写清楚。否则 Demo 再顺，上线后也没人知道它是否值得信任。

落地过程可以理解为逐步转移责任：每向生产前进一步，Agent 多接手一项工作，团队就要补一份证据和一条回退路径。

选择第一站：高频、可验证、低风险

合适的首个任务通常具备：有人反复完成，有历史问题和人工结果；口径有负责人，关键数字能复算；以只读为主，失败可转人工，不直接改变生产系统。

例如每周净收入复盘，比“自动发现全公司经营问题”更适合试点。前者可以固定身份、指标、时间、来源和交付物，后者连完成定义都很难写清楚。

先写任务卡，不急着写 Prompt

任务卡至少包含：

谁发起，支持哪项决定，最终由谁负责；
使用哪些数据与指标版本，时间、粒度、退款和去重规则；
允许读取和禁止访问的资产，是否允许代码、文件和外部工具；
期望产物、关键证据、允许误差和必须拒答的条件；
最大延迟、扫描量、模型/工具预算和人工接管点；
失败、取消、权限撤销和版本回退路径。

Prompt 只是实现细节。任务卡才是业务、数据、工程、安全和评测可以共同签字的契约。

建立真实任务集

从 20–50 个真实高频任务起步，再派生不同问法、角色和边界样本。不要只准备系统知道答案的正常题，还要加入：

指标歧义和定义冲突，系统应澄清；
数据迟到、来源缺失和空集，系统应保留未知；
同名测试表和过期报表，系统应排除；
无权限、敏感字段和外发请求，系统应拒绝；
查询超时、工具故障和状态未知，系统应安全恢复；
相关性被要求写成因果结论，系统应说明证据不足。

近重复样本应分组切分，避免同一个模板同时出现在开发和测试中。

六个阶段与门禁

1. 范围定义

业务 Owner 确认任务、人工基线、价值假设和不可接受的错误。数据团队确认口径与来源；安全团队确认身份和风险边界。

2. 只读 POC

接入最小数据范围和语义资产，在沙箱中保存查询、代码、上下文和验证轨迹。先证明系统能稳定找对数据、算对指标、知道何时停。

3. 离线回归

固定快照，按任务切片评分。红线错误独立阻断；质量、延迟、成本和人工复核分别报告。任何模型、语义或工具变更都重新跑核心集。

4. 影子运行

处理真实请求，但结果不直接交给用户，不产生业务动作。对比人工结果，发现分布漂移、权限、数据水位和长尾成本问题。

5. 有限生产

只开放明确用户、任务和数据域；保留人工入口、速率和预算上限、熔断开关。先交付只读结果或草稿，高影响动作继续人工执行。

6. 规模化

达到稳定门禁后再扩数据域、用户和动作。每次扩张都视为新风险边界，需要新的任务集和回归，而不是复用一次 POC 结论。

上线门禁不要只看平均正确率

红线门禁包括越权、泄密、危险写入、错误接收者和无法停止的副作用，一次有效触发就应阻断对应版本或能力。

质量门禁看关键任务成功、口径错误、证据支持、拒答和人工修改。运营门禁看 p95 延迟、单位任务成本、人工接管、故障恢复和审计完整性。

阈值来自业务风险和人工基线，不存在通用的“90% 就能上线”。财务报送和探索性分析允许的错误不同。

组织责任必须长期存在

业务负责人维护任务优先级、指标口径与可接受错误；数据负责人维护来源、语义和质量；工程/评测负责人维护版本、轨迹、回归和故障归因；安全/运维负责人维护权限、红线、灰度停止和事件恢复。

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 接入层：连接数据之后，怎样先找对数据

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

“本月新客转化为什么下降？”仓库里可能同时存在生产漏斗模型、名字相近的测试表和上季度活动表。连接器都能访问，字段看起来也都合理。Agent 如果挑错其中一个，后面的 SQL、图表和解释越完整，误导性反而越强。

接入层要在生成查询之前回答三个问题：当前身份可以访问什么，这个任务应该使用什么，候选数据是否足以支撑结论。它不是一个把所有 Schema 塞进提示词的管道，而是一套受权限约束的数据发现和上下文路由系统。

图里最重要的是两道权限检查：目录检索前先缩小可见范围，真正执行时再次鉴权。目录中的“可发现”从来不等于数据库中的“可执行”。

接入层与相邻层的边界

接入层负责发现资产、检查来源与可见范围，并交付最小充分上下文。语义层维护“新客”“转化率”等定义、粒度和合法关联；规划层决定分析步骤；执行层保管凭证、运行查询并重新检查权限。

这几层不能互相代替。表名相似不是业务定义，目录授权也不是执行凭证。把这两个边界混在一起，常见结果是 Agent 用热门旧表回答新问题，或者通过共享服务账号绕过用户权限。

四个组件，各自要交付什么

组件	最小交付物	失败时怎么办
数据源注册中心	稳定来源 ID、环境、业务域、负责人、认证引用、允许操作和预算	未注册来源不静默接入
资产目录与采集器	Schema 版本、字段说明、血缘、质量状态、采集时间和数据水位	未采到的信号标为未知
上下文路由器	候选资产、采用与排除理由、必要字段、定义引用和缺口	无可靠来源时澄清或停止
连接器运行时	身份绑定、分页、超时、重试、标准结果和审计事件	凭证不进入模型上下文

现有目录能力应优先复用。OpenMetadata把所有权、术语、血缘、画像和质量信号组织在统一元数据中，其采集框架覆盖多类元数据工作流。但安装目录不会自动产生正确路由；哪些信号参与排序、哪些属于阻断条件，仍要由团队设计。

一次可靠路由包含六步

1. 把业务问题解析成检索约束

提取业务域、实体、指标、时间、粒度、用途与交付物。相对时间要落成具体区间和时区。问题中“客户”“订单”含义不清时，应在检索前澄清，而不是等 SQL 失败后再补救。

2. 在当前身份可见范围内召回

关键词、业务术语和向量检索可以共同生成候选，但召回必须身份感知。表名、字段说明和样例值本身也可能敏感；不能先把全量目录交给模型，再指望它自行忽略无权访问的资产。

3. 先做硬性策略过滤

环境、用途、地域、敏感等级、元数据可见性和数据访问权限都是门禁，而不是排序加分项。测试表与生产表名称再接近，也不能因为语义相似度高而越过环境隔离。

4. 在合规候选中排序和裁剪

比较业务覆盖、权威性、更新时间、质量证据、关联完整性和预计成本。热门表的历史使用量只能做辅助信号，否则新权威模型永远排不过旧表。多表任务还要保留必要的 Join 路径，而不是只挑几个相似字段。

5. 绑定资产，执行时再检查

路由器交付资产引用、版本与预算，运行时再绑定真实身份。目录发现到执行之间，权限、Schema 和数据状态都可能变化。Microsoft Fabric Data Agent 的权限文档也区分 Agent 的分享权限与底层数据权限；共享 Agent 不会替用户获得源数据访问权。

6. 把结果和纠错写回

保留候选、排除理由、采用版本、执行结果与人工纠错。用户点击或采纳只能说明体验，不足以证明来源正确；被确认的错误才进入回归集或质量标签。

上下文包需要同时表达事实和限制

上下文不应只是字段列表。一个可执行的上下文包至少应包含：

{
 "asset_ref": "warehouse.prod.funnel",
 "schema_version": "v12",
 "selected_fields": ["day", "channel", "new_users", "converted_users"],
 "definition_ref": "metrics/new_customer_conversion/v3",
 "grain": "day × channel",
 "metadata_observed_at": "2026-09-07T09:00:00+08:00",
 "data_watermark": "2026-09-06",
 "quality_status": "unknown",
 "policy_ref": "policy/read-funnel/v4",
 "allowed_operations": ["read"],
 "limitations": ["尚未确认所有渠道覆盖"],
 "requires_runtime_authorization": true
}

metadata_observed_at 与 data_watermark 必须分开。目录今天同步成功，不代表业务数据也更新到了今天。policy_ref 只是策略引用，不是凭证；授权句柄和密钥留在可信服务端。

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 的 L0–L5：升级的不是功能，而是责任

Sun, 06 Sep 2026 00:00:00 +0000

一个系统会写 SQL，另一个系统会调用 SQL 和 Python，遇到错误还能重新规划。后者连接的工具更多，但这还不足以证明它更“自主”。真正的区别是：谁决定目标，谁组织过程，谁有权执行，谁验证结果，出了问题又由谁恢复并负责。

因此，Data Agent 的等级不是功能数量表，而是一张责任转移图。每升一级，Agent 接手的不只是更多操作，也包括更多判断与风险。

这套 L0–L5 框架来自 2026 年论文 Data Agents: Levels, State of the Art, and Open Problems 及其配套的 Data Agent 研究资料库。作者将公开研究的主体现状放在 L0–L2，把正在探索端到端自主编排的系统称为 Proto-L3；L4 和 L5 主要是未来愿景。它适合用来讨论人机分工，不是厂商排行榜，也不是采购认证。

判断等级，要看五种权力归谁

同一个产品在不同工作流上可能处于不同等级。判断时可以沿五个维度逐项追问：

维度	关键问题
发起权	任务必须由人提出，还是系统能主动发现问题？
规划权	人预先定义步骤，还是 Agent 能拆解、选工具并重新规划？
执行权	只能建议、可以只读执行，还是能触发写入与外部动作？
验证权	谁判断结果足够可靠、任务可以结束？
恢复与责任	失败时谁停止、回滚、接管并解释发生了什么？

只要其中一个关键维度仍由人控制，系统的实际等级就会受到它限制。例如 Agent 可以自动写并执行 SQL，但每一步由人指定、结论也由人验收，它更接近 L2，而不是 L3。

L0：人是唯一的操作者

在 L0，分析师或工程师自己找数据、写 SQL 或代码、检查结果并决定下一步。数据库、BI 和 notebook 是工具，但不会代替人做判断。

L0 并不等于落后。在财务结账、监管报送、重大生产变更等高风险流程中，完整人工控制可能是合理设计。它的问题是吞吐依赖个人经验，过程难以规模化，隐性知识也容易留在个人电脑和脑中。

生产门槛：建立版本、评审、数据口径和操作记录。没有这些基础，接入 Agent 只会把原本不透明的人工过程自动化。

五条 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 或编排系统中的代码和配置。

什么是 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 的契约稳定，系统仍能按同一套治理规则工作。