深入Caveman Log压缩器:为什么丢弃INFO级别日志,保留85-95%压缩率

发布时间:2026/8/31 9:31:06
深入Caveman Log压缩器:为什么丢弃INFO级别日志,保留85-95%压缩率 深入Caveman Log压缩器为什么丢弃INFO级别日志保留85-95%压缩率【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/cavemanCaveman 是一款让 Claude Code 等 AI 编码代理像穴居人一样说话的开源 Token 压缩工具其内置的 Log 压缩器Log Compressor专门处理构建输出与运行日志丢弃海量的 INFO 级别噪音只保留错误、堆栈和头尾上下文目标压缩率高达 85–95%。本文带你理解它敢删的原因、怎么删的规则以及被删日志如何一键找回。一、为什么日志是 Token 黑洞当 AI 代理执行pnpm test或make build后把输出塞回上下文时往往是这样一种结构[INFO] starting [INFO] step 1 ok [INFO] step 2 ok ... (几百行) ... [ERROR] kaboom: undefined symbol at frame (file.go:10)真正决定下一步怎么办的只有那几行[ERROR]和堆栈帧其余[INFO] step N ok对模型来说信息密度接近于零却实打实地消耗 Token 费用。这就是 Caveman Log 压缩器的设计起点日志的 90% 是噪音噪音恰好就是压缩率的空间。官方对各压缩器的目标压缩率有明确表格Log 类型位列最激进的一档检测类型保留内容目标压缩率json键、结构、错误/消息子树70–90%log错误、堆栈、首尾行丢弃 INFO 与进度噪音85–95%code导入、签名、类型40–70%来源README.md#L166-L175二、Log压缩器只保留三类关键行核心实现在 engine/compressors/log.go规则非常直观错误信号行正则匹配ERROR / FATAL / PANIC / EXCEPTION / TRACEBACK / FAIL / WARN等关键词以及堆栈帧特征at ...、File ...、.go:123、caused by一行不少全部保留头部 2 行 尾部 2 行即使全是 INFO也保留首尾各 2 行给模型开始于什么、结束于什么的上下文锚点查询相关行当代理带着问题如 websocket reconnect来时用 BM25 相关性打分额外捞出最多 16 行与查询最相关的日志见 engine/compressors/relevance.go#L12-L16。其余连续的 INFO/进度噪音行被整段折叠成一行省略标记… 50 lines elided (caveman) …折叠不是简单计数。engine/compressors/invariants.go 中的类不变量摘要会从被删行中提取可验证的事实写进标记里——比如被删行的status字段只有三个值就会标注status: fulfilled×15 shipped×3 processing×2数字字段则给出namemin..max的精确边界。这样模型看一眼标记就知道被删的那 50 行到底长什么样而不用盲目恢复。三、删了也不怕CCR 存储兜底 幂等保证丢弃 INFO 之所以安全靠两道保险CCR 优先Content-Addressed RecoveryLog 压缩器被标记为 S4 级有损压缩见 engine/safety/safety.go#L23-L25原始字节在任何转换发出前已落盘到本地内容寻址存储代理随时可用caveman_retrieve工具按句柄取回原始日志字节级一致幂等性重复压缩不会产生第二层省略输出与首轮逐字节一致测试用例TestLogIdempotent见 engine/compressors/log_test.go#L44-L54。这一点很关键——输出抖动会击穿提供商的前缀缓存反而推高成本。此外还有几个细节体现工程克制小于 4 行的日志不值得压直接放行含非法 UTF-8 的疑似二进制内容一律透传CRLF 换行原样保留。四、85-95%压缩率如何验证想看真实效果无需读源码跑一次统计即可caveman stats # 按内容类型查看压缩器实际做了什么 caveman shrink -- pnpm test # 实时压缩命令输出可字节级恢复测试套件 engine/compressors/log_test.go 覆盖了核心场景50 行[INFO] step N ok 1 行[ERROR]的日志压缩后错误行必须保留、省略标记必须出现、输出必须小于输入、二次压缩必须幂等。值得一提的是当日志体量大到删了也不够时Caveman 还有 Pixel 模式——把 4 万行级别的长日志渲染成像素化 PNG 页面交给视觉模型读取图像不按 Token 计费五、小结丢弃INFO背后的三个原则信息密度优先错误和堆栈是日志里唯一答案依赖的行INFO 进度行只是氛围可恢复才算删CCR 存储保证每一次有损压缩都有字节级回退路径标记要能自证省略标记携带从被删行计算出的事实计数、范围、枚举模型据此判断要不要恢复而不是恢复一切。这正是 Log 压缩器敢把目标定在 85–95% 的底气。想深入了解整体架构可阅读 docs/technical/engine.md 与 docs/technical/cache-and-rewriter.md各压缩器源码集中在 engine/compressors/ 目录。【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考