在 2026 年 AICon 全球人工智能开发与应用大会上，火山引擎数智平台端侧记忆负责人马进分享了 Lance 的格式设计与实践。这场分享的关注点不只是一个新的数据湖格式，而是当企业数据开始同时服务模型训练、RAG 检索、Agent 记忆和上下文回放时，底层数据系统需要补齐哪些能力。
过去一年，多模态数据管理的难点正在从“能不能存下来”转向“能不能被反复复用”。智驾数据会同时包含摄像头图片、点云、雷达、传感器、标签和 embedding；内容理解场景会叠加文本、图片、音频、打分结果和实验版本；Agent 场景还会加入文档、对话、工具调用结果、检索日志和长期记忆。如果这些数据分散在对象存储、向量库、全文检索系统、训练格式和元数据库中，复用成本、一致性风险和链路复杂度都会迅速上升。
把索引和随机访问下沉到格式层
Lance 容易被误解成向量数据库，或者 Parquet、Iceberg 的替代品。但按照演讲中的定义，它更像一套面向 AI 数据底座的 lakehouse format stack。其底层是文件格式，用 column pages、offsets 和 footer 提供更适合随机访问的读路径；往上是表格式，用 fragments、versions 和 ACID 能力提供表级治理；再往上则是向量、全文和标量索引；Catalog 与 Namespace 负责表发现、协同和跨引擎接入。
这种分层设计的关键，在于把过去依赖外部系统完成的能力放到了格式层。随机点查、向量检索、全文检索、版本管理、分支实验和多引擎协同，不再只是外围组件的功能，而成为数据格式本身的一部分。Lance 与 LanceDB 的分工也由此展开：Lance 更偏底层湖格式与数据管理，服务企业级多模态数据底座；LanceDB 更偏轻量、开箱即用的本地向量检索和混合检索，降低 Agent 记忆和轻量检索场景的使用门槛。
演讲将多模态场景对湖存储的诉求总结为四类：大宽列、低成本结构变更、混合存储和随机点查。AI 数据表往往不只是几列结构化字段，智驾一帧数据包含几百列并不罕见，推荐和特征工程中的宽表也可能达到上万列。Lance 通过 Fragment 和 DataFile 的组织方式，让新增列可以作为新的 DataFile 附加到现有表结构中，而不必重写整个 Fragment。同时，它尝试把结构化字段、半结构化 JSON、非结构化对象和向量收敛到同一张可查询的数据表里，减少检索命中后再回对象存储取原文的长链路。
在文件格式层面，Lance 去掉了 Parquet 的 Row Group，并把 Data、Metadata 和 Footer 解耦。Parquet 的 Row Group 诞生于 HDFS 时代，用于在计算并发度和文件句柄数量之间做权衡；但在对象存储成为主流底座后，这种折中未必仍然最优。尤其在大宽表场景中，不同列大小差异极大，如果图像列、向量列和整型列被绑在同一个 Row Group，小列也可能承担额外 I/O 成本。Lance 的路径是先通过 footer 找到目标列的 column metadata，再定位目标行和数据页。分享中提到，在相关设计下，Lance 可以把随机读取路径压缩到 1 到 2 次 IOP，并在特定随机读取场景下相较 Parquet 带来数量级提升。
智驾与内容平台的两种落地方式
从发展路径看，Lance 的成熟并非单线推进。它从 2022 年开源起步，随后推出 LanceDB，并逐步形成多模态 Lakehouse 与 Lakehouse format stack 的定位。火山引擎从 2024 年开始围绕智驾、具身智能等多模态场景参与社区共建，并在 2025 年推进产品化和商业化落地。围绕 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、数据集、异构存储等能力。
智驾数据湖是一个典型场景。客户原本使用 KV 存储多模态数据，每行对应一帧，一帧包含几百列，大小约 20 MB。原方案使用 Python pickle 序列化，Schema 主要隐含在代码里，下游复用困难；数据实验和交付时需要不断复制；同时缺少有效压缩，在高性能存储上的成本压力明显。引入 Lance 后，原本散落在序列化对象中的摄像头、传感器、点云和标签数据被治理成一张大宽表。新增列、减少列或更换 embedding 算子，都可以在表结构层更自然地表达。分享中提到，在点云和图片等数据上引入压缩后，原始数据被压到约 30%，并帮助客户应对了当年超过 10 倍的数据体量增长。
另一个案例来自内容平台的数据清洗、去重和打分实验。此前，客户会在不同过滤、去重和打分规则下不断生成新的 Parquet 中间文件，导致中间表难管理、重复列多、成本高，也缺少清晰的数据处理时间线。引入 Lance 后，流程改为围绕主表、分支和 Tag 迭代：原始表清洗后形成加工表，冻结后拉出不同分支，分别增加不同打分列，验证效果后再打 Tag 发布。真正增量的数据主要是新增的打分列，历史数据能够被更充分复用。
Agent 记忆之外，更大的对象是上下文资产
演讲还讨论了 Lance 在 Agent 记忆场景中的应用。Agent 记忆通常会经历信息捕获、记录、切分、embedding、索引，再到后续任务中的召回等步骤。LanceDB 在这类场景中的优势是轻量和开箱即用，不依赖复杂的服务化引擎，就能基于磁盘提供向量检索和混合检索能力，适合 Agent 插件、个人记忆、团队知识库和上下文组件等低部署成本场景。
在 Openclaw Memory Plugin 的实践中，分享提到两条路线。一条偏企业知识和结构化沉淀，使用 Tag 实现毫秒级备份，使用 Branch 支持团队记忆，并增强混合检索与中文分词；另一条偏个人文档和偏好沉淀，利用模型更擅长编辑 Markdown 的特点，对记忆进行语义切分和整理。后者带来记忆捕获增强 30%、记忆召回准确率提升 20% 的效果。
不过，比“怎么存记忆”更值得注意的是，Memory 可能只是 Context 中高质量、个性化内容的提取结果。Context 包含文档、图片、视频、代码、历史决策、工具调用结果、检索日志以及跨会话引用关系，模态更多，规模更大，也更需要一套能同时管理对象、版本、索引和检索的数据底座。
从这个角度看，Lance 的价值并不是把所有数据系统统一成一种新格式，而是把 AI 流程中的关键能力下沉到格式层。随机访问、宽表加列、Blob 大对象管理、向量与全文索引、分支和 Tag、跨引擎协同，这些能力组合在一起，构成面向训练、检索、评测、打标和 Agent 记忆的统一数据底座。当数据主要服务报表和离线分析时，传统湖格式已经足够成熟；但当数据开始同时服务模型训练、样本回放、RAG 检索、多模态对象管理和 Agent 上下文复用时，数据底座需要新的抽象。
据现场信息，9 月 12 日将在上海举办 Lance & LanceDB 中文社区线下沙龙，LanceDB 核心成员将携手云厂商、芯片厂商和互联网企业技术专家，围绕多模态数据、具身智能、向量存储与开源生态展开交流。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/lance-ba-jian-suo-xun-lian-yu-agent-ji-yi-fang-jin-tong-yi
