在老飞腾 FT-1500A麒麟银河 V10 上安装 DeepSeek Harness（DSH）全记录

兼容适配
1

在老飞腾飞腾 FT-1500A麒麟银河 V10 上安装 DeepSeek Harness（DSH）全记录

一台老旧的飞腾 FT-1500A（ARM64）芯片 + 银河麒麟桌面操作系统 V10，折腾两天，最终通过 Docker 自建镜像成功跑通 DeepSeek Harness。这篇记录把这台"老爷机"上遇到的所有坑、走过的弯路和最终解法整理成文，给同样在国产化平台上折腾的伙伴一个参考。其中 GLIBC 兼容问题和 Docker 部署思路同样适用于 openKylin 的 ARM64 平台。

背景

DeepSeek Harness（简称 dsh）是 DeepSeek 2026 年 8 月发布的开源 AI Agent 开发框架，本质是一个本地命令行工具，核心依赖 Node.js 环境，官方推荐 npx @deepseek-ai/dsh web 启动，然后通过浏览器访问 http://127.0.0.1:3080 使用。

我最初的设想是在华为鸿蒙平板上直接运行它——结果被现实教育了：鸿蒙平板是移动系统，没有完整的 Node.js 工具链，直接运行不可行（鸿蒙生态只能通过小艺 App、Copilot 组件等方式"间接使用"DeepSeek 模型）。

随后我转战 Windows 笔记本，经历了安装 Git、Node.js、pnpm、解决 GitHub 访问、ECOMPROMISED、rm 命令不兼容等一系列小坑之后，DSH 在 Windows 上终于能跑了。但真正的挑战，是在我把目光投向那台久经沙场的飞腾 FT-1500A 麒麟银河 V10 老机器之后才开始的。

一、Windows 上的前奏（简要）

在正式进入麒麟 V10 之前，我在 Windows 笔记本上先踩了一遍基础坑，这些问题后来在 Linux 上以另一种形式重演，值得一提：

问题 原因 解法
npx 不是内部或外部命令 没装 Node.js 安装 Node.js LTS（DSH 要求 ^22.19.0 或 >=24.0.0）
git 不是内部或外部命令 没装 Git 安装 Git，安装时选择 “Use Git from the command line”
git clone 连接重置 / 超时 国内网络访问 GitHub 不稳定 改 hosts、githubproxy.cc 等代理、配置 insteadOf 镜像
npm error ECOMPROMISED Node.js v24 的 npx 已知 Bug 降级 Node.js 到 v22.21.1
'pnpm' 不是内部或外部命令 pnpm 未安装 / PATH 未配置 npm install -g pnpm，然后 pnpm setup

这些坑基本都属于"环境没配好"，一步步解决后，Windows 上 DSH 就能用了。真正的硬仗在麒麟 V10 上。

二、银河麒麟 V10：GLIBC 与 ARM64 的"绝境"

2.1 第一道坎：Node.js 根本装不上

在麒麟 V10 上执行 npx @deepseek-ai/dsh web，提示"未找到 ‘npx’ 命令"。于是开始按常规套路装 Node.js，结果连装都装不上：

① apt 安装直接报依赖错误：

下列软件包有未满足的依赖关系：
 nodejs : 依赖: libc6 (>= 2.28) 但是 2.23-0kord11k20.14 正要被安装

② 换官方二进制包，node -v 直接崩：

node: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)

真相浮出水面：银河麒麟 V10 基于 Ubuntu 18.04 / Debian 10 体系，系统 GLIBC 只有 2.23，而所有较新的 Node.js 预编译包（16/18/20/22）都依赖 GLIBC 2.25+。这是系统级限制，不是换软件源能解决的。

用 lscpu 确认了硬件底牌：

Architecture:          aarch64
CPU(s):                4
Model name:            Phytium,FT-1500A

飞腾 FT-1500A，2015 年前后的 ARMv8 老芯片，4 核 1.5GHz。ARM64 架构 + 老 GLIBC + 老内核（uname -r 显示 4.4.131），三个因素叠加，把官方安装路径全部堵死。

2.2 第二道坎：nvm 的"幽灵"问题

后来通过 NVM 装 Node.js，发现只有 Node.js 16 能正常运行（18 也一样报 GLIBC 错误）。但重启电脑后 nvm 命令又找不到了，排查发现 ~/.bashrc 里加载 nvm 的两行被注释掉了：

export NVM_DIR="$HOME/.nvm"
#[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm

把行首 # 去掉、source ~/.bashrc 后恢复。但这只是小插曲——Node.js 16 能用，可 DSH 要求 Node.js 18+，这仍然是个死结。

2.3 第三道坎：现成 Docker 镜像全军覆没

既然宿主机 GLIBC 太老，想到用 Docker 容器隔离环境（容器自带新版 GLIBC）。但这一步也踩满了坑：

  • 权限问题：Got permission denied while trying to connect to the Docker daemon socket → 需要 sudo usermod -aG docker $USER 把自己加入 docker 组；
  • 架构问题：ghcr.io/huoxue1/deepseek-harness:latest 报 no matching manifest for linux/arm64/v8——这个镜像根本没有 ARM64 版本；
  • 换成 1panel 镜像：能拉下来，但容器启动后 3080 端口无进程监听、日志只有一行 dsh web: http://127.0.0.1:3080 就再无下文，curl 返回空响应（Content-Length: 0），容器内连 ps、netstat、curl 都没有，无从排查；
  • 配置环境变量：先后报 HTTPS_ACCESS_HOST must be an IPv4 address...、DSH_AUTH_USERNAME must contain only letters...，补上 -e HTTPS_ACCESS_HOST=0.0.0.0 -e DSH_AUTH_USERNAME=admin -e DSH_AUTH_PASSWORD=... 后容器才肯启动，但界面依然出不来。

Docker 现成镜像路线，宣告失败。

2.4 Python 替代版的失望

Docker 走不通，又试了社区维护的 Python 版 DSH。结果：

  • 依赖 greenlet 需要源码编译，而系统里是 Python 3.13.6，greenlet 还没有对应的预编译 wheel，g++ 编译报错失败；
  • 即便装上了，Python 替代版功能也不完整，"缩水"明显。

2.5 阶段性结论：放弃本地部署？

两天下来，三条路全灭：

方案 失败原因 结论
Node.js 源码/二进制 16 能跑但 DSH 要 18+；18+ 要 GLIBC 2.28+，系统只有 2.23 :x: 永久不可行
Docker 现成镜像 ARM64 无镜像可用（ghcr 无 arm64 版，1panel 启动后无进程） :x: 暂不可行
Python 替代版 依赖编译失败，且功能缩水 :x: 功能太弱

当时 DeepSeek 自己的建议是"果断停止本地部署，改用 DeepSeek 官网/API"。我也差点接受了——但心里总有一个念头：既然 Docker 容器自带新 GLIBC，为什么不自己构建一个 ARM64 镜像？

三、破局：自建 Docker 镜像，绕开 GLIBC

3.1 第一步：升级 Docker

系统自带的 Docker 是 18.09.7，太老，对现代镜像（多架构、新特性）支持差。而麒麟 V10 不能直接用官方源安装，只能手动装静态二进制包：

# 1. 停止并卸载旧 Docker
sudo systemctl stop docker
sudo yum remove -y docker docker-client docker-common docker-engine docker-runc ...

# 2. 下载 aarch64 静态包（注意选对架构）
wget https://download.docker.com/linux/static/stable/aarch64/docker-24.0.9.tgz

# 3. 解压并复制到系统路径
sudo tar -xzvf docker-24.0.9.tgz -C /usr/local/
sudo cp /usr/local/docker/* /usr/bin/    # 注意：解压后没有 bin 子目录，文件直接在 docker/ 下

# 4. 创建 systemd 服务
sudo tee /etc/systemd/system/docker.service > /dev/null <<'EOF'
[Unit]
Description=Docker Application Container Engine
After=network-online.target firewalld.service
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock --selinux-enabled=false --default-ulimit nofile=65536:65536
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
TimeoutStartSec=0
Delegate=yes
KillMode=process
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target
EOF

# 5. 启动并验证
sudo systemctl daemon-reload
sudo systemctl start docker
sudo systemctl enable docker
docker --version

踩坑提醒：复制二进制时如果报 cp: 无法创建普通文件'/usr/bin/containerd': 文本文件忙，是因为旧 Docker 进程还在运行，先 sudo pkill -9 dockerd containerd docker-proxy 再复制。

验证升级成功：

docker run --rm hello-world
Hello from Docker!

同时把用户加入 docker 组（免 sudo）：sudo usermod -aG docker $USER，并配置国内镜像加速器（/etc/docker/daemon.json 里加 registry-mirrors）。

3.2 第二步：编写 Dockerfile

核心思路：基础镜像自带新 GLIBC。这里用 node:24-slim（Debian 系，自带新版 GLIBC，远高于宿主机 GLIBC 2.23），在容器内完成 DSH 的安装构建，宿主机 GLIBC 老不老完全无所谓。

由于宿主机直连 GitHub 经常超时，改成先在宿主机用国内镜像把源码 clone 下来，再 COPY 进镜像，避免构建时联网拉 GitHub：

cd ~/dsh-docker
git clone https://gitclone.com/github.com/deepseek-ai/deepseek-harness.git

目录结构：

~/dsh-docker/
├── Dockerfile
└── deepseek-harness/          # 克隆下来的源码

Dockerfile 内容：

# 使用 Debian 系 slim 基础镜像，自带新版 GLIBC，绕过宿主机 GLIBC 2.23 的限制
# 直接用 node:24 —— 满足 DSH 官方要求的 Node.js ^22.19.0 / >=24.0.0
FROM --platform=linux/arm64 node:24-slim

# 设置环境变量，解决 pnpm 和 dsh 的路径问题
ENV DSH_HOME=/data/dsh \
    DSH_WORKSPACE=/workspace \
    DSH_PORT=3080 \
    DSH_HOST=0.0.0.0 \
    PNPM_HOME=/root/.local/share/pnpm \
    PATH=/root/.local/share/pnpm:$PATH

# 创建工作目录
RUN mkdir -p $DSH_HOME $DSH_WORKSPACE

# 更换为阿里云的 Debian 镜像源，加速国内下载
RUN sed -i 's/deb.debian.org/mirrors.aliyun.com/g' /etc/apt/sources.list.d/debian.sources 2>/dev/null || \
    sed -i 's/deb.debian.org/mirrors.aliyun.com/g' /etc/apt/sources.list

# 安装编译依赖（Node.js 原生模块可能需要）
RUN apt-get update && apt-get install -y \
    git \
    python3 \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

# 全局安装 pnpm（node:24 满足最新 pnpm 的要求，无需降级，见下文 3.3）
RUN npm install -g pnpm

# 复制本地源码到镜像内（避免构建时直连 GitHub）
COPY deepseek-harness /app

# 设置工作目录
WORKDIR /app

# 安装依赖并构建
RUN pnpm install && pnpm run build

# 暴露端口
EXPOSE $DSH_PORT

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD node -e "require('http').get('http://localhost:'+process.env.DSH_PORT+'/',(r)=>{process.exit(r.statusCode===200?0:1)}).on('error',()=>process.exit(1))" || exit 1

# 启动 DeepSeek Harness Web 服务（注意：不能加 --host 0.0.0.0，见下文 3.4）
CMD ["pnpm", "dsh", "web", "--port", "3080"]

3.3 pnpm 版本陷阱：换用 Node.js v24

构建时卡在 pnpm install：

ERROR: This version of pnpm requires at least Node.js v22.13
The current version of Node.js is v18.20.8

pnpm v11 及以上要求 Node.js 22+，而当时基础镜像用的是 node:18——这是我犯的一个惯性错误：在宿主机上我只能跑 Node 16/18，就把这个"版本天花板"思维带进了容器。其实容器内自带新版 GLIBC，根本不受宿主机限制，完全可以直接用更新的 Node.js v24，它恰好满足 DSH 官方要求的 ^22.19.0 或 >=24.0.0，最新的 pnpm 也一并解决，无需降级：

FROM --platform=linux/arm64 node:24-slim
...
RUN npm install -g pnpm

3.4 安全限制：–host 0.0.0.0 被禁止

构建成功后启动容器，日志报错：

error: --host 0.0.0.0 is intentionally not supported yet for safety: it would expose remote code execution to the network; use 127.0.0.1 instead

DSH 出于安全考虑，强制禁止监听 0.0.0.0（担心把"远程代码执行"能力暴露到网络）。所以 Dockerfile 里 CMD 不能带 --host 0.0.0.0，让服务默认监听 127.0.0.1 即可。

3.5 关键谜题：容器内 200，宿主机却被重置

重新构建、启动容器后：

  • 容器内测试：docker exec dsh node -e "require('http').get(...)" → Status: 200，HTML 正常返回，服务明明活着；
  • 宿主机测试：curl -v http://127.0.0.1:3080 → Recv failure: 连接被对方重设。

原因：服务监听的是容器内部的 127.0.0.1，而 -p 3080:3080 端口映射下，宿主机发起的连接在 Docker 网络层被视为"外部"连接，服务直接拒绝。docker exec 之所以能通，是因为它在容器内、共享同一个 loopback。

解法：改用 --net=host 让容器共享宿主机网络栈——容器内的 127.0.0.1 就等于宿主机的 127.0.0.1：

docker stop dsh && docker rm dsh

docker run -d --name dsh \
  --net=host \
  -v dsh-data:/data/dsh \
  -v dsh-workspace:/workspace \
  deepseek-harness:arm64

浏览器打开 http://127.0.0.1:3080——DeepSeek Harness 的界面终于出来了！

四、成功之后的收尾配置

4.1 配置 API Key

首次使用需要在界面里填入 DeepSeek API Key（在 platform.deepseek.com 创建，sk- 开头，只在创建时显示一次），并选择工作区（容器内 /workspace）。

4.2 安全审批机制

第一次让 Agent 干活时，界面弹出"等待审批"的提示——这是 DSH 的安全机制在起作用：容器内没有 bubblewrap 等沙盒后端，workspace-write 模式不可用，Agent 请求降级为 danger-full-access，需要手动点"批准"。如果不想每次都审批，可以在设置里把默认沙盒模式改为 danger-full-access（仅限可信环境）。

4.3 挂载宿主目录作为工作区

--net=host 模式下，用 -v 把宿主机的真实目录挂进去当工作区，方便 Agent 直接操作宿主机文件：

docker run -d --name dsh \
  --net=host \
  --user 1000:1000 \
  -v dsh-data:/data/dsh \
  -v ~/dshworkspace:/workspace \
  deepseek-harness:arm64

配套的权限调整（容器内以 UID 1000 运行，宿主机目录也要给对应权限）：

id                                  # 查看宿主用户 UID/GID，例如 1000:1000
sudo chown -R 1000:1000 ~/dshworkspace
sudo chmod -R 755 ~/dshworkspace

注意：如果 dsh-data 卷之前是 root 创建的，改用 --user 后可能没权限，需要 sudo chown -R 1000:1000 /var/lib/docker/volumes/dsh-data/_data 或干脆删卷重建。

五、最终方案速查

给同样环境（飞腾 ARM64 + 麒麟 V10 + 老 GLIBC）的后来者，直接抄作业：

# 1. 升级 Docker（老版本 18.09 必须换）
wget https://download.docker.com/linux/static/stable/aarch64/docker-24.0.9.tgz
sudo tar -xzvf docker-24.0.9.tgz -C /usr/local/
sudo cp /usr/local/docker/* /usr/bin/
# 配置 systemd 服务、加入 docker 组、配置镜像加速器（见上文 3.1）

# 2. 宿主机用国内镜像克隆源码
cd ~/dsh-docker
git clone https://gitclone.com/github.com/deepseek-ai/deepseek-harness.git

# 3. 编写 Dockerfile（见上文 3.2，关键点：node:24-slim 基础镜像 + 去掉 --host）
#    并构建
docker build -t deepseek-harness:arm64 .

# 4. 用 --net=host 运行（不能用 -p 端口映射！）
docker run -d --name dsh \
  --net=host \
  -v dsh-data:/data/dsh \
  -v ~/dshworkspace:/workspace \
  deepseek-harness:arm64

# 5. 浏览器访问
# http://127.0.0.1:3080

日常管理命令：

docker logs dsh          # 看日志
docker stop dsh          # 停止
docker start dsh         # 重启
docker rm dsh            # 删除（先停止）

六、经验与教训

  1. 老国产平台的核心矛盾是 GLIBC，不是软件本身。 银河麒麟 V10 的 GLIBC 2.23 就像一道天花板，所有"为现代发行版编译"的二进制（Node.js 18+、各类原生模块）都进不来。遇到 GLIBC_2.27 not found 这类报错，别再折腾换源、换版本了，直接想隔离方案。

  2. Docker 是绕开 GLIBC 的最优解，但"现成镜像"基本别指望。 ARM64 在老平台上是"二等公民"，社区镜像要么没有 arm64 版（no matching manifest），要么有但内部依赖依然不兼容。自己构建镜像（node:24-slim 这类自带新 GLIBC 的基础镜像）才是正道。

  3. 永远不要尝试直接升级系统的 GLIBC。 那是 Linux 的基石，强升会导致 bash、ls 全部崩溃，系统直接"变砖"。

  4. DSH 的 --host 0.0.0.0 是安全红线。 官方明确禁止监听全网卡（防止远程代码执行暴露），容器场景要用 --net=host 来绕开端口映射的 loopback 问题，而不是试图绑定 0.0.0.0。

  5. 容器内工具极度精简。 ps、netstat、curl、wget 可能都不存在，排查要用 node -e 或 /proc 文件系统，或者干脆在宿主机侧测试。

  6. 国产平台踩坑是常态，但坚持有回报。 两天时间、三条死路，最后一条"自己动手构建镜像"的路线走通了。这个过程排除了所有不可行的选项，本身就是价值。

如果你也在飞腾/鲲鹏/龙芯等国产芯片 + 麒麟/统信系统上折腾 DeepSeek Harness，希望这篇记录能帮你少走两天弯路。

1 个赞