在 2026 年 AICon 全球人工智能开发与应用大会现场，火山引擎数智平台端侧记忆负责人马进以"Lance:从多模态数据湖到 Agent 湖"为题，分享了 Lance 的格式设计与实践。
相比传统数据湖关注"怎么存、怎么查"，这次分享更进一步回答了一个问题：当企业数据开始服务模型训练、RAG 检索、Agent 记忆和上下文回放时，数据底座还需要具备什么能力？
以下内容摘自演讲实录。
AI 时代的数据，不再只服务一种系统
过去几年，企业的数据底座经历了两次明显变化。第一阶段，Hive 让越来越多的数据管道进入开源生态；第二阶段，Iceberg、Delta、Paimon 等湖格式把"格式"推到数据系统的核心位置。到了 AI 时代，新的问题又出现了：同一份数据，既要进入传统 ETL 和分析链路，又要喂给训练任务，还要支撑向量检索、全文检索、样本回放和 Agent 记忆。
例如，多模态场景的数据天然复杂。智驾数据里可能同时包含摄像头图片、点云、雷达、传感器、标签和 embedding；内容理解场景里可能同时包含文本、图片、音频、打分结果和实验版本；Agent 场景里则还会叠加文档、对话、工具调用结果、检索日志和长期记忆。数据一旦分散在对象存储、向量库、全文检索系统、训练格式和元数据库之间，复用成本、一致性风险和链路复杂度都会迅速上升。
这正是 Lance 想回答的问题：能不能用一套 AI-native 的湖格式，让训练、检索、分析和 Agent 记忆围绕同一份数据展开。
Lance 的定位：不是"又一个向量数据库"
理解 Lance 时，一个常见误区是把它简单看成向量数据库，或者看成 Parquet、Iceberg 的替代品。更准确的说法是，Lance 是一套面向 AI 数据底座的 lakehouse format stack。
它的底层是 File Format，用 column pages、offsets 和 footer 提供更适合随机访问的读路径；往上是 Table Format，用 fragments、versions 和 ACID 能力提供表级治理；Index Formats 负责向量、全文和标量索引；Catalog 与 Namespace 则承担表发现、协同和跨引擎接入。
这种分层设计的关键意义在于，Lance 把很多原本依赖外部系统完成的能力，下沉到了格式层本身。随机点查、向量检索、全文检索、版本管理、分支实验和多引擎协同，不再只是外围能力，而被设计成数据格式的一部分。
这也是 Lance 与 LanceDB 同时存在的原因。Lance 更偏底层湖格式与数据管理，LanceDB 则更偏轻量、开箱即用的本地向量检索和混合检索能力。前者服务企业级多模态数据底座，后者则降低了 Agent 记忆和轻量检索场景的使用门槛。
从发展路径看，Lance 的成熟并不是单线推进，而是开源格式演进与生产场景验证并行发生。一方面，Lance 从 2022 年开源起步，随后推出 LanceDB，并逐步形成多模态 Lakehouse 与 Lakehouse format stack 的定位；另一方面，火山引擎也从 2024 年开始围绕智驾、具身智能等多模态场景参与社区共建，并在 2025 年推进产品化和商业化落地。两条线共同推动 Lance 从一个新兴格式，走向可承载 AI 数据湖底座的生产级方案。
Lance & LanceDB 中文社区 · 上海站线下沙龙
还想了解更多AI基础设施落地实践，可关注 9 月 12 日在上海举办的 Lance & LanceDB 中文社区 · 上海站线下沙龙。届时，LanceDB 核心成员将携手一线云厂商、芯片厂商与互联网企业技术专家，围绕多模态数据、具身智能、向量存储与开源生态，与你面对面畅聊技术实践。详见硬核议题+社区交流+精美伴手礼｜Lance Meetup 2026 · 上海站火热报名中
也可扫描下方二维码，填写报名表单名额有限，先到先得～
为什么多模态数据湖需要新格式？
在这次分享里，多模态场景对湖存储的诉求被总结为四类：大宽列、低成本结构变更、混合存储和随机点查。这四个词看上去抽象，但其实分别对应了 AI 数据处理里最常见的四类痛点。
第一，是大宽列。AI 数据不再只是几列结构化字段，而是会把图片、视频、点云、传感器、标签、embedding 和模型打分放进同一张表。智驾一帧数据包含几百列并不稀奇，推荐和特征工程里一张表上万列特征也不罕见。此时，如果底层格式仍然按传统 Row Group 去组织，宽表和大对象的访问路径就会变得很重。
第二，是低成本结构变更。AI 数据生产天然处于持续演进中。新增一个标签、替换一种 embedding 算子、增加一列特征，都是日常动作。如果每一次加列都要重写历史文件，工程成本会被迅速放大。Lance 通过 Fragment 和 DataFile 的组织方式，让新增列可以作为新的 DataFile 直接附加到现有表结构中，而不需要重写整个 Fragment。
第三，是混合存储。很多传统方案里，向量库只存向量和少量文本，原始图片、视频或点云还留在对象存储；检索命中后，再回对象存储拿原始对象。这样虽然能工作，但链路长、系统多，也更容易带来一致性与治理问题。Lance 试图把结构化字段、半结构化 JSON、非结构化对象和向量收敛到同一张可查询的数据表里。
第四，是随机点查。无论是训练中的 shuffle、样本回放，还是检索命中后的精排和原文取回，本质上都要求系统能稳定、低成本地读到特定行。分享中提到，在相关设计下，Lance 可以把随机读取路径压缩到 1 到 2 次 IOP，并在特定随机读取场景下相较 Parquet 带来数量级提升。
File Format 的关键变化：去掉 Row Group，让访问路径更直接
Lance 的一个标志性设计，是在 File Format 层去掉 Row Group，并把 Data、Metadata 和 Footer 解耦。这个变化看起来底层，但其实正对应了 AI 数据访问模式的变化。
Parquet 的 Row Group 设计诞生于 HDFS 时代，当时系统需要在计算并发度和文件句柄数量之间做权衡，因此 Row Group 是合理折中。但当对象存储成为数据湖主流底座后，这种折中未必还是最优。
在多模态宽表场景中，Row Group 会暴露两个问题。其一，不同列大小差异极大，一个图像列或向量列可能非常大，而一个整型列非常小，如果它们被绑在同一个 Row Group，小列也会承担额外 I/O 成本。其二，当系统只想读取某一列时，仍可能需要加载与其他列相关的元数据；如果表里有上万列特征，这部分元数据成本并不小。
Lance 的路径更直接：先通过 footer 找到目标列的 column metadata，再由 column metadata 定位目标行和数据页。对于大对象，它还通过 Blob V2 提供更适合多模态对象的托管方式，让大 Blob 可以被更自然地引用、追踪、懒加载和流式读取。
Lance 与 Parquet、Iceberg 的关系：不是替代，而是补位
从定位上看，Lance 并不是为了替代 Iceberg 或 Parquet 而出现。Parquet 仍然是通用列式文件格式的事实标准，Iceberg、Delta、Paimon 更擅长快照、事务、演进和多引擎治理；这些能力在结构化分析场景里依然非常成熟。
Lance 的差异化，在于把 AI workload 需要的随机访问、多模态对象、向量与全文索引、频繁加列和跨场景复用，作为一等能力来设计。对于纯结构化分析任务，传统湖格式依旧合适；当数据开始进入训练、检索、评测、打标和 Agent 记忆等 AI 流程，Lance 的价值才会显现出来。
换句话说，它更像是为 AI 数据底座补上一层能力，而不是把所有已有格式"一刀切"替换掉。在实际 pipeline 里，结构化数据仍然可以在上游通过 Iceberg 等格式治理，再通过 Spark、Ray、Daft 等引擎加工成 Lance 表，服务下游 AI 任务。
火山实践：从社区共建到生产场景落地
火山引擎对 Lance 的投入，并不是停留在格式适配层，而是在真实生产场景里把它往产品化和商业化能力推进。从 2024 年开始，火山引擎围绕 Table Format、性能、索引、计算引擎生态、SQL 能力和商业化特性持续增强，并与社区共建。
这些增强包括 Branch、Transaction Commit Message、CDC、时空类型、Take API 优化、FragmentSession API、分布式 FTS Index、分布式 Vector Index、JSON 类型全文检索、Java SDK、Spark Connector、Ray Connector、Daft Connector，以及 LAS Catalog、数据集、异构存储等能力。
如果把这些能力连起来看，它们最终服务的是一套更完整的多模态数据湖架构：底层由对象存储、高性能文件存储和 Lance 格式承载数据，中间通过 Spark、Ray、Daft 等计算引擎完成数据加工、特征生成、索引构建和样本治理，上层再面向训练、检索、评测和打标提供统一访问。
这说明，火山引擎看重的不是 Lance 作为一个"新格式"的噱头，而是它是否有机会成为 AI 数据流程里的统一接口。
两个真实场景，让实验、训练和检索围绕同一份数据协同发声
第一个典型场景是智驾数据湖。客户原本使用 KV 存储多模态数据，每行对应一帧，一帧包含几百列，大小约 20 MB。原方案使用 Python pickle 序列化，Schema 主要隐含在代码里，下游复用困难；数据实验和交付时需要不断复制；同时缺少有效压缩，在高性能存储上的成本压力明显。
引入 Lance 后，原本散落在序列化对象中的摄像头、传感器、点云和标签数据被治理成一张大宽表。新增列、减少列或更换 embedding 算子，都可以在表结构层更自然地表达。分享中提到，在点云和图片等数据上引入压缩后，原始数据被压到约 30 %，并帮助客户应对了当年超过 10 倍的数据体量增长。
第二个场景来自内容平台的数据清洗、去重和打分实验。原先客户会在不同过滤、去重和打分规则下不断生成新的 Parquet 中间文件，导致中间表难管理、重复列多、成本高，也缺少清晰的数据处理时间线。引入 Lance 后，流程改为围绕主表、分支和 Tag 迭代：原始表清洗后形成加工表，冻结后拉出不同分支，分别增加不同打分列，验证效果后再打 Tag 发布。真正增量的数据主要是新增的打分列，历史数据能够被更充分复用。
从记忆到上下文：Agent 场景可能是更大的机会
除了多模态数据湖，本次分享中还讨论了 Lance 在 Agent 记忆场景中的应用。Agent 记忆一般会经历几个步骤：模型从对话和操作中捕获重要信息，把它记录到 Markdown 或向量数据库，再进行切分、embedding 和索引，最后在后续任务中通过 search 或 get 召回。
LanceDB 在这类场景中受欢迎，核心原因是轻量和开箱即用。它不依赖复杂的服务化引擎，就能基于磁盘提供向量检索和混合检索能力。这对 Agent 插件、个人记忆、团队知识库和上下文组件来说尤其重要，因为这些场景往往需要低部署成本和低使用门槛。
在 Openclaw Memory Plugin 的实践中，分享提到了两条路线。一条偏企业知识和结构化沉淀，使用 Tag 实现毫秒级备份，使用 Branch 支持团队记忆，并增强混合检索与中文分词；另一条偏个人文档和偏好沉淀，利用模型更擅长编辑 Markdown 的特点，对记忆进行语义切分和整理。分享中提到，后者带来记忆捕获增强 30 %、记忆召回准确率提升 20% 的效果。
但更值得注意的，不只是"怎么存记忆"，而是 Memory 本身可能只是 Context 中高质量、个性化内容的提取结果。Context 才是更大的资产，因为它包含文档、图片、视频、代码、历史决策、工具调用结果、检索日志以及跨会话引用关系。它比记忆更大、模态更多，也更需要一套能同时管理对象、版本、索引和检索的数据底座。
从这个角度看，"从多模态数据湖到 Agent 湖"真正指向的，也许不是一个更时髦的概念，而是企业数据底座下一步演化的方向：从管理训练数据，走向管理上下文资产。
Lance 的价值，不在于把所有数据系统统一成一种新格式，而在于把 AI 流程中的关键能力下沉到格式层。随机访问、宽表加列、Blob 大对象管理、向量与全文索引、分支和 Tag、跨引擎协同，这些能力组合在一起，才构成面向训练、检索、评测、打标和 Agent 记忆的统一数据底座。
当数据主要服务报表和离线分析时，传统湖格式已经足够成熟；但当数据开始同时服务模型训练、样本回放、RAG 检索、多模态对象管理和 Agent 上下文复用时，数据底座需要新的抽象。Lance 试图给出的答案是：让格式不再只是存储规范，而成为 AI 数据流转、治理和检索的共同接口。
AI 时代的数据不只是被保存下来，更要被反复检索、组合、训练、回放和进化。谁能更高效地管理这些数据，谁就更接近下一代 AI 应用的底层基础设施。