第 4 卷

10 11[... tool result middle pruned ...]

12

240 个字裁成 129 个字：中间的 150 个字被换成那行 39 个码点的标记，净省 111 个字（150

• 39）。给模型看的，从一大段全文变成了“开头 + 标记 + 结尾”，那行标记的作用就在这

儿：让它不至于把剩下的头尾当成全文。

日志那一段是这件事的另一半：原 seq 3 一条没动，裁剪只往账上追加了两笔，seq 4 记下遮掉了谁、它值多少 token，seq 5 才是替换件。seq 6 的 turn/end 压在最后，是因为自动

压缩的标记必须落在开着的轮次里（压缩那节讲过这条要求），所以这一轮最后才闭合。

阈值（thresholdChars，默认 8192）、头部保留（headChars，默认 4096）、尾部保留（tailChars，默认 1024）都是可配的。示例的文本只有 240 个字，所以把阈值调到

200、头尾调成 60 / 30，得到的正是“240 → 129”（60 + 39 + 30：中间的 39 就是那行标记，35 个可见字符加上前后各两个换行）。

本讲小结

其中装不下分两种情况，压力是慢慢逼近窗口上限，得靠计量提前判出来；溢出是已经越线，不用量，请求被拒那一刻就已经确认。

两道手段则各管一段：裁剪是自动压缩的前置步骤，动手前先把超长的单个工具结果在 surface 上裁成“头 + 标记 + 尾”，旧的完整事件一条不丢；压缩最后兜底，把旧历史压成一

个 checkpoint 节点，全程由 compaction/start、summary、end 三个只写日志的事件锁住，surface 上唯一的变更是一条 replace 进摘要的 user/message。这两个动作和上

一讲的“配平”落在同一个原则上：账本只往后写，不往回改。

这背后真正的变化是，你不再把“上下文太长”当成一次需要就地改写的清理，而是把它拆成两道、只做追加：超长的工具结果先收一次，旧的整体再压成一个 checkpoint 节点；让“变短”

只发生在 surface 清单上，账本一页不撕。

这，就是上下文压缩的本质，压的从来不是记在账上的事实，而是模型当下要看的那份 surface 清单。

到这里，日志这条线上的“长度”问题也就落地了：裁剪收一收，压缩压一压。但这只是单个会话的账；磁盘上还攒着几十上百个会话。账本一多，就得能翻、能找，还能顺着父子关系一路

摸下去。下一讲，我们讲跨会话查询：这些会话记录怎么被读、怎么被搜、怎么被追溯。

注：本讲 GitHub 链接

思考题

动手实操：在 compact-demo.ts 里，把 TURNS 从 4 改成 8，再跑一次 npm run start:ch10:compact。你会看到压缩前的 surface 消息数从 8 变成 16、压缩后仍是 2，

而“被遮蔽的事件 seq”从 7 条变成 15 条（估算遮蔽 token 从 362 涨到 774），新落的事件也从 seq 25–28 挪到 seq 49–52。想一下：为什么遮蔽的那串 seq 变长了？

格；这份示例没有工具结果，碰不到这种情况），历史越长，被遮蔽的那串就越长。

小改动：把 prune-demo.ts 里的 THRESHOLD 从 200 改成 400，重新跑。这次“裁掉几条”会是 0，全文原样打出来，为什么？提示：那段工具输出一共 240 字，而裁剪是超过阈值

才动手，日志那一段也会跟着少两笔，只剩 turn/end 收尾。

欢迎把你的运行结果分享出来。如果你觉得这节课对你有帮助，也欢迎分享给其他朋友，我们下节课再见！

© 版权归极客邦科技所有，未经许可不得传播售卖。页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。