大家好，我是十三！欢迎来到十三Tech。
上一讲聊了上下文分诊——信息进 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：压缩的安全感来自关键证据保护。错误堆栈就是 Agent 的测试套件——它记录了上次为什么失败、失败在哪一行、哪条路已经走不通。把错误堆栈压成一句模糊的"出现了数据库错误"，就像重构时顺手把测试删掉。
六、Level 3 是退场信号
最后一条让我有共鸣的判断：Level 3 极限压缩不是"再压一次"，而是退场信号。
和服务端"重试上限 + 报警升级"完全一样。我做 SRE 时最警惕的反模式就是无限重试——系统一旦进入需要不断重试的状态，正确动作不是"再试一次"，而是退出当前路径、升级到人工。
Agent 压缩也一样。一旦 session 反复进 Level 3，正确动作是导出 handoff summary、交给二线或人工。极限压缩不是工程胜利，是系统在要求退出。
handoff summary 的内容和服务端 incident escalation 的标准模板一模一样：现象、已尝试方案、已排除原因、下一步建议、SLA 剩余。Agent 的 handoff summary 是同一份东西。
课程入口
关于十三Tech All in AI Agent方向的架构师，专注AI工程实践。 相信AI是程序员的最佳搭档，帮助每一位开发者驾驭AI。
联系方式：569893882@qq.com GitHub：@TriTechAI
