How to Upgrade DeepSeek Harness Safely (rc.6 to 0.1.1-rc.1)

DeepSeek Harness（dsh）在 5 天内连发三个 npm 版本——0.1.0-rc.6、rc.7、rc.8、0.1.1-rc.1——因为它仍处于**开发者预览（developer preview）**阶段，每个版本至少带一处兼容性破坏性变更。其中最重要的两处：从 rc.8 起会话数据存储改用新的 SQLite 格式；同时，任何注册了 keyed 设置卡槽的插件现在都需要显式传入 options.key。本文按顺序梳理每个版本改了什么、升级前该做哪两件事，以及升级后如何用一份清单确认没有东西被悄悄弄坏。

版本时间线：每个版本改了什么

版本	发布时间	主要变化
0.1.0-rc.6	2026-08-13	此前已知的基线版本（依据 npm registry 时间戳）
0.1.0-rc.7	2026-08-17	插件可自行注册设置卡片；Codex/Claude Code 子代理任务接入 Job Panel；MCP/ACP 支持持久化图片附件；修复了极简模式下 bash 卡顿、大历史消息分页栈溢出、max-tokens 截断导致会话无法继续等问题；node-pty 升级到 1.2 beta；"Code mode" 更名为 "PTC mode"
0.1.0-rc.8	2026-08-19	多模态输入增强（/goal//plan 可接收图文输入，@ 菜单可引用文件和会话）；Claude Code/Codex 子代理可作为 Profile Bundle 按需安装，支持非交互权限模式与多个命名实例；Windows PTY 支持持久 PowerShell 会话；破坏性变更：SQLite 存储格式变更，keyed 设置卡槽现在强制要求 options.key
0.1.1-rc.1	2026-08-21	新增 DeepSeek-V4-Flash-Vision-Exp 模型适配器；修复 Bubblewrap 沙箱可经 /proc/<pid>/root 绕过限制的问题；会话 Markdown 表格自适应、缓存命中率显示精度提升；ask_user_question 支持多行输入与 Shift+Enter

节奏大约是每两天一个版本。如果你上次接触 dsh 还停留在 rc.6，这次升级相当于一口气跨过三个版本、两处破坏性变更——建议先读完下面两节再动手执行升级命令。

升级前必做的两件事

1. 备份会话数据。 有社区用户在从 rc.6 升级到 rc.8 时发现，dsh 的会话存储从 rc.8 起改用了新的 SQLite 格式（社区报告，Discussions #3691）。跨越这个版本边界升级前，建议整体备份 $DSH_HOME 目录（默认 ~/.dsh）——这个目录同时保存着你的 profile、凭证和会话历史，完整拷贝一份的成本很低，能防止存储格式迁移出岔子。

2. 记下当前 profile 的插件清单。 每个 profile 已安装的插件都记录在 $DSH_HOME/profiles/<name>/package.json 里，具体是 dsh.profile.bundles 列表加上该 profile 自己的 npm 依赖。升级前先复制一份这个文件（如果你的 profile 目录纳入了版本控制，直接 git diff 也行），这样升级后如果某个插件面板消失或报错，你就有一份确凿的对照基准。

破坏性变更详解：keyed 卡槽现在强制要求 options.key

从 rc.8 起，任何注册了 settings.plugin.item keyed 卡槽（一种需要在多次渲染间保持稳定身份的设置 UI 元素，通常用于逐项配置的列表）的插件，都必须传入显式的 options.key。之前不带 key 也能正常工作的卡槽，现在会渲染失败或在启动时直接抛错。

社区报告中点名了两个真实受影响的插件：dsh-vision-router 和 dsh-smart-route。如果你在用这两者之一，升级 dsh 之前先去看看是否有更新版本发布。

如果你是插件用户： 升级后打开设置 → 插件，对比升级前记录的清单（见上一节），检查有没有卡片是空白的、控制台报错的，或者干脆整个消失了——这正是这处破坏性变更的典型症状。去插件仓库看是否已有新版本；如果还没有，要么把 dsh 固定在之前的版本等插件跟上，要么向作者提 issue 并附上这条讨论线索。

如果你是插件作者： 你插件里任何 settings.plugin.item 卡槽注册处，现在都需要补上 options.key——不是"以后再说"，rc.8 已经发布，0.1.1-rc.1 是在此基础上继续迭代的。这是个很小、很机械的修复，但跳过它会让所有 rc.8 及之后版本的用户的插件设置界面悄悄失效。

已知升级坑与修复方案

本周社区反复提到三个安装期问题。它们都不是 DeepSeek 官方文档给出的方案，请当作经过实战验证的社区 workaround，而非保证有效的官方修复。

低内存机器上 npm install 会 OOM。 有社区用户在从 rc.6 升级到 rc.8 时遇到 V8 heap 内存溢出（社区报告，Discussions #3691）。调高 Node 的堆内存上限可以绕过：

NODE_OPTIONS=--max-old-space-size=6144 npx @deepseek-ai/dsh@0.1.1-rc.1 web

native 依赖的构建脚本被拦截。 dsh 依赖了几个 native 模块——node-pty、koffi、@deepseek-ai/dsh-subprocess-local——它们在安装时需要跑构建脚本。pnpm 10 出于供应链攻击防护考虑，默认拦截依赖的生命周期脚本，因此这些构建会被静默跳过，除非你显式审批（参见 pnpm 官方文档）。如果 dsh 安装完成了，但 native 相关功能（终端 PTY、文件夹选择器、子进程执行）不工作，运行：

pnpm approve-builds

并审批被标记的依赖包。升级后遇到这个问题的社区用户（Discussions #3691）把这一摩擦点归因于正是这套机制。

npx 卡在依赖解析阶段。 另一条尚未解决的报告描述 npx @deepseek-ai/dsh web 会无限卡住——CPU 占用 100%、零网络流量，换镜像源也无效（社区报告，Discussions #3786）。一条更新的 Reddit 报告描述了相同症状，安装日志卡在拉取 @deepseek-ai/dsh-client-modules 处，得到的建议是换一个包运行器：

bunx @deepseek-ai/dsh@0.1.1-rc.1 web

这个方案只有一条社区回复背书，尚未经过更多验证——如果你也遇到 npx 卡死，先试试它，再去折腾 registry 配置。

为什么值得升级到 0.1.1-rc.1

除了版本号本身，0.1.1-rc.1 里有三处值得特别提一下：

• 一个真正的沙箱安全修复。 该版本修补了 Bubblewrap 沙箱的一个绕过点：受限进程原本可以经 /proc/<pid>/root 逃出限制。如果你运行 dsh 时用的不是 danger-full-access，这个修复补上了你原本以为存在、实际有缺口的隔离能力——具体各沙箱模式如何配合，参见我们的权限与沙箱指南，以及能进一步加固的 Security & Permissions 分类插件。
• 原生视觉支持。 dsh 的模型适配器现在可以直接对接 DeepSeek-V4-Flash-Vision-Exp，取代了此前部分模型靠 OCR+像素分析硬凑出来的"伪视觉"方案。如果你打算在此基础上开发，可以逛逛 Vision, Voice & Multimodal 分类下的插件。
• 缓存命中率显示精度提升。 这只是个 UI 层面的小修复，但如果你习惯直接在 Web UI 里判断 DeepSeek 的 KV 缓存计费行为、而不是查 API 原始数据，这个改动是实打实有用的。

锁版本 vs. 跟随最新版

dsh 没有 changelog 页面，也没有正式的迁移指南——npm 的 dist-tags 和 GitHub Releases 页面是了解版本变化和当前 latest 指向的唯一权威来源。实践中有两种姿势：

• 锁定版本：如果你在 CI、演示环境，或者任何"可复现性比拿到最新特性更重要"的场景里跑 dsh，用显式版本号：npx @deepseek-ai/dsh@0.1.1-rc.1 web。
• 等下一个 rc：如果你依赖的某个插件还没发布 keyed 卡槽的修复版，或者你刚升级完想让当前版本先稳定一段时间再动——考虑到本周大约每两天一版的节奏，多等几天成本通常不高。

升级后验证 checklist

任何一次升级后都建议走一遍，跨越 rc.8 存储格式边界时尤其要走：

[ ] dsh web 能正常启动，Web UI 加载无控制台报错
[ ] 设置 → 模型 里保存的 API key 依旧在
[ ] 设置 → 插件 里列出了升级前的每个插件，没有空白/报错卡片
[ ] 打开一个升级前的旧会话，消息历史能正常渲染
[ ] 发送一条新任务，工具调用能正常流式返回

如果某个插件面板缺失，先回去看上面 keyed 卡槽那一节，再考虑是不是别的原因。

FAQ

每次 dsh 更新我都需要备份吗？

不是每次都需要——但跨越 rc.6 → rc.8 这个边界时一定要，因为正是这个版本改变了会话存储的格式本身（社区报告，Discussions #3691）。备份整个 $DSH_HOME 的成本很低，任何跨多个版本的升级前都值得做一次。

rc.6 到 0.1.1-rc.1 之间到底有哪些破坏性变更？

目前唯一一处被明确点名的破坏性变更，是 rc.8 引入的 keyed 卡槽 options.key 强制要求。dsh 除了发布说明和 GitHub Discussions 之外，并没有正式的迁移指南，其余变化都应当被视为较小的修复或功能新增，而非硬性破坏。

DeepSeek Harness 现在可以放心用在生产环境了吗？

它仍然明确处于开发者预览阶段，版本之间会有兼容性破坏。想全面了解目前已知的安全隐患和已修复的问题，可以看我们的插件安全检查清单和DeepSeek Harness 安全现状。

我怎么知道自己装的到底是哪个版本？

dsh 自己没有类似 --version 的 changelog 机制，npm registry 是权威来源。运行 npm view @deepseek-ai/dsh dist-tags 可以看到 latest 当前指向哪个版本；如果需要精确知道自己在跑什么，直接在启动命令里锁定具体版本号即可。

我现在该升级还是再等等？

如果你装的插件都没受 keyed 卡槽变更影响，也不急着用视觉模型或沙箱修复，那就没有紧迫性——本周 dsh 大约每两天发一个新 rc，多等几天通常不会等太久。

Next steps

升级完成后，先过一遍权限与沙箱模型，确认自己跑的隔离级别符合预期；也可以看看 dsh 头两周社区都在说什么，了解项目目前所处的更大背景。如果有插件还没跟上 keyed 卡槽的变更，去 /zh/plugins 逛逛完整目录找替代品；如果 0.1.1-rc.1 里的沙箱修复让你想更全面地审视自己的配置，可以从 Security & Permissions 分类开始。