上回说到上下文分诊——信息进Context之前先排优先级。这一讲要聊的，是信息进来之后的事：Agent只要跑得足够久，上下文几乎必然膨胀。

对话历史、tool返回、错误日志、代码diff、测试输出，这些东西会一轮一轮地堆起来。到了某个阶段，系统必须对历史做点什么，否则不是撞上context limit，就是让模型淹在旧信息里。这个阶段通常被称为"语义压缩"，但有一个关键判断需要先明确：压缩不是做摘要，它的本质是工作记忆维护。压缩之后，Agent到底还能不能记得自己为什么走到这一步？

一、坏的压缩比不压更危险

举个例子就很清楚了。

一个ConnectionPoolExhausted的错误堆栈，14行trace，清清楚楚地写着pool_size=20、queue_depth=347、timeout in acquire_connection。如果被压成一句"database error occurred"——好，Agent可以说直接失去了判断力。

它后面接着调pool_size、加retry、改timeout，看起来还在努力，但实际上已经丢了最关键的信息——问题根本不是连接池太小，而是连接没有被及时释放。

不压历史，最多撞窗口限制；乱压历史，Agent会忘记关键证据，甚至会忘记哪些方案已经被证明失败，然后在同一个坑里反复试错。

二、三层压缩链：从轻到重

压缩通常不是一步到位的，而是一层一层往下压。

Level 1清理tool输出——日志全文、API响应，替换成占位符或截断。Level 2做Anchor合并——把旧对话、任务状态抽取成intent / changes / decisions / excluded / next，增量合并进Anchor。Level 3才进入极限压缩阶段。

最稳的策略不是无限压，而是：少压、分层压、保留证据、保留回退路径。

这和特德·姜那个"模糊图像"的类比几乎一模一样：暗房里翻拍照片，第一次翻拍主体还在，第二次边缘就开始模糊，第三次很多细节就永久丢了。多层压缩每多压一次，语义漂移的风险就大一分。

三、Anchor五字段

压缩后的工作记忆，必须稳定回答五个问题。

 复制代码@dataclass
class CompactionAnchor:
    intent: str                         # 用户要什么
    changes_made: list[str]             # 已经改了什么
    decisions_taken: list[str]          # 已经做了哪些判断
    excluded_approaches: list[str]      # 已经排除的方案
    next_steps: list[str]               # 下一步做什么

五个字段里，excluded_approaches 最关键，也最容易被遗漏。 很多长会话Agent反复试错，不是因为它不会推理，而是因为它忘了哪些路已经走不通。

这里值得多说一句。服务端做事故复盘时，incident timeline记录的无非也就是这些：客户是谁、已经做过什么、已经排除了什么原因、下一步该做什么。Anchor其实就是会话级incident timeline的运行时版本。

四、Action与Observation分离

OpenHands有一个非常值得关注的设计，叫ObservationMasking。Agent的历史里其实包含两类信息：Action是Agent自己做了什么，Observation是外部世界返回了什么。

ObservationMasking的做法是：把早期的Observation替换成占位符，但完整保留Action。这相当于告诉Agent——你不需要记住每一屏输出，但必须记住自己走过哪些路。

通用LLM summarization把这两类混在一起压，可以说是最隐蔽的工程错误之一。服务端日志治理早就分了"行为日志"和"状态日志"——前者长期保留，后者采样或截断。Agent历史里的Action和Observation，完全对应这两类。

五、错误堆栈是Agent的测试套件

这一讲最锋利的一个类比，来自Martin Fowler的《Refactoring》。平移过来就是：压缩的安全感，来自关键证据保护。错误堆栈就是Agent的测试套件——它记录了上次为什么失败、失败在哪一行、哪条路已经走不通。把错误堆栈压成一句模糊的"出现了数据库错误"，就像重构时顺手把测试删掉。

六、Level 3是退场信号

Level 3极限压缩，不是"再压一次"，而是退场信号。

和服务端"重试上限+报警升级"完全是一个道理。从SRE实践来看，最需要警惕的反模式就是无限重试——系统一旦进入需要不断重试的状态，正确的动作不是"再试一次"，而是退出当前路径、升级到人工介入。

Agent压缩也是同理。一旦session反复进入Level 3，正确的动作是导出handoff summary、交给二线或人工处理。极限压缩不是工程胜利，而是系统在要求退出。

这个handoff summary的内容，和服务端incident escalation的标准模板几乎一模一样：现象、已尝试方案、已排除原因、下一步建议、SLA剩余。Agent的handoff summary，本质上就是同一份东西。