技术 · 深入
上下文爆掉，压缩不是第一步
先把原始输出挡在门外，再谈压缩
Agent 卡死很少是因为窗口不够大，而是工具输出从来没被拦过：一次拉 issue 列表就灌进 59 KB、一张浏览器快照 56 KB，三十轮之后四成窗口被这些原始数据占满，一压缩任务状态就没了。这份做法把顺序倒过来——先在沙箱里跑，只把 stdout 放进来；全量输出留在本地全文索引里，需要时按关键词取回。实测 315 KB 原始输出在上下文里只剩 5.4 KB（约省 98%），原先约 30 分钟就要压缩的会话能跑到约 3 小时。
方法 · 一图看懂
1
先量一次基线 — 记下长会话大概在第几轮开始触发压缩、那一次是哪个工具输出把它撑满的
2
把「读」换成「算」 — 不再整份读进来，让它先写一段脚本算出你真正要的结论
3
让执行落进沙箱 — 工具在隔离子进程里跑，只有 stdout 回到对话里
4
全量留下但不进来 — 被拦下的输出进本地全文索引，需要时按关键词取回
5
会话状态跟着走 — 文件改动 / 任务 / 决定记进同一处，压缩后不靠回灌恢复
6
按统计核对 — 看每次调用「进上下文多少 / 被留下多少」，用数字确认换对了入口
和「压缩」有什么不同
常见的上下文压缩是在已经塞满之后下手——总结历史、丢弃旧轮次。问题是那些原始输出本来就该被挡在门外：它每一轮都要跟着重新发一遍，压缩只是事后补救。这里换的是入口——工具在隔离子进程里跑，只有 stdout 进上下文，原始数据留在沙箱外的可检索库。一句话：不是把进来的东西压小，是不让它进来。
为什么不是「用 LLM 总结」
这套做法不做 LLM 调用：过滤在本地运行时（JavaScript / TypeScript / Python / Shell 等 12 种）里就地完成——让脚本先算，只把结论打印出来。检索侧同样是纯本地全文索引（SQLite FTS5 + BM25 排序），取回本身不额外烧 token。它的设计前提是那句 Think in Code：让模型写分析脚本，而不是把原始数据读进来再分析。
原理 · 为什么有效
上下文被吃掉的路径有两条：工具定义在入口占位（装到 81 个工具时，光定义就吃掉约 14 万 token，约占 20 万窗口的 72%），工具输出在出口堆积（每条命令的原文落进对话后，会在后续每一轮被重新发送）。这份做法只解决第二条，而且从源头解决：把「跑」和「读」拆开——脚本在隔离子进程里跑，跑完只把结果带出来。数据没有消失，它进了本地全文索引，需要时按关键词检索取回。所以省下的不是「精度」而是「冗余」：该看的一条不少，不该跟着重发的全部留在门外。这才是「315 KB 变成 5.4 KB」的真相——不是压缩比高，是大多数内容本来就不该进来。
适用场景
适用：长时间跑同一个仓库的编码会话；单次工具调用就会吐几十上百 KB 的场景（拉 issue / PR 列表、跑整份测试、抓网页快照、读大日志）；已经在为「会话跑到一半被压缩、任务状态全丢」反复重启的人；同时用多个编码客户端、希望一处装处处生效的人。不适用：① 会话短、工具调用少的用法 —— 积累量根本没到瓶颈，装了看不出差别；② 想靠它扩窗口的 —— 它不扩窗口，只是少往里塞；③ 需要 OSI 认可开源许可的团队 —— 它的许可为 Elastic License 2.0（source-available：可读可改可自用，但不允许当作托管服务转售）。
自测 · 5 问
我的会话是不是经常跑到中途被压缩、然后任务状态就断了？
我最近一次上下文暴涨，源头是「我要求它做的分析」，还是「某个工具吐出来的原始输出」？
我有没有在读整份文件之前，先让它写个脚本把答案算出来？
被挡在外面的那些原始数据，我有没有一个地方能按需查回来？
我是不是把「扩窗口」当成了「清理入口」的替代方案？
怎么上手 · 验证步骤
先做一次量化：挑一个你常跑的长会话，记下它大概在第几轮开始触发压缩、那一次是什么工具调用把它撑满的。再按三步换入口：① 装上沙箱插件并注册给你的 agent（MCP 方式，先跑一次自检命令确认装对了）；② 下一次要读大文件时不要直接读 —— 让它写一段脚本先算出你真正要的结论（例如「这个目录每个文件多少行」「这份日志里有多少条 404」）；③ 跑完用它的统计命令看一次：进上下文的是几 KB、被留在索引里的又是几 KB。停之前先确认取回路径是通的：从被拦下的输出里按需搜回一段 —— 能搜回来才叫「没丢」，搜不回来就是把数据扔了。
做完回看两件事：① 同一条任务，压缩出现的轮次有没有明显后移（而不是被压缩后你更频繁地重启）；② 抽一次被索引的输出，手检三条 —— 按关键词搜回来的到底是不是你要的那几条、内容有没有被截断、能不能追溯回原始来源。两条都过，才算把「入口」真的改成了「沙箱 + 索引」；只快不查，等于把风险从「看得见的爆窗」换成了「看不见的漏读」。