简介：多模态大模型在密集计数、目标定位等任务上频繁翻车，根源不只是“看不清”，更是“说不清”。本文解析感知鸿沟与指代鸿沟两大瓶颈，对比视觉原语与图像思考两条技术路线的原理与取舍，并给出词表检查、行为测试、Agent配置与企业落地四步实践方法，帮助读者建立可操作的多模态模型评估框架。
一、模型“看图”，难在两道鸿沟
近期，某新一代实验性多模态模型的发布，再次把一个老问题推到台前：多模态大模型在图像理解上进步飞速，为什么在数人数、找目标、走迷宫这类“小学生都会”的任务上还会翻车？业内研究把多模态模型的能力瓶颈归纳为两道鸿沟。
1. 感知鸿沟（Perception Gap）：模型“看不清”。 视觉输入经过分辨率缩放、patch切分与特征压缩后，细节信息天然受损；再叠加图文对齐训练不充分，细小目标、密集纹理、微小文字可能在编码阶段就已丢失。这是第一层瓶颈，也是过去几年高分辨率视觉编码器与更大规模多模态预训练主攻的方向。
2. 指代鸿沟（Reference Gap）：模型“说不清”。 这层瓶颈更隐蔽：即便模型看清了图像，它在推理时依旧要用自然语言来描述和指代画面——“左起第三个人”“红房子旁边那棵树”。自然语言在目标稀疏、特征鲜明的场景下够用；可一旦同类目标密集出现，语言指代迅速失灵：到底是哪个“红衣服”？哪个“靠边的”？指代一含糊，后续的计数、定位、推理链条整体崩溃。
一个典型症状是：模型能把画面描述得头头是道，却在密集计数上自信地给出错误答案——明明25人的合影被数成27人；论文演示中可完成的迷宫路径规划，线上版本完全失效。这不是“眼神”问题，而是“表达系统”问题。评估多模态模型时，“描述得像不像”与“指代得准不准”必须分开考核。
二、两条路线：图像思考与视觉原语
针对指代鸿沟，业界目前存在两条主要路线。
路线一：图像思考（Thinking with Images）。 更经典、工程上更普遍。核心思想是把“看图”本身变成推理链中可调用的动作，典型机制包括：
它胜在与现有工具调用范式天然兼容，Agent框架改造成本低、上线快。但天花板同样明显：每一步视觉操作都要经历“自然语言指令→工具执行→结果回传”的闭环，指令歧义与执行偏差会逐步累积；而在迷宫导航这类需要始终保持全局空间结构的任务上，频繁局部裁剪反而容易把全局视野切碎。
路线二：视觉原语（Thinking with Visual Primitives）。 釜底抽薪的思路：既然自然语言不适合做视觉指代，就给模型一套新的指代表达系统——直接用几何元素编码视觉内容。典型做法是在分词器词表中引入一组几何特殊标记，例如：
<|point|> <|/point|> —— 点<|box|> <|/box|> —— 矩形框<|polygon|> <|/polygon|> —— 多边形
借助这些标记，模型在推理时可以直接“想到”并输出结构化几何坐标：一个目标不再被描述为“左边那个人”，而是被表达为精确的点、框或多边形顶点。几何元素因此成为连续视觉空间中的无歧义指针——坐标没有歧义，密集计数退化为对几何标记的枚举，复杂定位退化为坐标运算，自然语言的指代陷阱被整体绕开。
它的代价也很实际：其一，训练数据构造难，需要大规模带几何标注的指令数据，并教会模型在语言与几何两种表达模态间正确切换；其二，生态兼容性差，输出中混入结构化标记，对下游的流式解析、前端渲染、日志系统都是额外负担；其三，解码开销上升，多边形顶点序列较长，推理token成本增加；其四，能力均衡难，几何表达强化的同时若普通图文对话训练跟不上，容易顾此失彼。
三、如何判断一个模型走了哪条路线
模型发布时通常不会把内部机制和盘托出，开发者可以从三个层面自行判断。
第一层：查词表。 可本地部署的模型会随包发布分词器配置文件。如果词表中出现成对的几何特殊标记（如上文point/box/polygon系列），说明模型在词汇层面为视觉原语做过准备。但必须强调：词表里“有”，不等于推理时“用”——标记可能只是训练遗留，实际部署版本未必启用，甚至可能切换到另一条路线。一个值得玩味的现象正在于此：有的模型词表中明确带有几何标记，说明训练阶段接触过视觉原语体系，但在Agent环境中的实际行为却更接近经典的图像思考——“训练时学过、部署时不用”，这种分裂状态本身就是观察“harness与模型能力如何错位”的绝佳样本。
第二层：看原始输出。 在密集计数或定位任务上观察模型的原始推理输出（而非产品界面包装后的结果）：倾向于发起裁剪、放大、标注类工具调用，属于图像思考；直接输出坐标序列或几何标记，则是视觉原语的特征。
第三层：做行为测试。 准备一组“照妖镜”任务，专门给自然语言指代制造最大压力：高密度计数（数百人合影、密集货架、鸟群鱼群）、同属性多目标定位（多个外观高度相似的目标中精确指认其一）、全局空间推理（迷宫路径规划、地图导航）。
另外要警惕基准与线上表现的脱节。可能原因包括：线上经过量化或蒸馏、推理配置（上下文长度、采样参数）不同、产品端叠加了额外处理层，甚至线上与论文根本不是同一档位版本。结论是：榜单和demo只能做初筛，评估必须落到自建基准与真实部署环境上。
四、Agent harness：被低估的决定性因素
多模态模型能力的实际发挥，高度依赖运行它的Agent harness（工具编排环境）。同一份模型权重，接在精心实现的harness上与接在粗糙的harness上，表现判若两台模型。原因很直接：图像思考的裁剪、放大、标注能力，需要harness提供对应的工具实现与图像回传通道；视觉原语的几何标记，也需要harness正确解析与渲染。握手协议一旦错位，能力就无从兑现——这往往比“模型内部用了什么路线”更能解释很多现象。
实际配置中，几个常见的坑值得记录：
坑一：配置方式隐蔽。 不少官方Agent工具不使用直观的命令行参数指定后端模型，而是通过JSON配置文件或profile机制完成切换。文档若不明确交代，用户极易在“命令行传参”上反复碰壁。最直接的排查方法是开启调试日志，确认实际请求的模型标识是否生效。
坑二：升级与配置必须成对操作。 实验性新模型上线时，往往要求先把命令行工具经包管理器升级到最新版本，再切换到对应profile才能调用。示意流程如下：
# 1. 经包管理器将官方Agent工具升级至最新版本<package-manager> update -g <official-agent-cli># 2. 切换到目标profile后启动<official-agent-cli> --profile <target-profile>
只改配置不升级，或只升级不切profile，都会得到“看起来配置了、实际上没生效”的假象。
坑三：文档颗粒度不足。 官方发布公告介绍新能力时，应当同步写清第三方用户的接入路径，而不是默认所有读者都处于内部环境；自家推送尚且不交代升级步骤，社区的支持成本只会被成倍放大。对使用者而言，遇到“文档看不懂”的情况，优先核对版本号、配置文件与profile三者是否一致，往往比反复试错更有效率。
一句话总结这个环节：模型是发动机，harness是底盘与变速箱，缺了后者，马力再大也跑不起来。
五、企业落地：四步评估与部署清单
第一步：建立自有评测集。 覆盖密集计数、精确定位、OCR、图表理解、空间推理五类任务，样本务必来自真实业务场景；同一套用例分别在基准条件与生产条件下运行，量化差距，避免“评测满分、上线翻车”。
第二步：验证路线与业务的适配性。 若业务强依赖密集计数与精确定位（质检、巡检、安防盘点），重点验证几何输出能力与harness的图像回传质量；若业务以对话式图文理解为主（客服识图、内容审核），图像思考路线的工程简单性可能更具性价比，不必盲目追新。
第三步：为推理链路建立可观测性。 多模态Agent的失败经常发生在“模型→工具→图像回传”链路上，而非模型本身。建议为每次视觉工具调用记录完整日志，事后才能区分是“没看清”（感知问题）、“说错了”（指代问题）还是“执行歪了”（harness问题）。在云上部署时，可借助百度智能云等平台提供的日志服务、监控告警与容器平台等通用能力，搭建可复现的评估与灰度环境，避免上线即黑盒。
第四步：谨慎对待实验版本。 名称中带有experiment、preview等标识的模型，行为与线上表现都可能快速变化。生产接入前应锁定模型版本快照，并建立回归测试，防止静默升级引入行为漂移。
六、结语
一个多模态模型是否装备了视觉原语，表面上是对技术细节的好奇，实质触及当前多模态技术的核心矛盾：视觉的精确性与语言的模糊性之间的张力。感知鸿沟靠更强的编码器弥合，指代鸿沟则要靠表达系统的重构——要么教模型“边想边看”，要么教模型“用几何说话”。两条路线没有简单的高下：前者赢在工程兼容与迭代速度，后者赢在精确任务的上限，长期更可能走向融合。
对开发者而言，无论路线如何演进，有三件事不变：用行为测试代替榜单迷信，用可观测的harness兑现模型能力，用自建基准守住生产质量下限。看懂了这一点，下次再遇到“数错人数”的模型，你至少能准确回答：它到底是没看清，还是说不清。