从视觉原语到图像思维：多模态模型技术路线解析

一、背景：一场关于“技术路线”的讨论

近期，某团队发布了实验性质的轻量级视觉多模态模型。与以往“发布即跑分”的氛围不同，社区讨论的焦点并非榜单成绩，而是一个更本质的问题：这个模型在处理图像时，究竟采用了哪条视觉推理技术路线？是延续结构化“视觉原语”的方案，还是转向了更经典的“图像思维”路线？

这个问题之所以重要，是因为技术路线直接决定了模型在密集计数、空间定位、路径规划等任务上的能力上限，也决定了开发者应该如何设计外围的调用与编排逻辑，即所谓 harness。本文以此为契机，梳理两条路线的原理差异，并给出一套可复现的评估方法。

二、两条技术路线：图像思维与视觉原语

2.1 图像思维：让模型“边看边操作”

图像思维路线的核心思想，是把图像当作可以被反复操作的对象：模型在推理过程中可以裁剪感兴趣区域、放大局部、在图上做标注，然后基于操作结果继续思考。它本质上是一个“感知—行动—再感知”的闭环，非常依赖成熟的工具调用能力。

它的优点包括：

• 通用性强：任意视觉任务都可以拆解为一系列图像操作；
• 过程可解释：每一步操作都有明确的中间产物，便于排查；
• 工程成熟度高：可以直接复用现有 agent 框架的工具调用机制。

代价也很明显：多轮交互带来更高的延迟与 token 开销；操作精度受限于底层视觉工具的质量；失败模式更复杂，定位问题更困难。

2.2 视觉原语：给视觉空间装上“无歧义指针”

要理解视觉原语，需要先理解两个概念：

• 感知鸿沟（Perception Gap）：受限于分辨率、图像切块与下采样，模型“看不清楚”细节。这是早期多模态模型的主要瓶颈，随着高分辨率与动态分辨率技术的普及，已在很大程度上被缓解。
• 指代鸿沟（Reference Gap）：即便看得清楚，模型在思考时仍然要用自然语言来描述图片内容。“左数第三个穿蓝衣服的人”这类描述在密集场景中天然含糊，后续逻辑推理建立在这种有损、有歧义的中间表示之上，于是在密集计数、精确定位等任务上出现连锁崩溃。

视觉原语的思路，是让模型在推理时直接引用一组定义在连续视觉空间中的结构化几何对象——点、矩形框、多边形。它们像程序语言中的指针一样，无歧义地指向图像中的某个区域，从而绕开自然语言这层“有损转换”。

2.3 两条路线的本质差异

用一句话概括：图像思维是“用动作代替描述”，视觉原语是“用坐标代替语言”。前者扩展的是探索能力，后者提升的是指代精度。两者并不互斥，融合使用正在成为趋势。

三、如何从公开产物推断技术路线

判断一个模型采用了哪条路线，最直接的办法是检查它随附的分词器配置中定义了哪些特殊标记。业界常见的示意格式如下（仅作说明，非任何特定实现）：

<point>    x, y </point>
<box>      x1, y1, x2, y2 </box>
<polygon>  x1,y1 x2,y2 x3,y3 ... </polygon>

判读要点有三个：

1. 出现成对的几何类特殊标记（点、框、多边形），通常意味着模型具备输出结构化视觉指代的能力，与原语路线高度相关；
2. 出现图像操作类工具定义（裁剪、缩放、标注等），则更接近图像思维路线；
3. 两者可以共存：标记存在只说明“能力被预留”，不代表推理时真的被高效使用，还需要行为层面的验证。

近期那次发布的一个有趣细节是：社区在分词器配置中发现了成对的几何标记，似乎说明原语机制仍在位；但从 agent 场景的实际行为看，模型又表现出明显的图像思维特征。这种“配置与行为不完全一致”的现象，恰恰说明了下一节行为验证的必要性。

四、论文表现 ≠ 产品表现：建立自己的评估流程

一个反复被验证的经验是：同一模型在不同入口下的表现可能差异显著。预处理流程、输入分辨率、系统提示词、工具编排方式，任何一环都可能改变结果。两个泛化后的典型案例：

• 某模型论文中宣称能准确数清一张球队合影中的人数，但在网页端识图模式下，同样的图片却数出了多余的人；
• 论文中演示的迷宫导航路径规划能力，在网页端几乎完全失效。

这不一定是“夸大宣传”，更可能是论文环境与产品环境的 harness 不一致。因此，负责任的评估应遵循以下流程：

1. 划分任务族：密集计数、细粒度定位、文档理解、空间推理、图表问答，分别构造用例；
2. 固定输入与提问：使用确定的图片与提示词，每个用例多次采样，统计成功率而非单次结果；
3. 对照实验：分别测试不同入口（接口直连、网页端、agent 框架），并尝试调整分辨率与提示词，定位差异来源；
4. 记录环境：模型版本、配置文件、调用参数全部留档，避免“玄学复现”。

在企业落地场景中，这类评测流水线可以借助通用云产品能力搭建：用对象存储管理测试图片集，用容器平台跑批量推理任务，用日志服务与监控告警追踪指标漂移。以百度智能云为代表的通用云产品类目均可覆盖上述需求，开发者无需自建全套基础设施。

五、harness 与开发者体验：被低估的一环

这次讨论还暴露了一个常被忽视的问题：新模型发布时，外围工具链的文档往往严重滞后。社区遇到的典型情形包括：

• 官方公告演示了新模型的用法，却没有说明命令行工具需要先升级才能识别新模型；
• 模型切换的配置方式既不是文档中的命令行参数，也不是环境变量，而是藏在 JSON 配置文件里，普通用户几乎不可能自行发现；
• 给第三方开发者写的接入示例，与官方自身的实际用法并不一致，让人分不清到底谁才是“第一方”。

示意性的升级与配置流程如下（伪代码）：

# 示意：先升级命令行工具，再切换到目标模型
pkg update -g <agent-cli>
<agent-cli> --profile web

{
  "model": "<vision-model-name>",
  "profile": "web"
}

这些细节传递出一个行业信号：模型能力的最终兑现，高度依赖 harness——即模型外围的编排、配置与工具层。对开发者而言，评估一个模型时，除了看能力上限，还要评估接入成本、文档质量与配置透明度；对厂商而言，发布日同步给出完整的接入说明，是基本的工程素养。

六、给开发者与评估者的三点启示

1. 路线判断要“配置 + 行为”双验证：特殊标记只能证明能力被预留，行为实验才能证明能力被真正使用；
2. 不要用单一入口下结论：论文环境、接口、网页端、agent 框架是四套不同的系统，它们之间的差异本身就是重要信息；
3. 把 harness 当作一等公民：同样的模型，好的工程编排可以把可用性提升一个档次，差的编排则会让能力完全无法兑现。

七、结语

视觉原语与图像思维之争，本质上是在回答同一个问题：如何让模型在连续的视觉空间中精确地“指”与“走”。前者用结构化坐标解决指代精度，后者用主动操作扩展探索边界。对于即将面对越来越多多模态模型的开发者来说，理解机制、动手实测、关注工程编排，远比记住一个发布日期或一个模型名更有价值。