Data Agent 产品分析框架
核心论断
Data Agent 的护城河不在模型能力，而在上下文深度。 模型是公共基础设施，上下文是私有资产。
两篇关键文章的交汇点：
- a16z（投资视角）：为什么 Context Layer 是关键——大多数 Data Agent 失败于缺乏业务上下文
- OpenAI（实践视角）：怎么把 Context Layer 做到六层深——内部 3,500+ 用户、600PB 数据的实战验证
分析框架：五维评估
维度 1: 上下文深度 ⭐ 核心维度
核心问题: 产品能理解多深的业务语义？
这是 Data Agent 的决定性维度。OpenAI 的六层架构提供了一把标尺：
| 层级 | 内容 | 对应能力 | 难度 |
|---|---|---|---|
| L1 Schema | 表名、列名、数据类型 | 基础 Text-to-SQL | ★☆☆☆☆ |
| L2 Usage | 查询历史、表血缘、join 模式 | 推断常见用法 | ★★☆☆☆ |
| L3 Annotation | 人工标注的业务含义和注意事项 | 理解业务意图 | ★★★☆☆ |
| L4 Code | 管道代码级理解（表怎么产生的） | 区分”看似相似实则不同”的表 | ★★★★☆ |
| L5 Institutional | 组织文档（Slack/Docs/Notion） | 理解业务事件和内部术语 | ★★★★☆ |
| L6 Memory | 从更正和对话中学习 | 持续提升准确率 | ★★★★★ |
检验方法:
问一个需要业务判断的问题：
"上季度收入增长多少？"
→ L1 产品：生成 SQL，可能选错表
→ L3 产品：知道"收入"在这家公司指 ARR 还是 Run Rate
→ L5 产品：知道 12 月有日志故障导致数据缺失
→ L6 产品：记得上次被纠正过要排除内部测试账号
关键洞察（OpenAI Lesson #3）:
Meaning Lives in Code. Schema 和查询历史描述表的”形状”和”用法”，但真正的含义在产生数据的代码中。管道逻辑捕获了 schema 永远不会显现的假设、新鲜度保证和业务意图。
判断标准:
| 等级 | 上下文层级 | 判断 |
|---|---|---|
| 🔴 初级 | 仅 L1-L2 | Text-to-SQL 包装，无竞争力 |
| 🟡 中级 | L1-L4 | 有技术壁垒，但缺组织理解 |
| 🟢 高级 | L1-L5 | 接近”懂业务的分析师” |
| 🔵 卓越 | L1-L6 | 越用越好，形成飞轮 |
维度 2: 推理闭环
核心问题: 出错时能自我修正吗？
Data Agent 的关键差异不是”一次答对”，而是迭代收敛到正确答案的能力。
检验项:
| 能力 | 描述 | 权重 |
|---|---|---|
| 错误检测 | 能发现中间结果异常（零行、数量级错误） | 高 |
| 自主重试 | 调查错误原因、调整策略、重新执行 | 高 |
| 跨轮上下文 | 多轮对话保持完整语境，无需用户重述 | 中 |
| 主动澄清 | 指令模糊时主动提问，而非猜测 | 中 |
| 合理默认 | 无回复时使用合理默认值继续推进 | 低 |
关键洞察（OpenAI Lesson #2）:
Guide the Goal, Not the Path. 高度规范性的 prompt 反而降低结果质量。给高层级目标指导，让模型自己选择执行路径，效果更好。
反面模式:
- ❌ One-shot 查询，答完即走
- ❌ 固定脚本式执行，无法应对意外
- ❌ 出错后只报错不修正
维度 3: 信任基础设施
核心问题: 用户敢拿这个结果做决策吗？
Data Agent 的输出直接影响业务决策。没有信任，再准确也没用。
四层信任:
| 层级 | 内容 | 检验问题 |
|---|---|---|
| 透明性 | 展示推理过程和假设 | 用户能看到每一步怎么得来的吗？ |
| 可验证性 | 链接到底层查询和原始数据 | 用户能自己验证结果吗？ |
| 权限控制 | 严格的数据访问权限 | 是直通式权限还是另起一套？ |
| 评估体系 | 持续的准确率监控 | 有没有系统化的回归测试？ |
关键洞察（OpenAI 评估体系）:
评估不依赖简单字符串匹配。生成的 SQL 可以语法不同但结果正确。比较 SQL 和结果数据，通过 Evals grader 产出评分和解释。
判断标准:
- 🔴 黑盒输出，用户只能”信或不信”
- 🟡 展示 SQL，但不解释为什么这样写
- 🟢 展示完整推理链 + 可验证的中间步骤
- 🔵 上述全部 + 持续评估 + 权限直通
维度 4: 集成深度
核心问题: 产品嵌入工作流有多深？
Data Agent 的价值与其在组织工作流中的嵌入深度正相关。
三级嵌入:
| 级别 | 描述 | 示例 |
|---|---|---|
| 独立工具 | 单独的界面，用户需要切换 | Web 仪表盘 |
| 多入口 | 嵌入到用户已有的工具中 | Slack + IDE + Web |
| 工作流引擎 | 可复用的分析流程，自动化重复任务 | 定期报告、数据验证 workflow |
关键洞察（OpenAI Lesson #1）:
Less is More. 暴露全部工具集导致功能重叠混乱。精简和合并工具调用提升可靠性。Agent 不是人——冗余工具对人可以容忍，对 Agent 是致命的。
检验问题:
- 用户需要离开当前工具吗？
- 能否将重复分析封装为可复用 workflow？
- 工具集是精简的还是臃肿的？
维度 5: 上下文维护成本
核心问题: Context Layer 是活的还是死的？
这是 a16z 文章的核心论点：传统语义层（如 LookML）是静态的、手工维护的、为特定 BI 工具硬编码的。现代 Context Layer 必须是动态自更新的。
检验项:
| 检验项 | 静态（旧） | 动态（新） |
|---|---|---|
| 构建方式 | 手工编写 | LLM 自动提取 + 人工精炼 |
| 更新频率 | 季度/年度 | 每日/实时 |
| 知识来源 | 仅 schema | Schema + 代码 + 文档 + 对话 |
| 暴露方式 | 嵌入 BI 工具 | API / MCP 开放协议 |
| 维护成本 | 高（专人维护） | 低（自动化 + 众包修正） |
a16z 五步实施框架:
- 数据可访问性 → 跨仓库全面访问
- 自动化构建 → LLM 提取高信号上下文
- 人工精炼 → 纳入隐性知识
- Agent 连接 → API / MCP 暴露
- 自更新流程 → 持续反映变化
判断标准:
- 🔴 纯手工语义层，维护成本高
- 🟡 半自动构建，但不能自更新
- 🟢 自动构建 + 人工精炼 + 定期更新
- 🔵 闭环自学习，越用越准，维护成本趋近于零
市场定位矩阵
根据 a16z 的市场观察，Data Agent 玩家分为三类：
| 类型 | 代表 | 优势 | 风险 |
|---|---|---|---|
| 数据引力平台 | Databricks, Snowflake | 现有基础设施 + 用户基数 | AI 能力可能是附加而非原生 |
| AI 数据分析公司 | 各类创业公司 | AI-native 设计 | 缺乏数据基础设施护城河 |
| Context Layer 专家 | 新兴公司 | 专注上下文问题 | 需要与平台集成 |
关键判断: 类似 Palantir 的模式——真正的价值不在工具，而在构建组织本体论的能力。谁能最高效地将企业的隐性知识转化为 Agent 可用的上下文，谁就赢。
快速评估模板
分析一个 Data Agent 产品时，逐项打分（1-5）：
产品名称: ___
评估日期: ___
1. 上下文深度 [ /5] 达到第几层？L__
2. 推理闭环 [ /5] 能自我修正吗？
3. 信任基础设施 [ /5] 用户敢做决策吗？
4. 集成深度 [ /5] 嵌入工作流多深？
5. 维护成本 [ /5] 上下文是活的吗？
总分: [ /25]
定位: [数据引力平台 / AI分析公司 / Context Layer专家]
| 总分 | 判断 |
|---|---|
| 20-25 | 值得深度关注，可能是好案例 |
| 15-19 | 有亮点但有短板，需关注演进 |
| 10-14 | 中规中矩，观望 |
| <10 | 可能是反面教材 |
深层方法论：为什么这个框架有效
Text-to-SQL 是伪命题
大多数 Data Agent 创业公司从 Text-to-SQL 起步。这条路线的天花板极低：
用户问题 → [模型] → SQL → 结果
↑
这里是瓶颈吗？不是。
模型能力已经足够。
真正的瓶颈：
用户问题 → [???] → 正确的表 + 正确的定义 + 正确的过滤
↑
上下文缺失
Palantir 类比
a16z 明确指出 Data Agent 的商业模式与 Palantir 历史模式类似：
| Palantir | Data Agent |
|---|---|
| 为每个客户构建组织本体论 | 为每个企业构建 Context Layer |
| 高度定制化 | 需要理解特定业务语义 |
| 一旦建成，替换成本极高 | 上下文越深，lock-in 越强 |
| 价值在知识图谱，不在工具 | 价值在上下文资产，不在模型 |
飞轮效应
最强的 Data Agent 应该形成这个飞轮：
用户提问 → Agent 回答 → 用户纠正 → Memory 更新
↑ ↓
← ← ← 下次回答更准确 ← ← ← ← ← ← ← ←
检验问题: 这个产品用得越多会越好吗？如果不会，它的上下文是死的。
与主框架的关系
本框架是 AI产品分析框架 在 Data Agent 赛道的垂直化应用：
| 主框架维度 | 本框架对应 |
|---|---|
| 维度 1 时代定位 | Context Layer > Text-to-SQL（AI Native 判断） |
| 维度 2 场景边界 | 效率型场景（分析师不享受找表和 debug SQL） |
| 维度 3 叙事策略 | ”不是更好的 BI，而是懂业务的分析师” |
| 维度 5 商业模式 | Palantir 模式：卖知识图谱而非工具 |
| 维度 6 竞争定位 | 三类玩家矩阵 |
| 维度 7 记忆 | Memory Layer（L6）直接对应 |
参考来源
- 2026-03-10 - Your Data Agents Need Context - a16z - Context Layer 投资论述
- 2026-01-29 - Inside OpenAIs In-House Data Agent - OpenAI - 六层上下文架构实战
- AI产品分析框架 - 主分析框架