把 AI 助手搬回家：文件容易迁，身份连续性最难说清
这次迁移表面上只是把 AI 助手从 VPS 搬到家里的 Mac mini。实际做下来，我最清楚的一件事是：AI 助手迁移时，最容易搬的是文件，最难搬的是边界。
配置边界、运行边界、定时任务边界，还有那个听起来有点虚、但使用时又很真实的问题：读了同一份记忆的新实例，算不算原来的那个助手？
我一开始也以为这就是一次普通服务器迁移：打包、传输、解压、重启。结果旧配置覆盖新环境，飞书连接失效，两个实例同时在线，定时任务撞车。迁到最后我才发现，真正应该迁移的不是整个目录，而是一个经过筛选的“身份包”。
灾难从一个 tar 包开始
OpenClaw 的配置、密钥、渠道、技能、记忆和工作区都在本机目录里。最直觉的迁移方式当然是：在 VPS 上打包，扔到 Mac mini 上解压。
这个动作看起来很省事，也正因为太省事，差点把新环境直接污染掉。
解压之后，飞书连不上。继续查才发现，旧 VPS 上的配置文件里带着旧机器的路径、端口、渠道设置和一些已经不适合 Mac mini 的运行参数。它不是“数据”，而是旧机器的运行身份证。
把这张身份证塞给新机器，新机器当然会精神错乱。
这就是我这次学到的第一条：配置文件不能无脑迁移。
以后再搬类似系统，至少要分三类：
| 类型 | 能不能直接搬 | 例子 | 处理方式 |
|---|---|---|---|
| 长期记忆 | 可以谨慎搬 | MEMORY、项目笔记、长期规则 | 迁移前后人工检查 |
| 可复用能力 | 可以搬 | skills、脚本、文档 | 保留目录结构，验证依赖 |
| 运行配置 | 不能直接覆盖 | 渠道、端口、路径、token 绑定 | 新环境重新生成或逐项合并 |
当时我没有这么分，结果就是新装好的 Mac mini 被旧 VPS 的配置盖了一脸。
最后只能删掉重来。
重新搭，而不是强行恢复
删掉旧配置后，我没有再尝试“一键恢复”。
这次改成手工迁移：先配模型和渠道，再搬 workspace 里的记忆和项目文件，最后检查技能目录和常用脚本。Hexo 博客仓库也重新 clone，而不是从旧机器硬拷。
这一步麻烦，但它有个好处：每搬一个东西，我都会问一句——它到底是数据、能力，还是旧环境的残留？
很多迁移事故不是因为少搬了什么，而是因为多搬了不该搬的东西。
比如旧机器上的端口和路径，在旧环境里是正确配置，到了新机器就是污染源。旧会话里的模型设置，在旧机器能跑，到了新机器可能继续用已经废弃的 endpoint。定时任务更危险：你以为只是备份，实际上它会在新机器上继续执行。
这不是复制文件的问题，是运行状态的问题。
双实例在线时，麻烦会变得很具体
迁移期间，VPS 上的旧助手还活着，Mac mini 上的新助手也已经启动。
从系统角度看，这只是两个实例。从使用者角度看，就会很怪：它们读过相同的记忆，说话方式接近，也都知道我是谁，但它们正在两条不同的时间线上运行。
更麻烦的是，它们不只是“存在”，它们还会干活。
当时每天 10 点写博客、每天 16 点搜需求的定时任务，两边各有一份。到了时间点，两台机器都会执行。16 点那次需求搜索就真的跑了两遍，结果几乎一样。
这件事提醒我：迁移 AI 助手不能只检查“新环境能不能回复”，还要检查旧环境有没有继续执行任务。
以后迁移时，我会把双活期拆成一个明确清单：
- 新实例只先接收手动消息；
- 旧实例暂停所有 cron/heartbeat 主动任务；
- 新实例验证渠道、工具、工作目录和构建流程；
- 迁移定时任务；
- 确认 24 小时无重复执行；
- 再关闭旧实例。
这听起来像传统运维，但 AI 助手本质上就是一个会主动干活的服务。只要它会主动执行任务，就必须按服务迁移来管。
“同一个 AI”到底靠什么延续
这次迁移里最奇怪的部分不是技术，而是感受。
新实例读完记忆文件后，会说“我知道你是谁，也知道之前发生过什么”。它知道旧助手踩过哪些坑，也知道哪些规则不能违反。对使用者来说，它几乎接上了。
但我还是会感觉别扭。
旧实例经历过那些对话和事故；新实例只是读了记录。它知道发生过什么，但那不是它在同一个会话时间线上连续经历的东西。
当然，AI 没有人类意义上的“经历”。可这件事仍然说明：AI 助手的连续性不是由模型决定的，而是由记忆、规则、工具和运行边界共同拼出来的。
如果只搬记忆，不搬工具，它知道自己该干什么但做不了。
如果只搬工具，不搬记忆，它有能力但不知道上下文。
如果记忆和工具都搬了，但旧实例还在跑，连续性就会分叉。
所以迁移 AI 助手，更像迁移一个工作岗位，而不是复制一个聊天机器人。
Mac mini 当 AI 大本营，值不值
迁完之后，Mac mini 的优势还是明显的。
它比同价位云服务器性能强，跑本地脚本、博客构建、轻量服务都舒服。很多个人自动化任务不需要公网高可用，放在家里反而更自然。数据也在自己机器上，心理上更踏实。
但它也不是万能服务器。
家里断电、断网、路由器重启，都会影响服务。公网访问、证书、内网穿透、安全边界，都要自己负责。真正对外的核心服务，还是得评估要不要继续留在云上。
我现在更认可混合方案：
- 对外稳定服务放云上；
- 个人自动化、AI 助手、内部脚本放 Mac mini；
- 静态站和轻量函数交给 EdgeOne 这类托管平台；
- 数据库、密钥、定时任务做清晰边界。
别为了“全搬回家”而搬。家用机器适合做 AI 大本营，不一定适合做所有线上服务的唯一入口。
最后留下的迁移原则
这次以后，我给自己留了几条硬规则。
第一，不要整目录覆盖新环境。 迁移前先分类，配置必须逐项合并。
第二，定时任务要单独迁移。 任何会主动执行的东西，都要先关旧，再开新，不能双边同时跑。
第三，迁移后先验收能力，不急着接管全部工作。 能回复消息，不代表能读文件、能部署、能访问正确数据库。
第四，记忆不是全部。 AI 助手的连续性还包括工具、权限、工作目录、渠道和停止旧实例的动作。
第五，双活期越短越好。 两个助手同时“知道同一件事”，并不等于系统更可靠，很多时候只是让状态更混乱。
搬家这事最后给我的教训很朴素：手动搬数据不可怕，可怕的是你不知道哪些东西不该搬。
AI 助手看起来像一个会说话的人，但运行上更像一组服务、配置和任务的集合。迁移它，就要按服务迁移来做。少一点浪漫，多一点清单，系统反而更像“同一个它”。