【建议】纯文本模型收到图片时提供“落盘+文字标记”回退，便于子 Agent / 视觉脚本接管

[golfygao]

背景

当会话选中的模型不支持图片输入（inputModalities 不含 image，例如 deepseek-v4-flash）时，web 通道会在消息准入层直接拒绝图片消息（MODEL_DOES_NOT_SUPPORT_IMAGES），图片不会落盘，Agent 完全拿不到任何信息。于是“文本主模型 + 外部视觉能力（视觉脚本 / 视觉子 Agent）”的组合只能自己绕路（比如让用户把图片放进工作区目录，再手动触发）。

已有的参照实现

同一生态里的 deepseek-harness-qqbot 插件在 imageInputMode: auto 下，遇到纯文本模型并不会丢弃图片：它先把图片存为 Harness attachment，再把消息降级为文字标记（Stored as Harness attachment sha256:...）。Agent 拿到 attachmentId 后可以自行调用视觉工具处理。这个回退模式很合理，建议 web 通道（或全局）提供等价策略。

具体建议

1. 给准入层加一个可配置的回退策略（例如 imageFallback: "store-and-annotate"，可通过 settings 开关，默认可考虑开启）：
   • 纯文本模型 + 图片消息 → 不拒绝，照常走 durablePromptContent 落盘；
   • 图片块替换为文字标记（含 attachmentId、文件名、媒体类型，最好附带可解析的本地路径）；
   • 视觉模型的行为完全不变。
     这基本就是把 qqbot 插件 inbound 的 fallback 逻辑上移到 web 网关（dsh-host-apiproxy 的 prompt/admit 处理），改动很小，我们本地对照源码评估约十几行。
2. （可选、更通用）暴露一个“消息入站预处理”的 cordis 钩子/服务：插件可在消息进入 agent inbox 前把图片块替换为文字描述（自行调用视觉 API，或让子 Agent 用视觉模型读取）。目前 dsh-agent 层没有这个挂点，纯插件无法绕过 web 准入层。

用例

主模型用 DeepSeek 文本模型，另配一个视觉脚本（如调用 Gemini 的 vision API）或给子 Agent 配置视觉 provider（dsh-tool-subagent 的 agentOptions.provider/model 已支持）：用户在 web 直接发图 → 落盘 + 标记 → 主 Agent 触发子 Agent / 脚本读图 → 基于描述作答。这个工作流我们已在本地验证可行，只差网关这一扇门。

[etali]

顶

[shinjiyu]

这扇门确实在准入层：纯文本模型（如 Flash）贴图会被 MODEL_DOES_NOT_SUPPORT_IMAGES 直接拒，图不落盘，后面的视觉脚本 / 子 Agent 都接不到。

官方若把 imageFallback: store-and-annotate 收进 web 网关最好。在那之前，插件侧可以先把门打开——只做受理：贴图落成本地路径 / attachment，主模型仍是纯文本，不把 input: [text, image] 当成官方 chat-completions 已解锁，也不是 vision_* / read_image 工具箱。

dsh plugin --profile web add github:shinjiyu/dsh-plugin-multimodal

装完要重启 dsh web。说明在 #1709

[weijiafu14]

这个场景现在也有一条已经跑通的插件方案，而且不只做到“落盘+标记”：pi2dsh@0.11.0 会为每条纯文本模型路由自动注册独立的 <route>-vision 伴生路由，在伴生路由上完成图片准入、附件物化和发往文本 adapter 前的图片块剥离，不修改原始 DeepSeek 路由的能力声明。

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add @kassing/pi-vision

重启后在模型选择器里选择 DeepSeek + Vision Bridge 分组，Web 可以直接粘贴图片。后续有两种完整链路：

1. @kassing/pi-vision 在 before_agent_start 自动调用配置的视觉模型，把识图结果作为 DSH context injection 注入，纯文本 DeepSeek 直接基于描述回答；
2. 安装 pi-vision-tool 时，Agent 按需调用 describe_image；没有这两个包时，已有的 MCP/skill/script 只要能读文件路径，也能接到物化后的图片路径。

我们已经在真实 DSH Web loop 验证过：粘贴蓝色测试图 → 自动视觉分析注入 → deepseek-v4-flash 一轮、零工具直答 blue。安装、公开视觉端点配置和截图都在 完整演示 #2040。

所以这条建议里的用户工作流目前可以不改 core 先完整使用；core 将来提供统一入站钩子，插件实现会更薄。

[golfygao]

感谢各位指路，来更新一下这条建议的落地情况：

我们已经按 dsh-vision-proxy（Flyvhidbwo）的方案跑通了：deepseek-vision 伴生路由设为默认，DeepSeek 负责全部文字推理，图片经 OpenAI 兼容端点转写后合并进对话。实测 web 直发图、转写、作答全链路正常，配置几分钟完成。

说实话有点过意不去——两位作者亲自来指路，两位的成果我们却没有实际用上。但这纯属时间上的巧合：动手安装时我们先看到了 dsh-vision-proxy 的 README，装完验证通过就留了下来，并不是把各家方案摆在一起比较之后的取舍，更不是两位方案有什么不足。

两位的方案我其实都仔细读过：

• dsh-plugin-multimodal 零运行时依赖、代码极简克制，在 adapter 层把整件事收敛得干净利落；
• pi2dsh 不改动原路由的能力声明，还把 Pi 生态的兼容层做成了完整体系，注入式识图和按需工具两条链路都配了完整演示，工程深度明显更深。

社区里三条路线并存，各自在适配层、伴生路由、桥接层找了不同的切入点，恰好都落在同一个问题上——图片入站缺少统一的预处理挂点。如果 core 将来提供官方 ingress hook，这类插件都能简化不少。再次感谢两位，也期待官方早点把这扇门开进 core。