云栖2026的主题定下来的时候我一点都不意外——“湖生万物助力 AI”这个口号说实话做数据的人听了会心一笑。过去几年湖仓一体、数据中台喊得震天响但真正让数据湖焕发第二春的恰恰是这轮大模型和 Agent 的爆发。围绕“面向 Agent 的全模态数据平台”这个方向我结合自己这段时间做 Agent 项目、折腾数据架构的实操经验从数据视角把这件事拆开聊聊。这不是一篇官方通稿式的前瞻而是一个从业者眼里的技术路线图、踩坑记录和落地参考。1. Agent 开发真正的瓶颈卡在数据这一层先说一个很现实的问题现在做 Agent框架一大堆从 LangChain、AutoGPT 到各种国产的 Agent 框架各家都在卷编排、卷工具调用、卷多智能体协作。但真把 Agent 丢到业务场景里去跑你会发现最掉链子的不是推理能力不是 Prompt 写得好不好而是 Agent 拿不到它需要的数据或者说拿到的数据形态根本不适合它消费。我见过太多团队把 Agent 做成了“一个聪明的空壳”。模型调度得再溜工具调得再顺一落地做真实的问答、决策、执行任务就必须面对企业里那堆乱糟糟的数据资产文档散落在各个网盘和 Wiki 里业务数据在 Oracle、MySQL、数仓里各占一摊图片、音视频、日志文件躺在对象存储里没人理。传统做法是给 Agent 接一个搜索接口、连一个数据库再塞一堆文档进去做 RAG。这套方案在小规模 Demo 上能跑一旦数据量上来、数据类型变杂问题立刻暴露。Agent 这东西最要命的需求是“多模态、实时、有记忆、可推理”。它要的不只是数据本身而是数据的语义化组织和动态供给。一个合格的面向 Agent 的数据平台至少得让 Agent 做到这几件事找到数据能从海量结构化和非结构化数据里用语义和关键词混合的方式快速定位。理解数据拿到的不只是原始记录而是带 Schema、带上下文、带关联关系的知识。消费数据数据要以模型容易消化的接口形态输出比如向量、知识图谱、事件流、API而不是甩给 Agent 一个 CSV 文件或数据库连接串。记住数据跨会话维护长期记忆让 Agent 在多次交互里保持业务上下文。你可以把 Agent 想象成一个新入职的员工。你光给他一个工位和一个公司内网入口他会寸步难行你只有给他一套完整的数据资产目录、知识库、实时业务看板他才能独立干活。过去我们建数据平台是为了给人看报表现在建数据平台是为了给“数字员工”当大脑和神经。这个转变才是“面向 Agent 的数据平台”和传统数据平台最本质的区别。所以我在跟团队讨论云栖这个主题的时候反复强调一句话Agent 的上限是模型决定的但下限是数据决定的。你别光顾着换更强的基座模型先把你那一屋子数据收拾明白。2. 全模态数据平台解决的四个真实痛点说清楚“为什么是数据”之后还得说清楚“为什么是全模态”。这个“全模态”不是造概念而是 Agent 时代硬逼出来的需求。我把这几年在企业里做数据治理和 AI 项目遇到的真实痛点归纳成了四类。2.1 痛点一数据的割裂与格式孤岛企业内部的数据从来不是整齐划一的。你有一堆 PDF 和 Word 文档有大量的表格有数据库里按行存的交易记录有图片、有音频、有监控视频还有源源不断的日志流。传统数据仓库洗干净的都是结构化数据数据湖里则堆了一堆未治理的非结构化文件。两边井水不犯河水报表有报表的管道AI 有 AI 的管道中间夹着一个搜索系统勉强度日。全模态数据平台做的事情简单说就是把这一切收拢进一个统一架构在物理存储上不强制统一但在逻辑层、语义层、接入层必须统一。文本要被抽取、表格要被解析、图片要被向量化、音视频要被切片索引。这样 Agent 才可能在一套体系内完成跨类型检索。否则你做一个“从产品说明书里找安装视频片段”的需求就得自己组装至少三套系统。2.2 痛点二机器消费数据的方式和人完全不同人看一张产品图知道这是苹果、这是手机、这是 Type-C 接口。人读一份合同能区分甲方乙方、标的金额、违约条款。但这些对机器来说都是无差别的字节流。过去我们靠人去标注、靠规则去抽取效率极低。Agent 时代出现了一个决定性工具——大模型本身变成了数据解析器。全模态数据平台的核心设计之一就是在大模型之上构建数据解析流水线把文本、图像、音视频自动抽取成语义化的知识单元。这个拼图非常关键。你可以把全模态数据平台理解成一个大食堂的“中央厨房”原材料进来之后先经过自动清洗、切配、预加工变成一道道可以快速出餐的半成品。Agent 就是那个点餐的人它不用关心原材料长什么样只要告诉平台“我要什么”平台就给他加工好的、可直接消费的“菜”。2.3 痛点三数据的时效性被严重低估Agent 和传统 BI 最大的不同是BI 看的是昨天的报表Agent 要处理的是这一刻的请求。比如客服 Agent 被问到“这个订单现在到哪了”如果数据平台还是 T1 离线同步那 Agent 给出的答案就是错的而且是大错特错。全模态数据平台必须支持从批量导入到流式接入的平滑升级让 Agent 能够吃到准实时甚至实时的事件流。我见过不少团队做客服 Agent上线前自信满满上线后翻车一查根因九成是数据时延。知识库里明明是昨天的版本用户在问今天的政策Agent 讲得一本正经全是错的。数据平台的实时性建设是整个 Agent 可靠性的地基之一。2.4 痛点四数据量大、检索精度差RAG 天花板明显现在做 RAG 的人应该都有一个共同的体会文档一多、切分粒度一大、语义近义词一多向量检索的召回效果就开始飘。Top-K 拿回来的片段经常是什么都不靠的废话或者方向对但细节全错。我自己的经验是只靠纯向量检索的 RAG天花板非常低。全模态数据平台的检索层必须要做到“混合检索 重排 知识图谱辅助”。这不是可选项是必需品。表格数据又是另一大难点。传统拆文档的方式处理表格经常拆得支离破碎字段名和值分离。面向 Agent 的数据平台核心功能之一就是表格语义还原把行列关系、表头、单元格合并、跨表关联全部保真让 Agent 能真的读懂一张利润表而不只是搜到“利润表”四个字。3. 从“湖”到“万物”平台内部到底怎么分工标题里“湖生万物”这四个字我理解是有层次的。“湖”是底层的存储底座“万物”是湖里长出来的能力、数据产品、Agent 应用。不能光有湖没有万物也不能绕开湖泊去空谈万物。具体到参考架构我认为一个面向 Agent 的全模态数据平台至少应该分这么五个层级。3.1 接入层全模态数据入口的统一纳管接入层解决的是“数据怎么进来”的问题。这里最常见的坑是只做批量同步不做流式或者文本一个管道、图片一个管道各管各的。统一的接入层应该提供多源连接器覆盖对象存储、消息队列、数据库增量、API 推送、手动上传等等。数据进来之后统一打上元数据标签落到一个暂存区再交给后面的解析层。我强调一下元数据标签这件事很多人不重视后面会付出十倍代价。数据一旦海量如果进来的时候没有把来源、时间、格式、归属部门、敏感级别这些属性打全等到要治理的时候就只能躺平了。数据资产管理不是从治理开始的是从接入那一刻开始的。3.2 存储层湖仓一体底座的再升级存储层是全模态数据平台的家底。这里我会坚持采用湖仓一体架构对象存储做底座上面覆盖 Iceberg、Hudi 或 Delta Lake 这类表格式。这样既保留了数据湖的海量、低成本、可扩展又引入了数据仓库的事务、Schema 约束和高效查询能力。这一层被验证得已经很扎实了不需要再创新关键是别犯低级错误。我的建议是文本和结构化数据进表图片音视频这类大文件分桶存放向量化之后的 Embedding 可以放在单独的向量存储组件里或者直接以列式格式存储在湖中再加载到内存加速计算。别一个库包打天下全模态没那么简单。3.3 解析与语义层湖生万物的关键一环这一层是全模态数据平台最核心、也最体现“AI 原生”特性的一个层级。传统数据湖的解析只解决“能否读”这个平台的解析层要解决“能否理解”。大模型在这里承担解铃人的角色对文本做实体抽取、摘要、关键信息提取对表格做结构还原和语义建模对图片做目标检测和 OCR对音频视频做转写、切片和事件标记。每一份原始数据经过解析后变成结构化的知识条目、向量表示、图谱关系统一落到语义索引中。解析层的设计有几个要点第一解析任务要基于事件驱动新数据一进来就自动触发而不是设定时任务定时扫一遍第二解析结果要可以迭代更新模型升级了老数据能自动重新解析再优化第三对用户提供人工校验的界面模型抽取得再不靠谱也要允许业务人员拉回来重新标这在金融、医疗这些领域是硬需求。3.4 知识组织层从数据碎片到可推理的知识网络有了语义化解析的结果还不够还得做组织和关联。这里就需要引入知识图谱和实体关系模型。比如同一份合同里的甲乙方要跟工商信息里的公司主体对齐同一件商品在文档里的表述、在数据库里的 SKU、在图片里的标签要映射到同一个实体 ID。没有这一层Agent 做跨文档推理就永远像瞎子摸象摸到一条腿就以为是全身。知识图谱在这里不是做成一个百科全书式的天网而是做成“业务域驱动的轻量图谱”。你只需要把你的业务对象定义清楚、关系建明白让 Agent 能通过一跳二跳路径发现隐式关联就足够了。这个环节很考验业务提炼能力也是最难外包的一个活。3.5 服务层Agent 取数接口的规范化输出最上层是面向 Agent 的统一数据服务层。Agent 不直接访问原始数据库而是访问数据平台暴露出来的语义 API。它可以是一个向量查询接口、一个知识问答接口、一个事件订阅接口、一个图谱查询接口。这样可以屏蔽下游的复杂性并且方便做权限控制和用量观测。我把这一层比喻成插座标准。过去每个数据库都有自己的方言和协议Agent 为了取数得写一堆适配器现在全模态数据平台把接口标准化Agent 只需对接一套 API就能拿到全模态的数据能力。这对大规模 Agent 开发效率的提升怎么强调都不过分。4. 技术选型和实现路径哪些组件值得投入精力参考架构画出来容易落到代码和选型上才是真正的修罗场。基于我做过的几个项目我把技术栈上值得重点投入的部分和可以搭便车的部分做了个梳理。4.1 底座框架优先选择 Iceberg 对象存储 Spark/Presto 的组合湖仓底座我首推 Iceberg 加对象存储计算引擎用 Spark 跑批、Presto/Trino 跑交互查询。Iceberg 在表结构演变、时间旅行、增量读取这些特性上比 Hudi 更成熟是开源社区当前热度最高的选择。对象存储选型上S3 兼容协议是避坑的关键这样既能用公有云的对象存储也能切换私有部署避免厂商锁定。这个组合的好处是生态大、人才好招、踩坑文档多。别在这个底层玩太多自研湖仓底座已经被各大云厂商和开源社区打磨得相当成熟你的核心竞争力不在这里。4.2 解析引擎大模型作为数据处理器解析引擎层是全模态数据平台的重头戏。这里我建议用“多模型混合架构”来做数据解析而不是只押一个模型。文本抽取用强项的通用语义模型OCR 用专业的视觉模型表格结构识别用专门的版面分析模型语音转写用 ASR 模型。各司其职通过一个统一调度框架把它们串起来。我踩过最大的坑是试图用一个万能的 VLM 干所有解析的活结果速度和精度都不理想。现实中更好的做法是每个环节上最强的工具然后靠编排层把结果拼装成统一的知识对象。大模型迭代太快平台得设计成可插拔的模型管道的形态不然每换一个模型就要重写一套数据流水线那是灾难。4.3 检索链路向量 关键词 重排组合拳检索层我强烈建议不管数据量多大都别只搭一套纯向量方案。向量检索适合语义匹配但你没法处理“订单号 SO-20260901-001”这种精确匹配这种场景还得靠倒排索引和数据库查询。正确的产品形态是做一个 Unified Search 网关多路召回然后接一个跨模态的重排模型把融合后的结果送进 LLM 上下文。排序模型的训练数据来自于线上反馈。这里我想强调要和用户行为闭环对齐——用户对 Agent 返回结果的点选、点赞、追问就是天然的标注数据。闭环迭代做得好的团队Agent 问答质量三个月内能有肉眼可见的提升。4.4 记忆与上下文短期记忆、长期记忆、业务记忆三级架构Agent 的记忆能力本质上也是数据问题。我把 Agent 记忆拆成三层会话级短期记忆用 Redis 或者内存缓存业务级长期记忆用向量库存用户的长期偏好和历史决策摘要组织级共享记忆用知识图谱和文档库承载。三层记忆合在一起Agent 才能在跨设备、跨会话的场景里维持稳定的“人设”。在做记忆层的时候注意一个平衡记忆越多上下文越长Token 成本和响应延迟都会飙升。必须给记忆加衰减策略、重要性打分和自动归档机制不能什么东西都往上下文里塞。5. 落地一个客服 Agent 数据平台我建议分五步走概念说得再多不如一个端到端的落地步骤来得实在。拿一个比较通用的智能客服 Agent 场景举例如果一个企业要从零开始建一个面向 Agent 的全模态数据平台我建议按这个顺序推进。第一步数据盘点与目标定义。别急着买组件、搭集群先花两周摸清数据家底把产品文档、工单历史、客服录音、订单库、商品库、售后政策这些来源列成一张表标清楚格式、量级、更新频率、敏感级别。这一步同时定义好 Agent 第一批要解决的高频问题一定是具体的问题清单而不是“提高客服效率”这种空目标。第二步最小闭环搭建。只选一个高频场景比如订单状态查询加售后政策问答搭一个最小的数据管道把订单库接入、文档做解析向量化、建立简单的检索接口接进 Agent 推理链路。这一步的目的不是完胜而是打通从数据到 Agent 的全部环节发现所有打嗝的地方。第三步流式补全与实时链路。把订单状态、物流信息这类对实时性敏感的数据接入消息队列实现准实时同步。对客服系统来说这是一道生死线客户不会接受一个比自己查物流还慢的客服机器人。第四步全模态拓展与知识图谱建设。把通话录音、工单截图、视频教程这些非结构化数据接入建立跨模态检索和内部实体关联。这个阶段会明显感受到全模态带来的威力——用户拍一张故障照片Agent 能结合说明书和工单历史给出精确排查步骤。第五步治理闭环与权限安全。这是上线前的最后一步也是最容易忽略的一步。给不同角色配置数据访问边界让 Agent 只回答权限范围内的内容然后通过日志审计追踪每一次数据访问。没有这一步的数据平台就是给安全事故留了一扇门。五步走下来整个过程更像是在积累“数据资产 Agent 能力”的复利。每一步都能独立产生价值又为下一步做了铺垫。6. 实际跑过之后值得写下来的几个坑从我自己的实盘经历看有些坑特别共性写下来给大家做个提醒。第一个坑是重模型轻数据。项目一启动所有人都盯在“用什么模型”“怎么调 Prompt”上数据管道随手糊了一个。结果 Demo 效果惊艳一换真实语料就开始胡说八道手忙脚乱补数据管道前后返工一个月。这个顺序一旦错了后面全是被动。第二个坑是过度设计。一开始就想要大而全的全部模态、全流程、自动化知识图谱花三个月搭底座最后连一个业务场景都没跑通。做数据平台切记从小切口开始用业务反馈推动平台演进。数据平台不是规划出来的是长出来的。第三个坑是向量检索的迷信。纯向量方案碰到精确数值、专有名词、ID 类查询几乎必挂。混合检索是唯一靠谱的路。要反复强调多路召回——关键词一路、向量一路、数据库精准查询一路然后重排融合。第四个坑是权限治理起步太晚。Agent 的权限问题要比人严重得多因为它的动作量放大效应极其明显。一个员工一天跑不了几次越权查询一个 Agent 能在一个小时里把上千万条敏感数据全打一遍。权限必须在搭建第一天就纳入架构切忌上线前补。第五个坑是评估指标的缺失。很多团队上线 Agent 之后说“效果还不错”但问具体哪里好、哪里差拿不出数。给 Agent 数据平台建立一个持续评估集包括检索召回率、幻觉率、端到端响应延迟、用户反馈满意度。没有度量就谈不上迭代一个不能持续变好的数据平台很快会被业务方弃用。说到这我最后想分享一个个人体会面向 Agent 的全模态数据平台最迷人的地方在于它把“数据工程师”和“AI 工程师”这两拨人拉回了同一张桌子。过去数据团队交付完报表就和 AI 团队再无交集现在数据平台必须深度嵌入 AI 应用的生命周期数据工程师开始讲 RecallK 和幻觉率算法工程师开始操心 Schema 和血缘。这种融合本身就是 Agent 时代最有意思的变化。湖还是那个湖但湖里长出来的万物已经是新的物种了。
