为什么"自动压缩"比"定时压缩"聪明

传统做法是设一个固定阈值——比如上下文用到 85% 就触发压缩。这就像一个闹钟，到点就响，完全不管你在干什么。你可能正在做一个复杂的代码重构，上下文里全是关键信息，这时候压缩就是灾难。反过来，你刚完成一个任务准备开始新的，之前的上下文已经没用了，但因为还没到阈值，这堆废话就一直占着窗口。

Deep Agents 的方案是把压缩动作暴露为一个工具（tool），让模型自己判断时机。说白了，就是把"什么时候该忘"这个决策权交给 AI 自己。

什么时候该压缩？

团队总结了几类适合压缩的场景：

  • 任务边界清晰时：用户明确表示要开始新任务，或者当前任务已经确认完成
  • 从大量上下文中提炼出结论后：比如做完一轮调研，已经得到了关键结论，原始素材就可以压缩掉
  • 即将消耗大量新上下文前：准备生成长文档、读取大量新文件之前，先腾出空间
  • 进入复杂多步流程前：要开始一次大规模重构或迁移，已经定好了计划，之前的讨论过程可以精简
  • 新决策推翻旧方案时：需求变了，之前的讨论和死胡同可以压缩成一句话总结

这些场景没法穷举，但关键洞察是：人和 LLM 其实都能识别这些"合适的时机"。与其等到窗口快爆了再被动压缩，不如在合适的节点主动清理。

压缩的时候发生了什么

机制并不复杂：保留最近 10% 的上下文原文不动，把之前的内容做一次摘要替换。调用压缩工具本身的消息也会被保留在近期上下文中，这样模型知道自己刚做了一次压缩。

另外，Deep Agents 会把所有对话历史保存在虚拟文件系统中，所以即使压缩出了问题，上下文也能恢复。这个兜底设计很重要——毕竟让模型自己决定"忘什么"是有风险的。

怎么用

在 SDK 中，它是一个独立的中间件，加到 create_deep_agent 的中间件列表里就行：

在 CLI 中更简单，直接 /compact 命令就可以手动触发。

实际效果如何

团队做了几轮测试：用 LangSmith traces 构建了专门的评测集，在 terminal-bench-2 基准测试中跑了一遍，还在自己的日常编码中长期使用。

结论是：模型非常保守。它不会动不动就压缩，但一旦触发，时机选择通常很准——基本都在明显有利于后续工作流的节点。这其实是个好事，宁可少压不要错压。

背后的设计哲学

这个功能本身不大，但它指向了一个更大的方向：Agent 框架应该尽量"让路"，把更多控制权交给底层模型。与其在框架层面写一堆手工调参的规则，不如让模型自己管理自己的工作记忆。

这其实就是 Rich Sutton 说的"苦涩的教训"（The Bitter Lesson）在 Agent 工程中的体现——那些精心设计的启发式规则，最终往往不如把问题扔给模型让它自己解决。

对于正在搭建长时运行 Agent 或交互式 AI 工具的独立开发者来说，上下文管理是绕不过去的问题。如果你还在用固定阈值压缩，不妨试试这个思路：给模型一个"自我整理"的工具，让它在合适的时候主动清理记忆，而不是等到窗口快满了才被动应对。