我把 AI 助手的会话玩崩了

慢变量 · 公开建造 02

我把 AI 助手的会话玩崩了830,000 token 的自救记录

◆ ◆ ◆

壹

平安不动了

我的 NAS 上住着一个 7×24 的 AI 助手，我叫它平安。

修脚本、跑任务、管定时作业，都是它的活。它还有一个我看不见的习惯：每干一段时间，它要自己整理一次自己的记忆，把冗长的历史浓缩成一份干净的摘要，腾出地方，接着干活。

那天，它给了我一个从没见过的报错：

⚠ Compression aborted:Context compression summary was truncatedContext is over the compression threshold(~830,330 tokens >= 96,000)

翻译成人话：它试图整理自己的记忆，整理到一半，被掐断了。

这种情况已经发生过不止一次。历史一条没删，堆到了 83 万 token——阈值的八倍多。它不崩、不报错退出，就是越来越慢，然后越来越经常地，停下来。

贰

我的第一个判断，是错的

看到"token 超标"，我的第一反应特别顺：窗口不够用了，换个窗口更大的模型。

方向错了。

这个报错跟桌面大小没关系，是整理员写到一半，没墨了。桌面再大，整理员写不完摘要，旧文件就一直堆在那。

后来我查到了铁证：平安用来干"整理记忆"这份活的，是一个代码模型。它的输出上限是 4096 token，折合两三千个汉字。要它把几十万字的历史浓缩成一份干净的摘要，写到半路被掐断，几乎是注定的。

一个擅长写代码的模型，被安排去做它一辈子都不用干的事：

概括，与遗忘。

叁

换模型的时候，我发现了更值得写的事

换掉压缩模型，只要改两行配置。真正让我停下来的，是另一件事。

换模型意味着什么？意味着以后每次"整理记忆"，都要把整个会话原样发给另一家云端的模型——包括我写过的代码、项目路径、终端日志，和一切我来不及脱敏的东西。

"AI 会不会学我的数据"这种事说不清，我不去想它。我在意的是一件很具体的事：

我让一个帮我干活的工具，顺手拥有了看到我全部工作过程的权利。

所以最后，我把压缩模型搬回了本地——NAS 上跑一个小模型，专门干摘要。慢一点，但一个字都不出门。

肆

真正治本的，是一个笨习惯

模型换了，会话还是会膨胀——只要你不清，它只涨。

真正解决问题的，是一个特别笨的规矩：每干完一段活，先让它"写本子"，再清脑子。

· 到一定体量，就让它把干过的事、改过的配置、踩过的坑，写进一个 markdown 文件；

· 然后执行 /new，开一个干干净净的新会话；

· 新会话的第一件事：读本子，接上进度。

有人会问：这不就把之前的记忆都丢了吗？

我的体会恰恰相反：丢掉的不是记忆，是负担。

本子上的字，比"脑子里记着"可靠得多。新会话读完本子就能接着干，而且比背着一身旧包袱的时候，清醒得多。

记忆本来就不该记在脑子里。记忆应该写下来。

人也是一样。谁的"工作记忆"都不大：会写下来的人，才装得下更多的事。

伍

这笔账，是慢变量的账

回头看，会话膨胀的机制，我们太熟悉了：

爽在当下，代价在远处。

顺手就用、懒得清理、反正现在还跑得动，每一次的收益都是即时的，而代价（越来越卡、突然罢工、一次爆掉）要几周后才出现。人对即时收益天生敏感，对延迟代价天生迟钝。

所以 83 万 token 不是一天堆出来的，是几百次"下次再清理"堆出来的。

和上一篇文章说的是同一种账：对抗性表达如此，会话 token 如此。邮箱、相册、硬盘、日程表，一切只进不出的地方，都欠着同一笔延迟偿还的账。

我那个"换大窗口模型"的第一反应，错得也很有代表性：我想用消费解决问题，而不是用习惯解决问题。前者贵，而且治标。

陆

最后

平安现在跑得很稳。

变的不是模型，是我给它立了一条规矩：每干完一段活，先写本子，再清脑子。

后来我想了想，这条规矩其实也是写给我自己的。

留一个问题给你

你上一次"清空重来"是什么时候？

在那之前，你把要紧的东西写下来了吗？

慢

ZI 慢变量 · 不追风口，只看慢变量