今年的云栖2026主题是湖生万物助力AI其中被反复讨论的一个核心概念就是面向Agent的全模态数据平台。做Agent开发的朋友应该都深有体会模型能力越来越强可肚子里的货却常常不够用。文本、图片、视频、表格、日志、API返回值……各种模态的数据散落在后台、对象存储、关系库里Agent想用的时候就像在一片没有地图的沼泽里找水看着到处都是数据真正能捞上来用的却少得可怜。全模态数据平台要解决的就是这件事把所有模态的数据统一收集、统一治理、统一服务让Agent像拧开水龙头喝水一样按需获得自己想要的任何数据。这篇文章我打算从Agent开发者的视角拆一拆全模态数据平台的设计思路、底层架构、交互方式以及一套能跑通的最小落地闭环。最后把我自己在实操中踩过的坑和填坑经验一起交代清楚。1. Agent对数据平台的胃口从单模态到全模态的必然转变1.1 Agent的饭量早就不是一两个接口能喂饱的早些年我们做聊天机器人喂给模型的语料基本就是纯文本能加个知识库检索就算很高级了。但现在所谓的Agent已经不是那个只会聊天的调包机器人。它要能看图片、听语音、分析表格、查询数据库甚至要实时处理传感器流、操作浏览器和桌面应用。我接触过的Agent项目里最常见的用法就有用户传一张产品设计图Agent需要同时理解图像里的物体、标注文字再去检索对应的技术文档最后生成一份可执行的测试报告。一个数据分析Agent需要读取CSV、Parquet、JSONL等不同格式的数据还要能调用SQL引擎跑聚合查询再把结果渲染成图表。智能客服Agent要能处理用户发来的语音、截图还要结合历史订单库和工单系统给出端到端的解决方案。你会发现这些场景里Agent单靠一个向量数据库或者一个结构化查询接口根本转不起来。它需要的是一个全能食堂——既有文本、图片、音视频这类非结构化食材又有数据库、数据仓库、API返回值这类结构化食材而且食材之间必须建立关联让Agent能一锅烩出个像样的菜。1.2 传统数据平台在哪几个环节卡住了Agent正好最近和几个团队交流发现大家卡住的地方惊人地相似归纳起来无非这么几类。一类是通道断数据散落在不同的存储系统比如业务库在MySQL日志在Elasticsearch图片在对象存储算法特征在HDFS。Agent要拿数据得一个个接SDK光写连接器就得小半年。另一类是字典乱同一个用户ID订单表里叫user_id行为日志里叫uid图片元数据里叫userName。Agent自己很难理解这些字段的对应关系更别提跨模态做关联。还有一类是形态旧传统数据仓库只认结构化表存不了图片、视频和文档全文向量数据库能存Embedding但又不负责原始数据管理和权限控制搜索系统能检索文本和某些元数据但对图片内容、音频内容基本是没有感知的。Agent被夹在中间成了一个到处拼装管道的管道工而不是智能体。1.3 全模态数据平台到底改变了什么全模态数据平台的核心是让Agent有一个统一的数据入口。数据到达平台后不管原始形态是什么都会经历一套标准化的采集—清洗—索引—服务流程。平台对外暴露的不再是散落的API和连接串而是一个带语义的数据目录和一套统一的访问协议。Agent只要知道自己需要什么概念比如销售额客户投诉录音产品截图就能从数据目录里找到对应资产通过平台提供的检索、查询、订阅接口把数据拿回来。我习惯把它比作一个自来水厂源头是千家万户的溪流、水库、地下水水质和形态千差万别但经过沉淀、过滤、消毒之后送到你家里就是干净的、统一标准的自来水。Agent不需要关心水是从哪条河来的只需要打开龙头就能用。当然做到这一步背后的水厂管道铺设、水质监测、应急调度就是全模态数据平台真正要啃的硬骨头。2. 全模态数据平台的底层架构湖、仓、流一体的设计思路2.1 先说清楚湖和仓在这场变革中的新角色数据湖和数据仓库的概念大家都不陌生。传统做法是结构化数据进仓库非结构化数据扔到数据湖里躺着。但Agent时代这种割裂扛不住用了因为Agent常常要同时理解一张订单表和一张产品图片之间的关系。我的做法是湖仓一体——湖里存原始数据仓里存结构化处理后的数据再用一套统一的表格式比如Apache Iceberg、Delta Lake、Hudi把两者串起来。这样设计的好处非常直接原始数据永不丢失湖里的文件可以保存全量历史满足模型训练和调试追溯的需求。仓里的表可以按业务概念建模让Agent直接通过SQL或查询语法进行结构化访问。一份数据既能跑批处理也能通过增量读取提供给实时的Agent推理链路湖和仓本质上是同一份底层文件的不同视图。我推荐优先选Iceberg因为它的快照隔离和时间旅行特性特别适合多模态数据的完整性和回滚。比如Agent凌晨拉了一批图片元数据处理到一半发现数据有问题我们直接用Iceberg的快照回滚到前一版本不需要重新上传文件非常省事。2.2 多模态数据的统一存储层怎么搭全模态平台的第一步是解决原始文件的统一存储。我在项目里用的是对象存储MinIO自建或者云上的OSS/S3所有模态的文件统一放进去按业务域和日期分桶。但光存文件没用关键是要有一层让引擎能读懂的开关。这里的最佳实践是给所有文件打上统一的元数据标签比如asset_id资产ID、mode文本/图片/音频/视频/结构化、source_system来源系统、timestamp事件时间等。这些元数据一方面可以写入Iceberg的元数据表另一方面也可以同步到Elasticsearch或OpenSearch做全文检索。实际运行下来先设计好元数据规范再铺数据摄取管道能省掉后面至少三分之二的辩证麻烦。2.3 流批一体的数据摄取机制多模态数据形态各异到达的节奏也不一样。交易数据可能是实时流水图片和文档可能是一批批上传日志则可能是不间断的流。为了不让Agent拿到的是滞后三小时的旧闻平台需要具备流批一体的摄取能力。我们采用的架构是Apache Flink负责实时流处理处理完的结果既写入Iceberg做批式分析也把最新的变更推送到一个轻量级的实时索引比如Redis或Kafka同时用Apache Spark定期跑批处理做全量数据回填和校验。这套机制跑了一年多整体稳定Agent需要实时数据时直接查实时索引需要历史分析时查Iceberg表两边数据最终靠asset_id关联。2.4 统一语义层把多模态翻译成业务语言这个部分我觉得是整个架构的点睛之笔。原始数据是工业零件但Agent和业务方需要的是一台能直接开走的车。语义层的作用就是定义好业务概念与底层数据的映射关系。比如定义产品全景视图这个概念它背后关联了产品主数据表结构化、产品图片集非结构化、说明书PDF文档、用户反馈录音音频。Agent在数据目录里直接查找产品全景视图就能拿到一个封装好的数据包里面包含所有模态的数据以及它们之间的关联ID。这个语义层可以用一个轻量级图数据库或元数据管理工具比如Apache Atlas、DataHub来实现再配上自定义的语义SQL解析器就能做到让Agent用大白话问数。3. 让Agent用上多模态数据核心API与交互模式拆解3.1 Agent访问全模态数据的三种姿势从我的实践来看Agent和数据平台的交互无非三种姿势。第一种是投喂Agent在推理前通过数据平台把背景材料统一取出拼装成上下文。这种适合有明确需求的场景比如写行业分析报告前先把所有相关数据拉回来。第二种是检索Agent把当前问题转成向量去平台里检索最相关的多模态片段然后带着检索结果去生成回答。这种是RAG的标准玩法适合知识问答、文档总结这类开放任务。第三种是工具调用把数据平台封装成一个个工具ToolAgent根据用户的意图决定调用哪个工具、传什么参数、怎么处理返回结果。比如一个根据图片生成产品描述的工具Agent会先调用图片检索工具拿到图片再调用大模型生成描述最后调用图片存储工具把结果存回去。三种姿势可以混合使用。比如做智能导购Agent用户上传一张沙发照片Agent先投喂产品库里的用户画像数据再通过检索找出相似风格产品图片最后调用促销查询工具获取价格整个过程数据平台就像一个不停转动的底座。3.2 多模态数据的语义索引是怎么做的要让Agent能看懂图片、音频和视频单纯靠元数据标签是远远不够的。我们需要给非结构化内容做语义向量化。现在比较成熟的做法是使用多模态Embedding模型比如CLIP、ImageBind或者开源的Chinese-CLIP把图像、文本映射到同一个向量空间。举一个实际例子用户发给Agent一张北欧风格沙发的图片我们需要让Agent明白这张图片和文字简约布艺沙发浅色系是相关的。做法是先用图像Encoder把图片转成一个1024维的向量。同时将产品库里的每一条描述文本也用同一个文本Encoder转成向量。把这两个向量都存到向量数据库比如Milvus、Qdrant、或Elasticsearch的dense_vector字段。Agent收到图片后计算图片向量和文本向量的余弦相似度找到Top-K最相近的产品描述再结合产品ID去查结构化数据。这段逻辑写起来并不复杂但要注意Embedding模型的语言一致性和领域适配性。之前我们直接套用英文通用模型处理中文商品描述效果惨不忍睹后来换成了在中文电商数据上微调过的模型召回率直接提升了近40%。3.3 统一数据服务接口的Design Note要支撑上面三种交互模式平台对外至少要提供这几类接口数据目录检索接口支持模糊查询、标签过滤、语义搜索返回数据资产和对应的访问方式。内容读取接口输入asset_id返回文件的下载地址或二进制流支持限流和临时凭证。向量检索接口输入文本或图片向量返回Top-K结果及相似度分数。SQL查询接口面向结构化表返回JSON结果兼容Agent工具调用的输出格式。事件订阅接口当某个数据资产更新时平台主动推送变更消息给Agent。我设计接口时最看重的就是身份透传和数据权限这两个点。每一个Agent调用平台接口时都会携带自身的AppKey和用户上下文。平台在返回数据前会做一次细粒度的字段过滤比如普通用户查不到手机号运营人员查不到身份证号。这项能力不是锦上添花而是Agent能规模化落地的基本前提。4. 从零搭建一个面向Agent的全模态数据平台最小闭环实战4.1 选型清单和整体拓扑这里我给出一个可以直接上手的最小闭环组合全部用开源组件就能跑起来对象存储MinIO单机Docker即可表格式Apache Iceberg配合Spark或Flink使用元数据与数据目录DataHub开源版或者直接先用自定义MySQL表向量数据库Milvus Lite单机启动非常简单语义检索API自己用FastAPI写一个轻量服务Agent框架LangChain或ReAct模式自研整体链路是数据源本地文件/API → Fluentd或Nginx接收 → Spark作业写入Iceberg/MinIO → 元数据登记到数据目录 → 图片/文本切片后生成向量存入Milvus → Agent通过统一服务层FastAPI访问目录、内容、向量和SQL。4.2 第一步搭好原始数据层先启动MinIO和MinIO客户端创建raw-bucket和processed-bucket两个存储桶。原始数据一律进raw-bucket处理后的数据进processed-bucket。文件命名建议遵循统一规则{业务域}/{日期}/{asset_id}.{ext}。比如产品图片的路径就是product/2026-03-12/041c9f4e-... .jpg。为了保证文件可校验我会在摄取时顺便计算MD5值写入元数据表。后面Agent拿到文件地址时可以先校验一下MD5值再决定是否下载能有效避免文件在传输过程中被损坏。4.3 第二步做一份多模态数据的血缘和编目等文件进了MinIO就要登记元数据。我用一个简单的MySQL表data_assets来记录资产信息字段包括asset_id、mode、source_path、processed_path、description、tags、create_time、update_time。同时在asset_relationships表里维护不同资产之间的关系。比如一张产品图片asset_id img_001它关联的产品主数据asset_id prod_001它们之间的关系类型是depicts。这样一来Agent在查产品主数据时就可以通过血缘关系自动找到所有相关联的图片、视频和文档。这一步不求大而全只要能把关键资产和关联关系登记好后面Agent的多模态理解就已经有据可依了。4.3 第三步把多模态内容变成向量向量化是多模态平台和传统数据仓库最不一样的地方。我们需要一个异步任务定时扫描data_assets表对每一个新出现的图片生成向量并写入Milvus。我用的是Swiss-Army式的脚本里面最关键的一段逻辑代码Python伪码如下from chinese_clip import ChineseCLIPProcessor from milvus import MilvusClient model ChineseCLIPProcessor.from_pretrained(...) client MilvusClient(urihttp://localhost:19530) # 创建集合 client.create_collection( collection_namemultimodal_embedding, dimension1024, metric_typeCOSINE ) def embed_image(image_path, asset_id): vector model.encode_image(image_path) client.insert( collection_namemultimodal_embedding, data[{asset_id: asset_id, vector: vector}] ) def embed_text(text, asset_id): vector model.encode_text(text) client.insert( collection_namemultimodal_embedding, data[{asset_id: asset_id, vector: vector}] )有一个坑必须提醒向量化任务要设置增量检查点避免每次全量扫描重复编码浪费GPU。我们会在data_assets表里加一个vectorized字段处理完成后置为1。4.4 第四步封装Agent可调用的统一服务现在到了最关键的一步——把前面所有能力封装成一个Agent友好的服务。我这里用FastAPI快速实现一个聚合接口同时支持语义检索和结构化查询from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class AgentDataRequest(BaseModel): text: str None image_url: str None top_k: int 5 data_type: str all app.post(/api/agent/data/search) def search_data(request: AgentDataRequest): # 1. 调用向量检索拿到Top-K asset_id # 2. 从data_assets表读取这些资产的分组和路径 # 3. 根据data_type字段决定返回内容raw文件URL还是结构化结果 # 4. 校验Agent的权限范围过滤敏感字段 # 5. 封装统一返回结构 return { results: [...], query_id: some-uuid, cost_ms: 78 }这个接口的定义需要仔细推敲。我踩过一个坑最初返回的结果直接把MinIO的内网地址暴露给Agent导致外部环境访问失败。正确做法是返回一个带时效的预签名URL比如有效期5分钟让Agent在有效期内去下载内容。这样既保安全又避免因权限不足导致的403。4.5 第五步Agent端联调与端到端验证平台搭好后还需要验证Agent真的愿意用这个平台。最简单的验证方式是让Agent走一遍图文问答场景。比如用户问这张图里的沙发和哪几个产品风格最接近Agent应该先调用/api/agent/data/search接口传入图片URL拿到相似产品的asset_id再调用SQL查询接口取回产品名称和价格最后组织语言回答。我在联调时习惯用LangChain的ToolCallingAgent来做from langchain.agents import create_tool_calling_agent from langchain.agents.tools import Tool tools [ Tool(namesearch_multimodal, funcsearch_data, descriptionSearch across text and images), Tool(namequery_product_table, funcquery_product_sql, descriptionQuery product info) ] agent create_tool_calling_agent(llm, tools) result agent.invoke(这张图里的沙发和我店里的哪个产品最像)这一步跑通后整个最小闭环就算成型了。从数据进入平台到Agent能用自然语言调取多模态信息链路已经通了。5. 数据治理与性能瓶颈我在实践中踩过的坑5.1 小文件过多把查询拖成龟速多模态数据有一个非常典型的毛病——文件散而小。一张产品图片可能就几百KB一个文档片段可能就几KB但如果每天上百万个小文件直接落进Iceberg表执行查询时元数据目录会被撑爆。我们有一次审计报表查询明明只查一天的数据居然跑了20分钟最后定位发现是Iceberg表里的小文件分区数量超过了10万个。解决办法有两个一是数据摄取落盘时做文件合并比如用Spark的repartition按asset_id哈希重分区尽量把碎片文件合并成128MB左右的大文件二是定期用Iceberg RewriteDataFilesAction做Compaction把小文件合并成大文件。这就像把满抽屉的纽扣按大小颜色分装到盒子里翻找速度完全不一样。5.2 向量索引和原始数据的一致性向量数据库里存的是Embedding原始文件存在MinIO。如果原始文件被删了或者更新了向量库里那条记录就成了幽灵索引。Agent检索的时候明明搜索到了点开原始数据却发现404这种体验极差。我现在的做法是在删除原始文件之前先进队列发一个delete事件由后台任务同步删除对应的向量记录。如果是更新则先更新对象存储再重新生成向量并覆盖写入。同时做一次全量对账每天凌晨跑一个脚本把data_assets表和Milvus里的asset_id做差集发现不一致就自动补偿。这个对账脚本虽然技术含量不高但救了我很多次。5.3 并发尖峰时的服务降级策略Agent本身是多实例的当用户量上来之后多个Agent会同时调用数据平台的接口。最怕的不是QPS高而是某个奇怪的多模态请求特别重比如用户上传一个100MB的视频文件让Agent总结内容。这种请求如果直接同步处理会拖垮整个服务的Tomcat线程池。我的策略是分三档处理轻量请求文本、结构化查询同步处理限制单次响应时间不超过3秒。重量请求图片向量化、文件抽取异步任务化接口先返回任务IDAgent轮询获取结果。超大请求视频解析、批量数据导出直接拒绝只允许通过离线任务中心提交。这套策略再加上每接口的令牌桶限流实测可以把平台的可用性稳定在99.9%以上。5.4 安全合规的头疼事儿多模态数据往往比纯文本更容易触碰隐私红线。一张照片里可能包含人脸、车牌、甚至家里的环境信息一段语音可能包含声纹特征。平台如果不管不顾地全量提供给Agent一旦出事责任不小。我的经验是三层防护数据接入时做内容安全检测比如人脸检测、低俗内容识别违规图片直接隔离。数据访问时按Agent的用途动态脱敏。比如客服Agent可以听到用户的语音内容但不能看到面部画面那就返回音频URL时裁剪掉视频流的画面轨道。所有Agent调用数据平台的行为必须留痕包括请求参数、返回结果摘要、调用时间方便事后审计和追溯。这套东西做下来确实比普通BI平台复杂很多但它是面向Agent的数据平台能真正规模落地的必要条件。写在最后我在搭建这个全模态数据平台的过程中最大的体会是技术选型倒在其次真正难的是把数据供给这件事想得比Agent的能力还靠前。模型要什么数据、以什么形式给、给完怎么溯源这些问题想清楚了平台才不是一堆组件的堆砌。如果你现在正打算搞自己的Agent数据底座我的建议是先别追新框架从最小闭环起步——一个对象存储、一张Iceberg表、一个向量库、一个统一查询接口已经能支撑很多业务需求。等数据量和Agent场景真的跑起来了再逐步迭代治理、安全和性能优化。这座湖不是一夜之间挖成的得先让一股清泉流起来才能慢慢引来鱼虾和万物。