Claude Desktop 只聊天也拉起 1.8GB VM：Agent 桌面化的边界失控

一台 16GB 内存的 Windows 11 Pro 机器，打开 Claude Desktop，还没跑 Cowork，也没让 agent 干活，任务管理器里先多出一个 Vmmem：约 1,796–1,846MB。

这不是“多占一点”的观感问题。它吃掉约 11% 总内存。原本空闲内存占用约 50%，打开后跳到约 62%。用户只是想聊天，机器却先替 AI 应用开了一间小机房。

这条报告说的是 Windows 桌面端 Claude Desktop，不是 Claude Code CLI。它也还不是大规模验证过的通病。但反常点已经够清楚：只聊天，也被 agent 基础设施拖进场。

这次到底发生了什么

原报告的环境锚点很具体：Windows 11 Pro，Claude Desktop 最新版，VirtualMachinePlatform 启用；Hyper-V、WSL、Docker、Windows Sandbox 都关闭，Core Isolation / Memory Integrity 也关闭。

关键信息压成一张表：

这里最容易误读的是 2,689 个残留会话文件。它们确实难看，也像清理机制出了问题。

但不能把它们直接判成根因。原报告里，删掉这些文件后，VM 仍会重新拉起。

更关键的一点是：手动杀掉 vmwp / vmcompute 后，聊天仍可用。也就是说，至少在这个报告里，普通聊天不依赖这台 VM。

那问题就来了：既然聊天不用它，为什么启动聊天窗口时要默认拉起它？

问题不是 VM，而是默认值

Cowork/agent 模式需要隔离环境，这合理。

让 AI 读写文件、跑命令、执行任务，本来就该有沙箱。虚拟机、容器、权限边界，都不是原罪。开发者不希望一个桌面 AI 裸奔到本机系统里，这点没争议。

真正的问题是启动顺序。

用户点 Cowork，再初始化 VM，这叫按需。用户只打开聊天窗口，也先拉起 1.8GB 虚拟化进程，这叫抢跑。

我不太买账“只是内存 bug”的轻描淡写。它当然可能最后被修成启动逻辑问题、会话清理问题，或者 Windows 虚拟化调用问题。但产品信号已经露出来了：agent 化产品很容易把“我可能马上要用”放在“用户现在要用”前面。

桌面软件史里，这事不新鲜。

杀毒套件、云盘同步、企业 IM、浏览器插件，都曾用“提升体验”的名义常驻后台。它们一开始也都有正当理由：更安全、更快、更连续。后来很多用户只记得一件事：机器变慢了，后台变厚了，退出也不干净。

今天换成了 AI agent。

不完全一样。AI agent 的本地隔离需求更强，安全理由也更硬。但老问题没变：供应商想要随时待命，用户只想按自己意图付成本。

天下熙熙，皆为利来。放到软件里，就是产品总会偏向降低自己的摩擦，而不是降低用户机器的负担。

受影响的人该怎么做

最该在意的是两类人。

一类是 Windows 上使用 Claude Desktop/Cowork 的开发者。尤其是 16GB 内存机器。你要看的不是启动界面，而是任务管理器里的 Vmmem、vmwp、vmcompute。

如果你不用 Cowork，可以禁用 VirtualMachinePlatform。代价很直接：Cowork 会废掉。

如果你还要用 Cowork，只能临时手动结束 vmwp / vmcompute。原报告显示，聊天仍可用。但这不是正常工作流，只是绕法。

另一类是准备在团队里铺 Claude Desktop/Cowork 的人。我的建议更保守：先别全员推。

至少先拿几台 Windows 机器做小范围验证。看三件事：启动后是否默认拉 VM，退出后资源是否释放，重复使用 Cowork 后是否堆 stale session。

如果团队机器以 16GB 内存为主，或者同时跑 IDE、Docker、浏览器、会议软件，这 1.8GB 不是小数。它会挤压的不是理论性能，而是每天都能感到的卡顿余量。

接下来最该盯的不是一句“已修复”。要看四个具体动作：

这件事现在还小，证据也有限。不能拿一个 issue 就判定 Anthropic 故意占用用户资源，也不能说所有 Windows 用户都会遇到。

但它戳中了 AI 桌面应用接下来最难躲的问题：模型越想变成工作台，产品越容易把本地机器当成自己的机房。

好产品不是没有野心。好产品知道什么时候候命，什么时候动手。只聊天就只聊天，需要 agent 再开 agent。这个顺序一乱，聪明就会先变成负担。