夜雨聆风你有没有遇到过这种情况：把一份几千字的文档丢给 AI，让它帮你回答问题，结果 AI 给的答案明显漏掉了文档里的关键细节？
你可能以为是 AI「没认真读」。但真实原因可能更简单：它根本没读完。
大语言模型有一个叫做「上下文窗口」的硬约束——就像一个人的短期工作记忆，能同时处理的信息量是有上限的。当你提交的内容超过这个上限，要么系统直接截断，要么 AI 自动启动「压缩」，把长文档缩减成它能处理的体积。
问题在于：压缩不等于摘要。压缩有四种完全不同的策略，用错了，要么答案有偏差，要么关键信息直接消失。
这篇文章来拆解 GitHub 上的 context-compression Skill（来自 h4vzz/awesome-ai-agent-skills 仓库，截至 2026 年 5 月），看 AI 系统是如何被「教会」压缩信息的，以及这套设计背后有哪些值得记住的反直觉原则。
先搞清楚一件事：为什么需要压缩？
这个问题听起来很基础，但答案会影响你对整套设计的理解。
当一个 AI agent 要回答问题时，它通常要先「加载上下文」——可能是一篇文档、一段对话历史、一堆检索结果。这些内容全部塞进模型的 context window，然后模型才能生成回复。
context window 的大小用「token」衡量。不同模型的上限不一样——4K、32K、128K 不等（截至 2026 年 5 月，主流商用模型大多在 32K～200K 范围）。但即使是 128K token 的窗口，一本书、一批业务日志、一段完整的客服对话历史，照样能轻松撑爆。
而且，就算没有超出限制，塞太多无关内容也会降低答案质量——模型需要在一堆信息噪声里找到真正有用的部分，注意力被稀释了。
所以压缩不只是「装不下了才压」的应急手段，更是「让模型更聚焦」的主动策略。
Skill 里的第一步描述得很准确：
“「先量一下 token budget——总窗口减去系统提示词、指令、以及模型生成所需的输出空间，剩下的才是真正可用于上下文的配额。如果原始内容已经装得下，就不需要压缩。」
这里有一个很容易忽略的细节：token 预算不是总窗口，是总窗口减掉一堆预留之后的余量。很多人没意识到，系统提示词本身就要占走一大块，如果你在 Skill 里写了几百行的 prompt，留给用户内容的空间其实比想象的少很多。
四种压缩策略，差异比你以为的大得多
Skill 里列了四种策略，这是整篇文章最核心的部分。它们不是同一件事的四种说法，而是适用场景完全不同、失败模式完全不同的四条路。
策略一：提取式摘要（Extractive Summarization）
字面意思——从原文中挑出最重要的句子，原封不动保留，其余的扔掉。
优点是精确：没有改写，没有重新表述，保留了原文的措辞。对于法律条款、医疗数据、代码片段这些「一字之差谬以千里」的内容来说，这是最安全的选择。
缺点也明显：如果重要信息分散在整段话里，单独提取几句话可能会失去上下文，让读者（或模型）无法理解。
工具侧的实现：TextRank、LexRank，或者直接用 LLM 做句子相关性打分再挑选。
策略二：生成式摘要（Abstractive Summarization）
这个大多数人更熟悉——让 AI 用自己的话把长文本重新写一遍，更短、更连贯。
优点是可读性强，压缩率也更高，而且能把分散的信息整合在一起。
但这里有一个反直觉的设计决策：
“生成式摘要绝对不能用于代码。
Skill 里写得很清楚：对代码内容，生成式压缩「可能引入细微错误（subtle errors）」。这话说轻了——实际上，一段 100 行的 Python 函数，经过生成式摘要之后，可能函数名对、逻辑对、注释也对，但某个边界条件悄悄改了，或者一个变量名被「规范化」了，这种错误在上下文里极难被发现，但运行起来就会出 bug。
所以对于技术内容，宁可用提取式，哪怕压缩率低一些。
策略三：关键点提取（Key-Point Extraction）
把文本压缩成结构化的要点列表：命名实体、数字、关键事实、结论。
这是压缩率最高的策略，通常能达到 90%+。一篇 800 token 的文档，变成 150 token 的要点清单，仍然保留了模型需要的所有关键信息——人名、日期、金额、结论。
适用于：信息密集型文档（财报摘要、会议纪要、数据报告），查询目的明确（用户想问「这家公司什么时候上市的」，不是「帮我感受这篇文章的语气」）。
不适用于：需要理解叙事逻辑、论证过程、语境推断的场景。关键点提取会扔掉「为什么」，只保留「是什么」。
策略四：选择性剪枝（Selective Pruning）
这是四种策略里最「保守」的，也是最容易被低估的：不改写，不提取，只是把明显多余的部分删掉——样板开头、重复的解释、纯修辞性的语句、空行和格式符。
Skill 里给出的使用场景是：「内容只超出预算 10%~15%」的时候。
这是一个值得记住的原则：轻度超支不要动刀，剪枝就够了。 很多开发者一遇到内容超出就上生成式摘要，但压缩是有代价的——每多一步处理，就多一份信息丢失的风险。能剪枝解决的，不要摘要。
最核心的设计决策：信息密度评分
四种策略背后，还有一个更基础的步骤：怎么判断哪些内容「值得保留」？
Skill 的第二步叫做「信息密度评分（Score Information Density）」——给每一段、每一句打分，看它在每个 token 里携带了多少与当前任务相关的信息。
这个设计让我觉得有意思的地方在于：它是 task-aware 的，而不是通用摘要。
一篇关于电商用户行为的文档，如果你的任务是「计算用户 LTV」，那么第三段里关于「用户注册来源分布」的详细分析，信息密度就是低的——虽然它本身很有价值，但对你的任务帮助不大。
传统摘要工具不管这个，它只看「这段话本身重不重要」。这个 Skill 的设计是：先锚定任务，再评分。 同一份文档，面对不同的查询，应该保留不同的内容。
实现上，Skill 给出了两条路：启发式方法（关键词与 query 的重叠度），或者轻量分类器。对于工程实践来说，启发式方法通常已经够用——把 query 的关键词列出来，然后统计每个段落包含多少这些词，打个加权分，就能快速筛出高密度段落。
处理多个来源时的 Token 预算分配
现在 RAG（检索增强生成）是非常常见的架构——在回答一个问题之前，系统先从知识库里检索出 5～10 个相关段落，然后把这些段落一起塞进 context 里让模型综合回答。
这里有一个很实际的工程问题：如果 context 预算是 4000 token，10 个检索结果每个平均 600 token，总共 6000 token，超出了怎么办？
最简单的做法是均匀截断——每个段落只保留前 400 token。但 Skill 里推荐的做法是动态预算分配：
“「对相关性更高的检索段落分配更多 token，对相关性更低的段落进行更激进的压缩。」
道理很简单：5 个检索结果里，前 2 个相关性远高于后 3 个，均匀截断等于把最重要的部分也砍掉了一半。按相关性分配 token 预算，才是合理的优化。
这个设计决策在 Skill 里叫做「Token Budget Management」，是四种压缩技术的横向管理层。
五个真实会踩的 Edge Cases
说完设计原则，来说 Skill 里记录的 Edge Cases——这些才是真正体现「工程洞察」的部分。
1. 内容本来就装得下——别压缩
听起来废话，但 Skill 专门写出来了，因为这是真实会发生的误操作：有人写了一个流程，不管内容多长，先压缩再提交。结果对于本来就很短的内容，压缩反而引入了信息损失。
规则很简单：先量 token，超了再压，没超就别动。
2. 高技术内容（表格、JSON、代码块）不适合生成式压缩
前面提到代码不能用生成式，这里扩展到了结构化数据。一个 JSON 对象或一个数据表，经过生成式摘要，结构会被打乱，字段可能被「概括掉」。
正确做法：对结构化内容，用选择性剪枝（删掉不相关的字段）或提取式（保留相关行），而不是重新描述它。
3. 多语言内容要分开压缩
如果原始文档里同时有中文、英文、日文，用一个统一的摘要模型处理，不同语言的质量可能差距很大——某些语言在训练数据里的比例低，压缩质量也更差。Skill 的建议是：按语言分段，各自独立压缩，或者专门用多语言摘要模型。
4. 安全信息绝对不能被压掉
这条 Edge Case 写得很直接：安全警告、法律免责声明、医疗剂量信息，无论压缩率多高，这些内容必须原封不动保留。
实现上的建议是：在压缩前先标记「必须保留」的关键词或段落，压缩算法跳过这些部分。这需要在 prompt 层做预处理，不能只靠后处理兜底。
5. 压缩后要验证信息保留率
这条很容易被忽略：Skill 里要求在压缩完成后，做一次「回溯检查」——针对原始内容里的关键问题，验证压缩后的版本还能不能正确回答。
这个检查步骤在工程上增加了延迟，但避免了一种很隐蔽的风险：压缩看起来成功了，内容也短了，但模型在回答问题时却给出了错误答案，因为关键信息已经在压缩时悄悄丢失了。
横向对比：这个 Skill 和「直接让 AI 总结」有什么不同？
很多人遇到文档太长，会直接扔给 AI 一句「帮我总结」。这和 context-compression Skill 的区别是什么？
本质区别是目的不同：让人读的摘要，追求可读性和连贯性；让 AI 处理的压缩上下文，追求信息保留率和 token 效率。这两个目标在很多地方是矛盾的。
一篇「让人读起来很流畅」的摘要，可能把很多具体数字和原文措辞都改掉了——人读着觉得更优雅，但 AI 在做精确问答时，需要的恰恰是那些「不那么流畅」的原始数据。
说一个让我有点震撼的设计细节
Skill 里有一条 Best Practice 很简单，但细想很有意思：
“「压缩完成后，要告诉模型这份上下文经过了压缩。」
理由是：让模型知道自己读的是摘要而不是原文，它在回答时会「适度降低确定性」，比如加上「根据摘要，文档似乎提到……」而不是直接断言。
这里有一个隐含的认知：模型的自我校准能力是可以被 prompt 提示触发的。 告诉它「你拿到的是压缩版」，它对自己输出的不确定性估计会更准确。
这和「chain of thought」的逻辑有点像——提示语改变模型处理信息的方式，不只改变输出内容，还影响输出的置信度。
大多数人在做 RAG 或 long context 处理时，不会专门加这一句话。但如果你的应用对答案准确性要求高，这个细节值得加上。
Skill 的边界在哪里
读完这个 Skill，会发现它在技术层面考虑得很细致——但有一件事它做不到：判断什么信息「在语义上真的重要」。
Skill 里的信息密度评分，是基于关键词重叠和任务锚点的。这能解决 80% 的场景——你问的问题里有「营收」，文档里含「营收」的段落就会得高分。
但有些重要信息不直接用你问的词表达。一个分析用户流失的文档，里面有一段关于「产品迭代节奏」的描述，和流失没有直接词汇关联，但实际上是解释流失原因的关键背景——信息密度评分不会给它打高分，但一个有经验的分析师读到这里会停下来。
这不是 Skill 的缺陷，是所有自动化压缩系统的共同边界：语义理解的深度是有限的。
真正高质量的上下文管理，往往需要人工标注哪些段落是「必须保留」的（Skill 里叫做 must-retain keywords）——而这个标注工作，本身就需要人对文档的深度理解。
AI 接管了压缩执行，但「决定什么值得保留」这个判断，最终还是人的工作。
写在最后
这次拆解的 context-compression，是 h4vzz/awesome-ai-agent-skills 仓库 context-engineering 分类下的一个 Skill（截至 2026 年 5 月，该仓库共收录 70+ 个 Skill，覆盖 14 个分类）。
它之所以有趣，在于它揭示了一件通常被藏起来的事：AI 在处理长文档时，并不是「逐字阅读」，而是在做不断的信息取舍。 取舍的策略，决定了答案的质量上限。
四条策略，适用场景各不同；五个 Edge Cases，每一个都是真实踩过的坑；一个「告诉模型你读的是摘要」的细节，影响的是模型自我校准的准确性——这些设计背后，是大量工程实践的沉淀。
下次你把一份长文档丢给 AI，发现它「漏看了」重要信息，不一定是它不认真，也许是压缩策略用错了，或者 must-retain 没有设好。
理解 AI 怎么「读」信息，是用好 AI 的前提。
