1. 从湖生万物这个名字说起一个数据平台为什么要谈全模态第一次看到湖生万物这个提法我脑子里冒出来的第一个念头是这不就是数据湖那套东西换了个说法吗但仔细琢磨面向 Agent 的全模态数据平台这个定位会发现它想解决的问题跟传统数据湖完全不是一回事。传统数据湖的核心任务是存和算——把结构化、半结构化的数据倒进去然后用 SQL 或者 Spark 跑批。数据是给人看的给人分析的最终产出是报表、看板、指标。但 Agent 时代的数据消费方变了消费方式也变了。一个 AI Agent 在完成任务时它需要的不只是一张干净的表它可能需要同时读取一段文本、一张图片、一段音频、一个 API 返回的 JSON、甚至是一段视频里的关键帧。这些数据形态各异、来源分散、更新频率不同但 Agent 需要在一次推理链路里把它们全部拿到、理解、关联起来。这就是全模态三个字的分量所在。它不是简单地把图片和文本塞进同一个存储桶而是要解决一个更底层的问题当数据的消费方从人变成Agent时数据平台需要重新设计自己的接口、组织方式和治理逻辑。我过去两年在几个 Agent 项目里踩过的坑几乎都跟数据供给有关。Agent 的推理能力再强如果喂给它的数据是割裂的、过期的、格式不统一的最终输出就是不可靠的。所以当我看到湖生万物这个定位时第一反应是终于有人把数据平台的设计视角从人怎么查数据切换到Agent 怎么用数据了。这篇文章我会围绕这个平台定位拆解几个核心问题全模态数据平台到底要解决什么、Agent 消费数据的特殊需求是什么、数据湖架构在 Agent 场景下需要做哪些改造、以及在实际落地时有哪些容易踩的坑。内容会结合我在 Agent 开发中积累的经验尽量给出可参考的思路和实操建议。2. Agent 消费数据的三个特殊需求跟人查数据到底哪里不一样2.1 需求一一次请求要拿到多种模态的关联数据人查数据通常是我要看某个指标或者我要拉一批明细一次请求对应一种数据形态。但 Agent 不一样。假设你做一个电商客服 Agent用户问我上周买的那件红色连衣裙有没有同款不同色的Agent 需要同时拿到订单记录结构化、商品图片图像、商品描述文本文本、库存状态实时结构化数据。这四种数据可能分布在四个不同的系统里但 Agent 需要在一次推理中全部拿到。传统做法是让 Agent 分别调用四个 API然后在 Agent 侧做拼接。但这样做的问题是延迟叠加、一致性无法保证、Agent 的上下文窗口被大量无关数据占用。全模态数据平台的价值就在于它能把这种跨模态关联查询下沉到平台层Agent 只需要发一次请求平台返回一个已经关联好的多模态数据包。2.2 需求二数据要能被理解而不只是被读取人看数据看到的是数字和文字理解靠人脑。Agent 看数据需要的是可被模型直接消费的表示。这意味着数据平台不能只提供原始数据还需要提供某种程度的语义封装。举个例子一张商品图片如果平台只返回图片的 URL 或者二进制流Agent 还得自己调视觉模型去理解。但如果平台能在存储时就生成图片的 embedding、标签、结构化描述Agent 就能直接拿这些语义信息做推理。这不是说平台要替代模型而是说平台要在数据层面做好预理解减少 Agent 侧的重复计算。2.3 需求三数据治理要面向机器消费做优化传统数据治理关注的是数据质量、血缘、权限这些当然也重要。但 Agent 场景下治理还需要多考虑几件事数据的时效性标注Agent 需要知道这条数据是 5 分钟前的还是 5 天前的、数据的置信度这条数据来自可靠源还是用户生成内容、数据的模态完整性一个数据包里文本有了但图片缺失Agent 需要知道。这些元信息在人查数据的场景下往往被忽略因为人可以根据经验判断。但 Agent 没有这种常识它只能依赖平台提供的元数据。所以全模态数据平台在治理层面需要比传统数据湖多走一步。我在实际项目里遇到过一个典型问题Agent 拿到了一条三天前的库存数据但用户问的是现在有没有货Agent 直接回答了有货结果实际已经售罄。问题不在于 Agent 笨而在于数据平台没有把数据时效性这个元信息传递给 Agent。3. 全模态数据湖的架构改造从存算分离到存算理解一体3.1 存储层多模态数据的统一编目传统数据湖的存储层核心是文件系统和对象存储编目靠 Hive Metastore 或者类似的元数据服务。但多模态数据带来的第一个挑战就是图片、音频、视频这些非结构化数据怎么编目我的经验是不能简单地把它们当成大号二进制文件扔进去。需要做几件事统一 ID 体系每个模态的数据都要有一个全局唯一的 ID并且这个 ID 要能跟其他模态的数据关联。比如一个商品它的文本描述、图片、视频、结构化属性都挂在同一个商品 ID 下。模态感知的元数据 schema不同模态需要不同的元数据字段。图片需要分辨率、格式、色彩空间音频需要采样率、时长、编码格式文本需要语言、编码、长度。这些元数据要能被统一查询。内容指纹对非结构化数据做内容哈希用于去重和版本管理。我见过一个项目因为没做内容指纹同一张商品图被重复存储了 17 次浪费了大量存储和计算资源。3.2 计算层从批流一体到批流理解一体传统数据湖的计算层讲批流一体解决的是实时和离线计算的统一。但 Agent 场景下还需要加上理解这一层。所谓理解包括模态转换把一种模态转成另一种。比如语音转文字、图片生成描述、视频抽帧。语义提取从原始数据中提取 embedding、标签、实体、关系。关联推理跨模态建立关联。比如根据图片中的物体和文本中的描述判断它们是否指向同一个商品。这些计算任务的特点是计算密集、对延迟敏感、结果需要被缓存。所以在架构上我倾向于把它们做成独立的理解服务层跟传统的批处理、流处理并列而不是混在一起。3.3 服务层面向 Agent 的统一数据接口这是全模态数据平台最核心的差异化能力。传统数据平台的服务层提供的是 SQL 接口、REST API、SDK面向的是开发者。但 Agent 需要的是一个更语义化的接口。我设想的理想接口是这样的Agent 发一个自然语言查询或者结构化查询平台返回一个多模态数据包里面包含所有相关的数据片段、每个片段的元信息、片段之间的关联关系。Agent 拿到这个包之后可以直接塞进上下文窗口做推理不需要再做额外的数据获取和拼接。这个接口的设计难点在于如何决定返回哪些数据、返回多少、以什么粒度返回。返回太少Agent 推理信息不足返回太多上下文窗口爆炸。这需要平台根据查询意图做智能裁剪。4. 落地时最容易踩的五个坑4.1 坑一把全模态理解成多模态存储这是最常见的误解。很多团队觉得我把图片、音频、文本都存到同一个对象存储里就算全模态数据平台了。但实际上存储只是第一步真正的难点在于跨模态的关联、检索和理解。如果只是存进去但查不出来、关联不起来那跟分别存在三个系统里没有本质区别。4.2 坑二忽略模态之间的时间对齐多模态数据往往来自不同的采集渠道时间戳可能不一致。比如一个监控场景视频流的时间戳、音频流的时间戳、传感器数据的时间戳可能来自不同的时钟源。如果不做时间对齐Agent 拿到的数据在时间维度上是错位的推理结果就会出错。我的做法是在数据接入时就做时间归一化统一到一个参考时钟并且记录每个模态数据的时间偏移量。这样在查询时可以根据需要做对齐。4.3 坑三元数据治理跟不上数据增长多模态数据的元数据量是巨大的。一张图片可能有几十个元数据字段一段视频可能有上百个。如果元数据治理没做好查询性能会急剧下降。我见过一个项目因为元数据表没有做好分区和索引一个简单的跨模态查询要跑十几分钟。建议的做法是元数据分层存储热数据放内存数据库温数据放列式存储冷数据放对象存储。同时元数据的 schema 要做版本管理避免频繁变更导致兼容性问题。4.4 坑四权限模型没有考虑 Agent 的特殊性传统权限模型是用户-角色-资源三层。但 Agent 场景下权限的主体可能是 Agent 本身也可能是 Agent 代表的用户还可能是 Agent 调用的下游服务。这三者的权限边界怎么划是个新问题。我的经验是Agent 的权限应该遵循最小必要原则并且要能动态调整。比如一个客服 Agent 在处理订单查询时只能读取该用户的订单数据不能读取其他用户的数据。这个约束需要在平台层强制执行不能依赖 Agent 自己遵守。4.5 坑五低估了数据质量对 Agent 输出的影响Agent 的输出质量高度依赖输入数据的质量。如果数据平台提供的数据有缺失、有错误、有过期Agent 的输出就会不可靠。而且 Agent 不像人它不会主动质疑数据的可靠性。所以数据平台需要建立一套面向 Agent 的数据质量监控体系包括完整性检查、时效性检查、一致性检查。5. 从湖生万物看数据平台的下一站5.1 数据平台的角色正在从支撑变成参与过去数据平台是支撑角色业务系统产生数据数据平台负责存储和计算最终产出报表供决策参考。但在 Agent 场景下数据平台开始参与到业务链路中。Agent 的每一次推理都需要数据平台实时供给数据。数据平台的质量和响应速度直接决定了 Agent 的输出质量。这意味着数据平台需要具备更高的 SLA、更强的实时能力、更智能的数据组织方式。这也是湖生万物这个提法背后的深意数据湖不再只是一个被动的存储池而是一个能主动生长、主动关联、主动供给的有机体。5.2 全模态只是起点跨模态推理才是终局全模态数据平台解决了数据能拿到的问题但下一步是数据能推理。也就是说平台不仅要能返回多模态数据还要能基于这些数据做初步的推理和关联把更高层次的语义信息提供给 Agent。比如Agent 问这个用户的投诉跟最近的产品变更有没有关系平台不仅需要返回投诉记录和产品变更记录还需要分析两者之间的时间关联、语义关联给出一个初步的判断。这需要平台具备一定的推理能力而不只是检索能力。5.3 对开发者的启示数据思维需要升级对于做 Agent 开发的同行来说这个趋势意味着我们不能只关注模型和框架还要关注数据层。一个 Agent 项目能不能做好很大程度上取决于数据供给的质量。我建议在做 Agent 设计时就把数据平台的能力纳入考虑而不是等到模型调优遇到瓶颈时才回头补数据层的课。具体来说可以从几个方面入手一是梳理 Agent 需要消费的所有数据模态和来源二是评估现有数据平台是否支持跨模态关联查询三是设计面向 Agent 的数据接口而不是简单复用面向人的接口四是建立数据质量的监控和反馈机制。6. 一些实操层面的建议如果你正在规划或建设面向 Agent 的数据平台以下几点是我从实际项目中总结出来的供参考。第一先做数据编目再做数据接入。很多团队一上来就急着把数据往里灌结果灌进去之后发现找不到、关联不上。正确的顺序是先设计好编目体系明确每种模态的数据怎么标识、怎么关联、怎么检索然后再做接入。第二把理解做成可复用的服务。模态转换、语义提取这些能力不要在每个 Agent 里重复实现而是下沉到平台层做成服务。这样既能保证一致性又能提高效率。第三元数据要跟数据同步更新。我见过太多项目数据更新了但元数据没更新导致 Agent 拿到的元信息是过期的。建议在数据接入管道里就把元数据更新作为强制步骤。第四建立面向 Agent 的数据质量指标。传统的数据质量指标如完整性、准确性仍然适用但需要增加一些 Agent 特有的指标比如数据包完整性一次查询返回的数据是否覆盖了所有需要的模态、语义一致性不同模态的数据是否指向同一个实体。第五权限设计要前置。不要等到平台建好了再补权限而是在架构设计阶段就把权限模型考虑进去。Agent 的权限边界、数据隔离、审计日志这些都需要在平台层做好。第六留好扩展接口。多模态数据的形态还在不断演化今天可能是文本、图片、音频、视频明天可能就有新的模态出现。平台架构要留好扩展点避免每次新模态出现都要大改。从湖生万物这个定位来看面向 Agent 的全模态数据平台还处于早期阶段很多能力还在探索中。但方向是清晰的数据平台需要从为人服务转向为 Agent 服务从存储计算转向存储计算理解一体从被动查询转向主动供给。这个转变对做数据平台和做 Agent 的团队来说都是机会也是挑战。