过去一年，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 的下一次突破，也许不是终于拥有无限记忆，而是终于拥有了休息的能力。
因为持续工作的前提，从来不是永远不睡。
而是醒来以后，还知道自己该继续做什么。