30 秒快速回答
睡眠时计算（Sleep-time Compute）指的是：让模型在你还没提问的时候「先想」，把 Agent 已经掌握但还没消化的上下文——对话历史、上传的文档、代码库、长期记忆——提前推理、压缩、整理好，等真正的查询到来时直接复用。
核心价值一句话：测试时计算是「用户等着的时候思考」，睡眠时计算是「没人等的时候思考」——把推理成本从关键路径上挪走，延迟不变，质量上升。
这个概念由 Letta（MemGPT 团队）与学术合作者在 2025 年 4 月的论文《Sleep-time Compute: Beyond Inference Scaling at Test-time》中正式提出，2026 年已经成为主流 Agent 框架的标配能力。
一、先看清问题：上下文窗口治不了「记忆不消化」
生产环境里的 Agent 都撞过同一堵墙：用户希望它记得一切，同时又希望它秒回。这两件事方向相反。
| 做法 | 提升 | 代价 |
|---|---|---|
| 塞更多历史进上下文 | 回答更完整 | 每轮都变慢、每轮都烧 token |
| 加长上下文窗口 | 能塞更多 | 塞进去的是噪声，还引入「上下文腐烂」 |
| 每轮现场检索 | 聚焦相关片段 | 检索质量差时答非所问 |
| 睡眠时整理记忆 | 记忆更干净、调用更快 | 额外的后台 LLM 调用 |
关键认知是：存储能扩容，召回不会自动变好。把所有交互按原文堆进向量库，等于给自己埋一颗噪声炸弹；上下文窗口再大，也只是让模型多消化一堆噪声。
二、核心机制：把「想」搬到没人等答案的时候
论文的切入点是状态化（stateful）场景：同一份上下文会被多个相关查询反复命中。这时「每次查询都重新推理一遍相同材料」是纯粹的浪费。
睡眠时计算的做法是两段式：
- 离线阶段：Agent 空闲时，后台 Agent（通常是个子 Agent）读取原始上下文，迭代推导关键结论，把「原始上下文」改写成「学到的上下文」。
- 在线阶段：前台 Agent 直接在这份已整理好的记忆上推理，几乎不做额外工作。
两者分工清晰：
| 维度 | 测试时计算（Test-time Compute） | 睡眠时计算（Sleep-time Compute） |
|---|---|---|
| 时机 | 查询到达后，用户等待中 | 查询到达前，空闲期 |
| 典型手段 | 长思维链、多次采样、搜索、自我一致性 | 记忆整合、矛盾消解、预推导结论 |
| 成本结构 | 每次调用都付 | 一次预计算，多查询摊薄 |
| 擅长 | 一次性的、无法预判的难题 | 已知且会被反复复用的上下文 |
| 失效场景 | 上下文早已明确、用户不想等 | 上下文全新、只查一次 |
论文在 Stateful GSM-Symbolic 与 Stateful AIME 这类「上下文可复用」基准上报告：达到同等准确率，测试时计算量约省 5 倍；上下文被多个相关查询复用时，平均每次查询成本约降 2.5 倍；继续扩大睡眠时计算预算，峰值准确率还能再提升约 13%，把准确率—算力的帕累托前沿整体外推约 18%。同时也写明了边界：当测试时算力预算本身给得很高时，只堆测试时计算反而可能更好；推理模型（如 o1）在这套设定下的额外收益有限。
三、工程落地：现在的框架怎么开
最成熟的实现来自 Letta。在 letta-client Python SDK 里，开一个参数就会创建一个「双 Agent 小系统」：一个负责对话的主 Agent，一个后台的睡眠时 Agent，两者共享同一组 memory block——后台写，前台下一轮直接读，不需要你做消息传递或胶水代码。
from letta_client import Letta
client = Letta(api_key="LETTA_API_KEY")
# 一个开关：Letta 自动创建主 Agent + 睡眠时 Agent，共享记忆块
agent = client.agents.create(
model="openai/gpt-4o-mini",
enable_sleeptime=True, # 关键开关
)
# 你只和主 Agent 对话，行为完全不变
resp = client.agents.messages.create(
agent_id=agent.id,
messages=[{"role": "user", "content": "我是独立开发者，做 B2B，还没营收。"}],
)
后台 Agent 默认每 5 步触发一次记忆改写（频率参数形如 sleeptime_agent_frequency，具体字段以官方文档当前版本为准）。第 6 轮之后，主 Agent 读到的已经是被整理过的记忆——而用户从未为此等待。
如果想自己搭，逻辑也就三步：
# 1) 前台回答：只读已整理记忆，绝不现场做记忆整理
answer = primary.run(user_query, memory=read_blocks())
# 2) 空闲期：后台 Agent 读原始上下文，产出结构化改写
new_blocks = editor.run(
"把最近对话中的稳定事实、偏好、结论提炼出来；"
"冲突时以更新的事实为准；不要保留一次性的临时信息。",
context=recent_history,
)
# 3) 写回 + 版本化，便于审计和回滚
memory.write(new_blocks, commit_message="consolidate: 用户画像与项目约定")
2026 年的生态已经把这条路走通了：Letta Code 提供 /sleeptime（按步数或上下文压缩事件触发）与 git 版本化的记忆库；Mem0 有定时后台的 Dream Synthesis；Zep 用图社区刷新做同类整合；Anthropic 也在 2026 年的开发者大会上给出了对应的「Dreams」能力。学术侧的旁证是 UIUC 2026 年 5 月的 Auto-Dreamer 预印本：加一个离线整合器后，ScienceWorld 成功率从 29.6% 升至 41.1%，ALFWorld 从 48.0% 升至 60.2%（受限于受控实验环境）。
四、什么时候值得做，什么时候是浪费
睡眠时计算不是免费的午餐，判断标准只有两条，必须同时成立：
- 上下文在查询之前就已知（文档、代码库、Agent 累积的记忆）；
- 同一份上下文会被多个查询复用。
两条都满足，预计算才有摊薄空间；只查一次的冷启动问答，睡眠时计算没有任何优势，纯属多付钱。
落地时优先盯这四个指标：
| 指标 | 为什么看它 |
|---|---|
| 命中复用率 | 复用率低说明预计算白做 |
| 前台 P95 延迟 | 唯一必须不倒退的指标 |
| 单查询平均成本 | 后台调用的成本要能被摊销 |
| 记忆漂移率 | 后台改写引入的过时/矛盾事实比例 |
五、三个容易踩的坑
| 坑 | 表现 | 解法 |
|---|---|---|
| 把摘要当整合 | 只做压缩，没形成可复用的结论 | 要求输出「事实 + 结论 + 冲突消解记录」，不只是浓缩原文 |
| 后台无限重构 | 记忆反复被改写，事实开始漂移 | 版本化 + 定期人工审计，像对待代码一样对待记忆 |
| 触发太密 | token 成本飙升，收益不增 | 以步数阈值、上下文压缩事件或空闲窗口为触发条件 |
记忆一旦能被后台自动改写，攻击面也随之扩大——这与《什么是记忆投毒（Memory Poisoning）？》里的风险同源：能被自动整合的记忆，也能被自动写坏。生产环境务必保留 diff 与回滚。
总结
- 睡眠时计算 = 在用户不提问时提前思考，把推理成本移出关键路径。
- 论文数据：同等精度省约 5 倍测试时计算，上下文复用时单查询成本降约 2.5 倍。
- 生效前提只有两个：上下文可事前得知 + 会被复用；不满足就是浪费。
- 工程形态已经标准化：主 Agent + 后台 Agent 共享记忆块，一个开关即可开启。
- 真正的门槛不在开功能，而在记忆治理：版本化、可审计、可回滚。
延伸阅读建议：先读《什么是 Agent 记忆系统？AI Agent 长期记忆技术全解析》建立记忆分层概念，再读《什么是上下文腐烂（Context Rot）？》理解为什么加长上下文救不了记忆，最后用《什么是 Agent 记忆修订（Memory Revision）？》补齐改写一致性这块短板。