数据 Agent 答不对"上季度营收"，缺的不是模型，是上下文层
先做个思想实验。你在公司内部搭了一个数据 Agent：接了最新的基础模型，连上了所有该连的数据源，配了个漂亮的对话界面，专门回答内部同事的数据问题。
第一个问题进来了："上季度营收增长多少？"
这问题简单到什么程度？任何一个业务同事瞟一眼 Looker 或 Tableau 仪表盘就能答。对一个"先进、智能"的 Agent 来说，不该是个事——可它大概率答不好。
这不是我编的段子。a16z 的两位投资人 Jason Cui 和 Jennifer Li 在 2026 年 3 月那篇《Your Data Agents Need Context》里，用的就是这个例子。而他们要说的道理，比"模型还不够强"要扎心得多：过去一年市场终于意识到，数据与分析 Agent 若没有正确的上下文，基本等于废物——它没法拆解含糊的问题、没法解读业务定义、没法在一堆散乱的数据里正确推理。
我在语义层取数那篇里已经碰到了这道墙的一角。这篇顺着 a16z 的论证往深里钻：问题的根子，早就不在 text-to-SQL 了。
一、撞墙：不是模型不会写 SQL
2024 到 2025 年，随着 LLM 能力猛涨，几乎每家组织都想在自己现有的数据栈上搭 Agent。这股热潮自上而下、自下而上一起来：开发者想用最新最亮的模型能力，领导层则施压"用 AI 提效、降本"。大家一窝蜂去做"和数据聊天"的机器人、支持 Agent……
然后大面积失败。MIT 那份广为流传的《State of AI in Business 2025》给了一句冷冰冰的判词：多数 AI 部署"死于脆弱的工作流、缺乏上下文学习、与日常运营脱节"。
最初，大家把锅甩给模型：以为是模型的数据推理和 SQL/Python 代码生成能力不行，觉得"等模型变强就好了"。这话不全错——模型在 SQL 上确实仍落后于它在通用代码生成和数学推理上的表现（看 Spider 2.0、Bird Bench 这些 SQL 基准就知道）。但很快大家学到了一件更重要的事：问题的范围远超 text-to-SQL。
把"上季度营收增长"这个问题拆开，你会撞上两道坎，哪一道都不是模型变强能解决的。
二、两道最要命的坎：业务定义与真相源
坎一：Agent 怎么知道"营收"和"季度"到底怎么定义？
"营收"根本不是硬编码在数仓或管线里的字段，它是一个业务定义。用户要的是 run-rate 营收还是 ARR？财季在不同公司可能是完全不同的三个月；"上季度"的时间窗到底怎么取？——这些都不在数据里，在人的共识里。
数据平台负责人这时会站出来说："我们早建了语义层，专治这个，营收定义就captured在里面。" 听起来有救了——把语义层当上下文喂给 Agent 不就行了？可团队打开那几个 YAML 文件一看：上次更新是去年离职的那位同事改的，BI 工具早就不用它了，而且它压根没包含之后新上线的两条产品线。 Agent 拿到的，是一份过期的、没人维护的营收定义。它根本不知道今天的营收是怎么算的。
坎二：数据的真相源到底是哪张表？
好，有人手动把营收和时间窗的定义硬编码进去了。Agent 继续跑，又撞上第二道坎：原始数据散在多张表、多个数仓里，哪个才是 source of truth？ 财务团队用 fct_revenue，看着像对的；可数据团队又物化了 mv_revenue_monthly、mv_customer_mrr……到底信哪张？
结论很清楚：数据 Agent 需要一个"始终最新的业务定义 + 数据源"的仓库，才能跨越这两道坎。而这，正是"上下文层"要填的坑。
三、上下文层：把散乱数据 + 部落知识打包给 Agent
问题的实质是：Agent 没被喂进正确的业务上下文，所以连最基本的问题都答不了。 这背后是一个更大的缺口——企业里的自动化 AI 系统，需要一份持续维护、始终最新的上下文，它不仅要理解企业怎么运转、数据系统怎么组织，还要沉淀那些把一切串起来的"部落知识"（tribal knowledge）。
于是"上下文层"这个概念冒了出来。业界给它起了一堆名字——context OS、context engine、上下文数据层、本体（ontology）……但内核是同一个：把企业散乱的数据全都系在一起，在上面加一层上下文帮 Agent 理解业务逻辑，再打包成 Agent 能取用的形式。
这里要接一个我之前埋过的线索。我在 RAG 与上下文工程那篇里讲的是"怎么把上下文喂给模型";这篇讲的是上下文本身从哪来、怎么维护——是上游更根本的一环。
四、和语义层似曾相识？它必须是语义层的超集
聪明的读者会立刻反问：这不就是语义层吗？
有相似，但如果 Agent 工作流要走向真正自治，它需要的比今天的语义层多得多。
传统 BI 语境下的语义层，擅长的是具体指标定义（营收、流失、ARPU）。但它通常由数据团队手工构建，用的是很专门的语法（比如 LookML），而且直接绑死在某个 BI 工具（比如 Looker）上。它是为"人点仪表盘"设计的，不是为"Agent 自主推理"设计的。
一个现代的数据上下文层，本质上要成为语义层的超集：
| 维度 | 传统语义层 | 现代上下文层 |
|---|---|---|
| 覆盖内容 | 具体指标定义 | 指标定义 + 规范实体 + 身份解析 + 部落知识 + 治理指引 |
| 构建方式 | 数据团队手工、专用语法 | LLM 自动构建为主 + 人工精修 |
| 绑定对象 | 直接绑某个 BI 工具 | 通过 API / MCP 暴露给任意 Agent |
| 形态 | 静态定义文件 | 代码与自然语言共存的多维语料，持续演化 |
| 服务对象 | 人点仪表盘 | Agent 自主推理 |
一句话：语义层管"指标怎么算",上下文层还要管"实体是不是同一个、真相源在哪、有哪些只存在于老员工脑子里的规矩、什么能查什么不能查"。 后者才够撑起 Agent 的自治。
五、怎么建：可落地的五步构建法
a16z 基于和大量客户的对话，给出了一套"上下文层 + 智能数据系统"的构建路径。我把它整理成五步，并接上工程视角：
第一步·接入正确的数据。 这是入场券。理想情况是组织已经用某种现代数据栈、通过湖仓架构做了一定统一。但要注意：Agent 需要的数据往往超出数仓和业务系统本身——还包括散在 GDrive、Slack、内部 wiki 里的部落知识。
第二步·自动构建上下文。 数据齐了，就开始建上下文层。用 LLM 的好处是，大量初始的上下文采集可以自动化：翻查历史 query 记录能高信号地判断"哪些表最常被引用、哪些 join 最常见";dbt、LookML 这类数据建模方案能提供清晰的指标定义。重点是抓高信号上下文，别一上来贪多。
第三步·人工精修。 自动构建能拼出一大块，但拼不出全貌。最重要的上下文往往是隐性的、有条件的、依赖历史的，只以"部落知识"的形式存在于团队脑子里。举个例子——"CRM 数据这块，2025 年起的新 USCAN deal 看 Affinity，但那之前的全球 leads 看 Salesforce。" 这种链接，只能靠人补。补完之后，上下文层就成了一个代码与自然语言共存的多维语料，就像开发者用 .cursorrules 引导编码 Agent 一样，数据从业者也能在这里维护规则和指引。
第四步·经 MCP / API 接入 Agent。 上下文层建好，只需实时暴露给 Agent，通常走 API 或 MCP。这一步要和授权治理咬合——我在 MCP 直连数据库那篇里讲过，暴露给 Agent 的每一条通道都得回答"谁在查、能查什么"。
第五步·自更新闭环。 数据系统从不静止，上下文层也不该静止。上游数据源和格式会变，业务需求会变，个人会想加自定义指令。尤其——当 Agent 给出了错误数据、需要纠偏时，这次纠偏应当回灌进上下文层。 这样它才成为一个活的、持续演化的语料，而不是又一份放到过期的 YAML。
这五步里，第三步（人工精修）和第五步（自更新）是最容易被低估、也最决定成败的——它们是"技术挑战"之外的"人的运营挑战"。建一个像样的数据 Agent，从来不是纯技术活。
六、市场格局：谁在造上下文层
既然不是每家企业都能（也不该）自建，外部方案的窗口就打开了。a16z 画了张市场地图，我按三类拆给你看：
第一类·数据引力平台。 Databricks、Snowflake 这种已经把数据的接入、转换、存储走了一遍，数据引力极强。它们已经在做 AI 数据分析产品——Databricks Genie、Snowflake Cortex Analyst——建在数仓之上，用基础模型做 text-to-SQL。它们当下的上下文层功能还谈不上多精细，但只做轻量语义建模，通过收购或自研补上上下文层，路径是通的。（我在 Snowflake 语义治理那篇里已经看到这个方向在动。）
第二类·已有的"AI 数据分析公司"。 一批"和你的数据聊天"公司早已涌现，很多在市场里摸爬后顿悟：有效数据 Agent 的关键其实是那层上下文，于是把上下文构建纳入了核心产品。
第三类·专用上下文层创业公司。 一个全新品类：从零专门造上下文层。它们得为每一个客户都走一遍上面那套"接数据、收部落知识"的苦活。
还有两个绕不开的参照：OpenAI 公开过自建内部数据 Agent 的详细复盘，优雅但漫长，印证了"这条路不好走";Palantir 则用为组织构建本体（ontology）、从散乱数据里给出清晰上下文，做成了一门大生意——它其实是上下文层这件事最老资格的实践者。
七、ICE 观察
技术层面：这篇最该记住的一句话是——数据 Agent 的准确率天花板，不由模型决定，由上下文层决定。 text-to-SQL 只是最后一厘米，前面九十九厘米是"这家公司的业务到底怎么定义、真相源在哪、有哪些不成文的规矩"。这也解释了为什么我在语义层取数篇里强调"口径"——上下文层就是把口径、真相源、部落知识系统化、可维护化、可喂给 Agent 的那层基础设施。
落地层面：别把上下文层当成一个"买来即用"的产品，它更像一套持续运营的机制。给想上手的团队三条务实建议：① 先啃高信号——从 query 历史里挖最常用的表和 join、从 dbt/LookML 里抽已有指标定义，比一上来搞大而全的本体见效快；② 把人工精修制度化——指定 owner，把部落知识当一等资产维护，否则三个月后它就退化成那份没人管的 YAML；③ 建纠偏回灌闭环——每一次"Agent 答错→人工纠正"都要沉淀回上下文层，让它越用越准。上下文层的护城河不在建成那一刻，在持续更新的能力里。
本土视角：国内很多企业跳过了"现代数据栈"的完整演进，数据比 a16z 描述的更散、部落知识更依赖人。这既是坑也是机会：坑在于自动构建能抓到的高信号更少，人工精修的担子更重；机会在于，谁能把"上下文层"和已经在推的数据治理、自主取数治理、数据要素流通拼成一套东西卖，谁卖的就不只是"能聊天的数据机器人",而是"问得准、答得对、错了能追、越权查不到"的可信数据智能底座。这和我这段时间反复讲的主线一脉相承：Agent 时代真正稀缺的，是可验证的信任与可维护的上下文，不是又一个更大的模型。
结尾
十年前我们追过"全自助分析"的梦，最后大多落空——不是工具不够炫，是没人把业务的真相沉淀下来。今天数据 Agent 的故事，正在同一个地方差点重蹈覆辙：我们以为缺的是更强的模型，其实缺的是一份始终最新、把散乱数据和部落知识系在一起的上下文。
好消息是，这一次问题被看清了，工具也在长出来。
所以留个问题给你：如果现在有人问你的数据 Agent"上季度营收增长多少",它答出来的那个数——你敢直接拿去开董事会吗？ 如果不敢，那你缺的，多半不是模型，是上下文层。