刷到一条视频：右边开着 Claude 的聊天窗，左边是 Windows 11 桌面。一句「帮我打开 Word」敲进去，系统自己弹开始菜单、搜索、点开 Word——全程没截一张图，没调任何视觉大模型。

这事过去也能做，但要给 AI 配一个”眼睛”——多模态模型不断截屏、看图、找按钮在哪，慢、贵、还经常点歪。这条视频里的主角 Windows-MCP，把”眼睛”这步直接砍了：它不看屏幕，改成”读”屏幕。

这篇就拆它：它凭什么不用视觉模型就能操控电脑、这套路线和”截图+视觉”到底差在哪、怎么自己跑起来，以及——让 AI 拿到你电脑的鼠标键盘，安全这关怎么过。

一句话定性

Windows-MCP 的核心不是”又一个能控制电脑的 AI 工具”，而是换了条路线：用 Windows 系统自带的无障碍接口（UIA）把界面变成「带坐标、带层级的结构化文字」，让纯文本大模型直接读懂界面——不截图、不耗多模态 token、延迟 0.2–0.5 秒。它把”AI 操控电脑”从”看图找按钮”降维成”读文本点元素”。

为什么这次不一样：UIA 替代了”眼睛”

要看懂它的价值，得先看清”AI 控制电脑”过去的主流做法，和它的代价。

老路线：截图 + 视觉模型。 AI 每动一步，先截一张屏，把图喂给多模态大模型，让模型”看”出按钮在画面哪个像素，再回传坐标去点。这是大多数 Computer Use 方案的底层逻辑。它通用——任何画得出来的界面都能看——但代价很硬：

  • 贵：每一步都烧多模态 token，一张 1080p 截图就是几百上千 token，连续操作累计惊人；
  • 慢：截图→上传→视觉推理→回坐标，一个来回好几秒；
  • 不准：视觉模型靠”看”估坐标，按钮一小、排版一密就点歪。

新路线：UIA 无障碍树。 UIA 全称 UI Automation，是 Windows 系统底层原生的无障碍接口——本来是给读屏软件、辅助工具用的。它能把当前界面里的窗口、按钮、输入框、菜单，整理成一棵带名称、带类型、带坐标、带层级的结构化数据树。

关键就在这：这棵树是文字，不是图片。于是——

维度截图 + 视觉模型UIA 无障碍树（Windows-MCP）
AI 怎么”看”界面截图喂多模态模型，看像素读系统给的结构化文字
用什么模型必须多模态纯文本 LLM 即可
token 成本每步烧图，贵只读文本，省
延迟数秒级0.2–0.5 秒
定位精度估坐标，会点歪直接拿元素 ID 和真实坐标
天生短板几乎能看任何界面只认”规范控件”

一句话：它把”理解界面”这件事，从模型的负担挪回了操作系统的本职。 系统本来就知道每个按钮叫什么、在哪、是什么类型——以前我们绕一大圈让 AI 去”看”出来，现在直接问系统要。

这其实是个反复出现的判断：能从结构里拿到的信息，就别让模型去”看”。浏览器自动化里”读 DOM/无障碍树 vs 截图识别”是同一场辩论，结论也一样——有结构化数据时，结构化永远更快更稳。Windows-MCP 把这套搬到了整个桌面。

视频里还演示了一个细节：它带一个可选的 DOM 模式（use_dom），操作浏览器时能过滤掉浏览器外壳、只聚焦网页内容——本质还是”能读结构就读结构”的延伸。

它到底能干啥：一套桌面操作工具集

Windows-MCP 不是只能”打开 Word”。它给 AI 配了一整套桌面操作工具，覆盖从点击到系统级操作：

类别工具干啥
输入控制Click / Type / Scroll / Move / Shortcut / Wait / WaitFor点击、输入、滚动、移动、快捷键、等待
界面捕获Screenshot / Snapshot截图（仅作画面参考）/ 抓全界面结构+元素 ID
应用管理App 启动 / 窗口管理 / 窗口切换开应用、调窗口、切前台
系统操作PowerShell / 文件系统 / 进程管理跑命令、读写文件、管进程
网页Scrape抓网页数据
批量MultiSelect / MultiEdit批量选、批量改
杂项剪贴板 / 通知 / 注册表复制粘贴、读通知、改注册表

注意 Screenshot 在这里的角色变了：它只是”画面参考”，整套控制逻辑完全靠 UIA 跑，不靠这张图找按钮。 这跟老路线刚好相反。

怎么跑起来：一行命令的事

部署确实简单，前提和步骤都很轻：

前提

  • 操作系统：Windows（全版本兼容）
  • Python 3.13+
  • 包管理器：uv（pip install uv 或官方脚本装）
  • 建议把 Windows 显示语言设为英文（App 工具对英文界面识别更稳）

本地直连跑（最常用）

uvx windows-mcp serve

一行 uvx 命令拉起，直接对接本地的 MCP 客户端（Claude Desktop、Cursor、Claude Code 等）。

装成开机后台常驻

windows-mcp install

三种连接模式（transport），按场景选：

  • stdio：默认，进程直连 MCP 客户端，本机用最省事；
  • sse：服务器推送事件，--transport sse --host localhost --port 8000；
  • streamable-http：流式 HTTP，生产/远程环境推荐，同样 --host --port 起。

支持的客户端不少：Claude Desktop、Cursor、Perplexity Desktop、Gemini CLI、Qwen Code、Codex CLI，以及 Claude Code（连 WSL 都能通过 PowerShell 桥接走）。项目在官方 MCP Registry 里有登记，据称在 Claude Desktop 扩展生态里已有 200 万+ 用户量级——开源 MIT 协议，GitHub 上 6k+ star。

真正该花时间的地方：安全

这才是重点。你让一个 AI 拿到了你电脑的鼠标、键盘、PowerShell 和文件系统——这等于把一台机器的完整操作权交出去。一旦走远程模式，或者模型被诱导（prompt injection），后果不是”点错按钮”那么轻。

好在这点项目方想到了，给了一套防护，远程暴露前这几样必须配齐：

  • 密钥校验：--auth-key 加 Bearer Token，没钥匙连不上；
  • IP 白名单：--ip-allowlist 限定 CIDR 网段，只放行可信来源；
  • TLS 加密：支持自签证书，远程链路别裸跑明文；
  • OAuth 2.0 + PKCE：兼容的客户端可走标准授权；
  • CORS 控制：浏览器客户端显式白名单来源；
  • 工具裁剪：--tools / --exclude-tools 按需启停，可以直接屏蔽 PowerShell、注册表这类高风险工具——这是降风险最实在的一招；
  • SSRF 防护：Scrape 工具会拦截私网、回环、链路本地地址。

一条判断：本机自用和远程暴露是两个安全档位。 本机 stdio 自己用，风险可控；一旦想远程操控，密钥+IP白名单+TLS 是底线，再叠上”屏蔽高危工具”才算稳。别因为”一行命令就能起”就把它直接挂公网。

适用 vs 短板：别拿它干它不擅长的

UIA 路线快、省、准，但它的能力完全建立在”界面有规范控件、有无障碍数据”之上。这决定了它的边界很清晰：

适配的场景

  • 办公自动化（Word/Excel/浏览器/各类规范桌面软件）
  • 软件测试、QA 自动化
  • 本地 AI 调度、批量重复操作

抓瞎的场景

  • 游戏：自绘画面、没有标准控件，UIA 读不到东西；
  • 无障碍数据缺失的自定义界面：一些用 Canvas/自绘 UI 的软件同样识别不了；
  • 段落内精细选词：受无障碍树粒度限制，做不了;
  • 当编程输入用：Type 工具是整段写入、不是增量输入，不适合在 IDE 里写代码。

换句话说：它是”办公/规范软件”的自动化利器，不是”万能屏幕操控器”。 想自动化的目标如果是规范桌面应用，它又快又稳；如果是游戏或自绘界面，老老实实回到视觉路线。

写在最后

Windows-MCP 真正值得记住的，不是”又一个 AI 控电脑工具”，而是它示范的那个判断：

当一件事既能靠”看”也能靠”读结构”完成时，优先读结构。 截图+视觉模型路线通用、但贵、慢、不准；UIA 无障碍树路线有边界、但在边界内又快、又省、又精确。工具的进化方向，往往不是把模型堆得更强去硬扛，而是找到系统里早就存在、却被忽略的结构化入口，把负担卸下来。

落到行动上很简单：你要自动化的是规范桌面软件（办公、测试、批量操作），它现在就能装、一行命令起、几乎零门槛；但只要涉及远程暴露，先把密钥、IP 白名单、TLS 和高危工具屏蔽配齐再上——让 AI 接管电脑这件事，省下的那点 token 钱，远不如守住安全这条线值钱。