OpenVLHarness：让模型多想没用，给它一个"带记忆的工具箱"平均分涨 12 个点
你有没有遇到过这种场景：让多模态大模型数一张密集图里有几粒药丸，它张口就来一个数；问它"窗户和柜子的中心相距几米"，它盯着两张照片硬猜；问它图里那个背包拿过什么奖，它开始一本正经地编造。这些任务的共同点不是模型不够聪明，而是它需要的信息根本不在脑子里——需要放大看、需要搜索、需要拿工具量。
直觉的解法是"让模型多想一会儿"。但 UCLA 和 Apple 的这篇论文用一个很扎心的对照实验告诉你：把推理预算从 xhigh 拉到 max，token 花销翻 2.7 倍，22 个 benchmark 的平均分只涨了 0.7 个点。
钱白烧了。
这篇 OpenVLHarness（arXiv:2610.26860）给出的答案是：与其让模型对着原始输入干想，不如给它一套带持久多模态记忆的工具箱——工具结果渲染成模型看得懂的证据，证据背后的图像、掩码、深度数组全部注册成可寻址的"工件"，后续步骤随时取用。就这么一个思路，在 8 个开源和闭源底座上把 22 个 benchmark 的平均分拉高 9.7 到 12.6 个点。更狠的是效率：GPT-6 Luna 中等推理强度挂上这个 harness，比裸模型、Codex、Visual Sketchpad 全部开到 max 强度还高 7.7 到 8.5 分，而 token 成本最多只有它们的 37%。
核心摘要：视觉任务卡壳的根源往往不是推理不够，而是证据不够。OpenVLHarness 用"能力层（统一工具接口+证据渲染）+ 持久多模态记忆（图像/结构化数据/网页引用全程可寻址）"搭了一套通用 harness，让 MLLM 可以反复获取、检查、组合多模态证据。22 个 benchmark、8 个底座上全面碾压无工具基线和 Codex、Visual Sketchpad 等训练-free 方案，甚至不动权重就超过了三个需要微调的 training-based 方案。这不是又一篇"刷榜"论文，而是一份关于"视觉 Agent 基础设施该怎么搭"的扎实答卷，工程参考价值很高。
论文信息 - 标题：OpenVLHarness: Real World Visual Agentic Tool-Use with Multimodal Memory - 作者：Yu Zhou, Cheng-Fu Yang, Rui Sun, Di Wu, Sibo Peng, Mingyang Zhang（UCLA）；Zhen Yang, Ruiyi Zhang, Zhe Gan（Apple，共同一作标注）；Nanyun Peng, Kai-Wei Chang（UCLA） - 链接：https://arxiv.org/abs/2610.26860 ，代码开源在 github.com/uclanlp/OpenVLHarness - 提交日期：2026 年 10 月 19 日
🎯 问题：推理预算救不了"证据缺失"
先说那个让我愣了一下的实验。
作者拿 GPT-6 Luna 在 22 个 benchmark 上扫了五档推理强度（low 到 max）。裸模型从 low 到 max，平均分从 44.3 爬到 48.0；Visual Sketchpad 从 44.7 到 48.8；Codex 最惨，low 档只有 36.9，max 档 48.6。而单单从 xhigh 提到 max 这一档，token 成本就乘了 1.5 到 2.7 倍。
这就是论文的核心立论："很多视觉任务的瓶颈不在想得不够久，而在手头证据不够"。数 134 粒药丸需要真的去定位和计数，不是盯着图冥想；问产品拿过什么奖需要真的去搜网页；问两个物体相距几米需要相机位姿、深度图、分割掩码一起做几何计算。这些证据必须通过异质工具——感知模型、搜索引擎、代码执行——从外部世界拿回来。
说起来，视觉工具调用这条线其实不新了。早期 VisProg、ViperGPT 那波把工作流当程序合成，编译一个固定 pipeline 跑到底，中间结果没法反馈调整；后来 AdaReasoner、PixelReasoner、DeepEyesV2 这一派走多轮交互，但要微调 backbone 才能 work；跟本文最接近的是 Visual Sketchpad 和 OctoTools，都是 training-free 的手工工具框架。那 OpenVLHarness 的差异在哪？我的判断是：它把赌注押在了harness 本身的工程结构上——工具输出怎么变成模型可读的证据、证据背后的原始工件怎么跨轮次复用——而不是押在某个特定工具集或某个模型上。
🏗️ 方法：能力层 + 持久多模态记忆
图 2（论文 Figure 2）：MLLM orchestrator 通过类型化接口调用能力层，能力层把后端输出渲染成模型可读的证据（图中是带标签的掩码叠加图+文字描述+归一化框坐标）；右侧的持久多模态记忆把图像工件、结构化数据、网页引用按可复用句柄存起来，每轮工具调用后用 Environment Update 把当前可用工件清单广播给 orchestrator。
整个系统的设计可以用一句话概括：让工具结果既可读、又可复用。它由两个互补机制组成。
能力层：接口统一 + 证据渲染
第一个机制解决"怎么调"和"怎么看"。
任务级工具接口按"操作"而不是"后端"来定义能力。比如 Visual Grounding 这个能力只规定"输入图像引用+文本查询，输出目标位置、元数据和可视化"，底层挂 SAM 3 还是 Grounding DINO 无所谓，orchestrator 的调用方式不变；OCR 可以在 PaddleOCR-VL 和 DeepSeek-OCR 之间切换。基础实例一共九个能力：感知五个（Zoom-in、Visual Grounding、OCR、深度估计、相机轨迹）、检索三个（文本搜索、图像搜索、网页访问）、外加一个 Python Coding Agent。
证据渲染解决的是另一个常被忽视的问题：工具的原始输出往往根本不是模型能消化的形态。一个 RLE 编码的分割掩码精确是精确，但把这串编码塞进上下文，模型根本不知道分割的是哪个物体；一个稠密深度数组倒是数据齐全，但直接序列化就是纯粹浪费 token。所以每个能力都带一个输出处理器，把结果渲染成组合式观测：可视化附件（掩码叠加图、彩色深度图、轨迹可视化）+ 简短自然语言描述 + 紧凑结构化信息 + 可复用工件的引用。
图里那个例子很典型：对 input_image_3 做"cabinet"的 grounding，返回一张标注了 5 个框的叠加图和文字描述。模型能直接"看见"检测结果；而真正的 RLE 掩码和坐标悄悄进了记忆，后面要用随时拿。
持久多模态记忆：句柄与载荷分离
第二个机制解决"怎么留着下次用"。
坦率讲这里的区分很关键：渲染出来的叠加图给模型看没问题，但如果下一步要"算每个柜子区域内的平均深度"，光有描述没用，得拿到掩码和深度数组的原始数值。OpenVLHarness 为每个 query 维护一个显式的工件注册表，贯穿整条推理轨迹，关键是句柄和载荷分离——模型只看到名字和紧凑描述符，harness 自己保管实际数值，需要时解析引用。
注册表分三类：
- 图像工件：输入图、工具生成图、检索到的图，用 input_image_3、tool_generated_image_6 这类句柄引用，重复图像自动复用条目；
- 结构化数据绑定：框、分数、掩码、深度数组、相机参数、OCR 结果，每个绑定带字段和类型描述符（含数组形状）；
- 网页引用：检索到的 URL 存成 webpage_url_1 这样的句柄，后续要回访网页不用模型背 URL。
每轮工具调用结束后，一个 Environment Update 消息把当前可用的句柄清单广播给 orchestrator——只报名字和描述，不重复载荷。
这套设计跟语言 Agent 里的 ReWOO（可引用变量）、CodeAct（解释器里的中间变量）、HuggingGPT/LLMCompiler（符号引用在执行时解析）一脉相承，OpenVLHarness 的贡献是把它扩展到了多模态：图像、结构化数据、网页证据统一进一个类型化注册表。
记忆之上的计算：Python Coding Agent
记忆里最值钱的用法是跨工具组合计算。orchestrator 用自然语言描述计算目标（比如"算每个检测区域内的平均深度"），harness 把可用绑定的描述符喂给同一个 backbone 的一个全新代码生成会话，生成的程序直接以绑定值为命名变量执行，结果用文字返回，新产出的工件继续注册复用。
这一步的意义在于：orchestrator 永远不用把巨型数组序列化进自己的请求里。过滤检测结果、聚合 OCR 数值、把两次 grounding 的掩码做并集去重——这类"胶水计算"全部下沉到代码层。
图 3（论文 Figure 3）：三个真实推理轨迹。(a) 相机位姿+深度图+grounding 掩码在代码里组合，算出窗户和柜子中心相距 1.1957 米（SparBench）；(b) grounding 裁出的背包区域依次过 Zoom-in、OCR、图像搜索，最后用网页访问核实"ISPO Award 2024"（FVQA）；(c) "pill"检出 134 个掩码、"round pill"检出 72 个，代码把两批掩码按像素重叠去重合并，修正漏数得到 139（FSC-147）。
这三个案例值得盯着看一会儿，因为它们展示了记忆机制真正解锁的东西：(c) 里单次 grounding 漏数了，靠两次查询的掩码在代码里对账才拿到正确答案——没有可寻址的掩码工件，这种自我修复根本无从谈起。
📊 实验：22 个 benchmark、8 个底座的全面碾压
主表（Table 1）按底座分组，对比 Base（无工具）、OctoTools（OT）、Visual Sketchpad（VS）、Codex（CX）。Qwen3-VL 结果是三次独立运行的均值（搜索 API、工具路由、LLM judge 都有随机性），闭源模型因成本只跑单次。
| 底座 | Base | 最强 training-free 基线 | OpenVLHarness | 提升 |
|---|---|---|---|---|
| Qwen3-VL-8B | 34.24 | OctoTools 31.80 | 45.41 | 涨 11.2 个点 |
| Qwen3-VL-32B | 38.30 | OctoTools 36.79 | 50.92 | 涨 12.6 个点 |
| GPT-6 Luna (medium) | 45.76 | VS 45.55 | 56.52 | 涨 10.8 个点 |
| GPT-6 Astra (medium) | 60.27 | — | 70.17 | 涨 9.9 个点 |
| GPT-5 | 44.4 | — | 55.7 | +11.3 |
| GPT-6 Sol | 52.7 | — | 64.3 | +11.6 |
| Kimi K3 | 56.4 | — | 66.1 | 涨 9.7 个点 |
有几个点我想单独拎出来说。
Codex 挂了 harness 反而更差。GPT-6 Luna 配 Codex 平均 43.8，低于裸模型的 45.8。这个结果我觉得特别有价值——它直接戳破了"接个 coding agent 就等于会工具调用"的幻想。写代码的壳子谁都有，证据怎么渲染、工件怎么复用才是分水岭。
不动权重打赢了微调的。Qwen2.5-VL-7B 上 OpenVLHarness 平均 33.45，超过三个需要微调 backbone 的 training-based 方案：AdaReasoner（25.29）、PixelReasoner（28.02）、DeepEyesV2（25.02）。
分领域看提升来源很诚实。Grounded perception 和视觉搜索吃工具红利最多——专用视觉专家和外部检索直接补上了能力缺口；通用 VQA 和空间推理的提升则更依赖底座本身的工具使用熟练度，Luna 和 Astra 每个 benchmark 都涨，但 Qwen3-VL-8B 在这些领域涨得不稳。作者没有藏着掖着，这个不一致直接引出了后面的失败分析。
推理预算实验：harness 和 reasoning 是互补的
Table 2 那组数据我建议大家自己去看原表，信息量很大。几个关键数：
- OpenVLHarness 在 low 档（49.9）就已经打平其他三种方法的 max 档；
- medium 档 56.5 分，成本最多是别人 max 档的 37%；
- 在 grounding 和视觉搜索两个领域，OpenVLHarness 任意一档都高于其他方法的任意一档，max 档领先 15.6 和 12.4 分；
- 通用 VQA 和空间推理上，low 档的 OpenVLHarness 略微落后于 Base（61.5 对 61.6、54.5 对 56.5），medium 起全面反超——说明这两类任务确实需要推理深度配合。
结论很清爽：证据获取和推理扩展是互补的两条轴，光堆一边都有天花板。
消融：每一步加什么都算得清楚
| 变体 | 8B Overall | 32B Overall |
|---|---|---|
| Baseline（无工具） | 37.06 | 41.29 |
| + 裸工具访问 | 40.84（+3.8） | 45.61（+4.3） |
| + 能力层 | 44.23（+3.4） | 48.80（+3.2） |
| + 文本记忆 | 44.93（+0.7） | 49.12（+0.3） |
| 完整多模态记忆 | 47.14（+3.1） | 52.51（+4.5） |
最打动我的是最后一行：从"文本记忆"（工具图只有文字描述、没有可复用图像句柄）到完整多模态记忆，8B 涨 3.1、32B 涨 4.5，其中视觉搜索领域涨 6.2 和 3.5 分。图像句柄这件事值 3 到 4.5 分——这是对"多模态记忆必须真的是多模态"最直接的证据。相比之下文本记忆只值零点几分，聊胜于无。
失败分析 + harness 自优化
作者用 Kimi K3 当批评家，分析了 Qwen3-VL-8B 的 9893 条失败轨迹（与人工标注一致率 92%）。失败模式按领域分化得很开：grounded perception 里 75% 是"工具输出本身错了"（密集场景漏检）；视觉搜索里 49% 是"该调的工具没调"；空间推理和通用 VQA 则是漏调和推理错误参半。而"工具给了正确结果但模型没用"只占 3% 到 8%——侧面证明证据渲染确实把结果做 readable 了。
更妙的是他们把诊断结果接到两条 coding-agent 驱动的优化流水线上：harness search（改系统提示、工具描述、渲染模板）和 tool generation（组合现有能力生成新工具）。选了四个"药方画像"相反的数据集验证：ERQA/RealWorldQA 上文本级修改占主导（71%/56%），harness search 涨 4.1 和 3.7 分而 tool generation 基本不动；SparBench/FREAK-VQA 上缺工具占主导（75%/62%），tool generation 涨 8.2 和 4.5 分而 harness search 反而掉分。先诊断失败画像，再选优化工具——这套"对症下药"的方法论比结果本身更有迁移价值。
🤔 我的判断
这篇论文最值钱的地方不是某个单点技巧，而是它把"视觉 Agent harness"当成一等公民来系统设计：接口抽象、证据渲染、工件注册、引用解析、记忆计算，每一层都有消融数据背书。很多 Agent 系统的记忆里只存文本描述，这篇用消融实验告诉你图像句柄值 3 到 4.5 分——这种量化证据在 Agent 工程文献里不多见。
也要泼点冷水。其一，整套系统的天花板明显受限于后端工具质量——grounding 在 25 个物体以上的密集场景直接漏检，这是 SAM 3 的问题不是 harness 能修的；其二，9 个能力的覆盖面对视频理解、长文档等场景还不够，论文自己也主要在静态图像任务上验证；其三，虽然 token 成本相对 max-effort 基线有优势，但 harness 多轮调用的绝对延迟和工具执行成本（论文明确排除在统计外）在真实部署里仍需算账。还有个我没完全看懂的点：Environment Update 每轮广播全部句柄清单，在超长轨迹上这个命名空间本身会不会膨胀成新的上下文负担，论文没有给出轨迹长度与上下文增长的曲线。
但瑕不掩瑜。如果你在做视觉 Agent 或工具调用系统，这篇值得精读——尤其是证据渲染和工件注册表这两块，基本是可以直接抄进工程实现的设计模式。加上代码、工具、评测协议、优化工作流全部开源，复现门槛很低。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我