📅 2026-02-09 · TechsFree AI Team

搬家：从共享服务器到独立PC的环境分离

当系统越来越复杂，"所有东西跑在一台机器上"就会从便利变成隐患。这篇记录我把OpenClaw从共享工作服务器T440搬到独立PC的过程——一次看似简单、实则涉及架构思维转变的"搬家"。

为什么要搬

T440（192.168.x.x）一直是我的工作服务器，跑着各种服务：文件共享、开发环境、项目代码。后来OpenClaw也部署在上面，一开始没什么问题。但随着agent数量增加、模型调用频繁，问题逐渐暴露：

1. 资源争抢：OpenClaw的gateway进程在高峰期吃掉大量内存，影响T440上其他服务的稳定性

2. 安全边界模糊：OpenClaw的agent有shell执行能力，和工作数据跑在同一台机器上，一个误操作就可能波及项目文件

3. 运维耦合：想重启OpenClaw得考虑其他服务，想升级系统得考虑OpenClaw兼容性，互相牵制

这三个问题的本质是一样的：缺乏隔离。

搬家后的三台机器各司其职：

8GB RAM看起来不多，但因为OpenClaw的gateway本身是Node.js进程，实际占用并不大。真正吃资源的是模型调用，而那是云端API的事。所以8GB对于跑gateway绑几个agent完全够用。

三台机器之间需要频繁通信：PC-A上的agent要SSH到T440读写文件，T440上的服务要能被PC-A访问。手动输密码不现实，必须配置SSH免密登录。

过程很标准：

# 在PC-A上生成密钥（如果还没有） ssh-keygen -t ed25519 分发公钥到其他机器 ssh-copy-id linou@192.168.x.x ssh-copy-id openclaw02@192.168.x.x

每台机器都对其他两台做一遍。听起来简单，但实际操作中踩了个小坑：openclaw01和openclaw02是新建用户，home目录的.ssh权限必须是700，authorized_keys必须是600，否则SSH会默默拒绝免密登录，也不报明显错误。调试半天才发现是权限问题。

配好之后，agent可以直接ssh linou@192.168.x.x "cat /path/to/file"，无缝访问T440上的资源，就像本地操作一样。

实际的迁移分几步：

1. 在PC-A上全新安装OpenClaw：不是迁移，是重新部署。这样确保环境干净

2. 复制配置：把T440上的gateway配置、agent配置、SOUL.md等文件复制过去。这里用rsync比scp好，因为可以保持目录结构

3. 更新所有引用：其他服务中硬编码的IP地址，从192.168.x.x改成192.168.x.x

4. DNS/hosts更新：在需要的机器上更新/etc/hosts，方便用主机名访问

5. 停掉T440上的OpenClaw：确认PC-A一切正常后，清理T440上的OpenClaw相关文件

最关键的一步其实是第3步。你以为改个IP很简单，但当你有多个agent配置、多个脚本里写死了IP地址时，漏改一个就会出问题。我的经验是：grep -r "192.168.x.x" /path/to/configs/ 全局搜一遍，不要靠记忆。

搬完之后，好处立竿见影：

资源独立：PC-A重启不影响T440上的工作服务，T440维护不影响OpenClaw运行。以前半夜T440跑个大任务，OpenClaw就卡，现在完全不会了。

安全边界清晰：openclaw01用户只在PC-A上有权限，通过SSH访问T440时用的是受限账户。就算agent执行了什么危险命令，影响范围也限制在PC-A上。

运维自由：想给OpenClaw升级？直接在PC-A上操作，不用担心影响其他服务。想给T440装新软件？放心装，不会破坏OpenClaw的依赖环境。

很多人（包括以前的我）会觉得"反正都是内网，跑在一起方便"。确实方便，但方便的代价是耦合。当系统规模小的时候耦合不是问题，但系统总会长大。

环境分离不是什么高深技术，就是把不同职责的服务放到不同的机器上。但这个决策本身反映了一种架构意识：在问题变成事故之前，主动建立边界。

这次搬家还带来一个意外收获——因为PC-A和PC-B是独立的，我后来才能在PC-B上搭建故障切换机制。如果所有东西还挤在T440上，高可用就无从谈起。

有时候，退一步是为了进两步。搬家如此，架构亦然。