多模态 Agent 的记忆系统，过去很容易被理解成一个升级版 RAG：图片、图表、PDF 进来之后，先抽取内容、做 embedding、写进向量库；用户提问时，再用 query 做检索，把命中的top-k图片、文档页或图表一并塞进上下文，再交给多模态模型回答。整个过程中，所有原始模态信息都会不加选择的塞给大模型。这个思路在系统复杂度低的时候，问题不大。但记忆累积到几十个会话、上千个文件之后，失败概率就会直线上升。有时候，是因为系统“召回了太多证据”，导致需要的原图已经在上下文里，但却被一堆语义相近但无关的图片淹没；有时候，则单纯是一些只需要读文字摘要就能回答的问题，系统仍然把原始图片或 PDF 页面渲染进 prompt，白白消耗 token。如果你也有类似困扰，这篇多模态记忆 benchmark 的论文（M3 Exam，arXiv 2606.07402），或许可以给你带来一些启发。01 多模态 Agent记忆，不需要反复看图
与传统的单次视觉理解不同，M3 Exam 论文会更加关注长期多模态记忆。举个例子来帮助我们理解其中区别：单次视觉理解：“这张图片里有什么？”“这张图表最高值是多少？”“这页 PDF 讲了什么？”长期多模态记忆：我之前上传的那份报告里，哪一页能解释这张图？这张照片和我上次提到的训练材料有什么关系？单次视觉理解中，读取原始模态信息的存在是必要的，但在长期的多模态 Agent 记忆中随着多模态信息总量增加还是这么做，就会导致决定性证据被无关视觉内容淹没，以及单次查询 token 预算被抬高。比如一张图表，如果坐标轴、数据系列、关键数值已经被转写成文字，模型可能读文本就能回答。一份 PDF，如果文本层和页面摘要已经可用，很多问题根本不需要重新渲染页面。一张图片，如果问题只问明显对象、场景或描述性信息，caption 也可能够用。当然，也有一类问题必须回到原始视觉源。比如图片里的细微视觉差异、图表布局、截图中的空间关系、文档页面中的视觉结构。这些信息很难被简单 caption 完整替代。02 M3 Proctor：把图变成可检索的文本
M3 Proctor 把是否需要看原图变成了一个显式决策。第一步是在索引阶段为原始多模态内容生成文本代理（textual surrogate）。图片配 caption；图表、表格这类信息密集的视觉内容，额外生成包含坐标轴、数据系列和具体数值的转写；文档页则保留文本层，并加上一句摘要。这样，原本只能靠视觉模型读取的内容，就可以变成普通文本检索器可以命中的代理表示。光有文本代理还不够，每个 chunk 还需要挂一个模态标签（modality tag），标记它对应图片、文档还是图表。M3 Proctor 还为每个 session 增加 session-summary chunk，相当于一份压缩的小时间线，保留跨会话信号，避免跨会话的线索被按轮（round）切碎。第二步是“成本感知级联（cost-aware cascade）”，分为三个阶段：第一阶段是模态偏置检测：用一次指令调优的 LLM 调用，判断这道题到底依赖哪种模态，输出一个二值向量，结果缓存起来。第二阶段是模态感知重排：密集检索只按语义相似度排序，可能把“持有决定性图片、但跟 query 只是中等相似”的那条压下去，于是用模态偏置去校正候选池内的排序，让对的模态浮上来——注意这一步只动 top-k 的模态构成，不会把无关 chunk 提上来，也完全在索引时的标签和代理上操作，不碰原始源。第三阶段才是级联本身。系统先只用文本代理回答。如果置信度足够，流程就结束；如果文本答案不可靠，或者模态偏置明确显示这题需要原始视觉源，系统才进入第二阶段，把对应的原图、图表或文档页补进上下文。论文把这个机制称为 cost-aware modality cascading：先使用足够便宜的表示，只有不够时才为更贵的表示付费。论文报告称，级联只在该升级的场景才触发：在文件管理（fm）上触发率 68.0%、多模态推理（mr）上 51.1%，而纯文本类问题都在 15% 以下。整体只有 26.4% 的 query 会升级到读原图。成本上，M3 Proctor 建索引 需要72 秒、每 query 需要4591 token；而多模态基线如 MIRIX 要 43271 秒建索引、NGM 每 query 要 26988 token，差出一到三个数量级。综合下来，M3 Proctor 相比现有系统准确率提升约 13%、token 少约 70%、索引构建时间少约 80%。需要说明的是，这些数字来自论文在自己 benchmark 上的评测，条件限定在 M3 Exam 内，不能直接外推到所有生产环境模态感知。03M3 Proctor+Milvus 3.0 ，如何搭建更好的多模态 Agent 记忆
很多人会把这件事放在 Agent 编排层处理：加一个 router，加一个判断模型，加一个 reranker。这样当然可以起步，但如果底层存储不支持对应的数据组织方式，系统很快会变复杂。第一，同一条记忆要能挂多种表示。文本代理、视觉 embedding、图表转写、文档页面摘要，最好围绕同一个 memory entity 管理，而不是拆散后再在业务层拼接。Milvus 3.0 引入的EmbList正好可以承接这个需求：它支持把一个实体（如一篇文档、一张图片）的多个向量片段（文本代理 embedding、原始视觉 embedding、图表转写 embedding ）打包存在一条记录里，并在搜索时直接对整个列表做 late interaction。这样，Stage 1 可以走文本代理路径，Stage 2 再按需走原始模态路径。第二，检索时要能利用 metadata。让模态过滤应该尽可能发生在候选进入上下文之前，也就是让modality tag、session_id、user_id、file_type、created_at 这些字段决定候选范围。这里推荐使用Milvus 的标签过滤能力，我们可以把模态标签作为标量字段存进 Milvus，检索时用过滤表达式可以直接约束候选范围。配合 partition key 或 metadata filter，还能把不同 persona、不同 session 的记忆隔离，避免跨用户记忆互相污染，这正好对应 M3 Exam 里 15 种 persona 各自独立管理的隔离需求。第三，系统要能接受异步补齐。多模态 pipeline 往往不是同步完成的：图的文字描述（caption）可以在图传入时立刻生成，OCR 和图表解析稍后完成，视觉 embedding 更晚才就绪。存储层需要允许一条记忆先以部分表示参与检索，再逐步补齐其他表示。Milvus 3.0 的可空向量字段（nullable vector）支持记忆条目在视觉 embedding 还不存在时先写入，文本代理字段照常参与检索；等视觉 embedding 就绪，补填进来即可。不需要等待两路同时完成才能写入，也不会因为视觉字段为空而影响文本路径的召回。第四，读取应该是列级或字段级的。Stage 1 只需要文本代理，就不该把原始视觉内容也读出来；Stage 2 触发升级时，再读取 raw source。否则上层虽然做了 cascade，底层成本仍然没省下来。Milvus 3.0 的存储引擎Storage V3重构了数据的组织方式：数据可以以列存格式落在 S3 兼容的对象存储上，每个版本状态由一份不可变的 Manifest 快照（Avro 编码）捕获，读取时只拉需要的列，不读整行。尾声
按需取图不是所有系统都需要。只有用户出现图片、图表、PDF 会跨多个 session 长期积累；问题经常需要在旧文件和新对话之间建立联系时才需要，典型场景包括：法律、医疗、教育等等。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
