随着 DeepSeek Harness 的社区项目增加，单看仓库名称或 GitHub Topic 很难判断一个项目究竟是插件、配套工具，还是与 Harness 无关的同名项目。
为了解决这个问题，我建立了 Wanbinyu Harness Toolbox，用于整理和校验我维护的 DeepSeek Harness 插件与配套工具。
项目地址：github.com/Wanbinyu/wa...
需要特别说明：这是个人独立维护的第三方项目，不属于 DeepSeek 官方，也不代表官方认证或安全审查。
当前包含的项目
工具箱目前记录了三个项目：
dsh-billing：按 provider/model 统计 Token 费用、会话额度和 Web 费用条dsh-plugin-git-inspect：为 Harness 提供只读 Git 检查工具dsh-launcher：在 Windows 上通过双击、dsh或deepseek快速启动 Harness Web
其中前两个属于可以组合进 profile 的插件 Bundle；dsh-launcher 是 Windows 配套工具，不会被错误标记为 Cordis 插件。
不只是一个 README 列表
仓库提供机器可读的 plugins.json，记录项目分类、版本、兼容范围、安装命令、Release 地址和核验日期。
同时提供自动校验脚本：
bash
npm install
npm run verify校验过程会检查：
- GitHub 仓库是否公开可访问
- Bundle 是否在
package.json中声明dsh.bundle.patch cordis.patch.yml是否真实存在并包含插入配置- README 是否提供可复现的安装命令和兼容性说明
- 目录版本是否与实际 package 版本一致
- 启动器下载链接是否指向最新 Release 资产
GitHub Actions 除了在提交时运行，还会每周自动检查一次，尽早发现版本和下载地址漂移。
为什么要区分插件和工具
真正可以通过 dsh plugin --profile web add ... 安装的 Bundle，需要携带对应的 manifest 和 patch 文件。一个帮助启动 Harness 的 EXE 很有用，但它不是插件；一个仓库带有 dsh-plugin Topic，也不代表它真的能安装运行。
把分类和验证条件写清楚，可以减少用户下载后才发现无法使用的情况。
如果你正在关注 DeepSeek Harness 的第三方扩展，可以从这个工具箱了解项目边界和安装方式，再进入各仓库查看完整 README、许可证和 Issue。