dsh-auto-vision

dsh-auto-vision

中文 | English

让不支持图片输入的模型(如 deepseek-v4-pro、deepseek-v4-flash)也能接收截图。 粘贴的图片由配置的视觉模型自动识别,描述以折叠的上下文条目写入会话历史——你的原始消息保持原样。模型自己能看图时(目录里声明了 image 输入)插件完全不干预,图片原样交给模型。每个会话都生效;与模型相关,与会话无关。纯插件 + 配置实现,不修改 DSH 源码。

工作原理

1. GUI 放行:图片准入检查发生在插件之前,且只相信模型声明。要么该模型在目录里已声明 image 输入,要么开启 autoDeclareInput: true 让插件在启动时与适配器变化时替已配置模型补上声明(原生视觉模型同样需要声明才能收到图)。
2. 准确模型快照(插件):监听 system-prompt/assemble(pre-step 前、同一步发生),从 assembly.variables 读取 GUI 此刻选择的准确 provider/model(由 DSH 的 model-selection 机制写入)。
3. 放行判定(插件):agent/pre-step 时先判定当前模型能否自己看图——命中 nativeVision 白名单,或目录条目声明了 image 输入(passThroughDeclaredVision,默认开)——能看图就完全不干预,图片原样交给模型。判定结果按 provider/model 缓存,适配器变化时清空。
4. 拆分注入(插件):判定为不能看图的模型 → 原消息完全保留(图片照常显示,和 vision-exp 会话一样),识别描述作为独立的 notice 上下文消息追加其后(GUI 渲染为折叠行:摘要 + 展开看全文)。两条消息都由 agent loop 原样写入会话历史,识别结果天然持久化,后续多轮都能引用同一条图片记忆。agent/pre-step 与下一步共用同一个判定,两者不会打架。
5. 请求级剥离(插件):发给模型的请求在 llm/stream 阶段把图片块替换为短占位文本(完整内容在描述消息里,不重复消耗 token),所以图片永远不会到达网关;GUI 显示不受影响。
6. 识图跟随分组:识图路由自动跟随当前会话模型的分组——在 sub2api 分组里发图,就用 sub2api 分组里的视觉模型识图(走该分组的 key);切到官方分组,就用官方视觉模型(走官方 key)。分组在白名单里没有视觉模型时,回退到 visionProvider/visionModel 默认路由。

行为

• 触发条件(三个同时满足):
  1. 进入 step 的消息含有图片块(顶层或工具结果内);
  2. 当前模型不在 nativeVision 白名单内;
  3. 当前模型的目录条目没有声明 image 输入(或 passThroughDeclaredVision: false)。
• 图片照常显示:你的消息气泡里图片缩略图保留(和 vision-exp 会话一样),只是发给模型的请求把图片换成了短占位;完整识别内容在紧随其后的折叠上下文条目里。
• 递归处理工具结果:read_image 等工具结果里内嵌的图片同样会被识图替换(声明 input: [text, image] 会解锁 read_image 的执行门槛,这一层替换保证模型主动读的图也不会直达网关)。
• 每次发图都会识别,每次识别结果都会追加(不覆盖)。新截图的结果带时间戳追加在历史最后,模型以最新一条为主;旧结果仍在上下文中可引用。
• 识别失败(网络/网关错误)不阻塞消息:失败说明进描述条目,你的文字照常送达模型;用户取消则原样中止。

安装

构建产物 lib/ 已提交进仓库,无需构建步骤,装来即用:

# GitHub 安装
dsh plugin --profile web add github:soarGuo/dsh-auto-vision

# npm 安装(发布后)
dsh plugin --profile web add dsh-auto-image

# 或 tarball 安装(在仓库目录里先 pnpm pack)
dsh plugin --profile web add ./dsh-auto-image-0.2.0.tgz

安装后重启 DSH。

配置

模型声明零手动配置。 只要模型自己的目录条目声明了 image 输入(原生视觉模型通常都声明了),插件就无需任何配置:准入放行,且带图时插件完全不干预。只有当某个模型确实支持图片、但目录条目没声明时,才需要开启 autoDeclareInput: true 让插件替它补声明(它会扫描 llm-pi-ai / llm-deepseek 段,幂等写入)。

插件自身配置(均可省略,以下为默认值):

auto-vision:
  visionProvider: deepseek-official            # 默认识图路由
  visionModel: deepseek-v4-flash-vision-exp    # 默认视觉模型
  nativeVision:                                # 原生视觉白名单:带图时不干预,也是识图路由的候选
    [
      { provider: deepseek-official, model: deepseek-v4-flash-vision-exp },
      { provider: deepseek, model: deepseek-v4-flash-vision-exp }
    ]
  passThroughDeclaredVision: true              # 目录声明了 image 的模型直接放行原图;false 则只认白名单
  autoDeclareInput: false                      # 给未声明的模型补 image 声明(会污染模型目录,按需开启)

settings.yaml 修改即时生效(热重载)。识图路由也可指向任一网关的视觉模型:

auto-vision:
  visionProvider: deepseek
  visionModel: deepseek-v4-flash-vision-exp

手动声明(仅当 autoDeclareInput: false)

以某 OpenAI 兼容网关路由为例:

llm-pi-ai:
  providers:
    {
      my-gateway:
        {
          displayName: My Gateway,
          models:
            [
              { id: my-pro, name: My-Pro, input: [ text, image ] },
              { id: my-vision, name: My-Vision, input: [ text, image ] }
            ],
          baseURL: https://example.com/v1,
          apiKeyEnv: MY_API_KEY
        }
    }

依赖、权限与失败边界

运行时依赖:无。 manifest 不声明 dependencies / optionalDependencies。插件在运行时只导入宿主已经提供的官方模块:

其余 @deepseek-ai/* 只在类型层引用,编译后不产生 import。插件不捆绑依赖,不含原生制品,要求的 Node 版本与 DSH 宿主一致(^22.19.0 || >=24.0.0)。

权限边界。 插件只经 DSH 的公开服务工作,不直接触碰系统资源:

唯一会写入的地方,是经 ctx.settings.update() 给你已配置的模型补 input: [text, image] 声明(可用 autoDeclareInput: false 关闭)。这是 DSH 的公开设置接口,写入的是模型能力声明,不涉及凭据字段。

外部服务。 识图会调用 visionProvider / visionModel 指定的模型路由,产生一次真实的模型请求与相应计费;该请求由 DSH 适配器发出,使用你为该路由配置的凭据。除此之外插件不联系任何第三方服务。

失败边界。

• 识图失败(网关错误、超时、限流):不阻塞你的消息。失败说明写进描述行(如 [识图失败:...]),文字照常送达模型。
• 用户取消:识图调用随取消信号中止并原样上抛,不产生描述行。
• 没有可用的视觉模型:该轮不识别,消息仍原样送出(被桥接的模型看不到图片内容)。
• 配置段缺失或非法:回退到内置默认值,不影响插件加载。
• 插件被停用:见下方"注意事项"——此时不要再向被桥接模型发图。

注意事项

• 声明 input: [text, image] 后,GUI 会把被桥接模型显示为"支持图片";实际图片由插件桥接,不会发给网关。
• 插件停用后不要向被桥接模型发图:图片会直达网关并被拒绝。先恢复插件或切到原生视觉模型。
• 官方路由(deepseek-official)的模型如需桥接,同样在 llm-deepseek.models 里声明 input: [text, image]。

卸载

dsh plugin --profile web remove dsh-auto-image

重启 DSH。

开发

pnpm install
pnpm test        # vitest 单元测试
pnpm typecheck   # 类型检查
pnpm build       # 重建 lib/(发布前记得提交构建产物)