那天下午，我在任务管理器里发现了一个吃内存的怪物。

刚开机，还没打开任何大型软件，32GB内存就少了将近2GB。关闭所有前台应用，数字纹丝不动。这是台刚买三个月的笔记本，系统干净得像刚装修好的毛坯房。我开始杀进程：OneDrive、微信、Adobe后台服务……可疑的全关了一遍。内存占用依然坚挺。事情变得有意思了。

打开网易新闻 查看精彩图片

直到我把任务管理器切换到"详细信息"，按内存降序排列——一个叫Vmmem的进程赫然出现在第二位，吃了1,846MB。Vmmem是Hyper-V虚拟机的宿主进程。问题是我从来没装过虚拟机。

先交代一下我这台机器的底细。雷蛇灵刃15基础款，i7-10750H配16GB内存，Windows 11 Pro 25H2。Hyper-V功能确认关闭、WSL没装过、Docker不存在、Windows沙盒也是关的。虚拟化相关的Windows功能里，只开了"虚拟机平台"这一个选项——这还是因为某些Windows安全功能要它做底层支撑。内存完整性保护也是关的，而且在这个问题出现之前就一直是关的。

那么问题来了：一个没有开启任何虚拟机功能的系统里，这个1.8GB的Hyper-V虚拟机是谁拉起来的？

线索藏在一串事件日志里。打开事件查看器，翻到Hyper-V Compute Admin这个节点，满屏的错误记录——每隔几分钟就刷一条，最早的记录可以追溯到2026年2月19日。错误内容出奇地一致："指定的属性查询无效：虚拟机或容器JSON文档无效。（0xC037010D，'无效的JSON文档'）"。每次开机触发，每次启动某个应用也触发。

这个错误说明有人在反复尝试创建或查询一个虚拟机，但传进去的JSON配置文件是坏的。谁干的？

追查工具用了PowerShell做了三件事。第一，检查vmcompute服务的启动方式——这个服务负责Hyper-V的主机计算层，正常情况下是手动启动。但日志显示，它在每次开机时被一个RPC接口事件触发唤醒，触发源的GUID是bc90d167-9470-4139-a9ba-be0bbbf5b74d，发起者是services.exe（PID 1400）。这说明不是用户手动启动的，是某个注册了RPC回调的服务在系统引导阶段就把它唤醒了。

第二，排查了所有可能的虚拟化组件：WSL确实没装（wsl --shutdown返回"未安装"）、Docker桌面版不存在（进程列表里一片空白）、Hyper-V管理工具也没有（Get-VM命令直接报错）。唯一的嫌疑人是"虚拟机平台"这个底层功能。

第三，也是最关键的发现——在%APPDATA%\Claude\local-agent-m目录下，堆着2,689个过期的会话文件。这些都是之前使用Claude Desktop的"协作模式"或Agent功能时生成的。问题清楚了：Claude Desktop每次启动时，不管用户这回想不想用Agent功能，都会尝试初始化一个虚拟机运行环境，读取那些残留的会话文件，结果文件格式对不上，JSON校验失败，虚拟机创建卡在半路。但VM进程已经分配了1.8GB的物理内存。

复现路径非常简单：在Windows 11上装好Claude Desktop，打开虚拟机平台功能。用一次Agent模式（这会生成会话文件）。然后关掉Claude，再重新打开——甚至不需要进Agent模式，只是开个聊天窗口。打开任务管理器，Vmmem准时出现，占用1796到1846MB内存。

16GB内存的笔记本上，这意味着一开机就有超过11%的内存被一段破损的JSON吃掉了。而且你关不掉它——虚拟机进程由vmcompute服务托管，强行杀Vmmem会导致服务崩溃重连，虚拟机又会被重新拉起来。

这个问题暴露出一个设计上的尴尬：Claude Desktop把"可能需要Agent功能"和"必须初始化Agent运行环境"画了等号。哪怕用户只是想敲几行字聊个天，底层照样给你拉一台完整虚拟机起来。桌面端不像网页端那样可以按需加载沙箱——一旦代码路径走到环境初始化，内存分配就停不下来。而那些2,689个过期会话文件，则像一堆没收拾的餐具，每次新客人进门，后厨就对着脏盘子重新开火做饭。

目前的临时解法是手动删除%APPDATA%\Claude\local-agent-m下的所有文件，然后重启vmcompute服务。但下次再用Agent模式，文件又会重新生成，循环照旧。真正需要修复的是两件事：Chat-only模式下彻底跳过虚拟机初始化，以及对过期会话文件做自动清理而非反复读取。