dsh 源码更新要按顺序跑哪些命令？

dsh 源码更新按 git pull、corepack enable、pnpm install、pnpm run build 的顺序执行。拉取代码后先用 Corepack 对齐仓库固定的 pnpm@11.7.0，再装依赖并构建；构建完成后再用 pnpm run typecheck 校验，最后用 pnpm dsh 从源码启动确认可用。

dsh 源码更新后 pnpm --version 不对或找不到 pnpm 怎么办？

仓库在 package.json 里固定了 pnpm@11.7.0，并通过 Corepack 提供，所以先跑 corepack enable 让 pnpm --version 经过 Corepack 解析。如果版本仍不对，用 corepack prepare pnpm@11.7.0 --activate 激活对应版本，不要用系统里随便一个 pnpm 版本装依赖。

为什么源码构建出来的 dsh 版本号后面带了额外标记？

因为 pnpm run build 会把根包版本、七位源码提交号和本地改动标记一起嵌入构建产物，Git 报告有本地改动时就会出现 dirty 标记。发布态用 pnpm run build:official，它省略本地 dirty 标记，是 CI 与发布构建的跨平台本地等价物。

dsh 源码更新后怎么确认构建真的成功？

跑 pnpm run typecheck，它以成功退出表示类型与源码检查通过；再用 pnpm dsh --profile headless 或 pnpm run start:web 从源码启动一次。源码更新后能构建、能通过 typecheck、能从源码跑起来，才算这次更新完成。

在 WSL 或 Windows 上更新 dsh 源码有什么要注意的？

把代码、依赖和工具链放在同一个操作系统环境里：WSL 2 把 checkout 放在 Linux 文件系统，原生 Windows 就放在 Windows 文件系统，跨文件系统访问会给 Git、装依赖和构建增加 I/O 开销。每个环境要单独装一次依赖，因为原生二进制与链接可能不同。

dsh 源码方式怎么更新？DeepSeek Harness 拉取、装依赖、重建与校验完整链路

dsh 源码更新的完整链路是：git pull 拉取代码，用 Corepack 对齐仓库固定的 pnpm@11.7.0，pnpm install 装依赖，再用 pnpm run build 重建，最后用 pnpm run typecheck 与从源码启动校验（来源）。

本文只讲源码方式。如果你用的是 npx、npm 或桌面端，更新方式完全不同，三种安装方式的对照见《dsh 更新到最新版本的方法》。源码这条路的价值是拿到还未发版的提交，代价是每次更新都要走一遍「拉取 → 依赖 → 构建 → 校验」。

dsh 源码更新第一步：拉取代码并对齐 pnpm 版本

源码更新的第一道坎不是拉代码，而是让工具链满足仓库要求：Node.js 支持 22.19+ 与 24+，pnpm 必须经 Corepack 解析到仓库固定的 pnpm@11.7.0，Git 需要 2.26 或更新（来源）。

工具链版本线如下：

工具	要求
Node.js	22.19+ 或 24+
pnpm	经 Corepack 解析到 `pnpm@11.7.0`
Git	2.26+

按五步准备：

拉取最新源码 — 在仓库目录执行 git pull。预期：本地源码对齐到目标分支的最新提交。
对齐 pnpm 版本 — 先看 pnpm --version 是否经 Corepack 解析；若不是，执行 corepack enable，必要时用 corepack prepare pnpm@11.7.0 --activate。预期：pnpm --version 返回仓库固定版本，而不是系统里随意的 pnpm。
确认 Node 与 Git 版本线 — Node.js 用 22.19+ 或 24+，Git 用 2.26+。预期：版本满足后再进入下一步，避免装依赖到一半才报错。
动手前只读核对三项版本 — 执行 node --version、pnpm --version、git --version。预期：三项都在要求线上，再动代码。
核对当前分支与远端状态 — 执行 git status 与 git branch -vv。预期：本地没有意外改动、分支与远端对应，避免 git pull 时半路冲突。

dsh 源码更新怎么装依赖与重建：pnpm install 与 pnpm run build

装依赖用 pnpm install，重建用 pnpm run build：后者按依赖顺序跑完 Host 与 Client 两个聚合的 tsc 与 tsdown，最后产出 Web 构建（来源）。

按五步走：

装依赖 — 执行 pnpm install。预期：依赖就位，且 postinstall 会配置 worktree 本地的 Lefthook 钩子。
补装钩子（仅当缺失） — 如果依赖从缓存恢复或跳过了 postinstall，执行 node scripts/install-lefthook.mjs。预期：Git 钩子补齐，提交前的检查能正常工作。
重建产物 — 执行 pnpm run build。预期：Host 与 Client 两阶段构建依次完成，Web 产物被生成；需要发布态时改用 pnpm run build:official，它省略本地 dirty 标记。
构建前只读核对依赖目录 — 执行 ls -l node_modules（Windows 用 dir）。预期：依赖目录已就位，不是空的或装了一半的状态。
装依赖失败就别急着构建 — 先看 pnpm install 的输出，定位缺的是哪个包。预期：不在依赖没装全时启动构建，省掉白跑一轮的时间。

更新后怎么校验：版本标记、typecheck 与从源码运行

校验分三层：看构建产物里嵌入的版本标记、跑 pnpm run typecheck、再用 pnpm dsh 从源码启动一次（来源）。

五层逐个确认：

看版本标记 — pnpm run build 会嵌入根包版本、七位源码提交号，以及 Git 报告本地改动时的 dirty 标记。预期：版本号能对应到你拉取的那次提交；要发布态就用 pnpm run build:official。
跑 typecheck — 执行 pnpm run typecheck。预期：命令成功退出，表示类型与源码检查通过；它也是新克隆后推荐的第一次校验。
从源码启动 — 用 pnpm dsh --profile headless "summarize this workspace" 或 pnpm run start:web 运行一次。预期：能正常启动并完成一次实际调用，说明这次源码更新可用。
只读核对产物是否为本次生成 — 用 ls -l 看构建输出目录的修改时间。预期：时间戳与本次构建一致，排除「其实没重建、跑的还是旧产物」。
确认运行时版本与产物一致 — 从源码启动时看到的版本应与第 1 层嵌入的标记一致。预期：两边对得上，说明跑的就是刚重建的那一份。

dsh 源码更新的注意事项

代码、依赖、工具链放同一个系统 — WSL 2 把 checkout 放在 Linux 文件系统，原生 Windows 放在 Windows 文件系统，跨文件系统会让 Git、装依赖和构建变慢。
每个环境各自装依赖 — 原生二进制与链接可能随操作系统不同，Windows 和 WSL 要分别 pnpm install 与构建。
别提交 .env — 真实密钥放在仓库根目录被 gitignore 的 .env 里，靠环境变量读取。
更新后卡在旧行为先怀疑构建 — 先确认 pnpm run build 真的跑完，再用 pnpm run typecheck 与从源码启动定位。
拉取前留一份可用基线 — 记下当前能跑的提交号，需要时可切回。预期：源码更新出问题时手里有可回退的参照。
别把构建产物当成源码改动提交 — 产物属于本地构建状态。预期：git status 保持干净，dirty 标记只反映真实的源码改动。

源码这条链路解决的是「拿到最新代码并跑起来」，DSH插件本身的更新是另一套命令，适合用 DSH Plugin Hub 统一管理：已安装列表直接标出可更新的 DSH plugin，点一下即可处理，确认弹窗后再动手。

来源：DeepSeek Harness Development Guide（官方仓库）、Node engine floor Agent Note