奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

npx @deepseek-ai/dsh web 是做什么的？默认端口 3080 与 Node 版本门槛

2026-08-16

先直接回答标题：npx @deepseek-ai/dsh web 是 DeepSeek Harness 的 README 里唯一一条不用克隆仓库的路径，跑起来会启动 Web UI，默认服务在 http://127.0.0.1:3080。README 对前置条件只写了一句「装 Node.js」，但根 package.json:8-10 声明的是 ^22.19.0 || >=24.0.0——而我们扫过的 230 份会发布出去的 manifest 里，带 engines 字段的是 0 份，也就是说这条门槛不会随包一起被 npm 校验到。这几条的出处、以及另外两条运行路径，下面逐条对。

先把时间戳钉死：deepseek-ai/deepseek-harness 这个仓库建立于 2026-08-13，我们采集事实的时间是 2026-08-16，前后只差三天。根 package.json:3 里的版本是 0.1.0-rc.5，GitHub 的 /releases 接口返回空数组——一个 Release 都没有。README 第 9 到 11 行自己标着「Developer preview」，紧跟一句加粗原文：THERE WILL BE COMPATIBILITY-BREAKING CHANGES.，中文侧 README.zh.md:9-11 写的是「未来将出现破坏兼容性的变更」。

所以下面所有命令、路径、默认值，都要按「随时会变」来读。本文全部内容来自 2026-08-16 取到的快照 47f9438 的文件实读，我们没有安装、没有构建、没有运行过其中任何一条命令。

路径 A：npx，README 唯一的「不克隆」路径

README.md:15-23 给出的就一条命令：

npx @deepseek-ai/dsh web

前置条件在 README.md:17，原文只有一句 Install Node.js, then run:。紧接着 README.md:23 说明这条命令会启动 Web UI，默认服务在 http://127.0.0.1:3080，中文侧 README.zh.md:23 同义。

3080 这个数字不是文档里随口写的，它在代码里有落点：组合配置 packages/bundle/web-app/cordis.patch.yml:118-120 写的是 port: !!js ctx.webStartup.port ?? 3080，packages/boot/cmdline/src/index.ts:14 的注释用的是同一个式子，测试也把它固化了（packages/bundle/web-app/tests/startup.spec.ts:59 与 :110）。有意思的是 examples/web-cordis/cordis.yml:9 的注释反过来说明了它的默认地位：「在这里钉住端口，好让这个 demo 避开默认的 3080」。

这仍然只是配置里的默认值，不是「你用起来会怎样」的承诺。

这条路上有个值得单独拎出来的口径落差。README 的门槛只说「装 Node.js」，但根 package.json:8-10 声明的是 "node": "^22.19.0 || >=24.0.0"；而根包在 package.json:5 标着 private: true。我们扫过 packages/*/*、apps/*、vendor/* 共 230 份 manifest，含 engines 字段的是 0 份——包括将要被发布出去的 apps/cli/package.json。也就是说，仓库里那条 Node 版本门槛，并不会随发布出去的包一起被 npm 校验到。这两处的位置就是 package.json:8-10（有门槛、不发布）与那 230 份 manifest（发布、无门槛），差异到此为止，我们不推断原因。

还得诚实说一句：我们没有联网查过 npm registry，所以 @deepseek-ai/dsh 在 registry 上是否存在、发过哪些版本、npx 实际会拉到什么，我们核不到。README 写了这条命令，我们只能记录到这里。

路径 B：从源码跑，README 给的命令一条都不能省

README.md:29-35 给的是完整的命令序列（README.zh.md:29-35 同步）：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

最后一步的 pnpm dsh 定义在 package.json:136："dsh": "node --import tsx/esm apps/cli/src/bin.ts"——直接用 tsx 跑 TypeScript 入口。而 pnpm run build 在 package.json:20 展开为 npm run build:lib && npm run build:web，再往下拆成 host 侧（package.json:22，tsc -b tsconfig.host.json && tsdown --env.DSH_BUILD_FACE host）、client 侧（:23）和前端（:24，pnpm --filter @deepseek-ai/dsh-web-frontend run build）三段。

这里有一条写得很直白的经验，来自 apps/cli/reference/README.md:84：新克隆之后 pnpm run build 必须单独跑一次；缺少 Typert host 产物时，profile boot 会以模块解析错误失败，而且不会提示你去构建；host 产物有了但前端/客户端 bundle 缺失时，启动会报错并提示跑 pnpm run build。同一段还有一句更要紧的：「The launcher does not check freshness」——启动器不检查产物新鲜度，旧的 bundle 会继续跑着老的浏览器端代码，直到你重新构建。这一条写在参考文档里，拉完新代码时值得先想起来。

产物本身不在仓库里：.gitignore:4 忽略 lib/、:33 忽略 apps/web/dist/。顺带的结果是，apps/cli/package.json:14-16 声明的 bin: { "dsh": "lib/bin.js" } 所指向的文件，在我们这份快照里是看不到的。

门槛清单：Node、pnpm、Git，以及 install 的副作用

  • Node：全仓只有根 package.json:8-10 一处声明 ^22.19.0 || >=24.0.0。AGENTS.md:62 的命令表首行写着同样的区间。.agents/notes/implemented/process/2026-07-06-node-engine-floor.md:20 解释了这个写法的两层含义：源码特性在 22.x 线上 22.18 就齐了，是依赖把 LTS 下限抬到 22.19；而这个区间「excludes Node 23 entirely」——Node 23 整条线被排除在外。
  • pnpm：package.json:7 钉死 "packageManager": "pnpm@11.7.0"，docs/development.md:11-14 要求通过 Corepack 启用。
  • Git：同一段前置条件里写 2.26 或更新。
  • CI 实证：.github/workflows/ci.yml:38 的 PRIMARY_NODE_VERSION 是 '24'；兼容矩阵 ci.yml:272-279 只有两条，node: '22.19' 和 node: 26，且这个 job 的 if 限定为 pull_request（ci.yml:261）。

pnpm install 不是纯粹的装依赖。docs/development.md:24 说明它会通过 scripts/install-lefthook.mjs 给你的 worktree 配好 Lefthook hooks 和一个叫 dsh-translation-pairing 的 git merge driver，对应 package.json:142 的 "postinstall"。按 lefthook.yml 的配置，pre-commit 挂着六个 job、pre-push 挂着 pnpm run typecheck——这是配置里写着的钩子，不是「你提交时一定会怎样」的保证，但至少说明这个仓库不打算让你克隆下来改一行就直接提交。

另一条摩擦来自 pnpm 10+ 的构建脚本白名单。pnpm-workspace.yaml:40-55 的 allowBuilds 显式放行 esbuild、lefthook、node-pty、koffi 等，显式拒绝 @google/genai、protobufjs 等，注释（:35-39）自陈这是「deny by default」。apps/cli/reference/README.md:51 把后果说清楚了：装 git 托管、带源码、靠 prepare 脚本构建的第三方插件时，第一次 dsh plugin add 会失败并打印 allowBuilds 提示，你得把 key 复制进 profile 的 pnpm-workspace.yaml 再重跑。

路径 C：Python SDK 是第三条路，但有平台白名单

docs/user/guide/python-sdk.md:19-25 给的是另一套：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
python -m venv .venv
. .venv/bin/activate
python -m pip install deepseek-harness-sdk

前置条件在 :9-13，其中一条对本站读者格外要紧：平台原文写的是 Linux x64, Linux arm64, or macOS 14 or newer on arm64——这份清单里没有 Windows。另外要求 Python 3.10+、Git、一个 DeepSeek 兼容的 API 端点与凭据，以及一个允许 agent 修改的隔离 workspace。:27 补了一句：这个装好的 runtime 不需要系统里的 Node.js。

至于前两条路在 Windows 上的完整可用面，我们只在仓库里看到零散痕迹：package.json:58 的 check:windows-wine、:59-61 三条 check:ci:windows-*、ci.yml:661 的 runs-on: [self-hosted, dsh-win-ci, windows]、apps/cli/tests/windows-shell.spec.ts 的存在，以及 pnpm-workspace.yaml:43,51 里关于 ConPTY 与 MoveFileExW 的注释。至于「哪些功能在 Windows 上可用」，我们没能在仓库里找到一处完整清单，所以这一点我们不给结论。

起来之后：profile、$DSH_HOME 与几条硬边界

dsh web 不是一个独立的服务命令，apps/cli/README.md:9-14 的表里写明它是 --profile web 的别名。同表另外三行是 dsh --profile <name>、dsh --profile headless "job"（跑一个全新持久化会话，打印最终答案后退出）、dsh plugin --profile <name> <pnpm args>。apps/cli/README.md:16 说明 web 和 headless 两个 profile 首次使用时会从随包模板自动初始化，其它 profile 必须经由 dsh plugin 创建。

profile 落在哪儿由 $DSH_HOME 决定。packages/util/home-paths/src/index.ts:12 定义目录名 .dsh，:62 默认值是 join(homedir(), '.dsh')，:79-81 的优先级是「显式配置路径 > $DSH_HOME > ~/.dsh」，并注明「只含空白的 $DSH_HOME 视为未设置」。

有三条边界必须照实写，不能淡化：

第一，默认权限档是 workspace-write（apps/cli/reference/README.md:70）。bash 与文件系统写入被限制在会话 workspace 与平台临时目录内，但原文同时写着 reads, network access, and process visibility are not confined——读取、网络访问和进程可见性不在限制范围内。这是一个会在你本机执行工具、跑 shell、起子进程的程序。

第二，--host 0.0.0.0 在仓库里有两种口径。packages/bundle/web-app/src/startup.ts:69-70 的实现是直接报错退出，错误文案原文含 intentionally not supported yet for safety: it would expose remote code execution to the network；apps/cli/reference/README.md:64 与其中文侧 :64 与源码一致。而 .agents/notes/implemented/feature/2026-07-22-web-bind-address.md:15（状态标为 implemented）写的是 CLI 接受 --host 0.0.0.0 作为显式的全网卡模式。两处不一致，位置如上，以我们实读的仓库状态为准。启动器自身能识别的 flag 只有四个（apps/cli/src/args.ts:131-134）：--profile <name>、可重复的 --patch <path>、--dump-config、--dump-default-config；--host、--port、可重复的 --trusted-host 是 Web app 自己的参数（packages/bundle/web-app/src/startup.ts:48-50）。

第三，默认不启用任何 MCP server。apps/cli/reference/README.md:80 写明 CLI 把 @deepseek-ai/dsh-mcp-client 作为依赖随包发出，但不默认启用，理由原文是「每个 server 命令都是 agent 沙箱之外受信任的可执行代码」。

首次使用：官方 guide 给出的步骤顺序

docs/user/guide/index.md 全文只有 30 行，顺序是：启动命令会打印 URL（:5，并注明「a fresh Web UI has no selected workspace until you add one」）；打开 Settings → Models 填入 DeepSeek API key 并保存，:9 说明模型路由「无需重启服务器即刻可用」；:15 点 Choose workspace 把你起 dsh 的项目目录加进去并选中，「在选中 workspace 之前，会话编辑区不可用」；:21 给的示例任务原文是 Summarize this repository and identify its main packages.；:23 说明在当前权限策略下需要批准的操作会先询问。

以上是文档原文的转述——我们没有打开过这个界面，所以界面长什么样、点起来什么感觉、跑得快不快，本文一个字都不写。

最后补一条现实感很强的信息：CONTRIBUTING.md:9 原文写着，项目仍处早期、正在活跃开发，「我们目前无法接受外部 PR」（中文侧 CONTRIBUTING.zh.md:9 同义）。所以你在这两条路上撞见的问题，短期内大概率得自己在本地绕过去。

延伸阅读

本文依据 DeepSeek Harness 官方仓库（github.com/deepseek-ai/deepseek-harness）的 README、docs/ 下的 架构与子系统文档、以及 packages/ 下的源码整理，核对日 2026-08-16，对应仓库快照 47f9438（版本 0.1.0-rc.5）。 本文内容为仓库源码与文档口径，我们没有安装、也没有运行过这个项目， 因此不涉及界面外观、操作手感与运行速度的任何描述。 该仓库建立于 2026-08-13，README 自述处于开发者预览阶段并明确说明未来会有破坏兼容性的变更， 文中出现的命令、配置与默认值随时可能变动，请以仓库最新内容为准。 安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员