Agent-Memory补上长视频记忆

openJiuwen给Agent补上长视频记忆

openJiuwen Agent-Memory近日上线多模态记忆能力OmniMem-Lens，试图解决Agent面对数小时视频时记不住、找不准、回答慢的问题。按照团队公布的测试结果，在搭配Qwen3-VL-8B后，OmniMem-Lens在三个长视频问答基准上的记忆召回精度均超过直接使用同一视觉语言模型处理视频的方案，其中EgoLife-QA提升45.7%，在线问答时延最高降低97%。

OmniMem-Lens是一个面向长视频的多模态记忆组件，其核心工作是先按真实事件组织视频内容，再把记忆分层存储并按问题检索。它不是一个新的视觉语言模型，也不是单纯扩大上下文窗口，而是在模型前面增加一套负责视频理解、索引和召回的记忆基础设施。

这项更新值得关注的原因，不是又多了一个视频摘要工具，而是它把长视频处理从「每次提问重新看视频」改成了「提前建记忆、提问时查记忆」。对于需要反复查询同一批录像的Agent应用，后者通常更接近可落地的工程路径。

固定一分钟切片，为什么会把事件切坏

固定时间切分是指按照30秒、60秒等预设窗口机械地拆分视频，再分别生成摘要或向量索引。这种方法实现简单，也容易并行计算，因此长期以来是长视频RAG系统最常见的基础方案。

固定切分的根本缺陷是时间边界不等于事件边界。一次产品演示可能从第55秒开始，到第80秒才结束；如果系统每60秒切一次，关键操作和操作结果会被放进两个记忆单元，检索时可能只召回其中一半。

长视频中的证据往往同时存在于声音和画面里。比如会议录像中，一名员工先说「最终采用B方案」，随后镜头切到投影屏幕展示预算数字；如果系统只按语音做摘要，就会丢掉预算，如果只检索画面，又可能不知道这个数字对应哪个方案。

视听双流记忆是指系统同时利用视觉变化与音频语义识别事件边界，并在记忆中保留两条信息流之间的对应关系。它与简单的「抽帧加语音转写」不同，重点不在于把两种输入都转成文本，而在于判断一次事件从哪里开始、在哪里结束，以及声音证据和视觉证据是否属于同一件事。

OmniMem-Lens的思路可以概括为两步：第一步用视听信息定位真实事件，避免按秒盲切；第二步为同一事件生成不同粒度的记忆，使Agent可以先粗定位，再按需要回看细节。这个设计更像给视频制作目录和索引，而不是把视频压缩成一篇不可追溯的摘要。

三层记忆不是三份重复摘要

分层记忆是指用不同信息密度保存同一段经历，让检索系统根据问题复杂度选择所需层级。OmniMem-Lens把视频记忆划分为L0、L1和L2三层，各层承担的任务并不相同。

| 记忆层级 | 保存内容 | 主要用途 | 成本与特点 | |---|---|---|---| | L0 | 原始视频帧及对应片段 | 核对人物、物体、动作、屏幕文字等视觉细节 | 信息最完整，但读取和推理成本最高 | | L1 | 视频或事件的高层概览 | 快速判断问题涉及哪一段、哪一类事件 | 类似书籍目录，范围粗但检索快 | | L2 | 更细粒度的事件描述与语义索引 | 定位具体行为、对话和事件关系 | 类似正文索引，适合大多数问答检索 |

L1和L2记忆会被文本化与向量化，因此可以接入常见向量数据库和现有RAG链路。对于已经使用向量检索、重排模型和Agent编排框架的开发团队，这意味着不必让视觉模型直接吞下整段视频，而是可以沿用「召回—重排—生成」的成熟结构。

L0则承担证据回查的角色。系统只有在问题确实依赖视觉细节时，才调取对应原始帧或短片段交给视觉语言模型确认，例如判断某人拿的是红色文件夹还是蓝色文件夹，或者读取监控画面中一块仪表盘的数值。

这种按需回看机制本质上是在做多模态版的延迟加载。网页不会在打开首页时加载数据库里的所有图片，视频Agent也没有必要在每次问答时重新处理数小时画面；先用轻量索引找到位置，再读取少量原始内容，才是更合理的资源分配方式。

三项测试均有提升，但45.7%最有解释力

openJiuwen团队使用Qwen3-VL-8B作为基础视觉语言模型，在Video-MME-L、LVBench和EgoLife-QA三个长视频问答数据集上进行了对比。对照方案是直接使用Qwen3-VL-8B处理视频内容，实验方案则是在同一模型基础上增加OmniMem-Lens记忆能力。

记忆召回精度是指系统能否从长视频记忆中找到回答问题所需的正确证据。它不完全等同于最终回答准确率，因为模型在召回正确片段后仍可能推理出错，但召回质量决定了后续模型有没有机会答对。

| 评测集 | 主要考察内容 | OmniMem-Lens相对直接使用Qwen3-VL-8B的提升 | |---|---|---:| | Video-MME-L | 通用长视频理解与跨片段问答 | 8% | | LVBench | 长视频内容理解、事件定位与推理 | 6.4% | | EgoLife-QA | 第一人称全天生活视频中的密集事件问答 | 45.7% |

EgoLife-QA上45.7%的提升最能说明事件化记忆的价值。第一人称生活视频通常没有稳定的镜头语言，做饭、取物、聊天、出门等事件连续发生，大量动作持续时间短且彼此交叠，机械切片很容易把「拿起物品—使用物品—放回物品」拆散。

Video-MME-L和LVBench的8%、6.4%提升则相对克制，但更接近通用长视频场景的真实收益。对于结构较清晰的视频，固定切分并非完全无效，因此改用事件边界后的提升不会总是达到数十个百分点；OmniMem-Lens的优势会随着视频长度、事件密度和跨模态证据比例增加而变得更明显。

上述数字仍需结合统计口径理解。现有公开信息给出了相对提升比例，但没有在同一张表中完整披露各方案的绝对分数、不同问题类型的拆分结果和置信区间，因此不能把「提升45.7%」直接理解为准确率增加45.7个百分点。

这组实验也不能证明OmniMem-Lens已经全面超过所有长视频理解系统。它能较清楚地说明，在基础模型同为Qwen3-VL-8B时，引入事件化分层记忆优于让模型直接处理视频；但要判断其行业位置，还需要与其他视频RAG、超长上下文VLM和专用视频检索系统进行统一条件下的横向测试。

97%的时延下降，来自把重活移到离线

在线问答时延是指用户提交问题后，到系统返回答案之间的等待时间。OmniMem-Lens报告的最高97%时延降幅，并不是让Qwen3-VL-8B本身推理速度提高了约33倍，而是通过改变计算发生的时间，把视频解析、事件切分和记忆构建提前到了离线阶段。

直接处理长视频的链路通常需要重新抽帧、编码图像、处理语音、填充上下文并执行推理。视频越长，视觉Token和预处理开销越高；用户换一个问题后，系统还可能重复读取大量相同内容。

OmniMem-Lens的在线链路更短：用户问题先与L1、L2记忆进行语义匹配，检索出少量相关事件，只有需要视觉核验时才访问L0。假设某一基线方案的在线等待时间记为100个单位，降低97%意味着实验方案只剩3个单位；这只是比例换算，并不代表官方测试的绝对时延为100秒和3秒。

| 方案 | 提问时处理范围 | 重复问答成本 | 在线时延 | 适合场景 | |---|---|---|---|---| | 直接使用VLM读取视频 | 可能重新处理大量帧和上下文 | 高 | 随视频长度明显增长 | 一次性短视频问答 | | 固定切片视频RAG | 检索预先切好的时间片 | 中 | 较低，但证据可能被切碎 | 结构稳定、事件较长的视频 | | OmniMem-Lens | 先查L1/L2，必要时读取L0 | 低 | 报告最高降低97% | 反复查询、事件密集的长视频 |

离线建库并没有消灭计算成本，而是把成本从用户等待阶段转移到了视频入库阶段。对于同一段视频只问一次的问题，提前构建复杂记忆未必划算；对于需要被数十次、数百次查询的会议库、监控库和培训资料库，索引成本则可以被持续摊薄。

真正的竞争对手不是更大的上下文窗口

OmniMem-Lens与超长上下文模型解决的是同一个表面问题，但采用了不同路线。超长上下文路线试图让模型一次看得更多，记忆系统路线则承认上下文始终昂贵，只把与当前问题有关的信息送进模型。

更大的上下文窗口不能自动带来更好的长视频理解。视频会产生远多于文本的Token，即使上下文容量足够，模型也可能在海量相似画面中出现注意力稀释，而推理成本和首Token等待时间仍会随输入增长。

分层检索同样不是没有代价。只要事件切分或记忆摘要发生错误，后续查询就可能根本找不到正确片段；如果L1把某个短暂动作遗漏，Agent甚至不会触发L0回看，这类错误比单次生成幻觉更隐蔽。

视听同步也会成为工程难点。现实视频中可能存在字幕延迟、旁白与画面错位、多人重叠说话和背景电视声，系统必须判断声音究竟描述当前画面、过去事件还是未来计划，否则所谓双流反而会制造错误关联。

最先受益的会是反复查询型视频应用

企业会议和培训资料是OmniMem-Lens最直接的应用方向。用户可以询问「预算争议发生在哪一段」「演示失败后谁提出了替代方案」，系统先定位事件，再返回时间点和证据片段，而不只是生成一份会议摘要。

工业巡检和安防复盘更依赖事件完整性。一次异常可能由设备声音变化、操作人员动作和仪表数值共同构成，按一分钟切片很可能拆散因果链；视听双流记忆则有机会把异常前兆、发生过程和处置结果组织为一个事件。

可穿戴设备和个人生活记录是技术收益最大、隐私风险也最高的场景。EgoLife-QA的提升说明这套方法适合第一人称视频，但L0层保存的原始画面可能包含人脸、住址、屏幕内容和旁人对话，部署方需要提供删除、访问审计、保留期限和细粒度权限控制。

Agent的视频记忆还需要可纠错机制。用户应当能够修改错误事件、合并重复记忆、删除敏感片段，并让L1、L2索引同步更新；否则记忆一旦写错，就可能在后续多轮任务中持续污染决策。

这次更新的价值在架构，不在跑分冠军

OmniMem-Lens最有价值的地方，是把长视频理解拆成了事件边界识别、分层记忆、在线检索和原始证据回查四个环节。这个架构比「把更多帧塞给更大的模型」复杂，但它更符合生产系统对成本、延迟、可追溯性和重复利用的要求。

97%的最高时延降幅也比单纯提高模型跑分更有现实意义。长视频Agent如果每次回答都要让用户等待数分钟，即使准确率不错也很难进入高频工作流；把响应压到可交互范围，才可能支撑连续追问和自动化任务。

现阶段仍不宜把OmniMem-Lens理解为已经解决了长视频记忆。公开结果尚缺少绝对时延、离线建库耗时、存储占用、长达数十小时视频的性能曲线，以及与更多视频记忆系统的统一对比，这些数据决定了它能否从演示走向规模化部署。

openJiuwen这次至少证明了一件事：Agent要真正理解长视频，关键不只是看过多少帧，而是能否把连续信号整理成事件、把事件沉淀为可检索记忆，并在需要时回到原始证据。对于正在搭建视频Agent的开发者，事件化切分和分层记忆比盲目追求更长上下文更值得优先验证。

参考来源

• openJiuwen Agent-Memory GitHub仓库：项目代码、版本更新、安装方式与开源状态的官方查询入口。
• 知乎：openJiuwen记忆与上下文引擎介绍：补充了解openJiuwen体系中的分层记忆、项目记忆和上下文管理设计。