现状的浪费#

当前 GUI agent（如 computer-use 模式）的计算分配策略是”每一步都用同一个大模型”。无论是：

• 点击一个明确的”确认”按钮
• 在已定位的输入框输入已知文本
• 关闭一个 cookie 弹窗

还是：

• 面对未预期的错误对话框，决定是重试还是换路径
• 在复杂表单中判断哪个选项对应用户意图
• 在页面结构变化后重新定位目标元素

都在烧同样的 token 和延迟。

论文方案#

[arXiv:2604.27151] 提出 event-driven step-level cascade：

1
默认：小模型（快速、便宜）
2
          │
3
          ├── Stuck Monitor 检测到进展停滞 → 升级大模型
4
          │
5
          └── Milestone Monitor 检测到语义检查点 → 升级大模型

两个触发器：

为什么有效#

GUI 操作的错误分布极不均匀：

• 90% 的错误集中在 10% 的步骤（决策点、异常处理点）
• 其余 90% 的步骤几乎从不出错（确认按钮、已知输入）

把计算预算集中在高风险步骤，其余用最小模型完成，总体准确率不降反升——因为省下的预算可以给关键步骤更多 thinking token。

实践思考#

这个模式不限于 GUI agent，对任何多步骤 agent 都适用：

1. 编码 agent —— 创建文件、写 import 语句用小模型；设计架构、处理 bug 用大模型
2. 工作流引擎 —— 模板化的节点用轻量模型；需要创造性判断的节点升级
3. 对话 agent —— 简单问答用快模型；复杂推理、情感分析用强模型

核心思想：算力分配应该是动态的，由运行时信号驱动，而不是静态配置。

参考#

• Step-level Optimization for Efficient Computer-use Agents