那天下午，我在任務管理器里發現了一個吃內存的怪物。

剛開機，還沒打開任何大型軟件，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模式下徹底跳過虛擬機初始化，以及對過期會話文件做自動清理而非反復讀取。