OpenClaw极限避坑指南(迁移篇)

作者：古德白

来源：Sillicon Mind科技播客

封面：即梦AI生成

🦞 最近有个叫“同事.skill”的项目很火。它能把一个人的文档、聊天记录、邮件打包，训练成一个AI数字人，继续回答问题、做表格。有人叫好，有人担忧隐私，但这件事本身说明了一个趋势：AI正在成为我们工作人格的延伸。

那么问题来了：如果你花了几个月“喂养”的OpenClaw（“龙虾”）——它记得你的代码风格、知道你的服务器密码、甚至学会了你怼产品经理的方式——当你换电脑、换团队，或者只是想把它复制给同事时，怎么才能让这只龙虾“魂穿”到新家，而不失忆、不智障、不闹脾气？

咱们直接上干货，三套经过验证的迁移方案，从傻瓜式全量备份到模块化分享，总有一款适合你。

方案一：全量物理迁移（搬山诀）

适用场景：旧机器报废、系统重装、或你根本不想思考哪些文件要搬。

优点：极简、完整，连环境变量、会话历史、渠道登录状态都保留。

缺点：会带上旧机器的“垃圾文件”；跨操作系统时需处理路径差异。

具体步骤

- 步骤 0：停止服务（重要！）

在旧机器上，必须先停止 Gateway，否则文件可能正在被写入，导致备份损坏：

openclaw gateway stop

- 步骤 1：打包状态目录和工作区

OpenClaw 的状态目录和工作区是两个独立的概念，都需要迁移：

cd ~

# 打包状态目录（包含配置、认证、会话）

tar -czf openclaw-state.tgz .openclaw

# 打包工作区（包含记忆、人格文件）

tar -czf openclaw-workspace.tgz .openclaw/workspace

📌 为什么分开打包？ 官方文档明确建议：状态目录和工作区是两个独立的概念。状态目录存的是“登录态”，工作区存的是“你是谁”——分开打包便于灵活迁移。

- 步骤 2：传输到新机器

scp openclaw-state.tgz user@new-machine:~/

scp openclaw-workspace.tgz user@new-machine:~/

- 步骤 3：在新机器上安装 OpenClaw

先完成基础安装，允许初始化生成默认目录（安装命令请参考 OpenClaw 官方文档）。

- 步骤 4：解压并覆盖

cd ~

tar -xzf openclaw-state.tgz

tar -xzf openclaw-workspace.tgz

- 步骤 5：修正权限

# 确保文件所有权正确

sudo chown -R $USER:$USER ~/.openclaw

chmod -R 700 ~/.openclaw

- 步骤 6：运行 Doctor 并重启

# Doctor 是官方推荐的“安全可靠”命令，加上--fix参数会自动修复配置迁移、权限异常、渠道状态等问题：

openclaw doctor --fix

openclaw gateway restart

openclaw status

# 验证检查清单

openclaw status显示 Gateway 正在运行

你的渠道仍然连接（例如企微，不需要重新配对，但可能需要重新配置IP白名单）

工作区文件（记忆、配置）存在

方案二：记忆与人格迁移（吸星大法）

适用场景：只迁移 OpenClaw 的“灵魂”——人格、记忆、用户偏好、工作流配置。这是最常用、最安全的方式。

核心原理：OpenClaw 的核心“灵魂”存储在~/.openclaw/workspace/目录下的多个文件中：

文件	作用	比喻
`SOUL.md`	人格定义：说话风格、行为原则、边界意识	“性格”
`USER.md`	用户画像：你的称呼、时区、偏好、禁区	“身份证”
`AGENTS.md`	操作流程：默认工作流、交付标准、安全规则	“工作手册”
`MEMORY.md`	长期记忆：具体的事实和经历	“记忆”
`IDENTITY.md`	智能体名称/风格/表情	“名字”
`TOOLS.md`	工具使用说明（可选，用户维护）	“工具说明书”

📌 设计理念：OpenClaw 采用“文件即记忆”的设计——每次会话启动时，Agent 会读取这些文件，“记起自己是谁”。

具体步骤

- 步骤 1：在旧机器上导出灵魂

mkdir ~/openclaw_soul_backup

cp ~/.openclaw/workspace/SOUL.md ~/openclaw_soul_backup/ 2>/dev/null

cp ~/.openclaw/workspace/USER.md ~/openclaw_soul_backup/ 2>/dev/null

cp ~/.openclaw/workspace/AGENTS.md ~/openclaw_soul_backup/ 2>/dev/null

cp ~/.openclaw/workspace/MEMORY.md ~/openclaw_soul_backup/ 2>/dev/null

cp ~/.openclaw/workspace/IDENTITY.md ~/openclaw_soul_backup/ 2>/dev/null

cp ~/.openclaw/workspace/TOOLS.md ~/openclaw_soul_backup/ 2>/dev/null

- 步骤 2：在新机器上初始化

# 官方推荐：用 openclaw setup 自动创建默认模板

openclaw setup

- 步骤 3：注入灵魂

cp ~/openclaw_soul_backup/*.md ~/.openclaw/workspace/

- 步骤 4：重启 Gateway（重要！）

复制完成后，必须重启 Gateway，让 Agent 重新读取这些文件：

openclaw gateway restart

- 步骤 5：验证

启动 OpenClaw，问一个只有旧机器知道的问题，例如：

问：“我之前说过我最讨厌什么代码规范？”

重要说明

如果某些文件在旧机器上不存在，属正常现象（例如TOOLS.md是可选的）

2>/dev/null用于忽略“文件不存在”的错误提示

方案三：技能与插件迁移（移花接木）

适用场景：你开发了自定义技能（skill），只想分享功能，不暴露个人记忆或API密钥。

技能加载位置（按优先级排序）：

/skills/—— 工作区技能（优先级最高）

~/.openclaw/skills/—— 本地/全局技能

内置技能（随安装包提供）

核心思路：技能是代码，代码就该进 Git。把你的技能推送到代码仓库，新机器上直接git clone安装。

⚠️ 安全警告：在将技能推送到 Git 之前，务必确认目录中只包含技能相关的文件（manifest.json、instructions.md、scripts/、assets/ 等）。绝对不要将以下内容提交到 Git：

任何包含 API Key、Token、密码的文件
~/.openclaw/credentials/ 目录下的文件
个人 SOUL.md、USER.md 等包含隐私信息的工作区文件
.env 文件

如果不确定，建议单独创建一个干净的目录存放技能，再初始化 Git。

具体步骤

- 步骤 1：在旧机器上把技能推送到 Git

cd ~/.openclaw/skills/my-skill

# 先创建 .gitignore，排除敏感文件

echo ".env" >> .gitignore

echo "*.key" >> .gitignore

echo "*.pem" >> .gitignore

git init

git add .

git commit -m "feat: 初始版本"

git remote add origin https://github.com/yourname/openclaw-skill-xxx.git

git push -u origin main

- 步骤 2：在新机器上从 Git 安装

git clone https://github.com/yourname/openclaw-skill-xxx.git ~/.openclaw/skills/my-skill

- 步骤 3：验证技能加载

openclaw skills list

最佳实践

把技能做成公开或私有 Git 仓库，这样你在任何一台新机器上，一条git clone命令就能把技能拉下来。

关于官方迁移功能

看到这里，你可能在想：这么常见的需求，OpenClaw 官方难道没有一键迁移功能吗？

坦白说，目前还没有。

官方目前的定位是“Bring Your Own Infrastructure”——你可以自己搭建、自己配置、自己管理。迁移这件事，暂时还需要你手动操作。这也是为什么我们写了这篇文章——因为这些坑，我们替你踩过了。

不过，从 OpenClaw 近期的 Roadmap 来看，官方已经在关注这个问题。社区里关于openclaw export/openclaw import的讨论越来越多，相信不久的将来，一键迁移、云端同步、配置导入导出这些功能，都会陆续补上。

到那时候，这篇文章可能就过时了——但那是好事。

🦞在官方功能到来之前，先用这三招顶住。

迁移决策树，你要迁移什么？

├─ 整个环境 + 数据 + 配置 → 方案一（搬山诀）

├─ 仅记忆 + 人格 → 方案二（吸星大法）

└─ 仅分享功能模块 → 方案三（移花接木）

常见问题

Q：迁移后OpenClaw变得“笨”了，怎么回事？

A：大概率是vector_store.db不兼容。删除它，让系统基于SOUL.md和MEMORY.md重新生成。

Q：我能把一只“龙虾”同时给多台机器用吗？

A：可以，但注意：

如果多台机器同时写入记忆，会导致向量库冲突。建议只在一台机器上开启记忆写入，其他机器只读。

配置文件中的 API key 如果超出速率限制，可能被封。

Q：有没有一键迁移脚本？

A：目前社区没有官方工具，但你可以把方案二的命令写成一个 bash 脚本。注意：跨平台路径处理需要额外判断。

结语

好了，三种迁移方案聊完了。打个比方你就明白了：

方案一：像搬家，连床垫带冰箱一块儿搬走。省事是真省事，但搬完发现旧冰箱里有半盒过期酸奶也跟着过来了。

方案二：像“赛博附体”。壳子随便换，但里面那个“你”——记忆、人格、说话方式——一点没变。主打一个换壳不换魂。

方案三：像传祖传菜谱。你把秘方写成书，出版发行（推送到代码仓库）。朋友想学，直接去买一本（git clone），主打一个省心。

不管选哪条路，核心就一句话：别把你的龙虾锁死在一台机器上。不然哪天电脑进水，你的赛博分身也跟着“溺亡”，这几个月喂的心血全白费——那场面，不敢想。

方案聊完，说点扎心的。

“同事.skill”为什么火？因为它捅破了一层窗户纸：你的工作痕迹——聊天记录、文档、邮件、代码——喂给AI之后，产出来的那只“龙虾”，到底算谁的？

二十年前，没人觉得文档是资产。十年前，没人觉得数据是资产

今天，你的龙虾里有你的说话方式、你的业务理解、你的代码习惯。它是你花三个月养出来的数字分身。

那么问题来了：这只龙虾，到底是你的工具，还是你的“同事”？

这个话题，今天聊着像个段子，但它可能很快就会变成现实。

关于作者：一个长期关注AI的技术人

一个不站队的行业观察者

📢 延伸讨论

好了，技术方案讲完了。有些事儿光看文章不够，值得再琢磨琢磨。

下面三个问题，感兴趣的欢迎来评论区聊聊：

问题一：你养的龙虾，算你的还是算公司的？

文档是公司的，数据是公司的，代码也是公司的。但你用这些东西三个月喂出来的那只龙虾——它的说话方式像你，它的判断逻辑像你，它连写代码的习惯都像你。

那它身上，到底有多少属于公司，多少属于你？

问题二：如果同事“复刻”了一个你，你怎么看？

“同事.skill”这类工具已经开源了。理论上，你的聊天记录、邮件、代码评审意见，都可以拿来训练一个“数字版你”。

如果公司真的这么做了——一个AI在替你回答问题、帮你干活，你是觉得“挺好的，省事了”，还是觉得“怪怪的，说不上来”？

问题三：AI资产，企业该不该管？

当每个员工手里都养着一只龙虾，当这些龙虾拼在一起就是半套业务系统——企业要不要把这些“数字分身”纳入资产管理？

管吧，好像有点越界。不管吧，万一哪天核心业务逻辑跟着一只龙虾一起“蒸发”了呢？