视觉能力缺失的痛点与旧方案局限
长期以来，使用 DeepSeek 构建 Agent 的用户面临一个显著瓶颈：代码编写和工具调用能力虽强，但无法直接处理视觉信息。当用户放入一张报错截图时，模型往往“看不见”，导致调试效率低下。业内对 DeepSeek 缺乏原生视觉能力的抱怨已久，开源社区为此不得不自行搭建桥梁。
在 Harness 的早期使用中（如使用 dsh-multimodal 或 dsh-deepseek-vision），用户需要经历复杂的配置流程：先安装插件，再配置 Qwen-VL、GLM 或通过 Ollama 运行的本地视觉模型。这种方案虽然能让 Harness 支持图片，但存在明显缺陷：需要额外安装和配置依赖，且在处理流程中，原图与问题之间多了一次模型调用环节。这导致信息在传递过程中产生一层损失，且增加了系统的复杂性。
“业内苦DeepSeek没有视觉能力确实已经很久了”
原生支持突破：Harness 0.1.1 与 V4 Vision Exp
8月21日，情况发生根本性改变。DeepSeek 发布了 DeepSeek-V4-Flash-Vision-Exp，同日 Harness 0.1.1 版本跟进更新。这次更新并非简单地在内置模型目录中新增一个条目，而是同时加入了图片能力声明。这意味着从模型选择、工具结果返回，一直到真正发送给 DeepSeek API 的请求，整条图片链路被完整补齐。具体支持包括：聊天上传、read_image 工具、持久化附件，以及 Files API 和 base64 的回退机制。
关于用户关心的性能权衡问题，DeepSeek 官方表示：Vision Exp 并没有为了看图而牺牲 V4 Flash 的文字能力。在 Agent 推理和世界知识等文字任务上，其表现与 V4 Flash 相当；而在需要视觉理解的多模态 Agent Benchmark 中，它比纯文本 Flash 有明显提升。
“整体接近了Opus 4.8”
需要注意的是，这一性能数据有两个重要限定：第一，这是 DeepSeek 官方公布的 Benchmark；第二，模型名称中带有 “Exp”（Experimental），表明其处于实验阶段。它适合用于测试截图分析、图表理解、文档阅读和视觉 Agent，但不能将其接近 Opus 4.8 的表现理解为所有任务都与 Opus 4.8 完全等价。
成本分析与缓存机制优势
价格是影响模型选择的关键敏感因素。Vision Exp 没有单独设置更贵的视觉价格档位，而是沿用 V4 Flash 的价格体系。具体计费规则如下：每张图片最多计入 384 个输入 token。
根据目前人民币价格计算： * V4 Flash 每百万输入 token，缓存命中价格为 2分钱。 * 未命中价格为 1元。 * 输出价格为 2元。
即使按照最贵的未命中价格计算，一张图片本身的输入成本也仅为 0.000384元左右。因此，真正影响账单的主要是较长的对话历史和模型的输出内容。此外，Files API 本身免费，同一张图片上传一次后可重复使用 file ID，从而有效减少重复传输成本。
| 项目 | V4 Flash / Vision Exp (沿用同一价格体系) |
|---|---|
| 输入 Token (缓存命中) | 2分钱 / 百万 token |
| 输入 Token (未命中) | 1元 / 百万 token |
| 输出 Token | 2元 / 百万 token |
| 图片最大输入 Token | 384 tokens |
Harness 三层架构：模型声明与预处理
Harness 新版本通过三个层级实现图片支持，确保流程的标准化和高效性。
第一层：模型能力声明。DeepSeek 官方适配器内置了一份建议模型目录，默认包含三个模型：V4 Flash、V4 Pro 以及 V4 Flash Vision Exp。该目录并非通过 API key 从 DeepSeek 的 /models 接口自动拉取，而是本地维护。其中，只有最后一个模型明确声明 input modalities 为 text和image。这不是装饰字段，当上传图片调用 read_image 并发起请求时，Harness 会检查当前模型是否声明了图片输入。普通的 Flash 和 Pro 仍按纯文本模型处理，不会假装看见也不会直接忽略图片，而是明确提示不支持。
“普通的Flash和Pro仍然按照纯文本模型在处理”
第二层：持久附件处理。图片不会以一长串 base64 永久保存在会话记录中，而是经过标准化预处理： 1. 校正 EXIF 方向。 2. 删除元数据。 3. 统一转换格式为 8-bit sRGB 或 sRGBA，默认保留透明通道。 4. 尺寸限制：边长限制在 2048像素以内。
会话中保存的是稳定的附件引用，而非某一家模型专用的请求格式。这种处理方式确保了跨会话和跨模型的兼容性。
像素预算与 Files API 的协同机制
第三层：发给模型的请求版本。Vision Exp 默认给每张图片 64万总像素、1 MiB的编码预算。缩放比例根据像素预算做开平方计算。例如，一张 2048 x 1024 的宽图会缩放到大约 1130 x 565，而不是直接裁切成正方形。相同附件使用相同的预算会得到相同的 variant ID，这为后续的缓存和文件复用奠定了确定性基础。
在发送请求时，Harness 优先使用 Files API： 1. 先上传生成的请求版本。 2. 在消息中发送对应的 file ID。 3. 容错机制：如果文件解析失败或超时，整个请求会切换成 base64 的 data URL。系统不会出现一部分使用 file ID、另一部分使用 base64 data URL 的混合状态，确保请求的一致性。
远端文件默认保存 7天。若文件过期或失效，Harness 只会重新上传并重试一次。如果图片历史过大，系统会按照固定步长省略最旧的图片，以减少请求前缀的反复变化，这对 KV cache 更友好。
CLI 实操演示与工具调用流程
通过官方 CLI 运行 Harness，无需克隆代码仓库或编译代码，直接执行 npx @deepseek-ai/dsh web 即可。在模型设置中保存好 API key，选择 DeepSeek-V4-Flash-Vision-Exp 即可开始体验。
一个直观的场景是：让 Agent 根据一张 UI 截图修改代码。例如，将 dashboard-before.png 放入工作区，并指示 Agent “找出按钮为什么错位并修改代码”。
工具调用流程如下：
1. Agent 调用 read_image 工具。
2. 工具结果不仅返回文件路径，还会把真正的图片块、实际尺寸、坐标缩放比例一起交给模型。
3. 模型分析截图后，回到 CSS 中进行定位和代码修改。
整个过程不需要用户先用文字来描述图片，实现了真正的端到端视觉理解。最后切回普通的 V4 Flash 模型时，Harness 会明确提示该模型没有声明图片输入，避免了幻觉或静默失败。
“工具结果不只返回文件路径 还会把真正的图片块 实际尺寸 坐标缩放比例一起交给模型”
结论
DeepSeek Harness 0.1.1 的更新不仅仅是增加了一个模型条目，而是构建了一整套完整的图片处理和请求机制。通过原生支持 V4 Vision Exp 模型、标准化的预处理流程（EXIF校正、格式统一）、确定的像素预算缩放算法以及稳健的 Files API 回退机制，Harness 解决了长期存在的视觉集成痛点。尽管模型仍处于实验阶段且性能需理性看待（接近但不等同于 Opus 4.8），但其极低的图片输入成本（单图约0.000384元）和无缝的工具调用体验，使其成为截图分析、图表理解和视觉 Agent 开发的极具性价比的选择。对于开发者而言，这意味着无需再依赖外部多模态模型桥接，即可在 Harness 环境中实现高效、低成本的视觉智能应用。