WSL Manager：把 WSL 指令碼收進圖形介面，順便跨進 macOS 虛擬機
GUI for the Windows Subsystem for Linux — and native Linux/macOS VMs on Mac. Install, back up, move and configure distros without CLI flags; AI assistant with tools, MCP server for agents, remote WSL over SSH.
秒懂
- 它是什麼？
- WSL Manager 以 Flutter 打造的 GUI 涵蓋 WSL 發行版管理、Docker 映像轉發行版、遠端 WSL 與 MCP 伺服器，並在 macOS 上透過 Virtualization framework 管理原生虛擬機。本文檢視它的實際機制、限制與適用邊界。
- 適合誰用？
- WSL Manager 適合那些每天在 WSL 裡安裝、複製、搬移發行版，卻不想記 wsl.exe 參數的開發者，也適合需要在 macOS 上以圖形介面建立 Linux 虛擬機的使用者。不適合完全不信任 GUI 工具、需要完整 Kubernetes 管理（目前僅在 debug 建置中出現）或要求 macOS VM 功能脫離 beta 狀態的團隊。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 Dart（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決什麼問題：把 WSL 的指令列痛點變成視覺化操作
WSL 的日常管理，例如安裝發行版、複製執行個體、搬移到其他磁碟、備份與刪除，通常得靠 wsl.exe 的各種旗標。對不熟悉指令列的開發者，這些參數是記憶負擔；對熟悉的人，重複輸入也煩人。WSL Manager 想解決的正是這個：它提供一個圖形介面，讓使用者在視窗裡點選完成這些操作，不需要記住任何 wsl.exe 旗標。根據 README，它支援從內建目錄安裝發行版，或匯入自己的 rootfs，也能複製、重新命名、搬移、備份與刪除執行個體。它甚至能壓縮虛擬磁碟，回收 WSL 不會自動釋放的空間。這專案的主要對象是 Windows 上的 WSL 使用者，但因為它也支援 macOS 的原生虛擬機，對象擴及需要在 Mac 上跑 Linux 虛擬機的開發者。值得注意的是，macOS 支援標記為 beta，且依賴 Apple 的 Virtualization framework，這表示它並非完整的虛擬機器平台，而是聚焦於特定工作流程。
運作機制：從 WSL 指令到 macOS 虛擬機的雙軌架構
這個專案的核心是雙軌設計。在 Windows 上，它直接操作 WSL2 的發行版；在 macOS 上，它改用 Apple 的 Virtualization framework 管理虛擬機。這不是同一個程式碼在兩個平台跑同樣功能，而是針對底層技術分別實作。README 指出，macOS 版可以從安裝 ISO、雲端映像或匯出的範本建立 Linux 虛擬機，也能在 Apple Silicon 上從還原映像建立 macOS guest。它透過自動佈建的 SSH（使用 cloud-init）在虛擬機內執行指令，而且會把你的 ~/.ssh 金鑰授權到每個 Linux VM，所以可以直接用 ssh user@vm-ip 連線。這個機制有個細節：當你從 macOS 部署整個執行個體到雲端時，由於 Linux VM 的磁碟映像是可開機機器，而不是容器引擎能讀取的格式，它會從執行中的 guest 讀出 root filesystem。這表示，如果你要把雲端上的執行個體拉回本地，在 macOS 上它會還原成一個 VM 的複本，而那個原始 VM 必須仍然存在且已停止，因為裸露的 root filesystem 沒有核心可以開機。這種依賴原始 VM 的設計是實際的限制，不是文件沒寫清楚的瑕疵。
安裝與啟動：從 Store、GitHub 或腳本建置
要取得 WSL Manager，README 提到三種管道：Microsoft Store、GitHub 上的 release 建置，以及網站 wslmanager.com。Store 版本由 Store 自動更新，而網站和 GitHub 建置會自行下載並安裝新版本。如果你是開發者想自己建置，macOS 版需要執行 scripts/build_macos.sh，這個腳本會打包已簽署的 vmctl helper。Windows 上沒有提供明確的建置指令，但由於它是 Flutter 專案（主要語言是 Dart），理論上可以用標準的 flutter build 流程，不過 README 沒有詳細說明。安裝後，你不需要手動編輯 .wslconfig，因為介面提供記憶體、處理器、swap、網路模式、DNS 等設定選項。它也支援掛載實體磁碟或 VHD 到 WSL，並控制分割區與檔案系統。實際使用上，你可以在 GUI 裡選擇要管理的發行版，然後執行複製、搬移或備份，這些動作背後會呼叫對應的 WSL API 或指令，但使用者看不到細節。這個抽象層是優點也是風險，如果 WSL 底層行為改變，GUI 可能需要更新才能跟上。
進階功能：Docker 映像轉發行版與 .wsl 可攜檔
WSL Manager 不只管理既有發行版，它還允許把任何 Docker 映像當作 WSL 發行版，而且不需要安裝 Docker。這個功能很實用，因為 Docker Hub 上有大量預先設定的環境，你可以直接拉取變成 WSL 執行個體。另外，它能將設定好的發行版打包成可攜的 .wsl 檔案，這個檔案可以在任何機器上安裝。README 明確說 templates 已被棄用，取而代之的是 .wsl 檔案，這是一個重要的設計轉變，代表專案在引導使用者走向更標準的格式。它還支援 snippets，讓你把設定指令存在應用程式裡，然後在任何執行個體上執行。若你維護自己的 rootfs 映像儲存庫，也能讓應用程式指向該儲存庫。這些功能讓 WSL Manager 不只是管理工具，更像是發行版的生命週期管理平台。不過，使用 Docker 映像作為發行版時，映像的檔案系統必須符合 WSL 的 rootfs 結構，否則可能無法啟動，這點 README 沒有詳細警告，使用時需要自行驗證。
AI 助理與 MCP 伺服器：讓代理直接操作 WSL
這個專案在 2.0 系列加入了 AI 助理與 MCP（Model Context Protocol）伺服器。MCP 是讓 AI 代理能與外部工具互動的協定，WSL Manager 的 MCP 伺服器允許 AI 代理驅動你的 WSL 環境。換句話說，你可以讓一個 LLM 透過 MCP 介面執行 WSL 管理操作，例如建立發行版或執行指令。這不是單純的聊天功能，而是工具整合。在 macOS 上，同樣的機制可以讓 AI 聊天或 MCP 用戶端在虛擬機內執行指令，透過自動佈建的 SSH。這種設計的潛在風險是安全：允許 AI 代理操作你的虛擬機器，等於開放一個自動化介面，如果代理的權限控制不當，可能執行破壞性指令。README 沒有詳細說明 MCP 伺服器的授權模型，只說它存在。實際使用前，你應該確認 MCP 伺服器是否限制操作範圍，以及 AI 助理是否需要明確的使用者確認。這是個有趣的方向，但文件資料不足，無法確認其實作細節。
真正的限制：未發布的功能與 macOS beta 的邊界
WSL Manager 的 README 中有一段被註解掉的內容，提到 Docker 與 Podman 容器管理、Kubernetes 叢集管理以及雲端部署功能。這些功能「已建置」，但只會在 debug 執行中出現，因為 LicenseManager.unreleasedFeaturesVisible 這個開關控制，正式 release 不會包含它們。這表示，如果你從 GitHub 下載最新 release，你無法使用容器管理或 Kubernetes 功能，只有當你自行以 debug 模式建置時才看得到。這是個明確的限制，文件也誠實地標註了。另外，macOS 虛擬機功能整體是 beta，而且雲端部署（推送到 Hetzner Cloud）也是 beta。beta 意味著 API 可能變動，功能可能不穩定。如果你需要穩定的容器管理，這個專案目前不是正確選擇，因為那些功能根本不在 release 中。另一個限制是，macOS 的 VM 管理依賴 cloud-init 與 SSH，這表示 guest 必須支援 cloud-init，否則自動金鑰授權不會運作。對於自訂 ISO 或特殊映像，你可能需要手動介入。
替代方案：wsl.exe 指令與其他 GUI 工具的比較
WSL Manager 的直接替代方案是 Windows 內建的 wsl.exe 指令。對於熟悉指令列的人，wsl --install、wsl --export、wsl --import 這些指令可以完成大部分管理任務，而且不需要安裝任何額外軟體。差別在於 wsl.exe 沒有圖形介面，也沒有 .wslconfig 的視覺化編輯器，更不用說 MCP 伺服器。另一個替代方案是 Windows Terminal 加上手動編輯設定檔，但這不算是管理工具。在 macOS 端，替代方案是 UTM 或 VirtualBox，它們提供完整的虛擬機管理，但 UTM 是獨立應用程式，與 WSL 無關，而 WSL Manager 的 macOS 版試圖用同一套介面管理 VM，讓 Windows 與 macOS 使用者有類似的體驗。如果你只需要在 macOS 上跑 Linux VM，UTM 可能更成熟，因為它沒有 beta 標籤。WSL Manager 的獨特之處在於跨平台的一致性，以及與 WSL 生態的整合，但若你不需要這些，傳統工具可能更穩定。
維護與授權：更新機制與授權的模糊地帶
關於維護成本，README 顯示專案活躍，最後一次推送是 2026 年 9 月，且近期有 2.0.2、2.0.1、2.0.0 連續發布，這表示修復與功能迭代頻繁。更新機制分為兩種：Store 版由 Microsoft Store 自動更新，網站與 GitHub 建置則會自行下載並安裝新版本。這種「自行更新」的行為對某些企業環境可能是風險，因為它會自動執行下載的執行檔，如果你沒有控管更新來源，可能引入未預期的變更。授權部分，這個專案的 LICENSE 標示為 NOASSERTION，這不是標準的開源授權（如 MIT 或 GPL），而是表示授權狀態無法從資料庫確認。README 提到 Pro 版本是一次性購買，透過 Microsoft Store 或 wslmanager.com/buy 取得授權金鑰，但免費版的功能範圍沒有明確說明。這表示，如果你打算在商業環境使用，你必須先釐清授權條款，因為 NOASSERTION 不代表它是免費軟體或開源軟體。這是一個需要實際查看授權檔案的點，但 README 沒有提供詳細資訊。
編輯結論
WSL Manager 適合那些每天在 WSL 裡安裝、複製、搬移發行版，卻不想記 wsl.exe 參數的開發者，也適合需要在 macOS 上以圖形介面建立 Linux 虛擬機的使用者。不適合完全不信任 GUI 工具、需要完整 Kubernetes 管理（目前僅在 debug 建置中出現）或要求 macOS VM 功能脫離 beta 狀態的團隊。採用前先確認三件事：你的 Windows 版本是否支援 WSL2、Store 版本與 GitHub 建置的更新管道差異（Store 版由 Store 更新，其他版本自行下載安裝），以及 .wsl 可攜檔案的匯出格式是否符合你的備份政策。若你只是偶爾用 WSL，且對指令列熟悉，wsl.exe 加上 .wslconfig 手動編輯可能更輕量。但若你管理多台機器、需要遠端操作，或想讓 AI 代理直接控制 WSL，這個專案提供了具體的切入點，值得花時間測試其 beta 功能。
社群筆記