a16z：Agent 表现不好，可能是缺乏正确的数据上下文

用户4242

3月12日修改

🔗 原文链接： https://mp.weixin.qq.com/s/WtQKUBPz...

金色传说大聪明 金色传说大聪明 赛博禅心2026年3月12日 18:48  广东 标题已修改​

市场终于明白了，数据和分析 Agent 要是没有正确的上下文，基本等于摆设 ​
​

本文是翻译稿，原文出自 a16z，地址：

https://www.a16z.news/p/your-data-agents-need-context

最近在数据和 AI Agent 的圈子里， 上下文层 和 上下文图谱 成了一个绕不开的话题。跟任何一个做数据和 AI 的组织聊天，不出五分钟就会聊到上下文这个话题​

common.docs_name - LarkCCM_Docs_Menu_Image

这很正常。过去一年，市场终于想明白一件事： 数据和分析 Agent，如果没有正确的上下文，基本上就是废物​

它们拆不开模糊的问题，读不懂业务定义，也没办法在分散的数据之间有效地推理​

这怪不了 Agent。现代数据栈经历了十多年的演进，从分散的数据源走向集中化的数据和清洗过的定义，这是好事。但集中化从来都做不到完美，过程中引入了大量的混乱。大致的演进脉络是这样的：​

1、现代数据栈的崛起 ​
我们之前跟 dbt 的 Tristan Handy 聊过这个话题，也在自己的参考架构文章里写过。过去十年，数据架构在摄取、转换、仓库和存储各个环节都经历了改造，目标是把数据集中起来，让人能快速方便地用上。理想的画面是：数据整理干净了，团队写写 SQL 就能从数据仓库里提数据，做图表，做仪表板，让整个组织都用上商业智能​

2、Agent 狂潮 ​
2024 年进入 2025 年，LLM 的能力越来越强，几乎每一个组织都想在现有的数据栈上搭 Agent。我们以前讨论过怎么定义 Agent。从组织的角度看，用更少的时间做更多的事，提升效率，这种天然的吸引力把大家都拉向了 Agent 化的工作流。各公司开始做「跟你的数据聊天」的聊天机器人，做客服 Agent。这股热潮自下而上和自上而下同时发生。开发者想用上最新最亮眼的 LLM 能力，管理层在施压要求 AI 落地，提高自动化，降低成本​

3、撞墙 ​
乐观没持续多久。很快就清楚了，大多数这类努力都失败了。组织们部署 Agent，撞了墙。MIT 发表了那份著名的「2025 年商业 AI 现状」报告，说 AI 部署「大多数失败是因为脆弱的工作流、缺乏上下文学习能力、以及与日常运营的脱节」​

Agent 表现不好，一个关键原因是 缺乏恰当的数据上下文 。今天的企业数据依然极度分散和混乱。数据 Agent 连「上个季度的收入增长是多少？」这样的问题都答不好，因为它面对的是横跨结构化和非结构化数据的各种架构​

多年前「完全自助式分析」的愿景没有实现。而在数据 Agent 的愿景上，似乎也走上了同一条路​

上下文问题：远不止 text-to-SQL

最初那一波 Agent 部署，到底为什么举步维艰？

起初很多人觉得，问题在模型那边，是数据推理能力和 SQL 代码生成能力不够。一般的想法是这样的：模型接收一个自然语言查询，对现有的数据系统做推理，按照传统 BI 的方式生成对应的 SQL 代码，拉取正确的数据，回答问题。如果模型失败了或者不准确，那就是模型 SQL 写得不好，等它慢慢变强就行了​

这话也不算全错。模型在代码生成和数学推理方面的能力确实大幅提升了，但在数据方面仍然落后，Spider 2.0 和 Bird Bench 这些 SQL 基准测试可以佐证。模型能力确实有了飞跃，但我们很快意识到，问题远远超出了 text-to-SQL 的范畴​

把收入增长的例子再拆细一点来看：

1.
假设一个数据 Agent 在组织内部建好了。用的是现代基础模型，连上了所有该连的数据源，配了个漂亮的界面，让内部用户可以来问数据问题​

2.
查询来了。「上个季度的收入增长是多少？」一个看起来很简单的问题。平时看一眼 Looker 或者 Tableau 仪表板就能答上来，对一个高级智能 Agent 来说应该不难吧 ​
挑战一：Agent 怎么知道这个组织里「收入」和「季度」到底是怎么定义的？ 收入其实是一个业务定义，并没有硬编码在数据仓库或管道里。用户要看的是 run rate 收入还是 ARR？财务季度的划分在不同组织里可能完全不一样，换一家公司，同一个「季度」对应的三个月可能完全不同。该看什么时间窗口？​

3.
好在数据平台负责人站出来说：「我们建了语义层，专门解决这个问题，收入定义就在里面。」Agent 应该能把所有语义层作为上下文吃进去。听起来有前途。但团队翻了几个 YAML 文件之后发现，这些文件是去年离职的一个数据团队成员更新的，BI 工具已经不再调用它们了，而且也没有包含后来新上线的两条产品线。Agent 根本不知道收入在今天到底怎么算​

4.
为了绕过这个障碍，有人手动把收入和时间窗口的定义硬编码进去了。数据 Agent 继续跑，但很快又撞上了 挑战二：正确的数据源在哪里？哪些才是真正的事实源？ 原始数据分散在多张表和多个数据仓库里。财务团队用的是 fct_revenue 表，可能是对的。但数据团队还建了物化视图， mv_revenue_monthly 和 mv_customer_mrr 都摆在那里​

很明显，数据 Agent 需要一个持续更新的知识库，里面装着业务定义和数据源信息，才能翻过这些坎儿​

上下文层登场

问题的要害在这里： Agent 没有被给予恰当的业务上下文 ，连最基本的问题都答不了。这反映的是一个更大的缺口。在组织内部构建自动化 AI 系统，需要有持续更新和维护的上下文。这个上下文要理解企业怎么运作，数据系统怎么组织，还要承载那些把一切串起来的部落知识​

由此催生了上下文层。今天的讨论里冒出来很多名字，Context OS、Context Engine、上下文数据层、本体论（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 来完成​

a16z：Agent 表现不好，可能是缺乏正确的数据上下文​

a16z：Agent 表现不好，可能是缺乏正确的数据上下文