案例分析一：Coding Agent 工作 35 轮后为什么突然“忘了”用户不允许改 tests/

场景背景

用户最开始明确说，“只修业务代码，不允许修改 tests/。”

Agent 前20轮都遵守。

后来为了排查复杂 Bug，它连续：

读取 12 个 Python 文件
运行 6 次 pytest
搜索 8 次关键词
产生大量 traceback

Context 已经非常大。

系统为了避免超限，简单做：

messages = messages[-30:]

于是用户最初那句：

不允许修改 tests/

被截掉了。

第35轮，Agent 看到：

tests/test_api.py

决定直接改测试。

表面现象

看起来像，“模型突然不听话。”

真正根因

不是模型能力突然下降。

而是，关键约束被 Context 截断。

这就是最典型的 Context Management Bug。

正确改造

把：

不允许修改 tests/

提升到：

Agent Rules / Project Rules

每轮稳定注入。

同时：

老 Conversation
旧 Tool Result
大日志

可以压缩。

Working Memory 再保留：

Completed:
- 已排除 tests 本身问题
- 当前只允许修改 src/

结果

即使 Session 运行 50 轮，规则仍然存在。

复盘

这个案例说明，Context Window 管理不能只按时间顺序裁剪。

必须按：

语义重要性
优先级
生命周期

处理。

这也是 ContextBuilder、Working Memory 和下一节 Compaction 要共同解决的问题。

这个 Coding Agent 案例把“Context 管理 Bug”表现得非常典型：模型并不是突然变差，而是最重要的约束被简单截断以后，它已经看不到那条规则了。

正确做法不是盲目扩大窗口，而是把“不允许修改 tests/”提升成稳定注入的 Project Rule，同时用 Working Memory 保留当前允许修改的范围，再对旧对话、日志和 Tool Result 做压缩。