DeepSeek Harness + IM 机器人部署实战：Windows 下踩坑与工作区配置
最近折腾了一下 DeepSeek Harness（DSH）+ IM 机器人。
先展示一下最终的效果
最开始的想法很简单：
在 Windows 本机部署 DeepSeek Harness，然后接入 IM 机器人，这样即使不打开 Web 页面，也可以直接通过 IM 和 AI 进行交互。
但真正部署之后，发现还是有一些坑。
尤其是 Windows 服务运行方式 和 IM 机器人工作区（Workspace）配置，花了一些时间才理顺。
下面记录一下整个实践过程。
一、为什么选择本地部署 DSH？
之前尝试过在服务器上部署 DeepSeek Harness。
但是实际运行之后发现，DSH 对服务器资源还是比较敏感。
我的服务器配置比较有限，运行 DSH 后资源占用比较明显。
所以后来决定：
直接把 DeepSeek Harness 部署到 Windows 本机。
这样做还有一个好处：
DSH 可以直接访问本机的代码仓库、项目目录以及各种开发工具。
对于一个主要用于辅助编程的 AI Agent 来说，本地运行其实更加方便。
二、最开始尝试使用 Windows 服务
一开始，我希望 DSH 能够像普通 Windows 服务一样：
Windows 启动 → DSH 自动启动 → IM 机器人自动连接。
所以最开始使用了 NSSM，将 DSH 包装成 Windows 服务。
这种方式理论上没有什么问题。
但是实际使用过程中发现，DSH 的运行环境比较复杂。
尤其涉及：
Node.js
pnpm
Corepack
DSH Profile
Plugin
Workspace
Web Runtime
IM Plugin
这些东西组合在一起之后，Windows Service 和直接在终端运行还是存在一些差异。
实际运行过程中出现了一些插件加载、运行环境以及 Web 功能方面的问题。
因此后来我决定：
不再使用 NSSM。
而是直接使用 npm 全局安装 DSH。
三、最终采用 npm 全局安装
最终我的安装方式非常简单：
npm install -g @deepseek-ai/dsh安装完成之后，可以直接使用：
dsh或者查看版本：
dsh --version我当前使用的是 npm 全局安装方式。
通过下面的命令可以查看 npm 全局安装目录：
npm config get prefix我的环境返回：
C:\nvm4w\nodejs再通过：
npm root -g可以看到全局 Node.js 模块目录：
C:\nvm4w\nodejs\node_modules查看当前安装的全局 npm 包：
npm list -g --depth=0可以看到：
@deepseek-ai/dsh已经安装成功。
这里有一个容易误解的地方。
虽然 DSH 是通过 npm 全局安装的，但 DSH 自己的 Profile、插件以及运行数据，并不一定都放在 npm 的 global node_modules 目录里面。
例如我的 Web Profile：
C:\Users\Administrator\.dsh\profiles\web四、安装 DSH IM 插件
接下来就是整个实践中比较关键的一步：
让 DSH 接入 IM。
我使用的是：
@xmanrui/dsh-im安装之后，可以通过：
dsh plugin --profile web list查看插件。
我的环境中可以看到：
dsh-profile-web C:\Users\Administrator\.dsh\profiles\web (PRIVATE)
│
│ dependencies:
└── @xmanrui/dsh-im@2.0.1说明 IM 插件已经安装到了 Web Profile 中。
插件实际目录：
C:\Users\Administrator\.dsh\profiles\web\node_modules\@xmanrui\dsh-im里面可以看到：
assets
bin
lib
plugin-src
scripts
src
cordis.patch.yml
package.json
README.md这也说明：
IM 并不是一个独立运行的 AI 服务，而是作为 DSH Plugin 接入 DSH。
五、这里又遇到了一个问题：IM 无法选择 Workspace
插件正常运行之后，我遇到了一个比较奇怪的问题。
在 DSH Web 前端中，可以看到 Workspace 相关功能。
但是通过 IM 机器人使用的时候，却无法像 Web 前端一样直接选择 Workspace。
这也是我一开始比较困惑的地方。
因为对于 AI 编程来说，Workspace 实际上非常重要。
例如：
D:\Projects\MyProject如果 Workspace 没有设置正确，那么 AI Agent 就可能无法在我们希望的项目目录下工作。
六、开始分析 dsh-im 插件
于是我直接查看了：
C:\Users\Administrator\.dsh\profiles\web\node_modules\@xmanrui\dsh-im尤其是：
lib\client.js通过搜索：
workspace
cwd
workDir
workingDirectory
session发现这个插件实际上已经包含了大量 Workspace 相关逻辑。
例如可以看到：
WorkspaceDirector以及：
setWorkspace同时还存在：
/workspace
/session
/sessionlist等相关命令。
这时候基本可以确定：
IM 插件本身是支持 Workspace 的。
只是它和 DSH Web 前端的 Workspace 操作方式并不完全一样。
七、最终发现：IM 可以直接使用 /workspace
继续查看 IM 插件的命令之后，发现了一个非常关键的功能：
/workspace也就是说，IM 并不需要依赖 Web 前端来选择 Workspace。
可以直接在 IM 对话中使用：
/workspace然后按照机器人提示设置工作区。
最终我直接通过 IM：
/workspace完成了 Workspace 修改。
修改成功之后，后续通过 IM 发送给 AI 的消息，就会使用新的 Workspace。
八、这个问题其实让我重新理解了 DSH 的 Workspace
一开始我的理解是：
Workspace 是 Web 前端里的一个功能。
后来实际使用之后发现并不是这样。
Workspace 更像是：
DSH Agent 当前工作的项目目录。
Web 前端只是提供了一套图形化操作方式。
而 IM 插件则提供了另一套操作方式。
所以：
Web 前端不能选择 Workspace，并不代表 IM 不支持 Workspace。
实际上通过 IM 命令一样可以完成。
这也是这次实践中比较容易踩的一个坑。
九、最终的使用方式
目前我的使用方式已经比较明确。
整体结构大概是：
Windows
│
├─ Node.js
│
├─ npm
│ └─ @deepseek-ai/dsh
│
├─ DSH
│ └─ Web Profile
│ └─ @xmanrui/dsh-im
│
└─ IM 机器人
│
▼
DeepSeek Harness
│
▼
Workspace
│
▼
本地项目代码DSH 直接运行在 Windows 环境中。
IM 机器人负责提供一个远程聊天入口。
而 Workspace 则负责确定 AI 实际工作的项目目录。
十、目前我的最终方案
经过前面的折腾，目前我采用的是：
1. Windows 本机运行 DSH
使用：
npm install -g @deepseek-ai/dsh2. 不再使用 NSSM
因为目前来看，直接运行 DSH 更容易排查问题。
3. 使用 Web Profile
插件安装在：
C:\Users\Administrator\.dsh\profiles\web4. 安装 dsh-im
使用：
dsh plugin --profile web add -w @xmanrui/dsh-im5. 通过 IM 使用 DSH
不需要一直打开 DSH Web 前端。
6. 通过 /workspace 修改工作目录
例如在 IM 中执行：
/workspace按照提示设置项目目录即可。
十一、实践过程中几个比较重要的结论
这次部署过程中，我觉得有几个点值得记录下来。
1. Windows 服务不一定是最优方案
一开始觉得把 DSH 做成 Windows 服务，可以实现开机自启动。
但实际使用之后发现：
对于这种依赖 Node.js、Plugin、Profile 和运行时环境的开发工具，直接运行反而更加容易排查问题。
所以目前我选择放弃 NSSM。
2. npm 全局安装并不意味着所有东西都放在 C 盘
DSH 的 npm 包确实安装在 npm global prefix：
C:\nvm4w\nodejs但是 DSH 的用户数据、Profile、插件等则在：
C:\Users\Administrator\.dsh因此如果后续需要调整磁盘空间，实际上要分别考虑：
Node.js/npm 全局目录
以及：
DSH Profile 目录
这两个并不是完全相同的东西。
3. IM 和 Web 前端的功能并不完全一样
这是这次最容易误判的地方。
Web 前端无法正常选择 Workspace，并不代表 DSH 本身无法设置 Workspace。
IM 插件提供了自己的命令：
/workspace最终我就是通过这个命令解决问题的。
十二、后续还可以继续折腾什么？
目前 DSH + IM 已经基本跑通了。
接下来其实还有很多值得研究的东西，例如：
如何让 IM 默认使用指定 Workspace
如何让不同 IM 用户使用不同 Workspace
如何管理多个 Workspace
如何管理不同 Session
如何让不同项目对应不同 AI Agent
如何让 DSH 开机自动启动，但又不使用 NSSM
如何优化 DSH Profile 的存储位置
如何配置更多 IM 平台
如何让 IM 机器人更适合日常编程使用
尤其是：
如果每次都需要手动执行
/workspace，其实还是有一点麻烦。
如果能够做到：
用户 A → 项目 A
用户 B → 项目 B
群聊 A → 项目 C那么 IM 就真正可以变成一个远程 AI 编程入口了。
实践截图
下面预留一些截图位置，方便后续补充实际部署过程。
① npm 安装 DSH
【实践截图：npm install -g @deepseek-ai/dsh】
② 安装 DHS-IM
【实践截图：dsh plugin --profile web add -w @xmanrui/dsh-im】
③ IM 机器人使用 /workspace & 修改 Workspace 成功
【实践截图：IM 中执行 /workspace】
总结
这次从服务器部署、Windows 本地部署，到尝试 NSSM，再到最终使用 npm 全局安装 DSH，实际上踩了不少坑。
但最终发现，最简单的方案反而是：
Windows + Node.js + npm + DSH + dsh-im。
而 Workspace 也不一定非要依赖 Web 前端。
如果 Web 前端无法选择 Workspace，可以直接尝试：
/workspace对于我来说，真正解决问题的关键就是这一点：
不要把 IM 当成 Web 前端的一个“聊天窗口”，它其实有自己的一套 DSH 操作命令。
目前这套方案已经可以正常通过 IM 连接 DSH，并且通过 /workspace 指定本地项目目录。
后面如果继续研究出更方便的 默认 Workspace、多项目 Workspace、Session 管理以及开机自动启动方案，再继续记录。