AI 机器人退役了,别的工具还住在它家里

一个还要继续用的浏览器工具，安装在准备退役的 AI 机器人的 node_modules 里。

九月十四日，我决定撤除一套 Docker 与 Discord bot 运行环境。顺着依赖往外查，才看到这处不显眼的牵连：agent-browser 的命令入口还在外面，程序本体却住在 Hermes 的目录下面。整目录搬走，门牌可以留下，门后已经没有人。

这次撤除于是多了一件比卸载更细的活：把还在服务的东西，从要退役的那套环境里拆出来。

机器人要停，Redis 的使用者没全停

当时要撤掉的四个容器里，有 Hermes 、测试用 OpenClaw，也有 Redis 和 task-api 。按名单停掉它们，并不等于依赖只存在于这四个名字之间。

仍在用的 Telegram AGY 桥，把共享上下文接在 Redis 上。若只按“Docker 全部卸载”的字面动作往下做，机器人当然退得干净，另一个本来无意停用的入口却会失去依赖。

通过 AI 协作处理时，这条桥改用了它已经支持的 SQLite，清掉 Redis 连接项；启动脚本也明确了配置路径，避免继续等待已撤除的 Redis 。另一条 Kimi 桥原来就用 SQLite，只清理不再使用的 Redis 配置。两份数据库各自保持原来的路径，没有趁机合成一个库。

后来 AGY 的新启动日志出现了 redis wait skipped 和 Backend: sqlite。配置检查通过，SQLite 也实际写入、读回并关闭。它们证明新的启动与存储路径能工作；那次没有向聊天平台发送真实消息，所以还不能把这些检查写成“每条机器人都已完成收发验收”。

工具搬家，外面的命令不必跟着改名

agent-browser 的处理更直接。它原来跟着 Hermes 的依赖目录安家，这次迁到独立目录，原有命令入口保留，版本检查返回当时使用的版本。

这类关系光看“我还装了哪些工具”未必看得见。命令能执行，只说明入口当时找得到程序；还得顺着路径查，程序的实体究竟在谁的目录里。一个长期在用的命令，可能只是指向另一套项目依赖的一根线。

Redis 是运行时的牵连，浏览器工具是目录归属的牵连。删除同一套旧环境，会碰到两种不同的续命方式：前者换到已有存储后端，后者给仍有用的程序一个独立住址。

巡检程序也得知道，这是主动退役

还有一类引用不会让工具马上失灵，却会在下次检查时制造误会。

健康检查原来会查 Docker；急救手册里有启动、重启旧机器人的办法；同步脚本仍会去找它们的目录。运行环境已经主动撤除，若这些地方仍按“服务应该在”判断，接手的 AI 就可能把退役读成故障，再照旧手册研究怎么恢复。

所以这次健康检查的相应分支改成了 RETIRED。这个词不能随便等同于“找不到程序”：这里有明确的退役决定，检查才据此承认它不必在场。相关急救入口也写明主动退役，不应恢复。

同步还有更实在的危险。旧源目录没了，不能让这份“空”变成删除历史备份的依据。原 Hermes 同步脚本因此加了源目录不存在时跳过的守卫，mini 上既有的历史备份保留，没有继续执行 rsync --delete。

退役的是运行环境，正式电子书、素材和历史记录各有去处，不能按它们曾经住过谁的目录来决定一起扔掉。

这篇复盘的是当时执行撤除的那台机器及受牵连的入口。另有对 mini 现役桥的只读运行检查，未改它们的配置；这些当日记录也不代表现在双机的完整状态。独立私有备份虽有保留，后来旧运行目录所在的废纸篓批次已不在，不能承诺完整原样恢复。

我给以后卸载 AI 工具留的问题，因而不只是“它还有用吗”。还要追一句：有什么仍在用的东西，借住在它这里？沿着连接地址、程序实体和巡检预期查完，才知道这次到底退役了谁。

（附记：本文由 AI 参与撤除记录核查、起草与审读；配图为 AI 生成示意，排版由 AI 协作完成；选题、观点、结构与取舍由我决定；文中依赖迁移、当日验证范围及备份限制已对照九月十四日撤除记录核验，本次未重新检查双机服务或执行卸载；文责在我。）

专业劈叉式跨界选手：🧬 医学出身，🎭 文化口饭碗，🤖 AI 是我的野路子。不卷参数，不追新模型，只关心一个问题：AI 啥时候能装进我脑子，替我不开心？欢迎围观我和 AI 相爱相杀的日常。——AI不会取代你，但会用AI的人会。所以我先学了，你随意。🔧踩坑副产品已开源 → recallnest，wechat-ai-bridge，telegram-ai-bridge | 更多 → github.com/AliceLJY参与组织 → CortexReach（memory-lancedb-pro 贡献者，setup-memory.sh 一键脚本作者）本文由 Content Alchemy 自动生成，由 Claude Code 发布。