智能体分析 ≠ 文本转 SQL

Anthropic 的2026年6月3日关于自助分析的文章是我与许多利益相关者和数据科学团队分享的一篇文章，因为终于有人在书面表达中指出 Agentic Analytics 不仅仅是将 Claude Code 连接到你的数据库并提出问题。

你可能熟悉 AI slop 这个术语，但没有遇到过分析 slop 吗？如果没有，让我告诉你这是什么。有了 Claude Code，任何人都可以让 Claude 连接到数据库并生成分析报告。

一方面，这很棒，因为数据分析的入门门槛降低了。另一方面……嗯，另一方面没有人检查生成的数字。绝对没有一个最近给我发送 .html 仪表板、Confluence 页面或终端截图的人检查过数字是否正确。

所有这些都是因为一种虚假的安全感，因为 LLM 擅长将英语翻译成给定语言（例如用于分析的 SQL），所以答案一定是正确的。

让我告诉你，但事实远非如此。如果你将 Agentic Analytics 简化为查询生成，你就过早地缩小了问题范围。你忽略了决定答案是有用还是危险的基础设施。Anthropic 自己的架构和他们的技术栈将数据基础、真相来源、技能和验证放在 Claude 接触查询的之前。

最后一部分是我认为 Anthropic 的贡献与他们的文章真正闪光的地方。他们明确指出传统的数据工程实践是必须的，还有一些关键的经验教训供我们其他人不要重复。

如果你对 Agentic Analytics 感兴趣，我将为你分解 Anthropic 的文章，以便你利用它。

1、为什么把Agentic Analytics简化为文本转SQL？

为什么这么多团队将 Agentic Analytics 简化为文本转 SQL？

团队将 Agentic Analytics 简化为文本转 SQL，因为查询生成是你可以在 30 秒内演示和尝试的部分。

→ 用普通英语提问。

→ 观看模型生成查询。

→ 对数据仓库运行它。

→ 返回数字或图表。

这种交互看起来很神奇，有一刻感觉分析层已经解决了。我的意思是，你能想象非技术人员在能够通过英语问题获得答案时的感受吗？甚至更多，当过去他们需要数据分析团队或预构建的仪表板时？

然而，虽然它可能感觉很神奇，但 Claude 或 Codex 输出的任何数字和合理的解释都不能证明业务问题得到了正确回答。Anthropic 直接指出了这个陷阱：将 Claude 指向数据仓库可能会产生精确的虚假感。

让我给你一个具体的例子。假设一个利益相关者问：

"上个月的活跃客户收入是多少？"

这就是分析细微差别开始的地方：

什么算作活跃？
哪个客户定义是官方的？
总收入还是净收入？
哪个日期字段？
哪些退款、欺诈过滤器或产品排除适用？

如你所见，文本转 SQL 出现在这些选择之后。因此，运行可靠的文本转 SQL 代理的唯一方法是围绕它们构建整个基础设施来指导它们对你的业务的理解（更多细节稍后）。

2、为什么数据歧义是分析代理中的真正问题？

我回答这个问题已经很长时间了。事实上，这种问题是关于机器学习系统中隐藏技术债务的传奇 Google 论文的主要锚定点，他们描述了机器学习模型如何只是生产中整个 ML 的非常小的一部分。

我们可以将这种思路应用于分析代理中的数据歧义，并用文本转 SQL 替换小黑框。

Anthropic 对这个问题的答案也非常一致：

"数据不是软件"

分析工作的失败方式与软件功能不同。例如：

通常有 1 个正确答案来自 1 个正确来源，但没有确定性方法仅从最终输出证明该答案是正确的。
系统可以编写完美的 SQL，但仍然完全错过业务含义。

Anthropic 提供了一组更详细的示例来比较这两种范式，我发现这非常有用。

我还编译了一些带来相同想法但问题不同的内容。

3、分析的 3 种风险或失败模式是什么？

这 3 种模式的分类来自 Anthropic 的博客文章，他们以以下方式区分这些模式：

概念/实体歧义。 用户说"活跃用户"或"收入"或"留存率"，代理必须在多个合理的实现之间进行选择。这些选择通常足够微妙，以至于错误的答案看起来仍然很专业。
数据过时。 表、业务规则和文档会发生变化。三周前有效的指标在模式更改、新的排除规则或仪表板重写后会悄悄变错。
检索失败。 正确的答案存在于技术栈的某个地方，但搜索空间太大。模型错过了正确的表、指标或文档，并自信地建立在接近失败的基础上。

仅靠数据仓库是不够的。数据仓库存储数据。它们不会自动存储业务的完整含义。该含义存在于指标定义、语义模型、注意事项、人工约定、所有权和历史背景中。

再想想之前那个简单的问题："上个月的活跃客户收入是多少？" 困难部分不是生成 GROUP BY。困难部分是决定"活跃"是指过去 30 天内的一次购买、计费期间的非欺诈付费使用，还是语义层中定义的其他特定于领域的阈值。

因此，有趣的问题不是 Claude 能否编写 SQL（它可能比你我编写得更好）。有趣的问题是 Anthropic 必须围绕 Claude 构建什么，这样这些问题就不会主导结果

4、Anthropic 为自助分析构建了什么？

答案是他们将老派的成熟工程实践与代理可以做的额外层混合在一起。但基本上，这仍然是围绕 Claude 构建了一个完整的系统来实现分析（或者如果你愿意，可以将系统可视化为 Claude 是接口层，系统存在于其下方，Claude 在前面）。

文章将该系统组织为 4 个部分。

首先是数据基础：规范数据集、数据模型、转换、测试、新鲜度检查和元数据。
然后是真相来源：语义层、血缘、业务上下文和策划的参考材料，帮助代理将问题映射到受管含义。
然后是技能：告诉模型如何工作的领域程序，而不仅仅是存在什么数据。
最后是验证：离线评估、在线检查、来源和维护循环。

注意 SQL 在该序列中的位置：在所有困难决策的下游。到模型编写查询时，技术栈应该已经缩小了问题的含义以及哪个受管路径值得信任。

该技术栈比模型选择更好地解释了标题结果。快速阅读 95% 的准确率数字，它听起来像模型基准。仔细阅读，它是系统基准。他们的文章在 Claude 周围的工具上花费的时间远多于在 Claude 本身上。

考虑到这一点，我们将在本文的其余部分更详细地介绍该技术栈的具体元素。

5、Agentic Analytics 技术栈需要什么？

Anthropic 明确表示标准数据工程仍然适用：维度建模、新鲜度和完整性检查、消费就绪的规范数据集、清晰的数据字典等。这些都不会因为界面变成对话式而消失。

如果有的话，因为消费者现在是代理（通过人类问题），风险增加了。人类分析师有时可以闻到表看起来不对，但代理可以更快地扩展错误假设。

读到前沿公司明确告诉世界，良好的旧数据工程实践对于代理良好执行是必不可少的，这真是太"有趣"了"。我觉得描述下面这些点有点贬义，因为描述的不是新的花哨东西。你可以拿任何一本 20 年前的数据仓库管理书籍，找到相同的答案。但是，无论如何，记住它们仍然是积极的。

5.1 规范数据集

这些数据集在检索开始之前减少了合理答案的数量。通过拥有更少、更受管的逻辑模型，这一小组规范的、单一真相来源的数据集是任何分析技术栈的基础。

你可能需要不同级别的聚合，但这些汇总聚合将始终从这一小组单一真相来源读取。分析代理也是如此：如果它们可以访问较小的真相集以及它们如何映射到不同的丰富维度，那么选择不正确数据源的失败概率会急剧降低。

5.2 将元数据视为一等产品

元数据为代理提供了表、列、粒度、所有者和注意事项的可用描述。如果你不花时间很好地描述你的数据模型、每列的含义、血缘（或连接键）索引是什么……那么 LLM 将做出很多假设。

5.3 将模型、文档、仪表板和技能文件放在一起

这很有趣，因为共存可能意味着拥有更大的单体仓库或许多工件在系统中彼此靠近。Anthropic 的声明很好地定义了它："几乎所有数据代码（即建模、语义层、参考文档、规范仪表板定义）都存在于单个仓库中，具有保护跨层完整性的 CI 检查。如果建模更改会破坏下游仪表板或使记录的指标无效，CI 会标记它，并在同一个 PR 中修复。"

如你所读，我不买 AI 分析将使数据工程不那么重要的懒惰叙述。随着更多问题通过模型路由，建模层的质量变得更加可见，而不是更不明显。

这种模式也出现在 Anthropic 之外。dbt 语义层旨在集中指标定义并使其可跨工具重用。Microsoft 的 Power BI Copilot 指南推荐 AI 就绪模式、经过验证的答案和明确的说明，以便模型在响应之前具有基于上下文的上下文。即使是 Snowflake 的 Cortex Analyst 架构也依赖于语义模型、经过验证的查询和 SQL 生成层周围的监控行为。不同的产品，相同的教训：准备好的上下文是答案的一部分。

6、为什么语义层是分析代理的地图？

首先，处理数据时什么是语义层？

语义层是一个架构桥梁，将原始、复杂的数据转换为熟悉的业务术语、指标和关系。语义层位于你的数据存储（如 Snowflake、Databricks 或 BigQuery 的数据仓库）和你的消费工具（如 Power BI/Tableau 的 BI 平台或 AI 代理）之间。

通过语义层，你可以回答诸如列 X 是什么意思、列 Y 的数据类型是什么、如何计算指标 Z、特征之间是否存在层次结构或表之间的关系等问题。

它如此重要，以至于 Anthropic 表示其代理在结构上需要首先咨询语义层。强烈的操作原则是模型从受管含义开始，而不是从对原始表的开放探索开始。

Anthropic 不仅强制代理使用语义层，他们实际上提到让代理自己想出语义层是不好的做法！从字面上看，世界上一个前沿实验室之一正在告诉你，人类是确保高质量语义层的关键。

Anthropic 并不是唯一的。市场正在汇聚到相同的结论。Snowflake 的 Cortex Analyst 中的语义模型层桥接业务问题和数据库结构。Databricks 的 Genie 要求领域专家提供数据集、说明、示例 SQL 和业务上下文。dbt 的语义层集中了指标逻辑，以便下游工具停止重新发明它。Microsoft 将经过验证的答案和 AI 说明推送到 BI 模型本身。在之前的一篇博客文章中，我介绍了 Google 的数据科学代理如何需要一个伪语义层（他们称之为"分析器"）来实现突破性性能。

DS-STAR：Google 如何构建一个真正有效的数据科学代理Google 的七模块管道如何比原始 Gemini 高出 32 个百分点——以及这对任何构建者意味着什么……

因此，没有那张地图，代理就是在猜测。有了它，模型将精力花在受限世界上进行推理，而不是从头开始发明世界。

6.1 示例查询也增强了语义层

除了数据库语义层之外，Anthropic 分享说知识（如查询语料库）可以产生积极的净效应。查询语奏库可以是来自仪表板、笔记本和先前分析的历史 SQL。有效的是将该语料库提炼为结构化的领域参考文档和可重用的分析模式，这些模式在技能中描述*（见下一节）*。将查询历史视为策划的原材料，而不是代理直接读取的真相来源。

6.2 为什么技能改变了准确率的故事？

感谢语义层，代理知道"世界意味着什么"……但它仍然缺少如何与世界合作。例如，语义层无法告诉代理，当利益相关者提出一个具有两个可能来源路径和一个区域中已知边缘情况的模糊问题时，优秀的分析师应该遵循什么步骤顺序。

在 Anthropic 的分析系统中，技能更像是编码的分析师手册，而不是文档。它们携带程序知识：

首先咨询哪个来源
何时使用语义层，何时回退
要问什么澄清问题
这个领域中哪些注意事项很重要
如何对抗性地审查结果
最终答案中应包含哪些来源

Anthropic 最强的数字出现在这里。根据文章的技能部分，Claude 在没有技能的情况下在他们的分析评估中未超过 21%。有了技能层，准确率总体上超过 95%，在某些领域达到约 99%。

这个数字迫使类别描述发生变化。如果最大的性能跳跃来自程序指导而不是更好的 SQL 生成，那么该系统从根本上不是文本转 SQL 产品。它是一个在内部具有查询执行的分析工作流产品。

以下是他们使用的技能模板示例。

如果你组合提到的工件，你将处理如下内容：

6.3 为什么评估和维护与提示一样重要？

因为即使是基础扎实的分析代理也会退化。

一旦你有了语义层、策划的示例和技能，下一个失败模式就是漂移。表会发生变化，业务定义会转移，仪表板会重建，技能会停止匹配源模型，等等。昨天的正确程序变成了明天的过时上下文。

Anthropic 给出了一个鲜明的例子。离线准确率在一个月内从约 95% 下降到约 65%，然后他们开始将技能维护视为工程问题。这个数字将维护从"最好有"变成了可靠性要求。

分析的好处是你可以将评估建立在任何程序都应正确的基于事实的数字上。如果你可以在系统中定义这一点，那么你可以调整构成同一系统的所有参数。例如：尝试使用 Haiku、Sonnet 或 Opus 和不同思考级别的技能 v2。你可以轻松地在它们之间基准测试准确率，并选择你觉得更适合你情况的一个（足够的准确率和较低的成本，或任何成本下的最高准确率）。

这就是成熟的分析系统应该如何测试的。使用存储的案例、明确的断言以及在系统失败时更新手册的反馈循环。

Databricks 在其 Genie 文档中展示了类似的直觉：响应检查、基准测试、可信资产和策划说明都内置在产品体验中。不同的实现，相同的结论。

这也是提示开始看起来不像人们预期的那么核心的地方。提示质量仍然很重要。但如果你的语义层很弱，你的示例过时，你的技能漂移，你的评估缺失，没有英勇的提示能够长期拯救系统。

当周围系统表现得像维护的产品时，Agentic Analytics 就能工作，而不是当允许模型从原始访问中即兴发挥时。

6.4 如果数据团队现在想要 Agentic Analytics，他们应该做什么？

正确的起点是最简单的可能有效的结构，然后只有在数据显示有帮助时才逐步增加复杂性（Anthropic 的构建有效代理正是主张这种逻辑）。他们的分析文章在实践中遵循了相同的模式。

5 个具体步骤：

选择一个领域，而不是整个数据仓库。 收入质量、支持运营、增长漏斗、财务报告。选择一个具有一个明确所有者和经常性问题的领域。
创建一个受管的真相来源。 在接触提示之前，确保该领域具有规范数据集、明确的指标定义、所有权和基本的新鲜度检查。
将语义层放在首位，将原始 SQL 作为回退。 如果问题可以清晰地映射到受管含义，代理就不应该通过原始表自由发挥其路径。
编写一个薄的技能或手册。 编码优秀分析师在该领域遵循的程序：澄清、来源、验证、报告、引用来源。
在广泛推出之前构建一个小的评估集。 二十到三十个具有预期答案和已知边缘情况的真实问题将比一百个内部演示教你更多。

我不会做的是首先将前沿模型直接连接到数据仓库，并将结果称为策略。除了一个错误答案听起来多么令人信服之外，这种方法教你很少东西。

文本转 SQL 在该技术栈中仍然有一席之地。它是一个有用的执行能力。它只是一个太小的概念，无法承载整个系统。

附录

Anthropic 的完整技能模板。

---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [the company]'s data warehouse for any
  [list of business domains] question — THEN invoke this skill. DO NOT invoke
  for [adjacent engineering tasks] or questions with no data-warehouse component."
---

# [Warehouse] Skill Instructions

## Description
The single source of truth for safe and effective [warehouse] querying.
Referenced by other skills [listed] for query execution guidance.

Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.

**Out-of-scope decisions**: [product areas, etc.] → surface data only,
state "decision is [owning team]'s call", do NOT take a position or author
code fixes.

## Executing queries
Priority:
1. **[Managed connection]** (if available): [query tool] / [schema tool]
2. **[CLI fallback]** (if installed): [default project, fallback project]
3. **Neither** — ask the user to authenticate, then stop

---

# Semantic Layer (REQUIRED first step)

The governed semantic layer is the **mandatory default path** for every data
question — same numbers as [the BI tool], joins/grain/filters baked in. Raw SQL
via the reference docs below is the **fallback**, used only after the
semantic-layer path is shown not to cover the ask.

## Required workflow
1. **Load** — [how to load the semantic layer in each runtime, with fallbacks]
2. **Discover** — search measures/dimensions by keyword; **always check
   segments** (the named canonical population filters — hand-rolled WHERE
   clauses for these are the dominant wrong-answer mode)
3. **Compile + run** — build the spec → compile to SQL → execute
4. **Fallback** — only if discovery finds no relevant metric or compile fails
   → raw SQL via `references/*.md` (PART 3 below)

> **Don't bail early.** Do NOT fall back to raw SQL on these grounds:
> - "[custom date filtering / cohorts]" → [covered by time-dimension specs]
> - "[needs a join]" → [the metric layer already encapsulates its joins]
> - [3–4 more pre-rebutted excuses agents use to skip the semantic layer]

### Date windows & timezone — decide before you query
- **As-of date vs trailing-N days**: [convention for each]
- **"Last week/month"** → the last *complete* calendar week/month, not trailing-7/30
- **Timezone default**: [TZ]; [exception for certain reporting rollups]
- **Freshness lag**: [some] tables settle late — anchor on MAX(date), not "yesterday"

---

# PART 1: MUST KNOW (Read First for Every Request)

## 🚀 Quick Start Workflow
1. **Check for red flags first**: [restricted/PII requests, gated domains,
   high-stakes asks that need extra validation]
2. **Out of scope — escalate, don't guess**: [access requests, pipeline
   troubleshooting, stale dashboards, root-cause assertions, product/pricing
   recommendations] → redirect to [the owning team], don't answer
3. **Clarify the request**: time period, segment, the business decision it informs
4. **Check for existing dashboards**: [per-domain dashboard catalogs]
5. **Identify the data source**: [navigation map below; prefer governed/aggregated tables]
6. **Execute the analysis**: [required filters + adversarial review]
7. **Deliver insights**: show methodology, differentiate observations from interpretations

## 🏢 Business Context

### Entity Disambiguation (MUST CLARIFY)
- **"[Term A]" can mean**: [entity 1] or [entity 2] — always clarify which
- **"[Term B]" can mean**: [entity 1] → [entity 2] → [entity 3] (one-to-many chain)
- **"Users"**: [which identifier gives accurate counts, and which ones inflate them]

### Business Terminology
- [Current product names vs deprecated aliases that still appear as frozen
  values in the data layer — write with the new names, filter with the old]
- [Key internal acronyms]
- **[Headline metric] calculations**: [monthly / default window / leading indicator]
- **Unfamiliar terms — search [internal docs], don't guess**

### Data Integrity Requirements ⚠️
- **NEVER**: make up data/columns; make speculative assertions beyond what data shows
- **ALWAYS**: use safe division; differentiate observations ("data shows X")
  from interpretations ("this suggests Y"); flag limitations

---

# PART 2: HOW TO DO (Follow During Execution)

## 🔧 Technical Execution Guide
- [Managed-connection tools and CLI invocation details]
- **PII protection**: for restricted data, return the SQL for the user to run
  themselves — do not return results

## 📊 Analysis Best Practices Guide
1. Clarify the ask before querying
2. Show your work (filters, inclusions/exclusions, freshness)
3. Clarify denominators
4. Consider sample bias
5. Connect to business impact
6. **Adversarial SQL review (MANDATORY)** — spawn the [sql-reviewer] sub-agent
   for every query before the final answer; blocking findings must be fixed
   and re-reviewed; do not self-certify
7. **Report with provenance** — every answer ends with a footer:
   > **Source:** [semantic layer | governed table | raw exploration] ·
   > **Confidence:** [tier] · **Reviewed:** [reviewer ✓, round N] ·
   > **Freshness:** [max date in the data] · **Owner:** [owning team]

---

# PART 3: DATA REFERENCES & RESOURCES

## 📚 Knowledge Base Navigation
### [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: `references/[domain_a]_dashboards.json`

### [Domain B] → `references/[domain_b].md`
- **Use for**: [...]

[... one entry per business domain — a few dozen in total ...]

## ⚠️ Troubleshooting Guide

### When Information Is Missing
- [missing tables / access denied / outdated docs / unknown enum values → what to do]

### Field Naming Gotchas
- Use `[field_x_v2]` NOT `[field_x]`
- [Two similarly-named tables report the same metric at different grains — which to use]
- [Which of two plausible sources is canonical for the headline metric]
- [… a dozen more hard-won one-liners …]

原文链接：Anthropic is telling you that Agentic Analytics is not just text-to-SQL

汇智网翻译整理，转载请标明出处