npx @deepseek-ai/dsh web 这条命令到底做了什么？

它一步完成「下载 + 启动」：npx 从 npm 拉取最新版 @deepseek-ai/dsh 包，执行其中的 dsh 命令，web 是 dsh web 的别名、等价于 dsh --profile web，启动的是 web 应用、并在终端打印访问地址。

npx @deepseek-ai/dsh web 下载的文件存在哪里？

包本体缓存到 npm 的 npx 缓存目录，用户数据与配置文件放在 $DSH_HOME（默认 ~/.dsh）；web profile 会在首次运行时从内置模板自动初始化，profile 目录里有 package.json、dsh.profile 清单与 cordis.patch.yml 补丁层。

npx 方式不装全局包，那它和 npm install -g 有什么区别？

npm install -g 把 dsh 装进全局目录、需要全局写权限且长期占空间；npx 每次运行临时拉取到缓存、用完即弃，不需要全局权限，还能自动保持最新。想在终端里直接敲 dsh 命令才需要全局安装。

为什么不建议直接用 sudo npm install -g 装 dsh？

因为全局默认写到系统目录，普通用户没权限，sudo 提权会把包的归属越弄越乱。更稳妥的做法是用 npx 临时运行，或把 npm 全局前缀改到用户目录（npm config set prefix ~/.npm-global）再装。

npx @deepseek-ai/dsh web 和源码构建是同一套东西吗？

同一套 dsh，区别在运行来源：npx 用 npm 发布的最新包，开箱即用；源码构建要 git clone + pnpm install + pnpm run build 再运行 pnpm dsh，适合想跟随开发版或改代码的人，生产运行必须先构建。

启动后想装插件，用这条命令还是别的方式？

装插件走 dsh plugin，例如 dsh plugin --profile web add dsh-plugin。更省心的是装 DSH Plugin Hub 后在「设置 → 插件市场」一键安装，来源、版本、进度都有界面可查。

DeepSeek Harness 用 npx 一键启动 Web UI：这条命令做了什么、数据存在哪里

npx @deepseek-ai/dsh web 是一条命令把 DeepSeek Harness 的 Web UI 跑起来的官方方式：npx 负责从 npm 拉取最新包并执行 dsh，web 是 dsh web 的别名、等价于 dsh --profile web，启动的是 web 应用。这条命令背后是「一份 npm 包 + 一个 profile 组合机制 + 一个用户数据目录」，本文把这三个层次拆开讲透：它下载了什么、数据存在哪、为什么不需要全局安装，以及它和 npm 全局安装、源码构建到底是不是同一套东西。

一句话理解：npx 把「下载 + 启动」合并成一步

npx @deepseek-ai/dsh web 的核心价值，是把「下载包」和「启动应用」两个动作合并成一条命令。 传统安装要先装、再启动，而 npx 每次运行都会从 npm 拉取最新版并立刻执行，所以你永远跑的是最新版，也不需要先手动安装。

拆开看这条命令有三段：

npx：npm 附带的执行器，负责从 npm 拉取并运行一个包，不需要先全局安装，也不会污染全局环境（来源）。
@deepseek-ai/dsh：DeepSeek 官方发布的 npm 包，是 DeepSeek Harness 的 Node 应用启动器（launcher），dsh 命令是唯一受支持的 Node 应用启动入口（来源）。
web：dsh web 的别名，等价于 dsh --profile web，启动的是 web 应用（Web UI）（来源）。

官方 Quickstart 也是这么用的：先按根 README 启动 Web UI，命令会打印访问地址（来源）。

第一层：@deepseek-ai/dsh 这个 npm 包是什么

@deepseek-ai/dsh 是 DeepSeek Harness 的启动器包，你运行的 dsh 命令就来自它。 从 npm 元数据看（来源）：

属性	值	含义
包名	`@deepseek-ai/dsh`	DeepSeek 官方 scoped 包
许可证	MIT	开源协议，可自由使用
依赖	62 个	启动器与运行时的依赖集合
被依赖	39 个	有生态在基于它构建
周下载	443,043	使用量可观

dsh 命令只做一件事：加载选中的 profile（profile 是插件 bundle 补丁层的有序堆叠），把其余参数交给 booted 的 profile 去解析。命令语法由 src/args.ts 负责，src/bin.ts 只加载当前选中的 runner（来源）。

正是这个「只加载选中 runner」的设计，让 npx @deepseek-ai/dsh web 不必把 web、headless、sdk 等全部跑起来——它只启动你指定的那一个。无效命令、来自其他模式的参数、配置错误、启动失败都会以非零码退出，方便你在脚本里判断。

第二层：web 是 --profile web 的别名，profile 是组合机制

web 根本不是单独的应用，它就是 --profile web 的别名；profile 是把多个插件 bundle 按顺序叠加补丁的组合机制。 这是理解这条命令的关键。dsh 启动的每个 profile 目录里都有一份 package.json（包含 profile 外的插件依赖和 profile 清单 dsh.profile，清单里是有序的 bundles 列表和 patchReload 生命周期）与一份 cordis.patch.yml（你自己的补丁层）（来源）。

Web UI 是由多个 bundle 拼出来的，整棵配置树的组合顺序是（在空根之上依次叠加）：

按 dsh.profile.bundles 顺序应用每个 bundle 的补丁；
再应用 profile 的 cordis.patch.yml；
再应用 home 级 $DSH_HOME/cordis.patch.yml；
最后叠加 --patch 覆盖层。

dsh.profile.bundles 里列出的 bundle 会优先从 dsh 安装中解析（@deepseek-ai/dsh-base、@deepseek-ai/dsh-web-app、@deepseek-ai/dsh-headless、@deepseek-ai/dsh-sdk-app、@deepseek-ai/dsh-sdk-minimal、@deepseek-ai/dsh-acp-app），其次才从 profile 自己的 node_modules 解析，后者是 pnpm 安装 profile 外插件的地方（来源）。web、headless、sdk、sdk-minimal、acp 这些 profile 会在首次使用时从内置模板自动初始化，其他 profile 必须通过 dsh plugin 创建。

想看到组合后的完整配置而不启动，可用 --dump-default-config 和 --dump-config 检查。

第三层：数据存在哪（$DSH_HOME 与调用目录）

npx 方式不会把用户数据散落全局，而是集中到 $DSH_HOME（默认 ~/.dsh），并把启动 dsh 时所在的目录当作默认工作区。 这决定了你的配置、插件和文件都在哪：

调用目录 = 默认工作区根：你在哪个目录执行 npx @deepseek-ai/dsh web，那个目录就会被当作默认文件系统位置（来源）。Web UI 在添加工作区前不会默认选中任何目录（来源）。
$DSH_HOME = 用户数据目录：默认在 ~/.dsh，profile 目录就放在 $DSH_HOME/profiles/<name> 下；home 级补丁 $DSH_HOME/cordis.patch.yml 也会被读取（来源）。
npm 缓存目录：npx 拉取的包本体缓存在 npm 的缓存目录里，与用户数据目录是两个地方。

所以删包、换机器时，真正要紧的是你 $DSH_HOME 里的配置与插件，而不是 npx 缓存里的临时包。

为什么 npx 不占全局空间、还始终最新

npx 的设计就是不安装进全局：它把包拉到缓存、用完即弃，所以既不需要全局写权限，也能自动保持最新。 这一下解决了两个最常见的痛点：

不用全局权限：npm install -g 默认把包写到系统目录，普通用户常遇到 EACCES（权限不足）。npx 直接绕开，不碰系统目录，也就不需要 sudo。
永远跑最新：每次 npx @deepseek-ai/dsh web 都会从 npm 拉取最新发布的包，你不需要手动 npm update 本体。

代价是：你没办法在终端里直接敲 dsh 命令（因为没装进全局 bin）。如果你需要 dsh web、dsh plugin 这种裸命令，就得走全局安装。这是 npx 与全局安装最本质的取舍。

npx、npm 全局安装、源码构建三者对比

三者跑的是同一套 dsh，只是「从哪里来」不同；日常用 npx，想敲裸命令用全局安装，想跟开发版用源码构建。 对照如下：

方式	命令	是否需构建	是否占全局	适合场景	数据目录
npx 临时运行	`npx @deepseek-ai/dsh web`	否	否	日常一键启动、保持最新	`~/.dsh`
npm 全局安装	`npm install -g @deepseek-ai/dsh`	否	是	想在终端敲 `dsh` 裸命令	`~/.dsh`
源码构建	`git clone` + `pnpm install` + `pnpm run build`	是（生产必须先构建）	否	跟踪开发版、改源码	`~/.dsh`/仓库内

三者共享同一个 profile 组合机制与 $DSH_HOME 数据目录，所以配置、插件、工作区是通用的，切换方式不丢数据。源码构建因为跑的是仓库里的 TypeScript 入口，运行方式是把参数全部转发给 pnpm dsh <args...>（来源）。

装完 DSH 之后：用 DSH Plugin Hub 一键装插件

启动只是第一步——DSH 的能力来自插件，装插件最省心的方式是走 DSH Plugin Hub 的「设置 → 插件市场」。 你可以在终端用 dsh plugin --profile web add <插件包名> 逐个装，但社区更主流的做法是先装 DSH Plugin Hub，再用它的界面管理一切：装 Hub 只需要一条命令 dsh plugin --profile web add dsh-plugin，装完重启 dsh web，打开 设置 → 插件市场 就是 DSH Plugin Hub 的插件市场首页，按分类浏览社区插件、卡片直接展示名称、描述、Star 与更新时间：

点进任意插件即可一键安装，后台串行执行、弹窗实时显示进度，装完大部分插件刷新页面即生效：

这下你既理解了 npx @deepseek-ai/dsh web 在背后做了什么，也知道装完 DSH 后怎么把插件生态接起来了。如果你更关心不同模式的取舍，例如 headless、sdk、acp 分别用来做什么，可以看《DeepSeek Harness 一条 dsh 命令多种模式：web、headless、sdk、acp 怎么选》。

来源：npm 包 @deepseek-ai/dsh、dsh CLI README、官方 Quickstart