Anthropic 内部 95% 数据分析自动化：分析 Agent 技术栈 + Skill 框架（21%→95% 准确率）¶

Ch09.003 Anthropic 内部 95% 数据分析自动化：分析 Agent 技术栈 + Skill 框架（21%→95% 准确率）¶

📊 Level ⭐⭐ | 49.2KB | entities/anthropic-95pct-data-analysis-skill-stack-architecture.md

Anthropic 内部 95% 数据分析自动化¶

一句话总结¶

"Anthropic 的做法是：95% 的业务数据分析请求由 Claude 自动完成，整体准确率约 95%。"

让公司里的非技术同事自己查数据这件事一直很难： - ❌ 把数据表做宽做平 → 各种口径不一致的视图越堆越多 - ❌ 给每个团队划出独立数据环境 → 长尾业务问题没人覆盖 - ✅ 大模型给了第三条路 — 但需要把分析 Agent 栈做好

深度分析¶

1. 数据分析的 95% 自动化目标¶

Anthropic 提出数据分析 95% 可由 AI 自动完成的假设——但这 95% 是"标准分析"（描述统计、趋势分析、异常检测），剩余 5%（因果推断、实验设计、业务判断）是最有价值的。

2. Skill Stack：AI 能力的分层架构¶

Skill stack 将 AI 数据分析能力分为层次：基础层（数据读取/清洗）→ 分析层（统计/可视化）→ 推理层（因果/预测）→ 判断层（业务决策）。每一层的自动化程度不同。

3. 与 Harness Engineering 的关系¶

Skill stack 是 harness 的上层——harness 管理"AI 能做什么"（工具和权限），skill stack 管理"AI 做得有多好"（能力和质量）。

实践启示¶

1. 从 95% 标准分析自动化开始¶

先自动化描述统计、趋势分析、异常检测——这些模式固定、规则明确，自动化 ROI 最高。

2. 5% 高价值分析仍需人类¶

因果推断、实验设计、业务判断不能交给 AI——将人类聚焦于这 5%。

3. 量化自动化的覆盖率¶

追踪 AI 自动完成的分析任务占比——95% 是目标，当前可能在 60-70%，逐步提升。

相关实体¶

• Anthropic Claude Cowork Task Boundary 5 Signals 6 Stages
• Anthropic 官方技能最佳实践14 个可复用的 Agent Skills 设计模式
• Anthropic Dreaming Claude Managed Agents Ovz5V7Jjkqdksu9Xmxwt8W
• Anthropic 12 Mcp Production Patterns
• Tencent Skill Writing Complete Playbook Jackjchou

→ 原文存档

• 使用Claude Codesession管理与1M上下文
• Anthropic 95Pct Data Analysis Summary 189 Chars
• 大反转马斯克牵手对手 Darioanthropic 与 Spacex 罕见合作
• Anthropic Dynamic Workflows Ultracode Deep Research Lyuyuebannzi
• MOC

数据分析 ≠ 写代码（核心区分）¶

核心问题：

"自助式业务数据分析，复杂性主要来自数据本身的模糊性。核心问题是：能不能把用户的问题准确映射到数据模型里具体的、最新的字段，并且知道怎么正确地使用它们。"

3 大失败模式（Anthropic 总结）¶

① 概念与字段的映射模糊¶

• 数据模型里可能有几百个候选字段（乃至数百万个字段）
• Agent 无法确定哪个最能回答用户的问题
• 例：统计活跃用户数 — 什么行为算活跃？要不要把欺诈用户算进去？回溯窗口用多长？

② 数据过期¶

• 数据源 / 业务定义 / 表结构在不断变化
• Agent 掌握的知识随之过期
• 开始给出表面看起来合理、实际上有偏差的答案

③ 检索失败¶

• 正确的信息可能就在数据模型里，也有完整的注释
• 但数据仓库的搜索空间实在太大，Agent 就是找不到它

Anthropic 分析 Agent 技术栈（分层架构）¶

"针对这三类失败，Anthropic 建了一套分层的数据技术栈，每一层专门对付一个或多个问题。"

┌─────────────────────────────────────────────┐
│  Skill  (对付检索失败)                       │
│  + 程序性知识：按什么顺序查哪些数据源         │
├─────────────────────────────────────────────┤
│  可信数据源 (4 类) (对付映射模糊)              │
│  语义层 / 血缘图 / 查询语料库 / 业务上下文     │
├─────────────────────────────────────────────┤
│  数据基础 (对付数据过期)                       │
│  数据模型 + 转换逻辑 + 测试 + 元数据           │
└─────────────────────────────────────────────┘

第 1 层：数据基础¶

核心断言：

"确保分析 Agent 准确的最重要因素，是扎实的数据基础"

没变的事：维度建模 / 左移测试 / 关键数据管道的新鲜度和完整性检查 — 传统数据工程最佳实践依然重要

变化的事：

"变化的是：数据模型的最终用户不再是数据专家，而是代表不同背景用户的 Agent"

挑战：结果的正确性无法依赖用户自己去验证，因为用户根本不了解底层

4 大关键做法¶

1. 建立权威数据集： - 维护少量、受强治理的逻辑模型（明确归属 / 面向消费 / 可被发现） - 坚决废弃那些近似的重复数据集 - 物理上的汇总表和缓存表仍然有存在意义，但应该是从权威模型机械派生出来的 - 目标：当 Agent 搜索某个概念时，只找到一个权威答案

2. 执行标准，不能只靠约定： - 靠工具强制执行（Agent 在结构上被引导先查权威模型） - 靠 CI 强制执行（绕过权威模型的改动无法通过代码审查） - 靠规定强制执行（下游团队必须基于权威层构建，否则需要说明理由） - 没有执行机制的治理，很快就会退回到多个候选数据集共存的问题

3. 把所有产出放到一个代码库里： - 几乎所有数据代码 — 建模、语义层、参考文档、权威看板定义 — 都在一个代码库里 - CI 检查保护跨层的完整性 - 如果一个建模变更会破坏下游看板或让某个文档化的指标失效，CI 会标记出来，修复在同一个 PR 里完成

4. 把元数据当成一等公民的产品来维护： - 列和表的描述 / 权威指标定义 / 粒度文档 / 有效值范围 / 数据血缘 / 归属信息 / 模型分级 - 像维护转换逻辑本身一样严格地维护

第 2 层：可信数据源（4 类，按可信度从高到低）¶

1. 语义层¶

编译好的指标和维度定义

• 如果一个问题能干净地映射到某个已定义指标，Agent 调用一个函数就能得到一个数字
• 和公司其他所有地方产出的数字一致
• Agent 被强制要求（通过 Skill 指令）优先使用语义层

踩坑教训：

"用大模型根据原始表和历史查询日志自动生成语义层指标定义。结果是生成了看起来合理的定义，但这些定义把原本要消除的那些歧义都编码进去了。建议：用 Claude 来生成文档，但定义本身要由人来负责。"

2. 数据血缘和转换依赖图¶

当语义层覆盖不到某个问题时： - 血缘关系 - 基于引用次数的表排名 - 可以让 Agent 推断哪些上游模型为某个概念提供数据、哪些已经废弃、哪些粒度相同 - "这把'我不知道这个指标'变成了'我知道应该从哪个受治理的模型里聚合'"

3. 查询语料库¶

来自看板、Notebook 和历史分析的 SQL：

• ❌ 直接给 Agent 访问数以千计的历史查询 — 准确率变化不到一个百分点
• ✅ 真正有用的做法：把查询语料提炼成结构化的、按领域划分的参考文档和可复用的分析模式，写进 Skill
• 查询历史是用来整理的原材料，不是 Agent 直接读取的数据源

4. 业务上下文¶

"这是大多数团队跳过的一层，也是 Anthropic 自己低估最久的一层。"

核心洞察：

"不了解业务的 Agent，会回答用户问的问题，而不是用户想要的答案"

业务上下文包括： - "Q2 发布" 指的是哪个具体产品 - 两个团队对同一个术语的定义不同 - 某个问题是因为周四有董事会会议才被提出来的

Anthropic 的做法：

"Anthropic 把公司知识图谱接入进来，包括索引过的文档、路线图、决策记录和组织架构，让 Agent 能够解析这些隐性引用，提出更好的澄清问题。"

4 类来源的共同失败模式：文档差或者文档过期。Claude 在弥补这个差距上非常有用（起草列描述、根据查询模式生成指标文档、在 CI 中标记没有文档的模型），但整理和归属权由人来管理。

第 3 层：Skill（程序性知识）¶

"可信数据源是 Agent 的声明性知识（即指标是什么意思），Skill 是它的程序性知识：按什么顺序查哪些数据源、如何处理模糊的数据、一个完整的分析应该是什么样子。"

Skill 定义：在 Claude Code 里，Skill 是一个 Agent 按需读取的 Markdown 文件夹

21% → 95% 准确率（核心数据）¶

"Anthropic 自己的经验是：不加 Skill，Claude 回答数据分析问题的准确率在评测集上不超过 21%。加了 Skill 之后，整体准确率稳定在 95% 以上，某些领域能达到 99% 左右。"

4.5 倍提升 — 这是本文最震撼的数据

关键做法¶

1. 成对创建 Skill：

路由器本质：

"路由器本质上是对检索失败问题的解答：不让 Agent 搜索一个有数百万字段的仓库，而是在写任何查询之前，先把范围收窄到几十个经过整理的文件。"

2. 写好参考文档：

• 参考文档是面向大模型检索写的
• 描述表的粒度、范围和排除条件
• 描述注意事项的具体机制（例：排除已知的免费邮件域名，但保留像 anthropic.com 这样的自定义域名）
• 加入明确的路由触发条件（例：如果问题涉及实验提升效果，不要用原始事件计数）
• 不要写成容易过期的操作步骤

3. 模板框架（Anthropic 主要参考文档模板）：

# [领域] 数据表

## 快速参考
### 业务上下文 — [用大白话描述这个领域是什么]
### 记录粒度 — [一行记录代表什么]
### 标准过滤条件 — [该领域每个查询都需要应用的过滤器]

## 维度说明
- [关键维度的编码方式，以及同一个概念在不同表里的不同命名]

## 关键数据表
### [表名]
- **粒度**: [...] · **范围/排除**: [...]
- **使用场景**: [什么时候用、什么时候不用、JOIN键、必须应用的过滤器]
[... 每个受治理的表写一个小节 ...]

## 注意事项
- [资深分析师会提醒你的那些容易踩坑的地方]

## 最佳实践与常见查询模式
- [默认选择、标准维度、查询形式本身就是难点的典型模式]

## 交叉引用
- [负责相邻问题的其他领域文档]

4. 把 Skill 维护当成一等公民的工程任务：

真实事故：

"Anthropic 曾经亲眼看到：上线时离线准确率约 95%，一个月后跌到约 65%，才意识到这是个工程问题需要认真对待。"

解决方案： - 把 Skill 的 Markdown 文件和转换模型放在同一个代码库里 - 改模型的 PR = 更新描述文档的 PR - 代码审查钩子标记任何改动了报表模型但没有同时改动 Skill 文件的 PR - 现在约 90% 的数据模型 PR 都在同一个 diff 里包含了 Skill 的变更

5. 在所有界面保持一致：

"同一个 Skill 必须在 Slack、IDE、看板工具和独立的 Agent 会话里给出同样的答案。做到这一点的方式是：保持单一的权威来源（数据代码库），Skill 变更自动同步。"

合并后 Skill 会同步到 3 个地方： - 插件市场（供 IDE 用户使用） - 云存储 Blob（供读取单个文件的托管应用使用） - 直接通过 MCP 以资源形式提供服务

第 4 层：验证（离线评测 + 在线验证 + 消融实验）¶

离线评测¶

核心做法：

"离线评测是解决这个问题的方式，本质上就是简单的问答对。可以把它类比成机器学习模型的离线测试，不能告诉你在线系统的表现，但能让你发现明显的盲区。"

Anthropic 两类评测： 1. 基于看板的评测 — Claude 自动生成（再经人工校验），覆盖最常见的业务方问题 2. 长尾评测 — 把业务上下文（路线图、表文档）喂给 Claude，让它生成该领域其他合理的问题 3. 持续积累：每当业务方在某个对话线程里纠正 Agent，这个纠正就成为候选评测用例

6 大关键实践：

消融实验¶

"每一个关于 Skill 结构的决策（暴露哪些数据源、某个子 Agent 的延迟是否值得、要不要把两个 Skill 合并），都通过固定离线评测集、只改变一个变量来做出，比较通过率的变化。每次运行只需要一个小时，能替代大量口头讨论。"

3 大实践：

1. 把负面结果当成有价值的结论：

"Anthropic 最有用的一次消融实验，结论是负面的。他们给 Agent 开放了对整个看板、转换模型和分析 Notebook SQL 的直接 grep 访问（数千个文件），在对话记录里验证了 Agent 在每次回答之前确实读了这些文件，但准确率的变化不到一个百分点。"

关键发现： - 答案在语料库里有的情况 约 80% - 知道答案在语料库里能不能预测它接下来会答对？不能 - 信息就在那里，Agent 也看了，就是用不上 - 核心洞察："瓶颈不在于能不能访问已有的工作，而在于结构（能不能把问题映射到正确的实体）。"

2. 在 PR 粒度上做消融： - 每次有意义的 Skill 改动，在相关评测切片上跑改前改后对比 - 把差值写进 PR 描述里 - 让"我改进了文档"变得可验证

3. 记录一份"有什么没用的"清单： - 例：在某个节点之后继续叠加文档打磨轮次（连续三轮净负面：文档越来越长，但并没有变得更好） - 例：把对抗性审查器换成更便宜的模型（准确率的提升大部分消失了，速度却没有真正提升）

在线验证（6 大机制）¶

1. 对抗性审查：

"部署一个 Claude Skill 来激进地质疑每个潜在最终答案的底层假设，在评测集上准确率提升了 6%，代价是 Token 消耗增加 32%，延迟增加 72%。"

2. 来源标注页脚： - 每个回答都带一个页脚，注明： - 数据来自哪个层级（语义层 / 权威参考文档 / 原始表） - 底层数据的新鲜程度 - 模型的归属团队 - "原始表，新鲜度未知" 这样的页脚是一个提醒：在向上汇报之前先核实 - "这是目前为数不多的针对静默失败问题的缓解手段之一"

3. 数据质量检查： - Agent 可能在用法上完全正确，但数据本身是错的 - 对被引用字段做基本的数据质量检查 - 确认它是最新的、完整的、没有异常

4. 被动监控： - 持续追踪两个生产信号： - Agent 查询通过语义层解决的比例 - 回答中出现纠正语言的比例（"那是错误的表" / "你没有应用欺诈过滤"） - 两个信号都汇入一个看板，每周和离线通过率一起 Review

5. 主动收集纠正案例：

"一个定时 Agent 每隔几小时扫描业务方的沟通渠道，发现类似的纠正语言后，起草对相关参考文档的一行修复，发起一个 PR 并 @ 到对应的领域负责人。修复路径被故意设计得无聊：改一个 Markdown 文件，合并，自动同步到所有地方，不占用领域负责人太多时间。同样的纠正案例也会回流到离线评测集中。"

6. 没有完全解决的静默失败问题： - 答案是错的，但看起来合理，没有人提出异议就被直接用了 - 缓解措施： - 来源标注页脚 - 对发给高层的任何内容要求人工确认 - 为每个领域的核心 KPI 设置固定评测，每天与权威看板做对比检查 - "但 Anthropic 承认目前还没有一个完善的解决方案"

从零开始怎么做¶

"如果是从零开始，几个权威数据集、几十个离线评测用例，加上一个轻量的知识型 Skill，就能拿到大部分收益。本文介绍的其他内容，都是在这些基础上逐步叠加的。"

采用前 5 大组织对齐问题：

终极断言：

"无论选择哪条路，Anthropic 取得最大收益的地方始终是解决那三类失败：把模糊性收拢为唯一的权威答案，让这个答案容易被找到，以及在两者过期时发出信号。"

附录：Skill File Skeleton（Anthropic 真实框架）¶

"以下是 Anthropic 主要的数据仓库 Skill 的框架，真实文件的结构保留了下来，内部具体内容替换成了占位符。这份框架的目的是展示值得写下来的内容类型，不是用来直接复制的。"

核心结构（5 大部分）：

1. YAML frontmatter — 描述（哪些问题用这个 Skill / 哪些相邻任务不要用）
2. 描述 — 安全有效执行查询的唯一权威来源
3. 执行查询 — 优先顺序（托管连接 → CLI 备用 → 用户认证）
4. 语义层 — 强制默认路径
5. 3 大主体部分：
6. 第 1 部分：必须了解（每次请求先读）— 快速工作流 / 业务上下文 / 实体消歧义 / 数据完整性要求
7. 第 2 部分：操作方法（执行过程中遵循）— 技术执行 / 分析最佳实践 / 对抗性 SQL 审查
8. 第 3 部分：数据参考资料与资源 — 知识库导航 / 故障排查指南

关键设计原则： - "不要过早放弃" — 不得以下列理由回退到原始 SQL（自定义日期过滤/队列、需 JOIN 等借口） - 实体消歧义必须澄清（"术语 A" 可能指实体 1 或 2） - 禁止编造数据/字段（数据完整性要求 ⚠️） - 对抗性 SQL 审查必须执行（阻塞性问题必须修复并重新审查，不能自我认证） - 带来源信息地汇报（每回答末尾附来源 / 可信度 / 已审查 / 数据新鲜度 / 归属 5 字段）

与已有实体的关系¶

• Anthropic 14 Skill Patterns Best Practices / Anthropic Agent Skills Design Patterns 14 — 14 个 skill 设计模式
• 本实体 = 1 个特定 Skill 类别（数据分析 Skill）的完整架构 + 真实框架

• 互证关系：14 模式 = 通用原则；本实体 = 通用原则在数据分析领域的具体落地

• Hermes Agent Skill Crossover Optimization / Darwin Skill 2 Huashu — Darwin SkillEvolver 生态

• 本实体 = 工业级 Skill 维护的真实工程实践（90% PR 同 diff / 自动同步到 3 个分发渠道）

• 互证：互优化 = 技能自进化；本实体 = 技能在企业中的工程治理

• Is Grep All You Need — 检索失败问题

• Anthropic 路由器 Skill 同样把检索范围从数百万字段收窄到几十个整理过的文件 — 直接验证了该论文的"inline + 字面证据"价值

核心金句¶

• "95% 的业务数据分析请求由 Claude 自动完成，整体准确率约 95%"
• "自助式业务数据分析，复杂性主要来自数据本身的模糊性"
• "没有任何确定性的方式来证明答案是对的"
• "数据模型的最终用户不再是数据专家，而是代表不同背景用户的 Agent"
• "没有执行机制的治理，很快就会退回到多个候选数据集共存的问题"
• "目标：当 Agent 搜索某个概念时，只找到一个权威答案"
• "用 Claude 来生成文档，但定义本身要由人来负责"
• "查询历史是用来整理的原材料，不是 Agent 直接读取的数据源"
• "不了解业务的 Agent，会回答用户问的问题，而不是用户想要的答案"
• "不加 Skill，Claude 回答数据分析问题的准确率不超过 21%"
• "加了 Skill 之后，整体准确率稳定在 95% 以上，某些领域能达到 99% 左右"
• "路由器本质上是对检索失败问题的解答"
• "不要写成容易过期的操作步骤"
• "上线时离线准确率约 95%，一个月后跌到约 65%"
• "改模型的 PR = 更新描述文档的 PR"
• "同一个 Skill 必须在 Slack、IDE、看板工具和独立的 Agent 会话里给出同样的答案"
• "离线评测是简单的问答对，类比机器学习模型的离线测试"
• "按领域设置上线门槛 — 最初设定的是约 90%"
• "每一个正确答案也应该能通过语义层得到"
• "把负面结果当成有价值的结论"
• "信息就在那里，Agent 也看了，就是用不上"
• "瓶颈不在于能不能访问已有的工作，而在于结构（能不能把问题映射到正确的实体）"
• "对抗性审查：准确率 +6%，Token 消耗 +32%，延迟 +72%"
• "原始表，新鲜度未知 — 提醒：在向上汇报之前先核实"
• "Anthropic 承认目前还没有一个完善的解决方案（静默失败）"
• "修复路径被故意设计得无聊：改一个 Markdown 文件，合并，自动同步到所有地方"
• "几个权威数据集、几十个离线评测用例，加上一个轻量的知识型 Skill，就能拿到大部分收益"
• "Anthropic 取得最大收益的地方始终是解决那三类失败：把模糊性收拢为唯一的权威答案，让这个答案容易被找到，以及在两者过期时发出信号"

2nd Source：极简短摘要文（2026-06-05）—— 189 字摘要存档¶

来源：未标注公众号摘要文（2026-06-05） 关系：与 1st source 同源不同公众号的极简摘要报道。Anthropic 数据科学团队博客原文（2026-06-04 公开）已被 1st source 深度收录；本文仅作 2nd source 存档。 信息密度评估：仅 189 字，与 1st source 内容重叠度高（仅含 95%、21%→95%、95% 自动化 3 个核心数字），无 1st source 未覆盖的独家数据。

极简摘要文原文（189 字）¶

Anthropic 的数据科学团队昨天发了篇博客：

他们内部 95% 的业务数据分析查询，现在都已经由 Claude 自动完成了，准确率大约是 95%。

数据团队也因此能腾出了手来，专注做因果建模、预测和机器学习这些更有价值的工作。

在这篇博客中，Anthropic 公开了整个技术栈的细节，包括踩过的坑、试错的数据……以及一个让准确率从 21% 飙到 95% 的关键发现。

Sources 对照¶

两源关系：同源不同公众号（同一 Anthropic 官方博客 + 不同公众号的极简摘要报道）。按"同源不同公众号 = merge"规则，本节作为 2nd source 章节保留可追溯性（无独家数据，纯传播记录），与 1st source 形成"完整技术栈 vs 极简摘要"对比。

3rd Source：架构师 JiaGouX 数据级 Harness 视角（2026-06-06）—— 5 个反直觉边界¶

来源：架构师（JiaGouX） 2026-06-06 解读 关系：与 1st source 同源（Anthropic 2026-06-03 官方博客），但架构师独特视角：① 提出"数据级 Harness"概念 ② 揭示 95% 数字背后 5 个反直觉边界 ③ 引用 12 个上游原始资料（a16z / Snowflake / Benn Stancil / Atlan / Karpathy / Hamel Husain / Genloop） 信息密度评估：8297 字，与 1st source 互补不重叠——1st 聚焦"技术栈 4 层 + 4 类可信数据源 + Skill 框架细节"，3rd 聚焦"95% 数字背后 5 个反直觉边界 + 数据级 Harness 概念 + 数据科学角色迁移"

架构师独特洞察：先把口径放清楚¶

它不代表 95% 的数据科学判断都交给 Claude 了。也不代表把模型接进数据仓库，再给业务同事一个聊天框，就能得到同样效果。更像是这样：大量重复、日常、口径相对稳定的数据请求，正在从「人手工查数」转到「Agent 按流程查数」。

人被释放出来以后，可以更多做因果建模、预测、机器学习和更复杂的业务分析。

架构师的核心追问："当一个数字错了，却看起来非常专业，谁能发现它。"——这与 1st source 的"静默失败"主题完全一致但表达角度不同（架构师更强调"人审在关键节点"而不是"系统自检"）。

错得很安静：false sense of precision¶

"上周"是最近 7 天，还是完整自然周？"企业客户"是否排除测试账号、欺诈账号、内部账号？"收入"是账单收入、确认收入、净收入，还是某个业务团队自己的口径？这些已经超出了 SQL 语法问题。SQL 写得再漂亮，也可能查的是错表、错字段、错时间窗口。

业务用户通常看不到底层数据模型。他只看到一个答案。答案越流畅，越容易被转发到周报、会议、经营分析里。

Anthropic 用的词：false sense of precision——看起来很精确，但它未必是对的。

数据不是代码（Data is not software）¶

写代码时，Agent 有很多反馈。测试会红，类型会报错，函数会跑不通，线上也能打日志。模型第一次写错了，系统会给它很多反向信号。数据分析给不了这么多硬反馈。很多查询能跑通。图表也能画出来。答案仍然可能错。错的原因不是执行失败，而是定义错了。

架构师的工程翻译： - AI Coding 的难点常常在执行和回归验证 - AI Analytics 的难点先在定义

消融实验的反直觉发现¶

Anthropic 给 Agent 直接开放数千个 Dashboard、转换模型和分析 Notebook SQL 的检索访问，结果准确率变化不到 1 个百分点。还有一个细节更关键：约 80% 的错误问题里，正确答案其实就在语料库中。信息存在，模型也看到了，但它仍然没有用对。

架构师的判断： - RAG 解决的是"有没有材料可读" - 数据分析 Agent 要补的是另一层判断：这次问题里，哪份材料才算权威。哪份已经过期。哪份只适合某个团队。哪份不能直接套用 - 企业要小心的地方就在这里

数据 Agent 上下文 = 工作现场，不是一堆文档¶

架构师引用 3 个外部观点构成上下文层共识： | 引用 | 来源 | 核心观点 | |------|------|----------| | a16z 《Your Data Agents Need Context》 | 2026-03 | 数据 Agent 的短板不在更多文本，而在能不能把业务定义、数据源、隐性知识和治理规则连起来 | | Snowflake 《Agent Context Layer》 | 2026 | Agent Context Layer for Trustworthy Data Agents | | Benn Stancil 《The Context Layer》 | 2025-08-29 | 给分析师一堆工具账号，不等于完成了入职；给一个 bot 同样的数据入口，也不等于它就懂业务 | | Atlan | 2026 | MCP 是传递上下文的线，不是上下文的生产、治理和版本系统 |

架构师的核心洞见：信息越多，如果没有排序、归属、路由和验证，反而会变成噪声。数据分析里的上下文，不是一堆文档。它更像一套长期维护的工作现场。

Skill 是规程：MCP 提供工具和连接，Skill 提供做事的方法¶

架构师把 Claude Code 的官方区分（"MCP 提供工具和连接，Skill 提供做事的方法"）落到数据分析场景：

数据库连接器告诉 Agent：能查哪些数据。数据仓库 Skill 告诉 Agent：这类问题该怎么查。

一个数据仓库 Skill 至少要写清这些东西（架构师补全 1st source）： - 什么时候默认先查语义层 - 什么时候要澄清时间窗口 / 分母 / 用户范围 - 哪些指标有权威定义，哪些表已经废弃 - 哪些问题只能返回数据，不能替业务下结论 - 涉及隐私或受限数据时，权限由系统层拦住 - 最终回答要带来源 / 数据新鲜度 / 置信度 / 负责人

架构师的流程图判断：流程越靠前，越需要先处理语义和红线。这不是把 prompt 写长一点。它是在把资深分析师的工作规程写进运行时。

与 1st source 的互补：1st source 给出了 Skill 框架的完整 4 类（Unbook + 知识型路由器 + 对抗性审查 + Skill File Skeleton 附录），3rd source 给出了"一个数据仓库 Skill 至少要写清的 6 项"清单——前者是结构，后者是内容。

95% 背后的 5 个反直觉边界（架构师独家）¶

Genloop 的评论提醒得很直接：Anthropic 的 95%，更接近一套被资深数据团队持续维护后的稳态结果，不是新团队把 Claude 接上数据仓库后的冷启动表现。

5 个边界： 1. 维护成本不低。Skill 描述的是每天都在变化的数据模型。如果不维护，几周内就会失真。Anthropic 看到过离线准确率从约 95% 漂移到约 65%。后来他们把 Skill Markdown 和数据转换模型放在同一个 repo 里。数据模型 PR 如果没有同步改 Skill，会被代码审查 hook 标出来。现在他们约 90% 的数据模型 PR 都包含 Skill 变更。 2. 验证也要付成本。对抗性审查在评测集上带来 6% 的准确率提升。代价是 token 增加约 32%，延迟增加约 72%。高风险分析里，这个成本可能划算。日常临时问题里，要按场景算账。 3. 权限不能交给提示词。让 Agent "优先走语义层"是流程约束，不是安全边界。行级权限 / 隐私字段 / 财务数据 / 客户数据，要在系统层执行。只在 Skill 里写一句访问限制，挡不住真实风险。 4. 组织边界会断开维护链路。数据工程 / BI / 财务 / 销售运营 / 产品分析，如果各自维护自己的口径和文档，Agent 看到的就会是一个拼出来的世界。人类分析师还能靠经验知道"这个看板别用，那个字段老了"。Agent 不一定知道。除非这些经验被写进可维护、可审查、可过期的系统资产里。 5. 静默失败还没有彻底解法。Anthropic 自己也承认，最难的是那种没人指出来的错误。答案错了，但语气自然、数字完整、图表漂亮，于是它被放进汇报、周会和决策材料里。来源页脚 / 领导汇报前的人审 / 核心 KPI 每天对权威看板，都只能降低风险。它们只能托住一部分风险。

数据级 Harness 概念（架构师独家提出）¶

架构师把 Agent Harness 的概念延伸到数据领域，提出"数据级 Harness"——不是"用户 → Agent → 数据库 → 答案"这种扁平架构，而是围绕模型的一圈东西：

让系统可用的，是围绕模型的一圈东西： - 权威数据集减少候选项 - 语义层提供一致指标 - 血缘和转换图说明数据从哪里来 - Skill 固化工作流程 - 离线评测暴露盲区 - 对抗性审查挑战错误假设 - 来源页脚暴露可信度 - 用户纠错回流到文档、评测和 Skill

我说的数据级 Harness，大概就是这层东西。它不保证答案永远正确。但至少把"为什么这么查、用的是什么口径、靠什么验证、错了怎么改"放进了系统里。

与 1st source 的互补：1st 给出 4 层技术栈（数据基础 / 可信数据源 / Skill / 验证），3rd 给出数据级 Harness 的 8 元素——前者是分层架构，后者是机制清单。

最小启动清单（架构师实操）¶

架构师不写"先做公司级聊天查数入口"，而是"先小一点"：

可以先列一张表：

一开始覆盖面小没关系。关键是先把闭环跑起来。能不能稳定回答 10 个高频问题。错了能不能复盘。口径变了能不能同步。权限能不能挡住。成本和延迟能不能接受。这些跑顺以后，再扩领域。

数据科学角色迁移：The Revenge of the Data Scientist¶

架构师引用 Hamel Husain《The Revenge of the Data Scientist》和 Josh Wills 2012 经典推文：

LLM API 让很多团队觉得自己可以绕过数据科学，直接把 AI 功能接进产品。可系统真要稳定，最后还是要回到 traces、错误分类、评测集、指标设计、标签质量、数据漂移这些基本功。

数据科学家是比软件工程师更懂统计、又比统计学家更懂软件工程的人。

AI 把执行层抬起来以后，很多人会以为"写代码""写 SQL""写报告"这些活被模型接过去了，专业角色就退场了。我的看法偏保守一点。角色会变，但那套能力没有退场。它只是从"亲手产出每一个分析结果"，往"设计数据口径、评测方法、错误分类、验证流程和反馈闭环"迁移。

Karpathy AutoResearch 类比¶

架构师把 AutoResearch 与数据分析对接：

AutoResearch 好看的地方，不是"AI 自己跑实验"这句话。而是它把自动循环放进了一个很小的 Harness：固定文件边界、固定时间预算、固定指标、可回放日志、可审查 diff。

Aakash Gupta 推论：凡是有清楚评分的系统，都可以迁移这种循环。

架构师的判断：很多业务问题没有一个像 val_bpb 那样干净的分数。但高频问题 / 权威指标 / 固定口径 / 历史正确答案 / 核心看板对账，可以先凑出一批可回放的评测点。

核心结论（架构师定调）¶

Anthropic 分享的这套 Claude 自助数据分析，远不只是把 SQL 门槛抹掉。它会把企业里原本藏在分析师脑子里、Dashboard 背后、Slack 讨论里、历史 SQL 里的那套隐性知识，推到系统层。

以前这些东西散一点，靠人还能兜住。Agent 进来以后，散就会变成风险。因为它会很快、很自信、很流畅地把一个混乱口径变成一个漂亮答案。

企业级 AI 数据分析的上限，不只取决于模型会不会写 SQL。它取决于企业有没有把数据口径、业务语义、分析流程、验证机制和责任边界，工程化地封装进 Agent 的运行环境里。

昨天我们聊 AI 研发级 Harness。今天换到数据仓库，结论差不多：当 Agent 进入执行层，系统就要补上定义、验证和刹车。不然它越能干，错起来也越像真的。

Sources 对照表（3 sources）¶

三源互补： - 1st = 技术栈分层（What to build） - 2nd = 传播存档（无独家） - 3rd = 数字背后边界 + 机制清单（How to think / Where to start）