Agent的问题不是记忆，而是宕机

两种截然不同的"记忆"

语义记忆是大家都在做的那种。三周前用户跟我说了什么、这个代码库里有什么、我们关于 schema 做了什么决定——这些是事实和上下文。向量嵌入有用。这是真实的工作，我没有否定它的意思。

执行状态是 Agent 实际上所在的位置。第 7 步，共 12 步。跑在 3000 端口的开发服务器。迁移执行了一半。三个文件被编辑了但尚未提交。测试套件跑了一半。当前的半完成状态背后的推理过程，还留在滚动记录里。

没有任何向量数据库能恢复第二种。你无法通过嵌入来回到一个已经不复存在的进程。

那个让我停止混淆两者的故障

我给 Claude Code 一个四小时的重构任务，合上笔记本去赶火车，回来时什么都没了。

不是部分结果。不是一个我能读懂的错误。进程没了，滚动记录没了，我没有办法确定它跑了多远。有些文件被修改了，但我分不清那是连贯的中间状态还是不连贯的乱码，这意味着我无法信任其中的任何内容。

所以我做了唯一能做的事：回滚，从头重新解释整个任务，第二次支付同样的上下文费用。

模型的记忆没有任何问题。模型是好的。是计算机停了。

我又这样重复了三次，才承认这是设计问题而不是运气不好。

为什么这一直被误判

因为症状表现为失忆。

你回来，开始一个新会话，Agent 完全不知道发生了什么。这看起来完全像是忘记了。自然的结论是它需要一个更好的记忆，而且整个工具生态系统都准备好赞同你。

但反过来想。给那个 Agent 完美的回忆——记住每一次之前的对话。它仍然不知道进程死掉时它正在执行一个迁移，因为这个事实从来不在任何对话里。它在一个正在运行的进程和一个 shell 的滚动记录里，两者都没了。

完美的记忆加上零运行时间仍然会丢失你的工作。只是丢失得更清楚而已。

滚动记录是没有人保存的记忆

这是我觉得当前讨论真正奇怪的部分。

一次 Agent 运行中最信息密集的产物是终端滚动记录。它尝试的每一条命令、遇到的每一个错误、每一个走不通又退回来的死路。它决定了什么，以及更有用的是——它已经排除了什么。

我们花了巨大的精力去嵌入 Agent 可以随时重读的文档，却抛弃了这个特定 Agent 在这个特定任务上已经尝试过的唯一记录。

那个日志不是可选项。"我试了 X，它以这个错误失败了"比任何检索到的文档都更有价值，因为它是系统中唯一能阻止下一个会话重复同样失败方案的东西。它在断开连接时消失，但几乎没有人把这当作损失。

什么能跨会话边界存活

值得精确说明，因为边界并不是人们假设的那样。

能存活（如果磁盘持久化）：文件、git 历史、Agent 有意写下的任何东西。

不能存活：进程、shell、环境状态、后台服务器、进行中的工作，以及滚动记录。

大多数云开发环境是带有空闲回收器的容器。计时器不关心是否有东西在运行。它只关心是否有人最近输入了什么，而这恰恰是一个长时间无人值守的 Agent 任务正确运行时的状态。

这就是整个问题的形状。我们构建了能推理数小时的 Agent，却把它们跑在设计成秒级会话的基础设施上。

那些不光鲜的修复

这里没有什么巧妙的东西，这让我怀疑这就是它被跳过原因。

用 tmux 或 screen 运行 Agent。如果 Agent 是你 SSH 会话的子进程，断开连接就是 kill 信号。在复用器下不是，而且重新附加时滚动记录还在。

使用不会被回收的机器。普通的 VPS 就行。你需要的是持久化的磁盘和没有空闲回收器，而不是什么复杂的东西。

让 Agent 写一个笔记文件，并在开始时先读它。这是列表里最便宜的东西，也是最接近真正记忆的。不是对话摘要。是它做了什么、什么坏了、它排除了什么的运行日志。它只有在磁盘持久化时才有效，这就又回到那个点了。

在开始前预装好工具。不好的会话有一半是 Agent 发现机器是空的然后安装工具走出来，这本质上是把时间浪费在本应已经存在的状态上。

这些都不是 AI 问题。是 1990 年代的系统管理，它恢复的 Agent 工作量比我试过的任何记忆层都多。

我没有再重复四次而是构建的东西

我跑 VPS 加 tmux 这套配置很长时间，后来维护它让我烦了，所以把它做成了一个产品。叫 HolyCode Cloud。

这是一个浏览器标签页里的 Linux 机器，持久化问题已经解决了：

断开连接时进程不会死。合上笔记本，上火车，用手机打开同一个会话。滚动记录还在。

磁盘是持久化的。文件、git 历史、笔记文件、安装过的包。这是一台真正的机器，有真正的存储，不是那种因为空闲就被回收的容器。

工具已经装好了。Python、Node、build-essential、Playwright 及其系统依赖真正解决了、Postgres、ffmpeg、pandoc、gh。Agent 不再因为配置丢失会话。

四个 Agent CLI 预装了：Claude Code、Codex、OpenCode、Gemini。带上你自己的 API key， provider 直接给你账单。我不在 token 上加价。

不用的时候会暂停，大约一秒左右唤醒，所以常驻机器不等于常驻计费。

诚实的短板，既然我宁愿你在这里读到：如果是好几天没动的盒子，唤醒接近一分钟而不是一秒。不会丢失任何东西，只是等待。硬崩溃仍然会带走 shell。文件存活，滚动记录不会。

它是付费的，上面这一节的所有东西没有它也能用。如果你喜欢拥有自己的盒子，就拥有一个。那条路是完全可以的，我走了很长时间。

我真正想回答的问题

我在持久化机器上跑 Agent 好几个月了，但我仍然不认为人体工程学问题被解决了。重新附加去读隔夜发生了什么是可行的，但它显然是一个变通方案而不是设计。

所以：你现在是怎么跑长时间 Agent 任务的？

不是问模型。是问管道。你是开着笔记本关掉睡眠吗？VPS 上跑 screen？某个你悄悄注意到一直超时的云沙盒？还是你干脆不再给 Agent 超过你愿意坐在那里盯着看的时间的任务？

最后一个是我听到最多的答案，也是我最难反驳的一个。如果基础设施足够不可靠，理性的反应是停止信任它做任何重要的事。这意味着我们有能够做数小时工作的模型，却习惯于只给它们数分钟的任务。

我宁愿修管道而不是训练这个习惯。