Agent不吃数仓，吃上下文

导语

2026云栖大会上传出的一条信息，值得所有做数据平台的人认真看一眼：阿里云正在用 Context Engine 把 Agent 数据旅程的六个阶段全部打通——从多模态数据入湖到上下文组装。这不是又一个新瓶装旧酒的概念，而是一个明确的信号：数据基础设施的服务对象变了。过去二十年，我们搭数仓、建湖仓，服务的是人和报表；现在，主要“用户”换成了 Agent，而 Agent 不看报表、不跑 SQL，它要的是随时可取用的、干净的、实时的上下文。

🔄 六个阶段，一条旅程

故事要从那次大会的展示说起。

阿里云把 Agent 消费数据的过程拆成了六个阶段：多模态数据入湖、语义抽象、上下文装配、实时计算、记忆管理、自然语言访问。这六个环节不是并列的功能清单，而是一条流水线——数据从业务系统里出来，先入湖，再被抽象出语义，然后按 Agent 当前的任务动态装配成上下文，配上实时计算和记忆管理，最后用自然语言交付。

熟悉数据平台的工程师一眼就能看出来，这六段旅程基本对应了过去十年数据栈的全部组件：入湖对应 MaxCompute 一类湖仓底座，语义抽象对应指标层和语义层，上下文装配对应向量检索和知识库，实时计算对应 Flink 一族，记忆管理是新东西，自然语言访问则把 BI 的查询入口彻底改写。

关键的变化在于装配方式。传统数据栈是“人拉管道”——分析师提需求，工程师跑调度，T+1 出报表。而在六阶段模型里，装配是被 Agent 的任务实时触发的。企业全域数据不再是静态资产，而是 Agent 可理解、可调用、可持续进化的实时上下文。

这句话的产业含义是：数据平台的交付物，从“查询结果”变成了“上下文”。这是一个根本性的产品定义变化。

🗺️ 谁在这条路上，各自的姿势

金句先行：大家都在做同一件事，只是入口不同。

把视野拉到全球，你会发现这并非阿里云一家的判断。Databricks 生态里，越来越多团队在 Lakehouse 之上构建 RAG 应用和 Agent，他们最初都以为难点在向量数据库或嵌入模型，做了几周之后才明白：真正的难点是让喂给这些系统的数据被良好治理、定义清晰、语义准确。Databricks 自己也按这个逻辑排兵布阵——Mosaic AI Vector Search 没有做成独立产品，而是直接长在 Unity Catalog 的治理体系里，配套了数据准备和质量监控工具；Snowflake 用 Cortex AI 把检索、语义、模型调用压进一个平台；AWS 的 Bedrock Knowledge Bases 可以直接从 S3 数据源自动完成切片、嵌入和索引。向量检索只是最后的“临门一脚”，前面九成的功夫在数据侧——这不是作者的观察，而是几家头部厂商用产品架构投出的票。

与之对照的是另一组事实：Pinecone、Weaviate 这些专业向量数据库厂商，检索引擎本身不落后，但它们没有湖仓底座、没有治理层、没有企业的存量数据引力，于是纷纷转向 serverless 和托管服务，事实上走向“被集成”的生态位。传统数仓则离 Agent 的消费方式最远——它的输出物是查询结果集，而 Agent 需要的是带语义、带时效、带记忆的上下文包。

不必画象限图也能得出三个判断，而且每个判断都有产品事实可依：

第一，云厂商走“全栈打通”路线，Context Engine 的价值不在某一单点，而在六阶段的端到端整合——判断依据是上述各家都不约而同地把向量检索收编进治理平台，而不是让它独立存在；第二，专业向量数据库在纯技术上并不落后，但缺少数据引力，商业价值被锁死在单点上，Pinecone 从数据库定位转向平台定位的转型本身就是佐证；第三，传统数仓最尴尬，它离 Agent 的消费方式最远，转型压力最大。

基于这些公开动作，我愿意给出一个可被检验的判断：未来两三年，数据平台的竞争焦点会从“存储计算引擎的性能”转移到“上下文供给的能力”。理由有三：一是计算引擎的性能竞争已趋同质化，T 族基准的边际差异越来越难转化成商业决策；二是 Gartner 在 2025 年 6 月的预测中明确指出，超过 40% 的 agentic AI 项目将在 2027 年底前被取消，主因是成本失控和价值不清——而价值不清的根源，多数指向数据供给质量；三是头部厂商的新品发布节奏，已经全部转向“数据到 Agent 的管道”而非“更快的数据处理”。谁先把语义层、记忆管理和实时装配做成一体化产品，谁就掌握了 Agent 时代的数据入口。如果两三年后主流平台还在用“跑分”作为核心卖点，这个判断就被证伪了。

⚠️ 脏数据：Agent 时代的头号杀手

金句先行：Garbage in，现在意味着带机器自信心的 garbage，规模化输出。

海外 Salesforce 生态的一线观察很有代表性。每个做 Agentforce 试点项目的管理员，几乎都撞上同一堵墙：AI 失败的原因是脏数据——不是偶尔失败，而是几乎每次都失败。

典型场景非常熟悉：多年 web-to-lead 表单和粗糙导入攒下的重复联系人和线索；看起来必填、实际一半记录为空的字段；“已成交”商机没有金额、没有成交日期、没有任何产品；"N/A"、“未知”、"-" 这类垃圾值混在真实枚举值里，被嵌入模型后成了“有语义的词”；自由文本字段里，同一个客户被写成八种格式；客户三年前换了公司，记录从未更新，Agent 照样引用。

这些在 BI 时代都是“可容忍的瑕疵”——报表上多一行重复数据，分析师肉眼跳过就行。但在 Agent 时代，每一个瑕疵都会被检索出来，包装进上下文，以模型特有的笃定语气输出给客户。这不是假设。2024 年 2 月，加拿大航空（Air Canada）因官网聊天机器人向乘客错误解释退款政策而被仲裁机构裁定赔偿——机器人引用的是过期且与官方政策不一致的内容，但输出时没有任何犹豫。同年 3 月，纽约市上线的 MyCity 商务聊天机器人被发现给出了多条错误甚至违法的经营建议，根源正是知识库内容本身有误。两次事件没有任何一次是“模型幻觉”，全是喂进去的数据或知识本身就是错的。

这个判断有更宏观的数据支撑：Gartner 早在 2021 年就估算，低劣的数据质量平均每年让每家企业损失 1290 万美元；Salesforce 自己的客户调研中也反复出现同一个结论——多数 IT 决策者认为生成式 AI 的输出质量取决于输入质量，而他们对自有数据质量的信心远低于对模型能力的信心。换句话说，瓶颈从来不在模型侧，而在数据侧，只是 Agent 把这个瓶颈从“报表难看”放大成了“业务事故”。

更隐蔽的问题在于：脏数据在 BI 时代是可见的（报表数字对不上，马上有人发现），在 Agent 时代却变成了静默失败——Agent 用自信的语气输出错误答案，用户无从分辨，错误会顺着对话流向下传递。数据质量的成本没有消失，只是从“人工核对”转移到了“信任损失”，而后者贵得多。

🧠 记忆管理：六阶段里唯一的新东西

六个阶段里，有五个都能在现有数据栈里找到对应物，唯独“记忆管理”是新的——这恰恰是最值得琢磨的地方。

Agent 的记忆至少分两层：任务内记忆（这次会话里用户说过什么、检索过什么），和跨任务记忆（这个客户的偏好、上次交互的结论、长期有效的约束）。前者用会话存储就能解决，后者本质上是一个持续更新的、带时效语义的知识资产——它既不是传统数仓里的一张表，也不是向量库里的一堆切片，而是一种介于两者之间的新形态。

开源社区已经先跑起来了：Mem0、Letta（原 MemGPT）这类项目专门做 Agent 长期记忆的抽取与召回，在开发者社区增长很快。这个现象说明需求真实存在，但也说明平台厂商还没给出标准化答案。谁能把“记忆”做成数据平台的一等公民——有 schema、有生命周期、有治理——谁就在六阶段模型里占了那块无人认领的地。

📋 给数据团队的行动清单

如果这条判断成立，做数据平台的人现在该做什么？四件事，按优先级排：

1. 先做数据质量审计，再谈 Agent 立项。 把脏数据清单列出来：重复率、字段空置率、垃圾值分布、数据新鲜度。Agent 项目的一半预算应该花在这里，这不是浪费，是前置排雷。

2. 补语义层。 让每个核心指标、每个业务实体有唯一、机器可读的定义。Agent 不需要你告诉它“GMV 怎么算”，但需要一份它能直接消费的口径说明。

3. 给数据配时效 SLA。 传统 T+1 在 Agent 场景下可能意味着给客户报三个月前的价格。哪些数据必须秒级新鲜、哪些可以小时级，需要按 Agent 的使用场景重新定义。

4. 把记忆当作数据资产来治理。 记忆会被 Agent 反复引用、影响决策，它需要和主数据同等的治理规格，包括过期策略和纠错机制。

🏁 结语

回头看，这篇文章的核心论点其实只有一句：数据基础设施的服务对象从人变成了 Agent，交付物从查询结果变成了上下文，而上下文的质量上限，就是企业数据质量的上限。

阿里云的 Context Engine、Databricks 的 Lakehouse AI、Snowflake 的 Cortex，形态各异，但都在回答同一个问题。六阶段模型的价值不在于它是一个标准答案——它一定会在实践中被改写——而在于它第一次把“Agent 怎么消费数据”当成一个端到端的工程问题来拆解。

二十年前的数仓浪潮里，赢家不是建了最好数据库的人，而是想明白“业务要用数据做什么”的人。这一次也不会例外。Agent 不吃数仓，吃上下文——但上下文好不好吃，还是由你的数据决定的。