OpenClaw 内置的策略很直接：满了就截断。老消息直接丢掉，腾出空间给新消息。这在大多数场景下够用，但如果你的 agent 工作流比较长——比如一个跨多个文件的重构任务，或者一个需要反复引用前文决策的 debug 过程——截断就成了隐患。agent 忘掉了之前为什么做某个选择，然后在后续步骤里做出矛盾的操作，你还得花时间把它拉回来。

lossless-claw：压缩代替截断

lossless-claw 提出了一个不同的思路：不截断，只压缩。

它的工作原理是这样的：

  • 每条对话消息都会被存进本地的 SQLite 数据库，作为完整的原始记录
  • 系统自动对这些消息生成摘要，并组织成 DAG（有向无环图）结构
  • 实际送入 context window 的是压缩后的摘要版本，而不是原始的完整消息
  • 当你需要回溯某条具体信息时，原始记录始终可查

这里有个关键的设计取舍值得注意：DAG 结构意味着摘要之间保留了依赖关系。比如"决定用 PostgreSQL"这条摘要会被标记为"数据库选型讨论"的子节点，而不是把所有摘要拍平成一个线性列表。这样在压缩时，系统能更智能地判断哪些信息该保留、哪些可以进一步精简。

代价是什么？

天下没有免费的午餐。lossless-claw 的代价是额外的 token 消耗——每条消息都要跑一次摘要生成，这本身就需要调用模型。对于短对话来说，这笔开销不划算；但对于那些动辄几十轮、上百轮的长工作流，用一点额外 token 换取 agent 不丢失关键上下文，往往是值得的。

这其实反映了 agent 工程中一个更深层的问题：context 管理本质上是一个信息压缩问题。截断是最粗暴的有损压缩，摘要是更精细的有损压缩，而 lossless-claw 试图在"对 agent 无损"和"实际可用"之间找到一个平衡点。

适用场景

如果你正在搭建的 agent 工作流有以下特征，值得试试这个插件：

  • 单次任务对话轮次多（超过 20 轮）
  • agent 需要在后续步骤中引用早期的决策或数据
  • 你发现 agent 经常"忘事"，导致重复提问或做出前后矛盾的操作

安装方式和普通的 OpenClaw 插件一致，项目仓库在 GitHub 上搜索 Martian-Engineering/lossless-claw 即可找到，目前已有 2k star 和近 150 个 fork，社区活跃度不错。

回过头来想一个问题：当我们的 agent 工作流越来越长、越来越复杂，context 管理会不会成为比模型能力本身更关键的瓶颈？