7 月底看 DeepSeek V4-Flash 更新日志的时候，我注意到一句以前没出现过的话。
DeepSeek 在 Code Agent 的 benchmark 说明里写道，这次测试使用的是 DeepSeek Harness minimal mode，后面还特意加了一句：
“to be released soon”。
当时我第一反应是，DeepSeek 终于也要自己做 Agent Harness 了。
后来这个项目确实公开了。
DeepSeek Harness，简称 DSH。
项目地址放在 DeepSeek 官方 GitHub 账号下面，目前还是 Developer Preview。官方对它的描述很简单：
它是一个开源 Agent Harness。
但真正让我感兴趣的是后面一句：
everything is a plugin。
也就是说，DSH 并没有把 Agent 的各种能力都写死在一个框架里，而是把大量能力都交给 Plugin 去完成。
这件事比“DeepSeek 又开源了一个 Agent”更值得关注。
Harness 到底解决什么问题？
最近 Agent 圈里 Harness 这个词越来越常见。
Claude Code、Codex、OpenCode、Pi，本质上都有自己的 Harness。
模型负责推理，但一个真正能工作的 Coding Agent，还需要很多模型之外的东西：
文件读写、Shell、权限控制、任务规划、上下文管理、工具调用、子 Agent、代码修改……
这些东西加在一起，才决定了模型最后“能不能把事情做完”。
所以同一个模型放在不同 Harness 里，实际体验可能差很多。
DeepSeek 自己在 V4-Flash benchmark 里专门注明使用了 DeepSeek Harness，其实已经说明了一个问题：
现在评价一个 Agent 模型，只看模型本身已经不太够了。
Harness 已经开始成为模型能力的一部分。
DSH 有一个我觉得很有意思的设计：插件不是附加功能
我一开始以为 DSH Plugin 和很多软件的插件差不多。
后来翻了一下文档，发现它不是简单地在 Harness 外面挂几个 Extension。
DSH 底层用的是 Cordis。
一个 Plugin 本质上就是一个 TypeScript module，通过 apply 注册自己的能力。
工具、事件、Service、依赖关系，都可以通过插件体系扩展。
官方文档甚至专门提供了一整套 Plugin 开发方式，包括 lifecycle、services、dependencies、events、configuration 等。
所以这里的 Plugin 更接近 DSH 的基础组成方式。
这也是为什么官方 README 会直接说：
everything is a plugin。
如果这个设计后面保持下去，我觉得 DSH 真正有意思的地方可能不是“DeepSeek 官方出了一个 Coding Agent”。
而是：
别人能在这个 Harness 上加什么。
但我很快遇到了一个很现实的问题
我想看看现在已经有哪些 DeepSeek Harness plugins。
结果发现，没有一个特别好的地方可以看。
官方现在推荐的方式很直接：
开发者做完插件以后，在 GitHub Repository 上加一个：
dsh-plugin
Topic。
然后用户可以从 GitHub Topic 里发现这些项目。
这个办法在生态刚开始的时候完全够用。
但我自己实际翻了一圈以后，体验并不算好。
GitHub 展示的是 Repository，而我真正想找的是 Plugin。
这两个视角其实不一样。
比如我更关心：
这个插件具体解决什么问题？
是开发工具，还是 Browser Automation？
有没有依赖其他 Plugin？
怎么安装？
最近有没有更新？
适合什么使用场景？
有没有类似插件？
但在 GitHub Topic 页面上，基本只能看到项目名、简介、语言、Star。
后面的信息还是得一个个点进 README 看。
插件少的时候没什么。
如果以后有几百个，这个方式就很难用了。
于是我开始整理这些插件
这也是我做 DSH.Tools 的原因。
一开始其实没想做得多复杂。
只是我自己在找 DeepSeek Harness plugins 的时候，觉得 GitHub Topic 看起来太散，就想做一个更方便浏览的版本。
目前 DSH.Tools 会自动同步 GitHub 上带 dsh-plugin Topic 的项目，然后重新整理成插件目录。
不是让开发者再手动提交一遍。
GitHub 依然是源头。
DSH.Tools 更像是在 GitHub 上面再加一层适合“找插件”的展示。
现在主要做了几件事情。
自动收录
只要插件使用了 dsh-plugin Topic，就有机会被同步进来。
不用插件作者再维护第二份信息。
自动分类
Repository 本身往往不会明确告诉你它属于哪个场景。
所以我会根据 README、描述等信息做进一步分类，让用户能从用途出发找插件。
例如开发工具、搜索、Browser、Automation 等。
把 README 里有用的信息提前拿出来
找插件最麻烦的一点，就是需要不断：
GitHub → README → 返回 → 下一个 Repo。
所以 DSH.Tools 会尽量把插件用途、项目介绍、GitHub 数据等集中在详情页里。
先判断值不值得用，再决定要不要去看源码。
持续同步 GitHub
这点我觉得比“做一个导航站”更重要。
插件目录最怕的不是数量少，而是过期。
Repo 改了描述、Star 在变化、插件还在更新，目录里的信息也应该跟着变化。
所以现在整个收录逻辑尽量以 GitHub 为 source of truth，而不是人工维护一张静态表。
我现在反而比较好奇 DSH 的插件生态会怎么发展
DeepSeek Harness 目前还是 Developer Preview，官方也明确提醒可能会有 breaking changes。
所以现在判断它会不会成为下一个主流 Agent Harness，还太早。
但 Plugin 这件事值得提前看。
因为官方已经把 Plugin 放到了一个很核心的位置。
甚至 README 里已经明确告诉开发者：
如果你做了插件，就给 Repository 加上 dsh-plugin Topic。
这意味着一个非常原始的插件生态其实已经开始出现了。
现在只是：
GitHub Topic + 一堆 Repo。
再往后可能会出现更复杂的问题：
插件之间怎么组合。
版本兼容怎么处理。
哪些插件质量更高。
哪些插件已经停止维护。
一个 Plugin 依赖另一个 Plugin 时怎么展示。
甚至 Agent 能不能自己搜索并安装需要的 Plugin。
这些问题目前都还没有答案。
我做的 DSH.Tools 现在只是在先解决最前面的一个：
DeepSeek Harness plugins 到底有哪些，以及怎么更快找到它们。
如果你最近也在玩 DeepSeek Harness，可以直接去看看：
现在插件数量还不算多，反而挺适合观察这个生态最早期会长成什么样。
