最近我一直在反复想一个问题：

AI 到底会不会真正给数据领域带来一些不一样的变化。

作为数据从业者，我其实能理解眼下一些并不乐观的判断。比如有人会说，当前这波 AI，对做数据的人并没有太大帮助。对这种观点，我某种程度上是认同的。因为真实的数据工作，难点从来不只是查询和分析本身，而是指标口径、业务定义、历史上下文、权限边界，以及不同系统之间那些并不天然连通的关系。

也正因为如此，很多看起来很聪明的 AI 能力，一旦落进真实的数据场景，往往就会显得差一口气。

但另一边，我又始终在想，AI 会不会真的给数据这件事带来一点新的东西。不是把分析师简单替代掉，也不是把 SQL 自动化得更彻底，而是把过去一些没有被产品化、没有被系统化的东西，重新推到台前。

去年看到 OpenAI 那篇写内部数据 agent 的博客时，我印象很深。真正让我惊讶的，不是它能查数、写 SQL、生成报告，而是它已经开始把 context 分成好几层来处理。那让我第一次更明确地意识到，Data Agent 要解决的，可能从来不只是“连接数据”，而是“理解上下文”。

今天再看到 a16z 发布Your Data Agents Need Context，我觉得这两个点终于可以放在一起写了。因为它们共同指向的，不只是一个新功能方向，而是一个更值得数据从业者认真面对的问题：

如果 AI 真会给数据领域带来新的突破，那么这个突破，可能首先不发生在查询能力上，而发生在 context 上。

很多 Data Agent，问题不在“不会查”，而在“不懂你在问什么”

过去一年，行业里大量 Data Agent 的想象，基本都建立在一个很顺手的逻辑上：自然语言提问，模型写 SQL，系统返回结果，再顺便给一段分析结论。这个路径看上去很顺，也确实能解决一部分轻量问题，所以很多人会自然觉得，数据和 AI 的结合，大致就是“Chat with Data”的升级版。

但如果你真的长期做过数据，就会知道这件事并没有这么简单。

在真实企业里，最难的问题往往不是“怎么查”，而是“怎么理解”。同样一句“上个月新增用户是多少”，背后就可能藏着一连串默认前提：这里的新增到底按注册算、激活算，还是首个关键行为算；是全量口径还是某个业务线口径；是否剔除机器人流量；指标定义是不是刚刚改过；同一主题在 A 系统和 B 系统里是不是根本不是一回事。很多时候，真正让数据工作变慢、变难、变得反复沟通的，从来不是 SQL 本身，而是这些没有被显式写进系统、却真实决定答案对不对的上下文。

这也是为什么，很多 Data Agent 看上去已经“能用了”，但真正进入复杂场景后，还是很容易撞墙。它也许能生成一条语法正确的 SQL，也许能从表结构里猜出几个字段意思，也许能把图表画得比传统 BI 更快。但一旦问题变得稍微模糊一点，涉及多个系统一点，或者需要理解业务口径一点，它就开始失真。问题不在于模型不会算，而在于它并不知道自己到底身处一个怎样的数据世界。

a16z 点破了一个关键问题：Data Agent 缺的不是能力，而是 context

Data 和 analytics agents 在没有正确 context 的情况下，本质上是不好用的。它们很难拆解模糊问题，很难理解业务定义，也很难跨离散系统做有效推理。这个判断我觉得非常准确。因为它说中的，不是模型能力的天花板，而是企业数据环境本身的复杂性。企业数据并不是一块平整干净、随取随用的地板，而更像是一座长期演化出来的旧城：系统很多，口径很多，历史包袱很多，局部经过整理，但整体依然充满断层和折衷。

而 OpenAI 那篇文章更有意思的地方，在于它没有停留在“context 很重要”这种正确废话上，而是进一步展示了 context 应该怎么被工程化。它提到自己的内部 data agent 不是单纯连数据库，而是围绕多层 context 来构建：既有表级知识、人工注释、代码和逻辑补充出来的语义，也有机构知识、记忆系统和当前任务运行时信息。换句话说，真正让 agent 更像一个“懂环境的分析同事”的，不是模型单点变聪明，而是系统开始持续给它提供多层背景

我觉得这件事很关键，因为它实际上改写了 Data Agent 的产品重心。

过去我们理解数据产品，核心任务大致是三件事：把数据接进来，把模型建起来，把结果展示出去。无论是数据仓库、BI、指标平台还是自助分析，底层逻辑基本都在这个框架内。大家追求的是集中化、标准化、可视化，让更多人更快地获得数据答案。

但到了 Agent 时代，问题开始变化了。

因为 Agent 不只是“读一个已经准备好的答案”，它开始试图参与到问题理解、路径选择、工具调用、结果解释这些原本需要人参与的环节。也正因为这样，产品的关键能力就不再只是“把数据准备好”，而是“把上下文提供好”。如果没有足够的 context，Agent 拿到的只是字段、表名和少量文档，它当然可以查一点东西，但很难做出真正可靠的判断。只有当指标定义、业务术语、组织规则、权限边界、历史反馈、常见问法、表之间的隐性关系都逐步变成系统可以调用的上下文时，Data Agent 才可能从一个会查数的接口，变成一个真正可用的分析协作者。

真正变化的，不是功能清单，而是数据产品的重心

这也是我现在越来越认同的一个判断：

Data Agent 的核心，不是更强的查询能力，而是更深的上下文系统。

这句话看上去只是换了一个说法，但背后对应的产品含义其实很不一样。

如果你把 Data Agent 理解成 NL2SQL 的升级版，那你的重点大概率会放在模型选择、Prompt 优化、SQL 正确率、图表生成这些能力上。它们当然重要，但它们更像“最后一公里”的能力。而如果你把 Data Agent 理解成一个建立在 context 之上的分析系统，那么真正重要的事情就会变成另一组：你的业务术语有没有被统一管理，指标口径有没有被持续沉淀，表和表之间的关系有没有被表达出来，历史问答和用户反馈有没有形成记忆，权限和组织边界有没有被正确注入，运行过程有没有留下可观察、可纠偏的轨迹。

前一种做法，更像是在给数据库加一个对话入口。

后一种做法，才更接近在为企业搭一层 agent 可用的语义运行时。

而我觉得，真正会带来差异的，恰恰是后者。

这也是为什么我不太认同“AI 对数据领域没多大用”这种一刀切的说法。更准确一点的说法也许是：AI 对数据领域最先改变的，不一定是分析动作本身，而是数据系统中那些过去长期被忽视、却决定理解质量的部分。比如 context、语义、记忆、权限、反馈闭环。这些东西在传统数据时代当然也重要，但它们往往被分散在文档、经验、口头沟通和少数关键人脑子里，没有被真正当作产品核心来建设。现在 Agent 逼着我们正视这一点：如果这些上下文不被系统化，Agent 就永远只能停留在表面能力上。

Data Agent 的未来，不是谁更会聊天，而是谁更懂这家公司

从这个角度看，OpenAI 那篇和 a16z 这篇真正共同指向的，不是一个短期热点，而是一个更值得认真对待的趋势：

上一代数据产品主要在做数据集中化，下一代 Data Agent 很可能在做上下文运行时化。

这可能才是数据和 AI 结合最有潜力的方向。不是让所有人都少写几条 SQL，也不是把 BI 换成聊天框，而是重新定义什么才是数据系统里最值钱的基础设施。未来真正的护城河，未必是谁的模型更强，甚至未必是谁的前台交互更酷，而是谁先把这家公司的数据定义、业务语义、组织规则和历史经验，变成了一套 Agent 能持续调用、持续学习、持续纠偏的 context system。

对数据从业者来说，这可能才是更值得投入的地方。

所以如果今天再回头看“Data Agent”这件事，我会觉得真正的问题已经不是：它会不会写 SQL。真正的问题是：它能不能理解这家公司自己的数据世界。

而这件事，才刚刚开始。