User-configured vision ability is ignored by isCanUseVision — models absent from model-bank can never use native vision

快速结论：该问题发生在 LobeChat 自托管（Docker）环境中，当模型不在内置 model-bank 列表中时，界面上的 Vision 开关虽然开启且已保存，但 isCanUseVision 仍从其它来源判断能力并返回 vision=false，导致图片被剥离。优先检查模型行是否被误判为 preference-only 而被过滤，或 abilities.vision 是否真正写入数据库。

适用环境：LobeChat v2.2.15、Self hosting Docker、Web 桌面浏览器（Edge）、Windows 操作系统、自定义 OpenAI-compatible Provider。

最快修复方案：暂无确认的一步修复方案。Issue 仅确认了问题现象和代码路径，尚未给出已验证的修复补丁。

注意事项：以下解决方案多为基于代码分析的推测，尚未在 Issue 中经过实际验证；isPreferenceOnlyRow 过滤器是否直接影响运行时 enabledAiModels 仍需确认。

问题场景

用户通过 Docker 自托管 LobeChat v2.2.15，在 Web 端创建自定义 OpenAI-compatible Provider，并添加了一个不在内置 model-bank 中的视觉模型（如 deepseek-v4-flash-vision-exp）。用户在界面中打开了该模型的 Vision 开关，开关显示为开启且值已保存，但实际发起请求时，上下文引擎仍判断为无视觉能力，将图片从请求负载中剔除，并在系统提示中注入一行说明模型“看不见”。该问题与具体 Provider 无关，只要是 model-bank 中没有条目的模型（包括自定义 Provider 下的任何模型、以及上游尚未收录的新发布视觉模型）都会复现。

报错原文

User-configured vision ability is ignored by isCanUseVision — models absent from model-bank can never use native vision

Native media input capabilities: vision=false, video=false, audio=false

原因分析

可能原因：isCanUseVision 函数完全依赖 getEnabledRuntimeModel(model, provider)?.abilities?.vision 来判定视觉能力，默认值为 false。它读取的 abilities 对象来自服务端 AiInfraRepos.getEnabledModels 拼装的 enabledAiModels 列表。代码中存在两条路径：

有 model-bank 条目的模型：用户数据库行会与内置卡片合并；当用户自定义的 abilities 非空时使用用户配置，否则回退到内置卡片的 abilities。
无 model-bank 条目的模型（自定义 Provider、新发布模型）：该行走 appendedUserModels 路径，理论上是直接透传数据库行上的 abilities JSON，不做任何合并或回退。因此界面开关正确写入 abilities.vision = true 后，理论上应当能传到运行时。

实际不起作用，说明断点要么在“写入侧”（Vision 开关没有真正持久化到数据库行的 abilities.vision 字段），要么在某个过滤环节。候选嫌疑包括 isPreferenceOnlyRow 过滤器——它会剥离那些只带有 config.chatConfig 且没有用户可见标识的行；如果模型行被误判为仅偏好类，就可能在 getAiProviderModelList（设置列表页）中被过滤掉，但该过滤器是否直接影响 getEnabledModels 尚待确认。这与另一类已报告问题吻合：#17040 描述了原生视觉模型被错误路由到兜底的视觉理解系统，#17704 记录了 Claude Haiku 4.5 通过自定义 OpenAI-compatible Provider 使用时出现同样的 vision=false 不匹配——已确认自定义 Provider 的模型即使模型 ID 与已知条目一致，也不会自动继承 model-bank 的能力。

环境排查

确认 LobeChat 版本是否为 v2.2.15 或更高（Issue 确认截至该版本仍存在）。
确认部署方式为 Self hosting Docker。
确认目标模型在 model-bank 中是否无对应条目——可在模型列表中观察条目是否显示为“裸 ID”（无显示名、无发布日期、无上下文长度徽章）。
如使用自定义 OpenAI-compatible Provider，确认该 Provider 下即使是名称与已知模型相同的条目也不保证能力。
检查数据库中该模型行的 abilities JSON 是否包含 vision: true。
检查更新模型配置的 updateAiModelsConfig action 通过服务写入的参数是否被完整传递。

解决步骤

在界面中开启目标模型的 Vision 开关，保存后在数据库中检查该模型的 abilities 字段是否确实写入 vision: true——这用于定位断点在写入侧还是读取侧。
若数据库已正确写入，可优先尝试排查读取侧：检查该模型行是否被 isPreferenceOnlyRow 过滤器误判。如果该行只带有 config.chatConfig 而没有用户可见标识（如显示名），可能在列表中无法显示；尝试补充模型的自定义名称等身份信息后再测试。
检查服务端拼装 enabledAiModels 时的产出结果，确认该模型是否出现在运行时列表中、abilities 是否完整透传。
关注上游修复：Issue 指出该缺口影响所有 model-bank 未收录的模型，建议同时跟踪 #17040（原生视觉模型被错误路由到兜底系统）、#17704（Claude Haiku 4.5 在自定义 Provider 下 vision=false）以及 #17708（自定义 Provider 自动继承已知模型 ID 的 model-bank 能力），等待官方统一修复。
若你有权修改代码，可考虑在 isCanUseVision 的判定逻辑中，将用户手动配置的 abilities.vision 也纳入参考来源，而非仅依赖 model-bank 的静态卡片。