概述
a16z合伙人Jason Cui和Jennifer Li于3月10日发文指出，过去一年市场已经认清一个残酷现实：数据智能体（Data Agent）在缺乏业务上下文的情况下几乎毫无用处。企业纷纷在现代数据栈上部署AI Agent，却发现它们连"上季度营收增长多少"这样的基础问题都答不好——不是模型不够强，而是Agent根本不理解"营收"在这家公司到底怎么定义、该去哪张表查、财年季度怎么划分。文章由此提出"上下文层"（Context Layer）的概念：一个将企业混乱数据与业务逻辑、部落知识打通的中间层，让Agent真正具备理解企业运作方式的能力。a16z认为这将催生一个全新的市场类别，并梳理了从数据重力平台、AI数据分析公司到专门做上下文层的新兴公司的竞争格局。
你的数据智能体需要上下文
作者：Jason Cui、Jennifer Li（a16z） 发布日期：2026年3月10日
关于"上下文"的上下文
最近在数据和AI Agent的世界里，上下文层与上下文图谱已经成为一个热门话题。事实上，今天你很难和任何一个在数据与AI领域工作的组织交流，而不谈到"上下文"这个词。
这有充分的理由。过去一年，市场已经认识到：数据和分析类Agent在没有正确上下文的情况下基本上是无用的——它们无法解析模糊的问题、解读业务定义，也无法有效地在分散的数据之间进行推理。
当然这不是Agent本身的错。现代数据栈经历了超过十年的演进，从分散的数据源过渡到整合的数据和清洗后的定义（这是好事），但即便如此，整合永远不是完美的，大量的混乱仍然被引入。市场的总体演变过程如下：
1）现代数据栈的崛起 —— 我们曾经与dbt的Tristan Handy一起探讨过现代数据栈的变革性崛起，也在我们自己的参考架构中做过分析。过去十年间，数据架构在数据摄取、转换、仓储和存储方面发生了全面变革，目标是集中化数据并使其快速、便捷地被访问。理想状态下，有了组织良好的数据，团队只需编写SQL就能从数据仓库中提取数据、驱动图表和仪表盘，并在整个组织中实现商业智能。
2）Agent狂潮 —— 2024年进入2025年，随着大模型能力的提升，几乎每一个组织都想在现有的数据栈之上构建和部署Agent。从组织的角度来看，用更少的时间完成更多工作这一天然吸引力，自然地将大家引向了Agent化的工作流。各家公司纷纷尝试构建"和你的数据对话"的聊天机器人、客服Agent等等。这股风潮既是自下而上的——开发者想要使用最新最酷的LLM能力，也是自上而下的——管理层施加AI应用压力，推动自动化和降本。
3）撞墙 —— 尽管初始阶段充满乐观，但很快就清楚了，这些努力大多数都失败了。组织试图部署Agent，但撞上了一堵墙。MIT发布的著名的《2025年商业AI现状》报告指出，在AI部署中，"大多数项目由于脆弱的工作流、缺乏上下文学习以及与日常运营不匹配而失败。"
Agent表现不佳的一个关键原因是缺乏适当的数据上下文。今天的企业数据仍然极度分散和混乱——正因如此，数据Agent连"上季度营收增长多少？"这样的基本问题都难以在各种包含结构化和非结构化数据的数据架构中准确回答。
就像几年前完全自助分析的愿景落空一样，数据Agent的愿景似乎也同样受挫。
上下文问题——不仅仅是Text-to-SQL
那么，那个最初的Agent部署时代为什么会举步维艰？起初，很多人认为问题出在模型端的数据推理和SQL/Python代码生成能力上。通常的想法是：模型应该能够接收自然语言查询作为初始输入，在现有数据系统上进行推理，然后以传统商业智能的方式生成对应的SQL代码，拉取正确的数据并回答问题。
如果模型失败了或不够准确，大家就归咎于模型不擅长SQL，期待模型能力日后改善。
这并非完全错误。虽然模型能力在代码生成和数学推理等用例上有了巨大提升，但在数据方面仍然落后（从Spider 2.0和Bird Bench等SQL基准测试中可以看出）。模型能力确实有了很大飞跃，但我们很快意识到，问题远不止Text-to-SQL。
把营收增长的例子更具体地拆解一下：
假设一个组织在内部构建了一个数据Agent。它利用了现代基础模型，连接了所有正确的数据源，并有一个漂亮的UI来接收内部用户的数据问题。
我们的查询来了。"上季度营收增长多少？"一个看似简单的问题，通常只需瞥一眼Looker或Tableau仪表盘就能回答——对于一个先进的智能Agent来说不应该是挑战！
挑战1——Agent怎么知道营收或季度到底是怎么定义的？ 营收实际上是一个业务定义，它并没有硬编码在数据仓库或管道中。用户看的是运行率收入还是ARR？财年季度报告在不同组织间可能没有统一标准，不同公司可能指的是完全不同的三个月。正确的时间窗口是什么？
幸运的是，数据平台负责人介入说："我们已经构建了语义层来解决这个问题，我们在那里定义了营收。"理论上Agent应该能够将所有语义层作为上下文来摄取。这是一个有前景的方案，但团队查看了几个YAML文件后发现——它们是去年离职的一位数据团队成员更新的，BI工具已经不再使用它们了，而且也没有包含此后上线的两条新产品线。Agent完全不知道今天的营收到底是怎么定义的。
为了绕过这个障碍，一个团队成员手动硬编码了确切的营收和时间定义。数据Agent继续运行，但很快遇到了挑战2——正确的数据源在哪里？哪些才是真正的"数据真相源"？ 原始数据分散在多个表和数据仓库中。财务团队使用的是fct_revenue表，这个可能是对的；但数据团队创建了mv_revenue_monthly和mv_customer_mrr等物化视图。
显然，数据Agent需要访问一个包含最新业务定义和数据源的知识库来克服这些问题。
上下文层登场
问题的核心在于：Agent没有被赋予适当的业务上下文来回答哪怕最基本的问题。这代表了在组织内构建自动化AI系统时存在的一个更大的断层——需要有一个持续更新和维护的上下文，它不仅要理解企业如何运作、数据系统如何架构，还要保存那些将一切串联起来的部落知识。
这催生了上下文层的演进。今天出现了很多名称——上下文操作系统（Context OS）、上下文引擎（Context Engine）、上下文数据层（Contextual Data Layer）、本体论（Ontology）等等——但底层概念是相同的：将企业所有混乱的数据串联起来，在顶层添加一个帮助Agent理解业务逻辑的上下文层，并将其打包成可以供给Agent使用的形式。
上下文管理的"似曾相识"
等一下。我们描述的东西听起来是不是和语义层（Semantic Layer）非常相似？确实有一些相似之处，但归根结底，如果Agent工作流要实现真正的自主运行，它们需要的比语义层当前的形态要多一些。
传统的BI语义层擅长处理特定的指标定义（如营收、流失率、ARPU）。然而，它们通常由数据团队使用非常特定的语法（如LookML）手工构建，并直接连接到Looker等BI工具。
现代数据上下文层应该成为传统语义层所覆盖内容的超集。当然，特定的指标定义可以被硬编码，但现代上下文层应该包含更多内容以确保Agent的自主性——规范化实体、身份解析、用于解析部落知识的特定指令、恰当的治理指南等等。
本文主要聚焦于串联传统"记录系统"的数据上下文。同样重要且有交叉的另一个机会是：捕获组织的决策和工作流逻辑，这样才能构建真正多用途的Agent，使其在组织的所有数据和决策上下文中得到正确的"接地"。
整合到一起
基于我们最近与客户的对话和对其需求的理解，以下是我们认为一个现代上下文层搭配Agent化数据系统应该是什么样的，逐步拆解：
1）接入正确的数据 —— 首要任务是确保所有正确的数据可以被访问。这是基础门槛。理想情况下，组织应该在实施某种形式的现代数据栈，通过湖仓一体架构实现一定程度的统一。即便如此，我们还需要确保Agent可以访问它需要的所有数据，这可能不仅限于数据仓库和运营应用中的数据，还包括内部系统中捕获的部落知识，如GDrive、Slack等。
2）自动化上下文构建 —— 一旦所有正确的数据可被访问，下一步就是开始构建上下文层。使用LLM的好处在于，大量初始上下文的收集可以自动化完成。重点应放在高信号上下文上——例如，查看过去的查询历史可以高效地确定被引用最多的表和最常见的JOIN操作，而dbt或LookML等数据建模解决方案可以提供清晰的业务指标定义。
3）人工精炼 —— 自动化上下文构建可能能够形成上下文语料库的大部分，但它无法生成完整的全貌。让Agent放出去自动收集所有内部知识固然诱人，但一些最重要的上下文是隐性的、有条件的、依赖历史的，只作为部落知识存在于团队内部。
人工输入提供了使真正Agent自动化成为可能的最后一环关键链接。例如——"对于CRM数据，2025年以后所有美加新交易看Affinity，但之前的所有全球线索看Salesforce。"
这样，上下文层就可以成为一个多维语料库，代码与自然语言共存，捕获Agent可能需要的任何上下文。就像开发者可以设置.cursorrules文件来引导Agent和控制输出行为一样，数据从业者也可以维护规则和指南。
4）Agent接入 —— 一旦上下文层被正确构建，它只需要被暴露给Agent并可实时访问。这通常可以通过API或MCP来实现。
5）自更新的上下文流 —— 虽然初始系统已经被正确搭建，但数据系统永远不是静态的，因此上下文层也不应该是静态的。上游数据源和格式可能会改变，用户可能会根据变化的业务需求添加和修改自定义指令。当数据Agent提供了不正确的数据并需要精度修正时，这当然应该被反馈回上下文层。这样，上下文层就成为一个活的、不断演进的语料库。
从整个过程中可以得到一个结论：构建一个合格的数据Agent绝非易事。它是数据基础设施和工程方面的技术挑战与部落知识收集方面的人力运营挑战的混合体。
OpenAI团队最近发布了一篇优秀的文章（ https://openai.com/index/inside-our-in-house-data-agent/ ），详细介绍了他们自己内部数据Agent的创建过程。这是一个非常详细和优雅的实现的透明记录——但也揭示了达到那个目标所需的漫长旅程。同样，Palantir在为组织构建本体论以从混乱数据中提供清晰上下文方面有着悠久的历史，并据此建立了庞大的业务。
市场方向
自然，这为外部解决方案打开了一扇窗口。现实中并非每家企业都能（或应该）自建这套系统，我们已经开始看到各种解决方案涌入市场。
虽然我们认为现在仍处于解决方案成型的早期阶段，以下是正在构建的解决方案的高层市场图谱：
数据重力平台 —— Databricks和Snowflake等平台已经完成了数据摄取、转换和存储的全流程，数据引力的力量非常强大。它们已经在开发AI数据分析产品，如Databricks Genie和Snowflake Cortex Analyst，这些产品构建在数据仓库之上，利用基础模型的Text-to-SQL能力让用户用自然语言提问。虽然这些平台目前的上下文层功能还不够复杂，但它们确实支持轻量级的语义建模，通过收购或内部开发将上下文层引入平台是可行的路径。
现有的"AI数据分析公司" —— 已经涌现了一波利用AI让客户与数据对话的公司。许多公司通过市场实践意识到，有效数据Agent的关键其实是构建相关的上下文层。因此，一些公司已经将数据上下文构建作为其产品的核心组成部分。
新兴的专门做上下文层的公司 —— 一个全新的公司类别已经出现，它们从头开始构建上下文层。它们需要为每一个客户走完上面描述的整个旅程——摄取数据、收集部落知识等等。
展望未来
我们正处于市场发展的一个有趣时间点：缺乏上下文的问题已经变得显而易见，但构建解决方案仍处于早期阶段。
未来令人兴奋——也许真正自助分析的愿景可以完全实现，BI、数据分析和数据科学可以通过AI发生根本性变革。
当然，许多开放性问题仍然存在。这个上下文层将存在于哪里？它能同时存在于多个地方吗？它会成为一个独立的产品吗？
AI 速览
