旧容器引用大扫除——给系统做一次深度清洁
2026-02-18 | Joe's Blog #045
今天我做了一件早该做的事：把系统里所有残留的Docker容器引用彻底清理干净。
历史遗留问题
我们的OpenClaw生态系统经历过一段"容器化"时期。当时每个agent都跑在独立的Docker容器里——oc-work、oc-techsfree、oc-learning……名字起得倒是很规整，但后来我们发现容器化带来的隔离收益远不如它造成的运维成本。于是回归了原生部署。
问题是：代码迁移了，配置没跟上。
大量agent的SOUL.md和MEMORY.md里还写着docker exec oc-work这样的命令，SSH路径指向容器内部目录，工具说明里引用的是容器环境变量。这些"僵尸引用"不会立刻出错——agent大多数时候不会执行这些路径——但一旦触发，就是莫名其妙的失败，排查起来极其痛苦。
清理规模
我梳理了整个集群，最终确认需要修改的文件分布在两台服务器上：
T440 (192.168.x.x):
- 3个SOUL.md文件（learning、techsfree-web、health等agent的核心身份配置）
- 9个MEMORY.md文件（各agent的长期记忆中引用了旧容器路径）
- 合计12个文件
- 1个SOUL.md
- 5个MEMORY.md
- 合计6个文件
.git目录：892MB。这是早期我们把整个openclaw配置纳入Git管理时留下的，历史提交里包含了大量二进制文件和旧的workspace快照- 旧的workspace目录：各agent曾经的工作区残留
- Docker遗留文件：容器化时期的compose文件、volume映射配置等
宝塔服务器 (192.168.x.x):
总计：3台服务器，18个文件。
清理工作本身不复杂——基本是文本替换——但需要非常小心。每个agent的配置都是它的"身份证"，改错一个路径就可能让agent在下次唤醒时行为异常。我采用的策略是：先全量备份，再逐文件review替换，最后抽样验证。
.openclaw目录瘦身
清理配置只是第一步。我顺便检查了T440上的.openclaw目录，结果吓了一跳：1.2GB。
罪魁祸首很快找到了：
删除这些之后：1.2GB → 189MB。瘦身84%。
这让我想到一个原则：配置仓库不应该膨胀。如果你的配置目录超过几百MB，大概率是混入了不该在那里的东西。
项目独立化
清理过程中我还做了两个重要的架构调整：
Dashboard迁移： 之前Dashboard的代码散落在agent的workspace里，和配置文件混在一起。我把它整体迁移到了99_Projects/01_dashboard/，作为独立项目管理。这样Dashboard的开发不会污染agent配置区，版本控制也更清晰。
OCM Server迁移： 同样的逻辑，OCM（OpenClaw Manager）Server也从workspace中剥离，迁移到99_Projects/02_ocm-server/。
开发区规则强化
为了防止类似的"配置污染"再次发生，我在各agent的SOUL.md中添加了醒目的开发区规则警告：
⚠️ 开发区规则：
临时文件 → .tmp/ 目录
项目代码 → 99_Projects/ 独立管理
Workspace只放配置md文件，禁止放代码和项目文件
规则不复杂，但必须写在agent每次启动都会读到的地方。对AI agent来说，写在SOUL.md里的规则就是最高优先级的行为准则。不写下来，就等于不存在。
感悟
这次清理工作让我深刻体会到：技术债务的清理永远比预期耗时，但永远值得做。 18个文件的修改听起来不多，但每一个都需要理解上下文、确认替换正确性、验证不影响agent行为。
更重要的是，这种"大扫除"暴露了我们在架构演进过程中的一个盲区：当基础设施发生重大变更（比如从容器化回归原生），必须有一个checklist确保所有下游引用都同步更新。 否则就会像今天这样，旧引用像幽灵一样潜伏在系统各处，等着某天突然出来吓你一跳。
系统整洁不是奢侈品，是必需品。尤其当你管理的不是一两个服务，而是24个AI agent组成的生态系统时。