从本地到云：一个 OpenClaw 玩家的迁移踩坑实录

本文是「OpenClaw 云上实战指南」系列第 5 篇（完结篇）

我在 Mac 上跑了两周龙虾（OpenClaw ），合盖断了 3 次之后决定搬到云上。

头一次断是周五下班，合上 MacBook 就走了——周末两天 Slack 消息没人回、RSS 抓取全停了、cron 任务挂了一地。第二次是出门开会，4G 热点一断龙虾直接掉线。第三次更离谱：macOS 系统更新自动重启，我回来一看 进程没了，session 文件还锁着。

三次之后我不想再赌了。合盖断线这事在本地部署是个无解的结构性问题——你不可能要求笔记本永远开着不动。

刚好第 1 篇讲过 Lightsail 一键部署、第 3 篇讲过龙虾自动开 EC2——云端实例不存在”合盖”这个概念，启动之后就一直跑着。搬家本身不难，但坑全藏在迁移过程里。

这篇文章记录我从本地 Mac 迁到亚马逊云科技 EC2 实例的完整过程，包括迁移清单、实际命令、4 个踩过的坑和解法，以及搬完之后的真实体感对比。如果你也受够了笔记本合盖断线，这篇能帮你少走弯路。

先搞清楚龙虾的”家当”有哪些。在本地 Mac 上跑一下 ，看看 目录结构：

一共 5 类东西需要考虑：

其中 是重中之重。里面的 定义了龙虾的性格， 存着它的日常记忆， 是你装的各种能力插件。这些丢了龙虾就不是”你的龙虾”了——它虽然还能跑，但会变成一只陌生的新龙虾。

云端实例我已经按第 1 篇的方案 B 开好了——一台 ARM 实例，挂了 IAM 角色，Bedrock 权限就位。

看看包有多大：

跑了两周，4MB 多——主要是 session 历史。

输出：

别直接启动——配置文件还是本地版本的，直接跑会炸。改什么见下面的坑 1。

这是我踩的头号坑。本地 Mac 上用的是 Anthropic 官方 API Key，配置长这样：

搬到 EC2 后要换成 Bedrock + IAM，不需要任何密钥（第 1 篇详细讲过原理）：

用 看一下改了什么：

三行改动，API Key 直接删掉。EC2 实例通过 IAM 角色自动获取临时凭证，不需要配置文件里写任何密钥。

验证方法：

看到 就说明模型调用链路通了。整个过程不需要管密钥轮换、不需要担心 Key 泄露——IAM 角色的临时凭证由亚马逊云科技自动管理，每小时刷新一次。

如果之前本地用的是其他模型（比如 OpenAI），Bedrock 上也有 Claude、Nova、DeepSeek 等多种选择，改 字段就行。第 4 篇会详细讲 Nova 模型的切换实战。具体支持列表见 Bedrock 模型页面。

把 目录搬过去之后，启动龙虾，发现它完全不记得之前的对话。

检查 session 文件：

问题在 字段——还指向 （macOS 路径），但云端是 。OpenClaw 用这个路径解析 workspace 里的相对引用。

修复：批量替换路径

验证：

重启 gateway，龙虾恢复记忆——之前的对话上下文全回来了。

踩坑教训：迁移完启动前，养成习惯先 一遍旧路径，确认没有残留：

⚠️ 如果你的 session 文件特别大（几十 MB），也可以选择不迁移——龙虾会从 和 目录重建上下文。丢的是逐条对话记录，不是”人格”。人格在 ，记忆在 ，这些都在 workspace 里。

本地 Mac 时区是 （UTC+8），我设了一个每天早上 9 点抓 RSS 并推送摘要的 cron：

搬到 EC2 后没改，结果——凌晨 1 点（UTC 9:00 = 北京时间 17:00？不对，UTC 9:00 = 北京 17:00）。

等等，我之前设的是”本地 9:00″，本地是 UTC+8，所以实际是 UTC 1:00。到了 EC2 上系统时区是 UTC，cron 读的是 UTC 时间， 就变成了 UTC 9:00 = 北京 17:00。

总之时间全乱了。

解法：统一用 UTC 思维

= UTC 01:00 = 北京时间 09:00。搬家时脑子里要装一个公式：北京时间减 8 小时 = UTC 时间。

转换速查表（北京时间 → UTC cron 表达式）：

或者直接让龙虾帮你算——在 Slack 里跟它说”帮我把所有 cron 任务从北京时间转成 UTC”，它会自动改 里的时间字段。毕竟这种机械换算的活交给 AI 来做正合适。

你也可以在 EC2 上改系统时区（），但不建议——云上统一用 UTC 是业界惯例，避免和 CloudWatch、CloudTrail 等服务的日志时间对不上。日志排查的时候时区不统一会让人抓狂。

Slack 和 Telegram 的 bot token 是跟着 bot 走的，不绑定特定 IP 或机器。所以 token 搬过去理论上直接能用——但 webhook URL 是绑 IP 的，换了机器就得更新。

如果你用的是 Socket Mode（推荐），连接方式是 outbound websocket，不需要 webhook URL，token 搬过去就能用：

启动后确认连接：

Telegram bot 默认用 webhook，URL 绑定了旧机器的地址。搬到新 IP 后需要更新：

如果嫌每次换 IP 都要改 webhook，可以改用 long polling 模式——在 里把 去掉，龙虾会自动降级到 polling：

第 2 篇里的 iMessage 渠道比较特殊——它依赖 macOS 系统，如果你从 Mac 迁到 Linux，iMessage 渠道需要单独保留在 Mac 实例上。可以参考第 2 篇的 Mac 云实例方案。

跑了一周之后回头看，差距一目了然：

体感上变化很大的一点：以openclaw 配置前用龙虾像用一个”桌面软件”，打开才有，关了就没了。搬到云上之后它变成了一个”一直在线的同事”——你不需要主动想着去用它，它自己会在后台帮你抓新闻、处理消息、跑定时任务。

那三次合盖断线的日子一去不复返了。

如果你现在还在本地跑龙虾，而且只是偶尔用用，本地完全够了——不需要为了”上云”而上云。

但如果你已经开始依赖它（配了 cron 任务、接了 Slack 渠道、让它帮你监控 RSS），那迁移到云上是早晚的事。与其等下次合盖断线的时候着急，不如现在花 40 分钟搬完。

从这个系列五篇文章走下来，一只龙虾从”试试看”变成了”离不开”：第 1 篇解决了部署和安全问题，第 2 篇打通了苹果生态，第 3 篇实现了全自动扩展，第 4 篇探索了多模型协作，这第 5 篇解决了”搬家”的临门一脚。

五篇看完，你手上应该已经有一只跑在云端、24/7 在线、零密钥、能自己干活的龙虾了。剩下的事——就交给它吧。

怕你上面看散了，这里把所有命令串一遍：

搬家本身不难——4 条命令传文件，改 3 处配置——难的是那几个不看日志根本发现不了的坑。踩完之后回头看，早搬早省心。

系列回顾：

• 第 1 篇：Bedrock + IAM 零密钥部署
• 第 2 篇：Mac 云实例接入苹果生态
• 第 3 篇：龙虾 AI 全自动部署实战
• 第 4 篇：电商多 Agent 协作实战（即将发布）

延伸阅读：《把 AI Agent 部署到云端，是值得做的事》 — 亚马逊云科技官方博客

OpenClaw 是开源项目，欢迎参与社区贡献。本系列所有代码和配置均在 GitHub 上公开。