1. 从“湖生万物”说起这个平台到底在解决什么问题第一次看到“湖生万物助力 AI”这个提法我脑子里冒出来的第一个念头是又是一个把数据湖概念重新包装的发布会主题。但把“面向 Agent 的全模态数据平台”这几个字连起来读一遍再结合 DLF、Flink 这些关键词我意识到这次讲的不是传统数据湖那套存算分离、批流一体的老故事而是数据基础设施正在被 Agent 这个新物种倒逼着做一次结构性调整。先说清楚这个平台是什么。它是一个面向 AI Agent 场景构建的全模态数据管理平台核心能力是把结构化数据、文本、图像、音视频、向量等不同形态的数据统一纳管并且通过一套面向 Agent 的接口层让 Agent 能够以“感知—检索—行动”的方式去消费这些数据。它要解决的问题很具体过去的数据平台是给人看的报表、看板、SQL 查询人来做决策现在数据的第一消费方变成了 AgentAgent 不会写 SQL它需要的是语义化的数据访问、实时的上下文注入、以及跨模态的联合检索。适合谁来参考这篇内容三类人。第一类是正在做 Agent 应用开发但被数据接入卡住的工程师你可能已经用上了某个 Agent 框架但发现接数据这一步特别别扭要么是接口不匹配要么是延迟太高。第二类是数据平台的建设者你手里有一套基于 Flink 和 DLF 的湖仓体系现在业务方要求你支持 Agent 场景你需要知道架构上要补什么。第三类是对全模态数据管理感兴趣的技术负责人你想搞清楚“全模态”到底是不是伪需求以及它在 Agent 场景下的真实价值边界在哪里。我个人的判断是这个方向不是概念炒作。Agent 要真正干活数据供给的质量和形态直接决定了它的上限。一个只会调 API 的 Agent 和一个能实时读取企业全量数据湖的 Agent能力差距是数量级的。下面我把这个平台涉及的核心设计思路、关键技术点、实操层面的注意事项拆开来讲尽量让不同基础的读者都能拿到可落地的东西。2. 全模态数据平台的架构设计思路拆解2.1 为什么 Agent 场景需要“全模态”而不是“多模态”多模态和全模态这两个词经常被混用但在数据平台的语境下它们指向的是不同的架构决策。多模态通常指的是模型层面能处理多种输入格式比如一个模型同时接受文本和图像。全模态在数据平台语境下指的是数据存储、元数据管理、检索索引、权限控制这一整套链路都对所有模态一视同仁不存在“主数据是结构化数据其他模态作为附件挂载”这种主从关系。为什么这个区别对 Agent 很重要举个例子。假设你有一个客服 Agent用户上传了一张发票截图问“这笔报销为什么被拒了”。这个请求里包含了图像数据发票、结构化数据报销单状态、审批流记录、文本数据审批意见。如果平台是“多模态”架构图像走 OCR 转文本后再去查结构化数据中间会有信息损耗和延迟。如果平台是“全模态”架构发票图像本身作为一个数据对象和报销单记录、审批意见文本在同一个元数据体系下被索引Agent 可以一次性拿到所有相关上下文。这个设计选择的背后逻辑是Agent 的推理过程是跨模态的数据平台如果按模态分而治之Agent 就得自己做数据拼接这个拼接逻辑会变得极其复杂且难以维护。全模态架构把拼接这件事下沉到平台层Agent 只需要表达“我要和这个发票相关的所有信息”平台负责返回完整的上下文包。2.2 湖仓一体在这个场景下的角色变化传统湖仓一体的核心价值是让数据在同一个存储底座上同时支持批处理和流处理避免数据在数据湖和数据仓库之间来回搬运。这个价值在 Agent 场景下依然成立但重心发生了变化。过去湖仓一体主要服务于 BI 和报表场景对查询延迟的容忍度是分钟级甚至小时级。Agent 场景下延迟要求被压缩到秒级甚至亚秒级。这不是说 Agent 每次请求都要查全量数据而是说 Agent 需要的是一个“实时可查”的数据视图。DLF 作为湖仓的元数据管理层在这里承担的角色从“表结构管理”扩展到了“Agent 可发现的数据资产目录”。我理解的设计思路是这样的DLF 维护的不只是表名、字段名、分区信息这些传统元数据还包括数据的语义描述、模态标签、访问模式、更新频率等面向 Agent 的元信息。Agent 通过一个统一的元数据接口来发现“我有哪些数据可以用”而不是由开发者硬编码数据源。这个变化看起来不大但它决定了 Agent 能否在运行时动态扩展自己的能力边界。2.3 Flink 在 Agent 数据链路中的定位Flink 在这个架构里的角色需要重新理解。传统 Flink 作业做的是 ETL把数据从 A 搬到 B做清洗、聚合、关联。在 Agent 场景下Flink 多了一个身份实时上下文供给管道。Agent 在执行任务时往往需要最新的数据状态。比如一个库存管理 Agent它需要知道当前库存量而不是一小时前的快照。Flink 的流处理能力可以把数据库的变更日志实时捕获经过必要的转换后推送到 Agent 可访问的低延迟存储层。这个链路的端到端延迟直接决定了 Agent 决策的时效性。这里有一个关键的设计取舍是让 Agent 直接查数据库还是通过 Flink 构建一个实时数据视图直接查数据库的问题在于Agent 的查询模式不可预测可能对生产库造成压力而且跨库关联查询在 Agent 场景下很常见直接查库不现实。通过 Flink 构建实时视图相当于在 Agent 和源系统之间加了一层缓冲和加工层既保护了源系统又提供了 Agent 友好的数据形态。2.4 面向 Agent 的接口层设计考量这是整个平台最核心也最容易被低估的部分。传统数据平台的接口是给人和程序用的SQL、REST API、SDK。Agent 需要的接口不太一样。Agent 和传统程序的区别在于Agent 的调用是探索性的、多轮的、带上下文的。它可能先问“有哪些数据和这个任务相关”然后根据返回结果决定下一步查什么。这就要求接口层支持元数据发现、语义检索、上下文组装这些能力。我推测这个平台在接口层做了几件事一是把数据访问抽象成“能力”而不是“表”Agent 看到的是“查询客户订单历史”这个能力而不是“orders 表”二是支持自然语言到数据查询的转换Agent 可以用接近自然语言的方式表达数据需求三是返回结果自带上下文比如数据的时间范围、置信度、来源说明让 Agent 能判断这个数据是否可用。这个设计思路的合理性在于它降低了 Agent 开发者对接数据的认知负担。你不需要了解底层表结构只需要知道平台提供了哪些数据能力然后按需调用。代价是平台需要维护一套能力注册和路由机制复杂度从 Agent 侧转移到了平台侧。3. 核心细节解析与实操要点3.1 全模态数据的统一元数据建模全模态平台最基础也最棘手的问题是如何用一套元数据模型来描述结构化和非结构化数据。结构化数据的元数据很成熟表、字段、类型、约束。非结构化数据的元数据则五花八门一张图片有尺寸、格式、拍摄时间一段文本有语言、长度、主题一段音频有采样率、时长、说话人。我见过的比较务实的做法是分层建模。第一层是通用元数据所有数据对象都有唯一标识、创建时间、更新时间、模态类型、存储位置、访问权限。第二层是模态特定元数据按模态类型挂载不同的属性集。第三层是语义元数据由 AI 模型自动抽取或人工标注包括内容摘要、实体标签、情感倾向等。这个分层的好处是Agent 在做数据发现时可以先通过通用元数据和语义元数据做粗筛命中后再加载模态特定元数据做精筛。实操中要注意的是语义元数据的质量直接决定了 Agent 的数据发现效率。如果摘要写得含糊Agent 就找不到正确的数据。我的经验是对于关键数据集语义元数据最好人工审核一遍不要完全依赖模型自动生成。3.2 Flink 实时同步链路的参数调优Flink 做实时数据同步最常见的场景是 MySQL 到某种分析型存储的同步。这个链路的稳定性取决于几个关键参数。首先是 checkpoint 间隔。默认是 10 秒但在高吞吐场景下频繁 checkpoint 会影响吞吐量。我的建议是如果数据延迟要求是秒级checkpoint 间隔可以设到 30 秒到 1 分钟配合 exactly-once 语义故障恢复时最多重放这个间隔内的数据。如果延迟要求是亚秒级那 checkpoint 间隔要相应缩短但要注意观察 checkpoint 耗时如果 checkpoint 本身耗时超过间隔会出现 checkpoint 堆积。其次是并行度设置。并行度不是越大越好。源端 MySQL 的 binlog 读取并行度受限于表数量如果只有几张表并行度设太高反而会增加协调开销。目标端的写入并行度要考虑目标存储的写入瓶颈比如 ClickHouse 的写入并发过高会导致 part 合并压力大。我一般会从源端并行度和目标端并行度中取较小值作为作业并行度然后根据实际吞吐调整。还有一个容易被忽略的参数是 state backend 的选择。对于同步作业状态主要是 offset 和少量聚合结果用 HashMapStateBackend 就够了不需要上 RocksDB。RocksDB 适合状态很大的场景但它的读写性能不如内存态对于状态小的作业反而是负担。3.3 Agent 数据访问的权限与安全设计Agent 访问数据平台权限模型和传统用户访问有本质区别。传统权限是“用户 A 能访问表 B”Agent 场景下权限的主体是 Agent 实例客体是数据能力而且 Agent 的权限可能需要动态调整。我理解的设计是三层权限控制。第一层是 Agent 身份认证每个 Agent 实例有独立的凭证不能共用。第二层是能力级授权控制 Agent 能调用哪些数据能力比如“允许查询订单不允许查询用户手机号”。第三层是数据级过滤即使 Agent 有查询订单的权限返回结果中敏感字段也要做脱敏。实操中要注意的是Agent 的权限审计比传统系统更重要。因为 Agent 的行为是自主的它可能在一次任务中发起几十次数据访问人工很难逐条审查。所以平台需要记录完整的访问日志包括 Agent 标识、访问时间、访问的数据能力、返回的数据量、是否命中敏感字段。这些日志不仅是安全审计的需要也是优化 Agent 数据使用效率的依据。3.4 全模态检索的索引策略全模态检索的难点在于不同模态的数据需要不同的索引结构。文本用倒排索引向量用近似最近邻索引图像用特征索引结构化数据用 B 树或列存索引。平台需要把这些索引统一在一个查询接口下。我见过的比较可行的方案是为每种模态维护独立的索引但在查询层做一个路由和融合。Agent 发起一个跨模态查询时查询层把请求拆解成多个子查询分别路由到对应的索引然后对结果做融合排序。融合排序的策略可以是简单的分数加权也可以是基于学习的排序模型。这里有一个实操中的坑不同模态的相似度分数不可直接比较。文本检索的 BM25 分数和向量检索的余弦相似度不在同一个量纲上。直接加权融合会导致某一种模态主导结果。我的做法是先对每种模态的分数做归一化映射到 0 到 1 区间然后再加权。归一化的参数需要根据实际数据分布来调没有万能值。4. 实操过程与核心环节实现4.1 环境准备与基础组件部署假设我们要搭建一个最小可用的全模态数据平台原型用于验证 Agent 数据接入的可行性。基础组件包括对象存储存放原始数据、DLF 或类似的元数据服务、Flink 集群、一个向量数据库、一个查询网关。对象存储用 S3 兼容的接口就行本地测试可以用 MinIO。元数据服务如果不用云厂商的托管服务可以自己搭一个 Hive Metastore 加自定义的扩展表来存语义元数据。Flink 集群本地测试用 standalone 模式就够了生产环境建议用 Kubernetes 部署方便弹性扩缩容。向量数据库选型看数据规模百万级向量用 FAISS 或 Milvus 单机版就够千万级以上考虑分布式方案。部署顺序上我建议先搭对象存储和元数据服务这两个是基础。然后部署 Flink配置好 checkpoint 存储指向对象存储。最后部署向量数据库和查询网关。查询网关可以用一个轻量的 Web 框架自己写核心逻辑是接收 Agent 请求解析后路由到不同的后端服务组装结果返回。4.2 结构化数据实时入湖的完整链路以 MySQL 订单表同步到数据湖为例完整链路是MySQL binlog → Flink CDC → 数据湖存储Parquet 格式→ DLF 元数据注册 → Agent 可查询。Flink CDC 的配置关键点source 端用 mysql-cdc connector配置好数据库连接、表名、server-id。server-id 要确保唯一否则会和 MySQL 主从复制冲突。sink 端用 filesystem connector配置好输出路径、分区策略、滚动策略。分区策略建议按日期分区方便后续做时间范围查询。滚动策略控制文件大小太小会导致小文件过多太大会导致写入延迟我一般设 128MB 一个文件。元数据注册这一步容易被忽略。Flink 写入数据湖后文件是有了但元数据服务不知道这些文件对应什么表、什么分区。需要有一个额外的步骤把 Flink 写入的路径和分区信息同步到元数据服务。可以用 Flink 的 sink 端自定义逻辑来做也可以起一个定时任务扫描新文件并注册。我倾向于用定时任务因为逻辑简单容错性好。4.3 非结构化数据的向量化与索引构建非结构化数据要能被 Agent 检索需要先向量化。文本用 embedding 模型图像用视觉编码器音频用语音编码器。向量化后的数据存入向量数据库同时把原始数据和向量 ID 的映射关系存入元数据服务。向量化的批量处理策略很重要。如果数据量大不要一条一条调 embedding 接口要批量调用。大多数 embedding 服务支持一次传几十条文本批量调用可以把吞吐量提升一个数量级。但批量大小也不是越大越好受限于服务端的 token 限制和内存一般 32 到 128 条一批比较合适。索引构建的参数需要根据数据规模调。以 FAISS 为例如果向量数量在百万级用 IVF 索引nlist 设为 sqrt(N) 左右。如果要求高召回率可以加 PQ 量化但会损失一些精度。我的经验是先不做量化用 Flat 索引跑通流程确认检索效果后再根据性能瓶颈决定是否加量化。4.4 Agent 侧的数据接入示例Agent 接入平台的方式我建议封装成一个 SDK提供几个核心方法discover发现可用数据能力、query执行数据查询、fetch_context获取上下文包。discover 方法的实现逻辑是Agent 传入任务描述平台返回相关的数据能力列表。这个匹配过程可以用语义检索来做把任务描述向量化后和能力的描述向量做相似度匹配。query 方法接收结构化的查询参数平台转换成底层查询语句执行。fetch_context 方法是最关键的它根据 Agent 当前的任务状态主动组装相关的数据上下文返回。一个实操中的技巧fetch_context 的返回结果要控制大小。Agent 的上下文窗口是有限的如果一次返回太多数据会挤占推理空间。我的做法是平台侧做一个相关性排序只返回 top-K 最相关的数据片段并且每个片段附带一个简短的相关性说明让 Agent 知道为什么这个数据被返回。5. 常见问题与排查技巧实录5.1 Flink 同步作业的典型异常与处理Flink 做数据同步时最常见的异常是 checkpoint 超时。表现是作业日志里频繁出现 “Checkpoint expired before completing”。原因通常是状态太大或者 barrier 对齐太慢。排查思路先看 checkpoint 的 duration 指标如果持续增长说明状态在膨胀。再看 backpressure 指标如果某个算子持续高背压说明下游处理不过来。处理方式分几种情况。如果是状态太大考虑优化状态结构比如把 ListState 改成 ReducingState减少状态条目数。如果是 barrier 对齐慢可以开启 unaligned checkpoint牺牲一些 exactly-once 的严格性换取吞吐。如果是下游写入慢先排查目标存储的健康状况再看是否需要调整并行度或批量写入参数。另一个常见问题是 JDBC 连接器异常报 “Connection is not available” 或 “Communications link failure”。这通常是连接池配置问题。Flink 的 JDBC connector 默认连接池大小可能不够在高并发写入时连接被耗尽。解决方法是调大连接池的 maxActive 和 maxWait 参数同时检查目标数据库的 max_connections 设置是否够用。5.2 Agent 数据访问延迟高的排查路径Agent 反馈数据查询慢排查要分链路看。第一步看查询网关的日志确认请求在网关侧的耗时。如果网关侧就慢说明是网关到后端服务的问题。第二步看后端服务的指标如果是向量检索慢检查索引是否加载到内存FAISS 的索引如果放在磁盘上每次查询都要读盘延迟会高一个数量级。第三步看数据源本身如果是查数据库看慢查询日志。一个容易被忽略的点是 Agent 侧的并发控制。如果 Agent 同时发起大量数据查询请求平台侧可能来不及处理导致请求排队。我的做法是在网关侧加一个限流器按 Agent 实例维度限制并发查询数超出的请求快速失败并返回重试建议而不是让请求堆积。5.3 全模态检索结果不相关的调优方法跨模态检索结果不相关最常见的原因是 embedding 模型和实际数据分布不匹配。比如用通用文本 embedding 模型去编码专业领域的文档效果会打折扣。解决方法是做领域适配可以用领域数据对 embedding 模型做微调或者用领域词典做查询扩展。另一个原因是索引构建时的参数不合适。比如 IVF 索引的 nprobe 参数设得太小检索时只探测了少数几个聚类会漏掉相关结果。nprobe 的调整需要权衡召回率和延迟一般从 1 开始逐步调大观察召回率变化找到拐点。还有一个实操技巧在检索结果返回给 Agent 之前加一层重排序。用一个小型的交叉编码器模型对 top-N 结果做精排可以显著提升相关性。代价是增加一些延迟但对于质量要求高的场景是值得的。5.4 常见问题速查表问题现象可能原因排查方法解决措施Flink checkpoint 超时状态过大或 barrier 对齐慢查看 checkpoint duration 和 backpressure 指标优化状态结构或开启 unaligned checkpointJDBC 连接器报连接不可用连接池耗尽检查连接池配置和目标库连接数调大 maxActive 和 maxWait向量检索延迟高索引未加载到内存检查索引加载状态和内存占用将索引加载到内存或使用内存优化索引跨模态检索结果不相关embedding 模型不匹配或索引参数不当检查模型领域适配性和 nprobe 参数微调模型或调整索引参数Agent 查询并发高导致超时平台侧处理能力不足查看网关和后端服务并发指标增加限流和快速失败机制元数据注册延迟定时任务间隔过长检查元数据同步任务的执行频率缩短同步间隔或改用事件驱动6. 我对这个方向的一些实际体会做 Agent 数据平台这件事我最大的体会是不要试图一步到位。全模态、实时、语义化这三个目标同时追求会让系统复杂度爆炸。务实的做法是先支持一种模态把链路跑通再逐步扩展。我见过太多项目一开始就设计了一个大而全的架构结果每个环节都半成品最后没法上线。另一个体会是Agent 的数据消费模式和人的数据消费模式差异比想象中大。人查数据有明确的目的Agent 查数据往往是探索性的。这意味着平台需要支持更多的“试探性查询”并且要能快速返回一个粗略的结果让 Agent 判断方向。这对查询接口的设计提出了新要求不能只考虑精确查询还要考虑模糊查询和采样查询。最后分享一个小技巧在 Agent 和平台之间加一个缓存层缓存 Agent 最近查询过的数据。Agent 的多轮对话中经常会在相近的时间窗口内重复查询相似的数据。缓存命中率在实测中能达到 30% 到 40%对降低延迟和减轻后端压力都有明显效果。缓存的失效策略要结合数据的更新频率来定对于实时性要求高的数据缓存 TTL 设短一些比如 10 秒对于变化不频繁的元数据TTL 可以设到几分钟。