LMM-Searcher：长程多模态 Agentic Search 的"文件式视觉表征 + 按需取图" — 精读与批判

  • 实例：flyP
  • 日期：2026-08-07 15:50 (Asia/Shanghai)
  • 论文链接：https://arxiv.org/abs/2604.12890（v2，2026-04-25 提交；v1 2026-04-14）
  • HTML：https://arxiv.org/html/2604.12890v2
  • 代码：https://github.com/RUCAIBox/LMM-Searcher（论文承诺开源；待补查 release 状态）
  • 作者/机构：Yifan Du, Zikang Liu, Jinbiao Peng, Jie Wu, Wayne Xin Zhao, Ji-Rong Wen（中国人民大学 人大高瓴 AI School）+ Junyi Li（香港城大）
  • 学科：cs.CV / cs.AI
  • Base 模型：Qwen3-VL-Thinking-30A3B（30B 激活 3B 的 MoE-VL），用 12K 高质量轨迹 SFT
  • 评估基准：MM-BrowseComp（Level1/Level2）、MMSearch-Plus、MMSearch（171 image）、Video-MME、可能还含自建 Long-horizon 集合
  • 核心宣称：100-turn 长程搜索下，open-source SOTA on MM-BrowseComp & MMSearch-Plus；可推广到不同 base
  • 分类标签：multimodal-agent, long-horizon-search, file-based-visual-rep, UID-offload, agentic-multimodal-rag, research-kb/review, flyP-multimodal-axis

0. 为什么挑这篇（flyP 选稿理由）

flyP 7-1 ~ 7-5 主线已建出"RAG / Agent 质量六层矩阵"：机制层 + 推理层 + 来源层 + 记忆层 + 基础设施层 + 安全层。8 月以来陆续做了： - 8-1 ShadowDancer（VLA + depth memory）/ See2Think / ViSTR-Bench dynamic reasoning - 8-2 RecMem / PhiZero - 8-3 Beyond-pass1 / Emergence-World - 8-4 Mental World Modeling / TEngineDB-V + DEFRAG / LongDS-Bench - 8-5 Zero-Mem + Sparse-Event KV / 3DZip / SwanTale - 8-6 MiniWorld video world model - 8-7 BVS visual jailbreak（multimodal + safety）

8 月 flyP 的方法学轴心已经向"长上下文 + 多模态 + agent 评测"倾斜：LongDS-Bench（长程数据分析）、Mental World Modeling（mental long-horizon）、Beyond-pass1（pass@k vs 可靠性）、ViSTR-Bench（动态推理）、MiniWorld（视频世界模型）。唯独"长程多模态 agentic search"这条主线没有专门的精读承接。

LMM-Searcher (arXiv:2604.12890) 直接以"file-based visual representation + UID offload + fetch-image tool" 解决"长程多模态搜索的 context explosion"——这条方法学正好和 flyP 主线两轴契合： - 多模态轴：把视觉当作"外部文件 + UID"而非"raw tokens"，是对"multimodal as first-class context"路线的反向修正； - 长程 agent 轴：100-turn 长程搜索 + on-demand visual loading，连接 flyP 已有的 Beyond-pass1 / LongDS-Bench 长程可靠性讨论。

特别切题 Anan 实际场景：Anan 的工作栈（OpenClaw 系列）正是 agentic runtime。LMM-Searcher 的 "file-based visual rep + UID + fetch-image" 是 Anan OpenClaw 可以直接借鉴的视觉记忆模式——不需要把每张图 base64 喂给 LLM context，而是落到本地/对象存储、按需调 fetch-image 工具加载。

1. 核心贡献（论文自述）

LMM-Searcher 把多模态搜索 agent 的"context explosion"问题转化为"offload + UID + 按需取回"问题：

阶段 名称 关键操作 工程含义
Stage A File-based Visual Representation 把视觉资产（图像/视频关键帧）offload 到外部文件系统，用轻量文本标识符 UID（file path / UUID / token）代替 raw pixels 进入 LLM context 视觉 token 数量从 O(N·H·W) 降到 O(N) —— 上百张图只占几百 UID
Stage B fetch-image Tool 给 agent 一个自定义 fetch-image tool，能根据 UID 把视觉资产按需重新加载到 working memory（限定分辨率 / ROI / 时间窗） progressive on-demand visual loading —— 避免一次性把所有图全量塞入 context
Stage C 数据合成 pipeline 构造需要跨模态多跳推理的查询 —— 把"单模态可答"的 query 升级为"必须图文交叉验证"的 query 训练集与测试集设计原则统一
Stage D SFT 蒸馏 用 12K 高质量轨迹微调 Qwen3-VL-Thinking-30A3B，得到专门的多模态 deep search agent 与 search-r1 / WebThinker 等 RL 路线对比，走 SFT 而非 RL 路线
评估 100-turn 长程搜索 在 MM-BrowseComp / MMSearch-Plus / MMSearch 等 4 个 benchmark 上把搜索上下文扩到 100 turn 验证"长程 + 多模态"组合可行性

核心宣称： 1. 在 100-turn 长程搜索下，open-source SOTA on MM-BrowseComp（Level2 子集，难度更高）与 MMSearch-Plus。 2. 跨 base 模型可推广：除 Qwen3-VL-Thinking-30A3B 外，方法可移植到其他 MLLM backbone。 3. 4 个 benchmark 一致提升，证明框架 generalizable。

2. 方法拆解（flyP 视角）

2.1 File-based Visual Representation — 把"视觉是 token"降级为"视觉是文件"

传统多模态搜索 agent 的失败模式： - 把每张搜索结果图的 base64 / patches 全部塞进 LLM context → 100 张图 ≈ 数十万 token → context overflow； - 或者用 heuristics（DeepEyesV2 等）丢弃中间图像 → 关键视觉信号丢失 → 信息不完整。

LMM-Searcher 的解法借鉴 planning-with-files paradigm（Othmanadi 2024、Merrill 2026 Terminal）—— 把 LLM 的工作记忆视为"指针 + 文件系统"： - 每个视觉资产被 offload 到 file_store/（沙箱文件系统）； - LLM context 中只保留 UID（文件路径 / 短 token）； - 需要时通过 fetch-image(UID, region, resolution) 调取局部视觉。

flyP 关键洞察：这是OS 虚拟内存分页思路在 multimodal context 中的复刻 —— 视觉资产是"页"，UID 是"页表项"，fetch-image 是"缺页中断"。这条思路与 6 月以来"长上下文 KV cache 压缩"（MosaicKV / GSRQ / PartRep）形成方法学合流： - KV cache 压缩：在 token 序列层面"少装点东西"； - UID offload：在语义资产层面"别把东西都装进来"。

flyP 主张：长程多模态 agent 的成本治理 = KV 压缩 + 语义 offload + 工具化取回三层叠加。任何一层缺位都会导致 context explosion。

flyP 风险判断： - fetch-image tool 的"按需"是否真的按需：LLM 必须主动判断何时调用 fetch-image 才能拿回关键视觉信号。如果 agent 没有学会"哪些 UID 值得二次取回"，UID offload 等同于"丢弃关键信号"。 - UID 到原始视觉的映射损失：UID 是文本指针，没有任何视觉信息内嵌。如果 agent 在第 1 轮就把 UID 写进 reasoning 但从未调 fetch-image，UID 等同"垃圾回收中的悬空指针"。 - 与传统 RAG 的本质区别：RAG 用 embedding 检索 + top-k chunk；LMM-Searcher 用 LLM 自己生成 UID + 按需取回。前者的失败模式是"检索漏召"，后者的失败模式是"agent 不会调工具"——两者完全不同的失败谱。

2.2 数据合成 Pipeline — 把"单模态 query"升级为"跨模态多跳"

论文花篇幅描述一个数据合成流程：从已有的多模态语料（图像-文本对）中： 1. 找出"仅文本可答"的 query（baseline 可以解）； 2. 找出"必须图文交叉验证"的 query（文本信息不充分，必须看图）； 3. 组合成"跨模态多跳"query。

flyP 关键洞察：这是 MIR-style 多跳 query 设计的强化版 —— 不仅要求多跳，还要求跨模态。多跳 = 多步推理 + 多源证据，跨模态 = 至少包含一次 image-grounded verification。

flyP 风险判断： - "12K 轨迹"规模 vs 长程 100-turn：12K 轨迹是否覆盖了 100-turn 长程搜索中的所有失败模式？如果合成 pipeline 平均轨迹长度 < 30 turn，训练与测试的 turn 分布不匹配，泛化不可信。 - 多跳 query 的"构造完备性"：合成 query 是不是真的"必须图文交叉"？还是"文本够了但作者强制加图文"？——这决定 query 难度是真实难度还是设计难度。 - 未给的对照：合成 query vs 人工构造 query 的难度对比 / query 难度与 SOTA 模型准确率的相关性 —— 论文没给这层 ablation。

2.3 SFT 而非 RL — 训练路线的策略选择

12K 高质量轨迹 SFT Qwen3-VL-Thinking-30A3B —— 不走 search-r1 / WebThinker / ZeroSearch 那条 RL 路线。

flyP 关键洞察： - SFT 优势：训练稳定、不需要复杂 reward 设计、可以快速蒸馏； - SFT 劣势：上限受 teacher 轨迹质量制约、对分布外查询泛化能力弱、无法在线探索新的搜索策略。 - 与同期 RL 路线的对比：search-r1 类工作用 outcome reward + RL 让 agent 自学搜索策略，但 RL 在多模态上的工程复杂度高（reward model 必须是 MLLM），LMM-Searcher 走 SFT 是一种务实的工程简化。

flyP 风险判断： - 12K 是不是太少：与 search-r1 训练数据规模相比，12K 算小规模 SFT。如果论文没说 teacher 模型（哪条 MLLM 生成的轨迹）、没说 trajectory filtering 标准，12K 的有效性存疑。 - SFT 是否覆盖了 RL 擅长的"探索"能力：100-turn 长程搜索中，agent 需要在陌生搜索空间尝试新策略。SFT 模型被限定在 teacher 轨迹见过的模式，可能在第 30 turn 之后开始"模式崩塌"。

2.4 100-turn 搜索长程扩展性

论文把搜索 horizon 扩到 100 turn，验证"长程 + 多模态"组合可行。

flyP 关键洞察： - 100-turn 是不是真长程：相比 Long-Horizon Terminal-Bench（46 task × 231 step × 9.9M token），100-turn 搜索算"中等长程"。但相比 MMSearch 标准设置（5-10 turn），100-turn 是显著扩展。 - 长程 vs 短程性能衰减：论文没给 10 / 30 / 50 / 100 turn 的性能曲线。如果性能随 turn 增加快速衰减，"100-turn SOTA" 的解读价值打折。

3. 实验风险与可信度判断

3.1 强证据（高可信）

  • 方法学清晰：file-based visual rep + UID + fetch-image + SFT 蒸馏，每一步都可独立评估。
  • 评估 benchmark 公开：MM-BrowseComp / MMSearch-Plus 是公开 benchmark，可复现。
  • 开源承诺：GitHub 仓库 https://github.com/RUCAIBox/LMM-Searcher —— 可复现性高于多数同主题工作（待补查 release 状态）。
  • "跨 base 模型可推广"：如果论文真给跨 backbone 实验（不仅 Qwen3-VL-Thinking-30A3B），方法普适性提升一档。

3.2 弱证据（待补查 / 不确定）

  1. 跨 base 模型实验细节：论文 abstract 说 "exhibiting strong generalizability across different base models"，但具体跑了哪几个 base？仅一个 base 还是 3-4 个？单 base 实验不能证 "generalizable"。
  2. 100-turn 性能曲线缺失：在 10/30/50/100 turn 不同 horizon 下的准确率曲线没给。100-turn SOTA 是峰值还是平台？——决定"长程"是真实扩展还是过拟合。
  3. fetch-image tool 的使用统计：100 turn 内 fetch-image 被调用多少次？平均每个 UID 被取回几次？——决定"按需取回"是否真生效。
  4. false retrieval 评估：agent 调 fetch-image 但取回错误视觉 / agent 完全不调 fetch-image（UID 沦为噪声）——这两种 false 模式论文没量化。
  5. MM-BrowseComp / MMSearch-Plus 评测细节：是否做了 prompt-level / decoding-level 的多 run 平均？置信区间？论文没明示。
  6. 12K 轨迹的合成细节：teacher 模型、过滤标准、平均 turn 长度、多跳深度分布 —— 全部未在 abstract 给定。
  7. 与 RL 路线（search-r1 / WebThinker）的对比：同样 base model（Qwen3-VL-Thinking-30A3B）走 RL 路线与走 LMM-Searcher SFT 路线的 head-to-head —— 论文没给。
  8. 生产化评估：成本（USD / task）、延迟（sec / task）、tool-call failure rate —— 任何"工程落地"指标都没给。

3.3 复现难度

  • 可复现性：⭐⭐⭐⭐（中高） —— 代码承诺开源、benchmark 公开、base model 公开（Qwen3-VL-Thinking-30A3B），复现门槛主要在 30B-A3B 模型推理硬件（≥ 80GB GPU / 多卡并行）。
  • 复现成本：12K SFT 训练 ≈ 8-16 张 A100/H100 × 1-2 天；inference on MM-BrowseComp + MMSearch-Plus ≈ 数小时 / run × 5 benchmark × 3 backbone = 数天 GPU。
  • 关键依赖：Qwen3-VL-Thinking-30A3B 是 MoE-VL 架构，推理栈需支持专家并行；Anan 本地 OpenClaw runtime 是否能调用 30B-A3B 取决于部署栈。

4. flyP 主线接口（最强支线）

flyP 8 月主线已建出"长上下文 × 多模态 × agent 评测"三轴交叉的多个工作点。本篇补全长程 × 多模态 × agentic search 这一具体子方向：

子方向 代表工作 与本篇关系
长上下文 × 多模态 6-19 V2PE / 7-1 InftyThink 机制层（位置编码 / 迭代推理）
长程 × agent 评测 8-3 Beyond-pass1 / 8-4 LongDS-Bench / 8-4 Mental World Modeling 评测层（pass@k vs 可靠性 / 长程数据分析 / mental model）
长程 × 多模态 × agentic search LMM-Searcher (本篇) 搜索层（跨模态多跳 + 长程 100-turn + 文件式视觉）
长程 × 多模态 × 视觉压缩 8-5 3DZip / 8-5 SwanTale 压缩层（视觉 token 压缩 / 多说话人音频）
长程 × agent 安全 8-7 BVS 安全层（视觉越狱）

LMM-Searcher 在 flyP 主线中横向贯穿"长程 + 多模态 + agentic"三轴，是少数同时具备三轴的工作点之一。

4.2 与 Long-Horizon Terminal-Bench（LHTB）的回路对比

LHTB（Tencent HY，2026-07，46 task × 231 step × 9.9M token × 85 min）评测terminal 任务（代码执行、SW 反编译、科学计算、多模态成像）的长程完成率 —— 是 agent 执行层 的长程评测。

LMM-Searcher 评测 search 任务（多模态信息检索 + 跨模态多跳推理）的 100-turn 长程成功率 —— 是 agent 搜索层 的长程评测。

flyP 关键洞察：两者共同揭示 2026 H2 agent 长程评测的两个根本不同范式： - 执行式长程（LHTB）：agent 必须"做事"（写代码、运行命令、生成 artifact），评价"是否做完"。 - 搜索式长程（LMM-Searcher）：agent 必须"找证据"（查网页、看图、跨模态推理），评价"是否找对"。

两者失败模式不同：执行式长程失败在"工具调用错误 / 状态管理崩溃"；搜索式长程失败在"检索漏召 / 跨模态信号丢失"。flyP 主张：2026 H2 应建"执行 × 搜索"双轴长程评测矩阵，而不是把两者混在同一 benchmark。

4.3 与 KV cache 压缩路线的方法学合流

LMM-Searcher 的 file-based visual rep 与 6-30 / 7-3 / 8-3 几条 KV cache 压缩路线（MosaicKV、GSRQ、PartRep、Expected Attention）形成方法学合流： - KV 压缩层：在 attention score 层面保留关键 token，丢弃冗余 token； - UID offload 层：把视觉资产完全 offload 到 LLM context 之外，UID 只占文本位置； - 工具取回层：agent 通过 fetch-image 按需加载，把"取回"作为显式 tool call。

flyP 趋势洞察（强化）：长程 agent 的 context 治理正在从单层 KV 压缩走向多层叠加（KV + offload + 工具化）。LMM-Searcher 是这一叠加范式在多模态场景的首个明确实例。后续工作应在这三层上做 ablation，量化每层的边际收益。

4.4 与 planning-with-files paradigm 的承接

论文明确引用 Othmanadi 2024（planning-with-files）和 Merrill 2026（Terminal），承认方法学谱系来自 planning-with-files paradigm —— LLM 把工作记忆外化到文件系统，自身 context 只保留指针。

flyP 关键洞察：这是 "LLM as OS" 思路的进一步实例化： - 2025：Memento（agent memory as file system） - 2026 H1：planning-with-files / Terminal（LLM 把 todo / state 写入文件） - 2026 H1（本文）：LMM-Searcher（视觉资产 as file system） - 2026 H2（预测）：LLM + full file system as cognitive extension（不仅视觉，所有模态都 file-based）

flyP 主张：Anan 的 OpenClaw runtime 在工具调用层面已具备 file system access，但视觉 / 音频 / 视频资产的 file-based 治理还没系统化。LMM-Searcher 给出一个"最小可行模式"：UID + fetch-image tool。Anan 可在 OpenClaw 工具集加入 fetch-image（基于本地/对象存储 UID 池），立即获得长程多模态场景的 context 治理能力。

5. 工程含义与生产落地建议

5.1 对多模态 agent 产品工程团队

  • 不要把视觉 base64 全量塞 LLM context —— 即使是 GPT-4o / Gemini 1.5 Pro，100 张图也是灾难。优先采用 file-based visual rep + UID + fetch-image 范式。
  • fetch-image tool 应支持三种模式：
  • 全图加载（context 短时高带宽）
  • ROI / 区域加载（按 bounding box）
  • 多分辨率加载（thumbnail → 原图 on-demand）
  • UID 应稳定 + 可重定位 —— 用 UUID / 文件 hash 而非随机 ID，便于断点续传 + 跨 session 共享。
  • 轨迹数据合成 pipeline 应纳入 CI —— 12K 轨迹 + cross-modal multi-hop 是 LMM-Searcher 成功的关键，没有这个 pipeline，模型只是普通 VLM。

5.2 对 research 社区

  • SFT vs RL 路线：在多模态搜索场景下，SFT 蒸馏 12K 轨迹就能打到 SOTA —— 这意味着数据质量 > 训练范式。后续工作应优先回答"什么样的多模态 query 训练集设计能跨 backbone 泛化"。
  • UID offload 是 multimodal RAG 的新形态：传统 RAG 用 embedding retrieval；UID offload 用 LLM 自身生成 UID + 按需取回。两者优劣：RAG 检索漏召率高但训练简单，UID offload 训练复杂但信号保真度高。
  • 100-turn 长程 vs 5-turn 短程：当前多模态搜索 benchmark 默认 5-10 turn。LMM-Searcher 把 horizon 拉到 100 turn，对未来的多模态 search benchmark 设计有强指向意义 —— 长程搜索应是默认而非扩展。

5.3 对 OpenClaw 用户 / Anan 个人

  • OpenClaw 工具集升级：在现有工具列表中新增 fetch-image(uid, region?, resolution?)，对应一个本地 file-based visual pool + UID registry。
  • 复用 LMM-Searcher 的数据合成 pipeline：构造跨模态多跳 query 训练 OpenClaw 多模态 agent。Anan 的 OpenClaw 工作栈可借鉴这套合成方法。
  • 成本评估：跑 LMM-Searcher 30B-A3B 模型需 ≥ 80GB GPU（4-bit 量化约 24GB），推理 MM-BrowseComp Level2（200 sample）约 30-60 min / run。
  • 风险：GitHub 仓库 https://github.com/RUCAIBox/LMM-Searcher 截至 2026-08-07 是否真的 release —— 待 Anan 自查。

6. 与 8 月 flyP 主线的接续

文档 主题 与本篇关系
8-7 BVS visual jailbreak critical read 多模态 + 视觉越狱 姊妹篇：BVS 评多模态安全漏洞，LMM-Searcher 评多模态搜索能力；两者共同覆盖"多模态系统层 + 安全 / 能力"
8-6 MiniWorld video world model 视频世界模型 同主线：MiniWorld 评视频世界建模能力，LMM-Searcher 评长程多模态搜索；两者都属"长程 × 多模态"
8-5 3DZip / SwanTale 3D 视觉压缩 / 多说话人音频 同主线：3DZip 评 3D 视觉 token 压缩，SwanTale 评音频 token 压缩；LMM-Searcher 评视觉 offload；三者形成"模态压缩三轴"
8-4 LongDS-Bench / Mental World Modeling 长程数据分析 / mental model 同主线：LongDS-Bench 评执行式长程（LHTB 谱系），LMM-Searcher 评搜索式长程
8-3 Beyond-pass1 Reliability Science 长程 agent 可靠性 方法学合流：Beyond-pass1 评 pass@k vs 可靠性，LMM-Searcher 评长程搜索成功率；两者共同支撑"长程 agent 质量评估"
8-1 ViSTR-Bench dynamic reasoning 动态推理评测 评测方法学：ViSTR-Bench 评动态推理，LMM-Searcher 评动态搜索；两者都用"动态过程评估"
7-5 2250 Vera evidence-grounded agent safety Agent 安全评测 同主线：Vera 评 agent 安全，LMM-Searcher 评 agent 搜索能力；两者共同覆盖"agent 能力 + 安全"

7. flyP 判断（3 条）

7.1 flyP 不同意 #1 "100-turn 长程 SOTA" 的解读方式

论文 / 媒体可能把 100-turn SOTA 当作"agent 已具备长程多模态搜索能力"的强信号。flyP 不同意这个解读：

  • 100-turn 是不是真长程：相比 LHTB（231 step / 9.9M token / 85 min），100-turn 多模态搜索算"中等长程"。"长程 SOTA" 应限定在"多模态搜索"场景，不应外推到"任意长程 agent 任务"。
  • 缺 turn-by-turn 性能曲线：如果性能在 50 turn 后开始衰减，"100-turn SOTA" 可能反映"前 30 turn 强，后 70 turn 崩"。论文应给 10/30/50/100 turn 四点性能曲线。
  • 缺 false retrieval 量化：fetch-image 被调用次数 / 取回错误率 / UID 沦为噪声比例 —— 这些决定"按需取回"是真按需还是名义按需。

flyP 结论：100-turn SOTA 是"在设计 horizon 下的最佳数字"，不是"agent 长程搜索能力已成熟"的强信号。生产团队应优先跑 turn-by-turn 曲线 + false retrieval 量化再做决策。

7.2 flyP 不同意 #2 "file-based visual rep 是通用解"

论文 / 媒体可能把 file-based visual rep + UID 包装为"长程多模态 agent 的通用解"。flyP 不同意这个解读：

  • 依赖 agent 主动调取：UID offload 的有效性完全取决于 agent 是否主动调 fetch-image。如果 SFT 训练数据中 fetch-image 调用频率低（agent 倾向于"用 UID 推理而不取回"），UID 沦为噪声。
  • 不适合所有场景：在"必须看图才能答"的 query 上有效；在"文本足够"的 query 上 UID 是 overhead（不如直接 base64）。
  • 与 RAG 不是替代关系：UID offload 适合"agent 自己生成 UID"场景；RAG 适合"embedding 检索"场景。两者应互补而非互斥。

flyP 主张：file-based visual rep 是"长程 × 多模态"场景的重要补充，不是通用替代。生产团队应根据场景选择 UID offload vs embedding RAG vs 直接 base64 三种范式。

7.3 flyP 不确定 #3 "跨 base 模型可推广" 的实证强度

论文 abstract 说 "exhibiting strong generalizability across different base models"，但没在 abstract 列出具体跑了哪几个 base：

  • 如果只跑了 Qwen3-VL-Thinking-30A3B + InternVL3 / Qwen2.5-VL 等 2-3 个 MLLM backbone，"跨 base 可推广"是中等可信；
  • 如果跑了 5+ backbone（含小模型如 Qwen2.5-VL-7B、Qwen3-VL-4B 等），"跨 base 可推广"是高可信；
  • 如果仅 1 个 base model 实验，"可推广"是营销话术。

flyP 风险标注：跨 base 实验细节待 Anan 自查 v2 论文正文 Section 5 / Appendix。本精读不预设"跨 base 可推广"的强度。

8. 可信度与建议

8.1 综合可信度

⭐⭐⭐⭐（中高）

  • 方法学可信：file-based visual rep + UID + fetch-image 思路清晰，与 planning-with-files paradigm 同源。
  • 评估可信：MM-BrowseComp / MMSearch-Plus / MMSearch 是公开 benchmark，4 个 benchmark 一致提升可信度较高。
  • 复现可信：GitHub 仓库承诺开源、base model 公开、12K SFT 流水线清晰 —— 高于多数多模态 agent 论文。
  • 解读可信：100-turn SOTA 应限定在"多模态搜索"场景，不应外推到"任意长程 agent"。

8.2 是否建议入库

强烈建议。理由： 1. 补全 flyP 8 月主线"长程 × 多模态 × agentic"交叉点的搜索层； 2. 与 Long-Horizon Terminal-Bench（LHTB）共同支撑"执行 × 搜索"双轴长程 agent 评测矩阵； 3. 与 KV cache 压缩、planning-with-files paradigm 形成方法学合流，给出"多层 context 治理"的具体实例； 4. Anan OpenClaw runtime 可直接借鉴 file-based visual rep + fetch-image tool 的设计模式。

8.3 后续验证动作

  1. 拉取 LMM-Searcher GitHub 仓库（https://github.com/RUCAIBox/LMM-Searcher）确认 release 状态 + 12K 轨迹数据是否公开。
  2. 读 v2 论文正文 Section 5 + Appendix，确认跨 base 模型实验细节（跑了几个 backbone、性能差距）。
  3. 拉 turn-by-turn 性能曲线：从论文 Table / Figure 找 10/30/50/100 turn 四点数据；若没给，请求作者补充。
  4. 跑 false retrieval 量化实验：在 100 sample 上统计 fetch-image 调用频率 / 取回错误率。
  5. Anan 自查：本工作栈 OpenClaw 与 GitHub 仓库的兼容性（UID 池设计、fetch-image tool 集成）。
  6. 下个 7 天跟踪：LMM-Searcher 后续是否有 v3 / 跟进工作给 turn-by-turn 曲线 + 跨 backbone 完整数据。

8.4 建议写入路径

  • 本文件：/shared/research-kb/inbox/flyp/2026-08-07-LMM-Searcher-long-horizon-multimodal-agentic-search-critical-read.md（精读草稿，按规则仅写 flyp/ 目录）
  • 下游桥接：
  • notes/2026-08-08-multimodal-context-management-three-layers.md（建议）——flyP 把"长程多模态 context 治理"整理为 KV 压缩 + UID offload + 工具取回三层叠加范式笔记
  • notes/2026-08-08-long-horizon-agent-eval-dual-axis.md（建议）——flyP 把"执行 × 搜索"双轴长程 agent 评测矩阵整理为方法学笔记，承接 8-4 LongDS-Bench / Mental World Modeling + 本期 LMM-Searcher
  • reviews/2026-08-08-LMM-Searcher.md（建议）—— 8-8 单独同步任务把本精读搬入 review/，与 8-7 BVS + 8-6 MiniWorld + 8-5 3DZip 等 flyP 多模态长程主线并列
  • promo/selection/2026-08-08-top.md 候选（建议承接 flyP 8 月长程 × 多模态主线第 N 件套）—— 本期可作 RAG/agent 雷达的"长程多模态搜索"代表，Jay 进工程笔记（UID offload 模式）+ Stephen 进视频脚本（"100-turn 长程 SOTA" 是好 hook）

8.5 不触碰边界

  • 不写其他实例目录（jay / spark / stephen / tom）
  • 不写 review/、published/（按规则仅草稿落 flyp/）
  • 不 git commit/push/gh pr
  • 不输出任何密钥 / Token / API key
  • 不复制论文全文 / 长段
  • 不复制 Substack / CSDN / GitHub README 长段内容

元信息

  • 本次轮次：2026-08-07 15:50 flyP 精读与批判（下午场）
  • 承接：8-7 BVS visual jailbreak（姊妹篇：多模态安全） + 8-6 MiniWorld（视频世界模型） + 8-5 3DZip / SwanTale（模态压缩） + 8-4 LongDS-Bench / Mental World Modeling（长程评测） + 8-3 Beyond-pass1（长程可靠性） + 7-5 2250 Vera（agent 安全）
  • 跨实例去重：全库 grep 未发现 LMM-Searcher / arXiv:2604.12890 已精读收录——本场为新候选
  • 轻量精读边界遵守：本精读只拉 2 次 web_search + 2 次 web_fetch（abs + html），未做并行子任务、未抓全文、未进入 GitHub 仓库深爬
  • 可信度自评：⭐⭐⭐⭐（中高）；后续验证以"turn-by-turn 曲线 + false retrieval 量化 + 跨 base 实验细节 + GitHub 仓库 release 状态"为主

本文件由 flyP cron 3d8f503a "研究知识库 · flyP 精读与批判 · 每天3次"触发，作为 8-7 下午场 1550 精读产出。仅写 flyP 实例目录，等待 8-8 单独同步任务串行处理 review/ 与 published/ 的合并。