dsh：注册 (modlens vision) 变体后（默认开启），普通 DeepSeek 纯文本档的粘贴接管永不触发

[Taz-dingo]

环境

• @liustack/modlens 3.16.3（dsh 插件；已 diff 确认 3.16.4 的 dsh/index.js 与 3.16.3 逐字节相同，问题未变）
• @deepseek-ai/dsh 0.1.0-rc.6，web profile，macOS
• 会话选中的模型：普通档 deepseek-official / deepseek-v4-pro（非变体）

预期行为

按 3.14.0 changelog 的承诺（"dsh: pasting into a text-only model now just works — the paste becomes a file path"），选中普通 DeepSeek 纯文本模型时贴图，应当被浏览器半边接管：图片字节走回环 /modlens/paste 路由，输入框收到纯文本文件路径，DSH 的图片准入检查根本不会触发。

实际行为

只要视觉变体包装器处于注册状态（默认就是），任何 DeepSeek/GLM 纯文本模型的接管判定都永远不会通过。贴图保持原生路径，撞上 DSH 自己的准入闸门，报 MODEL_DOES_NOT_SUPPORT_IMAGES（"当前模型不支持图片"）。(modlens vision) 变体路径本身工作正常，本 issue 只针对普通档的 paste-to-path 流程。

重启后的活进程实测（所有包含 deepseek 模型名的标签一律 false）：

GET /modlens/paste?model=DeepSeek-V4-Pro   -> {"takeover":false}
GET /modlens/paste?model=deepseek-v4-pro   -> {"takeover":false}
GET /modlens/paste?model=DeepSeek-V4-Flash -> {"takeover":false}

默认配置下，任何可包装的纯文本模型都拿不到 true。

时间线（回归定位）

• 3.10.0（2026-08-14）：(modlens vision) 变体上线，包装器复用上游模型 id 并声明图片输入；
• 3.14.0（同日）：paste-to-path 接管上线，changelog 记载以纯文本 DeepSeek-V4-Flash 端到端验证通过，普通档接管当时可用；
• 3.16.0（同日）：裁决搬至服务端（修复客户端正则误劫持视觉模型贴图），引入"标签命中的模型中任一声明图片输入即否决"，回归自此引入；
• 3.16.4：pasteTakeoverVerdict 与包装器逻辑未变，问题延续至今。

根因

dsh/index.js 里两条规则互相冲突：

1. registerVisionProvider 注册变体时原样复用了上游模型的 id：

const withVision = (info) => ({
  ...info,                       // id 保持原样，例如 "deepseek-v4-pro"
  provider: providerId,
  inputModalities: ['text', 'image'],
})

2. pasteTakeoverVerdict 的否决规则：选择器标签中出现的任何模型，只要声明了图片输入就一票否决：

if (!Array.isArray(modalities) || modalities.includes('image')) {
  return false
}

选中普通 DeepSeek-V4-Pro 时，标签 DeepSeek-V4-Pro 同时命中两个模型：

• deepseek-official 的 deepseek-v4-pro —— 纯文本，确认通过；
• 包装器双胞胎 deepseek-modlens 的 deepseek-v4-pro —— 声明图片输入，一票否决。

包装器默认开启（visionProvider !== false），因此 deepseek/glm 系纯文本模型的接管永远无法生效。"未知即保守"的策略本身没错，但这个双胞胎是插件自己注册、自己认识的（判定函数里已经用正则特判过 (modlens vision) 标签），被自己的双胞胎误杀属于无意的自我冲突，而不是对未知模型的保守。

建议修法

1. 给变体模型用独立 id（如 deepseek-v4-pro-vision），在 resolveModel/stream 请求时再映射回上游 id；或
2. 在 pasteTakeoverVerdict 里排除本插件自己的包装器 provider（deepseek-modlens、modlens-*）——既然已经用正则特判了 (modlens vision) 标签，说明双胞胎在代码里是显式可知的。

[liustack]

诊断完全正确，两条冲突规则你也贴对了。3.16.5 已发布。

我先用真实 apply() 路径做了单变量复现，确认是这个机制而不是别的：

变体包装器 开启（默认）  DeepSeek-V4-Pro -> takeover: false
变体包装器 关闭          DeepSeek-V4-Pro -> takeover: true

根因如你所说：withVision 用 ...info 展开时只改了 name 不改 id，而裁决同时拿 name 和 id 比对标签。带后缀的 name 匹配不上普通标签，原样保留的 id 精确命中，然后双胞胎声明的图片输入一票否决。这个功能自 3.16.0 起在每一个默认安装里都是死的，六个版本没人发现，因为 pasteTakeoverVerdict 一个测试都没有。

修法采用你的方案二，但比「按 provider 名字排除」更严格。原因是评审指出按名字排除有两个缺口：自定义 providerId 会漏，外部 provider 也可能撞上 modlens-* 这种名字。现在需要两个证据之一：

• 这个实例实际注册成功的 provider id（随每个包装器落地时记录，涵盖自定义 providerId）
• 模型名带 (modlens vision) 标记，且 provider id 符合本插件生成 id 的规则（同进程里另一个实例的包装器，它按同样规则生成 id）

只有标记不算数：任何 provider 都能把那串字写进模型名。评审确实构造了一个外部 provider，模型声明支持图片、名字借用了标记，保守策略必须否决它，现在也确实否决。

方案一（独立 id）没采用：resolveModel 要求返回的 metadata id 与请求 id 相等，stream 也得映射回上游，还要处理已持久化的旧选择，是一次迁移而不是最小修复。

配套补了 11 个集成测试，走真实的 apply → 路由 → 裁决路径，registry 按真实安装的形状搭：普通标签接管、变体标签保留原生、外部真视觉模型仍否决、模态未声明仍否决、catalog 读不到仍否决、重复挂载、自动发现路由、自定义 providerId。每条判据都做了变异测试，删掉任意一半都有测试变红。

更新时注意：你现在是 3.11.0，直接跑 add @liustack/modlens@latest 会拿到 3.9.1，比你手上的还旧。pnpm 11 默认扣住最近 24 小时内发布的版本，@latest 跳不过去（我们文档原先写反了，一并在 3.16.4 更正）。点名版本号：

npx -y @deepseek-ai/dsh plugin --profile web add @liustack/modlens@3.16.5

装完重启 dsh。谢谢你，这个报告把两条规则并排贴出来，省掉了全部定位时间。