读图能力看声明字段，并按模型逐个实测

更新于 2026-09-25

**模型能不能读图由两件独立的事决定：① 客户端读的那个声明字段（`modalities.input` 是否含 `"image"`）；② 该模型后端是否真的能读。两者都不能从「名字看着像视觉模型」推断出来。**

一、判定权在声明字段，不在「附件」标记

opencode 判定能否读图只看 modalities.input 是否包含 "image"；attachment: true 单独写没用。于是「配置里明明标了支持附件，模型却读不了图」的根因不是模型不行，而是消费方读的不是那个字段。

两个推论：

同一网关内部，模型能力不齐，不能按网关整体推断：

网关 / 模型	读图
`workbuddy-gl`：balanced / fast / default / primary / gpt-5.4·5.5·5.6 系列 / hy3 / hy4 / deepseek-v4.1-flash / kimi-k2.8 / kimi-k3	✅ 真读图
`workbuddy-gl`：`glm-5.3`	❌ 明确回复「不支持图片输入」
`deepseek`（官方）	✅ 真读图
`cli2api`（qwen）	❌ 不读图
`amd-radeon`	❌ 明确报错 `does not support image input`

结论：「这个网关支持读图」是个错的问题，正确的问题是「这个网关里的哪个模型支持」。这与模型可见性按入口分批同源 —— 可用性/能力都是按具体条目放量，不按账号或网关一刀切。

判定用真值，不用名字：喂一张双色图问颜色，答对才算真读图。名字里带视觉/多模态语义的模型也可能是空壳 —— 见能力被环境差异静默改变。
测不出来的必须记为未验证，不能按「应该支持」写进配置：deep-model / gemini-3.5-flash 返回空、b.ai 余额为 0、zcode 502 —— 这三类都是环境没给出结论，不是「不支持」。参见验不到的部分要显式记为未验证。