[Idea] 图片上传被模型目录能力硬性拦截：主模型无视觉模态时也应允许附件（以链接/路径交给工具处理，类似 opencode 做法）

[MicroHEROX]

背景

我是 dsh-koboldcpp-hands 插件的作者。该插件为 dsh 提供 koboldcpp_run / koboldcpp_vision 两个工具，把 OCR、图片分析、多图对比等视觉任务交给本地 KoboldCpp 多模态模型处理。其中 koboldcpp_vision 的一个重要输入来源就是"当前会话附带的图片"（通过 attachment 服务读取）。

问题

当用户在主对话中上传图片时，如果当前主模型在 pi-ai 模型目录中声明的 input 模态不包含 "image"（例如 opencode-go 下的 deepseek-v4-flash / deepseek-v4-pro，目录声明 "input": ["text"]），服务端会在消息进入会话之前直接拒绝整条消息：

1. dsh-host-apiproxy 的 prompt 接口发现消息含 image 部分后，调用 resolveModelInfo(provider, model) 查询当前模型的输入模态；
2. dsh-llm-pi-ai 从 pi-ai 内置目录（@earendil-works/pi-ai/dist/providers/data/.json）返回 inputModalities；
3. inputModalities 不含 "image" → 返回 attachment-error / MODEL_DOES_NOT_SUPPORT_IMAGES；
4. 前端 dsh-client-ui-conversation 渲染为"当前模型不支持图片，请切换支持图片的模型"。

对工具型视觉工作流不友好

1. 图片从未进入会话：拒绝发生在附件入会话之前，视觉工具（包括 koboldcpp_vision 的"读取会话最近附带图片"路径）永远拿不到图——即使主模型有视觉工具也派不上用场。
2. 混淆了"主模型原生视觉"与"工具视觉"：主模型不需要原生多模态能力；只要它拥有视觉类工具或文件读取工具，就完全可以把图片交给工具处理。opencode 等 agent 产品的做法是：无论模型是否声明视觉模态，都把图片以链接/路径形式随消息给到模型，由模型自行决定如何处理。
3. 误伤纯文本模型用户：用户明明配好了本地视觉模型（例如通过插件），主模型只是恰好选了纯文本的 deepseek-v4-flash，结果连图都传不上去，只能绕过 UI 手动给路径，体验很差。

建议

• 放宽限制：当 inputModalities 不含 image 时不再硬性拒绝；允许图片作为附件进入会话，并以"链接/路径"形式（而非像素数据）呈现给主模型，由模型决定是否调用工具读取（opencode 风格）。
• 或提供配置开关：例如设置项 allowImageAttachmentsForTextOnlyModels，把硬拒绝降级为提示/警告。
• 实现成本不高：附件已由 dsh-attachment / dsh-attachment-local 持久化，dsh-llm-pi-ai 已有 resolveAttachments 管线，路径是现成的。

复现

• dsh 0.1.0-rc.6（web profile）
• provider: opencode-go，model: deepseek-v4-flash（目录 input: ["text"]）
• 步骤：上传任意图片 → 发送 → 立即被拒（"当前模型不支持图片，请切换支持图片的模型"）
• 同目录声明 input: ["text","image"] 的模型（minimax-m3、qwen3.7-plus、kimi-k2.6、kimi-k3、mimo-v2.5、grok-4.5 等）不受影响

相关社区反馈

社区里已有类似声音（"聊天框的输入检测比插件的时机更早，不换模型无法 hook"、"多模态模型放进 dsh 壳子无法视图"），说明这不是个例。希望官方考虑放宽这个限制，给视觉工具类插件留出空间。谢谢！

[Electricitysheep]

同意——主模型无视觉时附件应允许以链接/路径交给工具处理（opencode 做法），而不是硬拦。这和社区视觉桥方案（#1153 路由/#1269 GLM MCP）是同一需求的两面。模型能力边界处理我们第 8 章有整理：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/08-tools-context.md

koboldcpp 视觉插件已收录进手册生态章节。

[xujipm]

补充：一个可落地的通用方案设计（对齐 Hermes / opencode 的 text-mode 图片降级）

同意楼主的分析——根因是 MODEL_DOES_NOT_SUPPORT_IMAGES 在图片进入会话之前就硬拒绝，导致工具型视觉工作流（koboldcpp_vision、以及社区各种 vision-bridge 方案）永远拿不到图。这里补充一个比"简单放宽限制"更完整的方案设计，参考了 Hermes 的 image_input_mode: auto|native|text 机制。

一、核心思路：区分"主模型原生视觉"与"工具视觉"

• 原生视觉：主模型 inputModalities 含 image → 图片以像素形式随消息入会话（现状，不动）。
• 工具视觉（text-mode 降级）：主模型纯文本 → 图片仍然落盘（attachment 服务已支持），但呈现给主模型的不是像素，而是：
  1. 图片的本地路径/链接（模型可调工具读取）；
  2. 可选：调用配置的 vision 后端（如 DashScope Qwen-VL / 本地 KoboldCpp / OpenRouter 视觉模型）预先生成一段文本描述，prepend 到用户消息——模型看到的是"文字版图片"。

这正是 Hermes text 模式的做法（vision_analyze 先行、模型只见文字摘要），也是 opencode 的"路径交给工具处理"思路。

二、建议的配置形态

在 settings 增加一个枚举：

agent:
  imageInputMode: auto   # auto | native | text

值	行为
auto	主模型支持 image → 原生；不支持 → 若配置了 auxiliary vision 后端 → 自动降级为 text；否则保留现状的拒绝并给出清晰提示
native	强制原生，不支持则报错（当前行为，显式选择）
text	强制降级：图片落盘 + 路径提示（+ 可选自动描述），主模型不必支持视觉

配套的 vision 描述后端（可复用现有 llm 服务，指向任意已注册 provider/model）：

auxiliary:
  vision:
    provider: dashscope        # 或 local-koboldcpp / openrouter 等
    model: qwen3.5-ocr

三、实现位置（关键：必须在入站检查之前/之内降级）

1. dsh-host-apiproxy 的 prompt handler：把 MODEL_DOES_NOT_SUPPORT_IMAGES 的硬拒绝替换为一次模式判定（decideImageInputMode）；
2. 判定为 text 时，仍然走 durablePromptContent（图片照常保存为 attachment），但组装给模型的 content 时把 image block 替换为 text block（路径提示 + 可选自动描述）；
3. read_image / 视觉类工具（koboldcpp_vision 等）依然能从 attachment 服务按引用读取原图——不需要图片以像素形式出现在消息里。

四、为什么纯插件方案不充分（回应评论区"不换模型无法 hook"）

图片被拒发生在 dsh-host-apiproxy 的 prompt 接口（host 层，先于 agent/tool 执行）。插件能 hook 的是 llm/stream waterfall 与工具执行，但消息入站这一环在插件可见之前就结束了——所以插件作者再怎么注册工具也拿不到图。这也正是楼主说的"输入检测比插件时机更早"。因此这个改动必须落在 host 层（apiproxy / llm 服务），官方合并或至少提供配置开关，社区插件才能在此基础上工作。

五、参考实现

我已在本地跑通一个最小实现（DSH 0.1.0-rc.6 + deepseek-v4-flash + DashScope qwen-vision 识别），效果：上传图片 → 不再被拒 → 图片落盘 → 模型收到 [用户上传了图片 (image/png 3824x1458)，已保存到本地文件: …] 路径提示 → 自动调用 vision 脚本识别并回复。完整 diff 与说明见：

• Gist: https://gist.github.com/xujipm/b13d3725d1bf63f23df7ef08e3e05910
• 关键点：
  • dsh-llm-deepseek 的 inputModalities 声明从 ['text'] 改为 ['text', 'image']（放行入站检查）；
  • 序列化时 flattenText 把 image block 渲染为包含本地路径的文本（imageBlockText），DeepSeek API 仍只收纯文本；
  • assertTextOnly 不再抛 UNSUPPORTED_CONTENT。

注意：上述"改 inputModalities"是本地快速验证的 hack，语义上不诚实（模型并不真正接受图片）。若官方采纳本方案，建议实现为"配置驱动的降级"（第二节的 imageInputMode），而不是谎报模型能力——这也是本方案与简单放宽限制的区别。

六、对官方的最小改动清单（若采纳）

1. packages/host/apiproxy：prompt / selectModel 的图片能力检查 → 接入 imageInputMode 判定；
2. 新增配置节（agent.imageInputMode + auxiliary.vision），注册到 settings；
3. 序列化层（各 adapter 或 llm 服务）提供 text-mode 渲染（路径提示 + 可选自动描述）；
4. 文档：config-catalog 增加条目。

---

补充人：xujipm（本地跑通验证，非官方人员）

[xujipm]

补充更新：参考实现已升级为官方风格（host 层配置驱动降级，不改 adapter）。

关键调整：

• 之前的快速验证改的是 dsh-llm-deepseek 的 inputModalities（语义不诚实的 hack，且会破坏官方 serialize.spec.ts 的 fail-closed 测试）；
• 正确做法是在 host 层（dsh-host-apiproxy） 做降级判定：新增 agent.imageInputMode（auto|native|text）+ 可选 auxiliary.vision 描述后端。需要降级时，图片照常经 durablePromptContent 落盘，但入会话语义从 image block 换成 text stand-in（含 attachmentId 引用，视觉类工具仍可经 ctx.attachments.readImage 读原图）；adapter 的 inputModalities 声明与 fail-closed 行为完全不动，官方测试保持全绿。

Gist 已更新为多文件参考实现（含完整源码 + patch + vitest 测试）：
https://gist.github.com/xujipm/b13d3725d1bf63f23df7ef08e3e05910

• image-input-mode.ts — 新模块：parseImageInputMode / modelAcceptsImages / decideImageAdmission / degradeImageBlocks（纯逻辑，20 项断言全过）
• api-proxy.patch — 对 prompt handler 的最小侵入改动
• image-input-mode.spec.ts — vitest 测试

核心判定逻辑（auto 模式）：模型支持 image → 原生；不支持 → 配置了 vision 后端 → 降级 text；否则保持现状拒绝。这样默认行为不变（fail-closed），需要工具型视觉的用户显式 opt-in，社区插件（koboldcpp_vision 等）也能在图片入会话后拿到 attachment 引用。