我做了一个非官方 DeepSeek Harness 工具箱：插件、启动器和可验证目录

随着 DeepSeek Harness 的社区项目增加，单看仓库名称或 GitHub Topic 很难判断一个项目究竟是插件、配套工具，还是与 Harness 无关的同名项目。

为了解决这个问题，我建立了 Wanbinyu Harness Toolbox，用于整理和校验我维护的 DeepSeek Harness 插件与配套工具。

项目地址：https://github.com/Wanbinyu/wanbinyu-harness-toolbox

需要特别说明：这是个人独立维护的第三方项目，不属于 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 地址和核验日期。

同时提供自动校验脚本：

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。