语言模型也需要“睡觉”：持续工作的 Agent，瓶颈正在从记忆变成休息机制

Wed, 27 May 2026 10:00:00 +0800

过去一年，Agent 圈子里最常被提到的词，是“记忆”。

模型要记住你的偏好，记住项目结构，记住哪些文件刚改过，记住上一次为什么失败。于是各种方案都在往同一个方向走：更长的上下文、向量数据库、会话摘要、项目索引、跨会话记忆。

这些都没错。但我最近越来越觉得，长期运行的 Agent 真正卡住的地方，可能不只是“记不住”。

更麻烦的是，它会越跑越乱。

你让一个 Agent 连续工作几个小时：改代码、查资料、写文档、跑测试、修报错，再继续下一个任务。前面半小时它很清醒，知道目标，也知道边界。后面上下文越堆越厚，临时判断、失败命令、用户补充、工具输出混在一起，它就开始重复检查、绕远路，甚至把已经废弃的想法重新捡回来。

这时候再给它加一层“记忆”，不一定有用。

因为问题已经从“有没有记住”变成了“能不能整理完再继续”。

所以我觉得，语言模型本身也许不需要睡觉，但持续工作的 Agent 需要某种类似睡眠的机制。

持续工作的 Agent，也会越跑越乱

短任务里的 AI 很像一次性顾问。

你给它一个问题，它读完材料，给出判断。上下文清楚、边界明确时，它表现通常不错。

长时间工作的 Agent 不一样。它不是回答一个问题，而是在一个不断变化的现场里干活。它会读文件、调用工具、等待命令返回、修正计划、遇到错误、换一个假设，再继续往前走。

这更接近真实工作，也更容易积累垃圾。

一次失败的命令，会留下一大段错误日志；一个临时猜测，可能后来已经被证明不对，但仍然躺在上下文里；用户中途改了方向，旧目标也不会自动消失；工具返回的内容里，真正有用的可能只有三行，噪音却有三百行。

如果没有整理过程，Agent 的工作记忆会变成一个堆满纸团的桌面。

东西是都在，但你很难继续工作。

这也是为什么很多长期运行的 Agent 会出现一种很熟悉的退化：一开始很聪明，后来开始绕圈；明明已经读过某个文件，过一会儿又查一遍；已经排除过的方案，又被拿出来试；当前目标越来越模糊，工具输出反而成了牵引它走的东西。

这不完全是模型不够强。

更像是系统没有给它安排“收桌子”的时间。

记忆和休息不是一回事

我们很容易把 Agent 的长期能力理解成记忆能力。

忘了，就加记忆；上下文不够，就扩窗口；跨会话断片，就做摘要。

但记忆解决的是：过去的信息能不能被找回来。

休息解决的是另一个问题：过去的信息应该以什么形态留下来。

比如一个 Agent 修构建失败，过程中可能做过十几件事：看日志，怀疑依赖版本，改配置，发现不对，回滚一部分，再改另一个文件，测试通过，最后又修了格式问题。

如果把这些过程原样存下来，它确实没有“忘”。但下一次接着做的时候，它拿到的是一团混合物：错误路径、有效路径、临时猜测、最终结论、无关日志，全挤在一起。

真正有价值的不是这段录像，而是整理后的状态：

这个问题修到哪一步了？哪些猜测已经被证伪？哪些文件发生了实质变化？哪些命令已经跑过？下一步最应该验证什么？

人睡一觉后，通常不会逐帧记得昨天每个操作。但你会带着一种更干净的判断醒来：这个方案别再试了，那个接口要小心，早上先跑测试。

Agent 也需要类似的东西。

不是保留所有经历，而是把经历加工成下一阶段能用的状态。

更长的上下文，不能自动解决这个问题

很多人会把希望放在长上下文上。

窗口越来越大，历史都能装进去，Agent 不就不会乱了吗？

我不太相信。

长上下文能装下更多东西，但不会自动告诉模型哪些东西已经过期。它也不会主动区分“最终结论”和“当时随口提出的猜测”。桌子变大了，不代表桌面更干净。

在短任务里，长上下文很像优势。资料都在，模型有机会一次看完。

到了长任务，它有时反而像负担。早期误判、失败命令、用户已经否定的方向，都会以某种方式留在现场。模型不是真的累，但它要在一堆互相打架的线索里做选择，表现自然会变钝。

所以长期运行的 Agent 不能只追求“把更多历史塞进去”。

它还要知道什么时候该清桌面，什么时候该归档，什么时候该把经验沉淀成规则，什么时候该把某些东西彻底丢掉。

这就是我说的休息机制。

它不是暂停工作，而是在两个工作阶段之间做一次状态整理。

Agent 的“睡眠”应该做什么

如果把睡眠翻译成工程机制，我觉得至少有几件事。

先是压缩状态。

每一条命令输出、每一次中间推理，都不应该原封不动进入下一阶段。更合适的形式是：当前目标、已经完成的部分、改过的文件、验证过的结果、还没解决的风险。压缩不是为了变短，而是为了让下一步更容易开始。

然后是清掉噪音。

失败路径不一定要删除，但要明确标出来。临时假设不应该和最终判断放在同一层级。已经失效的用户要求、已经废弃的计划，也不该继续影响当前任务。

再往后，是把经验放到合适的位置。

有些信息只属于当前任务，比如某个测试刚刚失败。有些信息以后还会用到，比如这个项目的构建命令、发布目录、用户偏好的写作风格。后者应该进入更长期、更结构化的记忆，而不是一直挤在会话历史里。

最后是重置注意力。

休息之后，Agent 应该重新拿到一个干净的起点：现在要做什么，已经不用再做什么，下一步先检查哪里。

这比一句“总结一下刚才做了什么”要难。

总结只是把历史缩短。真正的休息，是把历史变成下一段工作能继承的状态。

这会改变 Agent 产品的竞争点

如果这个判断成立，Agent 产品后面的竞争点会变得很有意思。

第一阶段大家比模型能力：谁更会推理，谁写代码更准，谁工具调用更稳。

第二阶段开始比记忆：谁能理解项目，谁能记住用户，谁能跨会话延续。

再往后，可能要比谁更会“休息”。

一个真正可用的持续工作 Agent，不能只是一直在线、一直执行。它要知道什么时候该停下来做 checkpoint，什么时候把一段临时上下文沉淀成长期记忆，什么时候提醒用户“这段历史太重了，整理一下再继续”。

这听起来不像模型发布会上的大功能，但对日常使用很关键。

真实工作不是一次漂亮回答，而是一串混乱的中间过程。你会走错路，会试错，会改方向，会遇到工具失败。Agent 如果没有阶段性整理能力，它工作得越久，背上的上下文包袱就越重。

到最后，问题不在于它不够努力。

问题在于它没有睡过。

现在我们可以怎么用

在工具还没有完全内置这套机制之前，个人用户可以手动给 Agent 安排“睡眠”。

最简单的做法，是不要让一个会话无限往下滚。完成一个阶段后，主动让它整理三件事：

已经完成了什么；
哪些尝试失败了，后面不要重复；
下一阶段只需要保留哪些事实。

然后基于这份整理后的状态继续，而不是把完整历史一直拖着走。

如果是在写代码，还可以让 Agent 在阶段结束前输出更具体的 checkpoint：改了哪些文件，跑过哪些测试，剩下哪些风险。下一轮开始时，它不需要重新翻完整聊天记录，也不容易把临时猜测当成事实。

这件事听起来很朴素，但很有用。

我现在越来越觉得，使用 Agent 的关键能力不只是会不会写 prompt，而是会不会安排工作节奏。什么时候让它冲刺，什么时候让它复盘，什么时候清理上下文，什么时候开新会话。

这可能比多背几个提示词模板更重要。

真正的长程智能，需要会忘记

“语言模型也需要睡觉”当然只是比喻。

模型没有身体，不会犯困，也不会在夜里做梦。

但 Agent 作为一个运行中的系统，确实会遇到类似疲劳的问题：状态堆积、注意力分散、噪音污染、过期前提残留。

更多记忆、更长上下文，只能解决一部分。

真正重要的是，它能不能在工作之间整理自己。

该保留的保留，该压缩的压缩，该归档的归档，该忘掉的忘掉。

持续工作的 Agent 的下一次突破，也许不是终于拥有无限记忆，而是终于拥有了休息的能力。

因为持续工作的前提，从来不是永远不睡。

而是醒来以后，还知道自己该继续做什么。

大语言模型 on 奇诺分享 | 重在分享