Windows-MCP 评测：不依赖视觉模型的 Windows 自动化 MCP 服务
用于 Windows 中计算机使用的 MCP 服务器。使用任何 LLM（视觉可选）与许多自动化工具不同，Windows-MCP 不依赖于任何传统的计算机视觉技术或特定的微调模型；它适用于任何法学硕士，降低复杂性和设置时间。
秒懂
- 它是什么？
- Windows-MCP 是一个面向 Windows 的 MCP 服务器，让任意 LLM 通过原生 UI 自动化工具操作文件、应用和浏览器。它避开传统计算机视觉，用 UIA 和 DOM 模式降低复杂度，但首次安装和语言环境有坑。
- 适合谁用？
- Windows-MCP 适合那些已经在用 MCP 客户端（如 Claude Desktop）且需要让 LLM 直接操作 Windows 桌面、应用或浏览器的开发者，尤其是想避开视觉模型和额外微调成本的人。它不适合需要跨平台支持、非英语界面自动化或对首次启动超时零容忍的用户。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
Windows-MCP 解决的是让大语言模型直接操作 Windows 系统的问题。传统方案依赖计算机视觉识别屏幕像素，或者需要针对特定模型微调，这既增加延迟也提高部署成本。Windows-MCP 走的是另一条路：通过 Windows 原生 UI 自动化接口（UIA）获取界面元素和状态，再模拟键盘鼠标输入。文档宣称它不需要任何传统视觉技术或特定微调模型，任何 LLM 都能用，视觉能力是可选的。这个定位适合两类人：一是用 Claude Desktop 等 MCP 客户端、想让 agent 帮忙做文件导航、应用控制或 QA 测试的普通用户；二是想在自己项目里集成 Windows 自动化、但不想绑定某个视觉模型的技术人员。它支持 Windows 7 到 11，覆盖老系统，这是一个少见但实用的选择。
核心机制：UIA 和 DOM 模式，不是截图识别
Windows-MCP 的关键在于它读取 UI 状态的方式。文档提到 State-Tool 有一个 use_dom=True 模式，专门用于浏览器自动化，只关注网页内容，过滤掉浏览器自身的 UI 元素。这暗示其默认机制是截取窗口或 UI 元素的属性树，而不是截屏让模型看图。对于浏览器，它支持 Chrome、Edge 和 Firefox，但 Firefox 有特殊处理：由于它不通过 UIA 暴露 RootWebArea，所以回退到 IAccessible2 接口。这个设计直接决定了工具的适用范围：它能精确获取按钮、文本框等元素的属性，但代价是必须依赖 Windows 的可访问性 API。如果某个应用没有正确实现 UIA，工具可能拿不到状态，这是所有基于可访问性树的自动化工具的通病。文档没有提供具体的状态返回格式示例，但基于 MCP 的常规做法，工具会返回结构化的元素列表，LLM 根据这些文本描述决定下一步操作。
安装与配置：uvx 一条命令，但 MSIX 有坑
安装方式很直接：通过 uvx 运行 windows-mcp serve 即可启动服务器。文档给出的命令有：uvx windows-mcp serve，以及指定传输方式的 uvx windows-mcp serve --transport sse --host localhost --port 8000 和 streamable-http 变体。如果想开机自启，可以用 windows-mcp install，它会创建一个名为 windows-mcp-server 的计划任务和包装脚本 ~/.windows-mcp/start-server.cmd，日志写到 ~/.windows-mcp/server.log 和 server.error.log。对于 Claude Desktop，配置 claude_desktop_config.json 中的 mcpServers 字段，指定 command 为 uvx 或 uv。但 MSIX 版 Claude Desktop 有特殊问题：它虚拟化了 %APPDATA%，配置文件路径变成 %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json，并且 Electron 沙箱不继承系统 PATH，所以必须写 uvx.exe 的绝对路径，比如 C:\Users\<user>\.local\bin\uvx.exe。文档明确指出自动安装会失败，必须手动编辑。这个坑对 Store 版用户是必踩的，提前知道能省不少时间。
工具集与实际操作：从点击到 DOM 抓取
Windows-MCP 提供了一套工具，覆盖基本键盘、鼠标操作和窗口/UI 状态捕获。文档没有列出完整工具清单，但提到有 App-Tool，用于控制应用，以及 State-Tool，用于获取 UI 状态。在 DOM 模式下，State-Tool 只返回网页内容，这对浏览器自动化特别有用，因为模型不用在大量浏览器按钮和菜单中找目标。文档给出的延迟数据是动作之间典型延迟 0.2 到 0.5 秒，但注明会随活动应用数量和 LLM 推理速度变化。这个数字说明工具本身很轻，瓶颈在模型推理。实际使用中，你需要在 MCP 客户端里调用这些工具，比如让模型先调用 State-Tool 获取当前窗口的 UI 树，再决定点击哪个按钮。这要求模型能理解结构化的 UI 文本，对纯文本 LLM 也能工作，但视觉模型可能更容易处理截图，不过 Windows-MCP 不强制。
限制与失败模式：英语依赖和首次超时
最明显的限制是语言环境。文档在前提条件里写明：Windows 默认语言最好是英语，否则需要禁用 App-Tool。这意味着非英语系统上，应用控制功能可能失效或出错。这是一个硬约束，对中文用户尤其重要，因为很多 Windows 系统默认是中文。另一个坑是首次安装：文档明确警告第一次安装可能因为安装 pyproject.toml 里的依赖而超时，需要忽略并重启服务器。这不是 bug，而是依赖安装慢导致的。另外，Firefox 的 DOM 模式依赖 IAccessible2 回退，这可能导致某些网页元素无法正确暴露，影响自动化精度。如果目标应用不完整支持 UIA，State-Tool 可能返回不完整的数据，模型就会做出错误操作。文档没有提供回退方案，所以遇到这类应用时，Windows-MCP 可能不是合适工具。
替代方案：视觉模型与跨平台工具的对比
与 Windows-MCP 形成鲜明对比的是依赖计算机视觉的自动化工具，比如 Anthropic 的 Computer Use 或其他基于截图的 agent。那些方案需要视觉模型，能处理任意界面但计算成本高、延迟大。Windows-MCP 通过 UI 树绕过视觉，优点是快和便宜，缺点是只能操作暴露了可访问性接口的应用。另一个替代方向是跨平台自动化框架，比如 Playwright 或 PyAutoGUI，但 Playwright 只针对浏览器，PyAutoGUI 是低层输入模拟，没有 UI 状态感知。Windows-MCP 的独特之处在于它把这些能力封装成 MCP 服务，直接接入 LLM，省去自己写 agent 逻辑。如果你需要 macOS 或 Linux 支持，Windows-MCP 不适用，只能选跨平台方案。
维护成本、许可证与升级路径
Windows-MCP 使用 MIT 许可证，这意味着你可以自由修改和商用，但文档没有提供贡献指南或版本升级说明。最近版本更新频繁，v0.8.5 在 2026-08-01 发布，说明项目活跃。维护成本主要在两方面：一是依赖 uv 和 Python 3.13+，环境升级可能破坏兼容性；二是微软的 UIA API 变化会导致工具失效，需要跟随项目更新。通过 uvx 运行的好处是每次启动都拉取最新版，但这也意味着你无法锁定版本，除非用 windows-mcp install 安装固定版本。如果对稳定性要求高，建议在配置中指定版本号，比如 uvx windows-mcp==0.8.5，但文档没有给出这个示例，只是理论上可行。日志文件位置固定，排查问题不难，但文档没有说明日志轮转机制，长期运行可能占用磁盘。
编辑结论
Windows-MCP 适合那些已经在用 MCP 客户端（如 Claude Desktop）且需要让 LLM 直接操作 Windows 桌面、应用或浏览器的开发者，尤其是想避开视觉模型和额外微调成本的人。它不适合需要跨平台支持、非英语界面自动化或对首次启动超时零容忍的用户。在采用前，先确认你的 Windows 系统默认语言是英语，否则必须禁用 App-Tool；检查 Python 3.13+ 和 uv 是否就绪；如果使用 MSIX 版 Claude Desktop，务必手动编辑配置文件并填入 uvx.exe 的绝对路径。安装后第一次运行可能超时，需要重启服务，这是文档明确提到的行为，不是故障。
社区笔记