技术 · 深入
压完之后，你还取得回原文吗？
入口改动之外的另一半：压结构，不压意思
前一页讲的是「不让它进来」——沙箱拦输出、本地索引按需取回。这一页补另一半：当某些东西确实必须进来时，怎么压。关键分野是可逆与不可逆：摘要是有损的（读完就没了原文，还可能连语义一起侵蚀），而 2026 这一批工具走的是无损那条路 —— 把结构压掉、把语义留下。三种机制已经被做出来了：对 JSON 做schema 因式分解（同一套字段名只出现一次，压 60~90%）· 对代码做骨架抽取（AST 剥掉函数体，只留签名 / docstring / import）· 对原始件做句柄化（全文留本机缓存，提示词里只放一个能取回的引用）。这一页给的不是「装哪个」，而是三条判据：哪些能无损压、压完必须验什么、什么时候该退回有损摘要。
方法 · 一图看懂
1
先分可逆与不可逆 — 摘要那条路是有损的；这一页讲的全部动作都必须满足「原文还取得回」
2
只压三类东西 — 结构冗长的 JSON · 只要骨架的代码 · 只用到一小段的整份文件
3
压的东西要能追溯 — 每一段被压掉的原文，必须留一处可寻址的落点（缓存 / 索引 / 原文件）
4
取回路径先验通再压 — 中途去取一条出来，取得到才算「没丢」
5
语义有损就退回摘要 — 需要跨段归纳、需要取舍的，⛔ 不要交给无损层，那是摘要的活
一 · 把「压」拆成三种机制，别混着谈
机制一 · 结构因式分解：同一份 JSON 里重复出现的字段名与嵌套结构，只保留一次模式、把值抽成表 —— 它压掉的是冗余，不是内容。机制二 · 骨架抽取：一份代码文件里，函数体往往是几千行而只在某一步被用到；先只把签名 / docstring / 装饰器 / import 送进去，让 agent 先看清「这个项目怎么组织」，真要看实现时再按需取那一段。机制三 · 句柄化：整份原始件留在本机磁盘或本地索引里，提示词里只放一个轻量引用（形如「第 N 段在 <路径>」），要用时按引用取。三种机制的共同点 = 被压掉的东西都有确定的落点；不同点 = 压的是什么（冗余 · 实现 · 全文）。
二 · 无损层与摘要层不是替代关系，是分工
无损层擅长的是「同一份东西本来就不需要整份进来」—— 大 JSON、长日志、整仓代码、抓下来的网页快照。它保证的是不丢内容，代价是需要一处落点与一条取回路径。摘要层擅长的是「必须跨段归纳」—— 二十轮对话的取舍、一长段讨论的结论、多来源信息的合并。它省得多，代价是不可逆（而且如上一页所述，它会连不该丢的一起丢）。⇒ 判据一句话：「我后面还需要那份原文吗？」需要就走无损；不需要、只要一个结论就走摘要。把该走摘要的硬塞进无损层，你会得到一份长得像原文的清单和一个更贵的账单；把该走无损的交给摘要，你会得到一段读起来很顺、但再也对不回原件的概述。
三 · 压之前要钉死的两条验收
第一条 · 落地性：被压掉的内容必须能按引用取回，并且取回的那一条要与原文可逐字对照（不是「意思差不多」的重写）。第二条 · 可追溯：从一段被压缩的引用，能不能回到它最初来自哪个文件、哪一轮、哪次命令输出 —— 回不去，那么出错时你无法判断是压缩压坏了，还是源头本来就错。这两条要在压之前就定好，不能等出了事再补 —— 因为无损失败的表现不是报错，而是你以为它读了、其实它只读了一个摘要句。
原理 · 为什么有效
上下文被吃掉其实有两条完全不同的路径：一条是量（工具输出、文件全文、抓取的网页），另一条是精度（为了让东西装得下而做的有损改写）。前一页解的是量 —— 不让它进来。这一页解的是精度 —— 进来之后别动意思。分开看就明白了：有损压缩的每一次动作都在赌「这段我以后不需要」；而无损压缩不需要赌，它只是把「现在就送」延后成「要用时再取」。所以它的收益随会话长度复利（同一份原始件不再每一轮重新发一遍），风险却是单一且可验的：取回路径通不通。这也是它与你已有的压缩习惯最大的区别 —— 你不需要判断「哪些重要」，只需要保证「都能取回」。
适用场景
适用：单次工具调用就吐几十上百 KB 的会话 · 要在整仓代码里长期工作的编码 agent · 手里有一批结构化程度高的数据（JSON / 报表 / 日志）· 已经装了减法类工具但发现「压缩完反而丢细节」的人。
⛔ 不适用：会话短、工具调用少（积累量没到瓶颈，装了看不出差别）· 指望它扩窗口的（它不扩窗口，只是不往里塞冗余）· 需要跨段归纳与取舍的场合（那是摘要的活）。
⚠️ 前提：你必须有一处能长存的本地落点（磁盘缓存 / 本地索引 / 原文件本身），并且认下「压掉的东西仍然占着你的磁盘」。
自测 · 6 问
我分得清「这次压缩是可逆的还是有损的」吗？
被压掉的那一段原文，我能在三十秒内指出它在哪吗？
我最近一次靠摘要接力的长任务，能不能逐条回溯到原始件？
我有没有把「需要归纳的场合」也交给了无损层（那会得到一份很长的清单）？
我知道自己装的那一层压的是冗余 · 实现 · 还是全文吗，还是只知道它「省 token」？
取回路径我实测过几次？还是一次都没试过？
怎么上手 · 验证步骤
第一步，先量一次真实体积：挑一个你常跑的长会话或一类常吐大输出的命令，记下它的原始体积和你实际需要的信息量（例如「这份日志 45 KB，我只要 404 那几行」）。第二步，只选一种机制先试——结构性最强的先上（有 JSON 就用结构因式分解，读代码多就先用骨架抽取），别一次装三层。第三步也是最重要的一步：先验取回路径。压完之后立刻去取一条被压掉的内容，与原文逐字对一次；取不回来，说明你装的不是无损层，而是在丢数据。第四步，跑一周之后回头比两件事：同一任务的 token 账单有没有下降，以及你有没有因为「反正取不到」而改变了自己的提问方式 —— 后者是隐性代价，出现就说明这一步装错了位置。
自检动作：写下你这一层压掉的三种内容各一条实例，并各自给出「原文在哪」。三条里有一条写不出落点，这一层就不能算无损 —— 它只是把「看得见的爆窗」换成了「看不见的漏读」。