让数据平台为 Agent 而生：存储智能与下一代 Agentic Lakehouse

前言

在过去两年，我们清晰地看到产业中生成式 AI 应用经历了两波关键节奏。第一波是模型能力外溢，包括智能助手、harness coding、RAG 应用遍地开花。第二波是围绕 AI 的业务流程重构，小团队开始借助 Agent 重新设计产品、运营、合规和数据工作流。走到这一步，真正拖慢 AI 价值释放的，不再是模型不够聪明，而是企业的数据、权限、流程和评估机制还没来得及为 AI 的连续作业做好配套。

传统数据架构是为人类低频分析设计的，如数据仓库搞定结构化实时报表，数据湖兜住海量原始数据，搜索服务负责大规模日志分析，模型平台负责训练和推理。每个系统都能独立运转，可一旦进入 Agent 场景，要求就变了：Agent 需要在同一条任务链路里跨系统检索、对比、决策、写回。于是原本各自安好的系统之间开始摩擦，数据复制的链路越拉越长，索引和原始数据逐渐脱节，权限和血缘断断续续，任务执行过程也找不到完整的审计轨迹，GPU 和计算资源在数据等待中白白消耗。到了这个阶段企业才真正发现，AI 应用看起来是在和模型打交道，真正决定它能不能进生产的，却是背后的数据架构。

这也是本系列上一篇《计算智能》之后，我们要继续讨论存储智能的原因——如果说计算智能解决的是 Agent 跑得快不快，存储智能回答的则是：Agent 手上到底有没有一套可靠、可随时取用的数据上下文。一个正在被反复印证的判断是，未来几年企业会启动一轮大规模数据架构重构，让数据从结构化表扩展到文本、图片、音视频、向量并存，真正变得 Agent-Ready。

存储智能：新一代 Agent-Ready 多模态数据底座

这场重构的目标将会非常明确：让数据平台真正变得 Agent-Ready，能持续被 Agent 发现、理解、调用、验证、复盘。在过去，数据平台服务对象是人，客户普遍关心查询效率、存储成本、系统稳定性。而未来数据平台的关键，则在于企业的数据底座能否被 AI Agent 持续、安全、低成本地调用。这意味着存储不再只是“把数据放下”的基础设施，而要成为能够理解数据、组织数据、加速数据、治理数据，并为 Agent 提供长期上下文治理的智能底座。

搞清楚这一点，就很容易理解"存储智能"的本质定义。存储智能并不是给传统存储加个加速缓存，也不是换个更高效的存储格式，它要求存储层承担起以前不属于它的职能：理解元数据、感知上层任务、编排数据流向、统一管理多模态资产、承载 Agent 的工作上下文。直白地讲，存储层不再只是一个"放数据的地方"，它要变成 Agent 可以持续调用的企业记忆和行动底座。

如果我们回看数据平台这二十多年演进的话，实际上我们会发现，其关键推动力很朴素——谁在消费数据，底座就要长成什么样子。数据仓库时代，消费者是企业管理者和数据分析师，平台解决好结构化查询就行。在数据湖时代，数据工程师和算法团队加入进来，平台要同时吞吐海量原始数据。湖仓一体出现后，大家想在开放存储上兼顾仓库级分析和湖上计算。实时 Lakehouse 把流批一体和秒级新鲜度补了进来。到现在，Agent 成为了新的消费主体，它不是一个坐着等报表的人，也不只是跑一次训练就结束的模型，而是一套会持续规划、检索、计算、生成、复盘的自动化工作流。业界开始把这一代面向 Agent 的架构称为 Agentic Lakehouse，腾讯云将其落地为 AI 多模态 Lakehouse。

腾讯云存储智能布局：TCLake 多模态智能数据湖

基于上述理解， AI 多模态 Lakehouse 不是对上一代架构的修补和升级，它将在 Agent 的工作方式倒逼之下被重新定义。同时它也不要求企业推倒已有的对象存储、湖仓表、大数据引擎和 AI 工具，而是在这些已有投资之上建立一层统一控制面，让企业以渐进的方式走向 Agent-Ready。在腾讯云新一代 AI Native 大数据平台中，把能力分成了系统智能、计算智能、数据智能与存储智能四个方向，如果说系统智能让平台自治、计算智能让 Agent 跑得更快，数据智能让 Agent 学会分析，那么存储智能回答的关键问题是：Agent 手上到底有没有一套可靠的、可随时取用的数据上下文。TCLake 作为 AI 多模态 Lakehouse，正是这条链路里的数据底座。

腾讯云 TCLake 核心定位为新一代 AI 多模态智能数据湖底座，整体实现结构化与多模态数据的统一管理，对接 Data 与 AI 双引擎生态。从 TCLake 的架构图来看，它不是一个单一的存储系统，而是一套从底层到应用层贯通的底座组合。底层对接对象存储 COS 和第三方存储，其上湖仓一体层由 TCIceberg、TCLance、Volume 和 Model 构成。元数据层由 TCCatalog 统一管控，实现多模态数据的统一控制面和上下文管理。加速层由 TCQA 提供计算感知、智能分层和缓存加速，上层连接腾讯云大数据包括 EMR、DLC、TCHouse、ES、Xpark 等基础产品，以及各类原生或第三方 Agent 应用。

TCLake 多模态智能数据湖产品布局

1. TCCatalog：多模态数据的统一控制面

在TCLake中，TCCatalog 管的是企业全量数据资产的入口。TCCatalog 整体覆盖结构化表、半结构化数据、非结构化对象和 AI 模型资产，跨源、跨平台、跨引擎都能访问。在物理存储层，TCLake 可以纳管 COS、第三方对象存储、腾讯云数据库产品、文件、FTP、AI 大模型和第三方 GenAI 平台；在计算侧，TCLake 可以原生服务 Spark、EMR、TCHouse、DLC、TensorFlow、PyTorch、Xpark 和 Agent 应用。对 Agent 而言，统一 Catalog 的意义远不止找到数据在哪，整体还解决了这份数据的业务含义是什么、我应该用哪个口径、访问权限是否沿链路继承、调用上下文如何保留等一系列问题。

TCCatalog 提供统一 Catalog Service、REST API 和独立 Console，负责多模态元数据管理、统一权限管理、AI 资产支持和外部资产接入。对客户来说，原来每个系统各管一套元数据，Agent 做任务时要靠人工配置和脚本拼接，现在可以在一个入口下统一发现、授权、审计和调用，减少重复建目录、重复配权限和数据资产不可见的问题。

2. TCIceberg + TCLance：一张表装下音视图文

数据格式是底座最核心的工程决策。TCLake 的结构化侧由 TCIceberg 承担，整体兼容 Iceberg、Hudi、Delta 等主流湖仓生态，支持流读流写、部分列更新、算子下推、数据裁剪、智能分层和动态列扩展。多模态侧由 TCLance 承担，兼容 Lance 生态，专攻图片、视频、音频和 Embedding 数据，提供自适应索引、压缩、随机访问和部分列更新能力。

这套 TCIceberg + TCLance 统一格式真正解决的，是企业 AI 应用里最常见的“多系统拼接”问题。过去做一个知识问答、智能巡检或多模态分析任务，结构化指标在数仓里，原始图片和视频在对象存储里，全文索引在搜索系统里，向量索引在向量库里，权限和审计又在另一套系统里。工程团队不仅要搬数据，还要持续处理索引漂移、权限不一致和 Schema 变化。统一表格式把 id、user、image、video、audio、embedding、timestamp、JSON 属性、业务标签放到同一个逻辑 Schema 里，让 Agent 可以围绕一份数据同时完成 SQL 分析、全文检索、语义召回和多模态处理。最终显著减少数据复制、降低索引维护成本、避免上下文在系统切换中丢失。

一个直观的例子是城市智能巡检。过去要回答"腾讯大厦周边 10 公里范围内、夜晚雨天、且包含施工区的所有图片"这样一个问题，结构化的地理位置和时间戳在数仓里、原始图片在对象存储里、天气和光照标签在另一套系统里、图像向量又在向量库里，往往要串联三四个系统才能拼出结果。在 TCIceberg + TCLance 统一表格式下，frame_id、video_uri、天气、光照、地理坐标、图像向量和原始字节被放进同一张大宽表，一条标准 SQL 就能完成这次跨模态检索——这正是"一张表装下音视图文"对 Agent 的真实价值。

3. TCQA：让存储层学会理解计算任务

TCQA 是大数据原生加速引擎，覆盖数据处理、数据分析和 AI 训练三种典型负载，靠的是计算感知、冷热分层和缓存加速三重机制。计算感知这个思路特别值得展开：传统存储层是"等请求"的模式，任务来了再响应，而 TCQA 会主动理解上层任务的逻辑和资源状态，提前做 Filter 下推和元数据预解析来降低扫描量，通过智能 IO 优化传输路径，再用 AI Based 缓存预加载热点数据。

TCQA 具体的优化可分为三类：第一是上文重点介绍的计算感知，通过 Filter 下推和元数据预解析降低扫描量，节省带宽和计算资源；第二是智能 IO 和数据分层，根据计算资源分布、冷热程度和数据访问路径优化布局，缩短传输路径；第三是 AI Based 数据缓存，根据访问模式动态预加载热点数据，提升缓存命中率。基于 TPC-DS 的测试结果显示，在实际性能方面，Spark等上层引擎在 TCLake 开启 TCQA 后，TPC-DS 等基准 Benchmark 计算耗时降低 22%，缓存命中率提升 10 个百分点，另外在数据扫描量大、访问热点明显、多引擎复用频繁的场景中，TCQA 的收益会更加明显。

4. 实时入湖与智能管理：数据跑起来才能被 AI 消费

底座的价值最终要落在数据能不能以足够快的速度被消费。TCLake 的做法是把从产生到消费的整条链路连起来：CDC 或 Kafka 把业务数据实时推进 TCIceberg 流批一体表格式，后面跟着 AI Compact、分层、Z-Order 自适应等自动化管理，再经过 TCQA 的缓存命中和数据裁剪，最终被传统数据工程、RAG、训练和 Agent 统一取用。

显而易见，实时入湖与智能管理链路对客户的实际收益将很具体，对业务侧来说，Agent 能更快拿到最新知识、最新指标、最新上下文；对平台侧来说，重复同步链路减少，运维脚本和手工调优工作下降，数据资产从产生到被 AI 消费的过程更可控。

结语

AI Native 不是给传统大数据平台打几个补丁就能到达的终点，它是一整套数据基础设施重构的起点。从传统 Lakehouse 到 Agentic Lakehouse，变的不只是存储格式，还有数据底座的服务对象。计算智能让 Agent 跑得更快，数据智能让 Agent 学会协作分析，而存储智能最终管的是 Agent 手里有没有一套可靠、实时、可治理、可复盘的数据上下文。

对大多数企业而言，建一个完整的 Agent-Ready 底座不需要一步到位。更务实的路径可能是，先把 Catalog 和权限统一起来，接着把高价值的多模态资产纳入统一表格式，再逐步引入计算感知加速和 Agent 记忆治理，让数据从可查询慢慢过渡到可行动。而未来在 AI 企业架构原生化路径上走得稳的企业，往往不是在 AI 上砸钱最多的，而是最先完成数据底座升级的那一批。