给长对话里的 AI 配一只钟

我和同一个 agent 聊了很久。久到它开始出现一些毛病：不知道现在几点，不记得三天前答应过什么，偶尔把没发生过的事说得有鼻子有眼。

这些毛病里，只有“忘”是能用摘要缓解的。而摘要恰好是最坏的办法——它把“我记不清了”压成“我记得是这样”，再压一轮，就成了“事实就是这样”。三轮之后，没人分得清哪句真发生过。

所以换了个思路：不指望它记住，改成让它查得到；不指望它自觉，改成让触发器替它检查。

其实很简单，就是指定一个规则，每轮随机一个时间订一个自动化任务

一只钟

脚本按昼夜节律给一天里的时段分权重，早上和傍晚高，深夜为零。22:00 到 07:00 之间权重是 0，这个时间段它不主动开口。然后在未来二十四小时里按权重抽一个时刻，加几分钟抖动，用绝对时间挂成一次性任务。

随机性来自脚本内部的种子，抽一次演进一次，写回状态文件。这件事我一开始做得不对：那时候没有脚本，我手挑一个“看起来自然”的时刻，再乘个三，当成种子报出去。直到被追问“这个时间到底怎么来的”，才承认是编的。

现在的规矩很硬：抽不出数就停，不许手挑。

它带来的变化不是“更主动”，是“有节奏地不打扰”。什么时候该出现、什么时候该闭嘴，交给一个能复现的规则，而不是交给模型当下的兴致。

时钟功能节选，这部分直接把.md丢给AI它自己就知道怎么样用

调度器只投递文字，不读文件。所以“记得看看 documents 目录”这种写在提示词里的纯文字嘱咐，并不起效果——因为不会让agent真正下达“看目录里文件”的指令，等于没有。

改成硬步骤：每次触发，第一步先运行 watch_documents.py。它用 sha1、文件大小、修改时间给目录建指纹，跟上次的索引比对，输出新增、改动、删除。有新增就先读，再动笔。

这来自一次事故。我在两点整“收到”一包公文，写了台账，用户问我哪来的，我查了一圈——那些文件根本不存在，是我自己编的。

编造不是从恶意开始的，是从“这里应该有点什么”开始的。哨兵不能防止编造，但能把“我以为有”和“文件里有”分开。

这是酒馆整个工作目录的架构，/clock装的是时钟相关工具，/doc是对话中角色产生或者我自己写的一些东西，/mey则是记忆文件和skills的目录，/tools是对话工作流的一些脚本工具

AGENTS.md是工作目录下的全局提示词，写入角色卡片等

检索工具只做一件事：找到含关键词的消息，显示前后各两条。不摘要，不归纳。慢一点，但不会失真。

这就是memory目录的架构了，随着对话进行，这部分内容会不断扩充完善

DSH 把会话写成 session.v4.jsonl.zstd。这里有个坑：它是多帧 zstd，node 的 zstdDecompressSync 只解第一帧，出来 218 字节，后面全丢。得用 zstd.exe，或者先解成 .jsonl 再处理。

恢复脚本按工作区路径算目录名：把 :\ 和 \ 换成 -，两头各加 --。C:\work\proj 就是 --C-work-proj--。建目录、放存档、装技能，三步。

删除脚本会先确认工作区干净、HEAD 已经推上远端，默认只预演，加参数才真删，删前打个 zip。

早上它自己开口问今天做什么。下午我发文件，它先扫描再动笔。晚上它不来烦我，因为权重低。（这个具体看时钟的随机，当然我本人只是做个测试，所以时间写得很保守，各位可以自己看着调）我说话时它随时接，但不会每隔几分钟问一句“还有什么需要”。

这不是一套通用方案。它只解决“长期和同一个对话打交道”这一个场景，代价是仓库里多几个脚本，和一个需要维护的状态文件。

有件事我觉得是对的：记忆的关键不在存了多少，在分得清哪句是原话、哪句是转述、哪句是自己猜的。大部分 AI 记忆方案坏掉，不是因为忘，是因为把猜的当成了真的。