computer use 或者 browser use 这些上下文压缩机制是咋处理的？

回复 群友 7309： cu 和 bu 处理上下文的方式有一个共同难点：每一轮的“观察”都很大，例如一张全屏截图就占几千 token，而几十轮下来就会超出模型窗口。但两者的处理方式不同，bu 比 cu 好处理得多。 先讲 bu。bu 的主要上下文不是截图，而是结构化页面状态。以 browser-use 为例，每一步会把 DOM、DOMSnapshot、Accessibility Tree 三棵树融合成增强节点，再序列化成带数字索引的 XML 树发给模型：只有带索引的元素可交互，`*` 标出上一步新生元素，裁剪不可见节点和空容器。这本身就是一次压缩：一个几万节点的页面，序列化后可能只剩几百行。历史部分同样会裁剪：早期步保留“我点了什么、拿到了什么结果”的摘要，最近几步保留完整动作和结果，中间过时的页面快照直接丢弃，页面状态每轮都重新采集，旧快照没有保留价值。任务计划另外保存（todo、plan 之类），这样历史即使被压缩，也还能知道进行到哪一步。 cu 则麻烦得多，因为屏幕像素本身就是信息，压缩等于丢信息。常见做法有几种，通常组合使用：一是降低采样，不把每一步都截图存进历史，只保留最近两三张图，更早的只保留文字结论，比如“打开了设置页，在第二栏”这类自然语言描述；二是多模态摘要，把旧截图交给模型转成文字描述再丢掉原图，因为文本比图像省 token 得多；三是分辨率与区域裁剪，只截变化区域或界面所在的窗口，而不是整屏；四是外部状态，把点击坐标、窗口结构、可访问性树存成结构化记录，让模型以后从状态里查，而不是翻看图片历史；五是有意识地使用“只读最近一步”的无状态循环，每轮给当前截图、任务目标和一个简短的进展备忘，不与过去几十张图片拼接。 真正的问题不在于压缩比，而在于压缩会丢掉哪些内容。Factory 研究过这件事，他们的结论值得借鉴：结构化的摘要远胜自由摘要。他们的做法是按固定栏目写摘要，分别是本次会话意图、修改过哪些文件、做过哪些决策、下一步是什么。每次压缩只总结新截断的那一段，再合并进持久摘要，而不是从头重写。这样多次压缩后，关键信息不容易消失。他们还发现，所有压缩方法在“哪些文件被改过”这一维度上得分都很差（满分 5 分，只有 2 分多一点），说明这类追踪不应依赖摘要，而应单独维护结构，比如文件索引、已访问 URL 集合、已完成步骤清单。 因此，判断实现质量的标准是压缩时保住了什么，而不是压缩了多少。具体要看三件事：任务的当前状态是否随时可用，做过什么是否记得，以及跳过哪些信息是有意为之的；压缩了多少反而次要。定向测试非常有效：压缩后问模型“群友 8334那个报错是什么”“我们最后决定用哪个方案”“现在进行到哪一步”，答错就说明摘要丢了不该丢的内容。