面向Agent的全模态数据平台：架构设计与工程实践

1. 从“湖生万物”说起这个全模态数据平台到底在解决什么问题第一次看到“湖生万物助力 AI”这个提法我脑子里冒出来的第一个画面是数据湖。做过几年数据平台的人都知道数据湖这个概念喊了快十年从最早的 Hadoop 生态到后来的湖仓一体本质上一直在解决同一件事把散落在各处的结构化、半结构化、非结构化数据统一存起来让上层应用能方便地取用。但这次云栖抛出的“面向 Agent 的全模态数据平台”明显不是把老酒换个新瓶它要解决的是一个更棘手的问题——当 AI 从“被动问答”走向“主动执行任务”之后数据平台该怎么重新设计。传统的数据平台是给人用的。分析师写 SQL 查报表工程师调 API 取特征数据消费的终点是人。但 Agent 不一样Agent 是自主决策、多轮交互、会调用工具、会记忆上下文的执行体。它对数据的需求跟人完全不同它需要的是低延迟的实时检索、跨模态的语义对齐、可追溯的记忆存储、以及能支撑多步推理的上下文组装能力。你拿一套为 BI 报表设计的数据仓库去喂 Agent就像拿一本电话簿去训练一个侦探信息都在里面但组织方式完全不对路。这个平台的核心价值我理解下来可以拆成三层。最底层是“全模态”意思是文本、图像、音频、视频、结构化表格、代码、甚至 Agent 执行轨迹全部纳入统一存储和索引。中间层是“面向 Agent”意味着数据的组织方式、检索接口、权限模型都是围绕 Agent 的工作流来设计的而不是围绕人的查询习惯。最上层是“湖生万物”这个说法有点诗意但落到实处就是数据湖不再只是被动存储而是能主动生成、衍生、关联出新的数据资产比如从原始文档自动抽取知识图谱从执行日志自动生成经验记忆。适合谁来关注这个方向如果你是做 Agent 开发的工程师正在头疼怎么给 Agent 接一个靠谱的记忆后端那这套东西值得研究。如果你是数据平台的架构师正在规划下一代数据基础设施那“面向 Agent”这个视角会给你很多启发。如果你只是对 AI 应用感兴趣的产品经理理解这个平台的设计思路也能帮你想清楚自己的 Agent 产品到底缺哪块数据能力。我个人的判断是2026 年这个时间点提“面向 Agent 的全模态数据平台”时机踩得很准。Agent 框架已经过了概念验证阶段大家开始认真做工程化了而工程化最先撞上的墙就是数据。记忆怎么存、上下文怎么组装、多模态怎么统一检索、执行轨迹怎么复用这些问题不解决Agent 永远只能做 demo。2. 全模态数据平台的核心设计思路拆解2.1 为什么“全模态”不是简单地把文件都塞进对象存储很多人一听全模态第一反应是“不就是什么格式都支持上传吗”。这个理解太浅了。真正的全模态数据平台难点不在存储而在语义层面的统一表示和跨模态检索。我举个具体场景。一个 Agent 在帮用户做竞品分析它需要同时处理一份 PDF 行业报告、一段产品发布会的视频、一张竞品功能对比的截图、以及一堆结构化的销售数据表格。如果平台只是把这些文件都存进对象存储Agent 拿到的是四个孤立的 blob它得自己想办法解析、对齐、关联。但如果平台做了全模态语义层情况就完全不同PDF 里的文字、视频里的语音转写、截图里的 OCR 文本、表格里的数值全部被映射到同一个向量空间里Agent 用一句“竞品 A 在 2025 年 Q3 的定价策略变化”就能同时召回四个模态里的相关片段。这就是“全模态”的真正含义不是格式兼容而是语义互通。实现路径上通常需要三层处理。第一层是模态解析把各种格式拆成可处理的原子单元比如视频拆成关键帧加音轨PDF 拆成段落加表格加图片。第二层是统一表示用多模态嵌入模型把不同模态的内容映射到同一个向量空间这一步决定了跨模态检索的质量。第三层是关联索引建立模态之间的引用关系比如某张截图来自哪个视频的哪个时间点某个表格数据引用了哪份报告的哪一页。注意多模态嵌入模型的选择直接决定平台的上限。不同模型对图文对齐、视频时序理解的能力差异很大选型时一定要用自己业务场景的真实数据做评测不要只看 benchmark 分数。2.2 Agent 对数据平台的需求跟人有什么本质不同这个问题我琢磨了很久因为搞不清楚这个就理解不了为什么需要“面向 Agent”重新设计。后来我总结出四个关键差异。第一是延迟敏感度。人查报表等三秒可以接受。但 Agent 在执行多步任务时每一步都要检索数据如果每次检索都要两秒十步下来就是二十秒用户体验直接崩掉。所以面向 Agent 的数据平台检索延迟必须压到毫秒级这意味着索引结构、缓存策略、向量检索算法都要重新优化。第二是上下文组装。人看数据是自己筛选、自己判断相关性。Agent 需要平台直接给它组装好一个“上下文包”里面包含当前任务最相关的信息片段而且要按照一定的逻辑顺序排列。这要求平台不仅会检索还要会排序、会压缩、会做冲突消解。第三是记忆的持久化与演化。人的记忆在脑子里Agent 的记忆必须存在平台上。而且 Agent 的记忆不是简单的日志堆积它需要支持遗忘、合并、抽象。比如 Agent 执行了一百次类似任务平台应该能把这些执行轨迹抽象成一条“经验”而不是让 Agent 每次去翻一百条原始记录。第四是权限与安全。Agent 可能会代表不同用户去访问数据也可能在自主执行中触碰到敏感信息。平台需要一套细粒度的权限模型能精确控制“这个 Agent 在这个任务上下文中能访问哪些数据的哪些部分”。这比传统的用户级权限复杂得多。2.3 “湖生万物”背后的数据衍生逻辑“湖生万物”这个说法我一开始觉得是营销话术后来仔细想了想它其实指向一个很实在的能力数据湖不只是存数据还能生成新的数据资产。具体怎么生成我梳理了几条路径。第一条是抽取式生成从非结构化内容里抽取出结构化知识比如从合同文本里抽出甲乙方、金额、期限从技术文档里抽出 API 定义和参数说明。第二条是关联式生成通过分析不同数据之间的共现关系自动建立知识图谱的边比如发现某篇论文和某个专利引用同一个技术术语就建立关联。第三条是轨迹式生成把 Agent 的执行过程记录下来抽象成可复用的任务模板或决策规则。第四条是合成式生成在数据不足时用生成模型合成符合分布的补充数据用于训练或测试。这四条路径里我觉得轨迹式生成是最被低估的。大部分团队做 Agent 记忆就是存对话历史顶多做个向量检索。但真正有价值的是把 Agent 的“成功执行路径”抽象出来变成平台上的一个数据资产。下次遇到类似任务Agent 可以直接调用这个路径模板而不是从零开始试错。3. 核心模块的实操要点与参数选择3.1 多模态数据接入层的设计细节接入层是整个平台的第一道关口设计得好不好直接决定后续处理的效率。我在实际项目里踩过的坑主要集中在三个方面。格式解析的容错处理。你永远想不到用户会传什么格式的文件。我见过把 .doc 后缀改成 .pdf 传上来的见过加密的压缩包见过扫描件里全是手写体。接入层必须有一套健壮的格式探测机制不能只看后缀名要读文件头魔数。对于解析失败的不能直接丢弃要进死信队列并通知上传者否则数据静默丢失是最可怕的。大文件的流式处理。一个 2GB 的视频文件如果你先完整下载再解析内存直接爆掉。正确的做法是流式读取边读边拆帧、边转写。这里有个参数很关键分片大小。我一般设 4MB 到 8MB 之间太小会导致请求次数过多太大则内存压力大。具体数值要根据你的解析服务并发数和单机内存来算。假设单机内存 16GB预留 4GB 给系统12GB 可用于处理并发 10 个任务那每个任务最多 1.2GB分片大小控制在 8MB 以内比较安全。元数据抽取的时机。元数据是在接入时抽还是异步抽我的经验是分两类轻量级的文件大小、类型、上传时间、哈希值在接入时同步抽取用于去重和基本管理重量级的内容摘要、实体识别、向量嵌入走异步流水线。同步部分要控制在 100ms 以内否则会影响上传体验。3.2 向量索引与检索的性能调优向量检索是 Agent 取数据的核心通道它的性能直接决定 Agent 的响应速度。这里我分享几个实测有效的调优手段。索引类型的选择。目前主流的有 IVF、HNSW、DiskANN 几种。IVF 建索引快、内存占用低但召回率对参数敏感HNSW 召回率高、延迟低但内存消耗大DiskANN 适合超大规模数据把索引放磁盘上但延迟比内存索引高一个量级。我的建议是数据量在千万级以内用 HNSW内存换性能上亿级别用 DiskANN 或者 IVF 加量化。量化压缩的取舍。向量维度通常是 768 或 1536每个 float32 占 4 字节一亿条就是 600GB 左右内存根本放不下。所以必须做量化。PQ乘积量化能把向量压缩到原来的 1/16 甚至 1/32但会损失精度。我的经验是先用 PQ 做粗筛召回 top 1000然后用原始向量做精排取 top 10。这样既省内存又保精度。检索参数的调优。以 HNSW 为例有两个关键参数M 和 efSearch。M 是每个节点的邻居数越大召回率越高但内存和建索引时间也越大一般设 16 到 64 之间。efSearch 是搜索时的候选集大小越大越准但越慢。我通常从 efSearch64 开始调观察召回率和延迟的曲线找到拐点。实测下来efSearch 从 64 提到 128召回率可能只涨 2%但延迟翻倍那就不值得。索引类型适用数据量内存占用召回率典型延迟IVF百万到千万低中5-20msHNSW千万以内高高1-5msDiskANN亿级以上低中高10-50ms3.3 Agent 记忆存储的结构设计Agent 记忆是这套平台里最特殊的一块它跟传统的数据存储有本质区别。我把它拆成三种类型来设计。短期记忆也就是当前会话的上下文。这部分要求读写极快通常放在内存数据库里比如 Redis 或者本地的 KV 存储。结构上就是按会话 ID 组织的消息列表每条消息带时间戳、角色、内容、工具调用记录。关键是设置合理的过期策略我一般设 2 小时太短会导致长任务丢失上下文太长则内存浪费。长期记忆跨会话的知识沉淀。这部分用向量数据库存每条记忆是一个嵌入向量加元数据。元数据里要包含来源、时间、置信度、访问次数。这里有个设计要点记忆要支持“强化”和“遗忘”。被频繁召回的记忆置信度应该提升长期不被访问的置信度衰减最终被归档或删除。这个机制模拟了人的记忆规律能有效控制记忆库的膨胀。程序记忆也就是 Agent 学会的“怎么做”。这部分最容易被忽略但价值最高。它存储的是任务执行的步骤模板、工具调用的参数模式、常见错误的处理策略。结构上可以用图来存节点是步骤边是转移条件。当 Agent 遇到新任务时先检索有没有匹配的程序记忆有就直接复用没有才走推理。实操心得程序记忆的冷启动是个难题。我的做法是先用人工编写一批种子模板覆盖高频任务类型然后让 Agent 在执行中不断修正和扩展。不要指望 Agent 一开始就能自己学会所有东西。4. 从零搭建一个最小可用平台的完整流程4.1 环境准备与基础组件选型假设你现在要搭一个最小可用的全模态数据平台支撑一个内部 Agent 的开发和测试。我按自己的经验给一套配置方案。存储层对象存储用 MinIO单机就能跑S3 兼容后期迁移到云上也无缝。元数据用 PostgreSQL别用 MySQL因为后面要做向量扩展和 JSON 查询PG 的生态更合适。向量检索用 Milvus 或者 QdrantMilvus 功能全但部署重Qdrant 轻量适合起步。缓存用 Redis会话和热点数据都靠它。计算层解析服务用 Python 写因为多模态解析库最全。PDF 解析用 PyMuPDF视频处理用 FFmpeg 加 Whisper 做语音转写图像 OCR 用 PaddleOCR。嵌入模型用开源的 BGE-M3 或者通义千问的嵌入接口前者可本地部署后者省事但依赖网络。编排层任务队列用 RabbitMQ 或者 Redis Stream别用 Kafka起步阶段运维成本太高。工作流编排用 Prefect 或者 Dagster轻量且 Python 原生。这套配置在一台 32GB 内存、8 核 CPU、带一张 24GB 显存显卡的机器上就能跑起来足够支撑日处理万级文档、百万级向量的规模。4.2 数据接入流水线的搭建步骤第一步起 MinIO 和 PostgreSQL。MinIO 用 Docker 一条命令就能跑注意设置好 access key 和 secret key别用默认的。PostgreSQL 建两个库一个存元数据一个给向量检索用如果选 Milvus 就不需要。第二步写接入 API。用 FastAPI 起一个服务接收文件上传做三件事计算文件哈希去重、抽取基础元数据写 PG、把文件流式写入 MinIO。这里要注意上传接口要支持分片上传大文件不能一次性读进内存。第三步配置异步解析流水线。文件上传成功后往消息队列发一条解析任务。解析 worker 从队列取任务根据文件类型分发到不同的解析器。解析结果包括文本内容、分块后的 chunk、每个 chunk 的嵌入向量、以及抽取出的实体和关系。第四步建立索引。文本 chunk 的向量写入向量库实体和关系写入图数据库或者 PG 的 JSON 字段。同时更新元数据里的解析状态。第五步验证。写一个简单的检索接口输入一句查询看能不能召回相关的 chunk。这一步一定要用真实数据测我见过太多 demo 用玩具数据跑得飞起一上真实数据就崩。4.3 Agent 接入与记忆模块的联调平台搭好了接下来让 Agent 接进来。我以常见的 ReAct 框架为例说下联调要点。Agent 的每次工具调用如果是检索类工具就走平台的检索接口。这里有个关键设计检索接口要支持“上下文组装”模式。也就是说Agent 传过来的不只是一句查询还有当前任务描述、历史对话摘要、已获取的信息列表。平台根据这些信息做多路召回、去重、排序、压缩返回一个组装好的上下文包。记忆模块的联调分两步。写入侧Agent 每完成一轮对话或一个任务步骤把关键信息写入短期记忆任务结束后把值得沉淀的内容写入长期记忆。读取侧Agent 在每轮推理前先从长期记忆检索相关经验注入到当前上下文中。联调时最容易出问题的地方是记忆污染。Agent 把错误的信息写入了长期记忆后续任务被误导。我的解决办法是给记忆加一个“验证状态”字段新写入的记忆标记为“待验证”只有被后续成功任务引用并验证过的才转为“可信”。这样能有效防止错误传播。4.4 性能压测与瓶颈定位平台跑通之后一定要做压测。我一般从三个维度压并发上传、并发检索、长任务执行。并发上传主要看接入层的吞吐和 MinIO 的写入带宽。如果瓶颈在解析就加 worker如果瓶颈在存储就考虑分片或者换更快的盘。并发检索看向量库的 QPS 和延迟。这里有个反直觉的点向量检索的延迟不是线性的当并发超过某个阈值后延迟会突然飙升。这是因为向量检索是计算密集型CPU 或 GPU 打满了之后请求就开始排队。所以压测时要找到那个拐点把线上并发控制在拐点的 70% 左右。长任务执行看的是记忆模块的读写和上下文组装的效率。我遇到过一个坑Agent 执行到第 20 步时突然变慢排查发现是短期记忆的消息列表太长了每次组装上下文都要遍历全部历史。解决办法是加一个滑动窗口只保留最近 N 轮更早的做摘要压缩。5. 常见问题排查与避坑经验实录5.1 多模态检索召回不准的排查思路这是被问得最多的问题。Agent 检索出来的内容跟查询意图不匹配导致回答质量差。我一般按这个顺序排查。先看嵌入模型是否匹配场景。通用嵌入模型在专业领域比如医疗、法律、工业表现会明显下降。解决办法是用领域数据做微调或者换用在该领域表现更好的模型。我实测过同一个查询通用模型召回的相关文档排在第 15 位微调后能排到第 3 位。再看分块策略是否合理。chunk 太大一个向量里混了多个主题检索时精度下降chunk 太小上下文不完整Agent 拿到也理解不了。我的经验是技术文档按段落分每块 300 到 500 字对话记录按轮次分表格单独成块并保留表头。可以加一个重叠窗口比如每块跟下一块重叠 50 字防止关键信息被切断。最后看检索参数是否调优。top_k 设太小相关的内容没召回来设太大噪声太多。我一般先用 top_k20 召回然后用重排序模型精排取 top 5 给 Agent。重排序模型用 BGE-Reranker 效果就不错。5.2 Agent 记忆膨胀与检索变慢的处理记忆库跑一段时间后检索越来越慢这是必然的。我见过一个项目三个月没清理记忆库从十万条涨到两千万条检索延迟从 5ms 涨到 200ms。处理手段有几个层次。最基础的是定期归档把超过一定时间且访问次数低于阈值的记忆移到冷存储不参与在线检索。进阶一点的是记忆合并把相似的记忆聚类合并成一条更抽象的记忆。比如 Agent 处理了一百次“查询天气”的任务没必要存一百条记录合并成一条“查询天气的流程和常见问题”就够了。最高级的是记忆抽象用 LLM 把多条具体记忆总结成一条经验规则这需要额外的计算成本但压缩率最高。避坑提示记忆清理一定要有回滚机制。我吃过亏一次批量归档把正在被某个长任务引用的记忆删了导致任务中断。后来改成软删除标记为归档但保留数据确认无引用后再物理删除。5.3 多租户场景下的权限与隔离如果平台要服务多个团队或用户权限设计不能马虎。我推荐三层模型。第一层是租户隔离不同租户的数据在存储层面就分开比如 MinIO 的不同 bucket向量库的不同 collection。这样最安全但资源利用率低。第二层是命名空间隔离同一租户内不同项目用命名空间区分检索时自动加过滤条件。这个灵活性和安全性平衡得比较好。第三层是文档级权限每份文档带权限标签检索时根据 Agent 的身份过滤。这层最细但实现复杂性能开销也大。我的建议是起步阶段用第二层等业务复杂了再上第三层。千万别一上来就搞最复杂的维护成本会让你怀疑人生。问题现象可能原因排查手段解决方案检索结果不相关嵌入模型不匹配人工评估 top 20 结果微调模型或换模型检索延迟突增索引膨胀或并发过高看监控 QPS 和延迟曲线扩容或加缓存记忆写入失败向量库连接池耗尽查连接数和错误日志调大连接池或加重试解析任务堆积worker 不足或解析超时看队列长度和 worker 状态加 worker 或优化解析逻辑跨模态检索缺失模态对齐没做好检查各模态向量是否同空间统一嵌入模型或加对齐层5.4 成本控制的几个实用手段全模态数据平台很烧钱存储、计算、向量检索都是成本大头。我分享几个实测有效的省钱办法。存储分层。热数据放 SSD温数据放 HDD冷数据放对象存储的低频层。我算过同样 100TB 数据全放 SSD 每月成本是分层存储的 5 倍以上。嵌入计算的批处理。嵌入模型推理是 GPU 密集型单条推理浪费算力。攒一批一起算吞吐能提升 10 倍以上。批大小根据显存来定24GB 显存跑 BGE-M3批大小设 64 比较稳。向量索引的按需加载。不是所有数据都需要常驻内存索引。可以把索引分成热索引和冷索引热索引常驻冷索引按需加载。这样内存占用能降一半以上。解析任务的优先级调度。不是所有文件都急着解析。用户刚上传的优先处理历史归档的可以慢慢来。用优先级队列把计算资源花在刀刃上。6. 这套平台后续可以怎么扩展平台跑通最小可用版本之后有几个扩展方向我觉得价值很高。第一个方向是Agent 执行轨迹的深度利用。现在大部分平台只是把轨迹当日志存其实轨迹里藏着大量可复用的知识。可以做一个轨迹挖掘模块自动识别高频任务模式生成任务模板推荐给 Agent 使用。这相当于让平台从“数据仓库”进化成“经验仓库”。第二个方向是多 Agent 协作的数据共享。单个 Agent 的能力有限多个 Agent 协作时它们之间的数据交换、记忆共享、冲突消解都需要平台支持。可以设计一套 Agent 间的数据协议让平台成为协作的中枢。第三个方向是数据质量的自动治理。全模态数据接进来之后质量参差不齐。可以引入自动质量评估对低质量数据打标、隔离、甚至触发重新采集。这能显著提升 Agent 的检索准确率。我自己在实际项目里的体会是全模态数据平台的建设不是一蹴而就的别想着一步到位。先把文本和结构化数据跑通再逐步加图像、音频、视频。每加一个模态都要重新审视索引结构、检索策略、记忆设计。贪多嚼不烂稳扎稳打才是正道。最后分享一个小技巧平台上线初期一定要建一个“检索质量反馈”通道。让 Agent 的使用者能标记“这次检索结果好不好”这些反馈数据是后续调优最宝贵的资产。我见过太多团队埋头优化算法却忽略了真实用户的反馈信号走了很多弯路。