从向量存储到 Agentic 数据基础设施：Paimon × Milvus 如何构建 AI 原生多模态数据湖-阿里云开发者社区

演讲者：李钰（Yu Li）｜阿里云 EMR & Milvus 负责人，Apache Paimon PMC Member
本文整理自李钰在 Apache Flink Forward Asia 2026 的演讲，讨论 AI 与 Agent 进入生产环境后，数据湖与向量数据库“双系统”架构暴露出的结构性问题，以及 Apache Paimon 与 Milvus 围绕同一份湖数据协同的技术路径。主要内容包括：
过去几年，AI 应用的焦点不断变化：从模型能力，到 RAG，再到能够持续运行、调用工具并与环境交互的 Agent。但当 Agent 真正进入生产环境，一个此前被低估的问题开始浮出水面：我们的数据基础设施，是否真的为这种持续运行的 AI 系统做好了准备？
今天我想讨论的，不是某一个单点 feature，也不只是如何把一次向量检索做得更快，而是 AI 时代的数据基础设施应该如何重新分层。
用更直接的话来说：随着 Agent 和多模态应用进入生产，我们是否有可能把数据的存储与治理、在线检索与服务，重新收敛到同一份数据之上？
我的核心判断是：未来 AI 数据基础设施的竞争，不会只体现在检索性能上。更关键的是，谁能率先把存储、治理、发现与服务整合为一体。围绕这个目标，Apache Paimon 与 Milvus 的协同提供了一条值得关注的开源路径：由 Paimon 承载统一湖存储、版本控制和数据治理，由 Milvus 提供高性能、可扩展的向量检索与在线服务。
如果今天只带着一个问题往下读，我建议记住这个问题：既然我们已经有成熟的数据湖和专用向量数据库，为什么 AI 工程实践反而越来越复杂？
今天，几乎每一个开始落地生产级 RAG、Agent 或多模态检索的团队，都会逐渐遇到一种相似的架构：一边是数据湖，保存原始数据、特征、训练集和批处理结果；另一边是向量数据库，保存 embedding 和索引，承担在线检索；两者之间，则是一组不断变长的 ETL、同步、重刷和 Schema 映射管线。
这套架构在早期并不显得荒谬。数据湖擅长存储和批处理，向量数据库擅长 ANN 检索，各自承担最擅长的工作。但随着数据规模、更新频率和治理要求不断上升，系统开始不得不维护“两份真相”：一份在湖中，一份在向量数据库中。
数据一改，索引要重刷；Schema 一变，字段映射要调整；线上服务与离线分析可能看到不同时间点的数据；大量冷数据很少被查询，服务集群却仍要常驻。此时，复杂性已经不是“ETL 写得不够好”，也不是再增加一个同步组件就能解决的问题，而是来自架构本身。
这正是我们希望改变的局面：数据不应该为了被不同引擎使用，就在“两份真相”之间被反复搬运。
为什么这个问题现在变得格外突出？因为 AI 系统访问数据的方式已经发生了变化。过去两年，很多团队经历了一个典型的三阶段演进。
第一阶段是静态 RAG。系统把文档切片，生成 embedding，建立索引，再完成一次检索。数据会变化，但变化相对缓慢，整个系统更像是在查询一个知识库。
第二阶段是 Tool Use。模型开始连接数据库、API 和工作流，能够在一次会话里执行一串动作，但整体仍是一种会话级的增强能力。
第三阶段是 Production Agent。Agent 持续运行、反复读写、长期持有上下文，线上服务和线下分析也开始交织。此时，数据不再是一批静态资产，而成为 Agent 持续消费、持续生产、持续修正的运行材料。
因此，问题已经不再只是“向量检索够不够快”，而是数据底座能不能支撑持续读写、反复检索、版本演进和在线离线协同。
与此同时，数据形态本身也在发生变化。真实 AI 应用处理的远不只是文本 embedding，还包括图片、视频、音频、日志、传感器信号和大量结构化属性。一条向量关联着数十、数百，甚至上千个 metadata 字段，已经不罕见。
传统向量数据库以向量检索为中心，标量通常用于过滤，大对象往往需要外置，数据治理能力也相对有限；传统数据湖擅长保存海量结构化和非结构化数据，却长期缺少原生向量类型和 ANN 查询语义。
真正缺少的不是更多系统，而是一个能把向量、标量、非结构化对象和索引都视为一等公民的数据底座。
如果把当前双系统架构的代价归纳一下，可以看到四个结构性问题。
第一是重复存储。Embedding 在湖里一份，在向量数据库里又保存一份。规模变大后，这不仅是存储成本问题，也会变成数据所有权、治理与血缘问题。
第二是索引冗余和重建。索引往往在向量数据库里独立构建，游离于数据湖的版本、事务和血缘体系之外。源数据或 embedding 模型发生变化，索引就需要重刷，而这一过程很难进入统一的数据治理闭环。
第三是一致性窗口。源数据更新到在线检索生效之间存在延迟，于是很难回答一个基础问题：线上查询看到的数据，与离线训练和分析看到的，究竟是不是同一份数据视图？
第四是弹性不足。很多向量服务需要常驻在线集群。即使大量历史数据访问频率很低，团队依然要持续为计算和内存付费。
根因在于，现有架构并不是围绕“同一份数据同时支持服务与发现”设计的。
面向下一阶段，我们希望得到的不是一个更大的封闭系统，而是一套围绕同一份数据建立的能力组合。
其一，统一存储。向量、标量、Blob 和索引共存在受治理、可版本化的底座中。
其二，流批一体。流式写入、批量回填和离线加工可以作用于同一份数据，不需要为在线服务与离线分析维护两套组织方式。
其三，一份数据、多种引擎。同一份湖数据可以被在线检索引擎低延迟服务，也可以被 Spark、Flink 等计算引擎大规模扫描和再加工，而且不绑定于某个特定引擎。
其四，弹性计算。常驻服务、按需计算和离线批处理可以按照访问频率和工作负载自由组合，让资源成本与业务需求匹配。
这并不是某一家厂商独有的叙事。Databricks 在从 Lakehouse 一侧向外延伸，Zilliz 在从向量数据库一侧向外延伸，Paimon × Milvus 则代表了一条“开源数据湖 + 开源检索引擎”的协同路径。
这些路线都看到了同一个趋势，但一个关键问题仍然值得追问：那份数据最终归谁？如果统一存储和治理由独立、开放的湖格式承载，上层检索与服务引擎就可以独立演进和替换，数据所有权也会更加清晰。
Paimon 与 Milvus 的角色边界相对清楚。
Paimon 是湖底座，负责“存、管、治”。它正在把 Vector、Blob、Data Evolution 和 Global Index 等能力纳入湖内原生语义，让多模态数据在同一张表中得到持续写入、版本管理和统一治理。
Milvus 是检索与服务引擎，负责“检、服、扩”。它在 ANN、混合检索、标量过滤、分布式扩展和生产级低延迟服务方面已有深厚积累。
两者协同的重点，不是简单把两个系统重新拼接，而是通过标准接口和共享数据契约，让它们围绕同一份湖数据工作。
在这套架构中，Flink Streaming、CDC、批量回填和离线计算构成统一写入层；Paimon Table 保存向量、标量、Blob 和索引，并提供版本、治理与 Snapshot；Milvus External Collection 则在服务层提供 ANN、Hybrid Search 与 Filter。
它要解决三个核心问题：消除湖与向量数据库之间的主数据搬运；让计算围绕同一份数据发生；通过快照和 Refresh 机制维持服务侧数据新鲜度。
一句话概括，就是 One Data First，先建立共享数据平面。
两个系统能否共用一份数据，不能只看“接口是否连通”。我们可以用三层就绪度来判断。