ACGC - Agent Context Garbage Collector

我构建 ACGC（Agent Context Garbage Collector，智能体上下文垃圾回收器），是因为我反复在智能体系统中遇到同一个问题：模型很少面临上下文不足的问题——它通常是被上下文淹没了。

常见的做法是不断向 prompt 中追加更多的历史记录、工具输出、检索到的文档、记忆以及中间状态。这种方式短期内有效，但随着智能体的运行时间变长、状态变得更丰富，上下文开始变得昂贵、嘈杂，也更难进行推理。最终，你会为大量 token 买单，而其中很多可能与当前任务毫无关系。

促使我构建 ACGC 的问题很简单：

智能体能否在保留大量记忆的同时，不必把全部记忆都塞进每一个 prompt 中？

ACGC 作为轻量级的 sidecar 旁挂在现有的智能体技术栈旁边。它不再把上下文当作一个不断增长的缓冲区，而是将其作为一个记忆系统来管理。信息可以被组织成记忆 DAG，相关的记忆可以通过语义方式被召回，较早的信息可以迁移到归档中，最终的上下文会在送入模型之前按照固定的 token 预算进行编译组装。

对我来说，重要的是这件事不应该要求重写现有的智能体框架。目标是让上下文管理成为一种基础设施层面的关切，它可以位于应用旁边，而不是与应用深度耦合。

在构建过程中，这个项目经历了相当多的演变。最初，我认为问题主要在于对旧上下文进行摘要和删除。结果证明这种想法过于简单。"最近发生"并不等同于"相关"，激进地压缩记忆可能会恰好删除掉智能体在几轮之后真正需要的细节。

于是，设计思路逐渐从"回收旧的 token"转变为"为当前任务编译出尽可能好的上下文"。

这意味着需要结合：

* 通过 DAG 构建的结构化记忆关系，

* 针对较早或较远信息的语义召回，

* 用归档记忆代替永久删除，

* 以及感知 token 预算的上下文编译。

这项工作中很大一部分还在于测试它在我们的示例之外是否依然站得住脚。我们使用外部的长上下文和记忆基准——尤其是 LoCoMo 和 LongMemEval——以及我们自己的消融实验和黄金数据集，对 ACGC 进行了广泛的评估。目标不只是衡量 token 的削减量，还要衡量系统是否仍然能够保留远距离召回、多轮推理以及依赖记忆的回答所必需的信息。

在我们所有的评估中，ACGC 在保持、甚至在某些情况下提升回答质量的同时，将上下文/token 用量减少了大约 46%–82%。

我最终关心的指标并不是"我们移除了多少 token"，而是：

我们送入模型的每一个 token，换回的有效智能究竟有多少？

ACGC 仍在演进中，我尤其希望听到那些正在构建长时间运行的智能体、编程智能体、copilot 或是上下文会随时间不断累积的系统的人的反馈。

也很想知道其他人在生产环境的智能体中目前是如何处理上下文增长和记忆问题的。