dsh plugin hub 怎么更新：DeepSeek Harness 插件中心升级、缓存与版本回退

dsh plugin hub 更新完，界面却跟昨天一模一样，这种落差多半来自版本线错位，而不是安装命令失效。 先把「我动的是本体、Hub，还是某个插件」回答清楚，缓存、重启与回退才有落点。

先把版本线分清：你动的是 DeepSeek Harness 本体、Hub 还是插件

同一个「更新」按钮背后至少有三套版本号，混着看就永远对不上账。

本体线指 @deepseek-ai/dsh 这个包，它决定核心运行时，更新通常通过 npx、全局 npm 或源码完成。 它升级后，模型调用、会话存储这些底层行为才会跟着变。插件市场长什么样，与它没有直接关系。

Hub 线是插件市场本身，它有自己的包名与版本，市场界面、条目渲染和搜索索引都由它负责。 它不会随本体自动升级，也不该被理解成「本体的一个页面」。把它当成独立软件看待，很多现象立刻就说得通了。

普通插件线更容易理解：记忆、机器人、工作流各发各的版本，往往一次只坏一个功能。 所以当你发现某个按钮失灵，先查那条插件线，而不是把整个环境重装一遍。三条线的发布节奏不同，彼此只有兼容关系，没有从属关系。

判断对象的方法，是把「我更新了」换成一句完整的话：「我把 X 从 a 版升到了 b 版」。 这句话说不出来，说明对象还没确认；说得出来，问题往往当场就定位了。再看现象落在哪条线上：界面没变看 Hub，模型行为变了看本体，单个功能异常看插件。一次只动一条线，出问题时才有归因的可能。

Hub 自己就是个 DSH plugin，版本得回已装列表里查

界面上的版本号只是渲染结果，包名、版本、发布者三项一致才算确认身份。

打开 DSH Plugin Hub 切到已安装，找到 Hub 自己的条目，先记下完整包名与发布者。 同名条目不止一个，发布者不同就是另一个东西。这一步看似琐碎，却能挡掉后面一大半的误判。

接着用 dsh plugin list 复核一遍。命令行列出的版本才是实际加载的版本，界面显示可能来自缓存或另一份配置。 两边对不上时不要急着更新，先弄清楚它们各自读的是哪个 profile。读错了对象，后面的重启与回退全是空转。

中文搜索时容易搜到搬运条目，搜 DSH插件 或 DeepSeek插件 都可能命中，但最终仍要回到包名确认身份。 包名对了，版本才有比较的意义；包名错了，所有结论都不成立。顺手看一眼发布者，比记一串版本号更省事。

版本比较还有一个前提：两次查询要在同一份环境里做。 换一个终端、换一个用户目录，看到的可能是另一套安装。确认环境一致，再谈「版本没变」才有意义。

更新 dsh plugin hub：界面点一下，还是命令行指定版本

单机随手点更新，团队与脚本走指定版本，两条路最后都要回读版本号。

界面更新适合一个人维护一台机器：选中 Hub、点更新、等它结束，然后刷新页面。 整个过程不要中途刷新，也不要连点，否则你看到的可能是一个半完成状态。确认版本号在列表里变过来，再继续下一步。

命令行更适合可复现的场景，因为版本号写在命令里，谁执行结果都一样。 装完立刻用 dsh plugin list 核对，别把「命令没报错」当成「版本已生效」。命令里的版本号越具体，复现时越省事。

1. 在已装列表选中 Hub，确认当前版本后再点更新。
2. 等待安装结束，期间不要刷新页面或重复触发。
3. 需要用命令行时，写成 dsh plugin add <包名>@<版本>，把版本固定下来。
4. 更新完成后重启客户端，让前端资源与插件索引重新加载。
5. 回读版本号，再打开市场搜索一次，确认条目能正常渲染。

更新成功但界面版本没变，先别怀疑命令。 回到已装列表看是不是更新到了另一份 profile，或者同事用不同目录启动了另一套环境。这类「更新了却像没更新」的情况，多数不是失败，而是对象不一致。

更新后界面没变，dsh plugin hub 的缓存排在最后

排查顺序是刷新、重启、对版本、看控制台，清缓存排在最后。

刷新页面只触发重新渲染，成本最低，先做。 没变化就重启客户端，让它重新拉取资源与索引，大部分旧页面问题到这一步就结束了。这一步只影响当前标签页，不会动安装文件。

还没好，就核对 Hub 与本体是否落在兼容范围内。 跨大版本时，Hub 可能根本不渲染，这时清多少次缓存都没用。打开控制台和网络面板，资源 404 或接口报错说明是加载失败，不是缓存陈旧。版本对不上时，先解决兼容，再谈缓存。

只有确认资源损坏，才动手清缓存。 清之前记下版本与现象，清之后再对一次，否则你无法判断问题是被修好了还是被藏起来了。一上来就清缓存，会把真正的版本不兼容掩盖掉，下一次更新还会复现。清理范围也要小，别把会话数据一起扫掉。

判断解决的标准不复杂：空白消失、条目能搜到、详情能打开，三件事都过才算完。 只过一两件，说明还有别的层没对齐。把每一步的结果写下来，比反复试要快得多。每一步都做完再进入下一步，排查才不会反复。

回退 dsh plugin hub 之前，先确认旧包还活着

回退成立的前提只有两个：旧包仍可解析，旧配置仍被当前本体接受。

先把问题版本记清楚：版本号、现象、出现时间。 这三样写下来，你才知道要退到哪一版、退回去要验证什么。时间点也很关键，它决定你能否对上那次更新。

再去市场条目或 npm 查上一版是否仍然发布。 旧版本被撤包时，「回退」只是一句愿望，实际能做的是升级到修好的新版本，或者临时换一个替代插件。查不到旧包时，回退计划要当场改掉。

重装时写确切的版本号，不要用范围写法，否则包管理器可能又给你装回最新版。 装完重启并刷新，再走一遍搜索、详情、安装三条核心路径，缺一条都不算回退完成。版本号写成范围，等于把结果交给解析器。

回退解决的是「新版本坏了」，解决不了「本体重构导致 Hub 不兼容」。 后者要往前升级 Hub，而不是往回退。给回退设一个复查点，下一版发布后重新评估，别把临时版本用成永久状态。复查点没到之前，也不要顺手再升回去。

什么时候该动 dsh plugin hub，什么时候先放着

有具体问题再更新，别因为「有新版本」就去动一台正在交付的机器。

值得更新的信号很具体：市场条目渲染错乱、搜索不到已上架插件，并且你已确认是 Hub 版本的问题。 也可能是 Hub 声明支持你刚升级的本体，或者发布说明里点名修了你正在遇到的 bug。这三条都指向同一个问题，才值得动版本。

可以先不动的情况同样具体：演示或交付前界面能用；本体还停在旧大版本；你只是看到版本号变了，却说不出要解决什么。 这几种情况下，更新带来的风险大于收益。把更新排到下一个维护窗口，比在忙的时候赌一次要稳妥。把「先不动」也写进维护记录，下次就不用重新判断。

更新本身不产生价值，解决的问题才产生价值。 先写清楚要解决什么，再决定升不升、升到哪一版。这条判断对 Hub 成立，对任何一个 DSH plugin 也同样成立。想不清楚就先不动，这个默认选项通常最安全。

来源：DSH Plugin Hub 插件条目、dsh-plugin-hub 仓库、npm @deepseek-ai/dsh。