[Bug Report] llm-deepseek 适配器把 inputModalities 硬编码为 ["text"]：自定义网关的视觉模型永远无法通过图片受理门控（#245：选了多模态模型仍提示"模型不支持图片"）

[DRAG0NM]

摘要

@deepseek-ai/dsh-llm-deepseek（所有 OpenAI 兼容网关的默认适配器路径）的 modelInfo() 对目录中的每一个模型（无论是否视觉模型）都返回硬编码的 inputModalities: ["text"]（lib/index.js L442）。图片受理门控（dsh-host-apiproxy session.prompt L2842-2848）据此判定"模型不支持图片"并拒绝：Model "X" does not support image input.。因此通过该适配器接入的第三方视觉模型（claude/gpt/qwen 系列经兼容网关）永远无法粘贴图片，即使模型本身支持多模态——这是 #245 的完整根因（用户已选多模态模型仍被拒）。模型目录 schema（id/name/description/contextWindow/maxTokens）与 Web 设置 UI 都不存在 input/模态字段，用户没有任何 UI 途径声明视觉能力；评论区给出的 input: ['text','image'] YAML workaround 只对读取该字段的适配器（如 pi-ai）生效，对 deepseek 适配器无效（源码确认其 modelInfo 忽略目录 input 字段）。

复现步骤

1. 通过 llm-deepseek 兼容路由（llm-deepseek.baseURL 指向第三方网关）配置一个支持视觉的模型（如 qwen-vl/claude 经网关）。
2. 在该模型被选中的会话里粘贴一张图片并发送。
3. 结果：提示 Model "<model>" does not support image input.（图片粘贴之后，选择了支持多模态的llm，但是还是提示 模型不支持图片 #245 原文），图片被受理门控拒绝——尽管模型实际支持图片。
4. 对照：改用读取目录 input 字段的适配器（pi-ai 族），目录里声明 input: ['text','image'] 后可通过——证明断点在 deepseek 适配器的硬编码。

根因（源码定位，rc.6）

1. dsh-llm-deepseek/lib/index.js modelInfo()（L436-444）：

   function modelInfo(provider, model) {
     return { provider, id: model.id, name: model.name ?? model.id,
       ...model.description === void 0 ? {} : { description: model.description },
       inputModalities: ["text"] };        // ← L442：无条件硬编码
   }

   resolveModel()（L505-526）对已配置模型返回 modelInfo(provider, configured)——
   目录里即使写了 input: [...] 也被忽略（schema catalogModel L642-648 只有
   id/name/description/contextWindow/maxTokens，无 input 字段）。
2. dsh-host-apiproxy/lib/index.js 图片受理门控（L2838-2848）：

   const modelInfo = await ctx.llm.resolveModelInfo(current.provider, current.model);
   if (modelInfo.inputModalities !== void 0 && !modelInfo.inputModalities.includes("image"))
     return err(request, { code: "attachment-error",
       message: `Model "${current.model}" does not support image input.`, ... });

   门控逻辑本身合理（信任目录声明），错误在于上游永远声称只支持文本。
3. 产品缺口：Web 设置页的模型编辑器字段（settings-models 客户端 schema）与
   deepseek 目录 schema 均无模态字段，用户无法通过 UI 声明视觉能力；错误文案
   也没有任何"如何声明图片支持"的指引。

建议修复

方案 A（推荐）· 目录支持 input 字段并贯通：catalogModel schema 增加
input: z.array(z.string())（可选）；modelInfo() 改为

inputModalities: model.input ?? ["text"]

resolveModel 的未配置分支保持 ["text"]。Web 设置 UI 的模型编辑表单增加
"输入模态"多选（text/image）。一处 schema + 一处 adapter + 一处表单，第三方
视觉模型即可在 UI 内声明并通过受理门控。

方案 B · 门控对"未声明模态"放行：inputModalities === undefined 时不再拒绝
（当前逻辑 undefined 已放行；但 deepseek 返回的是 ["text"] 而非 undefined）。
若适配器统一"未声明即 undefined"，门控自动只拒绝显式声明无图片的模型。
与 A 二选一或叠加。

方案 C（文案）：拒绝消息附修复指引："若该模型支持图片，请在模型配置中声明
input 模态（当前适配器不支持此字段的需升级/换适配器）"。

影响

• 通过 llm-deepseek 兼容路由使用任何第三方视觉模型的用户，图片粘贴 100% 被拒
  （图片粘贴之后，选择了支持多模态的llm，但是还是提示 模型不支持图片 #245；claude/gpt/qwen 视觉模型经自建网关均中招）
• 与 Idea: 纯文本模型贴图不再被拒——受理时转本地路径交给视觉技能 / accept pasted images with text-only models (fix ready on fork) #427/无法识图 #893（纯文本模型拒图）同族但机制不同：那两例是模型确实不支持；
  本例是适配器把支持视觉的模型谎报为纯文本——修复后多模态模型可用
• 视觉工作流（截图反馈、UI 走查、OCR 类技能）在 deepseek 兼容路由上整体不可用

环境

• 源码定位：0.1.0-rc.6（dsh-llm-deepseek/lib/index.js L436-444/L642-648、
  dsh-host-apiproxy/lib/index.js L2838-2848；Node v24.16.0，Windows 11）
• 原报告：图片粘贴之后，选择了支持多模态的llm，但是还是提示 模型不支持图片 #245（mac air m4；1 条评论仅给 workaround，无源码分析）

验证材料

• 根因节行号与代码片段：L442 硬编码、L505-526 的 resolveModel 直通 modelInfo、
  L642-648 的 schema 缺 input、L2842-2848 的门控判定
• 逻辑闭环：门控信任目录 → 目录被 modelInfo 覆盖为 ["text"] → 视觉模型必被拒
• 评论者 workaround 的适用边界已澄清（pi-ai 族适配器读 input，deepseek 不读）

---

First source-located analysis of discussion #245. Happy to open a PR with fix option A.