上下文六层（Data Agent 专用）
一句话定义
Data Agent 的护城河不在模型能力，而在上下文深度。OpenAI 的六层架构提供了一把标尺：Schema → Usage → Annotation → Code → Institutional → Memory。
出处
OpenAI 内部 Data Agent 实践 (3500+ 用户、600PB 数据)，引入框架：Data Agent产品分析框架 (2026-03-13)。
六层架构
| 层级 | 内容 | 对应能力 | 难度 |
|---|---|---|---|
| L1 Schema | 表名、列名、数据类型 | 基础 Text-to-SQL | ★☆☆☆☆ |
| L2 Usage | 查询历史、表血缘、join 模式 | 推断常见用法 | ★★☆☆☆ |
| L3 Annotation | 人工标注的业务含义和注意事项 | 理解业务意图 | ★★★☆☆ |
| L4 Code | 管道代码级理解（表怎么产生的） | 区分”看似相似实则不同”的表 | ★★★★☆ |
| L5 Institutional | 组织文档（Slack/Docs/Notion） | 理解业务事件和内部术语 | ★★★★☆ |
| L6 Memory | 从更正和对话中学习 | 持续提升准确率 | ★★★★★ |
关键洞察（OpenAI Lesson #3）
Meaning Lives in Code. Schema 和查询历史描述表的”形状”和”用法”，但真正的含义在产生数据的代码中。管道逻辑捕获了 schema 永远不会显现的假设、新鲜度保证和业务意图。
检验方法
问一个需要业务判断的问题：“上季度收入增长多少？”
- → L1 产品：生成 SQL，可能选错表
- → L3 产品：知道”收入”在这家公司指 ARR 还是 Run Rate
- → L5 产品：知道 12 月有日志故障导致数据缺失
- → L6 产品：记得上次被纠正过要排除内部测试账号
等级判断
| 等级 | 上下文层级 | 判断 |
|---|---|---|
| 🔴 初级 | 仅 L1-L2 | Text-to-SQL 包装，无竞争力 |
| 🟡 中级 | L1-L4 | 有技术壁垒，但缺组织理解 |
| 🟢 高级 | L1-L5 | 接近”懂业务的分析师” |
| 🔵 卓越 | L1-L6 | 越用越好，形成飞轮 |
三个使用场景
- 评估 Data Agent / BI / Text-to-SQL 类产品：用六层标尺打分，判断真护城河深度。
- 诊断”AI 数据分析助手”叙事：声称懂业务但只做到 L1-L2 = 包装；做到 L5+ = 真有壁垒。
- 客户咨询数据 Agent 路径：客户产品在哪一层？建议向 L4-L6 延伸（领域状态壁垒最深）。
与吞噬经验的关系
- L6 Memory 层 = 吞噬经验的具体形态（吞噬经验 在 Data Agent 场景的实现）
- L6 + 用户更正 = 飞轮形成 = 用得越久越好
反例 / 边界
- ❌ “我们做 Text-to-SQL” — 仅 L1-L2，无竞争力
- ❌ “我们集成了所有数据源” — 集成深度 ≠ 上下文深度
- ✅ “我们读管道代码理解业务含义” — 到 L4
- ✅ “我们从用户纠正中学习” — 到 L6
典型案例
- ✅ OpenAI 内部 Data Agent — L6 卓越
- 大量”Text-to-SQL”产品 — L1-L2 初级
相关术语
- Agent-native 壁垒 — L4-L6 = 领域状态壁垒
- 吞噬经验 — L6 的具体形态
- ORR - Observe-Record-Replay — L6 的另一种实现路径