DeepSeek Harness Goes Multimodal: V4-Flash-Vision-Exp Guide
DeepSeek Harness now supports DeepSeek-V4-Flash-Vision-Exp for native image input. See the rc.8 to 0.1.1-rc.1 timeline, setup steps, limits, and vision plugins.
2026 年 8 月 21 日，DeepSeek 发布了首个原生多模态模型 DeepSeek-V4-Flash-Vision-Exp，DeepSeek Harness（dsh）在同一天的 0.1.1-rc.1 版本中就跟进支持。这个模型的文本能力与普通 V4-Flash 持平，定价不变，每张图片最多消耗 384 token。升级 dsh、在 Settings → Models 里选中 Vision 模型，你就可以在会话里直接粘贴或用 @ 引用图片——不再需要靠 OCR 硬凑视觉的插件绕路。
本文讲清楚这个模型到底是什么、dsh 的多模态支持是怎么在最近三个版本里逐步落地的、如何开启，以及目前还有哪些坑。
DeepSeek-V4-Flash-Vision-Exp 到底是什么
DeepSeek 官方账号发布了这条公告，称其为实验性多模态版本，文本能力（含 Agent 推理与世界知识）与现有 V4-Flash 持平（x.com/deepseek_ai/status/2090730032574631962）。公告中列出的关键规格：
| 属性 | 值 |
|---|---|
| 模型名 | DeepSeek-V4-Flash-Vision-Exp |
| 状态 | 实验性 |
| 文本能力 | 与 V4-Flash 持平 |
| 每图最大 token | 384 |
| 定价 | 与 V4-Flash 相同 |
| API 接口形态 | Chat Completions、Messages、Responses |
| 图片复用 | Files API（免费） |
DeepSeek 在同一条公告里自报的 benchmark 数字，称多模态 Agent 能力接近 Opus-4.8：ApexBench 从 26.2 提升到 36.5，Agents' Last Exam 得分 27.3，对比 Opus-4.8 的 25.7。请把这些视为 DeepSeek 的官方自报口径——尚未见到独立第三方复测，我们也没看到任何针对该视觉版本的第三方 benchmark 结果。关于模型的通用文档和 API 参考，可查阅 DeepSeek 官方 API 文档。
dsh 多模态支持是怎么落地的：rc.8 → 0.1.1-rc.1
视觉模型并非凭空出现——dsh 的多模态基础设施是在 5 天内的三个版本里逐步搭建起来的，如果你在排查旧版本的问题，这个时间线值得了解：
| 版本 | 日期 | 变化 |
|---|---|---|
0.1.0-rc.7 | 2026-08-17 | MCP 和 ACP 支持持久化图片附件（会话历史中保留） |
0.1.0-rc.8 | 2026-08-19 | 多模态基建：DeepSeek 模型适配器可配置为发送原生图片请求，/goal 和 /plan 可接收图文混合输入，@ 引用菜单可以引用文件和历史会话 |
0.1.1-rc.1 | 2026-08-21 | DeepSeek 适配器正式把 DeepSeek-V4-Flash-Vision-Exp 加为可选模型——这是 dsh 首次跳出 0.1.0 系列的次版本号 |
来源：dsh-v0.1.1-rc.1 与 dsh-v0.1.0-rc.8 的 GitHub release notes。值得注意的是，DeepSeek 官方账号并没有为 harness 侧的这次更新单独发推——rc.8 和 0.1.1-rc.1 的版本细节都是先由第三方观察扩散，之后才被 GitHub release notes 确认。这对这个项目来说是常态：dsh 没有 CHANGELOG，也不像发布模型那样在社交媒体上高调宣布 harness 更新。
如果你现在还停留在 0.1.0-rc.6 及更早版本，上面这些图片处理的代码路径都还不存在——你用的是多模态支持出现之前的 dsh，必须先升级才能继续下面的步骤。
在此之前：伪视觉时代
如果你从 dsh 发布第一周就在用，这段背景值得了解：在原生视觉支持出现之前，"让 dsh 看懂截图"靠的是一个桥接插件，先用 OCR 加像素级分析把图片信息硬提取成文字，再喂给一个纯文本模型——这从来都不是真正的图像理解。社区用户 @YinsenW_（2026-08-19）在报道 rc.8 发布时直接扒出了这一点，称这个绕路方案"有点意思"，但本质上是对没有真正多模态模型这一缺失的硬凑补丁。随着 DeepSeek-V4-Flash-Vision-Exp 作为一等公民模型选项上线，这类桥接插件的历史使命正在淡出——不过如下文所述，这些插件在"路由到视觉模型 vs 纯文本模型"这类场景里仍然有用，而不是继续硬凑伪视觉。
在 dsh 中开启 Vision
假设你已经装好了 dsh，四步搞定：
-
升级到
0.1.1-rc.1。 如果你用npx启动，建议明确指定版本号，确保清楚自己装的是哪个版本：npx @deepseek-ai/dsh@0.1.1-rc.1 web如果是全局安装，用同样的版本号重新安装（
pnpm add -g @deepseek-ai/dsh@0.1.1-rc.1或你所用包管理器的等价命令）。完整的 rc.6 → rc.8 → 0.1.1-rc.1 升级清单（包括几个与视觉无关但你路上会遇到的破坏性变更）见 升级 DeepSeek Harness。 -
选择 Vision 模型。 打开 Settings → Models，进入 DeepSeek provider 卡片，从模型列表里选
DeepSeek-V4-Flash-Vision-Exp（如果你现有的 DeepSeek provider 配置是这次更新之前建的，可能需要手动新增该模型）。如果你已经用官方 DeepSeek endpoint 认证过，不需要更换 API Key。 -
附加一张图片。 在会话里，直接把图片粘贴进输入框，或者用
@引用菜单引用工作区里已有的图片文件。这两条路径现在都会走同一个已配置为原生图片请求的 DeepSeek 适配器。 -
发送一个用到图片的任务。 一个通用、低风险的测试方式：贴一张想要改动的 UI 截图，让 Agent 调整工作区里对应的 CSS 或组件代码。由于该模型仍是实验性的，且每图 token 上限为 384，测试图片尺寸不要太大，也不要指望它能精确提取密集小字这类细节——把早期测试当作能跑通的验证，而不是模型能力上限的 benchmark。
如果你走的是自建/第三方 OpenAI 兼容 provider 而非 DeepSeek 官方 endpoint，模型必须显式声明支持图片输入——dsh 不会自动推断。在 $DSH_HOME/settings.yaml 中：
llm-pi-ai:
providers:
my-gateway:
apiKeyEnv: GATEWAY_API_KEY
api: openai-completions
baseURL: https://gateway.example/v1
models:
- id: legacy-chat
- id: vision-preview
input: [text, image] # 未声明的模型默认按纯文本处理，附图会在发送前被拒绝
任何没有声明 input: [text, image] 的模型，在请求真正发出之前就会拒绝图片附件。这一点对第三方网关普遍适用——DeepSeek 官方的 chat-completions 路由在你于 Settings 里选中 Vision 模型后就已经配置好，不需要手动改 YAML。完整的 provider 配置见 DeepSeek Harness 自定义模型 Provider。
已知限制
- 实验性状态。 DeepSeek 自己把这个模型标注为实验性，而非生产稳定版——未来版本的行为和定价都可能变化。
- 大图和历史载荷增长的问题。 过大的图片，或者会话中累积了大量历史图片，都曾导致请求失败；
0.1.0-rc.8的 release notes 提到修复了一批这类问题，但我们能拿到的 release notes 原文有截断，未列全所有覆盖的场景。如果你在一个附了多张图片的长会话里遇到失败，可以先试试清理掉较早的图片附件。 - 384 token/图是硬上限。 密集截图或图表里的细节未必能在这个预算内保留——不要指望模型能稳定读出小字。
- 自定义 provider 需要显式配置。 如上文所示，任何非 DeepSeek 官方的模型都需要声明
input: [text, image]，否则图片附件会被直接拒绝。 - 尚无独立 benchmark 复核。 上文的 ApexBench 与 Agents' Last Exam 数字来自 DeepSeek 官方公告自报口径——我们尚未见到第三方复现结果。
站内的视觉类插件
即使有了原生视觉支持，插件仍然有其价值——在视觉模型和更便宜的纯文本模型之间做路由、生成图片而不只是读图片，或者桥接老工作流。以下几款来自我们 Vision, Voice & Multimodal 分类的插件值得了解：
- dsh-vision-router —— 只在会话确实附带图片时才把请求路由到视觉模型，否则回退到更便宜的纯文本模型。
- dsh-vision-toolkit —— 面向图文混合工作场景的一整套视觉相关工具集。
- dsh-image-gen —— 在会话内直接生成图片，方向与"读图"相反。
- modlens —— 伪视觉时代最早的桥接插件之一，如果你还需要在切到新 Vision 模型的同时继续兼容纯文本模型，而不是一次性全部切换，它仍然有用。
完整列表见 /zh/categories/vision-multimodal，或浏览全部插件目录 /zh/plugins。
FAQ
使用 Vision 模型需要单独的 API Key 吗？
不需要。如果你已经在 Settings → Models 里配置了 DeepSeek 官方 API Key，选中 DeepSeek-V4-Flash-Vision-Exp 就会复用同一个凭据——定价与 V4-Flash 相同，不需要单独的计费设置。
Vision 模型会替代纯文本的 V4-Flash 吗？
不会——它是一个独立的、额外的模型选项。DeepSeek 把它的文本能力描述为"与 V4-Flash 持平"，而非严格意义上的升级，并且明确标注为实验性。建议按会话/任务切换使用，而不是默认在所有场景下都换成它。
能通过 dsh 在自建或第三方模型上使用视觉能力吗？
可以，但前提是该 provider 的模型条目在 $DSH_HOME/settings.yaml（内置 provider 用 modelOverrides）中声明了 input: [text, image]。没有这个声明，图片附件会在请求发出前就被拒绝。具体配置示例见上文，完整流程见 自定义模型 Provider。
旧的 OCR 伪视觉插件是不是就没用了？
不是没用了，而是角色变了。在 DeepSeek-V4-Flash-Vision-Exp 出现之前，modlens 这类桥接插件靠 OCR 和像素分析给纯文本模型硬凑图像理解——社区已经公开点破了这一点。现在有了原生视觉能力，这些插件更适合作为纯文本模型的兜底方案，而不再是"看图"的主要途径。
这和 rc.8 里加的多模态支持是一回事吗？
相关但不完全相同。0.1.0-rc.8（2026-08-19）加的是底层基础设施——模型适配器里的原生图片请求、/goal 和 /plan 接收图文输入、@ 引用文件/会话。0.1.1-rc.1（2026-08-21）才是真正把这套基础设施接到一个具备视觉能力的真实模型上。两者你都需要——低于 rc.8 的版本没有这套基建，而只有 rc.8 却没有可接入的视觉模型。
下一步
如果你还没装过 dsh，先看 DeepSeek Harness 快速上手；如果你在用较旧的 rc 版本，需要走完 rc.6 → rc.8 → 0.1.1-rc.1 的升级路径，看 升级 DeepSeek Harness。关于非 DeepSeek 视觉模型的配置机制，见 DeepSeek Harness 自定义模型 Provider；关于图片附件如何在工具集成里持久化保留，见 DeepSeek Harness MCP 指南。配置完成后，可以在 /zh/categories/vision-multimodal 浏览视觉类插件，或前往完整目录 /zh/plugins。