Agent 工程笔记②：上下文太长——砍什么、留什么
上下文太长时，不是「模型突然变笨」一种可能，更常见的是：关键信息被挤出窗口，或噪音淹没了目标。
上一篇讲工具失败分层。本篇讲材料管理：窗有限，必须取舍。
一、先说一个具体麻烦
Agent 跑了四十轮：读文件、跑测试、改代码、再读日志。到后半段，它开始重复已修复的错误，或忘掉最初的验收条件。
你加长窗口，成本上升，问题仍可能在：窗口里塞满了过期轨迹。
二、先分清两种「太长」
（1）硬超窗：请求被拒或被截断
（2）软过载：没超标，但信噪比极差，模型抓不住重点
砍上下文对两种都有用。只加窗口，主要缓解第一种。
三、留什么（优先级从高到低）
（1）系统级硬规则与安全边界
（2）当前任务目标、范围、验收
（3）仍有效的关键事实摘要（已确认的接口名、复现步骤）
（4）与当前决策直接相关的代码/日志片段
（5）最近一轮工具结果（若仍相关）
四、砍什么
（1）重复失败的同一段日志（留最后一次 + 结论）
（2）已撤销方案的长讨论
（3）大段无关文件全文（改检索片段）
（4）客套与重复确认
（5）过期的中间 diff（以当前工作区为准）
原则：能变摘要的不变流水账；能检索的不整文件常驻。
五、可操作的压缩手法
（A）定期让模型输出「已确认事实」短摘要，替换旧历史
（B）工具结果只留尾部与错误行
（C）大文档走 RAG / 搜索，而不是全贴
（D）新子任务开干净线程，携带摘要而不是四十轮原文
下面是一个摘要槽位示意。
## 已确认
- 入口：apps/web/app/api/users/route.ts
- 验收：typecheck + 空态文案
## 待办
- 补测试
## 不要做
- 不改 schema上面文本中，三块信息比二十轮闲聊更占「有效窗」。
六、常见误区
（1）只扩窗不治理
贵且脏。
（2）砍掉验收条件
后半段必然漂。
（3）以为模型会自动记住仓库现状
以工作区与工具读取为准。
（4）摘要写太虚
「差不多修好了」没有信息量。
七、小结与下一篇
太长就取舍：留下规则、目标、有效事实；砍掉重复与过期轨迹。窗口是容量，摘要是管理。
下一篇预告：为什么要有评测集，比单次演示重要。
（完）