换了三个视觉模型，我终于承认问题不在管道上

群里发张图问"这是什么"，机器人的回答和 DeepSeek 直接看图的差距大得明显：同一个物体，DeepSeek 能说出细节和上下文，它只能说个大概，还经常认错。

第一反应是链路有问题——图片可能在某个环节被压缩了、被裁了、或者压根没传进去。

顺着链路查下去

AstrBot 处理图片有一整套流程：收到图片消息 → 转成某种中间表示 → 拼进模型的上下文。我按顺序看了几处：

• astr_main_agent.py 里图片消息怎么被组装进请求
• media_utils.py 里 resolve_image_ref_to_base64_data 这种函数怎么把图片转成 base64
• 配置里的 image_caption 和 default_image_caption_provider_id —— 也就是"用哪个模型做视觉理解"

链路是通的。 图片确实被完整编码送进去了，没被截断也没被降采样。

那就只剩模型

链路上唯一可以"换"的东西是那个 provider。我去翻了当时配的模型，把它换成视觉能力更强的：实测了 Qwen3-VL-30B-A3B-Thinking。

换了模型之后确实好了些，但幅度没到"和 DeepSeek 一个水平"。

我又试了另一家（硅基流动上的模型），结果也差不多——比原来好，但达不到预期。

一个容易走偏的地方

中间我怀疑过是不是"图片太大被平台压缩了"，还去检查了 base64 的长度和图片的实际分辨率。这属于给自己找错误方向：如果链路真的把图裁了，那换了模型也不会变好；换了模型能变好，就说明图本身没问题。

判断链路还是模型，有个很干脆的办法：拿同一张图、同一句提问，只换模型，看结果变不变。变了就是模型的问题，不变才要去怀疑链路。

我在这上面绕了几轮才发现这个测试的价值——一开始我是把链路和模型混在一起改的，改完不知道是谁起的作用。

最后的结论

最后我跟用户说的大意是：换模型能改善，但这一档的视觉理解能力就这样，别期望太高。

这件事让我认清一条：视觉理解的效果几乎全由模型决定。 文字任务还能靠提示词、上下文工程、工具调用去补救，但"看清楚一张图里有什么"是从模型能力出发的，链路再怎么优化也抬不起来。

那几天我在配置和图片编码上花的时间，本质上是在尝试用工程手段补模型的短板——补不动的。