调研成果
agent-desktop 是 Vercel Labs 的 Rust 桌面自动化 CLI（Apache-2.0、GitHub 17,246 星、npm latest 1.2.0、v1.2.0 发布于 2026-11-05）。技术路线是绕开截图：通过操作系统无障碍接口（macOS AX、Windows UIA、Linux AT-SPI）把界面读成带稳定 ref 的 JSON 树，agent 对 ref 执行动作后再快照复核，形成「观察—动作—复核」闭环；默认 headless，不移动指针、不抢焦点。 三条结论：一，优势在元素级、低 token、可确定性验证的自动化；短板是自绘界面（Canvas/WebGL/定制渲染）无障碍树往往只有粗节点，而项目本身不提供视觉或坐标兜底。二，用它操作微信这类强风控软件，技术上不具备「绕过风控」的能力——它不注入进程、不 hook 客户端、不改内存与报文，也没有指纹伪造组件，只是以当前用户身份调用系统辅助功能接口；同时微信规则把这类用法本身界定为违规（《个人账号使用规范》1.2.4 禁止非授权第三方工具/服务接入、1.2.6 禁止通过非腾讯开发授权的第三方软件或系统登录或使用微信；Safety Center 明确禁止 automated access 与 bypassing security controls）。三，因此该场景的真实风险不是「能不能绕过」，而是「一用就落入禁止条款」，处置从功能限制到封禁不等。 本次未安装、未运行该项目，也未在真实微信客户端上做任何观察或操作；关于微信 AX 可枚举性与平台检测阈值均属未验证推断，已列入不确定性。本报告不提供任何降低检测概率的操作建议。
把「看界面」从图像空间换到结构空间。核心循环：snapshot 读无障碍树输出带 ref 的 JSON；agent 选 ref 与动作（click、type、set-value、toggle、scroll）；执行后再快照比对决定继续或重试。ref 与快照 id 强绑定，跨快照被拒，界面变化返回 STALE_REF 或 AMBIGUOUS_TARGET，迫使重新观察而非盲点。底层按平台对接 AX/UIA/AT-SPI，上层共用核心与统一 JSON envelope，并提供 MCP 与 C 库两种集成。与截图式三点本质差异：输入是控件树而非像素，token 成本与屏幕复杂度脱钩；动作作用于元素而非坐标，不因分辨率主题窗口偏移失准；验证是结构比对而非视觉判断，失败原因可分类（元素过期、目标歧义、权限缺失）。代价是覆盖度受制于无障碍接口的暴露程度。
分两层。规则层是确定的：《微信个人账号使用规范》1.2.4 禁止对微信运行期内存数据、客户端与服务端交互数据、系统数据做复制修改挂接，形式明确含「插件、外挂或非经腾讯授权的第三方工具/服务接入」；1.2.6 禁止通过非腾讯开发授权的第三方软件、插件、外挂、系统登录或使用微信；1.2.7 禁止干扰其组件模块数据。Safety Center 另明确禁止 automated access and data collection 与 probing or bypassing security controls。处置阶梯从警告、功能限制到封禁。也就是说，用 agent-desktop 驱动微信这一用法本身落在禁止范围，风险是定性而非概率问题。 技术层不确定：本次未运行任何自动化操作真实微信，无法给出「是否被识别、多久被识别」的实测结论。可确定的机制事实是——agent-desktop 不做进程注入、不 hook、不改内存与网络报文，也无指纹或环境伪造能力，仅以当前登录用户身份调用系统无障碍接口；其痕迹属「合法 OS 接口被非授权使用」，而非「隐藏自身」。至于目标应用能否从控件级动作密度、操作节奏、全天候在线等信号识别非人类操作，属平台风控实现细节，本报告无证据、不做估算。
不具备，且此问题在技术层没有可交付的正面答案。从工具设计看：能力面只有「读无障碍树 + 对 ref 动作」，没有指纹伪装、设备信息伪造、协议改写、请求重放、节奏随机化等规避组件，README 与官方文档也无针对平台检测的设计目标；默认 headless、不移动指针，物理输入层面甚至没有「像人」的仿真能力。从规则看：绕过安全控制本身即被禁止的行为类别，Safety Center 明确把 probing or bypassing security controls 列为禁止项；因此「具备绕过能力」既非其技术属性，也不能成为合规路径——即便某组合在个别时点未被识别，仍是违规使用，平台保留追溯与处置权。本报告不提供任何降低被检测概率的建议（节奏扰动、环境隔离、账号轮换等），那属规避平台安全机制，不在交付范围。可行方向只有：改用官方开放接口（企业微信、公众号、客服、小程序），或在平台书面授权前提下做集成。
决定该类客户端上技术是否可行：若只暴露窗口与少量标准控件，完整会话操作无法完成，必须视觉兜底，架构完全不同。
在隔离测试机的自有测试账号上只做 snapshot 观察、不做操作，统计可枚举节点数与角色分布，与一个开源 Electron 客户端对比覆盖率；观察行为也需先确认平台条款边界，或改为在自建、结构相似的自绘客户端做同构实验。
决定违规使用的实际后果速度，但无论结果如何都不改变「规则禁止」的结论，也不构成使用授权。
本报告不做此类测试；可验证的替代是查阅平台公开规范与处罚公告口径，实证测试涉及违规使用与账号风险，不在建议范围。
决定长流程自动化能否稳定落地，以及是否必须改为「小步快照 + 频繁校验」。
在自建测试应用里构造自动刷新列表、异步弹窗与动画过渡，统计每百步 STALE_REF/AMBIGUOUS_TARGET 次数与平均恢复耗时。
HN 讨论时只有 macOS 为 GA，如今 README 称三平台齐备；若实际能力弱于 macOS，跨平台方案需按平台差异化设计。
在 Windows 与 Linux 跑同一批命令（snapshot、click、type、scroll、notifications），对比可用率与失败原因分布；本次无对应环境，未验证。
1) 准备四个对照应用：原生 AppKit、Electron、Qt、Canvas 自绘页面；2) 在同一台 macOS 13+ 上授予辅助功能权限；3) 对每个应用执行 snapshot --skeleton 与全量 snapshot，记录节点数、role 分布、带 ref 的可操作元素数；4) 每个应用尝试一次 click 与一次 set-value，记录成功或 STALE_REF/AMBIGUOUS_TARGET 等错误；5) 汇总各渲染栈覆盖率与动作成功率。
成功标准原生应用关键控件命中 ≥90% 且 click/set-value 成功率 ≥95%；Electron/Qt 达 70% 以上判定「需局部兜底」；Canvas 自绘低于 30% 判定不可单独依赖无障碍树。全部测试须记录失败原因，不用「大部分可用」替代数据。
1) 构造每 2 秒自动刷新列表并随机弹提示的测试应用；2) 脚本驱动 100 步「snapshot→click→snapshot」，记录每步耗时与错误码；3) 另跑「连续 5 个动作后统一快照」的批量策略 100 步；4) 对比两组成功率、总耗时、快照次数与重试次数。
成功标准给出两组成功率与总耗时差距；若批量策略成功率低于每步验证 10 个百分点以上，确认每步复核是必要开销；若接近，则长流程默认采用批量策略以节省快照成本。
Vercel Labs 维护的桌面 computer-use 命令行工具：不截图、不做像素匹配，读操作系统无障碍树，把当前界面变成带稳定 ref…
推荐理由适合作为自研或内部桌面应用的自动化基座，尤其当目标是稳定、可审计、低 token 的元素级操作；若要用于第三方成熟消费级客户端（…
17,246Apache-2.0
暂无符合条件的项目，不为凑数重复推荐。
桌面 agent 两代做法可按「操作作用于什么」区分。 截图派：截屏→视觉模型识别→坐标点击。可覆盖任何画得出来的界面（含 Canvas 自绘、远程桌面），代价是每步传图、token 与延迟随屏幕复杂度上升、识别有歧义、坐标对缩放/主题/布局漂移敏感，失败时难判断「没点到」还是「点了没反应」。 无障碍树派（agent-desktop 属此类）：调用 AX/UIA/AT-SPI 读控件树、按元素 ref 动作。优点是结构化、体积小、语义明确、可确定性验证（动作后重读同一窗口比对），元素级动作不移动指针、不抢焦点；缺点是强依赖目标应用是否暴露元素——自绘控件与部分跨平台框架常只暴露粗节点，此时没有兜底。 可见性差异值得单记：截图派点击在目标应用看来就是普通输入事件；无障碍派的 AXPress 式动作绕过物理输入链路，目标应用收到的是控件级激活。「操作是否被应用察觉、以什么形式留痕」两派不同，需审计或对输入来源敏感的系统应实测而非假设。 工程上可行的第三条是分层：无障碍树为主路径，元素缺失时做局部视觉或坐标兜底，并把兜底命中率作为独立指标监控——纯替换常退回人工。 另需区分技术可行与规则允许：对第三方强风控产品，平台条款本身多禁止非授权第三方工具接入或自动化访问，此时任何一派技术都是违规使用，工程评估不构成授权。
研究价值可直接用于桌面 agent 方案的选型与评审：给出两代技术的取舍维度（覆盖度、成本、可验证性、可审计性），指出「分层兜底」是唯一稳妥落地形态，并补上常被忽略的前置判断「技术可行≠规则允许」，避免把合规问题当技术问题。
1) 若目标是自有或企业内部客户端，先跑 status 与 permissions --guide 确认权限归属（macOS 权限属于启动它的宿主 App 而非 shell），再按 snapshot→click→snapshot 三拍循环验证 AX 覆盖度。2) 自绘界面用 snapshot --skeleton --compact 摸底再 --root 钻取；元素拿不到时评估官方 API 或协议层方案，别加坐标补丁。3) 涉及微信等第三方强风控产品，先过规则审查：条款不允许就停，不进入技术评估；需批量触达客户转向企业微信/公众号/客服等官方接口。4) 本报告两项实验可在数日内给出可用与不可用的量化分界，建议作为投入前置门槛。
用 agent-desktop 对 Electron、Qt、Flutter 与 Canvas 自绘四类桌面应用分别执行 snapshot --skeleton 与全量 snapshot，统计节点覆盖率、可执行动作数与 ref 稳定性，给出「哪些渲染栈可被无障碍树完整覆盖、哪些必然退化」的分界线。
这是本报告最关键的未验证假设：全部价值都建立于无障碍树能拿到元素，而微信这类客户端大量自绘。若覆盖率不足，任何该类方案都需视觉兜底，架构判断完全不同；实验可独立设计、结论可复用。
构造高频变动界面（自动刷新列表、异步弹窗、动画过渡），测量 STALE_REF 与 AMBIGUOUS_TARGET 发生率、恢复所需快照次数与耗时，比较「每步验证」与「批量动作后统一验证」的成功率与 token 成本。
ref 绑定快照并要求每步重观察，在稳定界面优雅、在动态界面放大成本；该成本决定它能否支撑长流程自动化，属可量化的工程权衡问题。
在自有测试应用里对比 AXPress 式 headless 动作与 --headed 物理键鼠：分别记录目标进程收到的事件类型、系统审计日志、焦点与光标变化，明确「无物理事件但有控件动作」可被目标应用察觉的程度。
决定它在需要留痕与可审计的企业系统里能否合规使用；研究的是「操作可被谁看见」而非如何隐藏，可用于设计审计与授权策略。