1. 项目概述长程多模态搜索的挑战与破局在AI智能体领域让模型像人一样通过主动搜索、浏览网页来获取信息并解决复杂问题正成为一个关键的研究方向。早期的深度搜索智能体主要处理文本但随着多模态大语言模型MLLMs的崛起我们自然希望它们也能处理“看图说话”的任务——比如给你一张古董钟表的局部特写让你找出它的生产年份和设计师。这听起来很酷但实际操作起来却面临一个巨大的工程瓶颈上下文爆炸。想象一下你让一个智能体去网上搜索“文艺复兴时期绘画中的狗”。它可能会打开十几个网页每个网页都包含大量文字和数张高清图片。如果按照传统方式把这些原始图片数据经过编码后是海量的视觉Token和文本一起塞进模型的上下文窗口那么可能仅仅搜索两三轮上下文长度就会爆掉导致后续的推理无法进行。更糟糕的是为了节省空间一些现有方案会选择性地丢弃中间过程的图片但这又可能丢失掉后续推理所依赖的关键视觉线索比如某张图片角落里的一行小字签名。LMM-Searcher正是为了解决这个核心矛盾而诞生的。它的核心思想非常巧妙借鉴了人类处理信息的直觉我们不会在脑子里记住整本百科全书的高清插图但我们记得“在某某网站的第三篇文章里有一张图展示了这个结构”。基于此LMM-Searcher 提出了一套“基于文件系统的视觉表示”机制。简单说就是把所有搜索过程中遇到的图片都像保存文件一样存储到外部的文件系统或对象存储中并在模型的对话上下文中用一串轻量级的、唯一的文本标识符UID比如一个URL或哈希值来“代表”这张图。只有当智能体明确需要仔细查看某张图的细节时它才会通过一个专用的工具如fetch_image去“按需加载”那张图的原文件。这种方法的价值在于它实现了“感知”与“推理”的解耦。模型的“工作内存”上下文始终保持轻量只处理文本和UID从而可以支持长达数十轮甚至上百轮的复杂交互长程交互。而高成本的、精细的视觉感知则被推迟到真正需要的时候才发生。这对于需要多跳推理的复杂任务至关重要——例如先搜索“某种稀有花卉”在结果中找到一个相关的公园再搜索该公园的雕塑最后识别雕塑中人物手持的物品。整个链条可能涉及多次视觉信息的回溯与比对LMM-Searcher 的架构为此提供了可持续的支撑。2. 核心架构设计文件系统与渐进式感知工作流LMM-Searcher 不是一个简单的模型而是一个完整的智能体框架。它的设计紧密围绕“如何高效管理长程、多模态的搜索上下文”这一目标展开。整个架构可以看作由三个核心部分组成一个负责存储和索引的文件系统后端一套为智能体量身定制的扩展工具接口以及一个驱动智能体行为的渐进式搜索工作流。2.1 文件系统的视觉数据管理从“嵌入”到“引用”传统多模态模型处理网络内容时通常会将网页中的图片解码后直接嵌入到上下文中。LMM-Searcher 改变了这一范式其数据处理流程更像一个智能的中间件。工作流程如下原始内容拦截当智能体调用google_search或scrape_website工具时环境例如浏览器模拟器返回的是一个包含原始文本和图片二进制数据的混合文档D。视觉资产索引化在D进入智能体的上下文之前LMM-Searcher 的框架会拦截这个文档。它会自动识别并提取其中所有的图片{i1, i2, ..., in}。持久化存储与UID映射每一张图片i都会被保存到一个持久化的外部文件系统中可以是本地磁盘也可以是云存储。系统会为每张图片生成一个全局唯一的文本标识符u f(i)。这个f就是映射函数。在实践中如果图片本身来自网络且已有唯一URL那么直接使用该URL作为UID是最佳选择避免了重复存储。如果没有则生成一个唯一的哈希值如SpU3Dt46.png作为文件名和UID。文档序列化原始文档D中的每张图片都被替换为其对应的UID。同时图片的替代文本alt text或从上下文中提取的简短描述caption会作为元数据保留。最终智能体收到的上下文是一个“轻量化”的文档文本部分被可能被摘要而所有图片都变成了类似[Image: https://example.com/image1.jpg, Caption: A bronze sculpture in the garden]这样的文本引用。注意确保UID与图片文件的映射是严格一对一且持久不变的这是整个系统可靠性的基石。任何映射错误或文件丢失都会导致后续的fetch_image工具调用失败使智能体“失明”。这个设计的优势是显而易见的。假设一个网页有5张1MB的图片编码成视觉Token可能需要数万个Token。而替换为UID和简短描述后可能只需要几十个Token。这为长程对话腾出了巨大的空间。2.2 扩展的智能体工具接口从“贪婪加载”到“按需索取”为了配合上述文件系统表示法LMM-Searcher 重新设计并扩展了智能体的工具集。其工具设计哲学是“渐进式加载”形成了一个从粗到细的感知漏斗。工具分为三大类1. 搜索工具获取信息的入口google_search(query): 执行文本搜索返回包含文本摘要、相关图片链接UID和网页URL的搜索结果列表。image_search(query): 执行以图搜图或基于文本的图片搜索直接返回图片结果同样以UID形式表示。visual_search(image_uid): 给定一张图片的UID搜索视觉上相似的内容。2. 浏览工具获取细节与主动感知scrape_website(url): 抓取并解析指定URL的网页内容。核心功能是摘要文本和提取并索引该页面所有图片。它返回给智能体的是文本摘要和图片UID列表而非原始图片数据。fetch_image(image_uid):这是实现主动感知的关键工具。当智能体从上下文的描述中判断需要对某张图片进行细粒度观察时例如“查看第三张图中人物手里拿的是什么”它调用此工具传入图片的UID。工具会从文件系统中定位并加载对应的原始图片将其送入模型的视觉编码器让模型“看到”高清原图。3. 视觉处理工具精细操作zoom_in(image_uid, region): 给定一张图片的UID和一个区域描述如坐标或文本描述工具会从文件系统加载原图对指定区域进行放大处理生成一张新的高分辨率细节图。这张新图又会被保存到文件系统并分配一个新的UID同时这个新UID和图片会被加载到上下文中供智能体继续分析。这套工具接口的核心在于fetch_image。它将视觉感知从被动的、一次性的“加载即遗忘”变成了主动的、可计划的“按需调用”。智能体需要学会在何时、基于何种文本线索去主动调用这个工具这是训练的关键目标之一。2.3 长程多模态搜索工作流模拟人类的信息获取模式结合以上两部分智能体的完整工作流模拟了人类的研究过程规划与粗筛智能体根据用户问题规划搜索策略调用google_search或image_search获取初步结果列表文本摘要图片UID。浏览与摘要智能体选择最有希望的网页链接调用scrape_website。它得到的是该页面的文本精华和所有图片的“索引”UID。推理与决策智能体在纯文本和UID构成的轻量级上下文中进行推理。例如它可能读到“根据摘要A公园有一座‘双犬’青铜雕塑图片UID:img_123。”主动感知如果问题需要确认雕塑细节如“人物手里拿着什么”智能体决定调用fetch_image(‘img_123’)。此时高清的雕塑图片被加载智能体进行细粒度视觉识别。迭代与回溯智能体可能基于新发现的视觉信息发起新一轮的搜索例如搜索识别出的物品名称然后重复步骤1-4。由于所有历史图片都以UID形式保存在上下文中智能体可以随时通过fetch_image回溯查看实现真正的多跳、长程推理。这个工作流天然保证了信息不丢失。UID就像一个永久的书签只要推理链中保留了它原始的视觉证据就随时可查克服了启发式丢弃策略的弊端。3. 智能体训练从数据合成到模型微调拥有一个强大的框架还需要一个懂得如何使用这个框架的智能体。训练一个擅长长程多模态搜索的智能体最大的难点在于缺乏高质量的、需要复杂跨模态推理的训练数据。现有的数据集往往只在第一跳涉及图像后续推理仍以文本为主这无法训练出智能体主动、反复查阅视觉信息的能力。3.1 构建需要“深读”的查询多模态网页问答合成LMM-Searcher 提出了一套自动化的数据合成流水线其目标是生成那些必须通过仔细阅读多模态网页内容才能回答的问题。流程拆解如下种子网页获取从富含图文信息的网站如新闻、影视、百科站点抓取原始网页W。核心实体与关联图像提取使用一个现成的MLLM如Qwen-VL分析网页提取出页面的核心实体E例如“《珀西·杰克逊》第二季第八集”和与这个实体直接相关的关键图像I_E例如该剧集的一张宣传海报。关键要求是E必须明确无歧义I_E必须有直接的图文关联。单跳视觉问题合成基于网页W、实体E和图像I_E让MLLM合成一个必须看到图像I_E才能回答的视觉问题q0。例如针对海报图问题可能是“海报中主角右手握着的武器是什么”。同时合成一个线索该线索提及E和I_E的关系但不直接给出答案例如“在关于E的某篇文章中有一张图I_E展示了...”。多跳推理链扩展为了让问题更复杂需要引入多跳推理。知识图谱构建以核心实体E为起点让LLM模拟搜索和联想迭代式地构建一个多跳知识图谱G。例如从“《珀西·杰克逊》”联想到“作者雷克·莱尔顿”再联想到“他另一部作品《埃及守护神》”。图谱模糊化为了阻止模型走捷径对图谱中一些非关键的中间节点进行“模糊化”处理。例如不直接说“作者雷克·莱尔顿”而是说“一位出生于1964年的美国奇幻文学作家”。多跳问题合成从图谱G中采样一条包含模糊节点的路径将其转化为一段自然的背景叙述然后与之前合成的单跳视觉问题q0结合形成最终的多跳视觉问题q。例如“一位出生于1964年的美国奇幻文学作家创作了一个关于希腊混血半神的系列小说在该系列第二季第八集的海报图I_E中主角右手握着的武器是什么”通过这个流程合成的问题强迫智能体必须遵循“线索→搜索→浏览→发现图像UID→主动获取图像→解答”的完整链条完美契合了训练目标。3.2 轨迹合成与模型训练有了合成的高难度查询下一步是生成智能体解决这些查询的“示范动作”即轨迹数据。数据混合与过滤将自行合成的查询与开源的多模态搜索数据集如FVQA、LiveVQA混合。首先用一个较小的VLM如Qwen2.5-VL-7B进行初筛过滤掉那些不调用搜索引擎也能直接回答的简单问题。教师模型轨迹采样使用一个强大的“教师模型”如 Seed-1.8在LMM-Searcher框架中实际运行这些查询让其自主调用工具进行搜索、浏览、查看图片直到得出答案。这个过程称为“轨迹推演”。高质量轨迹筛选只保留那些在最多40轮交互内成功解决问题的轨迹。最终我们收集了约1.2万条高质量的多轮交互轨迹作为训练数据。统计显示这批数据平均交互轮次17.26轮显著高于传统数据集且调用fetch_image等视觉工具的比例更高说明其“长程”和“深读”特性更强。模型训练与融合监督微调使用上述轨迹数据对一个强大的开源MLLM如 Qwen3-VL-30B-A3B-Thinking进行多轮指令微调。训练时损失函数只计算智能体的推理链和工具调用部分而屏蔽掉工具返回的结果因为这部分是环境给定的。能力融合纯多模态搜索轨迹的交互轮次和复杂度相比纯文本搜索仍有差距。为了进一步提升模型的长程规划和搜索决策能力借鉴模型融合的思想将微调后的多模态模型与一个在纯文本深度搜索上表现优异的模型如 MiroThinker-1.7-mini进行参数插值融合。具体来说对两者共享的语言模型部分进行加权融合例如Θ_final 0.8 * Θ_V 0.2 * Θ_T。这样能在保留视觉能力的同时注入更强的文本搜索推理能力。4. 实战效果与深度分析经过上述框架设计和训练流程LMM-Searcher 智能体的性能如何我们通过在多个权威基准测试上的实验来进行验证。4.1 基准测试与性能对比我们在四个具有挑战性的多模态搜索基准上进行了评估MM-BrowseComp (MMBC) 需要浏览复杂网页并理解图文内容来回答的竞赛式基准。MMSearch-Plus 增强版的多模态搜索基准包含需要多跳推理的复杂问题。VisBrowse 侧重于视觉网页浏览的任务。MMSearch 经典的多模态搜索基准。我们将 LMM-Searcher 与三类基线方法对比直接回答模型仅凭内部知识生成答案不使用任何工具。智能体工作流将相同的基座模型如GPT-5、Seed-1.8接入我们的框架或前人的框架。专用多模态搜索智能体其他团队发布的、专门为搜索训练的多模态智能体模型。核心结论如下表所示模型类型模型名称MMBCMMSearchVisBrowseMMSearch平均直接回答GPT-510.319.126.033.322.2Qwen3-VL-30B (基座)7.12.713.017.710.1智能体工作流GPT-5 我们的框架36.534.835.572.244.8Seed-1.8 我们的框架35.146.758.073.253.3Qwen3-VL-30B 我们的框架9.814.416.062.025.6专用多模态搜索智能体REDSearcher-MM-30B23.526.6-72.9-LMM-Searcher-30B (Ours)22.332.942.071.042.1LMM-Searcher-30B (100轮)30.134.848.372.346.4注表中数值为成功率%越高越好。100轮指启用上下文管理策略允许最多100轮交互。关键发现工具使用的必要性所有模型的“直接回答”性能都远低于使用智能体工作流的版本这印证了对于复杂开放域问题外部搜索工具是不可或缺的。框架的通用优势将同一个基座模型如GPT-5, Seed-1.8分别放入前人框架和我们的框架中我们的框架带来了显著的、一致的性能提升。特别是对于能力更强的模型如Seed-1.8在MMSearch-Plus和MMBC上的提升分别达到35.7%和13.7%。这证明了我们“文件系统按需加载”的上下文管理机制的有效性。模型本身的竞争力我们训练得到的专用模型LMM-Searcher-30B在多数基准上达到了开源模型中的领先水平。尤其是在最考验长程交互的MM-BrowseComp和MMSearch-Plus上表现突出。长程扩展能力当我们将最大交互轮次从通常的30轮放宽到100轮并启用上下文管理仅保留最近5次工具调用结果以控制上下文长度时LMM-Searcher-30B 在所有基准上均取得了进一步的性能提升。这在MM-BrowseComp上从22.3提升至30.1提升幅度超过35%强有力地证明了我们的方法能够有效支持并受益于更长的推理链条。4.2 深入分析工具调用与交互扩展工具调用分布我们对训练数据中智能体调用工具的类型进行了统计。如下图所示与我们合成的数据相比现有数据集如FVQA的轨迹中visual_search视觉搜索和fetch_image获取图像的调用比例要低得多。我们的数据则要求智能体更频繁地进行视觉搜索和主动的图像获取这反映了我们合成查询的“深读”特性迫使模型必须与视觉内容进行深度交互而非浅层检索。交互扩展曲线我们测试了在不同最大轮次限制下模型成功率的变化。结果显示在MMBC和VisBrowse这类需要深度浏览和理解的任务上即使将轮次上限增加到100模型的性能仍在持续增长尚未达到平台期。这表明对于真正的复杂多模态搜索任务提供足够的“思考时间”和交互空间至关重要而我们的框架正为此提供了可能。4.3 实操心得与避坑指南在实际复现或应用类似思想时有以下几点经验值得分享UID设计的稳健性使用URL作为UID是最直接的方式但需考虑URL可能失效或重定向。对于自托管的图片生成基于内容哈希如SHA-256的UID更为可靠能保证内容不变则UID不变避免重复存储。文件系统的选择对于研究原型本地文件系统即可。但对于需要高并发、持久化的生产环境建议使用对象存储服务如AWS S3、阿里云OSS并将UID设计为对应的对象键Key。同时要考虑设置生命周期策略清理长期未使用的临时图片控制成本。fetch_image的触发逻辑训练这是训练中的难点。智能体必须学会从文本线索如“查看图3中右下角的标志”中准确解析出需要调用fetch_image的意图。在合成数据时要有意识地构造大量需要此步骤才能解答的问题并在轨迹中明确展示这一调用。上下文窗口的管理策略尽管UID很轻量但上百轮的交互后纯文本的对话历史也会增长。除了保留最近N轮结果还可以探索更复杂的策略如对历史文本进行增量摘要将更早的详细观察总结为精炼的事实断言从而进一步压缩上下文。错误处理与鲁棒性在实际部署中fetch_image可能因网络超时、文件丢失等原因失败。框架需要设计重试机制并为智能体提供清晰的错误反馈如“无法加载图片UID: xxx”使其能调整策略例如尝试重新搜索或寻找替代图片。LMM-Searcher 为我们展示了一条清晰的路径通过将重型感知与轻型推理解耦利用外部存储和智能的上下文管理多模态智能体完全可以胜任需要长时间、多步骤探索的复杂任务。这套范式不仅适用于搜索对于需要长期记忆和复杂环境交互的具身智能、自动化工作流等场景同样具有深刻的启发意义。其核心价值在于它让AI智能体的“工作记忆”模式更贴近人类高效、灵活的信息处理方式。