DeepSeek Harness 装到 ARM 设备：树莓派与 DSH plugin 原生依赖的安装取舍

在 ARM 设备上装 DeepSeek Harness，成败不在「能不能装」，而在「你选哪条路」。 树莓派、ARM 服务器、苹果芯片三种 arm64 环境的可用面并不一样：CLI 路线基本都能走（它本质是 Node 工具），桌面端通常只有苹果芯片有官方包，而真正卡人的是 DSH plugin 的原生依赖——带原生模块的插件如果没有 arm64 预编译产物，就得在树莓派这类低配设备上从源码编译，慢且容易 OOM。所以 ARM 上的正确姿势是先分路（本机 CLI / 容器统一架构 / 远程跑本机当客户端），再决定装哪些插件。

ARM 上装 DeepSeek Harness：三条路线与前置确认

一句话结论：ARM 上装 DeepSeek Harness 只看三个指标——Node 版本达标、内存够装依赖、以及目标插件有没有 arm64 产物；三者任一不满足，先换路线再动手。

1. Node 版本：node -v 看是否达到官方支持的下限（以 apps/cli/README.md 与 npm 包页的 engines 说明为准）。
2. 内存与磁盘：装依赖时峰值内存最容易出事；小于 4G 内存的设备先把 swap 开起来。
3. 插件产物：想装的 DSH plugin 是否提供 arm64 预编译产物——去 DSH Plugin Hub 看该插件的依赖说明，比装到一半失败再回退快得多。

方案 A：ARM 上直接装 CLI（最直接）

一句话结论：只要 Node 版本达标、插件不依赖缺 arm64 产物的原生模块，直接用 CLI 就是最省心的路——没有容器层、没有模拟损耗。

1. 装 Node（走发行版包管理器或 nvm 皆可），然后验证架构：

uname -m        # 预期：aarch64 或 arm64
node -v && npm -v

2. 全局安装本体：

npm i -g @deepseek-ai/dsh
dsh --version

3. 固定数据目录（低配设备上放内置存储，别放 SD 卡上的慢速分区）：

export DSH_HOME="$HOME/.dsh"
mkdir -p "$DSH_HOME"

4. 一条条装插件，别一次装一整套：dsh plugin add <包名> 逐个装、逐个验证，既省内存峰值，也方便定位是哪一个插件不兼容。
5. 要网页端就起 dsh web，注意用 dsh web --help 核对参数名，低配设备上建议限制并发会话数。

方案 B：用容器统一架构差异（树莓派最推荐）

一句话结论：容器把「架构差异」这件事从「每次装插件都可能失败」变成「构建镜像时一次性解决」——树莓派这种反复装卸的场景收益最大。

1. 用与目标架构一致的基座构建（arm64 上就用 arm64 的 Node 镜像，避免模拟）：

docker build --platform linux/arm64 -t dsh-arm:0.2.0-rc.2 .

2. 把重活放在构建阶段：插件在镜像里预装（编译一次、复用多次），运行阶段就只剩启动——低配设备最怕的「运行时编译」被消掉了。
3. 数据与工作区都挂卷，容器删了状态还在（卷的取舍见 DeepSeek Harness 容器化安装）。
4. 确实需要 x86 产物时才用模拟层（例如 --platform linux/amd64 在 arm64 上跑），但要知道代价：CPU 密集型任务会明显变慢，内存占用上升，小内存设备上容易 OOM。

方案 C：远程跑、本机只做客户端（降级但常常最实用）

一句话结论：如果 ARM 设备是低配板子（内存 < 4G 或存储慢），把 DeepSeek Harness 跑在一台 x86 服务器或开发机上，用 ARM 设备通过浏览器当客户端访问——这样你既用上了 ARM 设备的便携，又不受它的性能限制。

1. 服务端：在服务器上装好 DeepSeek Harness 并起 dsh web，让它监听可被内网访问的地址。
2. 客户端：ARM 设备上只用浏览器访问该地址，不装任何东西——省掉了这台机器几乎所有依赖坑。
3. 打通网络两条路：同一局域网直接访问（见 局域网访问 dsh web），或走反向代理 + HTTPS（见 给 dsh web 配反向代理与 HTTPS）。
4. 代价说清：会话与服务端同机，ARM 设备只是显示层——断网就没法用，且不能操作本机文件（要操作本机文件才需要方案 A/B）。

DSH plugin 原生依赖在 ARM 上的三种处理

一句话结论：遇到 arm64 缺产物，按「先换插件、再补工具链、最后跨架构跑」的顺序试——换插件的成本最低，跨架构跑的代价最高。

1. 换插件（首选）：同一需求常有多份实现，挑纯 JS 或已提供 arm64 产物的那份。用 Hub 按场景找候选，比在 npm 上盲搜包名效率高。
2. 补工具链后从源码编译：sudo apt-get install -y build-essential python3，然后重装该插件。注意代价：树莓派上编译原生模块可能耗时很久，且中途 OOM 会留下半成品——先把 swap 开起来。

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
free -h      # 预期：Swap 一行显示新容量

3. 跨架构承载：把需要 x86 的那部分放到另一台机器或容器里，本机只保留不依赖原生模块的插件。
4. 装完必验：dsh plugin 列出清单 + 实际调用一次该插件的功能，别只看「装上了」——ARM 上典型的失败是「装上了但运行时报架构不匹配」。

低配 ARM 设备上跑 DeepSeek Harness 的运行取舍

一句话结论：低配 ARM 上要做减法——减并发、减插件、减长会话；把「能跑」优先于「功能齐全」。

1. 减并发：同时开的会话、子代理、后台任务越少越好；重活交给远端。
2. 减插件：只留与你场景最相关的几个，其余卸载；插件越多，启动期的加载与索引开销越大。
3. 减长会话：超长会话的内存与渲染开销在低配设备上感受最明显，必要时拆会话或压缩上下文。
4. 看资源用哪个工具：free -h 看内存、top 看单个进程占用，先定位是内存瓶颈还是 CPU 瓶颈，再决定减哪一项。

DSH插件 ARM 排查注意事项

一句话结论：ARM 上的失败九成落在「架构/依赖」而不是「配置」——先看错误里有没有架构或编译字样，再决定走哪条处理路径。

1. 报架构不匹配（incompatible architecture、wrong ELF class 一类）→ 走原生依赖三处理里的「换插件 / 跨架构」。
2. 报编译失败→ 补工具链、开 swap，或直接放弃从源码编译这条路。
3. 进程被杀→ OOM，按「开 swap + 分批装 + 减插件」处理。
4. 装得上但运行报错→ 优先怀疑 Node 与 npm 是 x64 翻译版本，换成 arm64 原生版本。
5. 运行很慢→ 先分清是 CPU 还是内存瓶颈，再选减法项（并发 / 插件 / 会话长度）。
6. 修复状态如实：桌面端在 Linux arm64 上通常无官方包，只有 CLI 可用；苹果芯片有官方桌面端。以上判断基于官方仓库与 npm 包页的公开信息，具体支持面随版本变化，装之前以官方 README 为准。

来源：apps/cli/README.md、apps/desktop/README.zh.md、npm @deepseek-ai/dsh。