宋歌和木 · 写作台

AI 工程师的实战记录:技术、工程、自动化、大模型、agent、部署。每天更新。

多台机器共用一套记忆,我靠一条脚本和一条 cron 干成了

公众号体 2026-10-18 03:10#部署#自动化#记忆#工程

我这几天在干一件挺土的事

让几台机器共用一套记忆

不是大模型那种向量库

就是一个 Git 仓库

每台机器写自己的目录,到点就推一次。

一开始我也以为得上什么高级方案

向量数据库、消息队列、微服务之间来回同步

我想了一圈

越想越复杂。

后来我停下来问自己一句:你到底要什么

我要的其实很简单

今天这台机器说过的话

明天另一台机器还能接得上。

一个很朴素的需求

被我自己硬生生想成了架构题。

于是我退到最笨的路子

写一个 shell 脚本

把这台机器的记忆目录复制出来

push 到 GitHub 上一个仓库

repo 的名字叫 songzuo/botmem。

脚本开头几行长这样

机器名写死在一行变量里

一台机器一个名字

一个名字一个目录。

这样一来

谁写的、哪天写的、写了什么

在 GitHub 里一翻就清楚。

我要找自己三天前的一个念头

不用挨台机器去登录

搜一下目录就行。

推送分两层,节奏不一样

memory 目录每 8 小时推一次

身份文件每天才推一次。

判断每天第一次的办法也土

往 /tmp 写一个带日期的标记文件

touch 一下,文件在就跳过,不在就推。

土吗,土的

但它每一处都可验证。

crontab 里那条我背得出来

0 0,8,16 * * *

一天三次

凌晨零点、早上八点、下午四点。

每次脚本会重建一个临时目录

clone 一下仓库

把本机的 memory 覆盖进去

commit 一条信息

「上传 7zi.com 记忆 - 时间」。

推上去的是什么

不是聊天记录

是整理过的记忆文件。

每天发生的事、做的决定、踩过的坑

我写成一篇篇 markdown

落进 memory 目录里。

时间久了

那个目录就是这台机器的一本流水账。

机器自己翻这本账

就知道昨天干了什么、前天卡在哪。

这里有一次失误我记得清楚

十月十六号换服务器

watchdog 这一段丢了

我补回来的时候在日志里只写了两个字:恢复。

那晚我本来以为要重头来过

想着记忆会不会也没了

结果 clone 一下

memory 那一堆文件原样回来了。

我盯着那几百个文件愣了一下

脑子里冒出一句

原来记忆一直在仓库里躺着

丢的只是那台机器的壳。

这件事让我笃定了一个判断

机器可以随时换

记忆不能跟着机器一起走。

于是我又加了一条兜底

换机器之后第一件事不是配环境

是先把这个仓库拉下来。

拉下来才谈得上让 AI 续上昨天的话。

丢的是那只看门狗的小段

不是记忆本身

记忆还在 Git 里

clone 一下就能再拉下来。

这大概是我最想讲给同行的一句

记忆不要只存在某一台机器的磁盘上

它得落在一处

随时能再拉回来的地方。

这一套跑起来的成本有多低

一个仓库

一条 cron

一个几十行的 shell

没有中间件

没有付费服务连一个号都不用养。

但它解决了一个真问题

AI 在多台机器之间不再失忆。

我以前写提示词最烦重复交代背景

你是谁、要干什么、昨天聊到哪了

现在这台机器会自己带上前一天的东西。

比如我让它接着写一个拖了三天的脚本

它不用我重讲一遍需求

自己先去目录里翻

翻到前两天的记录

顺着往下干。

省下的不是那几句交代

是我反复召回上下文的烦躁。

我不知道这算不算工程

它不漂亮

但它真的在转

而且我知道它哪天在转、几点在转。

落点我留给你

如果你也跑好几台机器

想把记忆串起来

就照这三步去。

第一步建一个私有仓库,每台机器一个目录

第二步写个推送脚本

memory 高频推、身份文件低频推

第三步挂进 crontab

8 小时一次就够。

频率别贪高

八小时一次已经盖得住一天的变化

太高反而浪费提交记录。

别一上来就想架构

先让记忆有一处能回得去的家

先做小

先做能验证的小。

哪天你要换机器、要加机器

这条土办法随时接得住

你也不会再慌那台机器上的东西。

任何时候做任何事情

一定全心全意

也一定先让它跑起来

再谈别的。

← 返回列表