简介：一套 U-Claw 虾盘离线安装方案，面向 OpenClaw 用户，适合希望在任何电脑上快速启动 AI 助手、又受网络与安装环境限制的开发者和爱好者，也适合在无外网、内网隔离或网络不稳定场景中完成部署。资源内含完整制作教程与源代码，通过 setup.sh 补齐依赖后，即可将 portable/ 目录复刻到 U 盘，实现插上即用、双击运行。压缩包共 110 个文件、20.58MB，其中以 30 个 md 教程文档、16 个 html 页面、sh/ps1/bat 等多平台安装脚本、json/js 配置与辅助代码为主，另含少量可执行文件、图片和图标，整体目录骨架清晰，方便按模块查找。目前已有 792 人参与学习。对于需要远程维护、定制开发或企业私有化部署 OpenClaw 的用户，这份资源提供了从文件结构到启动脚本的全套可复用材料，可帮助快速搭建便携 AI 环境并理解跨平台打包思路。
1. U-Claw 虾盘到底装了什么：一份能在 Mac / Windows / Linux 上双击安装的 OpenClaw 离线包
U-Claw 虾盘说白了，就是一块把 OpenClaw 离线安装包、三平台安装脚本和国内镜像配置一次性烧进去的 U 盘。插到任何一台 Mac / Windows / Linux 上，双击盘里的安装器，十几分钟内就能把 OpenClaw 跑起来，全程不消耗网络带宽，也不依赖目标机器的软件源状态。它适合两种人：一种是在内网实验室、客户现场部署，网络条件差到连 npm 都拉不动；另一种是要在十几台机器上重复装环境，实在不想每台都走一遍“下载依赖—卡住—重来”的流程。这篇笔记从分发选型讲起，把 Ventoy 烧录、三平台脚本、镜像源参数和踩过的坑一次性写透。
2. OpenClaw 的安装难点与离线分发选型：依赖链太长，U 盘是性价比最高的解
2.1 OpenClaw 依赖链里到底有哪些成员
OpenClaw 是一个把模型推理、工具调用、终端操作和外部服务串在一起的开源个人助理框架。它不像普通命令行工具那样一个二进制就能跑，至少需要四层依赖：运行时（常见做法是 Node.js 20 LTS，部分插件还依赖 Python 3.10+）、模型推理服务（本地最常用的是 ollama，也可以换成 llama.cpp）、OpenClaw 本体（核心包加插件市场）、以及真正干活的模型权重（GGUF 文件，动辄几个 GB）。
麻烦就出在这几层同时存在。模型权重好歹能靠网盘搬，但 npm 安装时会把几百个小包拆开分别下载，任何一个包下载失败，整个安装就失败；OpenClaw 的插件仓库大多放在 GitHub，网络差的时候 clone 大仓库经常中断；ollama 拉模型又不支持断点续传，拉到一半断了只能从头再来。换句话说，OpenClaw 的安装不是“下个大文件”的问题，是“几十个来源、上千个小文件”的问题。要离线分发，就必须把这些来源在打包阶段全部收敛成一个静态目录，让目标机器上每一条依赖都能在本地命中。
硬件差异也要提前考虑。一套离线包里，Mac 要区分 Apple Silicon 和 Intel，Linux 要区分 x86_64 和 aarch64，Windows 又额外有 ARM64 的小众场景。所以虾盘的离线包不能是“一个 tar 球走天下”，必须是按平台拆目录、由安装脚本探测后挑选对应文件。目录布局的设计决定了后面脚本能写得多简单，这一步偷懒，后面每个平台都要单独写一套逻辑。
2.2 为什么选 U 盘而不是内网源、Docker 镜像或移动硬盘
方案其实不少：自建内网 npm / pip 源、导出 Docker 镜像、用移动硬盘分发。我最早想过内网源，但客户现场的网络环境不可控，内网源服务器本身要维护，还得让目标机器能访问到地址，等于把部署问题平移成了运维问题。Docker 镜像对 OpenClaw 这种要操作宿主机终端、连外部设备的框架也不友好，容器化之后权限和 USB 透传都是坎。
| 方案 | 成本 | 目标机器要求 | 主要问题 |
|---|---|---|---|
| 内网软件源 | 高 | 能访问内网地址 | 现场网络不可控，要维护服务器 |
| Docker 镜像 | 中 | 已装 Docker | 设备透传 / 权限问题多 |
| 移动硬盘 | 高 | USB 口 | 贵，且同样要解决目录结构 |
| U 盘 + Ventoy | 低 | USB 口即可 | 容量有限，但 256GB 足够装完整套依赖 |
U 盘的另一个优势是自带引导能力。烧录工具里 Rufus、UltraISO 都能做启动盘，但虾盘选 Ventoy：它装完后 U 盘会变成一个“引导分区 + exFAT 数据分区”的结构，数据分区可以直接当普通 U 盘读写，Mac、Windows、Linux 全部原生支持 exFAT，三平台通用性在这一层就解决了。目标机器系统坏了、或者出厂是一台裸机时，还可以用 Ventoy 引导一个轻量 Linux 环境进去完成安装，一张盘干两件事。
3. 制作虾盘第一步：Ventoy 双分区烧录与跨平台目录布局
3.1 用 Ventoy 把 U 盘变成“引导 + 数据”双分区
Ventoy 装好后会出现两个分区：一个隐藏的 VTOYEFI 引导分区，一个大容量的 exFAT 数据分区。数据分区在三个系统里都能直接读写，里面放什么都不会影响引导分区，这是我最看重的一点。如果你用的是 Rufus 或 UltraISO，烧完镜像之后 U 盘就变成了只读的安装介质，没法再往里补模型文件；Ventoy 则把“启动能力”和“存储空间”解耦了。
烧录前先确认 U 盘的设备名，这一步翻车通常是把命令写到了系统盘上：
# 先看机器上有哪块盘，认准 TRAN=usb，千万别对系统盘操作 lsblk -o NAME,SIZE,MODEL,TRAN,TYPE # 把 Ventoy 安装到 /dev/sde（替换为你机器上识别到的实际设备名） sudo sh Ventoy2Disk.sh -i -s /dev/sde第一条命令输出里，TRAN=usb的那块盘才是目标；如果同时插了多块移动硬盘，按容量和型号双重确认。第二条命令里，-i表示 install 安装，-s会写入 Secure Boot 支持，Ventoy 的签名信息在安装时会被植入引导分区；安装过程会格式化整个 U 盘，之前的数据全部清空，这个没有后悔药。装完之后重新拔插一次，系统里应该看到一个 exFAT 分区，挂载后就能往里写离线包了。
提示：
Ventoy2Disk.sh在 Linux 下要带 sudo 运行，Windows 下对应的是 Ventoy2Disk.exe，操作逻辑一致。
3.2 三平台目录布局：为什么所有资产都按平台分目录
离线包的文件组织直接决定安装脚本的复杂度。虾盘的目录结构我一般固定成下面这样，新盘量产时照着建目录、丢文件就行：
U-Claw/ # exFAT 数据分区根目录 ├── openclaw-offline/ │ ├── version.txt # 当前离线包版本号，脚本启动时先读它 │ ├── checksums.sha256 # 所有文件的哈希清单，用于完整性自检 │ ├── packages/ # 三平台运行时安装包 │ │ ├── node-linux-x64.tar.xz │ │ ├── node-linux-arm64.tar.xz │ │ ├── node-macos-x64.tar.xz │ │ ├── node-macos-arm64.tar.xz │ │ └── node-win-x64.zip │ ├── wheels/ # pip 离线轮子，Linux 和 Mac 共用 │ ├── npm-cache/ # npm 离线缓存，加速 OpenClaw 本体安装 │ ├── repo/ │ │ ├── openclaw/ # OpenClaw 本体仓库（固定 commit） │ │ └── plugins/ # 常用插件离线缓存 │ ├── models/ │ │ ├── Modelfile # ollama 本地导入模型的描述文件 │ │ └── *.gguf # 模型权重 │ ├── sources/ │ │ ├── pip.conf # 清华 PyPI 镜像配置 │ │ └── .npmrc # npmmirror 镜像配置 │ └── scripts/ │ ├── install_all.bat # Windows 双击入口 │ └── install_all.sh # macOS / Linux 入口packages按平台分文件名而不是分目录，是为了让脚本只靠uname -m的结果就能拼出文件路径，少一层判断；wheels和npm-cache是打包机上用pip download和npm cache add预先填充好的，目标机器安装时优先读它们；repo/里放的是固定 commit 的 OpenClaw 源码和插件仓库快照，避免目标机器在线 clone。
checksums.sha256是整个目录的灵魂。U 盘拷贝过程中经常出现文件损坏，如果你不校验就直接装机，坏掉的文件可能让安装进行到一半才报错，到时候排查成本极高。虾盘量产完第一件事就是在打包机上跑一遍sha256sum -c checksums.sha256，确保每一条记录都能对上再交付。
装 OpenClaw 之前还有一条前置检查：目标机器最低要有 8G 内存和 20G 可用磁盘，模型推理占内存很凶，安装目录默认放在$HOME/.u-claw，避免写入系统目录触发权限弹窗。Windows 上如果是 Windows 10 1809 之前的版本，自带的tar命令不可用，需要提前把 7z 放进packages/——这条我在第 5 章的坑里还会提。
4. 三平台双击安装脚本：本地优先、镜像兜底，OpenClaw 全程走国内源
4.1 安装器的执行顺序：四步模型
虾盘的安装脚本在三个平台上执行顺序完全一致：先探测平台和目录，再从 U 盘本地释放依赖，本地缺失时才回落国内镜像，最后写 OpenClaw 配置并启动 ollama。这个顺序不能倒过来，一旦脚本启动就去请求镜像源，离线场景就白做了。
# 安装主流程（伪代码，三平台脚本都遵循这个顺序） 1. 读取 openclaw-offline/version.txt，不存在则直接退出 2. uname -s / uname -m 探测操作系统和 CPU 架构 3. 从 packages/ 释放对应平台的 Node.js 到 $HOME/.u-claw 4. 从 npm-cache/ 安装 OpenClaw 本体，--prefer-offline 优先本地 5. 本地 wheels 缺失时，PIP_INDEX_URL 指向清华 PyPI 6. 释放 ollama 二进制，用本地 GGUF 执行 ollama create 7. 写入 OpenClaw 的启动配置，输出安装完成的提示第 3 到第 6 步里，“本地优先”是通过包管理器的缓存参数实现的，不是靠手工拷贝大目录。npm 有个参数叫--prefer-offline，它会先查 npm-cache 目录，本地命中就不联网；本地没有的包才走 registry。离线包在打包机上用npm cache add把所有依赖填进npm-cache/，目标机器只要能读到 U 盘，就等于有了一份完整的 npm 私服缓存。
4.2 Windows 双击 .bat：编码与路径的细节
Windows 入口我做成install_all.bat，双击就能跑。bat 必须存成 ANSI 编码，里面尽量减少中文注释，否则在中文版 Windows 上会出现乱码，这个坑后面专门讲。核心逻辑如下：
@echo off setlocal enabledelayedexpansion set "ROOT=%~dp0..\.." set "OFFLINE=%ROOT%\openclaw-offline" set "DEST=%USERPROFILE%\.u-claw" if not exist "%OFFLINE%\version.txt" ( echo [ERROR] U 盘里没有找到 openclaw-offline，检查目录结构。 exit /b 1 ) :: 释放内置 Node.js 绿色版到用户目录，避免 UAC 弹窗 where node >nul 2>&1 if %errorlevel% neq 0 ( mkdir "%DEST%\node" 2>nul tar -xf "%OFFLINE%\packages\node-win-x64.zip" -C "%DEST%\node" --strip-components=1 set "PATH=%DEST%\node;%PATH%" ) :: 设置国内镜像：npm 用 npmmirror，pip 用清华源 set "NPM_CONFIG_REGISTRY=https://registry.npmmirror.com" set "PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple" :: 安装 OpenClaw 本体，优先读 U 盘里的 npm 离线缓存 if not exist "%DEST%\openclaw\node_modules" ( npm install --prefix "%DEST%\openclaw" ^ --cache "%OFFLINE%\npm-cache" --prefer-offline ) echo 安装完成，启动命令在 %DEST%\openclaw 下。%~dp0是批处理文件所在目录，后面..\..是为了从scripts/回退到 U 盘根目录；路径里我特意用的是引号包裹的完整路径，避免用户名带空格时炸掉。--prefix指定 npm 全局安装的目标目录，不写注册表、不需要管理员权限；--cache指向 U 盘里的离线缓存，--prefer-offline保证缓存优先。注意 Windows 10 自带的 tar 是 bsdtar，支持 zip 和 tar.xz，老系统没有就要先释放 7z。
4.3 macOS / Linux 的 .sh：解决 exFAT 执行权限问题
macOS 和 Linux 共用一份 bash 脚本install_all.sh。这里有个血泪经验：exFAT 分区没有 POSIX 权限位，从 Finder 双击.sh或者.command会直接报“Permission denied”，哪怕你已经在终端里 chmod +x 过——重启拔插之后权限又会消失。所以脚本不依赖可执行位，统一用bash install_all.sh运行，Windows 上的 bat 不受影响，因为它本来就是解释器加载的。
#!/usr/bin/env bash set -euo pipefail ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)" OFFLINE="$ROOT/openclaw-offline" DEST="$HOME/.u-claw" OS="$(uname -s)" ARCH="$(uname -m)" [ -f "$OFFLINE/version.txt" ] || { echo "缺少 version.txt，U 盘结构不完整"; exit 1; } install_node() { local pkg case "$OS-$ARCH" in Darwin-arm64) pkg="$OFFLINE/packages/node-macos-arm64.tar.xz" ;; Darwin-x86_64) pkg="$OFFLINE/packages/node-macos-x64.tar.xz" ;; Linux-x86_64) pkg="$OFFLINE/packages/node-linux-x64.tar.xz" ;; Linux-aarch64) pkg="$OFFLINE/packages/node-linux-arm64.tar.xz" ;; *) echo "不支持的平台：$OS-$ARCH"; exit 1 ;; esac mkdir -p "$DEST/node" tar -xf "$pkg" -C "$DEST/node" --strip-components=1 export PATH="$DEST/node/bin:$PATH" npm config set registry https://registry.npmmirror.com } install_node${BASH_SOURCE[0]}取的是脚本本身路径，不是当前工作目录，这样用户在终端里 cd 到任何地方执行脚本都不会找错 U 盘。uname -s在 macOS 上返回Darwin，Linux 上返回Linux；uname -m在 Apple Silicon 上返回arm64，在大多数 ARM 开发板上返回aarch64，所以分支要写Darwin-arm64和Linux-aarch64两条。这两个命令的输出差异是脚本里最容易写错的地方，盲目用uname -m判断操作系统会翻车。
ollama 的离线导入是另一段关键逻辑。离线包里的模型不能靠ollama pull拉，而是用本地 GGUF 文件注册：
# 释放 ollama 离线二进制并启动服务 "$DEST/ollama/ollama" serve >/dev/null 2>&1 & sleep 3 # 从 U 盘导入本地模型，整个过程不访问网络 "$DEST/ollama/ollama" create u-claw -f "$OFFLINE/models/Modelfile"ollama create的-f参数指定 Modelfile，里面的FROM行直接指向 U 盘上的.gguf文件路径，比如FROM /Volumes/U-Claw/models/qwen-14b.gguf。这个命令做的事情是把本地文件注册成一个 ollama 模型名，不产生网络请求；模型越大，这个注册过程越久，但本质只是建索引和元数据，通常几十秒内完成。
4.4 必调参数表：npm / pip / ollama 三处国内源配置
安装器的镜像配置不是临时 export 一下就完事，而是要落到用户配置文件里，否则装完 OpenClaw 之后，它内部启动时去拉插件照样走官方源。虾盘的做法是在安装末尾把下面的配置写进用户目录：
| 组件 | 虾盘使用的国内源 | 写入位置 |
|---|---|---|
| npm | https://registry.npmmirror.com | ~/.npmrc或NPM_CONFIG_REGISTRY |
| pip | https://pypi.tuna.tsinghua.edu.cn/simple | ~/.pip/pip.conf或PIP_INDEX_URL |
| ollama | 不联网，本地 Modelfile 导入 | 无镜像参数 |
| OpenClaw 插件市场 | 本地repo/plugins/离线路径 | 启动配置里的 plugins 目录 |
镜像源参数最忌讳的是只在命令行里export一次。OpenClaw 安装完之后，它内部的 package 管理脚本和 Python 插件都可能自己拉起子进程，子进程不会继承父 shell 的临时变量，所以配置文件必须落盘。~/.npmrc写一行registry=https://registry.npmmirror.com就够了，pip 则要创建一个~/.pip/pip.conf文件再写index-url。这两个文件在三个平台上路径一致，脚本里用一个printf就能生成。
5. 虾盘安装避坑：Secure Boot、exFAT 权限、乱码与中断的五个真实现场
5.1 Ventoy 在开启 Secure Boot 的机器上直接失败
现象：U 盘插到一台 Win 11 机器上，Ventoy 引导菜单都没出现，直接提示“Verifying shim SBAT data failed: Security Policy Violation”，BIOS 里也读不出 U 盘启动项。
原因：Ventoy 的引导程序没有该机器的 MOK 签名，UEFI Secure Boot 把它拦在启动链路之外。这跟你是否用-s参数安装没有必然关系，-s只是把 Ventoy 的证书写进 U 盘引导分区，目标机器的固件不信任这个证书就照样拒载。
解决：最省事的路径是进 BIOS 临时关掉 Secure Boot，装完 OpenClaw 之后再开回来；如果现场不允许动 BIOS，就在目标机器上先用 Ventoy 的“MOK 管理”手动登记一次签名，登记完重启即可。量产时记得每块盘都用-s装，至少能少一半兼容性问题。
5.2 exFAT 丢权限导致双击 .sh 报 Permission denied
现象：macOS 上双击install_all.sh，提示Permission denied，终端里ls -l看脚本没有x位，chmod +x 之后当时好了，重新拔插 U 盘又没了。
原因：exFAT 是微软设计的文件系统，根本不存储 Unix 权限位；macOS 读取它时会给所有文件挂一个默认权限，chmod 的结果只存在于当前挂载会话里。
解决：虾盘的脚本设计成不依赖可执行位，凡是#!/usr/bin/env bash的脚本一律用bash 脚本路径显式调用。macOS 用户第一次使用，我会让他在终端里执行bash /Volumes/U-Claw/openclaw-offline/scripts/install_all.sh，Windows 用户没有这个问题。
5.3 Windows 下 bat 中文注释乱码、安全软件拦截
现象：双击install_all.bat后窗口里中文全是乱码，某些机器上还直接被 Defender 拦截，提示检测到恶意脚本。
原因：bat 文件默认用系统 ANSI 代码页解析，存成 UTF-8 编码时中文注释会被拆成乱码字节；部分安全软件对“从可移动磁盘读取脚本再写文件和注册表”的模式过敏，把它当成潜在恶意行为。
解决：bat 一律保存为 ANSI（Windows 中文版对应 GBK），脚本里的输出信息尽量用英文，中文提示只在 echo 层显示不参与逻辑。被拦截时到 Defender 的“保护历史记录”里选择“允许”，或者把 U 盘的 exFAT 分区加进排除项。别因为图省事把 bat 转成 UTF-8，这个乱码问题无解。
5.4 本地 repo 不完整，安装到一半才报“找不到模块”
现象：安装进度条走了 70%，npm 突然报ENOTFOUND或者Module not found: openclaw-core，看起来是网络问题，但网络明明没断。
原因：U 盘里的repo/openclaw是打包时 clone 的完整仓库，但打包完成后往 U 盘拷贝时中断过，.git/目录损坏或者某些文件缺失。npm install 时有些依赖要读取仓库里的 hooks 目录，文件缺失就炸了。
解决：打包机在发布前必须跑sha256sum -c checksums.sha256，同时在安装脚本开头加一道快速校验——只校验version.txt和repo/openclaw/package.json两个关键文件的哈希，匹配才继续。中断的 cp 不会报警，但哈希一定对不上，这比让用户跑到一半才发现问题要体面得多。
5.5 macOS 拷贝模型时写入资源分叉，Linux 载入不了 GGUF
现象：在 Mac 上把 GGUF 模型拖进 U 盘，换到 Linux 机器上 ollama create 报错，说文件不是合法模型。
原因：macOS Finder 拷贝文件到 exFAT 会额外写入._开头的 AppleDouble 文件和.DS_Store，某些工具还会给文件附加 resource fork。Linux 上 ollama 读取时把这些元数据当成模型内容的一部分，解析直接失败。
解决：打包阶段用 tar 在 macOS 上封装模型目录，并设置COPYFILE_DISABLE=1禁掉 AppleDouble：
COPYFILE_DISABLE=1 tar -czf models.tar.gz -C openclaw-offline/models .后续在 Linux 上解包得到的就是干净的纯模型文件。日常维护时也别用 Finder 往 U 盘里补模型，用rsync --no-owner --no-group稳定得多。
6. 虾盘后续维护：增量更新脚本与上机前的 30 秒自检
6.1 一块 U 盘用半年：增量补丁代替全量重烧
OpenClaw 版本迭代很快，每次更新都重新烧盘不现实。我的做法是打包机上维护一个build_patch.sh，对比旧版和新版离线包的目录，输出增量清单：
# 增量清单格式：每行一个操作，之后脚本按行执行 ADD packages/node-linux-x64.tar.xz b8f3... DEL packages/node-linux-x64.tar.xz.old UPD repo/openclaw/package.json 7d2a...目标 U 盘拿到增量清单后执行apply_patch.sh，只增删变化的部分。模型文件一般不更新，因为几个 GB 的 GGUF 重新拷贝一次耗时太久；npm-cache 如果变化大也建议整体替换，增量对缓存目录的提升有限。这个流程坚持下来，一张虾盘能用大半年。
6.2 上机前的 30 秒自检
交付前养成一个习惯：把成品 U 盘插到一台干净的 Linux 机器上，跑一遍完整性校验，再交给现场。校验函数可以直接放在install_all.sh里复用：
verify_shrimp() { local root="${1:?用法：verify_shrimp <U盘挂载点>}" if [ -f "$root/openclaw-offline/checksums.sha256" ]; then (cd "$root/openclaw-offline" && sha256sum -c checksums.sha256 --quiet) else echo "缺少 checksums.sha256" return 1 fi }这套流程在最开始做虾盘 v0.1 时救过我一次：打包机拷贝中断没发现，直接带到现场，装到一半报错，我只能对着终端干瞪眼半小时。后来每次量产完先校验再交付，这种尴尬再没出现过。希望帮到你。
本文还有配套的精品资源，点击获取
