卸载 deepseek harness 前导出什么：DSH plugin 会话、插件清单与配置三份备份

卸载 DeepSeek Harness 之前，最该导出的不是安装目录，而是重装后无法重建的会话、插件清单与配置。 程序可以再装，DSH插件可以再下，但历史对话和长期调好的行为一旦丢掉，就只能靠回忆重来。下面先分清三类数据，再说明哪些导出看着完整、实际却缺了索引，最后给一套能落地的验收方法。

卸载 DeepSeek Harness 前真正该导出的是什么

会话保过程，清单保环境，配置保行为，三类数据缺一类，重装后就有一块对不上。

重装程序只需要一条安装命令，真正难恢复的是使用过程中积累下来的状态。对话记录里有当时的判断依据，插件清单里有与环境匹配的版本组合，配置里有模型、路径和权限的取舍。这些东西不会随安装包一起回来，也不会在重新登录后自动出现。

只备份会话的人，重装后能翻到旧对话，却不知道该装哪些插件才能让同一条任务继续跑。只备份配置的人，环境看起来恢复了，真正要查一次旧结论时却找不到上下文。两类数据各自完整，合在一起才构成可用的备份。

所以归档时不要按文件类型随手一丢，而要按用途建三个子目录，再写一份总清单说明每个目录里有什么。总清单不需要复杂格式，包名、版本、路径、日期和负责人就够。以后无论是自己恢复还是交给同事，都能从清单开始，而不是靠记忆猜。

DSH plugin 的会话与日志：看着完整却常常缺索引

会话文件复制成功，不代表重装后还能搜索和继续。

会话目录里通常不只有对话正文，还有用于列表和搜索的索引文件。只复制看得见的会话记录，重建后可能能打开单条对话，却搜索不到历史内容，或者列表里只剩一部分。判断是否需要索引，最简单的方法是在副本里做一次关键词搜索。

日志往往不在会话目录里，而是单独存放。排查类对话的价值很大一部分来自当时的错误输出和工具调用记录，只备份对话正文会丢掉这些细节。把运行日志和错误日志一起带走的成本很低，缺了却很难补。

有些会话还引用了附件、工作区快照或生成的文件。正文里只有路径，没有内容，恢复后点开就是空的。归档前先确认这些外部引用是否还在，必要时把附件目录一并复制，并在总清单里注明相对位置。

验证时不要在原环境里打开备份，那样会不自觉地依赖原目录。把归档复制到另一个用户目录或另一台机器，用只读方式打开，确认列表、搜索和附件都能正常访问。任何一项失败，都要回到导出步骤补齐，而不是等到卸载后再处理。

DeepSeek Harness 的插件清单与版本怎么导出才可用

清单要能直接变成安装命令，截图做不到这一点。

用 dsh plugin list 把已安装插件的包名和版本输出成文本，是成本最低也最可靠的方式。文本可以搜索、可以逐行对照，也能直接粘进安装命令。截图看起来直观，但无法检索，版本号里一个字符看错，重装结果就会不同。

除了包名和版本，还要记录插件装在哪个 profile、来自哪个来源。市场安装、npm 安装、GitHub 仓库和本地包，在重装时的命令并不一样。只写「装过某个插件」，等于把最关键的一步留给了猜测。

启用与禁用状态同样要记。禁用但保留的插件往往是为了排查问题临时关掉的，重装后如果默认全部启用，原来的行为就会改变。把状态写成单独一列，恢复时按列执行，比事后一个个试要快。

清单整理完后，用其中任意三行试着写出安装命令，确认包名、版本和来源都能对应上。插件条目可以在 DSH Plugin Hub 对照名称与版本说明。写不出来的行，说明记录还缺字段，应该在卸载前补齐。

dsh plugin 配置与凭据引用：脱敏之后还要能恢复

配置可以备份，密钥不该以明文形式跟着走。

配置文件里通常包含模型选择、工作目录、插件参数和超时设置，这些都应该原样复制。它们是行为差异的主要来源，缺一项就可能出现「同样的插件，回答风格完全不同」的情况。复制之后先比对文件数量与修改时间，确认没有漏掉被拆分的配置片段。

密钥不应该直接写进归档。配置里保留引用名，真正的值单独放进密码管理器或加密容器，并在总清单里注明对应关系。这样即使归档被误传，泄露的也只是结构，不是凭据本身。

启动脚本里的环境变量最容易被忽略。它们不在配置文件里，却会覆盖配置中的同名项，导致恢复后的行为与原来不同。把启动脚本一并保存，或者单独列一份变量名清单，能在恢复时省去大量排查。

配置格式会随版本变化，旧格式未必能被新版本直接读取。归档时记下导出时的 CLI 版本和配置格式版本，恢复前先看对应版本的说明。格式不兼容时，宁可手工迁移字段，也不要让程序自动覆盖原文件。

验收 DeepSeek Harness 备份是否真的可用

备份不演练，等于把风险推迟到重装那天。

先做静态检查：三类数据各有几个文件、总大小是否合理、文件能否正常打开。静态检查只能发现明显缺失，发现不了索引损坏或路径失效。真正的验收必须走到恢复环境里做。

1. 在另一台机器或另一个用户目录恢复配置，确认能正常启动。
2. 按清单逐条重装插件，记录失败的包名与版本。
3. 打开一条旧会话，确认内容完整且能搜索。
4. 跑一个原来常用的任务，观察插件是否按预期生效。
5. 把演练中发现的问题补进归档，再决定是否卸载。

演练失败并不罕见，失败点往往集中在索引、附件和 profile 三处。把失败信息原样记下来，回到导出步骤补齐，然后重新演练一次。只补一处就宣布完成，通常会在下一次恢复时暴露新的缺项。

演练通过后再执行卸载，顺序不要反过来。卸载之后原目录可能被清理，届时再想补导出一份索引或一条日志，成本会高得多。把归档放在安装目录之外，也是为了避免卸载程序顺手把它一起删掉。

卸载 dsh plugin 之前的最后检查

删除动作应该发生在验收之后，而不是导出之后。

归档要放在安装目录之外，并且至少保留一份异地副本。放在同一个磁盘分区里，磁盘故障时会一起丢失；放在安装目录里，卸载脚本可能直接清空。确认副本可读之后，再考虑是否需要压缩或加密。

卸载前再核对一次数据目录。有些版本会把会话和缓存放在用户目录深处，卸载程序只删除程序文件，数据仍留在原地；另一些版本则会询问是否一并清理。无论哪种情况，都不要假设「卸载不会动数据」，先确认归档已经独立存在。

使用 DSH插件 和 DeepSeek插件 时，插件自身的配置可能分散在多个位置，升级或卸载的清理范围也不一致。把插件相关的目录一并列入归档，并在总清单里写清来源版本。这样即使重装后行为有差异，也能快速判断是配置没恢复，还是版本变了。

备份的价值不在于文件数量，而在于恢复后能继续工作。只要旧会话能打开、插件能按清单装回、配置能复现原来的行为，这次导出就算合格。剩下的清理动作，可以慢慢做，不必赶在卸载的那一刻。

来源：deepseek-harness CLI README、DeepSeek Harness 快速开始、npm @deepseek-ai/dsh。