DeepSeek Harness 更新后插件失效怎么办：dsh 更新、版本漂移、profile 重载与三步回退

dsh 更新后插件失效，先别重装。 多数情况是版本漂移、profile 未重载或依赖不一致；先分清是哪一层，再按代价从低到高回退。

先分清三种更新

「更新」在 DeepSeek Harness 里至少指三件事，混在一起就会判断错。

本体更新改变的是底座。 核心版本一变，插件声明的兼容区间可能失效；这类失效通常表现为「加载失败」而不是「功能异常」。

插件更新改变的是单个包。 它可能引入新依赖或改变配置项；更新后原配置不认，表现是「插件在但不工作」。

Hub 更新只影响发现与安装。 它不应该改变已装插件的行为；如果更新 Hub 后插件失效，先怀疑索引或 profile，而不是 Hub 本身。

顺序建议：先本体、再插件、最后 Hub。 反过来的风险是插件先升到新核心要求，而本体还没升，直接不兼容。

失效的三类原因

更新后插件失效，原因集中在三类。 每一类都有可观察的信号。

1. 版本漂移。 插件依赖的核心包版本与当前核心不一致，加载时找不到匹配实现，或重复加载核心包；日志里常见版本冲突或包解析失败。
2. profile 未重载。 配置已更新，但运行中的进程仍用旧组成；表现是「改了没反应」，重启或重载后恢复。
3. 依赖不一致。 插件的新依赖与已装版本冲突，或构建脚本没有执行，产物不完整；表现是加载失败或运行时报错。

三类原因的外部表现很像，但日志位置不同。 版本漂移看包解析，profile 看重载记录，依赖看安装与构建阶段。

不要用「重装插件」一次覆盖三类。 重装能解决依赖问题，解决不了版本漂移与 profile 结构问题；先看日志，再选动作。

第一步：确认失效范围

先确认是「全部插件失效」还是「某一个插件失效」。 范围决定方向。

1. 执行 dsh plugin --profile web list，看插件是否还在列表里。
2. 在列表但加载失败：偏版本漂移或依赖；不在列表：偏 profile 或安装位置。
3. 新建一个会话测试，排除旧会话缓存的影响。
4. 看系统日志的加载阶段，记录第一个失败点。

「全部失效」优先查核心与 profile。 底座或组成出了问题，所有插件都会受影响；「单个失效」优先查该插件的版本与依赖。

第一个失败点比最后一条报错有用。 后面的报错往往是连锁反应，定位要从第一个开始。

第二步：三步回退

回退按代价从低到高，先做不影响数据的。

1. 重载 profile。 修改配置后先重载或重启，确认不是「未生效」；这一步成本最低。
2. 回退插件版本。 把最近更新的插件锁回上一版，重启验证；只回退一层，避免多个变量同时变化。
3. 回退本体。 前两步都无效，再回退核心版本；回退前记录当前版本与插件清单，方便恢复。

一次只回退一层。 同时回退本体与插件，问题消失了也不知道是哪一层解决的；下次再遇到仍然不会判断。

回退后要验证。 用同一会话、同一插件跑一次最小功能；只看「能启动」不够，要确认插件真的加载。

第三步：验证三个信号

回退是否成功，看三个信号，不只看启动成功。

1. 列表信号： 插件在 list 里，版本是预期的那个。
2. 配置信号： dsh --dump-config 里能看到插件注册的段，且没有重复核心包。
3. 功能信号： 插件的入口或命令可用，最小功能跑通。

三个信号从底向上。 列表对但功能不对，说明加载了但注册失败；配置里有重复核心包，说明版本漂移还没解决。

验证要留记录。 回退到哪个版本、三个信号的结果、是否恢复；下次更新前可以直接对照。

防复发：更新前做快照

更新前花五分钟做快照，比更新后花一小时回退划算。

1. 记录版本： 核心版本、插件列表与版本号，导出成一份文本。
2. 备份配置： 复制 profile 配置与关键设置，标注日期。
3. 备份数据： 会话与插件数据按 DSH_HOME 整体备份，避免只备份一部分。
4. 记录更新顺序： 先升什么、后升什么，写下来；出问题时能按相反顺序回退。

快照的重点是「可回退」，不是「全量归档」。 版本清单、配置副本与数据目录三样齐了，就足够恢复到更新前。

更新后先跑最小功能。 不要等一整天再发现问题；更新完立刻验证一个插件、一个会话，问题早发现早回退。

什么时候该整体回滚

三种情况说明局部回退不够，需要整体回到更新前。

1. 多个插件同时失效，且回退单个无效。 说明核心或 profile 结构变了，局部回退解决不了。
2. 回退插件后本体仍报兼容错误。 兼容区间已经断裂，只能回退本体。
3. 数据读写异常。 会话打不开、配置丢失，优先恢复数据与版本，再谈功能。

整体回滚前先停服务。 运行中回滚容易出现半写文件；停服务、恢复目录、再启动，顺序不能反。

回滚后复盘。 记录哪个版本组合可用、哪个更新引入了问题；下一次更新按这份记录避开。

下一步

先分清更新对象，再按层回退。 想了解更新命令本身，看《DSH 怎么更新》；想弄清 Hub 与本体的升级顺序，看《DSH Plugin Hub 与 Harness 升级顺序》；想处理版本漂移，看《核心包版本漂移》。

来源：DeepSeek Harness Releases、dsh CLI README、DeepSeek Harness 官方文档 - 插件与生命周期、DeepSeek Harness 官方文档