数据智能体为何失败？缺的是上下文

最近在数据和 AI 智能体领域，上下文层和图（Context Layers and Graphs）成了热门话题。现在跟任何做数据和 AI 的组织聊天，上下文都是绕不开的点。

这很正常。过去一年，市场发现没有合适的上下文，数据和分析智能体基本没用——它们没法理清模糊问题、解读业务定义，也无法有效跨异构数据推理。

当然不是智能体的错。现代数据堆栈经历了十多年演变，从分散数据源到整合数据和清晰定义（这是好事），但整合从来都不完美，总会引入一堆混乱。市场演进大致分三步：

1) 现代数据堆栈崛起 我们之前聊过现代数据堆栈的变革，从数据摄取、转换、仓储到存储，整个架构都在朝集中化、快速可访问的方向发展。理想情况是，数据整理干净后，团队写写 SQL 就能从数据仓库提取数据，生成图表/仪表盘，让全公司都用上商业智能。

2) 智能体狂热 2024 到 2025 年，随着 LLM 能力提升，几乎每个组织都想在现有数据堆栈上构建和部署智能体。从组织角度看，更高效率、更少时间完成更多工作的诱惑，自然让大家涌向智能体工作流。公司尝试做“跟数据聊天”的聊天机器人、支持智能体等等。这股狂热自上而下又自下而上——开发者想用最新最闪的 LLM 能力，管理层则施压推动 AI 采用，以提升自动化、降低成本。

3) 撞墙 尽管起初乐观，但很快发现大多数尝试都失败了。组织试图部署智能体，却撞上了墙。MIT 著名的《2025 年商业 AI 现状》报告指出，AI 部署中“多数失败源于工作流脆弱、缺乏上下文学习，以及与日常运营脱节”。

智能体不好用的一个关键原因是缺乏合适的数据上下文。如今企业数据依然极其分散和混乱——正因如此，数据智能体连“上季度营收增长多少？”这种基础问题都答不好，因为数据架构里混杂着结构化和非结构化数据。

就像多年前完全自助分析的美好愿景落空一样，数据智能体的愿景似乎也未能实现。

那么，为什么智能体部署的初期阶段会这么挣扎？起初，很多人认为问题出在模型侧的数据推理和 SQL/Python 代码生成能力不足。普遍想法是，模型应该能接收自然语言查询作为初始输入，在现有数据系统上推理，并以传统商业智能（BI）方式生成对应 SQL 代码，拉取正确数据来回答问题。

如果模型失败或不准确，大家就把锅甩给模型 SQL 能力不行，指望模型性能会改进。

这说法不完全错。虽然模型在代码生成和数学推理等用例上能力大幅提升，但在数据侧仍落后（从 Spider 2.0 和 Bird Bench 等 SQL 基准测试可见）。模型能力确实有巨大飞跃，但我们很快意识到问题不止于文本转 SQL。

为了更具体，咱们再拆解一下营收增长这个例子：

1. 假设一个组织内部构建了数据智能体。它利用现代基础模型，连接所有正确数据源，还接了个漂亮 UI 来接收内部用户的数据问题。
2. 查询来了：“上季度营收增长多少？”一个看似简单的问题，通常瞥一眼 Looker 或 Tableau 仪表盘就能答——对高级智能体不该是挑战！
3. 挑战一：智能体怎么知道营收或季度的实际定义？ 营收其实是业务定义，并非硬编码在仓库或管道里。用户想看的是运行率营收还是 ARR？财季报告可能没标准化，不同公司的时间窗口完全不一样。该看哪个时间段？
4. 幸好数据平台负责人站出来说：“我们建了语义层（Semantic Layer）就是解决这问题的。营收定义就在里面。”而且，智能体应该能摄入所有语义层作为上下文。这是个有希望的潜在方案，但团队看了几个 YAML 文件，发现是去年离职的数据成员更新的，BI 工具早不用了，还不包含后来新上的两条产品线。智能体根本不知道营收现在到底怎么定义。
5. 为了突破这个障碍，团队成员硬编码了确切的营收和时间范围定义。数据智能体继续吭哧吭哧跑，但很快遇到挑战二：正确的数据源在哪儿？哪些是可信来源？ 原始数据分散在多个表和仓库里。财务团队用 fct_revenue 表，这可能对，但数据团队建了物化视图，比如 mv_revenue_monthly 和 mv_customer_mrr。

很明显，数据智能体需要访问一个包含最新业务定义和数据源的仓库，才能解决这些问题。

当前问题的症结在于，智能体没获得合适的业务上下文，连最基本的问题都答不了。这反映了在组织内构建自动化 AI 系统时存在的一个更大缺口——需要最新且维护良好的上下文，不仅要理解企业如何运作、数据系统如何构建，还要保留那些串联一切的隐性知识。

这就催生了上下文层的演进。今天讨论中冒出了很多名字——上下文操作系统（Context OS）、上下文引擎（Context Engine）、上下文数据层（Contextual Data Layer）、本体（Ontology）等等——但底层概念都一样：把企业所有混乱数据绑在一起，在上面加个上下文层，帮助智能体理解业务逻辑，然后打包成能供给智能体的上下文。

等等。我们描述的东西听起来不就跟语义层很像吗？确实有些相似之处，但说到底，如果智能体工作流要真正自主，它们需要的比现有语义层提供的要多一点。

传统 BI 语境下的语义层很适合特定指标定义（比如营收、流失率、ARPU）。但它们通常由数据团队用特定语法手动构建，通过 LookML 这类专用层连接，并直接挂钩到 Looker 这类 BI 工具。

现代数据上下文层本质上应该成为传统语义层功能的超集。当然，特定指标定义可以硬编码，但现代上下文层应该包含更多内容以确保智能体自主性——规范实体（Canonical Entities）、身份解析（Identity Resolution）、解读隐性知识的特定指令、适当的治理指引等等。

本文主要关注串联传统记录系统（Systems of Record）的数据上下文。另一个同样重要且重叠的机会是捕捉组织的决策和工作流逻辑，这样才能构建真正多用途的智能体，并使其基于组织的所有数据和决策上下文。

根据最近与客户的交流和对他们需求的理解，我们认为现代上下文层搭配智能体数据系统可能是这样的，一步步拆解来看：

1) 获取正确的数据

第一步是确保所有必要数据都能被访问到。这是基础要求。理想情况下，企业应该采用某种形式的现代数据栈，并通过湖仓一体架构实现一定程度的统一。即便如此，我们还需要确保智能体能访问到它需要的所有数据，这可能超出数据仓库和业务应用的范围，包括内部系统、GDrive、Slack 等工具中捕获的团队隐性知识。

2) 自动化构建上下文

当所有正确数据都可访问后，下一步就是开始构建上下文层。使用大语言模型的好处在于，很多初始的上下文收集工作可以自动化完成。重点应该放在高价值信号上下文上——例如，查看过去的查询历史可以高效地确定最常引用的表和最常见的连接方式，而像 dbt 或 LookML 这样的数据建模解决方案可以为业务指标提供清晰的定义。

3) 人工精炼

自动化构建可能能形成大部分上下文语料，但无法拼出完整图景。虽然很容易放任智能体去收集所有内部知识，但一些最重要的上下文是隐性的、有条件的、依赖于历史背景的，并且只作为团队内的隐性知识存在。

人工输入提供了实现真正智能体自动化的最后关键链接。例如：

“对于 CRM 数据，2025 年之后的所有 USCAN 新交易看 Affinity，但在此之前的所有全球线索看 Salesforce。”

这样，上下文层就能成为一个多维语料库，代码与自然语言并存，捕获智能体可能需要的任何上下文。就像开发者可以设置 .cursorrules 文件来引导智能体并控制输出行为一样，数据从业者也可以维护规则和指南。

4) 连接智能体

一旦上下文层构建完成，只需要将其暴露给智能体并确保能实时访问。这通常可以通过 API 或 MCP 实现。

5) 自我更新的上下文流

虽然初始系统已正确设置，但数据系统从来不是静态的，因此上下文层也不应该是。数据源和格式可能在上游发生变化，个人也可能根据不断变化的业务需求添加和修改自定义指令。如果数据智能体提供了错误数据并需要准确性修正，这些信息当然应该被整合回上下文层。这样，上下文层就成为一个活的、不断进化的语料库。

从整个实践中得出的一个结论是：构建一个合适的数据智能体绝非易事。它混合了与数据基础设施和工程相关的技术挑战，以及与收集隐性知识相关的人力操作挑战。

OpenAI 团队最近发表了一篇精彩文章，详细介绍了他们内部数据智能体的创建过程。这是一个非常详细和优雅实现的透明记录——但也指出了到达这一步所需的漫长旅程。同样，Palantir 长期以来一直为组织构建本体，从混乱的数据中提供清晰的上下文，并以此建立了庞大的业务。

自然，这为外部解决方案打开了窗口。现实情况是，并非每个企业都能（或应该）内部构建这个系统，我们已经开始看到各种解决方案进入市场。

虽然我们认为解决方案的成熟仍处于早期阶段，但以下是正在构建的解决方案的高层次市场图景：

具体分类如下：

数据引力平台

像 Databricks 和 Snowflake 这样的平台已经完成了数据摄取、转换和存储的过程，数据引力非常强大。它们已经在开发 AI 数据分析师产品，如 Databricks Genie 和 Snowflake Cortex Analyst，这些产品构建在数据仓库之上，并利用基础模型实现文本到 SQL 的转换，让用户能用自然语言询问数据问题。

虽然这些平台本身没有超级复杂的上下文层功能，但它们允许轻量级的语义建模，并且通过公司收购或内部开发，将上下文层引入平台是可行的路径。

现有的“AI 数据分析师公司”

已经涌现出一波利用 AI 让客户与数据对话的公司。许多公司通过市场实践意识到，有效数据智能体的关键实际上是构建相关的上下文层。因此，一些公司已经演变为将数据上下文构建作为其产品的关键部分。

新的、专注的上下文层公司

出现了一个新的公司类别，它们从零开始构建上下文层。它们必须经历我们上面提到的旅程：摄取数据、收集隐性知识等——并且必须为每个合作的客户单独完成这些工作。

我们正处于市场发展的一个有趣时间点，上下文缺失的问题已经变得明显，但我们仍处于构建解决方案的早期阶段。

未来令人兴奋——也许真正自助式分析（Self-Serve Analytics）的愿景能够完全实现，商业智能、数据分析和数据科学都能通过 AI 得到转变。

当然，许多开放问题仍然存在。这个上下文层将存在于哪里？它能存在于多个地方吗？它会成为一个独立的独立产品吗？

我们仍然对这里的创新机会感到兴奋。如果你正在这个领域构建，我们很乐意聊聊！请通过 jcui@a16z.com 或 X 上的 @jasonscui 联系我们。

本通讯仅供参考，不应作为法律、商业、投资或税务建议。此外，本内容并非投资建议，也不适用于任何 a16z 基金的投资者或潜在投资者。本通讯可能链接到其他网站或包含从第三方来源获得的信息——a16z 未独立核实，也不对此类信息的当前或持久准确性作任何陈述。如果本内容包含第三方广告，a16z 未审查此类广告，也不认可其中包含的任何广告内容或相关公司。任何提及、引用或描述的投资或投资组合公司不代表 a16z 管理的基金中的所有投资；访问 https://a16z.com/investment-list/ 查看完整投资列表。其他重要信息可在 a16z.com/disclosures 找到。您收到此通讯是因为您之前选择了订阅；如果您想退订未来的通讯，可以立即取消订阅。