第 45 章：Computer Use 上下文管理
截图预算不是一个数字。文本观察、浏览器截图和用户提供的图像价值不同，也必须拥有不同生命周期。
公开源码快照：实现细节取自 Kocoro 公开
origin/main的4ec6772提交，复核日期为 2026-07-27。具体常量应以当前源码为准。
45.1 为什么 Computer Use 会快速膨胀上下文
浏览器循环每一步都可能加入 DOM Snapshot、Accessibility Tree、截图和模型回复。如果之后每轮都重发全部历史，Prompt 成本会随完整轨迹增长，但下一步通常只依赖当前页面。
一个全局图像上限无法解决所有问题。批量视觉任务可能需要很多用户图像，而浏览器 Agent 通常只需要最新 Viewport。文本观察也必须单独设置滑动窗口，因为它们不是 Image Block。
45.2 四种独立控制
| 控制 | 快照默认值 | 解决的问题 |
|---|---|---|
| 文本观察窗口 | 3 | 只让近期浏览器/GUI 文本保持完整 |
| 单次观察文本上限 | 24,000 Rune | 限制一个超大 DOM 或页面快照 |
| 浏览器截图保留 | 1 | 保留当前 Viewport，把旧 GUI 截图替换为占位符 |
| 全局图像消息上限 | 50 | 保护非浏览器视觉与批量图像任务 |
这些数字是工作负载选择，不是普遍常量。真正重要的是每个控制只负责一种失败模式，保留 tool_use_id 配对，明确告诉模型内容已被替换，并保证重复过滤不会不断改变 Prompt 前缀。
45.3 生命周期与验证
从 Prompt 中裁掉截图，不等于删除底层截图文件。上下文组装、审计保留、本地清理和用户上传所有权是四套独立策略。内容被移除或截断时也必须显式标记，否则后续推理无法审计。
45.4 实现检查表
- 区分浏览器/GUI 观察、用户上传图像和普通 Tool Result。
- 保留最新可行动状态，并加入明确的截断标记。
- 测试嵌套 Image Block、多语言 Rune 限制、幂等性与缓存稳定性。
- 根据真实任务成功率和 Token Trace 调整预算，不要根据单次 Demo 拍脑袋。
45.5 本章结论
Computer Use 上下文管理本质是观察策略：保留仍可能改变下一步行动的信息，摘要或占位陈旧状态，并让其他图像工作负载使用自己的预算。