"200k token 的窗口"听起来很大，但 Agent 跑起来它消耗得飞快。把窗口当成一笔预算：系统提示是房租（固定支出），工具定义是水电（接得越多越贵），对话历史是伙食（每天都涨），真正留给"思考"的余量比想象的小。点击色块看每一项的开销特征👇
研究和工程实践都指向同一件事：有效注意力不随窗口长度等比增长。上下文越长，模型越容易忽略中间部分的信息（"lost in the middle"），且每个 token 都要花钱、加延迟。好的 Agent 不追求"装得多"，追求每一轮窗口里都是当前决策需要的最小充分信息集——这就是"上下文工程"这个词的含义。
上下文不是匀速增长的——一次读大文件、一次网页抓取就能吃掉几万 token，而模型的思考本身很便宜。点击"执行下一轮"，模拟一个修 bug 的 Agent，体会增长节奏，以及窗口逼近上限时压缩（compaction）怎么救场👇
① 增长极不均匀：读文件、抓网页这类"观察"步骤才是大头，控制上下文先控制工具输出（截断、分页、只返回相关片段）；② 压缩有损：compaction 之后窗口空出来了，但被摘要掉的细节永远回不来——所以重要结论要在压缩前写进外部记忆（下一节）。
同一段 12k token 的对话历史，三种策略处理后长什么样、丢了什么？点击卡片切换对比👇
成熟的 Agent 通常三招齐用：工具输出先截断（单条结果设上限，旧的 tool_result 可以只留摘要）、历史定期摘要（保最近几轮原文 + 早期摘要）、关键状态外置（todo 清单、已确认的结论写进文件，每轮带回窗口的只有一小段）。Claude Code 的 auto-compact 就是这套组合拳。
压缩只能省，记忆才能存。把人类记忆的分层搬过来：窗口内是转瞬即逝的短期记忆，scratchpad 是干活用的工作记忆，外部存储才是长期记忆。三层的读写时机完全不同👇
两种触发：显式——用户说"记住我用 pnpm 不用 npm"，立刻写；隐式——会话结束/压缩前，让模型自问"这次有什么值得下次记住的"，蒸馏成几行再存。原文全存是反模式：存得越糙，将来检索回来的噪音越多。
窗口不只是"满不满"的问题——内容本身会出毛病。社区把常见失效归纳为四类，点击查看症状和处方👇
四种病的根因是同一个：模型不会区分上下文里信息的"质量"与"时效"——错的、旧的、无关的 token 和对的 token 在注意力面前一律平等。所以上下文工程的本职就是当好"守门员"：错的修剪掉，旧的标记清，无关的别放进来。
5 道题。答错没关系，解析比答案重要。