AI News
官方更新 Claude Blog 2026-08-14T00:00 正文 ok 2207 words

Slack 中的自助数据分析：Anthropic 如何部署 Claude Tag 回答临时问题

英文标题：Self-service data analytics in Slack: how Anthropic deploys Claude Tag for ad-hoc questions

Anthropic 介绍了如何在 Slack 中部署 Claude Tag，支持员工以自然语言进行临时数据查询、分析和排障。其核心架构是将技能文件作为持续更新的运行时内容，并结合数据仓库、内部知识索引、分析方法论与严格的服务账号权限控制。文章强调，数据分析 Agent 不仅要能查询正确的数据，还要具备预测、漏斗、留存、可视化和分析写作等技能，才能提供有用洞察。对开发者而言，关键实践包括从一开始建立可审计的遥测体系、以频道成员资格作为访问授权，并通过共享线程和自动化循环扩大自助分析的覆盖范围。
打开原文相关 2.4 · 机会 1
media9.6 KB media224.2 KB media403 B media184.9 KB media175.1 KB media247.7 KB media271.9 KB media50.3 KB

中文

像刷新数据模型一样频繁地刷新技能

你可以通过技能教 Claude 按照你的风格和要求完成任务。技能是一个 Markdown 文件，其中包含自然语言指令，以及 Claude 可在需要时引用的文件。

我们做出的最重要一项架构决策，是将技能文件视为在线提供的内容，持续刷新，而不是一次性交付后便不再维护的内容。

数据模型每天可能变化数次。例如，某一列被重命名、某项指标定义被修正，或者一张表被弃用。每一项变化都需要在相对较短的时间内同步到技能文件中。如果 Claude 读取的是上周二版本的技能，它就会非常自信地给出上周二的错误答案。

这种倾向尤其具有破坏性，因为数据消费者如今与判断回答准确性所需的上下文完全分离。他们不会看到带有趋势线或关联指标的仪表盘，无法借此进行“直觉检验”。他们在 Slack 中可能只会收到一两个数据点；如果这些并非他们经常查看的数据，他们很可能会接受那个自信但错误的答案。

为了控制这个不断变化的环境，Claude Tag 的运行时会挂载我们数据仓库中的 skills/ 目录，并在每一次对话中重新读取它。技能文件只是磁盘上的 Markdown；Agent 读取它们的方式与读取其他项目文件相同。

赋予 Agent 超越“知道查什么”的技能

最初，我们部署 Claude Tag 数据分析 Agent 时的想法，是创建一个“知识技能”，教 Claude 应使用哪些表、我们的语义层如何组织，然后就此结束。我们很快发现，这种做法能提供_正确的数字_，却不足以提供_有用的洞察_。

大多数数据消费者往往会提出开放且模糊的问题，例如“是什么导致这次下降？”、“你能预测这个数在月底会落在哪里吗？”或“把这些数据展示成一个漏斗”。回答这些问题，需要 Agent 不仅知道_数据在哪里_，还要知道_分析师会如何处理这些数据_。

因此，除这一知识技能外，我们还为 Claude Tag 挂载了额外的分析或操作手册技能，包括：

  • 预测：何时以及如何拟合简单趋势、季节性假设，以及何时应因时间序列过短或噪声过大而拒绝预测。
  • 队列和留存分析：标准队列定义、向管理层汇报的留存曲线模板，以及容易导致简单实现出错的注意事项（左删失、幸存者偏差）。
  • 漏斗分析：关键产品漏斗的标准阶段定义，以确保“用户在引导流程的哪个环节流失？”这类问题在不同回答中保持一致。
  • 图表制作：可视化规范，例如不同问题应使用何种图表类型、颜色方案，以及何时表格比图形更清晰。
  • 分析写作：如何组织一项发现（先给 TL;DR、再给数字、机制和注意事项），以及应根据置信程度采取何种程度的谨慎表述。

每个数据团队可能都已有这些惯例；只是它们通常存在于某个人的脑海中，且仅偶尔被记录下来。将其写成技能，可以确保 Claude 像你的数据科学家一样一致地应用这些惯例。

连接业务上下文，而不只是数据仓库

即使结合知识技能和操作手册技能，有时仍不足以回答一个问题。当有人问“为什么周二注册量下降了？”时，答案往往不在数据模型中，而是分散在 Slack 讨论串、事故追踪系统、发布说明和文档里。

为弥补这些缺口，我们将 Claude Tag 接入内部知识索引；该索引汇集了公司内的文档、讨论和事件。当 Agent 发现某项指标发生变化时，它可以在索引中搜索_同期上下文_：例如当天早上开启的事故、被切换的功能开关，或有人在频道里分享的竞争对手公告。

此时，回答会变成：“周二注册量下降了 12%：当天上午 9 点至 11 点支付服务发生事故，且下降主要集中在受影响地区。”

如果你的组织拥有知识图谱、内部搜索，或者至少有组织良好的事故与变更日志信息流，那么在数据仓库之后，将 Claude Tag 连接至它们是你所能增加的最高杠杆信息。你还可以连接 Claude Tag，使其能够读取 Slack 关键频道并从中获取上下文。

审慎配置服务账号权限

Claude Tag 通过服务账号查询你的数据仓库，而不是通过提出问题的用户本人。尽管这是正确的设计（因为你不希望每位 Slack 用户都需要直接拥有数据仓库凭据），但所有能够提及该机器人的人，都拥有该机器人的数据访问权限**。**这里不存在按用户区分的行级安全控制：服务账号能够读取的内容，频道中的任何人都可以询问。

我们通过五种方式应对这一问题（并建议认真对待，因为这很容易做错，也很难撤销）：

**1. 将服务账号限定为只能访问受治理的数据。**在 Anthropic，Claude Tag 的服务账号可以读取语义层的输出表，以及为这些表提供数据的精选数据集市。它不能读取原始事件流、暂存 schema，或个人沙盒中的任何内容。如果一个问题需要边界之外的数据，Agent 会明确说明，而不是猜测。这也是正确的用户体验，因为受治理层之外的数据尚未经过验证。

**2. 在列级别分类 PII，并拒绝向服务账号授予相关权限。**受治理的数据并不自动意味着不包含 PII（例如，精选表中仍可能包含电子邮件地址）。我们维护了一个具备列级血缘关系的数据目录，因此每一列的来源和下游流向都是已知的。当新列进入系统时，Claude 会扫描这些列，并标记可能属于 PII 的候选项供人工审查。随后由人工在该列元数据中应用分类，而血缘关系会将这一标签传播至派生表。由于 Claude Tag 的服务账号不拥有 PII 访问许可，数据仓库的列级访问控制会让所有 PII 列对 Agent 不可见。它可以查询该表，但敏感列本身无法读取。

**3. 在技能本身中记录连接路径。**我们的数据仓库技能有专门章节说明 Agent_如何_连接，包括通过 CLI、直接 API 还是 MCP 服务器，以及每条路径具体如何进行身份验证。这个看似平实的功能，让我们能够区分 Agent 的清晰失败（“我无法从这个界面连接到数据仓库；原因如下”）与令人困惑的失败（查询悄悄在错误项目中运行，或者认证提示被转发到了不应出现的地方）。当连接机制写在技能中时，Agent 可以解释自身的限制。

**4. 将 Claude 的频道成员资格视为一项访问授权。**将 Claude Tag 添加到 Slack 频道，实际上等于向该频道成员授予对 Agent 可查询内容的读取权限。我们明确了这一点：Claude 由数据团队成员添加至频道，且数据团队负责维护频道列表。

**5. 为每一次查询添加标签。**对于每一次数据仓库查询，Claude Tag 都会携带标识界面、对话和请求用户的标签（在 Slack 提供这些信息的情况下）。这不会在查询时执行任何限制，但它提供了成本归因和审计线索（例如，你可以事后确定是谁提出了那个扫描 4 TB 数据的问题）。

我们的总体立场是：Slack 中的数据分析 Agent 是你的受治理数据仓库的共享只读副本，我们也据此对其进行权限范围限制。

为每一个回答建立监控

判断 Agent 给出的回答是否充分，并不是靠肉眼就能完成的。

我们会为 Claude Tag 处理的每一个问题记录一个结构化事件，其中包括：

  • 加载了哪些技能文件，以及它们的版本；
  • 用户是否给出了 👍/ 👎 反应，或通过回复进行了纠正；以及
  • 它所访问表中是否存在未解决的数据质量警告。我们还会在回答页脚中展示所有数据质量警告，使过期数据警报出现在数字旁边，而不是完全不可见。

这些遥测数据会进入两个视图。一个视图追踪采用率，即按界面和领域划分，有多少 Agent 查询是通过受治理层路由的，而非通过临时 SQL 完成。另一个视图追踪正确性，以按领域划分的 👎 反应率和纠正率衡量。这是在两次评估运行之间衡量准确性的在线代理指标。

采用率指标最终成为我们追踪的最具可操作性的单一数字。当某一领域的采用率下降时，几乎总是意味着技能文件已经偏离现实，或出现了语义层尚未覆盖的新问题类型。

这如何加速自助数据分析的采用

Claude Tag 讨论串成为新的会议场所

我们最喜欢、也最有效的 Claude Tag 讨论串，通常有多人参与。在这些场景中，我们看到人们贡献想法和上下文，而 Claude 负责繁琐的执行工作。

例如，一位数据团队成员询问 Claude，为什么某个收入仪表盘的加载时间比平时多了几分钟。Claude 发现查询结果没有被缓存，并且一个 Bug 减慢了结果传送到页面的速度。

Claude 通知了仪表盘负责人；后者决定立即修复缓存问题，同时通过另一条工作流处理该 Bug。

随后，该负责人询问还有哪些仪表盘变慢了，结果发现数十个仪表盘都受同一缓存错误影响。Claude 编写了缓存修复方案，数据团队成员进行了审查，所有受影响的仪表盘在不到一小时内恢复满负荷运行。

为说明目的而虚构的 Claude Tag 对话复现。事故细节、姓名和工具均非真实。

这些讨论串是公开的，这在多个方面都很有帮助。旁观者可以了解上下文（什么出了问题、为什么会出问题、如何修复），而无需有人专门为他们撰写总结。更重要的是，他们不必只是被动读者。任何知道有用信息的人都可以加入并作出贡献，就像上例中的团队成员一样。

因此，应将 Agent 保留在共享频道中，并让工作留在讨论串中而不是私信里，因为讨论串可以作为可审查的历史记录。

Claude Tag 处理重复性任务

许多数据工作具有周期性：例如管道健康检查、KPI 监控等。你可以要求Claude 创建循环，按计划或响应异常变化来处理周期性任务。我们已实现的一些数据相关示例包括：

  • 主动解读：Claude 会在每周例会前提供摘要：上周有哪些变化、与前一周相比如何，以及有哪些值得注意的事项。
  • 测试监控：当我们监控一次发布或实验时，Claude 每天会多次提供解读。在最近的一次实验中，它注意到设置在实验中途发生了变化，帮助我们及早发现并修复问题。
  • 可观测性：其他循环会监控我们的数据管道和仪表盘。如果管道失败，Claude 会开始调查、起草修复方案，并通知值班人员。如果 KPI 出现异常变化，Claude 会提供可能的解释，例如节假日效应或上游数据变更，并在任何人打开仪表盘之前验证这些解释。
  • 分流处理：另一个循环会追踪我们的数据问题频道。对于每个新问题，它会做出判断：直接回答、启动更深入的调查，或转交给人工。等到数据团队成员查看时，大部分工作已经完成。

Claude 还可以协助设计循环。可以询问 @Claude：它在你的频道中看到了哪些重复性工作，以及它可以如何提供帮助。

在需要时介入

你可以允许 Claude 在任意指定频道中更加主动，持续阅读讨论，并在需要时介入提供帮助。过去一个月，在我们的一个数据频道中，Claude Tag 回答了人们发布问题的 75% 以上，通常即使没有被点名，也会在一两分钟内作答。

例如，一位 Anthropic 团队成员在公开频道询问：某个仪表盘是否包含一个新的使用类别。90 秒内，Claude 回答了数据定义方式，确认新分组缺失，提出修复方案，并起草了一个 PR。一位数据科学家进行了审查并批准。随后 Claude 合并了该 PR 并刷新仪表盘。

为说明目的而虚构的 Claude Tag 对话复现。事故细节、姓名和工具均非真实。

开始使用

如果你已经完成了我们的第一篇文章中介绍的工作，那么 Slack 部署主要是一些连接配置，不过顺序很重要：

  1. **权限优先。**在编写任何一行 Agent 代码之前，先决定服务账号可以读取什么。以后扩大访问范围远比之后再收回权限容易。
  2. **分发其次。**选择挂载仓库或通过 MCP 提供技能，并端到端验证新鲜度：修改一个技能文件，并确认 Claude Tag 能在你的 SLA 时限内获取更新。
  3. **从第一天开始建立遥测。**你无法事后为一个月前的对话补建监控。应从第一个问题开始就记录结构化事件。
  4. **条件允许时接入知识索引。**数据仓库回答_是什么_；内部文档和事故信息流回答_为什么_。一旦数据路径稳定，就应尽快将它们连接进来。
  5. **最后再添加分析技能。**先创建数据访问技能，再根据真实问题判断你的同事实际需要哪些分析师技能（预测、队列、漏斗）。

_本文由 Anthropic 成员 Clement Peng 和 Lily Zhao 撰写，

English / 原文

Refresh skills as often as you refresh your data models

You can teach Claude how to do a task aligned with your style and requirements using a skill, which is a markdown file with natural language instructions and files Claude can reference when needed.

The single most important architectural decision we made was to treat skill files as served content , refreshed continuously, rather than something shipped once and forgotten.

Data models can change several times a day. For example, a column gets renamed, a metric definition is corrected, or a table is deprecated. Every one of those changes needs to land in a skill file in relatively short order. If Claude is reading last Tuesday's copy of the skill, it gives last Tuesday's wrong answer with full confidence.

This tendency can be especially damaging since the data consumer is now completely separated from the context they need to judge the accuracy of the response. They aren’t looking at a dashboard with trend lines or associated metrics that can guide their “sniff test.” They may receive just a single data point or two in Slack, and if it's not data they look at regularly, they are likely to accept that confidently wrong answer.

To control this ever-changing environment, Claude Tag's runtime mounts our data repo's skills/ directory and re-reads it on every conversation. The skill files are just markdown on disk; the agent reads them the same way it would read any project file.

Give the agent skills beyond knowing what to query

Our initial instinct for deploying our data analytics agent using Claude Tag was to create a “knowledge skill,” which teaches Claude which tables to use and how our semantic layer is organized, and call it a day. We quickly determined that approach would provide correct numbers , but stop short of useful insights.

Most data consumers tend to ask open-ended and ambiguous questions like "what's driving this dip?" or "can you forecast where this lands at month-end?" or "show me this data as a funnel." Answering those requires the agent to know not just where the data is but how an analyst would work with it.

So alongside this knowledge skill, we mounted Claude Tag with additional analytics or runbook skills, including:

  • Forecasting : when and how to fit a simple trend, seasonality assumptions, and when to refuse because a series is too short or too noisy.
  • Cohort and retention analysis : standard cohort definitions, the retention curve template reported to leadership, and any gotchas (left-censoring, survivorship) that trip up naive implementations.
  • Funnel analysis : the canonical stage definitions for key product funnels, so "where are users dropping off in onboarding?" is consistent across responses.
  • Charting : visualization conventions like which chart type to use for which question, color palettes, and when a table is clearer than a plot.
  • Analytical writing : how to structure a finding (TL;DR first, number, mechanism, caveat), and the level of hedging that’s appropriate given the degree of confidence.

Every data team likely already has these conventions; they just usually live in someone's head and are only occasionally documented. Writing them down as skills ensures Claude applies them as consistently as your data scientist would.

Connect to business context, not just the warehouse

Even this combination of knowledge skills and runbook skills is not always enough to answer a question. When someone asks "why did sign-ups drop on Tuesday?", the answer often isn’t in the data model, but rather is frequently spread across Slack threads, incident trackers, release notes, and docs.

To account for these gaps, we wire Claude Tag into our internal knowledge index, which catalogs documents, discussions, and events across the company. When the agent sees a metric move, it can search that index for contemporaneous context : an incident opened that morning, a feature flag flipped, a competitor announcement someone shared in a channel.

The answer now would look like "sign-ups dropped 12% Tuesday: there was a payment-service incident open 9-11am that morning, and the dip is concentrated in the affected region."

If your organization has a knowledge graph, internal search, or even just well-organized incident and changelog feeds, connecting Claude Tag to them is the highest-leverage information you can add after the warehouse itself. You can also connect Claude Tag so it can read and get context from key channels across Slack.

Permission the service account deliberately

Claude Tag queries your warehouse as a service account, not as the human who asked the question. While that's the right design (since you don't want every Slack user requiring direct warehouse credentials), everyone who can mention the bot has the bot's data access. There is no per-user row-level security: what the service account can read, anyone in the channel can ask about.

We approach this in five ways (and we recommend taking this seriously as it’s easy to get wrong and hard to undo):

1. Scope the service account to governed data only. At Anthropic, Claude Tag's service account can read the semantic layer's output tables and the curated marts that feed them. It cannot read raw event streams, staging schemas, or anything in a personal sandbox. If a question requires data outside that boundary, the agent says so rather than guessing. That is also the right user experience because data outside the governed layer hasn't been validated.

2. Classify PII at the column level and deny the service account clearance. Governed data isn’t automatically PII safe data (e.g., a curated table can still carry an email address). We maintain a data catalog with column-level lineage, so every column’s origin and downstream flow is known. When new columns land, Claude scans them and flags likely PII candidates for human review. A human then applies the classification in the column’s metadata, and lineage propagates that label to derived tables. Given Claude Tag’s service account holds no PII clearance, the warehouse’s column-level access controls make any PII columns invisible to the agent. It can query the table, but the sensitive columns simply aren’t readable.

3. Document the connection path in the skill itself. Our warehouse skill has a dedicated section on how the agent connects (whether via CLI, direct API, or an MCP server) and exactly how authentication works for each path. This prosaic feature allows us to differentiate between the agent failing cleanly ("I can't reach the warehouse from this surface; here's why") versus failing confusingly (a query that silently runs against the wrong project, or an auth prompt relayed somewhere it shouldn't be). When the connection mechanics are in the skill, the agent can explain its own constraints.

4. Treat Claude’s channel membership as an access grant. Adding Claude Tag to a Slack channel is, in effect, granting that channel's members read access to whatever the agent can query. We made this explicit: Claude is added to a channel by a data-team member, and the data team owns the list of channels.

5. Label every query. For every warehouse query, Claude Tag carries labels identifying the surface, the conversation, and the requesting user (where Slack provides it). This doesn't enforce anything at query time, but it provides cost attribution and audit trails (you can determine who asked the question that scanned 4 TB after the fact).

Our general posture is that a data analytics agent in Slack is a shared read replica of your governed warehouse, and we try to scope it as such.

Instrument every answer

Determining whether the agent gave a sufficient answer is not something you can eyeball.

We log a structured event for every question Claude Tag handles. This includes:

  • Which skill files were loaded and at what version;
  • Whether the user reacted with 👍/ 👎 or replied with a correction; and
  • Any open data quality warnings on the tables it touched. We also surface any data quality warnings in the answer's footer, so a stale-data alert appears next to the number rather than being invisible.

This telemetry feeds two views. One tracks adoption or what fraction of agent queries route through the governed layer rather than ad hoc SQL by surface and domain. The other tracks correctness measured by the rate of 👎 reactions and corrections by domain. This is the online proxy for accuracy between eval runs.

The adoption metric turned out to be the single most actionable number we tracked. When it dips for a domain, it almost always means either a skill file has drifted or a new class of questions has appeared that the semantic layer doesn't cover.

How this accelerates self-service analytics adoption

Claude Tag threads become the new meeting

Our favorite, most effective Claude Tag threads usually have multiple people in them. In these cases we see people contributing ideas and context while Claude handles the legwork.

For example, a data team member asked Claude why a revenue dashboard was taking a few minutes longer than usual to load. Claude discovered query results weren't being cached and a bug was slowing down how results reached the page.

Claude notified the dashboard owner who decided to fix the cache immediately while handling the bug in a separate motion.

The owner then asked what other dashboards had slowed, and it turned out dozens were impacted by the same caching error. Claude wrote the caching fix, the data team member reviewed it, and all impacted dashboards were functioning at full capacity in less than an hour.

Fictional recreation of a Claude Tag conversation for illustrative purposes. Incident details, names, and tools are not real.

These threads are open which is helpful for multiple reasons. People reading along pick up context (what broke, why, how it got fixed) without anyone writing a summary for them. More importantly, they don't have to remain passive readers. Anyone who knows something useful can jump in and contribute, the way the team members did in the example above.

So keep the agent in shared channels and keep the work in threads instead of DMs, as the thread can function as a reviewable historical record.

Claude Tag handles repetitive tasks

A lot of data work is recurring: pipeline health checks, KPI monitoring, etc. You can ask Claude to create loops that can handle cyclical tasks on schedule or in response to unusual changes. Some data specific examples we’ve implemented include:

  • Proactive Readouts : Claude provides a summary before a weekly standup: what moved last week, how it compares to the week prior, and what’s worth noting.
  • Test Monitoring : When we’re monitoring a launch or an experiment, Claude provides readouts multiple times a day. During one recent experiment, it noticed the settings had changed partway through and helped us catch and fix it early.
  • Observability : Other loops monitor our pipelines and dashboards. If a pipeline fails, Claude starts investigating, drafts a fix, and pings the person on call. If a KPI moves unexpectedly, Claude provides likely explanations: a holiday effect? an upstream data change? and checks them before anyone opens a dashboard.
  • Triage : Another loop tracks our data questions channel. For each new question, it makes a call: answer it directly, start a deeper investigation, or bring in a human. By the time someone from the data team checks, most of the work is already done.

Claude can also help design the loop. Ask @Claude what repetitive jobs it’s seen in your channels and how it can help.

Stepping in when needed

You can allow Claude to be more proactive in any channel you choose, reading along and stepping in to help when needed. In one of our data channels over the last month, Claude Tag answered more than 75% of questions people posted, typically within a minute or two, even without being called.

For example, an Anthropic team member asked in a public channel whether a dashboard included a new usage category. Within 90 seconds Claude answered how the data was defined, confirmed the new segment was missing, proposed a fix, and drafted a PR. A data scientist reviewed and approved. Claude then merged the PR and refreshed the dashboard.

Fictional recreation of a Claude Tag conversation for illustrative purposes. Incident details, names, and tools are not real.

Getting started

If you've already done the work from our first post, the Slack deployment is mostly plumbing, though the order is important:

  1. Permissions first. Decide what the service account can read before you write a line of agent code. It's much easier to widen access later than to claw it back.
  2. Distribution second. Pick mounted-repo or skills-over-MCP and verify freshness end-to-end: change a skill file, and confirm Claude Tag picks it up within your SLA.
  3. Telemetry from day one. You will not retroactively instrument month-old conversations. Log the structured event on the very first question.
  4. Knowledge index when you can. The warehouse answers what ; your internal docs and incident feeds answer why. Wire them in as soon as the data path is stable.
  5. Analytics skills last. Create the data-access skill first and then let real questions inform which analyst skills (forecasting, cohorts, funnels) your co-workers actually need.

This article was written by Clement Peng and Lily Zhao, members of Anthropic's Data Science and Data Engineering team, with contributions from Josh Cherry and Michael Segner.