案例分析一：Coding Agent 运行 40 步，如何压缩而不丢失“禁止修改 tests/”？

这个案例很典型，也很适合配合图来看。因为很多 Agent 在长对话里出问题，不是不会写代码，而是把用户最重要的硬约束压没了。下面这张图把错误压缩方式和正确压缩方式放在了同一页里，对比会特别明显。

图中最关键的一点，就是“禁止修改 tests/”这种约束不能混进普通历史摘要里，而应该被提升为必须长期保留的硬约束。只有这样，历史再长、摘要再多，后续生成时也不会把这条规则忘掉。

场景背景

项目规则：

Python 3.9
禁止修改 tests/
不允许新增依赖
修改后必须运行 pytest

Agent 已经运行 40 步。

旧 Context 包含：

大量文件内容
6 次 pytest 输出
4 次 FileNotFoundError
多次搜索结果
旧计划

当前真正要做，修改 src/service.py 后重新验证。

错误方案

直接：

messages = messages[-20:]

结果把最早的项目规则删掉。

Agent 后面发现测试失败，决定：

直接改 tests/test_service.py

彻底违背规则。

正确 Compaction

第一层，永远保留：

Project Rules
Working Memory
Current Task

第二层，把前 30 步压缩：

Historical Summary:
- 已确认入口 src/main.py
- config.py 路径问题已解决
- 数据库方向已排除
- 当前根因集中在 Service.start() 对 API_TOKEN 的处理
- 已修改 src/service.py 一次，但测试仍有 1 个失败

第三层，保留最近 10 条原始消息：

最近 edit_file
最近 pytest
最近 traceback
用户刚补充的话

新 Context

System
Project Rules
Working Memory
Historical Summary
Recent Messages
Current Task

结果

Context 明显变短。

但：

禁止修改 tests/

仍然稳定存在。

复盘

这个案例告诉我们，高优先级约束不能依赖历史消息本身存活。

它们应该独立于 Compaction。

Compaction 主要处理的是“执行历史”。

不是“系统边界”。