[Bug] GUI 自动化（computer-use）长循环任务在 26 分钟内消耗 7,266 万输入 token、耗尽两个 5 小时配额窗口：缺少中途 compact，且缓存命中不计入配额保护

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

计费 / 配额 · Billing / Quota

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

环境

• ZCode 桌面端 0.16.5（macOS arm64）
• 模型：GLM-5.3（builtin:bigmodel-coding-plan），provider open.bigmodel.cn
• 会话 ID：sess_cf5f27d4-c29a-4242-bdfa-15f25c5a0f4e，2026-09-14 17:07–17:33 UTC

任务

用 computer-use 把 7 个网站项目的配置（每个约 12 个字段：slug、名称、首页 URL、描述、链接页清单、模型、语气、关键词、联系邮箱等）逐个填入 Chrome 扩展（Backlink Scout）的 dashboard 表单并保存。当时录入的项目：

项目	站点	类型
Pixarmory	https://pixarmory.org	AI 图像工具
AllCute	https://allcute.net	符号/文字工具
PhotoMerge	https://photomerge.app	图片合并工具
AdoptMeValues	https://adoptmevalues.trade	游戏价值查询
Mynoutore	https://mynoutore.com	在线小游戏
Shotra	https://shotra.app	视频生成工具
Echoryte	https://echoryte.com	转写/字幕工具

用量（本地 usage 数据库实测）

指标	数值
模型请求	252 次
工具调用	248 次（get_app_state×109、set_value×78、left_click×25、screenshot×9 等）
输入 token 合计	72,661,335（平均每次请求重发约 288k）
其中缓存命中（cache read）	72,113,728（99.2%）
缓存写入（cache write）	0
输出 token 合计	34,801

分 turn 看：58/99/79/16 次请求分别消耗 4.82M / 24.29M / 34.75M / 8.81M 输入 token。

复现步骤 · Steps to reproduce

1. 准备一个多字段的 Chrome 扩展 dashboard 表单（本例为 Backlink Scout，7 个项目 × 约 12 字段）
2. 让 ZCode agent 用 computer-use 逐项目填写并保存
3. agent 进入 get_app_state → set_value → get_app_state → … 循环：每次表单变化后元素 index 偏移、旧 state 作废，观察/动作比接近 1:1（109 次观察 / 103 次动作）；248 次模型响应每次恰好 1 个工具调用，无并行批处理
4. 上下文随 109 棵 AX 树（每次约 200 个元素）+ 9 张截图持续膨胀，全程没有任何中途 compact
5. 约 13 分钟后触发第一次 429 配额耗尽

期望表现 · Expected behavior

1. 上下文接近阈值（如 60–80%）时在 GUI 长循环场景主动 compact，而不是等配额耗尽后才触发
2. 缓存命中的重复输入在配额计量上有所豁免/打折，或配额临近时向用户/agent 预警——目前缓存对配额零保护，长循环任务实际按「全量上下文 × 往返次数」平方级烧配额
3. 429/配额事件作为系统信号注入（暂停/询问用户/降级），而不是让 agent 盲跑
4. computer-use 工具改进：get_app_state 支持按窗口/role 过滤；动作工具默认 return_state:"compact"；元素寻址用稳定句柄而非易失 index

实际表现 · Actual behavior

• 17:20:03 首次 429：[1308][已达到 5 小时的使用上限。您的限额将在 2026-09-15 04:32:04 重置]（会话开始后 13 分钟）
• 17:28:04 第二次 429（同类，重置时间 06:21:25）——第二个配额窗口也耗尽
• 17:33:34 唯一一次 compact 请求（querySource:"compact"）被取消，任务中断；此前整个会话没有任何一次上下文压缩
• 4 次 turn.failed（2 次用户取消、2 次上述 429）
• 工具本身合计仅耗时 28 秒，时间与 token 全部消耗在全量上下文重发上
• 26 分钟内输入合计 72,661,335 token，其中 99.2% 是缓存命中的重复上下文，但 5 小时配额照常计满——缓存对配额零保护

与 #322（长会话续用额度异常加速）相关但场景不同：本例是单次会话内 GUI 自动化长循环 + 无中途 compact 导致的平方级输入消耗，供交叉参考。

ZCode 版本 · ZCode version

0.16.5

设备 / 系统 / 浏览器 · Device / OS / Browser

macOS 26.6.2

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

No response

The report names no repository files or tests. Start with the local usage database records for the 252 model requests and the querySource:"compact" and 429 events; done means reproducing the long computer-use loop with bounded context growth, appropriate quota handling for cache-hit input, and a controlled response to quota exhaustion.