Context Compaction：让 Agent 学会“压缩记忆”

上一节我们已经把一个长期运行 Agent 最现实的问题看清楚了：Context Window 是有限资源，而 Agent 会不断往里面塞入新的用户消息、模型消息、Tool Result、代码文件、运行日志、异常信息、SQL 查询结果、Tool Schema、Working Memory 和项目规则。

如果什么都不处理，Agent 一定会越来越重。

但真正难的不是“Context 太长”这件事本身，而是接下来该怎么办。

最粗暴的方法当然是：

messages = messages[-20:]

只留最近 20 条。

这能立刻把 Context 缩短。

可它也可能把最关键的东西一起删掉。

比如：

用户最开始说：
不允许修改 tests/

第 35 轮：
只保留最近 20 条
→ 这条规则消失

然后 Agent 真的去改 tests/。

这说明我们不能把 Context Window 问题简单理解成，“太长了，删一点。”

真正需要的是，在不破坏任务连续性的前提下，把旧上下文从“原始细节”压缩成“仍有决策价值的摘要”。

这就是 Context Compaction。

这一节我们会实现一个最小但完整的：

compact_context()

流程是：

旧消息
  ↓
提取关键信息
  ↓
生成 Summary
  ↓
保留最近消息
  ↓
重新构建 Context

我们还会专门讨论几个特别容易踩坑的问题：

什么应该保留？
什么可以删除？
Tool Result 怎么压缩？
代码内容怎么处理？

到这一节结束，我们的 Agent 才真正具备“长时间工作但不会一直背着所有历史”的能力。

开场引入

先来看一个真实得不能再真实的场景。

用户让 Coding Agent 修一个复杂项目。

前 20 步里，Agent 已经做过：

list_files
read README.md
read pyproject.toml
read src/api.py
read src/service.py
read tests/test_api.py
run pytest
search API_TOKEN
read src/config.py
edit src/service.py
run pytest

其中某次 pytest 返回 400 行日志。

某次 read_file("src/service.py") 返回 9000 字。

某次 search_files("API_TOKEN") 返回 60 条结果。

Agent 到第 25 步时，Context 里已经有：

大量旧日志
已经修复的错误
已经读过的完整代码
重复出现的 Tool Result
很早之前的用户说明
过去的中间结论

这时它想继续做一个很简单的事情，“验证刚才修改后 API 测试是否通过。”

理论上它真正需要的，只是：

当前 Goal
项目规则
刚才改了哪个文件
当前未解决问题
最近一两次 Tool Result
下一步要跑哪个测试

可我们却把前 25 步所有原文都重新发给模型。

这就像一个工程师每做下一步，都必须先重新翻阅一天所有聊天记录、日志、终端输出、代码快照，才能决定下一件事。

当然很慢。

也当然容易被噪声干扰。

所以我们真正想做的是：

旧 20 步
 ↓
压缩为一份 Summary

最近 5 步
 ↓
保留原始内容

高优先级规则
 ↓
永远保留

Working Memory
 ↓
继续保留最新版本

于是下一轮模型看到的不是：

25 轮原始历史

而是：

System Rules
Project Rules
Working Memory
Historical Summary
Recent Messages
Recent Tool Results
Current Task

这就是 Context Compaction 的基本形态。

注意这里一个特别重要的词，Compaction，不是 Deletion。

压缩的目标不是让历史“消失”。

而是把：

很多低层细节

转换成：

少量高价值语义

例如旧历史中有：

Step 3:
read README.md

Step 4:
run pytest

Step 5:
FileNotFoundError config.py

Step 6:
list_files

Step 7:
找到 config/config.py

Step 8:
read config/config.py

Step 9:
确认数据库配置正常

压缩后不需要把每个 Step 原样保存到 Context。

可以变成：

Historical Summary:
- 已确认配置文件实际路径为 config/config.py
- 数据库配置正常，当前问题不在数据库
- 后续调查重点转向依赖与 API_TOKEN

对下一步决策来说，这已经足够。

原始 Step 仍然可以留在 Trace。

只是它们不再每轮都重复进入模型 Context。

知识地图

完整压缩链路：