同一个 bug 修到第 28 轮，30 款 AI 代理产品里谁把关键端口弄丢了

第 3 轮，编码 agent 跑测试，日志里有一行 connection refused，db-primary，端口 5433。第 28 轮，它要写修复，需要这个端口。中间 24 轮读文件、grep、改代码、跑小测试。第 17 轮，上下文管理机制触发。

Sergii Makarevych 用同一个 30 轮编码 ticket 做了回放。ticket 编号 #4821，集成测试在 CI 里报数据库错误。8 种策略，三十多款产品，模型调用用 Claude Haiku 5.5，token 计数用 o200k tokenizer，账单统一按 Claude Sonnet 5.5 的公开价格折算，输入每百万 token 2 美元，缓存读十分之一，输出不算。数字只描述这张 ticket，不代表你的工作负载。

基线是 Append everything，什么都不删。三十轮输入账单 0.77 美元，峰值窗口 156,635 tokens，缓存命中率 93.5%。它最便宜，因为它从不改前缀，几乎每个 token 都是缓存读。它也最危险，因为第 28 轮的窗口大小已经超过 LOCA-bench 测到准确率开始掉的范围。这张 ticket 上，端口还在窗口里，模型用上了。

8 种策略的结果：

数字里最刺眼的是截断。它只省了 2%，却把端口和旧消息一起丢了。清空更省，省了约五分之一，也把端口丢了。原因是测试日志属于被清空的工具结果，而模型第 4 轮的回复没有重复这个数字。摘要压缩保住了事实，但摘要调用按未缓存价格读了一遍整个窗口，所以只省了约十分之一。带指令的摘要让错误块和 pytest 统计逐字留下，形式更好，账单几乎没变。

trim 和 offload 最便宜，账单只有基线的五分之一。它们能保住端口，靠的是位置和存储。trim 留下日志头尾，错误行刚好在开头。offload 把大结果写进文件，窗口里只留预览和路径。第 28 轮模型打开三个卸载文件，没打开正确的那个。事实可恢复，agent 没恢复。这个区别很重要。机制决定事实在不在，模型决定用不用。

isolation 把测试运行放进子代理，主窗口只拿回两千 token 的报告。端口在报告里，模型用上了。但五次子代理调用多花 52,573 tokens，主窗口还是涨到 109,416，因为文件读取没有委托出去。子代理适合输出大、结论短的任务，比如跑测试、搜网页、扫目录。不适合编辑一个父代理随后必须理解的文件。

Sergii 的结论不复杂。多数产品默认在十万 token 左右清空或压缩，这是最可靠地移除早期事实的机制。压缩只有在摘要提示明确要求保留精确值时才保住事实，而摘要调用成本约等于一次未缓存的整窗读取。便宜策略改的是进入窗口的内容，需要 agent 主动取回被移走的东西。

市场地图分四层。模型 API 做压缩和清空，动作最少，控制也最少。Anthropic Messages API 有服务端压缩、工具结果清空、思考清空、客户端 memory tool 和延迟加载的工具搜索。OpenAI Responses API 有阈值压缩和压缩端点，输出是加密项，外部读不了。xAI 有开发者手动触发的压缩端点，没有自动阈值。Gemini 没有压缩，答案是一百万 token 窗口和缓存。框架中间件给控制，但默认最少。Deep Agents 在窗口 85% 时摘要，超过 20,000 token 的工具结果卸载到虚拟文件系统，子代理隔离。Letta 在历史放不下时压缩，滑动窗口摘要 30%，还有可搜索的淘汰消息和 pinned memory blocks。Mastra 在 30,000 token 时让观察 agent 把原始消息变成笔记。编码 harness 默认最多，文档最少。Claude Code 在模型限制时压缩，清空旧工具结果，分批移除旧图片，子代理嵌套三层。Codex CLI 在窗口 90% 时压缩，然后只保留用户消息到 20,000 token 加摘要。Gemini CLI 在半窗口压缩，工具输出超过 40,000 字符就截断并写文件。Cursor 在活动窗口顶部附近摘要，长 shell 和 MCP 输出移到文件。独立压缩器和网关是唯一能压缩 token 的地方。LiteLLM 在每个 provider 上 polyfill Anthropic 的清空编辑，配置摘要模型做压缩，还能调用 Compresr 或 Headroom 做 guardrail。Headroom 用 JSON crusher、代码压缩器或学习型压缩器处理工具结果，按哈希保留原文，给模型一个 retrieve 工具。

缓存是多数产品页不提的部分。每个 provider 只对字节一致的前缀给缓存折扣。agent 循环本来是理想客户，每轮往同一个前缀后面追加。上下文机制一编辑历史，前缀失效，编辑点之后的内容要重新写一次缓存。Sergii 的 ticket 上，清空把缓存命中率从 93.5% 降到 88.2%，压缩降到 86.9%，因为第 17 轮的编辑重写了一次前缀。trim 和 offload 保持 93%，因为它们只在结果进入窗口时改一次，之后不再动。isolation 主窗口保持 93.4%，每个子代理自己开缓存。Manus 的做法更彻底：禁止时间戳和非确定性序列化，从不编辑之前的动作或观察，只 mask 工具可用性，不删除工具定义。ACON 论文从成本侧得到同样结论：压缩历史很少省钱，因为破坏缓存；每个观察到达时压缩一次更划算。

回复里有人问，compaction 有没有编造细节，还是只检查了关键事实是否存活。有人问，如果第 28 轮需要的事实中途被修正过，摘要会不会保留旧值、丢掉修正。有人问，压缩是否保存了决策的原因，而不只是数字。还有人问，清空工具结果前 27 轮都正常，第 28 轮静默失败，这是最差的失败方式，产品会不会提前告诉你它扔了什么。Sergii 在推文回复里没有展开这些。他引用的 SelfCompact 研究给了一个提醒：当摘要改变答案时，约 40% 的变化是从对到错；固定间隔摘要的得分低于让模型自己选择摘要时机。LOCA-bench 的数字更直接：没有上下文管理时，最强模型在 8,000 token 环境里准确率 96.0%，64,000 token 降到 65.3%，128,000 降到 34.0%，256,000 降到 14.7%。清空工具结果在 128,000 token 档只提升 1.3 到 2.7 个百分点。程序化工具调用把某个模型从 38.7 拉到 49.3。

回复里还有一位开发者贴了 Kora，一个 Apple Silicon Mac 上的开源应用，把 Claude Code、Codex、OpenCode、Antigravity 编排成 lead 加 worker，用本地代码图在 agent 开始搜索之前把相关声明塞进上下文。它的思路和 Sergii 的测试互补：Sergii 比较读完之后怎么修剪，Kora 想减少 agent 一开始要读的东西。Kora 的 worker 各自跑在独立 git worktree，合并前用代码图检查那些 git 能干净合并、但会互相破坏的改动。它不建账号，没有遥测，MIT 许可。

如果要从这套材料里拿走一个实践形状，Sergii 的建议是：入口做一次大小裁剪，给事实一个固定存放处，阈值机制做兜底，长输出短结论的子任务交给子代理。每个栈都有这四件事，产品差别在它给你哪几件。

更具体的检查顺序：

先找决策点。模型 API、框架中间件、编码 harness、代理网关，每层只能编辑它看得到的窗口。网关看不到 harness 的子代理。

一个机制管大小，一个机制管事实。大小用 trim、offload 或压缩。事实用 pinned block、memory 文件、项目规则文件、子代理报告。别让摘要独自承担事实保留。

把默认触发阈值调低。默认十万 token 清空，或 90% 窗口压缩，往往在准确率已经开始下降之后才动作。LOCA-bench 的退化从三分之一窗口左右就开始了。

摘要指令写清楚要逐字保留错误行、文件路径、数字。Sergii 的默认摘要把端口标成可能的端口不匹配，未验证。自定义指令让错误块和测试统计原样留下。

清空要批量，保住缓存前缀。测缓存命中率，和 token 节省百分比放在一起看。只报省 token、不报命中率的产品页，数字要打折。

上下文管理先要回答的是哪一天、哪一轮、哪个事实会被扔掉，以及你有没有地方把它捡回来。省多少 token 排在后面。