Your Data Agents Need Context

这篇文章发表在 2026 年 3 月，被 a16z 归类为 Infra 赛道的研究。两位作者 Jason Cui 和 Jennifer Li 分别是 a16z 在基础设施和 AI 领域的投资人。

文章用一个三阶段叙事梳理了市场演进的脉络：

• 🏗️ Modern Data Stack 崛起 — 过去十年数据架构经历了 ingestion → transformation → warehousing → storage 的统一化进程（dbt、Fivetran、Snowflake、Databricks）。数据被集中、清理、变得可查询。团队通过 SQL + BI 工具（Looker、Tableau）进行业务分析。
• 🤖 Agent 狂热（2024→2025） — LLM 能力爆发后，几乎每家企业都想在数据栈之上构建 Agent。Bottoms-up（开发者想用最新功能）和 tops-down（管理层想降本增效）同时驱动，诞生了大量"chat with your data"聊天机器人和分析助手。
• 💥 撞墙 — 绝大多数 Agent 部署失败了。MIT 2025 报告指出 AI 部署失败的主因是"脆弱的流程、缺乏上下文学习、与日常运营脱节"。Agent 连最基本的业务问题都答不对。

本文的核心贡献在于：它不是把 Agent 失败归咎于模型能力不足（SQL codegen、推理能力），而是指出问题根源在于缺乏上下文层。

文章还提到了这个领域的多种叫法——context OS、context engine、contextual data layer、ontology——说明这个品类仍在早期，但底层概念是一致的。

文章中段用一个精心设计的例子，逐层展示了数据 Agent 在面对一个看似简单的问题时暴露的深层缺陷。

这个 Query 触发三层失败链：

• 🧱 第一层：业务定义不明 — Revenue 是 run rate 还是 ARR？Fiscal quarter 怎么算的？不同部门有不同的口径。语义层（LookML）理论上可以解决，但它的 YAML 文件可能是已离职同事维护的、BI 工具早已不再使用、也没有包含之后新增的两条产品线。Agent 完全不知道当前的 revenue 定义是什么。
• 🗃️ 第二层：数据源选择 — 描述完定义后，团队发现数据分散在多个表和数仓中。Finance 团队用 fct_revenue 表，Data 团队创建了 mv_revenue_monthly、mv_customer_mrr 等物化视图。Agent 不知道该用哪个表作为真实来源。
• 🧑‍🤝‍🧑 第三层：部落知识 — 很多关键的业务规则没有写在任何文档里，只存在于团队成员的头脑中——哪些产品线的收入应该计入、哪些应该排除、是否有特殊的折扣逻辑。这些隐含知识一旦人员流动就彻底丢失。

文章的核心判断是：这三层问题都无法靠更好的模型解决。即使 GPT-5 的 SQL 能力再强一倍，它还是不知道 revenue 的定义、不知道该查哪个表、不知道产品线之间的排除规则。这不是代码生成问题，是业务语义问题。

值得注意的是，这个问题恰好对应上下文 Lab 受控实验中的不同 Context Level——从裸 Schema（无上下文，准确率 30.8%）到注入规则（准确定义和数据源指引，65.4%），再到 Schema Graph（结构化的上下文关系，76.9%）。文章用叙事论证的，实验用数据验证了。

这句话是整篇最核心的判断：没有上下文的 Agent 不仅是不准确，而是 "useless"。这个定性把 Context Layer 从"可选的优化手段"提升到了"必要的基础设施"的层面。

早期大家认为 Agent 做不好数据分析是因为模型 SQL 能力不够（Spider 2.0 / Bird Bench 基准也确实显示模型落后）。但实际问题是：即使用最好的模型，Agent 也无法理解"revenue"在不同部门的定义差异、无法知道哪个表才是正确的数据源。这是业务语义问题，不是代码生成问题。

这段话定义了 Context Layer 的三层职责：连接（整合散乱数据）- 翻译（注入业务逻辑）- 供给（标准化接口输出）。后文指出这可以通过 API 或 MCP 暴露。

文章明确指出传统语义层（LookML、dbt 指标定义）的局限性：它们通常绑定在特定 BI 工具上、需要手写 YAML、会过时。而 Context Layer 的覆盖范围更广：包括规范实体（canonical entities）、身份解析（identity resolution）、部落知识拆解、治理规则。

这句话标志着投资机构的判断：经过一年多的市场验证，做 Agent 的公司发现瓶颈不在模型、不在数据接入，而在上下文构建。正在催生新的公司品类。

文章基于与客户的交流，提出了现代 Context Layer + Agentic Data System 的完整架构：

• 1. 数据接入（Table Stakes） — 确保 Agent 能访问所有需要的数据。理想情况下通过 Lakehouse 架构实现一定程度的统一。但 Agent 需要的数据不局限于数仓和业务应用，还应包括存储在 GDrive/Slack 等内部系统中的部落知识。这一步是前提条件。
• 2. 自动上下文构建 — 利用 LLM 自动完成初始上下文的收集。重点提取高信号上下文，例如：通过历史查询日志分析最常被引用的表和最常见的 JOIN 模式；从 dbt 和 LookML 等数据建模方案中提取业务指标的明确定义。
• 3. 人工校准 — 自动构建可以覆盖大部分上下文，但无法形成完整图景。最重要的上下文往往是隐含的、条件的、历史权变的——只存在于团队内部的部落知识中。这一步需要领域专家介入，校准和补充自动化遗漏的部分。
• 4. 通过 API / MCP 暴露 — Context Layer 构建完成后，需要通过标准接口供给 Agent。文章指出这通常通过 API 或 MCP（Model Context Protocol）实现。
• 5. 持续维护 — 数据系统不是静态的，Context Layer 也不应该静态。数据源和格式会变化、业务需求会调整、Agent 给出错误结果时需要修正反馈。Context Layer 应该是一个"living and constantly evolving corpus"。

这个架构设计的精妙之处在于：它把 Context Layer 的构建从"一次性工程"变成了持续运营——自动构建降低初始成本，人工校准保证质量，API 暴露实现复用，持续维护防止退化。

文章分析了当前市场的三类参与者：

• 数据引力平台（Databricks / Snowflake） — 它们已经完成了数据接入、转换和存储的基础设施建设，数据引力强大。Databricks Genie 和 Snowflake Cortex Analyst 等产品已提供轻量级语义建模能力。虽然目前没有成熟的 Context Layer 功能，但可以通过收购或自建将 Context Layer 纳入平台。
• 演化型公司 — 一批原本做"chat with your data"的公司，在市场上发现数据 Agent 成败的关键在于上下文构建，因此逐渐将产品方向演化为 Context Layer 的构建和维护。
• 原生 Context Layer 公司 — 从零开始构建 Context Layer 的新公司品类。它们需要完整经历上述的数据接入、部落知识收集等全部流程，并且要为每个客户重复这一过程。

文章认为这是一个正在形成的全新品类，而非已有功能的简单升级。市场仍在早期，很多开放问题尚未定论。

这篇文章不是学术论文，而是风投发出的市场信号。它在说：整个行业都意识到 Context Layer 是 AI Agent 基础设施的关键拼图，这个方向正在成为主流。

上下文 Lab 的数据受控实验（5 个 Context Level × 26 条查询）恰好从量化验证的角度回答了文章提出的核心命题：

• 问题成立吗？ — 是的。Schema-only 准确率仅 30.8%，注入规则后飙升至 65.4%（+34.6pp）。
• 什么结构最有效？ — Schema Graph 达到 76.9%（+46.1pp），验证了文章"context layer 是 semantic layer 的超集"的判断——結構化的上下文远比扁平文本有效。
• 仅仅是模型问题吗？ — 不。同一模型在 5 个 Context Level 下的准确率差异达 46.1pp，证明上下文编排才是决定性因素。

某种意义上，这篇文章是上下文 Lab 的「为什么」，而数据实验是「怎么证明」。

文章在结尾提出了几个开放问题，也是上下文 Lab 可以持续探索的：

• Context Layer 的载体问题：它是独立产品、是数据平台的内置功能、还是协议（MCP）层面的标准？
• 动态维护：文章指出 context layer 应该是"living and constantly evolving corpus"。数据变更、人员流动时如何自动维护上下文？
• 量化评测：文章用叙事论证，上下文 Lab 的实验已经开始了量化评测。我们能否建立 Context Layer 的标准化评测基准？