Gemini 桌面自动化：截图循环的延迟取舍

据 dev.to 文章节选，Google 已将 Gemini Computer Use 正式开放，开发者可以通过截图输入、结构化动作返回和本地执行，搭建桌面操作 Agent。作者给出了 Python 接入示例，但更值得程序员关注的是后半段：在 Windows 上，截图循环与无障碍树各有适用边界，选型会影响响应速度和操作可靠性。

目前能确认什么

节选描述的工作方式是：发送截图和任务，模型返回点击、输入、滚动等动作，本地代码执行后，再发送下一张截图。模型负责决定动作，执行器负责真正操作桌面。

据作者介绍，该能力支持 Interactions API 和 GenerateContent。示例使用 google-genai，返回坐标采用 0–999 的归一化网格，需要换算到实际屏幕或窗口尺寸。缩放映射出错，点击位置就会偏移。

截图路线需要经历图像采集、编码、网络请求和界面状态等待。作者给出了单步延迟估计，但节选没有提供完整测试条件，不能直接套到自己的应用上。

Windows 的 UI Automation（UIA）则允许程序读取无障碍树中的控件名称、边界和支持的操作，直接调用控件。前提是目标应用暴露了可用的控件信息；自绘界面或树信息不完整时，截图仍有用途。

我的判断

做 Windows 桌面 Agent，应该先检查目标应用的无障碍树是否可用。

如果按钮和输入框已经能被稳定识别，优先通过 UIA 操作，可以减少截图识别和坐标换算环节。遇到缺失控件、特殊绘制区域，或任务依赖视觉布局时，再考虑截图路径。

执行后的检查同样关键。点击后应确认窗口是否关闭、值是否改变，再决定下一步，否则重复点击可能把一次识别错误扩大成连续误操作。

正式接入前，仍需核实官方支持的模型、SDK 版本和安全参数语义。尤其是节选对提示注入检测「可选」与示例默认开启的描述，不能当成服务端默认保护的保证。