在阿里云 ECS 上给 DeepSeek Harness（DSH）接一个知识库，卡住人的往往不是插件本身，而是版本门槛、构建许可、磁盘落点和导入上限这四件事。下面按云上部署顺序走一遍：规划实例与磁盘、收紧安全组、装环境与插件，最后逐条拆开四个坑。插件为 Soren-ABT/dsh-knowledge（知识库检索），当前发布版 v0.4.1，许可 AGPL-3.0，综合分 53.2，星标 57，周下载 749；本站已在 1 天前于 dsh 0.2.0-rc.2 下真实安装成功（L4 · 真实安装）。
一、实例规格与磁盘规划
知识库是磁盘密集型，选型时把预算放在存储上更划算。
- 实例：2 vCPU / 4 GiB 内存即可跑通插件本体；若要在实例内跑本地 embedding 与 OCR，内存建议 8 GiB 以上，给 ONNX 推理留余量。
- 系统盘：默认 40 GB 偏紧。除 Node 运行时、pnpm store 和 DSH 外，默认 embedding 模型约 585 MB（1024 维）、扫描件 OCR 模型另需约 21 MB，再加上分块的独立 SQLite 文件与原始文件的 raw 存储，系统盘很快见底。建议系统盘 80 GB 以上，或把模型与数据都落到数据盘。
- 数据盘：挂一块 ESSD 云盘承载业务数据：
fstab 里的 nofail 不能省，否则云盘挂载顺序变化时实例可能卡在紧急模式。
二、安全组与访问路径
DSH 的 web 服务与管理面板不需要对全网开放。安全组只放行必要来源，管理端口（例如 8787）建议仅允许办公出口 IP 或跳板机，而不是 0.0.0.0/0；SSH 的 22 端口同理收窄。实例只买了内网时，把浏览器访问放到同 VPC 的另一台机器上走内网地址；必须从公网临时访问时，用 SSH 端口转发比直接开公网端口稳妥：
隧道建好后在本机浏览器打开 127.0.0.1:8787，安全组无需新增入方向规则。装完插件后记得重启 web 服务并刷新页面，否则侧边栏不会出现「知识库」入口。
三、版本门槛与许可
运行要求写得很硬：Node.js ^22.19.0 || >=24.0.0、pnpm >=10，且已安装并初始化 DSH；页头徽章也标着 Node.js = 22。动手前先核对：
许可方面，本插件采用 AGPL-3.0，后续若二次分发或在闭源产品里集成，需要先做合规评估。安装走站点生成的规范命令，插件装在 profile 层：
四、四个必须提前知道的坑
坑一 · Node 版本是硬门槛。 现象。 沿用了发行版自带的旧 Node，会出现装不上或装完行为异常。原因。 README 要求 Node.js ^22.19.0 || >=24.0.0，开发要求 >=22.19.0，^22.19.0 意味着 22.x 系列里也不能低于 22.19.0。解决。 先把 Node 升到 22.19 以上（或直接用 24 系列），再执行安装。
坑二 · pnpm 拒绝安装期构建，add 在登记 bundle 前退出。 现象。 第一次执行 dsh plugin add 直接失败，看着像插件包损坏。原因。 插件依赖含安装期构建的包（esbuild、onnxruntime-node、protobufjs、sharp、tesseract.js），pnpm 10 默认拒绝执行这些脚本，命令就在登记 bundle 之前退出了。解决。 把 README 给的构建许可合并进目标 profile 里已存在的 pnpm-workspace.yaml：
不要重复添加第二个 allowBuilds: 键，否则 YAML 会失效。 补全后重跑同一条 add：首次失败时包通常已进入 node_modules，第二次执行会继续完成 bundle 登记。
坑三 · 本地模型占磁盘，且默认落在 DSH 缓存目录。 现象。 插件装好、库里也有数据，回头一看系统盘少了几百 MB。原因。 默认 embedding 模型 onnx-community/Qwen3-Embedding-0.6B-ONNX 约 585 MB、1024 维，OCR 模型另需约 21 MB，而本地模型默认缓存在 <cache>/dsh-knowledge/local-models，正好压在系统盘上。解决。 用管理界面的「模型缓存目录」（支持原生文件夹选择、打开目录和安全迁移）把权重移出系统盘，落到数据盘。顺带一提，不下载模型也可以使用关键词检索。
坑四 · 批量导入有单次与单体两道上限。 现象。 一次拖一大批文件进去，只进来一部分。原因。 批量上传单次最多 20 个文件、单文件最大 22 MB，底层使用 5 路后台导入池，超出的部分不会被受理。解决。 分批导入；单个超大文件先拆分或压缩。另注意同名冲突由服务端统一检测（可选重命名、替换或取消），也有内容哈希避免重复导入；即便替换重建失败，也不会破坏上一份已提交内容。
总结
在阿里云 ECS 上部署 dsh-knowledge，落点其实是四件事：把 Node 提到 22.19 以上、把 allowBuilds 合并进 profile 的 pnpm 配置、把模型缓存与数据盘规划好、避开导入的 20 文件与 22 MB 上限；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：已有阿里云 ECS 并希望把知识库与业务放在同一 VPC 的团队；需要在实例内完全本地化跑 embedding、OCR、rerank 而不外发数据的场景；已经用过 DSH、熟悉 profile 与 pnpm 工作流的开发者。不适合：Node 仍停留在 22.19 以下且短期无法升级的环境；不接受 AGPL-3.0 许可约束、计划闭源集成或二次分发的项目；只想上传几个小文件做关键词查询、并不需要向量与 OCR 的轻量用户。
标签：dsh-knowledge、DeepSeek Harness、阿里云 ECS、知识库检索、云上部署
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
