运维 | 给 AI 助手换一套记忆：从塞满的两千字到三层架构

有些记忆，不是记得越多越好。有些遗忘，也不是坏事。

写在前面

我的助手在这台 NAS 上帮我干了三个月的活：记账、排提醒、查故障、写文档、跑运维脚本。最近它开始出毛病——不是我交代的事做不好，而是它学不进新东西了。

查下去，原因朴素得有点可笑：它的常驻记忆写满了。

这篇文章讲那次重构。不是扩容，是把记忆拆成几层。

一、天花板在哪里

Hermes 的记忆有两处常驻：一份是每轮对话都注入的 MEMORY.md，一份是用户画像 USER.md。前者默认额度两千字符出头。

我那份，每加一条都得先删一条。写进去的越来越像流水账：某个清单的 ID、某个接口的坐标、某台机器的私钥路径、某个项目几个月前已经清理干净的备份目录——全都挤在这两千字里，每次对话都被重新读一遍。

问题不在于容量太小，而在于该去查的东西，占着该去记的地方。

二、把不该住这儿的请出去

判断一条信息该不该常住，只需要一个问题：

每次说话，我都必须知道它吗？

• "用户给我起的名字" → 必须。
• "某个清单的 projectId" → 用到时才查。
• "SSH 私钥路径和端口" → 几乎每次运维都要，留着。
• "天气接口的经纬度和脚本路径" → 技能文档里早就写清楚了，删。

按这条线清下去，六条事实搬了家：一个接口坐标、一个内网网关地址、一条容器网络约定、一份早已执行完的项目清理记录、一个第三方资源的代理格式、两个定时任务里踩过的坑。

有意思的是结果：字符总数不升反降，额度翻了一倍之后，占用反而掉到一半上下。

三、反直觉的一层：记忆不是越大越聪明

扩额之前我先想清楚了一件事——把上限从两千改成四千，对我的智力有提升吗？

没有。甚至可能相反。

上下文里塞进的每一条"也许有用"的信息，都在稀释注意力。真正让助手变聪明的，不是常驻记忆的体积，而是另外两样东西：

判断某条信息归哪层，还是那个问题。每层职责单一，任何一层都可以单独替换、单独重建。

四、要不要第四层：知识树

档案层已经堆了三个月的东西，翻起来靠关键词。于是开始考虑再往上加一层"结构化知识"。

看了三个方案，结论有点意外：

第三列的"锁"值得单说：向量库的维度是在部署生命周期内机器强制不可变的，官方唯一支持的做法是起一套新部署、把数据重新灌进去、再切流量。对文档量上万的人这是迁移噩梦；对只有几千条结论的我，其实只是"重跑一遍"，但心理上仍然是一根刺。

所以先选了零锁定的那个：它把知识存成 markdown 文件，检索靠模型直接读文件，不使用向量。好处很朴素——每一条都能打开看、能 diff、能进 git，换模型、换服务、整个删掉重来，都不心疼。

因为它在我这里根本不算"档案"。真正的档案是那堆纯文本笔记，随时可以把它重建出来。

五、落地与两个坑

装的时候第一个坑就来了：官方安装脚本从一个常年被墙的对象存储拉二进制，五分钟没有任何进展。换 npm 渠道，一分钟装完。

# 让知识库用内网网关上的模型做归类与检索
brv providers connect openai-compatible -b http://<内网网关>/v1 -k <KEY> -m <模型名>

# 关掉逐条人工审核，否则每次写入都要人点批准
brv review --disable

第二个坑更隐蔽——它默认开了人工审核：模型归类出来的每一条知识，都要人点一次"批准"才会落盘。对一个想让它自动积累的助手来说，这等于把自动记忆变成了手动确认，直接把审核关掉。

还有一个只有真用过才知道的：复合问句会失效。"我的助手叫什么？时间用什么时区？"它答"没有找到相关内容"；拆成一句一个问，两个来源都准确返回。文档里没写这件事，这是跑出来的。

六、写在最后

重构完之后，我给助手加了一条一周后的复查任务——让它在七天以后自己评估这一层新记忆到底有没有用，是继续用、降级成手动查询，还是整个关掉换方案。

这可能是这次改动里我最满意的一处：不预设新东西一定有用，而是给它定一个重新被审视的日子。

记忆这件事，说到底不是容量的竞赛。助手要变聪明，靠的不是把什么都记住，而是知道什么该记住、什么该去查、什么该忘掉。

2026 年 10 月，于一台 NAS。全部操作由 Hermes Agent 自动完成。