DeepSeek Harness 发布：官网说“一切皆插件”，我现场给它接了一个视觉插件
#DeepSeek Harness 发布：官网说“一切皆插件”，我现场给它接了一个视觉插件
DeepSeek 这次没有发布新模型，而是开放了一套可以自己创建、更新和组合 Agent 能力的 Harness。官网把最重要的一句话放在第一屏：一切皆插件。
这句话看起来很像框架发布时常见的口号。
我决定不靠想象解释它，直接做一个插件试试。
结果是：当前选中的 DeepSeek 模型明确不支持图片输入，但我没有更换主模型，而是在 Harness 里做了一个视觉预处理插件，把图片交给外部视觉模型，再把文字描述送回 DeepSeek 会话。
这篇文章就从这个实验开始，看看 DeepSeek Harness 到底开放了什么。
#01 DeepSeek 这次发布的，到底是什么？
先看官方首屏。
DeepSeek Harness 目前是开发者预览版，已经开放测试并同步开源。官方提供的快速启动命令只有一行：
npx @deepseek-ai/dsh web真正值得看的不是 Web UI，而是官网对它的定位：
模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等所有 Agent 能力，均由插件组合而成，可以替换和重组。[1]
换句话说，DeepSeek 这次没有再交付一个能力固定的 Agent 产品，而是把 Agent 拆开了。
模型可以是插件，工具可以是插件，消息进入模型前的处理步骤也可以是插件。开发者不只能安装别人做好的能力，还可以自己创建、更新，然后把它放进当前 Harness 环境中运行。
这才是“一切皆插件”真正值得验证的部分。
#02 第一个问题很现实：当前模型看不了图片
我创建了一个测试工作区，选择 DeepSeek-V4-Flash High，上传一张图片并输入：
这张图是什么？界面马上给出提示：
当前模型不支持图片，请切换支持图片的模型这不是 Harness 出错，也不能推广成“所有 DeepSeek 模型都不支持图片”。它只说明当前会话选择的这个模型，在这套 Harness 配置里没有声明图片输入能力。
最省事的办法当然是切换模型。
但这也给了我一个更适合测试 Harness 的问题：
能不能保留 DeepSeek 作为主模型，只在图片进入会话前，让一个插件调用外部视觉模型完成预分析？
我想实现的并不是让 DeepSeek 模型本身突然长出视觉能力，而是改造消息进入模型之前的路径：
图片
→ 自制视觉插件
→ 外部视觉模型
→ 文字描述
→ DeepSeek
主模型不换，缺少的能力从外部接进来。这正好可以检验 Harness 所说的插件化，究竟是不是只停留在界面和口号上。
#03 自己写的插件，能不能直接进入 Harness？
我给插件设定的职责很克制：
发现图片附件
→ 调用外部视觉模型
→ 获得文字描述
→ 把描述注入会话
→ 交给 DeepSeek 回答它不负责最终回答，也没有改动 DeepSeek 模型。它只处理模型调用前的图片消息。
我先在会话里提出目标：创建一个插件，让 DeepSeek 可以借助其他供应商的模型识别图片。
随后，插件以 Cordis 插件的形式注册。界面显示的功能描述是：
DeepSeek 图片代理预分析
允许 DeepSeek 会话接收图片并在发送前替换为自动视觉识别文本更新后，界面出现 vpre-3 / pkg-13，Host 给出了运行实例 run-17：
从这些截图可以确认三件事：
- 用户可以定义自己的插件能力；
- 插件可以注册、更新，并交给当前 Host 激活；
- 当前 Harness 环境可以使用这个插件，不必为了一个新能力重做一套 Agent 产品。
截图不能证明“零停机热更新”，所以我不会这样宣传。它能证明的是：插件更新后进入了当前 Harness 的运行状态。
到这里，“一切皆插件”已经不再只是官网上的大字。
它意味着开发者写下的处理逻辑，真的可以进入 Agent 的运行过程。
#04 图片发出去之前，插件具体做了什么？
插件运行后，我再次发起图片问答。
这一次，图片不会原样进入不支持图片输入的 DeepSeek 主模型。vision-preprocess 会先发现附件，把图片交给外部视觉模型，并取得文字描述。
随后，这段描述作为上下文进入当前会话。
在会话中，可以看到这些上下文节点：
@deepseek-ai/dsh-system-prompt
vision-preprocess
skill-catalog
Think它们不是四个平级模型。
dsh-system-prompt 提供系统规则，skill-catalog 告诉会话当前有哪些能力，而 vision-preprocess 提供这次图片预分析的文字结果。等 DeepSeek 进入 Think 时，它面对的已经是一段可以阅读的文字现场。
整个处理链可以还原为：
用户图片 + 问题
→ Harness 接收消息
→ vision-preprocess 介入
→ 外部视觉模型读取原图
→ 返回文字描述
→ 描述注入上下文
→ DeepSeek 推理并回答
这里必须分清楚：
外部视觉模型读取原图；DeepSeek 收到的是文字描述，不是原图。
所以，这个实验没有让 DeepSeek-V4-Flash High 变成视觉模型。改变的是消息进入主模型之前所经过的路径。
#05 最终效果：不会看图的主模型，回答了“这个是谁”
真正测试时，我上传了一张人物图片，只问了一句：
这个是谁？
插件先生成视觉描述，再把它交给 DeepSeek。最终回答里出现了这些信息：
- 人物戴眼镜、穿蓝色西装；
- 站在讲台前，面前有两支麦克风；
- 手指靠近嘴部，像在做“安静 / 嘘”的手势；
- 图片右下角存在“知乎 @吴建明”的水印线索。
但回答没有顺着水印硬猜人物身份。
它明确指出：水印通常代表图片来源或发布者，不等于图中人物本身。仅凭当前图片描述，无法确认这名男子的具体身份。
这反而是这次测试里最有价值的部分。
视觉插件负责把画面转成文字；DeepSeek 负责在文字中区分“看见了什么”“能推断什么”“还有什么不能确认”。
当然，这套链路也有一个很现实的上限：如果外部视觉模型看错了，DeepSeek 就会在错误描述上继续推理。
插件注入的是上下文，不是真相。
#06 为什么不直接换一个支持图片的模型？
当然可以，而且对大多数普通用户来说，直接切换视觉模型更省事。
为了让视觉预处理链路知道该把图片交给谁，我还在自制插件里做了一个“模型视觉能力”设置页，用来声明哪些模型支持图片输入：
这不是 DeepSeek Harness 官方原生设置，也不代表 Harness 会自动判断所有模型的视觉能力。它是这个插件自己维护的能力声明和路由配置：当前主模型未声明图片输入时，插件可以把原图交给已标记支持图片输入的外部模型，再把识别结果送回 DeepSeek。
但我的目标不是证明插件一定比直接换模型更好，而是验证另一种组合方式：
| 组件 | 在这次实验里的职责 |
|---|---|
| 外部视觉模型 | 读取原图，生成视觉描述 |
vision-preprocess |
发现图片、调用视觉能力、整理结果 |
| DeepSeek 主模型 | 理解问题，基于描述推理并回答 |
| Harness / Cordis | 注册插件、承接会话、组织运行链路 |
这样做的好处是，主模型、视觉供应商和消息处理逻辑彼此解耦。
以后想更换视觉模型，不必连 DeepSeek 主模型和整套会话工作流一起换掉。想增加 OCR、敏感信息遮罩或截图错误识别，也可以继续在输入链路上组合能力。
需要注意，vision-preprocess 会接收图片附件并负责调用外部服务，真正进行视觉理解的是外部视觉模型；Harness 则从一开始就承接整条路由，不是最后才出现的一站。
#07 这个案例真正证明了 Harness 的什么？
回到官网那句“一切皆插件”。
视觉识别只是这次接进去的第一块积木。真正被打开的是开发者自己组合 Agent 能力的入口。
#能力可以由用户创建
不必等待主模型下一次升级，也不必等官方把所有功能都做好。开发者可以针对自己的场景定义插件。
#插件可以介入会话链路
插件不只是界面旁边多一个按钮。它可以处理模型调用前的输入、注入上下文、注册工具，甚至参与存储、循环、调度和 UI。
#不同模型可以各做擅长的部分
一个模型负责视觉，另一个模型负责推理与表达。Harness 把它们组织在同一个 Agent 流程里。
#能力可以继续向前、向后扩展
沿着这次视觉插件的思路，还可以创建或连接这些能力类别：
- OCR、PDF 与文档提取；
- 敏感信息遮罩；
- 私有知识库和项目上下文；
- 浏览器、Shell、内部 API 与 Skills；
- 结构化报告、任务系统写入和 Trajectory 记录。
上图中的 OCR、知识库、浏览器、Shell 等是能力类别示意，不代表它们已经全部作为官方默认插件内置。具体能不能用，仍取决于插件实现、权限、配置和部署环境。
#08 现在值得玩吗？值得，但先别接生产环境
DeepSeek Harness 现在仍是开发者预览版。插件化给了开发者很高的自由度，也把更多责任交回给开发者。
以这次视觉插件为例，至少需要处理这些问题：
- 图片会不会被发送到外部视觉供应商；
- 用户是否知道数据流向；
- 视觉服务超时或失败时如何降级；
- 注入的描述是否需要结构化；
- 错误描述会不会诱导主模型继续误判；
- 插件更新后如何验证当前运行版本；
- 哪些能力只读，哪些能力允许进一步执行操作。
尤其是失败降级。
如果外部视觉服务没有返回结果，插件应该明确告诉 DeepSeek“本次没有拿到视觉描述”，而不是注入一段空白，更不能偷偷猜一段内容。
第一次体验，建议只使用测试工作区、非敏感图片和只读型插件。等日志、轨迹、权限和异常处理都看清楚，再考虑接入真实项目。
#最后
DeepSeek Harness 最有意思的地方，不是官方预装了多少功能。
而是它允许开发者自己决定：
- 谁负责看；
- 谁负责想；
- 哪个插件先介入；
- 结果如何进入下一步；
- 过程怎样被记录和约束。
这次实验没有让 DeepSeek 模型本身学会看图。
我只是创建了一个插件，让外部视觉模型先看，再把文字描述交给 DeepSeek。
但也正是这个看起来不大的案例，把“一切皆插件”讲清楚了：
DeepSeek 这次开放的，不只是一个 Agent 产品，而是开发者重新组合 Agent 能力的入口。
#资料来源
- DeepSeek Harness 官方网站：https://www.deepseek.com/harness/
- DeepSeek Harness 官方文档：https://deepseek-harness.github.io/deepseek-harness/
- DeepSeek Harness GitHub 仓库：https://github.com/deepseek-ai/deepseek-harness
- npm：
@deepseek-ai/dsh：https://www.npmjs.com/package/@deepseek-ai/dsh
本文中的视觉预处理插件为个人实验案例；插件截图、运行状态和最终回答均来自实际 Harness 会话。漫画用于解释链路，不代替产品运行证据。
评论
还没有评论，来说点什么吧。