理解 Data Agent，建设可信的数据智能系统。 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：怎么开始构建

分享给出的路径很务实：

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

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

改一条费率，先找准哪些交易会受影响

Thu, 22 Oct 2026 00:00:00 +0000

把一条支付费率从万分之 14 降到万分之 1，商户一个月能省多少钱？

这个问题看起来是一道乘法题，实际难点在乘法之前：哪些交易会受影响。这次用 DABstep 的两道 hard 题做复算，重点放在范围确定和独立核验。

数据与题目

DABstep 由 Adyen 与 Hugging Face 构建，考查跨表、跨文档的多步分析。这次用到 2023 年的 138,236 笔合成支付交易、1,000 条费率规则，以及商户资料、行业编码字典和业务手册。

第一题：一笔 10 欧元交易，按适用费率规则计算的平均手续费是多少？条件是账户类型 H、餐饮行业、GlobalCard。

第二题：针对指定商户 2023 年 1 月，把规则 384 的 rate 从 14 改为 1，其他条件保持不变，费用变化多少？

两题都要求先读手册，确认单位和规则含义，再做筛选与计算。

第一题：先映射条件，再逐条计算

条件里有“餐饮行业”，但数据里用的是 MCC 编码。第一步是把行业描述映射为 MCC 5812，再据此筛出适用规则。

筛出 46 条适用规则后，按每条规则分别计算：

手续费 = 固定费用 + rate × 交易金额 ÷ 10,000

对 46 个结果取算术平均，得到 0.123217 欧元。

这里必须说明一个口径问题：平均的是 46 条规则各自算出的手续费，没有按实际交易分布加权。因此它不能当成商户实际每笔平均支付的手续费，只能理解为“在该条件下，规则集合的平均费率水平”。

另外要注意单位：rate=14 表示万分之 14，即 0.14%，不是 14%。误读为 14% 会把按交易金额计算的费率部分放大 100 倍，即两个数量级；包含固定费用的总手续费不一定按同一倍数变化。

酒店数据实战：品牌榜为什么会变

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

酒店品牌榜上，平均 5 星的品牌为什么不一定第一？

这次用公开评测原题走一遍完整链路：数据 → 问题 → 解法 → 验收。重点不在算出答案，而在看清资格门槛和分母选择如何改变结论。

数据与题目

数据集是 InfiAgent-DABench，评测从 CSV、自然语言问题和约束出发，检验能否真正执行分析并给出结果。本次固定题单有 257 题、引用 52 份 CSV；这里只取其中的 hotel_data.csv，1,057 行、9 列，覆盖 7 个城市和 103 个非空品牌，每行是一条酒店记录。

选择的是 510、513 两道 medium 题。

510：评价数至少 100 的酒店中，哪个品牌平均星级最高？还要求品牌、星级非空，品牌在全表至少 10 家，按算术平均计算，出现并列时再看全表规模。

513：评价数与 bubble_score 的相关，在不同星级组里分别是多少？注意 bubble_score 和酒店星级不是一个字段。

两道题都设置了约束，这使它们比“算个平均值”更接近真实工作：约束决定谁有资格参与，也决定分母是什么。

解法：把 510 拆成两路

第一路在全表计算品牌规模，确定参评资格；第二路筛出有效酒店，计算星级总和与均值。最后在品牌粒度汇合。

筛选路径：

步骤	行数	说明
全表	1,057	所有酒店记录
品牌规模 ≥10 家	—	确定参评品牌
星级、品牌非空	332	具备评分所需字段
评价数 ≥100 且星级、品牌非空	296	符合酒店级条件
应用品牌规模门槛后最终参与排名	125 家 / 6 个品牌	同时满足品牌与酒店两级条件

第一名 Preferred Hotels & Resorts 在全表有 21 家，参与评分的有 19 家，星级总和 83.5，均值 83.5 ÷ 19 = 4.3947。

腾讯云 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 消耗。

把 15 个 Skills 变成可验收的 Agent

Sat, 17 Oct 2026 00:00:00 +0000

装好 15 个 Skills，就等于有了一个可靠的 Data Agent 吗？

还差最关键的一步：把“会做什么”变成“怎样证明已经做好”。

这一篇不是新的官方 Skill，而是基于前 9 期原文整理的产品化方法。文中提到的任务协议、验收链和陷阱清单都是编辑整理的框架，不是原文定义的统一规范。

别把 Skill 数量当成系统成熟度

工作流需要按任务选择：补背景、定指标、诊断变化、检查质量、组织计算、表达或发布。

不是每次都串行跑一遍，也不是 15 个文档就代表 15 个独立 Agent。原文的口径一直很明确：主 Skill 只有一个，支持 Skill 按需加入，由主 Skill 决定什么算完成。

真正重要的是交接：前一步交给后一步什么证据？来源缺失时停在哪里？完成条件由谁核验？

这三个问题，正好对应下文的协议、工作链和验收链。

给每个任务写一份小协议

建议至少写清六项：

要素	要回答的问题
输入	这个问题需要哪些必要信息才算清楚
必需来源	哪个系统或文档控制这个答案
允许的方法	可以做什么、不可以做什么
交付产物	输出是什么形态、给谁看
验收条件	什么证据能证明任务完成
失败分支	来源缺失、口径冲突、证据不足时怎么办

以“解释留存变化”为例：

输入需要窗口、人群和产品范围；缺任何一个都应该先问。
必需来源不可用时暂停，而不是拿相邻口径代替。
输出不能只有“下降了 3%”，还要有定义、证据、备选解释和限制。
验收要求关键数字可复算，且比较基线明确。

六项写全之后，一个任务的“完成”就不再依赖模型的自我判断。

同时设计工作链和验收链

分析负责形成判断，验证负责检查判断有没有超出证据。

两条链并行推进，而不是串联：在工作链里，Metric Diagnostics 形成解释；在验收链里，Validate Data 检查这个解释的方法、数字和措辞。

高风险结论应当复算数字、核对口径、检查比较基线与表达边界，而不是让模型再润色一遍。润色只会让措辞更自信，不会让证据更充分。

可复用的语义层值得保存，但当前分析的临时背景不必全部写入。维护动作和任务分析要保持边界，否则语义层会被一次性上下文污染，反而降低可靠性。

用六类陷阱检验真实表现

这是最实用的一部分：与其问 Agent “你会不会”，不如设计具体的失败场景。

发布的是快照，不是实时系统

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

把分析结果发布成一个网址，团队就有了实时数据系统吗？

没有。Publish Artifact to Sites 的原文第一件事就把这个边界说清楚：发布的是快照，不会自动添加实时数据源连接。

这条边界决定了后续所有设计：访问权限怎么设、版本怎么管、交接时该说什么。

不是把一段草稿丢上网

发布之前，报告或看板流程应当已经产出完整的规范化结构与受控数据快照，并通过验证。

这个 Skill 负责接住合格产物，组织打包、版本保存、部署和核验。它不负责分析，也不负责判断数字对不对。

因此，发布成功不能替代分析验证。一个错误数字，不会因为有了分享链接就更可信；反过来，一次成功的部署也不能证明数据是最新的。

同一份逻辑产物，复用同一个站点

原文建议：一个逻辑报告或看板对应一个 Site；后续更新发布新版本，而不是每次重新建一个零散网址。

这个约定把两个问题分开了：

“报告是谁”：稳定的身份，对应固定的地址和访问策略。
“当前是哪一版”：每次发布产生一个版本，对应一个数据截止时间。

如果不这样分，团队的聊天记录里会散落着十几个链接，没人说得清哪个是最新、哪个还能打开。

更新成功之后仍要核对部署状态。原文的要求是轮询到终态，而不是把“开始发布”当成“已经可访问”。

有链接，不代表访问范围正确

原文要求读取当前访问策略，并严格验证是否只有创建者有权限。

这里有一组容易混淆的权限：

权限	控制什么
读者访问	谁能打开页面看内容
演示编辑	谁能在页面上修改文字与布局

读者权限和编辑权限是两件事。把页面分享给更多读者，不应该顺带给出编辑能力；反过来，给创建者编辑能力，也不应该扩大读者范围。

原文还规定：启用编辑时，指定创建者可以修改文字和布局，或发起刷新、导出交接；这些展示层面的覆盖保留在 Sites，不会反向同步到桌面端。这一点需要在使用前说清楚，否则团队会误以为编辑结果会回写到源文件。

自动发布有条件，不是普遍承诺

原文区分运行模式：

在明确识别的工作模式下，且完整的 Sites 生命周期工具可调用时，持久产物按自动路线发布。
桌面端非工作模式，则要求明确请求或接受分享建议。

原文也给出了失败处理：如果完整生命周期不可用，或在工作模式下重试一次后仍失败，应自动切换到所属工作流的自包含 HTML 模式，简要说明失败阶段，并且不能声称站点已经发布。如果用户明确只要 Sites，就如实报告阻塞，而不是擅自换交付面。

这是该仓库版本的路由规则，不代表任何具体环境已经具备相应权限，也不表示所有内容都可以自动公开。

最终交接要说明三件事

原文要求在交付时明确：

页面在哪里：可访问的地址。
数据截至什么时候：快照对应的时间点。
它是快照而非实时连接：后续数据变化不会自动反映。

第三点最常被省略，也最容易造成误用。业务方拿到链接后，会默认它是“当前数据”；如果实际是三周前的快照，基于它做的决定就会出错。

失败时还应说明失败阶段，并按允许的路线回退。

一个常见的误解链

这条链在实践中反复出现：

“数据在仓库里，所以页面是实时的。”
“页面能打开，所以数据是对的。”
“链接发出去了，所以任务完成了。”

每一步都不成立。页面是快照，正确性来自前置验证，任务完成取决于接收者能否正确使用。

原文的设计恰好逐条对应：快照要有截止时间，验证要在发布之前，交接要说清边界。

设计自己的发布流程时

三个可以立刻用的检查：

发布前，产物是否已经通过验证，并带着受控的数据快照？
站点是否复用了同一地址，而不是每次新建？
交接信息里，是否同时写清了位置、截止时间和“非实时”？

发布能力解决的是“怎样共享一个已验证版本”，而不是一键变成实时 BI。更新、权限和证据边界，仍然需要明确的产品设计。

参考：OpenAI Data Analytics Skills 公开参考仓库

看板与报告：共用可信底座，但完成不同的工作

Thu, 15 Oct 2026 00:00:00 +0000

看板越做越像长文，报告越做越像指标大屏，往往不是设计问题，而是没有先分清：读者到底要持续看状态，还是理解一次判断？

Data Analytics Skills 用两个 Skill 处理这件事：Build Dashboard 和 Build Report。它们共享一套可信底座，但服务的目的、结构和验收标准都不同。

看板：让人持续知道发生了什么

Build Dashboard 的第一步是明确看板简报：谁用、监控什么、多久刷新、需要哪些过滤和访问权限、交付面在哪。

原文要求先判断看板属于哪一类，因为这决定了布局和验收标准：

状态监控：持续看有没有异常。
周期性经营复盘：按节奏对比目标与计划。
分析性探索：支持临时的多角度下钻。

这个分类很实用。很多“看板很乱”的问题，本质是把三种目的塞进了同一个页面：监控区被探索控件淹没，复盘所需的对比基线又被省略。

指标模型要有分层，但不要凑数

原文要求按测量对象选择平衡的指标模型，而不是套固定清单。

通常需要考虑的指标族包括：主结果、驱动、护栏、明细与诊断。原文特别提醒，没有要求固定放四张指标卡——数量由决定需要什么来确定，不要为了排版凑数。

另一条要求是默认视图要直接回答主要问题，而不是让读者先点一圈筛选器。过滤器和参数是为追问服务的，不是进入看板的前置门槛。

报告：让人理解为什么这样判断

Build Report 的起点是报告要完成的工作：用户问题、要支持的决定或行动、主要受众、范围、时间框架、比较基线、成功标准。

原文要求恰好选择一个受众：

产品与业务相关方：产品、业务、管理层、战略、诊断、KPI 读数和一般相关方报告。
技术受众：用户明确要求技术或方法优先的报告，或者报告的主要价值在方法论。

受众的选择不是措辞风格问题，而是结构契约问题。同一份证据，写给管理层要答案先行，写给技术读者要方法先行。

报告的结构不能只有摘要

原文在动手之前要求先写出“报告骨架”：

问题
对决定有用的答案
指标、队列、分母、时间窗口与比较基线
按细分或驱动组织的发现，附支撑证据
比较性或因果邻近结论所需的敏感性或验证检查
会改变解读的注意事项
建议的下一步、监控点或未决问题

然后设了一道“深度闸门”：只有标题、执行摘要和一张图表或表格的报告，除非用户明确要求简报，否则应当先扩充证据路径。

它同时规定：一段总结配几张图，不自动等于完整报告。图旁要解释读法、发现和含义；比较性发现要交代人群、分母、时间与基线；因果表述附近必须放限制说明。

共用可信底座，不代表共用版式

两者都需要可靠来源、统一指标口径、足够的数据检查与可追溯记录。

差别在于对账的对象不同：

维度	看板	报告
对账对象	卡片、图表、明细之间能互相解释	每条主张能找到对应证据
时间处理	数据新鲜度、刷新节奏	比较窗口、基线、截止时间
读者动作	发现异常后去追问	读完形成一个判断
主要失败	数字对不上、刷新滞后、越权可见	结论超出证据、限制缺失

原文对数据的要求也很直接：来源路径必须在渲染之前找到；核心看板数据不可用时应当停下，不能拿样例数据冒充真实业务看板，除非用户明确要的是演示原型。

完成标准不同，但都要打开检查

看板的完成标准：默认视图可用、过滤器行为正确、指标对账通过、数据新鲜度达标、权限正确、性能可接受。

报告的完成标准：阅读顺序清楚、证据解释到位、限制与可行动结论完整、每条主张可追溯。

两者还有一条共同要求：必须打开最终产物检查。聊天里说“已经完成”，不是文件或页面真实可用的证明。

这条规则针对的是一种典型的 Agent 失败：工具调用返回成功，模型据此宣布完成，而实际渲染出来的页面是空白或错位的。

算得能复现，图才有说服力

Wed, 14 Oct 2026 00:00:00 +0000

同一张图，换个人重跑就变了；同一组数据，换个坐标轴又像另一个故事。Data Agent 的可信度，常常就在这些细节里掉下来。

Data Analytics Skills 把这段工作分成两个 Skill：Jupyter Notebooks 让计算能复现，Visualize Data 让表达不误导。前者负责“这数怎么来”，后者负责“这图能说明什么”。

Notebook 不是代码草稿堆

原文要求先锁定 Notebook 的模式和范围：它是分析报告、实验日志、诊断记录、质量检查、市场估算、模型探索，还是配套产物。读者是谁、支持什么决定、预期交接什么，都要先明确。

分析型 Notebook 的默认结构是：

## tl;dr
## Context & Methods
## Data
## Results
## Takeaways

关键约束是：tl;dr 和 takeaways 要在看过执行输出之后再写。摘要里要出现具体的观察值、可见的模式、行数或图表，而不是事先的假设。当假设影响正确性时，还要在 Context & Methods 下加一节 Key Assumptions。

这个顺序和很多人的习惯相反。常见做法是先写结论，再跑数验证；结果是结论和实际输出之间悄悄产生了偏差，而读者看不出偏差在哪里。

分离步骤，记录来源

原文要求把环境准备、导入、参数、数据加载、数据准备、计算、可视化和解读分开。如果同时使用 SQL 和 Python，复杂 SQL 应保留在 SQL 单元或独立查询文件中，而不是塞进 Python 长字符串。

代码单元要短、要单一职责：一个单元做一件事，前面配一句说明目的、假设和预期结果的 Markdown。多个表格或图表应拆到不同单元，而不是从一个单元里倾倒出所有输出。

对于支撑分析的每个已执行结果，原文要求记录来源：查询链接、请求 ID、源路径、看板链接、提取名称或其他来源产物。重查询要有过滤和边界，不要让 Notebook 变成对实时源的广泛扫描。

跑完，才谈得上复现

完成条件不是文件能打开，而是从头到尾成功执行。原文给出的命令是：

python -m jupyter nbconvert --execute --to notebook --inplace path/to/notebook.ipynb

如果受数据权限、依赖、内核或凭证限制无法执行，应明确说明，并给出在本地验证所需的确切命令、缺失依赖、凭证、数据访问或环境步骤。不能把旧缓存当成这次运行的证明。

数据质量与分析验证：两道门守住不同的风险

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

一张表没有空值、没有重复，分析就能放心发吗？

未必。数据全对，也可能算错；算得对，也可能比较错了，或者把相关性写成了因果。这三类失败发生在不同的环节，需要用不同的检查去拦。

Data Analytics Skills 把它们分成两个 Skill：Analyze Data Quality 检查数据，Validate Data 检查分析。两道门分别守住不同的风险，缺任何一道都会漏。

先问数据适不适合这次用途

Analyze Data Quality 的起点不是数据本身，而是用途和粒度：一行是用户、订单、订单明细，还是事件？

这个问题决定了后面所有检查是否有意义。订单号重复，不一定是脏数据，也可能是合法的明细行。如果粒度判断错了，去重反而会删掉有效记录，把一个正确的数据源变成错误的分析输入。

原文要求先确认：数据集代表什么、预期粒度、主键或候选键、重要日期列、时区假设、领域规则、允许取值和业务阈值。缺失的上下文应当谨慎推断并标注为假设，而不是默默补齐。

质量检查要按数据形态选

确认粒度之后，再选择高价值检查。原文给出的默认覆盖面是完整性、唯一性、有效性、一致性、完整性约束、时效性、体量与形态。

它也按数据形态给出不同的重点：

数据形态	典型检查
事件数据	重复事件 ID、未来时间戳、会话或用户覆盖缺口、发布后事件结构突变
维度表	非唯一业务键、孤儿代理键、状态变化缺少时间戳、参考值异常流失
事实表	混合粒度、不可能的量值（负收入）、Join 膨胀、迟到或部分加载的分区
特征与评分表	结果字段泄漏、特征稀疏度突增、模型变更后的分布漂移、标签漂移
实验数据	重复分流、分组不均衡、有曝光无分流、分流时间戳之前的事件

一条重要的方法论：比较比例，而不只是计数。1,000 条空值在一个亿级表里和在十万级表里，意义完全不同。同时按时间、来源、国家、平台、模型版本等维度分组，才能区分真实问题和预期波动。

质量报告要解释影响

“发现空值”只是检查结果，不是质量报告。

更有用的写法是：哪些日期、来源和人群受影响；会不会改变分母；会不会造成关联丢行；会不会让看板滞后。原文要求把每项发现与下游风险绑定：破坏可信分析、造成有偏决策、打断 Join、让看板过期、让实验失效、让模型特征不可靠，或者让细分结论失真。

每项发现应带证据、风险、严重度、置信度和最小修复建议，并保留 SQL 或 Notebook。原文对自动化的态度是克制的：稳定规则适合做成自动化测试，波动较大的指标不宜套死阈值。

一个容易被忽略的中间层

粒度之外，还有一类问题最容易被漏掉：时间维度上的完整性。

当用户说“从某天开始”“突然”“最近才出现”时，原文要求优先做时间诊断：首次出现日期、最后出现日期、每日或每周的空值率趋势、重复率趋势、行数趋势、类别份额变化、分布漂移，以及发布、迁移、事故、模型变更和回填前后的变化点。

这类检查之所以重要，是因为很多“业务变化”其实是采集或管道变化。把它们当成业务问题去解释，会浪费大量时间，还会得出错误结论。

再问分析能否支持决定

Validate Data 的对象是分析、图表、报告和建议——不是数据表。

它先提取关键主张：主要问题、受众、决定、头条数字、数据来源、时间窗口、人群、过滤、比较基线和已声明的限制。然后核对方法：人群、资格规则、排除项、抽样、指标定义、公式、单位、分母、时区、队列、比较期和基线，是否与这个决定匹配。

原文特别点出几类隐藏问题：隐藏的排除项、不一致的定义、部分周期比较，以及缺少实验或可靠因果证据的因果措辞。

独立复算，而不是再读一遍

Validate Data 要求独立重算影响最大的数字，检查粒度、小计、分母、非零分母、比率基数、环比基数、加权平均、单位、币种、时区处理，以及互斥类别是否加总到总数。

对 SQL，还要检查 Join 类型、Group By 粒度、过滤、去重计数，以及 Join 前后的行数变化。

教学示例：A 渠道 9 次转化、10 次访问，转化率 90%；B 渠道 50 次转化、100 次访问，转化率 50%。两组率直接平均是 70%，但整体应为 59 ÷ 110 ≈ 53.6%。记录没错，平均方式错了。

市场有多大：别只报一个数，要交付一套能追问的估算

Mon, 12 Oct 2026 00:00:00 +0000

“这个市场有多大？”Data Agent 最容易给出的，是一个看起来很精确的数字。最难交付的，是一套能追问、能调整的估算。

Market Sizing 这个 Skill 的重点不是帮答案补几个零，而是让规模估算有边界、有来源、有假设，并且在证据不足时明确说出不足在哪里。

先说清楚在估什么

原文要求在估算之前锁定五件事：

要素	需要明确的内容
对象	产品类别、工作流、问题、用例，还是某类活动
范围	地区、细分、时间跨度、市场成熟度
成员	谁或什么算在市场内：人群、需求单位、交易类型
单位	支出、收入、数量、创造的价值
问题类型	TAM／SAM／SOM、进入机会、扩张空间、支出池、收入池

这一步看起来像流程形式，实际上是估算质量的分水岭。估“收入”和估“交易额”会得到完全不同的数量级；把“意向客户”算进市场，和只算“付费客户”，结论可能差一个量级。

TAM、SAM、SOM 也不必每次都凑齐三层。原文的口径是按问题需要选择，而不是按模板填满。

选择最简单、站得住的方法

原文给出三类方法，各自适用条件不同：

自上而下：存在可靠的市场总量数据时，从总量拆解。
自下而上：市场可以由可观察的单元和假设搭建时，从单元累加。
价值法：估算应从创造的价值出发，而不是从已发布的市场总额出发。

混合方法适合交叉核验，但原文并没有要求每次必须双算。只有当交叉核验能实质提升信心时才值得做。

如果两条路径差得很远，正确动作是先查边界、单位、覆盖和假设，而不是把两个结果平均成一个“更稳”的数。平均会掩盖真正的分歧来源。

把三类输入分开

这是整个 Skill 里最实用的一条约束：把已查证的事实、用于替代直接数据的代理输入、以及主观判断，分别标注来源与可信度。

输入类型	例子	处理方式
已查证事实	公开财报中的市场规模、官方统计	标注来源与日期
代理输入	用相邻品类的客单价替代本品类	说明为什么可替代、局限在哪
主观假设	采用率、渗透速度、转化比例	标注为假设，给出区间

常见的失真发生在边界处：行业均值悄悄变成自己的成交价，意向客户被当作付费客户，试点转化率被外推到全量。

原文还设了一条硬规则：如果缺少的是必需的权威来源，应暂停这条估算路径，请用户补充或认可替代来源，不能拿更弱的数据冒充同等证据。如果缺的只是可选的补充信息，可以继续，但要在影响结论时标注缺口。

模型要能改，别只留最终值

原文要求模型可审计、可修改，至少包含：

市场定义与计量单位
假设与来源上下文
计算链与派生值
基准情形、实质区间与敏感性逻辑
验证优先级

每个主要输入都要能看到来源路径：结构化数据、上下文渠道、公开来源、用户输入，还是代理假设。派生值应当能追溯到公式或代码，而不是硬编码的结果。

教学示例：1 万家企业 × 40% 可服务比例 × 2,000 元年费 = 800 万元的年收入池。这是满足假设时的可服务规模，不是已经实现的收入。

指标跌了，先复现变化，再谈原因与行动

Sat, 10 Oct 2026 00:00:00 +0000

“转化率跌了，肯定是新版本不好用。”

这句话跳过两个问题：指标真的可比吗？变化真的来自产品体验吗？在具体排查中，需要先排除口径、覆盖或分母变化，再判断业务本身是否发生了变化。

Data Analytics Skills 把这段工作分成两个 Skill：Metric Diagnostics 解释变化，Product & Business Analysis 把解释转成有证据的业务选择。前者对“发生了什么”负责，后者对“该做什么”负责。

第一步不是找原因，是复现变化

原文把诊断拆成一个明确顺序：先定义问题，再验证来源，再建立模式，最后才分解驱动。

“建立模式”这一步最容易被跳过。它要求先量化变化的规模、时间与范围：跌了多少、从哪天开始、影响哪些人群和粒度。在规模、时间和范围被验证或明确标记为不确定之前，不应该开始搜索原因。

原因是最容易“找”出来的东西。只要愿意，任何一次下跌都能配上一段听起来合理的故事。先复现变化，是用数据把可解释的空间收窄。

口径与来源要一起验证

Metric Diagnostics 要求确认指标定义、粒度、聚合逻辑、过滤、Join、排除规则、时效与血缘，并检查可信表面之间是否存在分歧。

它也提醒不要被熟悉的表名迷惑：当前上下文、命名语义层和常见表名都只是来源候选，不是来源选择。对于宽泛的指标问题，应该在可用的表、看板、指标文档和语义层中做一次实际发现，并同时检查一个业务表面和一个底层来源，然后说明为什么选定的来源控制这个答案。

这一步在实际工作里经常被压缩成“用我们平时用的那张表”。如果那张表的粒度或过滤和这次的决策不匹配，后面所有精致的分解都会建立在错误的基础上。

率、加总与分组：三种诊断路径

原文按问题类型给出不同的诊断方式：

指标变化：对比窗口与基线，排序列出分组贡献，检查同行与历史背景，区分结构变化与组内变化。
尖峰、回退或事故：锁定起点、峰值、恢复、分布形态（而不只看均值）、受影响切片，以及是否发生流量或失败行为变化。
集中度与最大贡献者：先定义“最大”，再排序、比较份额与变化，找出主要变动者、进入者与退出者。
对账与差异分析：对齐定义、过滤、粒度、分子、分母与排除项，量化各组成部分，并说明残差。

对率类指标，要先看是分子变了还是分母变了。对加总指标，要计算贡献份额。当结构变化与组内表现同时存在时，两者的区分往往决定解释的走向。

一个容易被误读的例子

教学设定：高转化渠道的转化率始终 20%，低转化渠道始终 5%。前期两个渠道访问量各占 50%，整体转化率 12.5%；本期访问占比变成 20% 和 80%，整体转化率降到 8%。

复算：

前期：0.5 × 0.2 + 0.5 × 0.05 = 0.125
本期：0.2 × 0.2 + 0.8 × 0.05 = 0.08
差值：−0.045，即 −4.5 个百分点

各渠道自身的转化率一点没变，整体却跌了 4.5 个百分点。这是典型的结构效应（mix shift）。

这个例子说明了诊断的边界：算术分解能说明“变化如何组成”，但不能证明渠道占比为什么变了。要回答后者，需要继续核实流量来源和业务动作。把结构效应直接写成“渠道质量下降”，就是把解释力用超了。

测量问题也是解释，不是清理工作

原文特别强调：日志变更、近期数据未齐、重复记录、分母漂移，都可能是变化的真实原因，而不只是需要“清理掉”的噪音。

从定义成功到持续经营：KPI 系统的完整闭环

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

很多团队有一长串 KPI，却说不清三件事：什么叫成功、当前是否在轨、下一步该做什么。指标数量增加，判断力反而下降。

Data Analytics Skills 把这件事拆成两个 Skill：Design KPIs 负责定义成功，KPI Reporting 负责把实际表现、目标、驱动和行动组织成经营读数。两者合起来，才是一条从度量契约到持续经营的闭环。

本文基于公开 Skill 文档做结构化解读。文中的 AI 数据分析 KPI 是教学示例，不是 OpenAI 官方指标；Skill 文本描述的是预期方法与边界，不代表任何真实业务基线。

先明确决定，再选择指标

指标不是越多越好，也不是越漂亮越好。Skill 原文要求先回答：这套指标要支持谁、在什么节奏下、做什么决定。

这个顺序很容易被跳过。团队通常先问“我们该看哪些指标”，于是把能算的都算出来，再挑几个看起来重要的放进看板。结果是每个指标都有人负责解释，却没人对“成功”负责。

原文给出的筛选标准有六项，可以当作候选指标的过滤器：

标准	要回答的问题
反映真实目标	它是结果本身，还是只是容易涨的替代量
能改变决定	数值变动后，团队会做什么不同的事
及时给出信号	在决策节奏内能看出变化，而不是一年后才揭晓
有可控杠杆	团队是否有办法影响它
可稳定测量	能否持续、一致地计算，而非一次性手工统计
不易刷高	提升它是否会悄悄损害质量、信任或成本

最后一条最容易被低估。“不易被误导性地改善”意味着指标本身要带防作弊结构：如果提升转化率可以通过放宽资格实现，那么这个转化率就必须和资格指标一起看。

原文建议收敛到 1–3 个主 KPI，每个主 KPI 在有助于诊断时配 1–2 个驱动指标，在存在权衡时配 1–2 个护栏。除此之外的指标，只有在能实质改善决策时才值得加入。

三层结构：结果、驱动与护栏

指标体系不是平铺的清单，而是三类关系：

Outcome（结果）：最终想改变什么。
Drivers（驱动）：通过哪些可控路径影响结果。
Guardrails（护栏）：哪些底线不能被牺牲。

以一个 AI 数据分析产品为例，教学设定可以是：

层级	示例指标	它负责回答
Outcome	决策可用的分析完成率	分析是否真的支持了决定
Drivers	首个有效答案耗时、可验证来源覆盖率	哪些环节决定结果
Guardrails	返工与错误率、单任务成本、端到端延迟	代价是否可接受

这个结构比“一个总分”更有用，因为总分无法告诉你该改哪里。结果下滑时，驱动指标说明是慢了还是错了；护栏指标说明修得对不对。原文同时提醒：不要在没有来源定义支持时凭空发明因果层级。驱动关系应该来自业务实际如何运作，而不是为了让图好看。

别急着查数：先把业务背景收集到足以继续

Thu, 08 Oct 2026 00:00:00 +0000

“帮我看看转化率为什么下降。”如果 Data Agent 立刻找表、写 SQL、切渠道，它很可能高效地回答了错误问题。转化率的分子分母是什么？看注册、激活还是付费？变化发生在哪个窗口？结论要支持谁做什么决定？

Gather Business Context 的价值，是在计算前把请求放回业务坐标系。它不负责完成整场分析，而是交付一份足以让下一步安全开始的 Context Note。

先定义这次分析要改变什么

有效的起点不是“请给我更多资料”，而是四个边界：业务区域、目标人群、变化窗口、待做决定。它们决定后面该搜什么，也决定什么材料可以忽略。

如果决定是“本周是否回滚新版注册流程”，两年前的行业报告几乎没有控制力；近期实验配置、埋点变更和产品负责人的发布说明更重要。

用搜索锚点代替宽泛关键词

搜索可从四类锚点组合展开：实体（指标、功能、实验、客户）、责任（Owner、团队、评审会）、时间（发布日、事故周、复盘窗口）和来源（看板、文档、表、会议）。

结果太多就组合锚点，结果太少就更换同义词或放宽时间。一次没有命中，只能说明当前检索策略没找到，不能证明业务背景不存在。

让证据逐步收敛，而不是堆成资料库

聊天、会议和旧报告适合发现线索；上线记录、事故复盘和负责人说明更接近实际工作；指标规范、正式决策、当前实现和权威数据源更可能控制定义与状态。

对每条材料只记四件事：适用时间、来源类型、建立的事实、已知限制。问题不是“它有没有提到这个词”，而是“它到底能证明什么”。

冲突本身也是上下文

旧计划写“次日活跃”，当前看板却用“七日内回访”；会议说实验全量，配置记录显示只有 30%。这种矛盾不能在摘要中被整理掉。

通常，较新的明确决策强于旧计划，Owner 的原始材料强于转述，当前实现强于预期状态。但证据仍不足时，应并列保留两种说法，并指出由谁或哪份记录裁决。

Context Note 应该固定结构

一份可交接的上下文笔记至少包含：业务含义、为什么现在重要、受众与待做决定、指标定义与时间边界、控制来源、近期变化、冲突和未决问题。最后还要说明下一步最适合进入哪个分析工作流。

固定结构的好处不是形式整齐，而是避免搜索结果牵着分析走。团队可以直接看到哪里有事实、哪里只是解释、哪里仍需确认。

什么时候停止搜索

上下文收集没有天然终点。实用的停止条件是：问题、受众、时间和决策边界已清楚；关键定义能追到来源；近期变化和冲突已记录；剩余缺口不会阻止下一步，或已明确需要谁补充。

目标不是“收集完整”，而是“足够继续”。继续搜索只有在新证据可能改变任务范围、指标定义或决策时才有价值。

从背景到分析的交接

交接时应区分事实、解释与未知，并附上控制来源和适用日期。接手的诊断或报告 Skill 不必重新翻一遍资料，也不会把临时讨论当成正式定义。

优秀的数据分析往往不是从更快计算开始，而是从避免答错问题开始。Context Note 是这个边界的最小可审计产物。

参考：OpenAI Data Analytics Skills 公开参考仓库

15 个数据分析 Skills，谁来决定该调用哪一个

Wed, 07 Oct 2026 00:00:00 +0000

一个 Data Agent 同时会做指标设计、异动诊断、质量检查、Notebook、图表、看板和报告，听起来很强。但能力越多，越容易出现一种隐蔽失败：每个工具都调用了，真正的问题却没有被负责。

Data Analytics Skills 的 Index 值得看，不是因为它列出了 15 个 Skill，而是因为它承担了四件更接近控制面的工作：判断任务是否属于数据分析、选择谁负主责、处理来源冲突，以及定义什么叫完成。

第一道门：这真的是数据分析任务吗

“做一份报告”“研究一下市场”“验证这个观点”都不自动等于数据分析。判断标准应该是：结论是否依赖结构化记录、数值指标或可计算证据；用户是否需要据此做产品、运营或资源决策。

这道资格门很重要。普通写作被误路由到分析链，会制造不必要的查询和伪精确；真正的量化问题被当作写作任务，又会跳过数据验证。

主 Skill 只能有一个

复杂任务可以调用多个 Skill，但最好只有一个对最终问题负责。

请求	主 Skill	支持 Skill	完成标志
“周活为什么跌了？”	`metric-diagnostics`	业务背景、报告	原因链有证据，报告已检查
“这张表能用于月报吗？”	`analyze-data-quality`	数据验证	风险、缺口和使用条件明确
“建立持续经营看板”	`build-dashboard`	指标设计、可视化	口径、交互和刷新均可验证

主 Skill 决定问题如何收敛；支持 Skill 负责补背景、验证、表达或发布。若每个 Skill 都只是“帮一点忙”，就没人对遗漏负责。

工具可见，不等于获得授权

路由器还需要区分三件事：运行环境提供了什么能力、用户有权使用什么能力、当前任务允许执行到哪一步。看到数据库连接器，不能推断可以查询所有表；能够生成网站，也不代表这次任务允许发布。

因此，能力路由与交付路由应分开：前者决定用什么方法解决问题，后者决定成果能否写入文件、站点或外部系统。

冲突来源不能被悄悄合并

数仓、BI、指标文档、语义层、会议纪要和旧报告可能同时出现一个指标，但权威性、新鲜度和粒度不同。路由前至少要回答：哪个来源控制定义？哪个来源控制当前数值？冲突是否会改变结论？

如果无法裁决，正确动作是保留冲突并指出需要谁确认，而不是挑一个更顺手的数字。

完成门比“已经算完”更严格

分析结束至少要经过四项检查：主 Skill 确实执行；关键结论能够追到来源；方法、数字和图表经过验证；约定的制品真实存在、可打开并适合接收者使用。

这正是 Index 最实用的设计：入口有资格门，中间有责任路由，出口有完成门。数据 Agent 的可靠性，不只取决于模型会不会算，也取决于系统能否拒绝错误任务、选择最小责任链，并在证据不足时不假装完成。

设计自己的路由器时

不要从“有哪些工具”开始列菜单。先为高频请求定义主责任、必要上下文、允许动作、验证条件和失败去向。工具可以替换，责任契约不应该随提示词漂移。

参考：OpenAI Data Analytics Skills 公开参考仓库

隐私与站点统计

Mon, 05 Oct 2026 00:00:00 +0800

当前状态

DataAgentX 是一个静态内容站。站点代码已经支持 Google Analytics、百度统计和 Microsoft Clarity，但只有在配置正式站点的统计 ID 后才会启用。站点发布后，应再次核对本页面，明确实际上线的统计工具。

用于改进站点的数据

启用统计后，相关服务可能处理页面访问、来源页面、大致地区、设备与浏览器特征，以及访客与页面的交互信息。Google Search Console、百度搜索资源平台和 Bing Webmaster Tools 等站长服务还可能提供搜索词、展现、点击、索引状态和抓取错误。

DataAgentX 使用这些信息判断哪些主题对读者有价值、发现失效或加载缓慢的页面、改进导航，并评估内容工作的实际效果。站点不会出售个人画像。

第三方服务

正式站点可能使用：

Google Analytics 4：用于汇总访问与获客分析；
百度统计：用于分析中国访客与百度搜索相关流量；
Microsoft Clarity：用于观察汇总交互模式和排查可用性问题；
Google、百度与 Bing 站长平台：用于索引管理和搜索表现分析。

各服务商依据自己的条款和隐私政策处理数据。如果部署地区要求提供同意或退出机制，应在启用统计代码前完成相应配置。

联系方式与更新

正式上线前，发布者需要补充公开联系邮箱。当统计服务、广告或其他数据处理功能发生变化时，本说明也会同步更新。

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 问题，而不是照抄厂商架构。

关于 DataAgentX

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

把快速变化的概念，整理成可执行的知识

DataAgentX 是一份聚焦数据智能体的独立内容出版物。我们关心的不只是模型能否生成 SQL，而是系统能否在真实的数据、权限与业务语境中完成任务，并交付可追溯、可复核的结果。

站内内容覆盖从概念定义、七层参考架构到语义、规划、执行、验证、治理与交付，也持续跟踪 OpenAI、Anthropic、Google Cloud、AWS、Microsoft、阿里云、腾讯云与火山引擎等产品和实践。中文为主要更新语言，英文版提供核心基础文章与后续精选内容。

我们关注什么

新闻： 记录会影响产品与工程判断的发布、研究进展和行业信号。
产品： 拆解产品定位、能力边界、上下文体系、权限模型与采用条件。
技术： 解释架构、语义、规划、工具执行、评估、治理与生产实践。

编辑原则

系统重于口号。 模型只是组件；数据、语义、工具、验证与治理共同决定生产质量。
证据重于流畅。 查询成功或表达自然，都不能替代口径、来源与结果验证。
边界必须清楚。 区分公开事实、工程建议、案例口径与尚未验证的推断。
能力先于自治。 系统应通过持续评估与真实任务表现，逐步获得更大的行动范围。
双语服务于理解。 中英文共享核心概念与编辑标准，不追求机械逐句翻译。

DataAgentX 希望成为一份可以长期引用的 Data Agent 现场指南：既帮助团队理解行业，也帮助建设者把概念转化为架构选择、评测方法与上线检查清单。

联系我

欢迎围绕 Data Agent 的内容与实践交流。如果你有以下需求，可以通过邮件联系我：

投稿与经验分享： 分享原创文章、技术实践、产品案例或研究成果，也欢迎先交流选题。
问题反馈与内容建议： 指出文章中的错误、补充参考资料，或提出希望进一步讨论的话题与网站改进建议。
商务与合作： 探讨内容共创、技术交流、活动邀请及其他合作机会。

联系邮箱：027xbc@gmail.com

来信时，建议在主题中注明“投稿”“反馈”或“合作”，并简要介绍背景与具体需求；涉及站内内容时，请附上对应文章或页面链接。

火山引擎 Data Agent：问数与深度研究为什么要分流

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

“昨天华东销售额是多少”和“新品复购下降后应该先改产品、人群还是触达策略”，看起来都在问数据，工作形态却完全不同。前者目标明确、数据域窄、答案可快速核对；后者需要拆解问题、组合多类证据并形成有条件的判断。

火山引擎的产品路线把智能问数和深度研究分开，核心不是增加 Agent 数量，而是让不同责任走不同链路。

问数链路追求短反馈

智能问数适合指标查询、归因切片和多轮追问。数据集、字段和业务场景需要预先约束，复杂指标最好在 ETL 或语义层中稳定下来。官方文档给单个 Agent 设有数据集与字段数量边界，也建议围绕单一业务场景和意图配置。

深度研究需要证据编排

开放问题要先形成研究子题，再决定查询哪些数据、检索哪些知识、调用哪些工具。最终交付不应只是一个数字，而要区分事实、解释、假设、建议和未决问题。

两条链共享底座，但验收不同

问数和研究都需要指标语义、身份权限、数据新鲜度与审计记录。不同的是验收：问数看定义和数值能否复现；深度研究还要检查来源覆盖、推理跳跃、反例和建议适用条件。

多 Agent 不等于把同一任务拆碎

若多个角色共享模糊目标、重复访问数据、最后由模型自由拼接，系统只会增加协调成本。合理分工应为每条链定义输入、输出、权限和失败去向，并由协调层决定何时从快速问数升级到研究任务。

试点时可以用同一批业务问题做分流测试：明确指标问题应在短链完成；跨域策略问题进入研究链；证据不足时必须请求补充或降级结论。多 Agent 的价值，来自可验证的责任分工，而不是界面上出现多少头像。

升级条件要写成规则

问数链不应因为回答困难就无限扩展。可以设置明确升级信号：问题包含多个业务域、需要外部资料、存在相互矛盾的指标、需要提出行动建议，或预计超过查询预算。协调层据此创建研究任务，并把已经确认的指标定义、查询结果和未决问题一起交接。

反过来，深度研究也不应把简单问题复杂化。若核心事实可由一次受治理查询回答，就直接返回并保留查询证据。短链负责效率，长链负责不确定性；两者之间的交接质量，决定多 Agent 系统是否真的节省时间。

运营指标也应分开：问数链关注首个可用答案时间、定义命中率和追问修正率；研究链关注证据覆盖、关键反例、建议采纳与后续结果。把两条链混成一个满意度分数，会掩盖各自真正的瓶颈。

还要观察协调成本：一次任务发生多少次路由、重复读取了多少上下文、交接是否丢失来源，以及人工需要在哪一步重新解释问题。若角色增加后这些成本持续上升，说明分工边界需要合并，而不是继续增加新 Agent。

参考：智能分析 Agent 产品文档

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 产品文档

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 的任务，记录预期数据源、关键筛选、行级权限和可接受的汇总结果。每次模型、语义模型或数据源结构变化后回放，重点检查错误路由、静默截断和权限差异，而不是只看自然语言答案是否流畅。

AWS 的三条 Data Agent 路线，解决的是不同问题

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

同属 AWS 的 AI 能力，Amazon Quick、SageMaker Data Agent 和 Bedrock 并不是三个可以按功能数量直接排名的产品。它们从不同用户和责任边界出发。

路线	主要用户	主要交付	团队仍需负责
Amazon Quick	业务用户与 BI 使用者	对话问答、洞察、故事和工作流	Topic 语义、数据权限、答案复核
SageMaker Data Agent	分析师、数据科学与 ML 团队	查询、代码、分析开发过程	环境、成本、代码审阅和复现
Amazon Bedrock	构建自有应用的开发团队	可编排的 Agent 能力	工具契约、身份、状态、评测与 UX

Quick：从问答走向业务工作

Amazon Quick 的新体验强调跨数据集问答和 Agentic 工作流。多数据集 Topics 承担语义层作用。它更接近业务应用，但“能问多个数据集”并不意味着跨域指标已经统一；Topic 设计仍决定术语、字段和聚合是否一致。

SageMaker：把分析过程放进开发环境

这条路线更适合需要查看查询和代码、迭代模型或处理复杂数据的专业用户。优势是分析过程更可检查，代价是环境、依赖、算力成本与可复现性由团队共同承担。

Bedrock：给自建 Agent 一个底座

Bedrock 提供模型与 Agent 构建能力，但不会替企业决定指标口径、工具权限或结果验收。它给了最大自由，也把最多系统工程责任留给开发团队。

选型先问责任归谁

如果目标是让业务用户快速获得受治理洞察，先评估 Quick 的 Topic 和权限；如果核心是分析开发与代码审阅，关注 SageMaker；如果要嵌入自己的流程和界面，才需要 Bedrock 级别的可编程性。

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

Anthropic Skills：把分析经验从提示词变成可维护工作流

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

把模型接到数仓，不会自动得到稳定的分析师。它还需要知道团队怎样检查数据、如何建模、什么图适合表达结论，以及交付前必须做哪些复核。

Anthropic 将 Skill 定义为包含指令、脚本和资源的文件夹，相关时才加载所需内容。这个设计把“每次重新解释工作方法”变成可版本化的工作协议，也允许在需要确定性的环节执行代码。

Skill 封装的是方法，不是知识幻觉

指令可以规定步骤和边界；脚本可以承担清洗、计算或格式转换；模板与参考材料可以约束最终制品。三者组合后，同一套方法可用于表格、文档、演示和 PDF 等不同交付面。

但 Skill 不会凭空补齐企业指标定义和权限。分析类 Skill 仍需显式接入数据语义、来源优先级、允许调用的工具，以及谁负责最终批准。

为什么比一次性提示词更容易治理

Skill 可以进入版本控制，变更能审阅，测试任务能回归，组织也能分发经过批准的版本。它把模型行为的一部分从隐藏对话移到可检查文件中。

代价是新的供应链风险：Skill 可能包含可执行代码，也可能引导模型访问文件和连接器。Anthropic 官方同样建议只使用可信来源。企业至少需要来源审查、最小权限、隔离执行、依赖固定和制品扫描。

分析 Skill 的合理分层

一个成熟工作流通常分成六段：理解用户任务、加载方法指令、取得必要文件与工具、执行可重复计算、生成制品、进行内容与视觉验收。封面图中的每个区块都对应一个可测试的责任，而不是一句抽象的“做分析”。

适合怎么落地

先挑一个高频、边界清楚的交付，例如周度经营复盘。把输入契约、指标口径、异常处理、图表规范和验收清单写进 Skill；将真实历史任务做成回归集；让分析师审阅失败类型，而不是只看平均满意度。

Skills 最有价值的地方，不是给模型增加更多身份，而是把专家经验变成可以维护、组合和验证的工作流。

验收应覆盖过程与制品

分析 Skill 的测试不能只问“有没有生成文件”。过程层要检查输入数据是否完整、公式是否可追溯、异常是否被记录；制品层要检查表格公式、图表尺度、标题结论和移动端可读性。对同一批历史任务做版本回归，才能知道新指令是改进了方法，还是只让输出更像模板。

企业还需要明确失败策略：缺少关键字段时停止并说明，还是用替代口径继续；脚本报错后允许重试几次；生成的文件在发送前由谁批准。把这些边界写进 Skill，才算把经验工程化，而不是把一段更长的提示词放进文件夹。

维护时还应把方法更新与模型更新分开评估。模型升级可能改善推理，却也可能改变工具选择和制品风格；Skill 版本变化则会直接改变步骤与验收。分别固定变量做回归，才能知道质量变化来自哪里。

参考：Introducing Agent Skills

快手 Data Agent：1 万周活背后的规模化系统工程

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

一个 Data Agent 获得 1 万周活，意义不在于聊天框里多了多少提问，而在于它已经进入数据生产、经营诊断和日常交付。快手 2026 年 9 月 19 日技术分享中的阶段性数据，展示了一条从单场景 Workflow 到统一 Agent 入口的演进路径。

分享材料给出的快照包括：周活超过 1 万、核心数据分析与产运岗位渗透率超过 80%、Skill 数量超过 2,000，以及超过 60 万条评测记录。这些数字来自快手材料，未经过独立审计，也不应被理解为对其他组织的效果承诺。真正有参考价值的，是规模背后的系统关系。

先从能够验证结果的黄金任务开始

快手早期从单场景 Workflow 探索，逐步扩展到多场景、Agentic 能力和统一入口。规模化并不是先构建一个“万能 Agent”，而是不断找到高频、价值清楚、结果可核对的任务。

所谓黄金任务至少有三个条件：需求持续发生，节省时间对业务有价值，结果能够通过指标、查询或交付物验证。报告生成、异动归因、数据研发和实验分析都符合这一特征。

父 Agent 负责路由，专业 Agent 承担责任

统一入口接收用户目标，父 Agent 理解问题并选择主站、电商、商业化、安全或海外等专业 Agent。通用 Skill 则承担查数、归因和报告等可复用方法。

这种结构解决的是责任分配，而不只是多角色展示。父 Agent 要判断场景和权限，子 Agent 要在自己的数据域、规则和工具范围内完成任务。材料给出父子 Agent 路由准确率 95% 的阶段性口径；实际部署仍需要持续观察误路由如何被发现、纠正和回归。

Skill 把方法变成组织资产

指标查找、异常诊断、SQL 开发、报告和治理规则可以被封装成 Skill。Skill 市场让业务团队复用方法，也为评审和版本控制提供载体。

数量不是目标。一个有价值的 Skill 应明确输入、允许工具、异常处理、验证条件和交付物。若 2,000 个 Skill 缺少 Owner、版本和淘汰机制，路由成本与维护负担也会迅速上升。

知识飞轮解决模型之外的准确性

快手的架构把知识构建、分层存储、搜索或确定性路由、业务应用连成一条链。数据资产与历史任务被抽取为可服务知识，真实使用产生的纠正再回到知识和评测。

OpenAI 内部 Data Agent：难点不是写 SQL，而是找对上下文

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

表里都有 user_id，为什么两次查询算出的活跃用户仍不一样？企业问数最难的部分常常发生在 SQL 生成之前：应该用哪张表、哪个时间字段、哪套过滤条件，以及哪份定义仍然有效。

OpenAI 在 2026 年 1 月公开的内部实践，把问题中心放在上下文工程。文章给出的当时规模快照是超过 3,500 名内部用户、600PB 数据和约 70,000 个数据集。规模数字很醒目，但更值得借鉴的是系统如何缩小候选上下文。

六类上下文不是同一种知识

来源	提供什么	典型风险
表使用信息	Schema、血缘、历史查询	热门查询未必正确
人工注释	业务含义、已知问题、Owner 经验	可能过期或只适用于局部
管道代码	派生逻辑、过滤条件、新鲜度线索	实现复杂，需结合运行状态
机构知识	文档、讨论、决策背景	权威性和时效差异大
运行时反馈	查询结果、错误和数据分布	只能说明本次执行状态
记忆与纠正	已验证修正和失败经验	必须限制适用域与版本

这些材料不能简单拼进一个超长提示词。系统需要先检索候选资产，再按权限、时间、粒度和问题相关性收窄，并保留为什么选择这份上下文的证据。

查询生成只是中段

一个更完整的链路是：理解意图 → 检索元数据与机构知识 → 选择候选表和可信查询 → 生成与执行 → 根据错误和结果修正 → 独立验证 → 记录可复用纠正。

其中，执行反馈很关键。空结果可能意味着过滤错误，也可能是真实业务现象；SQL 成功只能证明语法和运行环境接受了它，不能证明业务语义正确。

记忆必须有适用边界

“上次把 created_at 换成 activated_at 就对了”不是全局规则。可靠记忆至少要绑定数据域、指标、表版本、时间范围和验证证据。否则一次有效纠正会成为下一次错误来源。

对企业团队的启示

不要先追求覆盖所有数据。先选一个定义相对稳定、Owner 明确、错误代价可控的业务域，建设可检索的资产说明、可信查询、运行时权限和回归任务集。每次纠正都进入审阅流程，而不是直接写入永久记忆。

这套内部实践不是可直接采购的产品规格。它真正说明的是：当数据规模扩大后，Data Agent 的瓶颈会从“能不能生成 SQL”转向“能不能找到、约束并验证正确的上下文”。

Data Agent 厂商地图：按系统位置比较，不按名字排队

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

Data Agent 市场最容易画错的一张图，是把云平台、BI 应用、内部自建系统、开源框架和学术项目放成一排 Logo，再暗示它们彼此竞争。它们可能解决不同任务，处在技术栈不同位置，也承担不同的生产责任。

更有用的地图以系统位置为纵轴，以交付形态为横轴。先找同类，再比较能力。

第一轴：产品位于系统哪一层

数据平台

Snowflake、Databricks、Google BigQuery、Microsoft Fabric、AWS Redshift 等平台拥有数据、计算、权限与治理入口。平台原生 Agent 的优势是能复用这些控制面，限制则是能力通常围绕自身生态展开。

例如 Snowflake Cortex Analyst建立在 Snowflake 语义模型与访问控制上；Microsoft Fabric Data Agent面向 Fabric 数据源并按用户权限查询；Google 同时提供面向分析、数据科学和数据工程的不同 Agent 入口。

语义与治理

这类能力维护指标、实体、关系、血缘、质量和权限。它们不一定以“Data Agent”命名，却决定 Agent 是否理解“收入”和“客户”。选型时要问：语义资产能否被 BI、Agent 和其他应用共同引用，版本和责任人如何管理，而不是只看是否有聊天框。

Agent 平台

平台提供模型、连接器、工具协议、运行时、状态、评测和治理，让团队构建自己的数据工作流。2026 年 9 月发布的 ChatGPT Work Data agent已是面向企业的产品，与 OpenAI 1 月分享的内部自建 Data Agent不是同一个交付边界。内部案例能提供架构经验，不能直接等同于可采购 SKU。

分析应用

BI、Notebook 和分析工作区把 Agent 放进业务用户或分析师已有界面。它们通常在问数、探索、代码分析、图表与报告交付上做得更完整，但底层语义、权限和执行可能依赖外部平台。评估时要沿调用链确认责任，不能只看前端体验。

数据工程与运维

这类 Agent 面向元数据、质量、dbt/Dataform、管道、成本和故障处置。它们可能产生代码或变更建议，甚至写入生产，因此测试、审批、幂等和回滚比问数准确率更重要。

第二轴：它以什么方式交付

形态	适合什么情况	需要承担什么
内部自建	数据和流程独特，已有强数据平台团队	架构、评测、安全、运维和长期迭代全部自担
平台原生	核心数据已集中在一个平台，希望快速复用权限与语义	生态绑定、跨源能力和区域可用性要核实
独立应用	需要跨平台体验或特定分析工作流	连接器、身份透传和数据出口责任要厘清
开源框架	需要可控部署、研究或深度定制	生产语义、权限、维护和支持不会随代码自动获得
学术项目	研究新方法、基准和能力边界	论文结果不等于生产 SLA 或产品支持

同一家厂商可以横跨多层，同一产品也可能在不同版本提供不同形态。地图不是互斥分类，更不是市场份额图。

企业落地 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% 就能上线”。财务报送和探索性分析允许的错误不同。

组织责任必须长期存在

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

Data Agent 榜单怎么看：先读测量链，再看排名

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

看到某个 Data Agent 排名第一，不能直接推导出它最适合企业采购。榜单回答的是：在某套题、数据、工具、预算和评分规则下，哪些提交表现更好。企业真正要判断的是：它能否在自己的口径、权限、成本和故障条件下稳定交付。

读榜时，最有用的动作不是先看分数，而是沿测量链向前追溯。

1. 它到底测什么任务

Text-to-SQL、数据科学代码、跨源分析和完整报告不是同一种能力。先读输入、允许交互和最终交付物：提交的是一条 SQL、结果表、代码仓库，还是带证据的报告？是否允许多轮工具调用、人工提供表名或重试？

BIRD关注大规模数据库内容下的 Text-to-SQL；Spider 2.0包含企业数据库环境、多 SQL 方言与复杂工作流；Data Agent Benchmark覆盖多数据库系统、异构引用和非结构化信息；FDABench则包含结构化数据、文档、网页、图像、音视频和报告任务。四个榜单的分数没有直接换算关系。

2. 数据和上下文给了多少

核对数据库版本、Schema、文档、样例值、业务知识和真实数据内容。是否提供了 Oracle Tables 或正确表集合？是否允许检索外部知识？表名、注释与题目之间是否存在明显线索？

给出正确表名后测到的是查询推理；让系统自己找表，才包含资产发现。两种设置都有价值，但必须分开报告。动态网页或在线数据库还要记录评测日期，因为环境变化会让同一系统得到不同结果。

3. 运行协议是否可比

模型版本、提示预算、候选数量、重试次数、温度、工具、网络、超时和费用都会影响成绩。pass@k 与单次成功率不是一回事；生成 32 个候选再挑最好结果，也不能与一次运行直接比较。

排行榜有时会更新评分器或修复样本。引用数字时应同时记录基准版本、赛道、提交日期和设置，而不是只截一张榜单图片。

4. 评分器判断了什么

SQL exact match 要求字符串或结构接近参考答案，可能错判等价查询。Execution Accuracy 更接近结果，但仍可能在不完整数据、错误业务口径或偶然相同结果下给分。报告任务使用模型评分器或量表时，还要检查其校准、人工复核和偏差。

可靠基准通常组合执行结果、不变量、结构化断言和人工/模型量表。没有任何评分器可以自动证明企业语义、权限和业务价值。

5. 失败如何分类

总分相同的两个系统，生产表现可能完全不同。一个主要失败在复杂 SQL，另一个会选错表、泄露数据或高置信编造。至少区分：来源选择、语义绑定、程序执行、分析推断、拒答、安全、超时和成本。

还要看方差。同一题运行五次，有一次成功和每次都稳定接近正确，对真实用户不是同一体验。报告均值之外，应提供成功分布、置信区间或重复试验。

6. 成绩能否迁移到我的任务

建立一张 Benchmark Card：范围、数据、环境、评分、风险、维护状态和不覆盖项。然后选择与企业工作流最接近的子集，在内部任务上复跑。

公开基准适合定位候选与能力边界，企业黄金集负责最终决定。后者应包含真实身份、指标版本、数据快照、允许与禁止资产、期望产物、拒答条件和错误成本。

一份读榜检查表

检查项	必须记录
范围	用户、任务、模态、语言、行业和不覆盖内容
数据	数据集/快照版本、是否 Oracle Tables、污染风险
环境	模型、工具、网络、预算、超时、重试、随机性
评分	主指标、评分器版本、人工复核和等价规则
稳定性	运行次数、方差、失败类型和置信区间
成本	延迟、Token、扫描量、工具费用和人工时间
维护	负责人、最后更新、变更日志和淘汰条件

把榜单变成采购证据

先用两个互补公开基准筛出候选，例如一个企业 Text-to-SQL 基准加一个跨源分析基准。再选 50–100 个内部任务，以相同身份、快照、预算和停止规则运行。最后进入影子流量，观察人工修改、权限阻断、延迟、成本和故障恢复。

Data Agent 的报告，怎样才算真正交付

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

Agent 生成了一份“新客转化下降”的报告，任务还没有结束。业务负责人要知道结论能否支持决策，分析师要复算关键数字，运营团队可能要创建排查工单。三类接收者需要不同产物，也拥有不同数据权限。

交付完成的标准，不是模型输出了最后一个句号，而是接收者能理解、核验并在授权范围内使用成果。建议、批准、提交、确认生效和业务效果必须分开记录。

这条链的关键是两个分离：报告状态与动作状态分离，执行成功与业务有效分离。

按接收者定义“完成”

接收者	主要产物	完成条件
业务负责人	结论、证据、限制、风险和待决策事项	能区分事实、假设与建议，知道由谁做决定
分析人员	结果表、方法、查询/代码、数据与语义版本	能复核关键数字，不能复算的限制已说明
业务系统	结构化动作草稿、审批、执行与回读记录	目标系统状态已确认，部分失败和未知未被隐藏

同一分析可能需要多个可见范围不同的版本。生成者能读取明细，不代表所有报告接收者也能下载。交付前应按接收身份再检查数据范围。

把声明和证据绑在一起

报告里的每个重要事实声明都应指向结果表、查询/代码、数据快照、语义版本和验证记录。一个最小输出契约可以这样表达：

{
 "task_id": "conversion-review-demo",
 "report_version": 1,
 "status": "partial",
 "claims": [{
 "kind": "observation",
 "text": "已覆盖渠道中观察到转化下降",
 "evidence_refs": ["result/channel-comparison"]
 }],
 "semantic_ref": "conversion/v3",
 "data_snapshot_ref": "snapshot/demo",
 "limitations": ["地区分支未完成，尚无因果证据"],
 "artifact_refs": ["report/v1", "table/v1"],
 "action": {"state": "draft", "type": "create_investigation_ticket"}
}

partial 不能在页面标题里被润色成“已找到全部原因”。动作仍是草稿，也不能对外声称工单已经创建。

图表和文件也要经过验证

表格应展示单位、时间、口径、分子分母、分页和截断。图表不能把缺失值画成零，也不能用截断坐标轴夸大变化。正文数字和图形最好来自同一结果对象，避免复制粘贴后漂移。

报告把关键不确定性放在结论附近，而不是埋在附录。Notebook 和应用要给出环境、输入版本、权限和成本提示，打开页面不应自动触发昂贵或有副作用的操作。

W3C 复杂图像无障碍指南建议为图表提供简短替代说明和传达核心信息的详细文本。对 Data Agent，这也能迫使系统用语言准确陈述图表到底证明了什么。

可复现不是把原始数据都打包

证据包可以把“数据快照—查询执行—结果表—报告声明”连接起来。W3C PROV 概览提供实体、活动和参与主体的溯源概念；实现时不必一开始完整采用标准，但关系要能查询。

复现至少分三层：能找到方法和来源，能在相同环境重跑，能在约定容差内得到等价结果。动态数据、过期依赖和外部服务会限制后两层，应明确标记。复制整份敏感原始数据并不是可复现的必要条件。

从建议到动作是一条独立流程

形成草稿：写清动作类型、目标、参数、依据和潜在影响，默认无副作用。
预检：检查身份、接收者、数据分级、版本、预算和预计变化。
授权：有权人员或策略批准具体参数与有效期，实质变化后重审。
提交：通过行动网关执行，使用稳定逻辑操作 ID 和下游支持的幂等机制。
回读：查询目标系统，区分“请求已接受”和“最终生效”。
恢复：分别处理部分成功、状态未知和不可逆动作。

Amazon Builders’ Library 关于幂等 API 的文章解释了客户端请求标识和安全重试。超时后应先按操作 ID 查询，不能直接重复提交。

OpenAI Data Analytics Skills：把分析拆成可检查的工作协议

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

“最近转化率为什么下降？”一个演示型 Agent 很快就能找表、写 SQL、画折线并列出几个原因。真正交付时，问题才暴露出来：分母是什么，数据是否到齐，渠道结构是否变化，所谓“原因”是计算得到的贡献还是语言模型补出的故事？

Data Analytics Skills 最值得研究的地方，不是某句提示词，而是它把分析工作的责任、交接和完成标准写成了可复用协议。

本文基于公开整理仓库中 15 份 Skill 文档的 2026-10-04 版本进行设计解读。Skill 文本描述期望的工作方式，不等于完整运行架构、线上权限或效果实测。

15 个 Skills 形成五组责任

责任域	Skills	它们要解决的问题
路由与上下文	Index、Gather Business Context、Create Data Context	该不该分析；需要什么临时背景；哪些知识值得长期保存
度量与判断	Design KPIs、Metric Diagnostics、Product & Business Analysis、KPI Reporting、Market Sizing	衡量什么；变化如何构成；证据支持什么决定
可信度	Analyze Data Quality、Validate Data	输入是否适用；计算、方法和结论是否成立
计算与表达	Jupyter Notebooks、Visualize Data	计算是否可复算；图形是否诚实表达问题
交付	Build Dashboard、Build Report、Publish Artifact to Sites	成果如何服务监控、阅读和发布

这不是一条每次都跑完的十五步流水线，也不代表需要十五个独立 Agent。Index 应选择最小够用链，每个 Skill 只承担自己的完成责任。

路由先确定主任务，再决定交付形式

“为什么转化下降”是指标诊断；“把转化下降做成一页报告”仍要先完成诊断，再组织表达。用户提到报告，不会让原因调查自动完成。相反，查询一个定义清楚的指标，也不应自动扩张成全面业务分析。

Data Agent 上线前，权限应该管到哪里

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

区域经理和总部分析师问同一句“渠道转化怎么样”，合法答案可能完全不同。即使数据库查询做了行级过滤，缓存、导出文件或报告分享仍可能把总部数据交给区域用户。

治理不能是一段“请勿泄露敏感信息”的系统提示词。它必须贯穿资产发现、模型上下文、工具调用、执行环境、结果交付和业务动作，并由模型无法覆盖的可信系统强制实施。

模型可以解释策略、请求审批和说明拒绝原因，但不能自行授予权限，也不能用“任务很重要”覆盖拒绝决定。

先画清资产、主体和信任边界

保护对象不只有原始表。字段说明、向量索引、查询结果、缓存、检查点、日志、图表和下载文件都可能泄露数据。主体包括最终用户、Agent 服务身份、数据平台身份、审批人、接收者与连接器供应方。

对每条链路都回答：谁发起、代表谁、读取或改变什么、用途是什么、在哪里运行、结果交给谁。外部文档、网页、数据库文本和子 Agent 消息都属于不可信输入；进入上下文不会让它们获得调用工具或修改策略的权力。

身份需要贯穿整条调用链

优先保留最终用户的权限范围。必须使用服务身份时，按租户、业务域、用途和动作缩小能力，并明确由哪个组件实施用户级限制。连接器能够登录，不等于每个用户都有权查看它连接的数据。

授权输入至少包括主体、租户、资源、字段/行范围、动作、用途、环境、风险等级和策略版本。策略服务返回允许、拒绝或需审批以及有效范围；凭证由服务端管理，不进入提示词。

Microsoft Fabric Data Agent 的分享与权限文档明确区分 Agent 访问与底层数据权限，并继续实施行列级安全。这支持一个普遍原则：入口分享不能替代源数据授权。

缓存和交付是最容易遗漏的出口

缓存键不能只有问题文本。至少要绑定租户、有效权限范围、语义版本、数据版本和策略版本，撤权后立即失效。命中缓存仍要授权，否则总部用户的答案可能被区域用户复用。

“分析师能看”也不代表“报告接收者能看”。导出前按实际接收者检查明细、聚合和小群体推断风险。删除文件中的敏感列，而不是仅在文件名上加“机密”。错误提示也不能泄露无权访问的表名、人员或字段。

提示注入与过度代理是两种风险

提示注入让不可信内容试图改变 Agent 行为；过度代理则是系统本来就暴露了过多工具、权限或自主性。没有注入，一个拥有删除权限的 Agent 也可能因普通判断错误造成事故。

OWASP 关于提示注入的指南强调组合防御：隔离不可信内容、最小权限、输入输出处理和高风险人工确认。把文档放进引号或再用一个模型检测，不构成安全边界。OWASP 关于 Excessive Agency则把过宽功能、权限和自主性列为风险来源。

实践上应把只读查询、写回和对外发送拆成不同能力，只注册任务必要的工具，限制目标和参数。内容检测提供信号，工具网关负责强制拒绝。

审批必须绑定实际动作

不要让审批人只看到“优化投放策略”这种摘要。高影响动作应展示目标对象、参数、数据范围、接收者、依据、预计影响、成本、回滚或补偿方法和有效期。任何实质变化都触发重新审批。

撤销也有真实边界。发送出去的邮件和被下载的文件通常不能保证收回，跨系统动作可能只能补偿而不能原子回滚。因此系统要区分：可事前阻断、可取消、可回滚、可补偿和不可逆。

审计与事件响应要能停止真实动作

审计应连接任务、用户、委派身份、资源、策略、审批、工具参数摘要、执行 ID、结果和接收者。普通日志避免凭证和敏感全文；高风险审计记录需要访问隔离、完整性保护、可靠时间与保留策略。

事件流程至少包括：发现 → 阻断新调用 → 吊销凭证或冻结任务 → 核对在途和已完成动作 → 保存必要证据 → 通知与修复 → 回归验证后恢复。停止聊天模型不会自动停止正在运行的数据库查询，必须在执行端确认取消。

上线前需要哪些证据

最低测试集应包括：

不同身份的资产发现、查询、缓存与导出隔离；
权限撤销后缓存、会话和长期任务是否失效；
用户输入、文档、OCR、数据库文本和工具响应中的间接提示注入；
未注册工具、参数扩张和审批绕过；
凭证是否出现在提示词、错误、日志或制品中；
高风险动作的参数级审批、幂等和状态回读；
下载与分享是否按接收者重新授权；
熔断、吊销和应急演练能否停止实际执行。

越权误放行率应独立报告，并作为上线阻断项。还要测合法请求误拒和审批负担，但不能靠放宽安全门禁改善体验。

NIST AI Risk Management Framework及其生成式 AI Profile可用于梳理责任、风险、测量和处置，但不会替组织自动满足法规，也不能取代技术控制。

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 或邮件分享发现，并使用连接工具执行用户批准的行动。这里的“批准”非常关键：分析建议、动作提案、授权执行和执行后回读应被视为不同状态。

SQL 跑通了，Data Agent 的答案就可信吗

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

查询成功、图表漂亮、报告完整，都不能单独证明答案可信。Agent 可能选错数据源、套错指标口径、执行了正确 SQL 却读到不完整数据，最后再把相关性写成因果解释。

一个总准确率会把这些错误压成同一个数字，也会掩盖高风险失败。更有效的做法是沿分析链逐层验证，并让失败回到真正需要修复的位置。

下层错误会污染上层。来源不对时，评价报告文笔没有意义；发生越权时，再高的平均准确率也不能抵消安全问题。

五层验证，各自回答不同问题

层级	验证问题	失败后回到哪里
来源层	资产、版本、权限、数据水位和覆盖是否正确	接入与上下文路由
语义层	指标、实体、粒度、时间、Join 与过滤是否符合业务定义	语义计划或澄清
执行层	查询/代码能否安全运行，结果是否完整且符合契约	工具参数、代码或运行环境
分析层	比较基线、统计方法、推断和不确定性是否成立	分析计划或补充证据
交付层	结论是否有引用，图表是否误导，接收者是否有权使用	报告、制品或审批流程

每层都应产生结构化结果：pass、fail、unknown 或 needs_human，并附证据。未知不能自动当作通过；同一个模型对自己的答案说“看起来正确”，也不是独立验证。

一道题需要多种正确性

以“哪个渠道导致本月转化下降”为例：

任务正确性：是否回答了“贡献变化”，而不是只列出最低转化率渠道。
数据正确性：是否覆盖本月全部渠道，水位是否完整。
语义正确性：转化率分子分母和新客定义是否一致。
程序正确性：SQL 是否避免重复 Join，查询结果是否被截断。
分析正确性：渠道结构变化是否造成聚合偏差，是否误写因果。
交付正确性：结论、证据、限制和建议是否对应，接收人是否有权限。

只用 exact match 比较 SQL，会把等价查询判错，也会把能运行但业务错误的查询判对。评测应执行查询、检查语义绑定和结果性质，再由规则或人判断分析结论。

建立一套来自真实工作的任务集

通用基准能比较研究系统，但企业上线仍需要自己的任务集。样本应来自实际问法、历史工单、分析报告和失败日志，并按业务域、难度、风险和数据形态分层。

每题至少记录：用户身份、目标、允许资产、禁止资产、语义版本、数据快照、期望产物、可接受变体、必须拒绝的行为和评分规则。开放分析不必只有一个标准答案，但应有事实不变量、必须覆盖的假设和不可越过的推断边界。

困难样本不能只靠“更长问题”制造。真正有价值的是同名表、歧义指标、权限差异、数据延迟、空集与零、工具超时、冲突证据和无法回答的问题。

指标要与失败成本对应

一组更实用的指标包括：

资产选择与覆盖：Hit@K、Recall@K、跨源完整集合覆盖率。
语义绑定：正确指标/实体/版本比例，歧义时的澄清或拒答质量。
执行可靠性：可执行率、结果契约通过率、超时与资源超限、重复副作用。
答案支持率：关键事实声明中有可访问证据支持的比例。
校准：系统表达的置信度是否与真实正确率一致，未知时是否收敛。
安全阻断：未授权请求误放行率，必须独立报告并设为上线门禁。
成本与延迟：端到端 p50/p95、模型与工具调用、扫描量和人工复核时间。

不要把这些指标简单平均成一个“综合分”。越权、错误写入和没有证据的高置信结论，成本远高于格式不完美；权重应由场景风险决定。

离线评测、影子运行和线上监控各做什么

离线回归用于固定快照上比较模型、提示词、语义版本和工具变更。每次发布都跑核心集和近期故障集，保存执行轨迹与差异。

影子运行让 Agent 处理真实请求但不向用户或生产系统提交结果，用来发现目录、权限、成本和长尾问题。它比离线集更接近环境，同时保持较低风险。

线上监控关注任务完成、人工修改、拒答、升级、工具故障、权限阻断、延迟和成本。用户点赞不是正确性标签；人工修改也要区分文风调整、口径修正和事实错误。

线上确认的错误进入回归集，但要去除敏感数据、绑定版本并记录失效条件。评测集本身也会漂移，需要负责人和更新流程。

评判器也要被评测

LLM-as-a-judge 适合检查结构、覆盖和开放式表达，却可能偏爱更长、更自信或与自身风格相近的回答。使用前应让多名领域专家标注一组校准样本，测量一致性，并为高风险结论保留人工复核。

Agent 生成的 SQL，为什么不能直接运行

Wed, 09 Sep 2026 00:00:00 +0000

模型输出一条 SQL，只说明它提出了一个候选动作，并不表示已经获得生产数据库的执行权。即使是 SELECT，也可能扫描数 TB、读取敏感列、触发外部函数，或者因为错误 Join 返回一份看似合理的结果。

执行层的任务，是把自然语言意图转换成一个受控操作：在运行前校验，在运行时限制，在运行后核验，并为每次副作用留下可追踪记录。

生成与授权必须分开。模型可以建议“创建工单”或“运行查询”，真正的工具网关根据身份、策略、参数和风险决定是否允许。

执行请求需要结构化契约

不要让执行器直接接收一段自由文本。一个最小请求应包含：任务与步骤 ID、调用者与委派身份、工具名和版本、结构化参数、输入产物、语义版本、允许动作、预算、超时、幂等键、审批引用和输出契约。

工具返回也要标准化：状态、执行 ID、结果引用、行数与截断、成本、Schema、数据水位、警告、可重试标志和审计引用。模型只看到完成下一步所需的结果摘要；凭证、内部错误栈和不相关敏感数据留在可信运行时。

运行前先过三道门

语法与静态检查

解析 SQL 或代码为语法树，拒绝不支持的语句、动态执行、未限定目标和危险库。只靠正则匹配 DROP 不够：写操作可能隐藏在存储过程、多语句、外部函数或工具参数里。

语义与数据检查

确认表、字段、指标版本、粒度、Join 基数和时间范围符合计划。执行层不重新发明业务口径，但要验证请求引用的契约仍存在、版本兼容、输入数据已就绪。

策略与资源检查

根据最终用户或受限服务身份检查资源、行列范围、用途、地域、环境、读写类型和审批。再估算扫描量、运行时间、并发与外部调用成本。未知成本不是零成本；无法估算时使用更严格限额或要求审批。

沙箱不是一个开关

SQL、Python 和外部 API 需要不同隔离：

SQL：只读事务、允许对象清单、查询超时、扫描上限、结果行数和敏感列控制。
代码：短期容器、固定依赖、CPU/内存/磁盘上限、无默认外网、只挂载任务所需文件。
文件工具：限定工作目录、文件类型、大小与恶意内容扫描，防止路径穿越。
外部 API：目标域名和动作清单、短期凭证、参数校验、速率限制和幂等策略。

隔离环境也要可复现。记录运行镜像、依赖、随机种子、输入版本与工具版本；否则“代码执行成功”无法转化为可复核结果。

查询成功之后还要验证

HTTP 200、进程退出码 0 或 SQL 完成，只代表工具没有报告执行失败。结果仍需检查：返回 Schema 是否符合合同、是否为空或被截断、数据水位是否满足任务、关键不变量是否成立、单位与分母是否正确。

对高影响查询，可以先 EXPLAIN 或运行限量探测，再执行完整版本。对工程变更，先生成差异、运行测试和影响分析；授权后执行，再回读目标状态。生成成功、提交成功和最终生效应是不同状态。

重试必须理解副作用

只读且确定性的查询在瞬时故障后通常可以限次重试。写操作则必须使用逻辑操作 ID，并核对下游是否真正支持幂等。超时并不等于失败；在未知状态下直接重发，可能创建两个工单、发送两封邮件或重复写入。

失败至少分为：调用者输入错误、策略拒绝、资源超限、可重试基础设施故障、工具确定性失败、结果验证失败和状态未知。每类错误都有不同去向，不能统一让模型“再试一次”。

审计记录什么，也要知道不记录什么

审计事件应连接任务、用户、委派身份、计划步骤、工具版本、参数摘要、策略决定、审批、执行 ID、结果引用和最终状态。高风险动作保存可验证的参数快照。

普通日志不应记录密钥、完整敏感结果或无需保留的提示词。审计系统本身需要访问控制、完整性保护和保留策略；“有日志”不等于日志足以追责。

最小上线测试

上线前至少验证：

越权表、列、行和工具调用全部被阻断；
注释、别名、子查询和多语句不能绕过静态规则；
扫描量、超时、输出行数和并发上限有效；
沙箱无法访问未授权文件、网络和环境变量；
相同幂等键不会造成重复副作用；
超时后的未知状态会先查询而不是盲目重试；
取消任务能在执行端真正停止，而非只停止聊天界面；
结果截断、空集、缺失数据和验证失败会被正确标记。

执行层成熟的标志，不是 Agent 能调用多少工具，而是每个动作都能回答：谁授权、在什么边界内运行、用了多少资源、产生了什么结果、失败后怎样恢复。只有这样，模型输出才可能安全地进入真实系统。

Data Agent 会规划，为什么任务仍然做不完

Wed, 09 Sep 2026 00:00:00 +0000

“新客转化下降，帮我找原因并给建议。”Agent 先查了渠道，再查地区，第三步遇到超时，于是从头重跑；或者生成十几步计划，却在拿到第一张结果表后忘了最初要验证的假设。它看起来会“思考”，任务仍然没有完成。

规划层的职责不是输出一段漂亮的待办清单，而是把复杂目标变成一个能保存状态、检查证据、恢复失败并在必要时交给人的执行过程。

图中每一步都应该有输入、产物、通过条件和失败去向。缺少其中任何一个，所谓“自主循环”很容易变成无界重试。

先分流任务，再决定是否需要规划

并非所有问题都值得启动 Agent 循环：

已有指标、单次只读查询、风险低的问题，可以直接走受约束的查询模板。
需要多个数据源、多个假设或代码分析的任务，才进入计划—执行—验证循环。
涉及写入、外发、敏感数据或高成本计算的任务，应在规划前标出审批节点。
目标、口径或数据覆盖不清时，先澄清，不要用规划掩盖需求缺口。

复杂度分流既节省成本，也缩小故障面。让每个问题都进入多 Agent 编排，通常只会增加延迟和排错难度。

一份可执行计划需要七个字段

每个步骤至少包含：

字段	作用
`step_id`	稳定引用，便于恢复和审计
`objective`	这一步要减少哪项不确定性
`inputs`	使用的数据、语义版本和前置产物
`tool_contract`	允许调用的工具、参数和权限
`output_contract`	预期结果的结构、版本和保存位置
`verification`	通过条件、容差和独立检查
`on_failure`	重试、改计划、降级、澄清或升级给人

“分析渠道影响”不是合格步骤，因为它没有说明使用什么数据、怎样判定完成。更好的目标是：“按渠道计算本月与基准期转化率，在相同口径和覆盖范围下标记绝对变化最大的三个渠道，并验证分母完整性。”

状态不能只存在对话里

长任务的事实状态应存放在 Harness，而不是靠模型记忆：任务目标、约束、当前计划版本、完成步骤、产物引用、失败次数、预算、审批和未解决问题。模型每轮只接收完成当前判断所需的切片。

一个实用状态机可以包含：PLANNING → READY → RUNNING → VERIFYING → COMPLETED，以及 WAITING_INPUT、WAITING_APPROVAL、REPLAN_REQUIRED、FAILED 和 CANCELLED。状态迁移由规则和工具结果触发，模型可以建议迁移，但不能随意把失败改成完成。

检查点应保存逻辑产物与版本，而不是完整复制所有敏感数据。恢复时先检查数据、语义、权限和批准是否仍有效；不能拿昨天的批准运行今天已经改变参数的动作。

规划、执行和验证要分工

常用模式是 Planner 提出下一步，Executor 通过受控工具运行，Verifier 检查结果与约束。它们可以是三个独立组件，也可以由同一模型在不同权限和上下文下完成。关键不在角色名称，而在控制面是否隔离：

Planner 不能持有生产凭证。
Executor 不自行扩张任务范围。
Verifier 使用独立规则、查询结果或测试，不只让模型评价自己的输出。
Harness 决定预算、重试和停止。

多 Agent 只有在专业上下文、工具权限或并行工作确实需要隔离时才有价值。把一个任务拆成许多拟人角色，却共享同一上下文、权限和评分器，只增加通信损耗。

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

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