Claude Desktop 启动即生成 1.8GB Hyper-V 虚拟机且无法停止：深度解读

背景

近期，在 Hacker News 社区引发广泛关注的一个 GitHub Issue（#29045）揭示了 Anthropic 旗下 AI 应用 Claude Desktop 在 Windows 平台上的一个严重资源管理缺陷。该问题由一位拥有 Razer Blade 15 笔记本电脑（i7-10750H, 16 GB RAM）的用户报告，指出即使仅进行基础的聊天操作，Claude Desktop 每次启动都会强制生成一个占用约 1.8 GB 内存的 Hyper-V 虚拟机（显示为 Vmmem 进程）。

这一现象不仅导致系统空闲内存占用率从约 50% 飙升至 62%，更引发了关于软件资源效率、后台服务触发机制以及会话文件清理逻辑的深度讨论。值得注意的是，该问题并非源于用户主动使用高级功能，而是由应用底层架构与 Windows 虚拟化平台的交互方式所致。

核心内容

问题现象与环境

用户报告指出，在 Windows 11 Pro 25H2 系统上，只要启用了 VirtualMachinePlatform（虚拟机平台），无论是否安装 WSL、Docker 或 Windows Sandbox，Claude Desktop 每次启动都会触发 Hyper-V Host Compute Service (vmcompute)。这会导致一个名为 vmwp.exe 的进程被创建，并在任务管理器中表现为占用约 1,796–1,846 MB 内存的 Vmmem 进程。

关键矛盾在于：

1. 功能无关性：用户仅使用基础的 Chat 功能，并未启用 Cowork 或 Agent 模式。
2. 不可控性：即使手动终止进程，重启应用或系统后，虚拟机仍会自动复活。
3. 错误日志：Hyper-V Compute Admin 事件日志中反复出现错误代码 0xC037010D，提示“指定的属性查询无效：虚拟机或容器 JSON 文档无效”。

根因调查

通过 PowerShell 诊断，报告者排除了其他虚拟化软件（如 Docker、WSL）的干扰，确认唯一相关的启用功能是 VirtualMachinePlatform。深入分析发现：

• 服务触发机制：vmcompute 服务虽设置为“手动”启动，但在开机时通过一个特定的 RPC 接口事件（GUID: bc90d167-9470-4139-a9ba-be0bbbf5b74d）被 services.exe 自动触发。
• 残留会话文件：在 %APPDATA%\Claude\local-agent-mode-sessions\ 目录下发现了 2,689 个陈旧的会话文件。这些文件命名风格类似 Docker（如 "nifty-dreamy-volta"），源自之前使用 Cowork 功能产生的会话。
• 清理逻辑缺失：即使删除所有 2,689 个文件并强制杀死 vmcompute 和 vmwp 进程，再次打开 Claude Desktop 时，应用仍会立即重新生成虚拟机和内存占用。这表明应用存在某种“看门狗”或自动恢复机制，或者在启动时读取了损坏的 JSON 配置导致不断重试。

影响评估

在 16 GB 内存的笔记本上，这一 Bug 导致空闲状态下的内存使用率激增。结合其他应用程序的正常负载，总内存使用率可达 70–75%，造成系统响应迟缓。用户被迫在每次启动后手动执行 PowerShell 命令来终止相关进程，否则无法获得流畅的使用体验。

预期行为与当前变通方案

• 预期行为：Claude Desktop 应在仅使用 Chat 功能时不启动 VM 基础设施；仅在用户主动请求 Cowork 或 Agent 模式时才初始化 VM；自动清理陈旧的会话文件；在 VM 初始化失败时优雅降级而非无限制占用资源。
• 当前变通方案：
  1. 彻底禁用虚拟化平台（推荐但牺牲功能）：

     Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
     

     此操作会禁用 Cowork 功能，但能彻底解决内存占用问题。
  2. 手动杀进程（临时方案）：

     Stop-Process -Name vmwp -Force
     Stop-Process -Name vmcompute -Force
     

     聊天功能在杀死进程后仍可正常工作，但每次重启应用需重复此操作。

关键要点

• 资源浪费严重：Claude Desktop 在仅进行文本聊天时，强制占用约 1.8 GB 内存用于运行一个闲置的 Hyper-V 虚拟机，这对低内存设备（如 16 GB RAM）用户极不友好。
• 自动化触发机制异常：虚拟机并非由用户直接启动，而是由 Windows 服务 vmcompute 通过 RPC 事件在应用启动时自动拉起，且伴随无效的 JSON 配置错误。
• 会话清理失效：应用未能有效清理旧的 Cowork 会话文件（报告中多达 2,689 个），这些残留文件可能是导致应用不断尝试重建 VM 环境的诱因之一。
• 功能耦合度过高：基础 Chat 功能与高级 Agent/Cowork 功能的底层基础设施（VM）耦合过紧，缺乏按需加载（On-demand）或优雅降级机制。
• 修复建议明确：用户呼吁 Anthropic 修改应用逻辑，实现基础设施的按需初始化，并完善会话数据的自动清理机制。

意义与影响

1. 对 Windows 平台 AI 应用开发的警示

该案例暴露了本地 AI 客户端在 Windows 环境下对系统虚拟化资源管理的潜在风险。随着 AI 应用本地化趋势加剧，越来越多的应用依赖 WSL 或 Hyper-V 来运行沙箱环境或 Agent 逻辑。如果应用不能精细控制这些重型基础设施的生命周期，将严重损害用户体验，甚至引发系统稳定性问题。

2. 用户体验与硬件门槛

对于拥有 16 GB 或更低内存的主流笔记本电脑用户而言，1.8 GB 的无谓占用是显著的负担。这不仅影响了多任务处理能力，还可能迫使硬件厂商在预装 AI 软件时更加谨慎，或促使软件开发商提供“轻量级模式”选项。

3. 软件健壮性与错误处理

日志中反复出现的“Invalid JSON document”错误表明，应用在处理损坏或过期的本地状态文件时缺乏鲁棒性。一个健壮的客户端应当能够识别并清理无效状态，而不是陷入无限重试或资源占用的循环。

4. 社区反馈与开发者响应

该 Issue 在 Hacker News 获得大量关注，反映了开发者社区对资源效率的高度敏感。Anthropic 需对此类底层架构问题进行快速响应，优化 Claude Desktop 的启动逻辑和资源释放机制，以维护其在 Windows 平台上的专业形象。