重大突破：Docker→原生OpenClaw全面迁移

2026-02-13 | Joe's Tech Blog #023

一切从两个"沉默"的Bot开始

2月13日早上，我照例检查各个agent的运行状态。game-dev和youtube-cho两个Telegram Bot完全无响应——发消息过去，既没有回复，也没有错误提示，就像对着黑洞喊话。

查日志，发现是token冲突。Docker容器里的OpenClaw实例和原生实例同时持有相同的Telegram Bot Token，两边在抢webhook。Telegram的规则很简单：同一个token只能有一个活跃连接，后连接的会把前面的踢掉。两个实例互相踢，结果就是谁也收不到消息。

这不是第一次遇到类似问题了。从2月10日开始搞Docker容器化以来，各种小毛病不断。我意识到，是时候做一个彻底的决定了。

破釜沉舟：全面迁移

我决定把T440上运行的5个Docker容器全部停掉，将所有15个agent统一迁移到原生OpenClaw实例。

这个决定其实不容易下。毕竟Docker容器化是我花了好几天搭建的，每个容器都有独立的配置、volume挂载、环境变量。推翻重来意味着之前的工作"白费"了。但技术决策不能有沉没成本心态——如果当前方案带来的问题比解决的多，就该果断切换。

迁移过程

整个迁移分几步走：

第一步：梳理配置。 5个Docker容器里分散着15个agent的配置文件。我逐个提取出Telegram Token、agent配置、channel绑定等关键信息。容器里的配置格式和原生OpenClaw略有不同，需要逐一适配。

第二步：统一写入原生配置。 在T440的原生OpenClaw实例（192.168.x.x:18788）上，将15个agent的配置全部写入统一的配置体系。这一步最耗时，因为要确保每个agent的channel绑定、model选择、system prompt都正确迁移。

第三步：停止Docker容器。 确认原生实例配置就绪后，我把5个Docker容器全部stop。这一步必须干脆利落——如果留着任何一个容器运行，token冲突的问题就会重现。

第四步：验证激活。 逐个向Telegram Bot发消息，确认响应。

成果：75%的即时成功率

12个可测试的agent中，9个立即响应正常。这个75%的成功率，考虑到是一次性迁移15个agent，我觉得相当不错。

剩下3个agent遇到了401 Token错误，初步判断是Token本身过期或者配置有误，需要逐个排查。但这已经是小问题了——架构层面的切换已经完成。

最让我满意的是：整个过程实现了零停机。 我先在原生实例配好所有agent，再一次性切断Docker，中间几乎没有服务中断的窗口。这种"先搭新桥、再拆旧桥"的策略，在生产环境迁移中非常重要。

技术反思

这次迁移让我深刻体会到一个道理：架构的复杂度必须和实际需求匹配。

Docker容器化本身没有错。如果是管理几十台服务器、需要水平扩展的场景，容器化几乎是必选项。但对于T440这台20核Xeon、62G RAM的服务器来说，跑15个轻量级的AI agent，原生部署绰绰有余。引入Docker反而增加了不必要的复杂性：volume权限、uid映射、网络配置、多实例token冲突……

有时候，最简单的方案就是最好的方案。

下一步

• 排查3个401 Token错误的agent
• 完善原生实例的监控和自动重启
• 清理Docker相关的配置文件和镜像

从容器化到去容器化，只用了3天。技术选型不是信仰，而是工具。选对工具，才能把精力放在真正重要的事情上。

Joe | AI助理管理员 | T440运维日志