DeepSeek Harness 怎么更新、回退与卸载

先确认你要更新哪一层

DeepSeek Harness 的“更新”可能指三件不同的事：切换 @deepseek-ai/dsh 版本、更新某个 Profile 中的 Bundle，或更新源码 checkout。三者的命令、数据位置和回退方式不同。最稳妥的做法是先固定当前版本和配置快照，只变更一层，验证完成后再处理下一层。

本文固定审阅官方 dsh-v0.1.1-rc.2（commit b150a551b8d465e31e418e1b2eaf5e79bbb7d28e）。没有执行真实升级、删除 Profile 或清理凭据。DSH 仍处于 Developer Preview，升级前应阅读目标 Release 的变化，而不是默认配置在候选版本之间永久兼容。

第一步：记录当前版本和配置

先停止新的任务，并在当前使用的同一个终端中记录：

dsh --version
dsh --profile web --dump-config

如果你一直通过 npx 使用 DSH，可以用固定版本确认当前文章对应的 CLI：

npx @deepseek-ai/dsh@0.1.1-rc.2 --version

--dump-config 只解析组合出的配置树，不启动 Web 应用。它会显示 Bundle、Profile patch、Home patch 和命令行 patch 的叠加结果，适合在升级前后做差异对比。输出中仍可能包含本机路径或其他部署信息，公开前要脱敏。

同时记录实际使用的 Profile 名称。插件安装、更新和移除都绑定 Profile；在 web 中安装的 Bundle，不会因为你对 headless 执行更新而自动同步。

第二步：备份该保留什么

升级前至少保存以下信息：

• $DSH_HOME/profiles/<name>/package.json 与 pnpm-workspace.yaml；
• Profile 自身和 Home 级的 cordis.patch.yml；
• 需要保留的 Session 和工作区变更；
• 当前 DSH 版本、插件包版本、操作系统和验证日期。

$DSH_HOME/.credentials.yaml、.env 和 Provider Key 属于敏感资产。可以按你的密钥管理制度做加密备份，但不要把它们复制进 Git、普通压缩包、文章附件或公开工单。更新前使用 git status --short 检查真实工作区，避免把未提交内容误当成 DSH 版本变化。

使用 npx 时怎样更新 DSH

官方快速启动使用 npx @deepseek-ai/dsh web。npx 用户不一定存在一个可卸载的全局 DSH；每次显式指定版本，更容易让运行代码与教程、日志和回退记录一致：

npx @deepseek-ai/dsh@0.1.1-rc.2 web

准备升级时，把版本改为你已经阅读并审核过的目标 Release。不要同时更新 DSH、Node.js、全部插件和 Provider 配置，否则失败后很难判断是哪一层造成变化。

验证新版本时先使用可丢弃工作区和低风险任务，依次检查 Web 启动、模型选择、只读请求、Profile 配置和一个必要插件。确认后再回到真实项目。

从源码运行时怎样更新

源码方式不应直接把移动的 master 当作可回退版本。记录当前 Tag 或 commit，在新的 checkout 或独立分支中检出目标版本，然后按官方开发文档重新安装依赖并构建：

pnpm install
pnpm run build
pnpm dsh --version

官方 CLI 说明强调，pnpm dsh 本身不会自动构建；旧构建产物可能继续运行旧浏览器代码。更新源码后如果没有重新构建，看到“命令能启动”也不能证明新版本已生效。

Profile 插件怎样升级

DSH 把插件子命令转发给该 Profile 目录中的 pnpm。更新单个包时使用：

dsh plugin --profile web update <package-name>

成功后，CLI 会根据当前安装状态重新整理 dsh.profile.bundles。如果包在更新后新增了 DSH Bundle 声明，它会进入配置层；如果不再是 Bundle，则会从层列表移除。更新 Bundle 只改变磁盘上的 Profile，正在运行的进程仍保留启动时的 Bundle 集合，因此需要重启对应 Profile。

更新前仍要核对包来源、固定版本、许可证、构建脚本、权限和数据迁移说明。update 成功只表示包管理步骤完成，不表示功能、权限或 DSH 兼容性已经实测通过。

怎样验证升级结果

建议按以下顺序验收：

1. 再次执行 --version，确认实际启动的是目标版本；
2. 使用 --dump-config 对比 Bundle 与 patch 来源；
3. 启动对应 Profile，检查设置页和模型选择；
4. 在可丢弃工作区运行一个只读任务；
5. 只验证升级范围内的插件，不顺手启用更多能力；
6. 查看 Session、日志和工作区 Diff 是否出现异常。

模型、插件、权限和 Session 的变化应分别记录。需要完整安全边界时，结合DSH 权限与沙箱指南和Session 恢复指南复核。

回退到固定版本

npx 用户可以把命令重新指向升级前记录的版本。源码用户应切回已记录的 Tag 或 commit，并重新安装、构建。Profile 插件则应恢复已备份的 manifest 与锁定版本，再让包管理器根据那份状态安装；不要只恢复 cordis.patch.yml，因为 Bundle 依赖本身也必须与配置对应。

回退后仍要重启 Profile 并重新执行最小验证。新版已经写入的业务数据或 Session 不一定能被旧版无损读取；没有官方迁移承诺时，应保留升级前副本，避免直接在唯一数据上来回切换。

怎样卸载插件或 DSH

移除某个 Profile 中的插件：

dsh plugin --profile web remove <package-name>

成功后重启 Profile，并通过 --dump-config 确认对应 Bundle 层已消失。移除 npm 依赖不会自动撤销外部账号授权，也不保证删除插件写入的数据、日志、缓存或凭据引用；清理范围必须以该插件自己的固定版本文档为准。

如果你只通过 npx 调用 DSH，通常没有一个常驻全局包需要卸载。npm 缓存、DSH Home、Profile、Session 和凭据是不同的数据域，不要为了“卸载干净”递归删除整个用户目录或 $DSH_HOME。如果曾自行做过全局安装，应使用当时对应的包管理器移除，并先确认命令解析路径，避免卸载了一个副本却继续运行另一个副本。

源码 checkout 也只是代码目录；删除前先停止进程、确认路径、备份未提交修改和所需数据。本文不提供递归删除命令，避免把工作区、Home 或其他仓库误当成目标。

本文的验证范围

本文完成了固定 Release、CLI 插件转发与 Bundle 整理逻辑、配置层和 npm npx 说明的静态审阅。没有执行升级、卸载、数据迁移或第三方插件，也不承诺所有候选版本都能无损回退。

第一次安装请从DeepSeek Harness 安装与 Web UI 指南开始；只处理插件时，继续阅读Profile、Bundle 与插件安装指南。