通过UIA驱动Electron桌面应用：一次Windows-MCP实地测试
内容提要
文章实测用Windows-MCP通过UIA语义树驱动Electron桌面应用，完成新建会话、输入、发送、校验回复和清理的自动化流程。作者记录了冷启动时无障碍树为空、窗口标题随会话变化、遍历全桌面窗口过慢、菜单动画导致点击失效、UIA瞬时COM错误及高DPI坐标错位等问题，并给出预热、按进程定位窗口、限定应用窗口、重试和声明DPI感知等修复。最终45次连续运行无测试步骤失败，但仅测试单一应用和流程，未与截图方案对比。
延伸解读
冷启动与预热：无障碍树需要被“唤醒”
Electron 应用刚启动时，UIA 返回的节点极少，只有窗口和面板，没有可交互控件。这是因为 Chromium 在检测到辅助技术后才构建完整的无障碍树，首次查询本身就会触发构建。作者没有使用 --force-renderer-accessibility 参数，而是在回放第一步做一次全窗口遍历并轮询节点数，直到超过 200 个。实测三次冷启动都在约 1.1 秒内达到 402 个节点。这说明预热步骤是必要的，且成本可控。
窗口定位策略：按进程而非标题
最初版本按窗口名称查找主窗口，但 Electron 会在会话有标题后重命名窗口，导致查找失败。作者改为用 Win32 枚举可见窗口，通过进程可执行文件路径匹配目标应用，再调用 ElementFromHandle 获取 UIA 元素。同时，避免从 UIA 根节点遍历整个桌面，只操作目标应用自己的窗口。这一改动将清理阶段扫描 9 个顶层窗口的耗时从 5.3 秒降到 0.02 秒，中位清理时间从 29.6 秒降至 5.7 秒。
稳定性修复：重试、等待与 DPI 声明
运行中遇到三类问题：菜单动画未结束导致点击被吞，作者在菜单项出现后等待 0.6 秒再点击，并增加一次重试；UIA 查询偶发 COM 错误，加入最多 3 次重试后 45 次运行未再出现；200% 缩放下 UIA 返回逻辑坐标而输入注入使用物理坐标，导致点击错位，脚本开头声明 per-monitor v2 DPI 感知后两者一致。这些修复共同支撑了连续 45 次运行无测试步骤失败。
对前端与适用边界的启示
文章指出，UIA 能按名称和控件类型定位元素，但当前 764 个元素中仅 11 个有 AutomationId，且多为框架生成、依赖渲染顺序，不适合作为选择器。会话列表中每行的“重命名”“删除”按钮名称相同，各 60 个，需要 aria-label 包含会话名以便区分。作者也明确局限：仅测试单一应用和流程，未与截图方案对比，只能说明语义树足够用，不能断言更快或更稳。
Q&A
Windows-MCP 默认会收集哪些遥测数据？怎么关闭？
Windows-MCP 默认开启匿名遥测，使用 PostHog 客户端，会上报工具名、耗时、成功标志、客户端名称和版本，以及持久化在 ~/.windows-mcp/ 下的匿名 ID；出错时还会上报原始错误信息和堆栈。只有将环境变量 ANONYMIZED_TELEMETRY 设为 false 才会关闭。由于安装生成的启动脚本没有设置该变量，需要手动在脚本中添加一行 set ANONYMIZED_TELEMETRY=false。
为什么 Electron 应用刚启动时 UIA 无障碍树几乎是空的？如何解决？
Chromium 只有在检测到辅助技术时才会构建无障碍树，所以冷启动后第一次查询只返回 14 个节点（1 个窗口、11 个 Pane、2 个 Document），没有交互控件。第一次查询本身就是唤醒信号，约 6 秒后同一查询返回 764 个节点，其中 299 个可交互。实际不需要加 --force-renderer-accessibility 参数，在回放流程的第一步做一次完整遍历并轮询节点数直到超过 200 即可。
用 UIA 驱动 Electron 应用时，窗口标题会变导致找不到窗口，怎么办？
不要按窗口名称查找主窗口，因为 Electron 会在会话有标题后把窗口重命名为该标题。应改用 Win32 的 EnumWindows 枚举可见窗口，通过 GetWindowThreadProcessId 获取进程 ID，再用 psutil 匹配进程可执行文件路径来定位目标应用的窗口，最后对匹配到的窗口调用 ElementFromHandle。
遍历整个桌面所有窗口有什么问题？如何优化清理速度？
从 UIA 根节点遍历所有顶层窗口可能遇到无响应窗口，导致一次运行卡住 63 秒，甚至根查询返回 0 个窗口。应只操作目标应用自己的窗口。清理时菜单和确认对话框是目标应用的弹出窗口，但最初在全桌面搜索，扫描 9 个顶层窗口耗时 5.3 秒；限定在应用窗口内后只需 0.02 秒，清理中位时间从 29.6 秒降到 5.7 秒。
菜单项刚出现就点击不生效，怎么处理？
点击“删除”后确认对话框没出现，或对话框出现但确认按钮找不到，判断是菜单还在播放展开动画，过早的点击被吞掉。在菜单项出现后等待 0.6 秒再定位并点击，可将首次清理失败从 20 次中的 4 次降到 2 次；再加一次重试后，后续批次没有出现两次都失败的情况。根本原因尚未完全确定。
高 DPI 缩放下 UIA 点击坐标错位是什么原因？如何修复？
在 200% 缩放的机器上，如果进程没有声明 DPI 感知，UIA 返回的是逻辑坐标，只有输入注入所用物理坐标的一半，点击就会落到错误位置。在脚本开头调用 SetProcessDpiAwarenessContext(-4)（per-monitor v2）声明 DPI 感知，使两者一致即可。
这次 UIA 驱动 Electron 应用的测试最终结果如何？有哪些局限？
经过修复后，B 到 D 批次共 45 次连续运行没有测试步骤失败，冷启动 3 次也全部通过。但只测试了一个应用和一条流程，没有与基于截图的方案对比，因此只能说明语义树足够用，不能说明更快或更稳定。回复断言仅检查开头词和长度不超过 8 个字符，模型措辞不同就会判失败；UI 字符串是硬编码中文，界面一变就要更新；RDP 断开时 Windows-MCP 返回 CONTROL_UNAVAILABLE，脚本直接失败。
