技术 on DataAgentX

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。

把 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 公开参考仓库

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

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可用于梳理责任、风险、测量和处置，但不会替组织自动满足法规，也不能取代技术控制。

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