卸载 deepseek harness 后 API Key 怎么办：凭据撤销、轮换与残留检查

卸载 DeepSeek Harness 之后，API Key 不会跟着消失，它仍然躺在模型服务商的账户里等下一次调用。 真正需要清理的凭据分散在本机配置、环境变量、插件目录和日志里，卸载程序只动了其中很小一部分。

为什么凭据还在：DeepSeek Harness 卸载只处理本机文件

卸载删掉的是程序，不是身份。

包管理器卸载 dsh 时，做的是删除可执行文件、清理注册的安装目录、移除部分缓存。它不会登录模型服务商后台，也没有权限替你停用任何密钥。这条边界由系统权限决定，不是实现偷懒。

很多人把「配置里看不到 Key」当成已经清理完成。实际上配置保存的往往只是引用，真正的密钥可能来自环境变量，或者由插件在运行时读取独立文件。删掉引用只是让客户端读不到，远端凭据依然有效。

凭据的生命周期和服务商账户绑定，而不是和某台机器绑定。同一把 Key 可以同时被另一台机器、另一个脚本或同事的本地环境使用。卸载只影响你这一侧，其他使用方完全无感。

凭据藏在哪：DSH插件卸载后的四个常见位置

先建立位置清单，再谈删除，否则清掉的只是你以为的那一份。

DeepSeek Harness 相关文件通常分布在用户配置目录、shell 启动脚本、插件自己的数据目录以及日志与崩溃转储里。不同安装方式会改变具体路径，但类别基本一致。下表列出典型内容和卸载时的处理情况，实际路径以你机器上的安装说明为准。

配置与环境变量最容易被漏掉，因为它们常被当成「开发环境的一部分」。插件目录更隐蔽，一个第三方插件可能把令牌写在自己的文件里，与主程序无关。日志则是最危险的一类，因为很少有人会去翻历史日志。

确认位置时要区分「引用」和「密钥本身」。引用是配置里指向某个变量或文件的指针，删掉它能阻止读取；密钥本身是服务商签发的那串字符，只有服务商后台才能让它失效。把这两件事混在一起，就会得出错误的清理结论。

远端撤销与轮换：DeepSeek插件碰不到服务商后台

不再使用的密钥要撤销，还要继续用的密钥要轮换，这两件事都必须在服务商侧完成。

撤销和轮换看起来相似，目的不同。撤销是让旧密钥彻底失效，适用于确定不再使用的场景；轮换是先签发新密钥、替换使用方、再停用旧密钥，适用于仍需保留访问能力的环境。选错方式，要么留下无效依赖，要么制造一次不必要的停机。

操作顺序可以按下面几步走，重点是每一步都能验证。顺序颠倒会让使用中的服务先断掉，再回头补配置。留下验证记录，也能在事后说明清理是否完成。

1. 在服务商后台按账户列出所有在用密钥，标注用途与归属机器。
2. 对确定废弃的密钥执行撤销，记录撤销时间与操作人。
3. 对仍需使用的密钥签发新版本，先不要停用旧版本。
4. 更新配置、环境变量和插件里的引用，逐项替换为新密钥。
5. 用新密钥跑一次最小请求，再用旧密钥确认请求被拒绝。

验证不能只看配置文件。真正的确认来自一次实际调用：新密钥成功，旧密钥返回未授权。只在本地删掉字符串，得到的只是心理安慰。如果服务商提供密钥状态列表，也应看到旧密钥被标记为已撤销。

轮换期间要留意依赖同一密钥的脚本和定时任务。它们不在 DeepSeek Harness 的配置里，却可能因为旧密钥失效而集体报错。提前搜一遍环境变量和仓库中的引用，能避免这种连锁反应。

本机残留：dsh plugin 目录、shell 与日志都要翻

本机清理是防泄露，不是替代远端撤销。

配置文件的处理相对直接，删除密钥字段或改成指向一个空引用即可。环境变量要从 shell 配置、启动脚本和容器编排文件里一并移除，只改当前会话等于没改。改完重新打开一个终端，确认变量确实不存在。

插件目录需要单独检查，尤其是那些由第三方提供的 DSH插件。它们可能在自己的数据目录里保存令牌，命名与主程序完全不同。对照条目说明确认存储位置，再决定删除整个目录还是只清密钥文件。

日志和崩溃转储经常被忽略。请求失败时，调试信息可能包含完整的请求头，密钥就在里面。删除日志之前先确认没有留存价值，需要保留的部分做脱敏处理，而不是原样归档。

最后做一次全盘搜索，用密钥的前缀或特征串确认没有遗漏。搜索范围要包括隐藏目录、备份文件和编辑器缓存，这些地方最容易留下副本。找到的每一处都要处理，而不是只记录位置。

重装之前：DeepSeek Harness 的新凭据怎么建

重装不是恢复旧状态，而是一次重新分配权限的机会。

决定复用还是新建，取决于旧密钥是否经过轮换以及是否曾经暴露。如果旧密钥在日志或备份里出现过，直接新建更省心。复用看起来省一步，实际是在承担一段说不清的历史。

新建密钥时按用途拆分，比一把 Key 走天下更容易控制。对话、嵌入、批处理可以各用一把，额度与权限分别设置。这样某一环泄露时，影响范围是可计算的。

写入配置时优先使用环境变量或系统凭据存储，不要把明文提交进仓库。配置里保存引用而不是值，既方便轮换，也避免误传。团队协作时，密钥归属和用途要写进内部记录，而不是靠某个人记得。

装完之后先跑一次最小请求，确认模型、额度和网络都正常。再检查审批与工作区配置是否随重装恢复，避免把旧的宽松设置一起带回来。凭据正确但权限过大，仍然是隐患。

DSH插件用户该把卸载当成一次凭据盘点

卸载的价值不只是清理磁盘，而是逼你回答「这些密钥还该不该存在」。

日常使用中，密钥往往只增不减，测试用的、临时演示用的、某次排障留下的，都会一直留在账户里。卸载提供了一个自然的检查点，把这些条目重新过一遍。该撤销的撤销，该合并的合并。

盘点结果最好落到一份可维护的记录里：哪把密钥属于哪台机器、哪个用途、什么时候轮换。记录不必复杂，但要能在下次清理时直接使用。没有记录，下一次卸载仍然从零开始猜。

如果对某个位置拿不准，可以回到 DSH Plugin Hub 查插件条目，确认它是否有独立存储。凭据清理没有捷径，只有把位置、引用和远端状态三件事都核对一遍，才算完成。任何一处存疑，都应该按仍然有效来处理。

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