第 1007 期:谷歌为其新的 AI 工具添加原生 Windows 11 和 WSL 支持

适用于 Linux 的 Windows 子系统（WSL）越来越受欢迎。近日，谷歌悄悄确认，它正在为其智能开发平台 Antigravity 开发 WSL，同时还会提供更好的 Windows 原生支持，这对于一个在支持 Windows 上历史上不太稳定的公司来说，还挺罕见的。

WSL 让您可以直接在 Windows 里运行 Linux 发行版，无需双系统启动或使用完整虚拟机。现代很多软件，比如构建流水线、云基础设施，以及像 PyTorch 和 llama.cpp 这样的 AI 框架，都是先在 Linux 上编写和测试的。

如果您还没有注意到，谷歌的 Antigravity 是一种 AI 辅助开发工具。谷歌正在为 Antigravity 添加对 WSL 的支持。

WSL2 在一个轻量级、由微软管理的虚拟机中运行 Linux 内核，因此像 Docker、bash 和 Linux 原生包管理器这样的工具，可以像开发者期望的那样工作，同时仍然在 Windows 上运行。微软一直在努力将 WSL 打造成一个可靠的平台，而谷歌本周的消息，则是这一努力取得成效的最明显信号。

谷歌终于开始支持 WSL 和原生 Windows，这很罕见

众所周知，谷歌很少对 Windows 大方。它的大多数开发者工具不是把 Windows 当作次要平台，就是推出占用大量内存的基于浏览器的应用，而非原生应用。但至少对于 Antigravity 来说，情况似乎正在改变。

谷歌 Antigravity 部门和 DeepMind 的高级开发者关系工程师 Rody Davis 在社交媒体上发帖说：

“我们正在研究 WSL 和更好的原生 Windows 支持。花点时间真正把它做好，让它按我们想要的方式工作。其他功能的话会传达给团队的！”

我们在查看 Davis 发起的一个帖子时注意到了这点，帖子列出了近期 Antigravity 的更新，比如自定义子代理、远程控制、IDE 扩展和企业 API 密钥支持，然后询问用户他们的工作流程还缺什么。

有用户希望，在 Antigravity 2.0 应用中能够将代理环境切换到 WSL 上。Davis 确认，WSL 和原生 Windows 支持都在开发中。

WSL 部分很容易理解。Antigravity 的开发人员可以在 Linux 中运行文件操作、Shell 命令和构建，而不必先通过 Windows 进行转换。

“原生 Windows 支持” 这一部分就令人惊讶了，因为 Davis 没有说明具体是什么意思。他没有直接提到 WinUI，但这是唯一符合条件的候选。微软在 Build 2026 上确认，WinUI 将成为 Windows 的永久原生应用框架，WinUI 3 中的 “3” 也被去掉，以表示将不会有新的框架推出。微软还开始在 GitHub 上开源 WinUI，外部贡献和公开问题追踪已经上线。

讽刺的是，大多数基于 AI 的跨平台开发工具默认使用 Electron 框架，因为它可以更快地在各个平台运行。但我们都知道，它们的内存消耗非常高。如果谷歌推出一个原生 WinUI 应用，它将是少数几款在 Windows 上不依赖 Chromium 的谷歌产品之一。有趣的是，在它真正发布之前，我不会完全信任自己的乐观，但 Davis 的回复，看起来也不像是谷歌随便说的，尽管他提到，这还需要更多时间。

GitHub Copilot 的应用现在可以在 WSL 中运行代理会话

对于开发者来说，这个故事的下半部分可能更有趣。GitHub Copilot 产品经理 Pierce Boggan（之前在 Xamarin 工作）发布消息称，“GitHub Copilot 应用现已开始实验性支持 Windows 子系统 Linux（WSL）！”

设置在 “设置 > 实验功能” 下，有一个新的 “WSL 主机（预览）” 开关，可以让应用 “连接到 WSL 并在其中创建会话”。开启后，单独的 “环境” 页面会列出通过 wsl.exe 安装的每个 WSL 2 发行版，这里有一个标记为默认并正在运行的 Ubuntu 发行版。连接后，会显示实时的 WebSocket 地址，然后您可以通过指向项目的绝对 Linux 路径（比如 /home/pboggan/coloring-book）来注册项目，应用会先验证路径再添加。

针对该项目启动新会话时，会在顶部看到 “WSL: Ubuntu” 徽章，确认会话运行在 Linux 发行版中。在演示中，Boggan 输入了一个提示，让代理在底部添加一行文字：“Made in Park City, UT”。代理加载了前端设计技能，搜索了 Next.js 项目的 page.tsx、layout.tsx 和 globals.css 文件，直接在 WSL 中运行 git status –short && git branch 检查当前状态，找到了现有的样式化页脚，并只用一行修改就完成了编辑。

之后，它再次检查文件以确认新文本正确，并运行 git diff –check 进行更改验证，然后展示 “创建 PR” 按钮。整个循环，包括推理、文件编辑和 git 验证，都在 WSL 内运行，使用的模型是 GPT-5.6 Sol。

GitHub 内部针对 Copilot 应用的反馈指出，“Windows WSL 支持有限” 是已知问题。回复确认更多功能正在开发中。远程 SSH 预计最快下周可用，因为 WSL 的基础架构也作为连接任意远程主机的底层架构。

有用户提出，希望能直接从主菜单添加或克隆项目，而不用去设置里翻来翻去，Boggan 确认，这是接下来的计划。微软工程师 Michael Tierney 提到，WSL 支持不会改变 Copilot 生成代码的方式，只会影响代理的文件系统和 Shell 执行的位置。

WSL 现在是 Windows 最活跃的部分之一。最新的稳定版本 2.7.3 增加了目录级 VirtioFS 挂载、virtio 网络的 IPv6 支持，以及 VirtioProxy 模式下的 DNS 隧道，同时内核升级到了 6.18。我们之前也介绍过微软更广泛的 2026 计划，要让 WSL 文件访问更快、网络更好、安装更简单。除此之外，微软还发布了 WSL Containers，可以让您直接在 Windows 上构建和运行 Linux 容器，无需 Docker Desktop。我们也亲自体验了 WSL Containers，看看它实际表现如何。

Windows 正悄悄地再次成为一个严肃的开发者平台

尽管 Windows 11 因广告、更新问题和强制 AI 功能而几乎不断受到负面报道，但操作系统的开发者方面却表现出强劲的走势。在 Build 2026 上，微软推出了适用于 Windows 的 Coreutils，将 75 个熟悉的 Linux 命令行工具（如 ls、grep 和 mv）原生带到 Windows 上，完全不需要 WSL，这些工具是基于 Rust 的开源 uutils 项目构建的。WinUI 作为永久性原生应用框架的承诺，以及其向完全开源的转变，都显示出微软再次将原生 Windows 开发作为优先事项。

我们最近讨论了根据 Canonical 的数据，Ubuntu 在 Windows 11 上的增长速度比在原生 Linux 电脑上还快，这很能说明：开发者们越来越倾向于从哪里运行 Linux 工作负载。

Windows 11 仍然有很多问题需要解决。但 WSL 容器取代 Docker Desktop、Copilot 在 Linux 发行版内运行代理、WinUI 开源，现在还有谷歌为 WSL 和 Windows 开发应用，这一切都表明：微软正尽一切努力回归自己的本源。

另外值得一提的是，如果您是一位高效能人士，拓扑梅尔智慧办公平台最近也更新到了最新的 6.0 版本，带来了诸如文件管理，个人工作台，文件秒搜，远程协助，音视频通话等功能，可以帮助您进一步提升日常工作效率。

您平常使用 WSL 进行开发工作吗？您觉得它好用吗？