如何判断小参数 GUI Agent 的瓶颈是否来自模型容量？

核心回答

不能仅凭小参数GUI Agent失败，就认定模型容量不足。任务经过观察、目标定位、规划、动作执行和状态反馈，任一环节都可能成为瓶颈。应先做分阶段替换与受控对照，确定在哪一环提供正确输入后任务明显恢复，再评估扩模是否值得。

例如给出正确子目标后仍点错，优先检查Grounding和坐标；直接执行正确动作也失败，优先查环境与执行器；提供清晰状态和候选元素后仍无法选择合理步骤，才更接近决策能力问题。

先排除观察与接口故障

核对截图是否及时、缩放是否保留细节，目标是否被遮挡，视觉坐标与真实屏幕是否使用相同尺度。检查小字OCR、元素边界、可访问性信息及候选动作是否完整。点击后的等待和状态检测同样重要：页面尚未响应就继续行动，会制造看似推理错误的轨迹。

用标准动作回放测试环境，记录实际点击位置、响应和最终状态。若标准轨迹也不稳定，先修环境；否则再比较模型，避免把执行噪声误当容量上限。

用替换实验缩小范围

保留任务与环境，分别提供人工核对的子目标、正确元素框或精确状态描述，每次只替换一个环节。正确元素框显著改善结果，说明定位链路值得优先优化；提供正确子目标有效，说明规划或指令理解存在缺口。替换输入改变了任务难度，因此这些实验是诊断线索，不是严格的因果证明。

训练侧检查标签、难例覆盖、数据去重和训练是否收敛。小模型训练不足、视觉Token过度压缩和数据不匹配，都可能表现成“模型不够大”。ShowUI的视觉Token与历史消融提供了一个实例：模型规模不变，观察与数据组织仍会影响表现。

容量对照怎样才公平

尽量比较同系列、相近训练配方的模型，固定任务、观察、动作空间、预算和环境，重复运行并按小目标、歧义、长程依赖等切片分析。还要比较延迟、显存和成本。

若更大模型在相同可靠输入下稳定解决小模型失败的决策，且小模型经合理训练和接口优化后仍有差距，容量不足的解释才更有依据。不同模型同时改变数据、视觉编码器和训练方法时，不能把全部差距归于参数量。

常见追问

不扩模还有什么办法？ 可以用局部放大、候选元素、结构化状态、动作约束及蒸馏减少决策负担，再用相同任务验证质量与成本。

参考资料