湖生万物：构建面向Agent的全模态数据平台

2026年的云栖大会技术专场我分享的主题是“湖生万物助力AI”。散场后好几个朋友围过来问同一个问题你们说的“面向Agent的全模态数据平台”跟现在成熟的大数据平台比到底改了什么这个问题问到了根子上。过去十年我们搭数据平台服务对象是BI报表、算法训练、实时风控这些“确定性的消费场景”但Agent不一样它在对话中动态决定要查什么、要调什么工具、要回忆哪段历史。数据平台不能再当“被动的仓库”得变成“主动喂养大脑的湖”——这就是“湖生万物”的含义。这篇文章把我在云栖现场讲的核心设计、选型思路和踩过的坑完整沉淀下来适合正在做Agent应用、RAG链路或统一数据底座的架构师和数据工程师参考。1. 先弄明白一件事Agent 时代的数据平台跟以前哪里不一样1.1 数据平台的消费对象变了很多团队做Agent时习惯沿用老一套数据架构结构化表进数仓文本丢ES图片丢对象存储各管各的。第一版demo能跑通一旦Agent开始处理真实业务问题就全冒出来了。本质变化在于消费对象。以前数据平台的“用户”是分析师和算法工程师他们清楚自己要什么写SQL、跑训练脚本、看报表。Agent不同它面对的是开放问题需要实时理解用户意图自行决定调用哪些数据。这意味着数据平台要把“多模态的数据资产”变成“Agent能理解、能检索、能调用的服务”而不是扔一堆表结构让Agent自己猜。另外Agent天然是“长尾数据”的消耗者。对话里可能夹着用户上传的合同PDF、产品照片、语音留言还要结合企业内部的订单表、工单记录。这类混合数据在传统数仓里基本没有位置但在Agent场景里是高频刚需。不把全模态接入做成平台能力每个Agent项目就得重复造轮子。1.2 Agent 对数据能力的四个硬性要求我总结Agent对数据底座的刚性需求可以浓缩成四点。第一是统一接入。文本、图片、音视频、结构化表、实时流不能分开接。分开接的结果就是每个Agent要维护五六个client数据口径还互相打架。第二是语义检索。Agent不会先写SQL再查数它需要自然语言直达知识。平台得把“关键词匹配”升级为“语义召回”背后是embedding、向量索引和重排模型。第三是记忆分层。Agent既需要记住当前对话的上下文又要能翻出三个月前的业务决策依据。这两类记忆的存储方式、更新策略、召回优先级完全不同不能笼统塞进一个Redis。第四是可控的服务化出口。数据要能暴露成工具函数、MCP协议接口或上下文片段并且每个出口都要有权限校验和审计日志。脱离了权限控制的数据服务Agent越强大风险越大。1.3 “湖生万物”到底想表达什么“湖生万物”不是宣传口号它对应了一个具体架构哲学数据湖是基底Agent生态是生长在湖上的应用。水数据是流动的、共享的万物各类Agent、模型、应用从湖里取水又把新的水汇入湖中。这个类比背后有一个很实际的考量——解耦。如果你让每个Agent都自带一套数据管道短期内看起来“独立”长期必然变成数据孤岛。上游表结构一改所有Agent静默出错。统一在湖上管理数据资产由平台负责格式、质量、血缘、权限Agent只关心“我检索到了什么、我如何用”。这种解耦让我在维护十几个Agent时只改平台一处而不是逐一排查下游。所以“湖生万物”落在技术上就是一套分层清晰的平台接入层入湖、存储层统一治理、服务层对Agent输出可检索可调用的能力。下面几节我逐个拆。2. 全模态数据平台的核心能力拆解2.1 多模态接入把文本、图像、音频、视频统一拉进来我见过最头疼的接入场景不是数据量大而是模态太杂。一个典型业务Agent会同时遇到订单库的MySQL表、业务团队丢在OSS里的产品图、客服通话录音、用户上传的PDF合同、实时推送的IoT传感器流。我的建议是不要为每种模态建独立管道而是统一抽象成“数据事件”。每一个事件都带统一的元数据头业务ID、事件时间、模态类型、来源标签、权限域。底层接入工具该用CDC就用CDC该用消息队列就用消息队列但进入平台的第一站都落到同一个事件总线再分发到对应的存储引擎。注意统一接入的本质是统一“元数据规范”不是统一“存储格式”。文件进对象存储、结构化表进湖仓表、向量进索引库这样各取所长但上层看到的是同一个Catalog。具体到这次项目我们用了三种接入通道Flink CDC同步业务库Filebeat加自定义解析器处理日志和文件OSS事件通知触发音视频转写管道。三条通道到平台后都注册进统一的元数据服务Agent问“最近一周的客服录音里提到‘退款’的有多少”系统能在十秒内完成语音转写、语义检索、聚合统计因为所有模态已经打通了。2.2 统一存储与湖格式为什么我建议用数据湖方案全模态数据平台里我最坚持的一点是结构化数据、半结构化数据、非结构化数据的“底座”必须统一放在数据湖上而不是继续分兵把守。原因有几个。一是成本。图像、音视频文件的体量通常是文本的百倍以上冷热分层在对象存储里做最划算。二是格式统一。采用开放湖格式比如Delta Lake或Iceberg后Spark、Flink、Presto、向量数据库可以同时读同一份数据不用来回导三次。三是时间旅行。Agent在复盘“上个月模型为什么错了”时需要看到当时的数据快照湖格式的ACID特性直接满足。当然湖格式不等于万能。我踩过的坑是把高频更新的业务热数据也塞进湖表结果小文件暴增查询性能崩了。正确做法是热数据留在OLTP库里通过CDC入湖做分析副本湖上主打“全量、历史、多模态汇聚”。一句话湖是“数据全集”库是“热数据快车道”两者配合而不是替代。2.3 语义检索与向量索引让 Agent 找得到数据Agent要“找得到”数据传统的关键词倒排索引远远不够。用户说“帮我找找上次合作方提到验收标准的那段”对方可能根本没提“验收标准”四个字说的是“交付满足条件后才能打款”。这种语义匹配必须上向量检索。但在平台里做向量检索跟单机脚本不一样要解决三个问题embedding模型选型、索引分片策略、混合检索融合。Embedding模型我们对比过通用中文向量模型和领域微调模型结论是通用模型冷启动好领域模型在专业术语上召回率能高十多个点。如果团队有标注数据强烈建议在通用底座上做领域微调。索引方面千万级向量用HNSW亿级以上就得考虑PQ量化加分布式分片。我们内部把这套写在选型账本里建议新项目起步别过度设计先用单机HNSW跑通再按召回延迟指标决定是否升级。混合检索的融合策略值得展开向量召回和关键词召回各出一份结果用RRF或加权分数融合。只靠向量遇到专有名词型号、订单号容易翻车只靠关键词又理解不了同义表达。两边必须一起上。2.4 记忆分层从短期上下文到长期知识库Agent记忆是我这次分享里提问最密集的部分。很多团队直接把所有对话记录塞进向量库美其名曰“长期记忆”结果上下文一长检索全是噪音模型还时不时自相矛盾。正确做法是把记忆拆成三层。工作记忆对应当前会话的上下文用高吞吐的KV存储比如RedisTTL设短会话结束就释放。情景记忆是“过去发生过的具体事”比如某次客户沟通的关键结论用向量库存语义按业务维度打标签。语义记忆则是最稳定的“人设和规则”比如公司产品话术、审批流程这类记忆更新频率低适合放在配置中心或知识库里由人工审核后发布。三层记忆的召回顺序也有讲究。Agent收到问题时先查工作记忆再查语义记忆稳定规则最后才查情景记忆历史往事。顺序反了模型会拿陈年旧事干扰当前决策。我们的做法是在检索接口里显式传mem_type参数从平台层强制分流。3. 实操记录搭一个面向 Agent 的全模态数据平台3.1 整体架构与选型考量这一节直接上我们最终跑通的架构四层结构每层只干一件事。接入层用Flink CDC加事件总线负责把业务库增量、文件事件、消息流统一接进来标准化成数据事件。存储层以OSS加开放湖格式为底座上层挂一个OLTP库存热数据、一个向量库存语义索引。计算层负责转写、抽取、embedding生成和聚合分析主力是Spark批任务加Flink实时任务。服务层是对Agent暴露的出口包括统一检索API、工具调用API和记忆读写API。选型上没有追求“全家桶”而是每个环节选了验证成本最低的组件。比如元数据服务直接基于现有DataWorks的数据地图扩展没有另起炉灶。小团队最忌“为架构而架构”先把链路跑通再逐步替换组件这是我反复强调的落地原则。3.2 数据接入与入湖的详细步骤以客服录音场景为例完整走一遍接入流程。第一步OSS上新增音频文件时触发事件通知函数计算拉起一个转写任务调用语音识别服务生成带时间戳的文本。第二步把转写结果连同原始音频路径、业务订单ID、客服ID、通话时间打包成一个JSON事件发到消息队列。第三步Flink消费这个事件做两件事文本切块后调embedding接口生成向量再把原始JSON写入湖表。第四步Spark定期从湖表读取增量数据做质量校验比如空转写率、时长异常并更新数据地图的血缘信息。这四步里最容易出错的是第二步的事件结构设计。我们吃过亏一开始事件里只放文本没放音频段落索引导致后续Agent想“回听原声”时找不到锚点。后来统一改成段落级别的事件每段文本都带上start_time、end_time和音频URI检索结果才能直接定位到原始片段。这件事给我们的教训是接入时多存一个关联ID比事后补数便宜一百倍。3.3 检索服务的参数设计与接口实现检索服务是Agent访问数据的咽喉参数设计直接影响体验。我给出我们线上验证过的一组参数供参考。向量检索TopK设为50重排后取Top5给Agent。为什么不是直接Top5因为向量召回的第一轮会有不少语义接近但业务无关的结果多召回一些给重排模型质量更稳。Embedding维度根据模型定我们用的768维索引分片数按数据量每500万条一个分片来分。检索超时上限设为800毫秒超过就走降级策略只返回关键词命中结果。接口方面我们封装了一个统一的POST /v1/retrieve接口入参包括查询文本、模态过滤条件、业务域标签、记忆层级出参是统一的文档列表每条带score、业务ID、模态类型和原始URI。之所以统一出参格式是为了让Agent不用关心底层是向量库还是ES。代码用FastAPI写的模型加载放独立进程避免阻塞I/O。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Optional, List app FastAPI() class RetrieveRequest(BaseModel): query: str modal_type: Optional[str] None biz_tags: Optional[List[str]] None memory_level: str scenario class RetrieveResponse(BaseModel): items: List[dict] app.post(/v1/retrieve, response_modelRetrieveResponse) async def retrieve(req: RetrieveRequest): # 实际实现会在这里调用混合检索链路 # 1. 生成 query 向量 # 2. 向量库召回 TopK # 3. 关键词召回并融合 # 4. 重排取 TopN # 5. 组装统一出参 return RetrieveResponse(items[]) # 启动命令: uvicorn main:app --host 0.0.0.0 --port 8300 --workers 4注意检索参数不是拍脑袋定的必须基于压测数据迭代。我们压测时发现重排环节最耗时间一度占到总延迟的60%后来把重排模型从大模型换成小的交叉编码器延迟降了一半召回质量几乎不变。3.4 从数据平台到 Agent 的联通配置平台搭好之后最后一步是让Agent真正用上。我们的Agent基于开源框架做二次开发接入平台有三个动作。动作一把检索服务注册成Agent的工具函数。框架里声明一个“业务知识检索”工具描述写清楚“适用于查询历史工单、客服录音、产品文档”大模型会在需要时自动调用。动作二配置记忆读写插件。工作记忆直接对接会话缓存情景记忆走向量库语义记忆启动时预载入模型上下文。插件里最关键的配置是权限令牌Agent每次读写记忆都带上这个令牌平台侧校验数据域防止一个Agent越权读另一个Agent的私有记忆。动作三在Agent的system prompt里写清数据边界。比如“只能检索已授权业务域的数据涉及客户隐私信息时只返回脱敏结果”。这个提示工程技术容易被忽略但实测能减少大模型乱调工具的概率。三个动作完成后Agent就算“喝上湖水”了。我们用一组内部数据测试Agent回答业务问题的准确率从裸模型的62%提升到89%多模态调用覆盖率也稳定在85%以上。4. 常见问题与排查技巧实录4.1 多模态数据对不齐最常见的故障现象是Agent引用了一段客服录音文字但跳转到原始音频时播的是完全不相干的内容。原因是转写文本和音频段落索引的对应关系错位了。排查思路分三步。第一步检查事件里的时间戳是否经过时区统一。录音文件来自全国多个节点我们一度没统一成UTC导致段落偏移。第二步检查切块逻辑是否和转写器的断句一致。转写器按静音断句切块按固定字符数切两边节奏不同就会出现文本多一句少一句。第三步检查音频URI是否被重写过。对象存储做生命周期沉降的时候URI发生了变化但检索索引没更新。这个问题的根治办法是在入湖时做“对齐校验”每条文本段落必须携带音频段的md5或者字节范围校验不过就告警而不是静默入库。宁可让数据延迟几分钟也不能让脏数据进入检索链路。4.2 检索召回质量差另一个高频问题是Agent反馈“搜不到想要的”。我看过团队排查记录八成的根因不在向量模型而在数据切块。切块太大会把不相关的内容混进一个向量切块太小又会截断语义。我们最终按“语义边界”切块而不是纯按字符数。具体做法是先用段落分割识别出标题、段落和列表结构再在段落内部按500到800字切分相邻块保留50字重叠。这套规则跑下来向量检索的命中率明显提升。还有一类问题是质量差来自“过期内容”。湖表里存了三个月前的促销政策Agent还当成现行规则回答。解决办法是在检索服务里加“时效过滤”业务数据打上valid_from和valid_to标签检索时默认只召回当前有效版本。这个字段越早加越好我们前期没加后面回补数据费了很大劲。4.3 高并发下服务被打爆Agent上线后流量峰值跟我们预想差距很大。一次市场活动让对话量半小时内翻了二十倍最先扛不住的居然是检索服务因为每个向量查询都要做embedding计算和索引查询连接池瞬间耗尽。我们的处理方案有三板斧。第一板斧是入口加限流基于令牌桶算法按调用方限速超限直接返回降级提示保护核心链路。第二板斧是加缓存对高频Query做结果缓存实测缓存命中率达到35%有效分摊了重复计算。第三板斧是embedding推理服务单独部署用GPU实例跑避免和在线检索抢CPU。如果想在扩容前先救急最有效的临时手段是“热点Query缓存”把最近十分钟内Top100的高频问题结果直接放Redis。虽然语义检索的查询很难完全重复但业务热点高度集中时这个方案能快速扛住峰值。4.4 权限与数据安全怎么落地Agent越权访问数据是我们从设计第一天就放在最高优先级的事。全模态数据平台把文本、语音、图像都汇聚在一处一旦权限失守泄露面会比传统数仓大得多。我建议的落地方式是三层权限模型。第一层是数据域隔离每个业务线一个域跨域访问必须显式授权。第二层是模态级控制比如客服团队能访问文本和录音但只有质检组能看原始音频普通客服只能看转写摘要。第三层是脱敏策略在检索服务出口统一做敏感信息识别身份证号、银行卡号、手机号默认打码只有申请了“明文权限”的特定Agent才能拿到完整值。这三层做完还要补审计。我们所有检索和记忆读写都有全量日志定期跑异常访问检测比如某个Agent在半夜高频拉取客户全量数据这类行为会被自动标记并告警。安全这件事没有一劳永逸但平台把权限机制做成基础设施后每个Agent项目就不需要重复设计安全方案了。5. 最后分享一点个人体会从数据中台到全模态数据平台我最大的体会是“平台思维必须让位于生态思维”。以前我们建平台核心指标是“数据是否及时、是否准确”现在面向Agent核心指标变成了“数据是否容易被智能体发现、理解和调用”。这个转变听起来简单做起来处处是细节接入时多存的那个关联ID、检索时多做的那个时效过滤、记忆分层时多拆的那一层都是在为Agent的“聪明”铺路。如果你所在的团队正在启动Agent项目我建议不要一上来就追求大而全的数据底座。先选一个高频业务场景拉通一小簇多模态数据把接入、存储、检索、权限这条链路完整跑一遍哪怕每天只处理几千条数据。链路跑通后再逐步扩展模态和规模。平台不是一步建成的但Agent对数据的需求每时每刻都在增长早一点让数据“活”起来你的Agent就能早一点变得更可靠。