简要结论
最短的启动路径是运行官方 npm 启动命令、打开本地 Web UI、确认模型提供商已经配置，再创建一个可丢弃的首次工作区。项目仍处于 Developer Preview，第一次运行应记录版本，并避免直接使用包含敏感信息的生产仓库。
这条路径使用官方发布到 npm 的包，不需要先克隆源码。
1. 检查 Node.js
打开终端执行：
node --version如果命令不存在，先从 Node.js 官方渠道安装受支持的稳定版本。不要从来历不明的下载站获取安装包。
2. 启动 Web UI
在准备作为工作区的项目目录中执行：
npx @deepseek-ai/dsh web官方 README 记录的默认地址是：
http://127.0.0.1:3080终端进程需要保持运行。浏览器无法访问时，先检查终端中是否有端口冲突、安装错误或权限提示。
3. 配置模型
进入 Web UI 后，打开 Settings → Models，填写模型 Provider 需要的 API Key 并保存。官方指南说明，保存后模型路由可以直接使用，无需重启服务。
不要把真实 API Key：
- 发到聊天记录里；
- 写入会被 Git 提交的文件；
- 放入截图或教程示例；
- 提交到公开 Issue。
4. 选择工作区
点击 Choose workspace，添加并选择你启动 dsh 时所在的项目目录。未选择工作区时，会话编辑区可能保持不可用。
第一次尝试建议使用一个没有敏感文件的测试项目。
5. 运行第一项任务
创建会话并发送：
总结这个仓库，并指出最主要的目录和包。先只读，不要修改文件。这条请求容易验证，也能让你观察工作区读取、计划和工具审批的基本流程。
6. 把请求写成可验收任务
第一次任务不要只写“看看这个项目”。使用四段式任务契约：
目标：说明仓库用途和主要入口。
范围：只读取 README、package.json 与 src 顶层目录。
约束：不修改文件，不安装依赖，不访问网络。
交付：用表格列出目录、职责和证据文件；最后说明未确认事项。明确范围可以减少无意义的上下文，硬约束则让审批更容易判断。交付格式提供了验收标准。
7. 观察一次完整循环
不要只看最终回答，至少观察一次工具链：
- 模型是否先读取允许范围内的文件？
- 工具参数是否指向正确工作区？
- 是否出现超出目标的命令或网络请求？
- 工具结果是否被下一步引用？
- 最终结论能否对应到具体文件？
如果 Harness 请求写权限，而你的任务声明为只读，先拒绝并让 Agent 解释原因。不要为了完成教程而无条件批准。
常见失败分支
| 现象 | 先检查 | 下一步 |
|---|---|---|
npx 找不到命令 | Node/npm 是否安装 | 使用官方 Node.js 发行渠道修复运行时 |
| 页面无法打开 | 终端是否仍运行、实际监听地址 | 处理端口冲突后重启 |
| 编辑器不可用 | 是否选择工作区 | 添加并激活测试目录 |
| 请求立即报认证错误 | Provider、模型 ID、凭据 | 转到下一章逐层验证 |
| Agent 看不到文件 | 工作区路径和沙箱 | 用只读文件列举命令验证边界 |
清理与回滚
结束练习后停止终端进程。若测试目录产生了修改，先查看差异，再决定保留或恢复；不要用会覆盖整个工作区的命令处理一两个文件。
成功标准
- Web UI 能打开。
- 模型配置保存成功。
- 已选中工作区。
- 会话能够返回仓库摘要。
- 整个过程中没有提交 API Key。
下一步阅读配置模型 Provider。