a16z提醒：没有好的数据上下文，你的智能体等于废物

投入巨资，把公司的海量数据全交给AI打理，项目可能一败涂地。

麻省理工学院发布的2025年企业AI状态报告，数字触目惊心。

企业在生成式AI上砸了300至400亿美元。

95%的试点项目没有任何可衡量的投资回报。

为什么？ 硅谷顶尖风投机构a16z的一篇博客给出了答案。

企业数据智能体如果没有正确的上下文，基本等同于废物。

读完这篇文章，你会明白那些参数量惊人的聪明模型，为何连上个季度收入增长了多少这种基础问题都答不对。

文章还为你逐层拆解了真正有效的数据智能体架构。

耗资百亿的智能体为何集体撞墙

回顾过去10多年的数据架构演进，一切看起来按部就班。

整个行业经历了现代数据栈的强势崛起。

早些年企业的数据就像是一座座孤岛。

销售部门用一套系统，财务部门用另一套软件。

数据散落在不同的服务器和硬盘里。

技术人员花费大量的时间去清洗、搬运和对齐。

dbt（数据构建工具）等开源技术横空出世，加上各大云端数据仓库的普及，彻底改变了游戏规则。

数据的摄取、转换、入库和存储被集中到了一起。

杂乱的数据被梳理得井井有条，定义也得到了统一。

团队只需写几行SQL（结构化查询语言）代码，就能从数据仓库中提取所需信息。

仪表盘和各类图表瞬间被点亮。

BI（商业智能）在整个组织内实现了无缝运转。

全自主式数据分析的梦想在那时显得触手可及。

时间线推移到2024年和2025年。

大语言模型的能力呈现爆炸式增长。

几乎所有的组织都迫不及待地想在现有的数据栈上，部署专属的数据智能体。

狂热的情绪自下而上又自上而下地蔓延。

底层的开发者渴望使用最新鲜的模型能力。

高层的管理团队施加了极大的采用压力。

大家都指望通过AI提高自动化程度，大幅削减运营成本。

与数据聊天成为了当时最时髦的词汇。

企业纷纷动手打造客服智能体和内部数据问答机器人。

现实泼了一盆冷水。

麻省理工学院在2025年企业AI状态报告中揭开了一块巨大的伤疤。

高达95%的试点项目倒在了实验室到生产环境的半路上。

只有不到5%的项目成功推向了生产环境。

报告明确指出项目停滞不前的根本原因只有一个。

大多数AI系统不会学习。

它们可以生成答案，但无法记住业务环境，无法适应反馈，也无法随着业务的发展而进化。

员工们在写邮件或起草文档时信任这些工具，但在处理关键任务数据时却弃之不用。

这种巨大的鸿沟被称作生成式AI鸿沟。

工作流异常脆弱，与企业的日常实际运营严重脱节。

企业数据经过多年的整合，依然存在大量的历史遗留问题，分散且杂乱。

面对跨越不同架构、堆积如山的结构化和非结构化数据，数据智能体显得手足无措。

业务人员随口问一句去年第4季度的营收增速是多少。

智能体可能会立刻宕机，或者给出一个看似合理却完全错误的数据。

就像当年全自助式分析的愿景最终大打折扣一样，数据智能体的光环也开始褪色。

业界最初把失败的锅甩给了大语言模型。

普遍的观点认为问题出在模型的基础数据推理能力和代码生成能力上。

理想状态下模型接收用户的自然语言提问作为输入。

在现有的数据系统里进行一番逻辑推理。

像传统的商业智能分析师那样生成相应的代码。

把正确的数据拉取出来完美解答用户的问题。

遇上模型崩溃或者答案不准的情况，人们通常会归咎于模型不够精通代码。

大家选择耐心等待，期待模型性能在下一代版本中实现飞跃。

想法只对了一小半。

模型在代码生成和数学推理方面确实完成了一次又一次的跨越。

但在真实的业务数据面前，它们依然举步维艰。

业内的2大权威数据库评测基准给出了详实的数据支撑。

Spider 2.0是一个专门评估语言模型处理真实企业级文本到代码工作流的基准测试。

测试不仅包含基础的查询，还要求模型处理真实的云端数据库系统。

模型需要在庞大的云数据环境中游走。

阅读长达数千字的方言文档，处理包含多层嵌套的复杂表结构。

有时候为了得出一个结果，模型需要编写超过100行的连环代码。

不仅如此，在没有人类提示的情况下，模型需要自己在700多个列名中找到正确的关联。

哪怕是公认最顶尖的推理模型，面对上千个字段和复杂的企业级环境，测试成功率也低的可怜。

BIRD Bench（大规模数据库文本到代码评测基准）的测试结果同样发人深省。

人类数据库专家的准确率可以稳定在93%左右。

最先进的AI系统拼尽全力，依然存在十几个百分点的巨大鸿沟。

问题早已超出了把文本转成代码的简单范畴。

为了把问题说透，让我们把收入增长的例子掰开揉碎。

假设一家公司内部倾尽全力打造了一个数据智能体。

它接入了最前沿的基础模型，连通了所有重要的数据源，还配有一个极度友好的用户界面。

业务主管在对话框里输入了一句，上个季度收入增长了多少。

一个简单到不能再简单的问题。

业务主管平时在看盘软件上瞥一眼就能知道答案。

高阶的智能体却在后台疯狂打转。

头号挑战立刻出现。

智能体根本不知道收入和季度在当前业务语境下的精确定义。

收入是一个纯粹的业务概念，它并没有硬编码在数据仓库底层的代码或数据流水线里。

提问的人到底想看当前的运行率收入，还是年度经常性收入。

财务季度的划分在每家公司也是千奇百怪。

不同的企业有完全不同的3个月时间窗口。

到底该按自然季度算，还是按公司的特殊财年算。

数据平台负责人可能会站出来救场。

声明团队早就建好了语义层来专门解决指标定义问题。

智能体理应把这些语义层全部吸收进来当作参考。

听起来是个无懈可击的解决方案。

技术人员翻开几个底层的配置文件，心瞬间凉了半截。

文件上的最后修改日期停留在去年，出自一位早已离职的数据工程师之手。

现在的商业智能工具早就不认这些旧规则了。

文件里甚至完全没有包含公司下半年刚刚推出的2个核心产品线。

智能体面对的是一份过期的地图，根本无从得知当下收入的真实定义。

有工程师干脆走捷径，把最新的收入和时间段定义直接硬编码进智能体的系统里。

智能体跌跌撞撞地继续运转，紧接着掉进了2号坑。

正确的数据源到底藏在几千张表的哪一个角落。

哪些表才是真正不含水分的单一事实来源。

原始数据被切碎，散落在多个不同的表和数据仓库里。

财务团队日常使用的是一张名为事实收入的底层表。

数据团队为了查询速度，又在外面包了一层，创建了诸如月度收入视图和客户月度经常性收入视图等物化表。

智能体就像一个站在庞大图书馆里迷路的新手，完全不知道该翻开哪一本书。

缺失了最新业务定义和可靠数据源指引，数据智能体寸步难行。

破局的底牌是上下文层

症结的十字路口已经清晰可见。

智能体被推上了战场，却没有配发最重要的业务上下文。

恰恰是组织内部构建自动化系统时普遍存在的鸿沟。

企业迫切需要一种动态更新、有人专职维护的上下文结构。

它不仅要像老员工一样理解企业的真实运作方式和数据系统的底层逻辑。

还要像一个知识库，完好保存团队内部口口相传的部落知识，把孤立的信息节点全部串联起来。

上下文层（Context Layer）的概念应运而生。

市场上的称呼五花八门。

有人叫它上下文操作系统，有人叫它上下文引擎、情境数据层，还有人套用学术词汇叫本体论。

抛开包装看本质，核心理念别无二致。

把企业内部杂乱无章的脏数据聚拢，在上面铺设一层厚厚的上下文。

充当智能体的翻译官，帮助它们理解复杂的业务逻辑。

再把这些经过提炼的知识打包，源源不断地输送给智能体的大脑。

听起来和传统的语义层十分相似。

他们确实有重合的基因。

追求智能体工作流的完全自主性，仅仅依靠传统语义层的表现形式是远远不够的。

传统的语义层在商业智能时代立下过汗马功劳，专门用来处理收入、客户流失率、每用户平均收入等具体的死板指标定义。

它们通常由数据团队手工搭建，使用专门的语法工具，一头连着数据，另一头直接焊死在看板工具上。

现代的数据上下文层必须完成进化，成为传统语义层的超级增强版。

具体的指标定义可以继续保留硬编码的形式。

为了让智能体拥有独立思考和执行的能力，现代上下文层必须装载更多的武器。

规范的企业实体清单、跨系统的身份解析规则、专门用来剖析历史部落知识的特定指令、严丝合缝的数据治理指南。

OpenAI在2026年1月公开的一篇技术博客，提供了教科书般的成功案例。

他们没有使用外部的现成产品，而是在内部亲手打造了一个专属的数据智能体。

系统服务着全公司超过3500名员工，涵盖工程、产品、研究等多个核心部门。

每天要在庞大到令人窒息的600PB数据、70000个独立数据集中穿梭寻宝。

内部数据平台不仅仅是几张表那么简单，它是一个巨型的数据迷宫。

为了解决上一个版本发布后欧洲企业客户的满意度变化这种问题。

智能体必须精确知道，客户满意度对应的是反馈表里的一项平均分数，而不是留存表里的客户健康分。

智能体会通过6层结构进行思考。

核心维度是表的结构和关联频率，智能体确切知道数据间的物理联系。

专家留下的大量人工标注构成了业务意图的护城河，补全了代码无法表达的避坑指南。

代码引擎自动扫描现有的数据流水线，理清数据流转的真实逻辑。

组织机构的历史沉淀知识被转化为机器可读的规则。

强大的记忆回溯能力确保同样的错误绝不犯第2次。

极其严苛的运行时校验机制牢牢守住底线。

最令人惊艳的是，当智能体在后台发现两个表连接后返回了0条数据，它不会直接把错误抛给用户。

它会自己停下来，分析错误原因，调整连接条件，重新尝试。

所有这些复杂的纠错都在后台默默完成。

员工只需输入简单的自然语言，几分钟内就能拿到附带深度分析的洞察报告。

为了确保系统不崩坏，内部还建立了被称为黄金查询代码的自动化测试集。

每次更新，系统都会自动比对生成结果和预期结果，抓出任何潜在的衰退。

过去动辄数天的等待成为了历史。

成功案例印证了上下文层的巨大威力。

把传统的死板记录系统串联激活，同步捕获组织的决策习惯和工作流逻辑。

真正的多用途智能体必须深深扎根于组织的数据土壤和决策上下文之中，才能开花结果。

打造数据智能体的5步施工图

结合当下的前沿技术实践和市场需求，一个配有智能体数据系统的现代上下文层，需要一套严密的5步施工图。

步骤1是访问正确的数据。

一切的起点必须牢靠。

理想状态下，组织应该已经完成了现代数据栈的基础建设，通过湖仓一体架构实现了某种程度的数据大一统。

必须保证智能体能够畅通无阻地访问它所需的所有数据资源。

视野绝不能仅仅局限于冷冰冰的数据仓库和正在运行的业务应用。

沉淀在内部工单系统、共享云盘和企业沟通软件里的非结构化文档，往往藏着最致命的业务逻辑。

这些角落里的部落知识同样需要向智能体敞开大门。

步骤2是自动化上下文构建。

数据通道打通后，地基的浇筑正式开始。

利用大语言模型的文本处理优势，海量的初始上下文收集工作完全可以全自动推进。

算力必须用在刀刃上，重点挖掘高信号强度的上下文。

通过逆向分析过去多年的员工查询历史，能够以极高的精度确定哪些表是业务命脉，哪些表连接方式最受青睐。

现有的数据建模解决方案也能自动贡献出1大批清晰明确的业务指标定义。

步骤3是人类的精细化调整。

自动化构建能拼凑出上下文语料库的骨架，但拼不出完整的灵魂。

直接放任智能体像爬虫一样去无脑收集所有的内部知识，具有极大的诱惑力，也伴随着极高的失控风险。

企业运作中最核心的上下文，往往是隐式的、充满历史包袱的。

它们作为心照不宣的部落知识，只存在于老员工的大脑和特定的团队内部。

人类专家的介入提供了实现真正智能体自动化的点睛之笔。

业务主管必须亲自在系统里写下规则。

调取客户关系管理数据时，2025年以后的所有新地区交易必须去查阅Affinity系统，而在此之前的全球历史线索只能认准Salesforce系统。

上下文层随之蜕变成一个多维度的立体语料库。

死板的代码和鲜活的自然语言在这里交汇，精准捕捉智能体可能需要的任何微小背景信息。

就像程序员可以通过编写代码规则文件来牢牢牵住智能体的缰绳一样，数据从业者也可以随时维护和更新这些业务准则。

步骤4是智能体连接。

上下文层构建妥当，知识库装填完毕，需要立刻向智能体开放，并保证毫秒级的实时访问响应。

主流的实现方式通常依赖于标准化的API（应用程序编程接口）或者最新的MCP（模型上下文协议）。

数据与大脑的通道正式合拢。

步骤5是自我更新的上下文流。

初始系统的落成只是一场马拉松的起点。

真实的业务数据系统永远处于奔腾不息的变化之中。

上下文层必须拥有自我进化的生命力。

上游的数据源地址和字段格式随时可能改头换面。

随着业务线的扩张，员工会有源源不断的自定义新指令需要补充进系统。

遇上数据智能体跑偏、提供错误结论的情况，业务人员的每一次手工纠正，都必须被系统捕获。

这些纠正动作必须形成闭环，毫无遗漏地合并回上下文层中。

上下文层蜕变成了一个活生生的、在实战中不断自我进化的巨型语料库。

回过头来复盘整个历程，打造一个及格的数据智能体绝非敲敲键盘那么简单。

这是一场必须同时打赢2场硬仗的持久战。

既要攻克数据基础设施工程上的硬核技术壁垒。

又要理顺人类收集、归纳庞杂部落知识的运营难题。

Palantir等顶尖公司在为各大组织构建复杂本体论方面有着极其丰富的实战经验。

他们正是通过从海量杂乱数据中抽丝剥茧，提供异常清晰的上下文，建立起了令人生畏的商业帝国。

历史经验印证了前路漫长却价值连城。

市场新风向与未来的归宿

不是每家企业都有雄厚的财力和技术储备在内部从零开始造轮子。

外部商业解决方案的窗户随之完全敞开。

敏锐的创业者和巨头们已经闻风而动，各类产品开始在市场上跑马圈地。

目前的市场玩家可以清晰地划分为3大阵营。

第1阵营是手握重兵的数据引力平台。

像Databricks和Snowflake这样的巨型数据平台，已经陪伴企业走过了数据摄取、清洗转换和底层存储的漫长黑夜。

汇聚在他们平台上的数据引力拥有无可匹敌的优势。

他们正开足马力研发基于AI的数据分析师产品。

依托底层的庞大数据仓库，调用顶级基础模型的代码生成能力，让用户直接用自然语言向海量数据开火提问。

现阶段的各大平台可能还没有装载最顶级的复杂上下文层功能。

他们已经全面开放了轻量级的语义建模入口。

凭借着雄厚的资本，未来通过大肆收购或者内部团队强攻，顺理成章地将完整的上下文层拼图嵌入自家平台，只是时间问题。

第2阵营是不断迭代的现存AI数据分析师公司。

大模型浪潮初起时，涌现了一大批立志让客户与数据顺畅对话的创业公司。

他们在残酷的市场厮杀中交足了学费最先大彻大悟。

不解决业务上下文层，一切绚丽的对话界面都是空中楼阁。

部分头部公司火速调转船头完成自我进化，将数据上下文的深度构建直接定为核心卖点。

第3阵营是生机勃勃的全新专属上下文层公司。

这是一个完全被痛点催生出的全新物种。

他们不碰底层数据存储，也不做表层的对话界面，只专注于打磨最硬核的上下文层。

他们必须像苦行僧一样深入每一位客户的业务一线。

走完摄取杂乱数据、手工收集部落知识的重重考验。

行业的车轮滚滚向前，我们正处在市场发展的一个奇妙十字路口。

智能体缺乏上下文的命门已经彻底暴露在聚光灯下。

真正完美的解决方案还处在艰苦卓绝的施工阶段。

那个喊了无数年的全自主式数据分析愿景，或许终于在上下文层的加持下迎来了破晓。

这个决定生死的上下文层到底会安放在企业架构的哪一层，会以独立软件的形态大杀四方，还是化作无形的协议分散在各个角落。

时间很快会给出答案。

真正的智能不在于拥有多少数据，而在于深刻理解数据背后的业务灵魂。

参考资料：

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

https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/

https://spider2-v.github.io/

https://bird-bench.github.io/

https://openai.com/zh-Hans-CN/index/inside-our-in-house-data-agent/