Windows-MCP 拆解与实测：AI 操作 Windows 这件事——智能体基建系列

上一期我把 Computer Use 的底层机制捋了一遍，结论是「Accessibility Tree 优先 + 视觉兜底」正在成为生产可靠的方向。

今天要聊的是 Windows-MCP，github.com/CursorTouch..., MIT 开源，Python 写的，作者是 Jeomon George（CursorTouch 组织）。它干的事很直接，做一个 MCP server，把 Windows 的桌面能力暴露给任意 LLM，让模型能点按钮、敲键盘、读界面、跑 PowerShell。

我把它装到本机跑了一遍，也调研了一下网上能找到的公开评价。初步结论：技术路线选得对，工程细节还毛糙，离「能替你干活」还有距离。下面分几块介绍，它怎么实现的，我自己跑出来什么，以及真要上手该怎么用、要注意什么。

一、它到底提供了什么

先说定位。它就是一层适配器，你把它的 20 个工具挂到 Claude Desktop、Cursor、Claude Code 这些客户端上，模型就能看见并操作你的 Windows 桌面。

装上之后实际能用的工具，我按类别理了一下：

类别	工具	干什么
感知	`Snapshot`	抓完整桌面状态，含 UI 树、可交互元素、坐标
感知	`Screenshot`	快速截图，跳过 UI 树，只要画面
感知	`DisplayInventory`	显示器布局、分辨率、DPI、缩放
输入	`Click` `Type` `Scroll` `Move` `Shortcut` `Wait` `WaitFor`	鼠标键盘，以及等待某个元素或文本出现
输入	`MultiSelect` `MultiEdit`	批量勾选、批量填表
系统	`App`	启停应用、切窗口、改尺寸
系统	`PowerShell` `Process` `Registry` `Notification`	命令、进程、注册表、系统通知
数据	`FileSystem` `Clipboard` `Scrape`	文件、剪贴板、抓网页

这份清单是我实跑 tools/list 拉出来的。

代码量 24860 行 Python。体量最大的目录是 src/windows_mcp/uia/，其中 controls.py 一个文件 6381 行。这是把知名开源库 UIAutomation（yinkaisheng 那套）内联进来了。也就是说，这个项目的"操作系统底子"大部分是站在别人肩膀上，自己主要写的是"把 UIA 翻译成模型能读的东西"那一层。

客户端覆盖面倒是挺全，Claude Desktop、Perplexity Desktop、Gemini CLI、Qwen Code、Codex CLI、Claude Code、Autohand Code 都有配置说明。Claude Desktop 那边已经进了官方的 Desktop Extensions 目录。

官方截图。Claude Desktop 里 Windows-MCP 挂载成功后的工具开关列表，每个工具可以单独关掉。

二、它凭什么不靠视觉模型

README 里有介绍：

Unlike many automation tools, Windows-MCP doesn't rely on any traditional computer vision techniques or specific fine-tuned models; it works with any LLMs.

翻译过来，它不看图，它读无障碍树。

这件事的技术底座是 Windows UI Automation（UIA）。许多标准的 Windows 控件，在 UIA 里会暴露名字、类型、自动化 ID、坐标和支持的动作，模型拿到的是一份结构化清单，不是一张图。

UIA其实并不是一条普遍保证。控件由不同的程序实现，暴露哪些属性、支持哪些动作（也就是所谓的自动化模式）并不统一，有的只给一部分。下面这种形态是常见的，不是每个控件都长这样。

作者本人在 XDA 那篇实测的评论区解释过这个选择的动机，我觉得这句话是整个项目的题眼：

if we can automate the web reliably through the DOM, why shouldn't we be able to do something similar at the operating system level? Windows-MCP is essentially an attempt to explore that idea using Windows accessibility APIs as the "OS-level DOM."

（如果网页能靠 DOM 稳定自动化，那操作系统层面为什么不能做类似的事？Windows-MCP 本质上就是在探索这个想法，把 Windows 的无障碍 API 当成"操作系统级的 DOM"。）

这个类比很精准。DOM 之所以好自动化，是因为它有稳定的元素标识，不用靠像素猜。UIA 树之于 Windows，就是同一个角色。

它给了三条感知通道，按场景：

通道	怎么调	代价
UIA 树	`Snapshot`（默认 `use_ui_tree=True`）	信息最全，但复杂界面会慢
纯截图	`Screenshot`	快，但只能靠视觉，且拿不到元素 id
浏览器 DOM	`Snapshot(use_dom=True)`	Chrome / Edge / Firefox 拿网页 DOM，过滤浏览器外壳

Firefox 那条有个有意思的兜底，因为 Firefox 不通过 UIA 暴露 RootWebArea，它改用 IAccessible2。这恰好说明了整个项目的性格，宁可换第二个无障碍 API，也不退回截图。

整条链路是这样闭合的：

我实跑出来的 Snapshot 长什么样，截取一段如下（这是我本机开着记事本时抓的，只摘了记事本这一棵子树）：

text 复制代码

├── window "Untitled - Notepad 2e x64 [ZH]"
│   ├── (939,92) 按钮 "New"        [action: click]
│   ├── (963,92) 按钮 "Open"       [action: click]
│   ├── (987,92) 按钮 "Browse"     [action: click]
│   ├── (1011,92) 按钮 "Save"      [action: click]
│   ├── (1235,92) 按钮 "Word Wrap" [action: click]
│   ├── (1410,955) 滚动条 "水平滚动条" [action: click]
│   ├── (1747,35) 按钮 "最小化"    [action: click]
│   ├── (1866,35) 按钮 "关闭"      [action: click]
│   └── 菜单栏 "应用程序"
│       ├── (946,66) 菜单项 "File"     [action: click]
│       ├── (991,66) 菜单项 "Edit"     [action: click]
│       └── (1040,66) 菜单项 "View"    [action: click]

模型看到的就是这种带坐标、带名字、带可执行动作的清单。它不需要猜"那个像保存的图标在哪儿"，它知道有个按钮名叫 Save，坐标是 (1011, 92)。

官方演示最能说明这个闭环是怎么跑的。右边是 Claude Desktop 里的工具调用序列，左边是被操作的记事本：

官方演示。注意右边这一串，"看状态 → 启动应用 → 等待加载 → 再确认状态 → 输入文字"，每一步都是一次独立的工具调用。

代价也很清楚。 它的结构化定位绑死在可访问性接口上。自绘画布、游戏、DirectX 界面、部分 Electron 窗口这些地方，UIA 树基本是空的，它就没法靠元素名去点。README 自己也承认 "can't be used to play video games"。

但"UIA 读不到就等于瞎了"这个说法，不准确。它还有 Screenshot 这条通道，截图可以交给支持视觉输入的模型去看；README 把视觉明确定位成可选能力（"Use Any LLM (Vision Optional)"），Snapshot 也支持 use_vision=True 把截图一起带上。准确的说法是：没有可用的 UIA 信息时，模型还能退到截图加坐标，但这时的可靠性不再由它兜底，得看客户端和模型自己的视觉能力，以及坐标算得准不准。

作者对性能瓶颈的解释也很坦白，同样出自 XDA 评论区：

performance still heavily depends on the number of interactive elements in an application. Since everything is driven by accessibility trees, large and complex UI hierarchies can slow things down. We've put a lot of work into generalized (non hard-coded) heuristics to prune and compress those trees.

（性能依然严重依赖界面里可交互元素的数量。因为一切都是靠无障碍树驱动的，庞大复杂的 UI 层级就会拖慢速度。我们做了大量通用的、非硬编码的启发式规则来裁剪和压缩这些树。）

代码里确实能看到对应的东西，src/windows_mcp/tree/ 下面有 budget.py（树预算）和 cache_utils.py（缓存），就是干这个的。

另外两个工程细节顺便提一下。截图后端是三级降级链，dxcam → mss → pillow，我本机上直接落到了最慢的 pillow。还有截图后会画一圈橙红色边框做视觉反馈，WINDOWS_MCP_DISABLE_FLASH=1 可以关掉。

三、我真机跑了一遍

我用 uvx 在本机把它拉起来，用 stdio 起了服务，直接按 MCP 协议的 JSON-RPC 手动调。

初始化握手返回的真东西：

json 复制代码

{
  "protocolVersion": "2025-06-18",
  "serverInfo": { "name": "windows-mcp", "version": "4.0.10" },
  "instructions": "Windows MCP server provides tools to interact directly with the Windows desktop..."
}

第一次真调工具，我让它报本机 PowerShell 版本：

text 复制代码

tools/call  PowerShell  {"command": "$PSVersionTable.PSVersion.ToString()"}
→ Response: 5.1.26100.9549
→ Status Code: 0

成功。顺手说明一点，它调的是 Windows PowerShell 5.1，不是 PowerShell 7，这个差别在写脚本时有影响。

然后走一遍完整 GUI 闭环，App 启动记事本 → Wait → Click 定位 → Type 输入 → Screenshot 截图。下面这张就是我本机上跑出来的，文字是 Windows-MCP 的 Type 工具敲进去的，我没有碰键盘：

四、真要上手，我建议这么用

看完上面这些，如果你还是想试，几条实操建议：

先放虚拟机或者 Windows Sandbox。这不是我谨慎，是厂商安全文档里明写的。
关掉用不到的高危工具 。--exclude-tools "PowerShell,Registry,FileSystem" 能砍掉一大片攻击面。默认全开的设定不适合随便试。注意这只是工具级的开关，管不到命令级------你把 PowerShell 留着，它内部能跑什么就没限制。
锁死版本 。别让 uvx 自己挑，明确写 windows-mcp==0.8.6，并在装之前确认你的 Python 版本够。否则你会在不知情的情况下用一个旧版。
远程访问必配鉴权 。--auth-key + --ip-allowlist + TLS 三件套，别把 --host 0.0.0.0 裸着开。这个项目就因为没做这件事吃过一个 HIGH 级漏洞（CVE-2026-48989：0.7.5 之前的 HTTP 模式，控制面不带任何认证就能被任意来源访问）。
关遥测 ，一行环境变量的事。项目用 PostHog 收集匿名使用数据，ANONYMIZED_TELEMETRY 默认是开的（README 环境变量表写 true，我实跑那版 0.8.5 的源码里也是 os.getenv("ANONYMIZED_TELEMETRY", "true")）。项目声明不采集个人信息、工具参数和输出，在意的话客户端配置里加一行，注意值要写成字符串："env": { "ANONYMIZED_TELEMETRY": "false" }。
中文系统注意 App 工具的匹配问题 ，按开始菜单名字启动应用可能失败，优先用 launch_executable 加完整路径。
期望管理最重要。它适合"目标明确、能试错、失败了不心疼、而且界面是标准 Win32 控件"的活。需要精确点击和填表的场景，浏览器侧还是走 CDP（Playwright 那套）更稳，两者各管一段，不互相替代。

本文作者，日常在公众号「围炉聊科技」分享前沿科技相关的技术文章，感兴趣可搜索关注。