Day 08 - Context Compression and Summarization

今日目标

能设计摘要、裁剪与分层记忆策略，控制长任务上下文膨胀。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读当天章节重点，只抓问题、思路、结论。
25-45 分钟	实践任务	动手完成输出模板，必须产出一份可复用产物。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
context inflation	上下文膨胀：长对话与长任务中历史信息不断累积，上下文越来越大，成本上升、噪声增加。	50 轮排查对话后，历史记录比任务本身还长。
summarization	摘要：用模型把历史内容压缩为更短的摘要，保留关键信息、丢弃细节。	把两小时排查记录压缩成 10 行要点。
truncation	裁剪：直接丢弃最旧或最不相关的历史片段，简单但可能丢关键信息。	只保留最近 20 轮对话，更早的整段丢弃。
hierarchical memory	分层记忆：维护多层摘要（完整摘要、关键摘要、当前结论），按需取用对应层级。	第一层留全量要点，最后一层只有一句话结论。
rolling window	滚动窗口：固定保留最近 N 轮完整对话，更早内容用摘要替代，是裁剪与摘要的组合。	每 10 轮对话压一次摘要，窗口内永远只放最近 10 轮。
KV cache	KV 缓存：模型已计算过的键值缓存，长上下文复用可减少重复计算，但缓存占用随上下文变长而增加。	长任务的成本主要来自 KV cache 占用，不只是 token 费用。
sub-agent isolation	子 Agent 隔离：子任务在独立上下文中执行，只把结论回传主 Agent，避免上下文互相污染。	让子 Agent 单独查日志，只把结果摘要拿回主流程。
compression risk	压缩风险：摘要可能丢失关键数字、引入错误信息，压缩本身也可能产生幻觉。	摘要里 P95 从 900ms 变成 90ms，结论就完全错了。
critical information	关键信息：绝不能丢的信息，如用户指令、数字结论、待办事项、待验证假设。	压测结论 3 项、待验证假设 2 条，摘要里必须原样保留。

阅读重点

对应章节：第 2 章中上下文压缩、KV Cache、分层压缩与子 Agent 隔离等内容。
关注点：
为什么上下文不是越长越好：成本、噪声、注意力稀释三个代价。
摘要、裁剪、滚动窗口三种策略各自的代价与适用场景。
KV cache 如何影响长上下文任务的成本与延迟。
子 Agent 隔离解决什么问题：上下文污染与互相干扰。
补充材料：
Anthropic 的 context engineering 文档中关于长上下文任务与压缩的部分。
模型 API 文档中 prompt caching 的说明，理解 KV cache 在成本上的作用。

理解检查

为什么上下文不是越长越好？长上下文会带来哪些具体代价？
摘要会带来什么风险？举一个压缩后信息变错的例子。
哪些内容绝不能被压缩掉？
子 Agent 上下文隔离解决什么问题？它和主 Agent 的上下文是什么关系？

实践任务

背景：上个月一次 Nginx CPU 升高排查持续了两个小时，日志、操作记录和中间结论混在一起有 35 行。直接把整段文字塞给模型，它总是抓不住重点。今天把这段记录压缩成三层摘要。

步骤：

准备原始记录：时间线、操作、观测数据、中间结论，30 行以上。
第一层：写 10 行完整摘要，保留时间线、关键数字、做过哪些操作。
第二层：写 3 行关键摘要，只保留当前状态、关键证据、待验证假设。
第三层：写 1 行当前结论，供下一次对话直接使用。
三层之间做一致性检查：第二、三层的数字必须与第一层一致。
保存为 three-layer-summary-nginx-cpu.md。

产出：一份三层摘要，以及一份一致性检查记录。

输出模板

原始记录长度：[行数/字数]，记录时间范围：[起止时间]。

第一层：完整摘要（约 10 行）
- 时间线：[按时间列出关键事件]。
- 关键操作：[执行过的排查动作]。
- 观测数据：[CPU、TPS、错误率等关键数字]。
- 中间结论：[每个阶段得出的结论与修正]。

第二层：关键摘要（约 3 行）
- 当前状态：[现在已知什么]。
- 关键证据：[支撑当前判断的数据]。
- 待验证假设：[下一步要确认什么]。

第三层：当前结论（1 行）
[一句话结论 + 下一步动作]。

示范输出

原始记录长度：35 行，记录时间范围：2026-08-12 10:00 至 12:30。

第一层：完整摘要（约 10 行）
- 10:00 开启 WAF 后 Nginx CPU 从 30% 升到 85%，持续 30 分钟。
- 10:20 检查 access log，发现 /api/pay 请求量增加 3 倍。
- 10:40 查询 upstream 响应时间，P95 从 200ms 升到 900ms。
- 11:00 对比 WAF 开关，关闭 WAF 后 CPU 回落到 35%。
- 11:10 复测三组请求：开启 WAF 时 CPU 高、关闭时正常，结论可复现。
- 11:30 查看 WAF 规则，怀疑正则匹配在长 URL 上开销大。
- 11:50 用 10 万次长 URL 请求复现，确认 CPU 与 URL 长度正相关。
- 12:10 结论：WAF 正则匹配长 URL 是 CPU 升高的主要原因。
- 12:20 待验证：修改正则或加长度限制后，峰值是否消失。
- 12:30 已同步开发，等待修复后回归验证。

第二层：关键摘要（约 3 行）
- 当前状态：已定位为 WAF 正则匹配长 URL 导致 CPU 升高。
- 关键证据：开关 WAF 前后 CPU 从 85% 回到 35%，长 URL 复现实验确认相关。
- 待验证假设：调整正则或限制 URL 长度后峰值消失。

第三层：当前结论（1 行）
WAF 正则匹配长 URL 是 CPU 升高的主因，等开发修复后做回归验证。

追问练习

上下文压缩和 RAG 有什么区别？什么情况下该用哪一个？
如果第二层摘要和原始记录冲突了，你会信谁？怎么避免这种冲突发生？
子 Agent 隔离后，主 Agent 如何判断该把哪些内容保留在主上下文里？
一个 50 轮的长任务，你会在第几轮触发第一次压缩？依据是什么？

常见误区

上下文不是越多越好：堆历史等于堆噪声和成本，也更容易让模型引用过期信息。
摘要只做一次就够：长任务需要递归压缩，旧摘要也会随任务推进而过时。
压缩时只留「看起来重要」的段落：关键数字丢了就无法挽回。
认为裁剪永远是最差策略：对最旧且无关的内容，裁剪比摘要更省、更可靠。

进阶扩展

KV cache 与 prompt caching：长任务成本不只是 token 费用，缓存命中与失效策略同样影响延迟与账单。
动态上下文注入：不把全部历史注入，而是按当前步骤检索需要的部分。
压缩质量评估：定期把摘要与原记录对比，统计丢失或改动的关键信息。

今日作业

完成三层摘要，保存为可复用文件。
对三层做一致性检查，记录发现的任何矛盾。
挑一条你工作里的长排查记录，用模板再压缩一遍。

自检清单

我能解释上下文膨胀的三个代价。
我能说出摘要、裁剪、滚动窗口各自的代价。
我能完成三层摘要且数字前后一致。
我能说清哪些内容绝不能压缩掉。
我能区分上下文压缩与 RAG 的适用场景。