DeepSeek Harness v0.1.0-rc.7 升级验证指南

截至 2026 年 8 月 17 日，v0.1.0-rc.7 已作为官方预发布版本发布；官方同时明确 DeepSeek Harness 仍处于开发者预览阶段，可能出现破坏性兼容变化。(官方 v0.1.0-rc.7 Release) 因此，本周不要在唯一运行环境上直接覆盖升级：先记录当前版本、配置、插件和基准任务，再用隔离环境完成验证，通过后才迁移正式任务，并保留能实际执行的回退动作。

本周建议动作： 今天完成资产盘点与备份，下一工作日建立隔离工作区，随后按“Web UI → 模型 → 工作区 → 受控命令 → 会话 → 插件”的顺序验收；任一步失败，就停在当前阶段，不要继续叠加配置。

这篇文章适合维护日常开发环境的个人开发者、负责远程 Mac 与持续任务的运维人员，以及需要统一升级窗口和签收证据的平台负责人。如果你只是准备首次安装 DeepSeek Harness，而不是从旧版本迁移，这套流程会比你的实际需求更严格。

最后更新于 2026 年 8 月 18 日，版本信息核实自官方 Release、项目 README 与 Web UI 使用文档。

升级风险边界

这次版本更新并不是单纯替换一个可执行文件。官方 Release 列出的变化同时触及插件设置卡片、任务面板、MCP 与 ACP 图片附件、持久 Bash、历史会话分页、max-tokens 截断后的续用、Safari 输入框和 node-pty。

你需要特别注意以下限制：

• 配置层可能不止一处。 环境变量、项目根目录的 .env、用户目录配置和工作区选择可能分别影响启动结果。官方文档说明，Web UI 初次启动后还没有选定工作区，必须手动添加项目目录后才能使用会话编辑器。
• 插件问题不一定表现为启动失败。 插件可能能够加载，但设置卡片不出现、权限不完整、旧配置字段被忽略，或者只在特定工作区下失效。
• 会话恢复属于数据回归，不是界面回归。 大历史会话、截断后的续用和持久 Bash 都可能在短任务中看不出问题，必须使用你实际依赖的历史任务验证。
• 远程 Mac 还多一层连接风险。 SSH、浏览器访问、端口转发、睡眠策略和后台进程管理任何一项异常，都可能被误判成 DeepSeek Harness 本身的故障。
• 预发布版本的“已修复”不是你的通过证明。 Release 只说明维护者修复了对应问题，不代表你的插件组合、权限策略、浏览器和工作区已经验证通过。

如果你需要先准备一台可丢弃的测试主机，可以参考 VPSMAC 的 Mac 节点选择页面，重点不是追求更高规格，而是让测试环境与正式环境隔离，并且能够在失败后重新创建。

当前环境冻结

升级前先做一份“回退目标记录”，不要一开始就复制整个用户目录。无差别复制会把缓存、临时文件、旧依赖和可能泄露的密钥一起带到新环境，既增加恢复噪声，也会让你无法判断新版本究竟读取了哪份配置。

建议按以下步骤操作：

第 1 步：记录版本与安装来源。

保存当前 dsh 或 Web UI 实际启动时显示的版本，并注明你是通过 npm、源码工作区还是其他封装方式运行。源码安装还要记录 Git 分支、提交号、Node.js、pnpm 与 Git 版本；官方开发文档目前列出的 Node.js 支持范围为 22.19+ 和 24+，仓库固定的 pnpm 版本为 11.7.0。(官方开发文档) 你还可以对照 Node.js 官方版本与发布计划 和 pnpm 官方安装文档，确认隔离环境没有因为运行时或包管理器漂移而改变测试条件。

第 2 步：记录配置来源。

把以下内容写进升级记录：

• DEEPSEEK_API_KEY、DEEPSEEK_BASE_URL 等环境变量名称，密钥本身不要写入记录；
• 项目根目录 .env 是否存在；
• Web UI 中已配置的模型、工作区和权限策略；
• 启动目录、监听地址、端口以及远程访问方式；
• 当前正在运行的任务、未提交的代码和待恢复会话。

官方开发文档明确提醒不要提交真实凭据，真实 API 测试会从环境变量或被 Git 忽略的 .env 读取。

第 3 步：备份可恢复资产。

优先备份官方文档明确涉及的配置、会话存储、插件配置、工作区清单和启动脚本，再通过实际文件核验它们是否真的存在。不要假设某个目录一定保存会话，也不要把整个 HOME 目录当作备份对象。

第 4 步：建立基准任务。

至少保留一条短任务、一条需要读取工作区的任务、一条受控 Bash 任务和一条旧历史会话。每条任务记录输入、模型、是否调用插件、结果摘要、失败日志和人工判定。基准任务的价值在于比较前后行为，而不是测试越复杂越好。

第 5 步：冻结正式环境。

在隔离验证结束前，暂停自动更新、清理旧依赖和迁移长期任务。若正式环境正在执行持续任务，先等待安全检查点，或者把任务转移到可恢复队列；不要在运行中覆盖依赖。

隔离安装与身份确认

官方 README 给出的 Web UI 启动方式是 npx @deepseek-ai/dsh web，默认地址为 http://127.0.0.1:3080；源码方式则是克隆仓库、执行 pnpm install、构建后启动。对升级验证来说，关键不是照抄启动命令，而是保证命令运行在新的目录、用户或远程 Mac 中。

推荐按这个顺序执行：

1. 创建备用工作区，或者使用独立用户目录；正式仓库只读，不直接作为构建和测试目录。
2. 从官方仓库获取标签，确认实际标签名称为 dsh-v0.1.0-rc.7，不要凭记忆输入相似版本号。
3. 在隔离目录执行依赖安装和构建；源码升级时，保存安装日志、构建日志和完整提交号。
4. 启动后核对实际加载版本、启动目录、工作区和模型配置；版本号不匹配时，立即停止。
5. 在 Web UI 中重新选择测试工作区。启动进程使用调用目录作为默认文件系统位置，但新 Web UI 不会自动选定工作区。
6. 远程 Mac 场景下，从本地浏览器和远程终端各确认一次访问路径，避免把端口转发问题误认为版本故障。

隔离环境的身份确认要回答四个问题：运行的到底是不是 rc.7，读取的是哪一层配置，当前工作区是不是测试仓库，模型请求是否使用了测试凭据或明确的测试项目。只要有一个答案不清楚，就不应继续迁移正式任务。

首次启动与最小任务链

首次启动不要马上导入全部插件和历史数据。你应该先让新版本只完成一条最小链路，并为每一环设置明确的成功信号：

• Web UI： 页面能够打开，输入框可用，刷新后仍能重新进入；
• 模型选择： 能看到预期模型，保存配置后不需要依赖不明的旧缓存；
• 工作区读取： 只读取测试仓库，能够列出文件并返回正确的项目摘要；
• 受控命令： 执行无破坏性的版本查询或目录查看，确认权限确认流程正常；
• 结果返回： 文本结果完整返回，会话状态可见，日志中没有持续重试或异常退出。

每一步都应该保存截图、终端输出或日志片段。不要在第一条失败后继续添加插件、图片附件和复杂代理任务，否则最后只能知道“整体不工作”，无法定位是模型、工作区、权限还是 UI 变化造成的。

会话、插件与工具回归

这一步决定你是否真的可以升级，而不是判断程序能否启动。官方 Release 对旧会话分页、max-tokens 截断续用、持久 Bash 和 Safari 输入体验都列出了修复；这些项目应逐项验证，而不能用一条新建短会话代替。

建议使用自己的真实工作流做以下检查：

• 打开一条较长的历史会话，确认分页、滚动和继续提问正常；
• 找到曾经因 token 截断而中断的会话，验证是否能从原上下文继续；
• 在低风险目录执行持久 Bash，观察第二次命令是否继承预期状态；
• 打开常用插件设置卡片，检查字段、默认值、保存动作和重启后的持久化；
• 用 Safari 完成一次输入、编辑、删除和提交，重点观察光标位置与文本选区；
• 通过 MCP 或 ACP 发送一张测试图片，确认附件可见、会话重开后仍能引用；
• 单独切换低推理强度，记录默认值和结果差异，不要把“请求成功”误判为策略符合预期。

图片附件、低推理强度和 Job Panel 子代理管理属于新增或体验变化，最好分别建立独立任务。一次任务中同时使用插件、图片、持久 Bash 和子代理，失败后很难判断是哪条路径发生回归。

失败回退与分批切换

如果 rc.7 升级后插件打不开，先不要删除插件目录，也不要立刻重新安装所有依赖。先保存启动日志、插件名称、配置差异和失败发生的具体动作，然后关闭测试进程，回到原版本目录或原提交号，重新加载原配置副本，确认旧环境能够恢复最小基准任务。

推荐的回退顺序是：

1. 停止新版本进程，避免新旧进程同时写入同一份会话资产；
2. 恢复旧版本代码或旧安装入口；
3. 恢复升级前确认过的配置和会话备份；
4. 用短任务、工作区读取和历史会话确认回退成功；
5. 将失败日志与环境差异归档，暂缓正式迁移；
6. 等待官方后续说明或在更干净的隔离环境复现。

通过验证后也不要一次迁移所有仓库。先处理低风险、短周期任务，再处理长期任务，最后才考虑敏感项目和无人值守任务。正式签收材料至少应包含版本标签、安装方式、Node.js 与 pnpm 环境、任务结果、失败日志、配置差异、插件清单和明确的回退命令。

升级方案评分

下面的评分不是官方性能结论，而是面向维护决策的风险评分：分数越高，越适合在当前预发布阶段采用。评分依据是是否隔离、是否可恢复、是否容易定位失败，以及是否会影响正式任务。

如果你需要长期保留旧版本并行验证，建议先阅读 VPSMAC 的远程 Mac 使用入口，把测试环境当作可重建资产管理，而不是把正式机器临时改成实验机。

验收清单与持续复核

候选版阶段不应只在发布当天测试一次。官方 README 明确写出 DeepSeek Harness 处于开发者预览并可能出现兼容性破坏，因此你需要建立固定的 Release 检查、基准任务复跑和插件兼容复核节奏。

你可以把这张表保存到团队变更单中，每次 Release 都复跑同一组任务。若插件数量较多，按插件逐个启用；若远程 Mac 数量较多，先选一台作为基准节点，再复制经过验证的环境，而不是同时升级所有节点。

当前方案与 Mac 方案

如果你现在把 DeepSeek Harness 直接装在唯一的本地 Mac 上，主要缺点是升级期间无法并行保留旧环境、失败时容易污染会话和插件资产，而且本地机器还可能被日常开发、睡眠或权限变化打断。若改用临时云主机，常见问题又会转移到 macOS 兼容性、图形界面访问、Safari 验证和远程交互链路上。

对于只需要几天并行验证、团队验收或临时回退窗口的场景，租赁 VPSMAC 的远程 Mac 通常更适合：你可以把 rc.7 放在独立环境，把正式任务留在原机器，验证完成后再决定是否长期迁移。若你的工作负载是长期稳定的高强度任务、必须连接固定物理设备，或者已经拥有成熟的本地 Mac 运维体系，自购设备仍然更合理；租赁的价值主要在于降低这次升级试错的隔离与恢复成本。