OpenClaw 主实例从桌面机迁移到树莓派：一次本地 AI 代理基础设施重构
本地 AI 代理最初往往只是一个“能跑起来”的工具：在桌面机上安装，接入模型，配置几个插件，再接入聊天渠道或浏览器能力。这个阶段的重点是验证可用性，而不是长期运行。 但当一个 AI 代理开始承担更多日常任务，例如消息通道响应、文件处理、浏览器辅助、系统状态检查、项目资料检索，它就不再只是一个临时工具，而会逐渐变成本地基础设施的一部分。此时，运行位置、可用性、状态目录、外部访问入口、权限边界和数据分工都会变得重要。 这次迁移的核心，就是把 OpenClaw 的主安装实例从一台桌面 Linux 主机迁移到一台树莓派上，让树莓派承担长期在线的主服务角色，而桌面机则退回为扩展资源主机。 迁移前的结构 迁移前，OpenClaw 主实例运行在一台日常使用的桌面 Linux 主机上。它同时承担多个角色： 这种结构在早期很方便。所有东西都在同一台机器上，路径简单，浏览器也直接可见，调试成本低。需要排查时，打开终端就能看到服务、配置和日志。 但随着 OpenClaw 逐渐变成一个长期使用的代理系统，这种结构的问题也越来越明显。 首先，桌面机不是理想的 24 小时在线主机。它可能重启、关机、休眠，也可能因为桌面环境、浏览器、图形会话或用户操作影响服务状态。 其次，桌面机上同时有用户日常使用的程序和 OpenClaw 的自动化任务。一旦 AI 代理具备操作浏览器、文件和系统命令的能力，就必须严格区分“代理可管理的资源”和“用户私人使用的资源”。 第三，桌面机上的 OpenClaw 历史安装路径、配置目录、浏览器 profile、systemd user service、shell alias、旧备份目录等内容逐渐混杂。继续在原地修补，会让整个系统越来越难判断边界。 因此，迁移的目标不是单纯“换一台机器运行”，而是重新划分职责。 迁移后的目标架构 迁移后的结构可以概括为： 也就是说，树莓派成为 OpenClaw 的主节点，桌面机只保留少量无法或不适合迁移的能力。 这种设计的好处是，主服务变得更加稳定。树莓派功耗低，适合常驻；桌面机可以继续作为高性能或图形资源节点，但不再承担 OpenClaw 主实例的核心状态。 为什么选择树莓派作为主节点 树莓派并不适合承载所有任务。它的存储容量、CPU 性能和 I/O 能力都有限，尤其不适合大型数据库、大型本地项目和图形浏览器长期高负载运行。 但它很适合承担以下角色： …