Antigravity要直连WSL了

谷歌开始补 Windows 开发体验的关键缺口

谷歌正在为 AI 编程智能体平台 Antigravity 开发 WSL 支持，目标是让它直接连接 Windows 10、Windows 11 中的 Linux 开发环境。Google DeepMind 高级开发者关系工程师 Rody Davis 已确认相关功能处于开发中，同时谷歌还在改善 Antigravity 的原生 Windows 使用体验。

这项能力截至 2026 年 8 月 30 日仍未正式发布，谷歌也没有公布具体上线日期、支持的 Linux 发行版清单和性能数据。因此，现在更准确的说法是“官方确认正在开发”，而不是“Antigravity 已经原生支持 WSL”。

Antigravity 是谷歌面向智能体编程场景推出的开发平台，包含 IDE、智能体面板和命令行工具，能够读取项目文件、修改代码、运行终端命令，并通过模型完成多步骤开发任务。它与传统代码补全工具的区别在于，后者主要预测下一段代码，前者则需要真正进入项目环境，调用编译器、包管理器、测试框架和 Git 完成一整条任务链。

WSL 是 Windows Subsystem for Linux 的缩写，是微软让 Windows 用户无需安装双系统即可运行 Linux 用户空间、命令行工具和软件包的兼容环境。对大量 Windows 开发者来说，编辑器运行在 Windows 桌面上，而 Node.js、Python、Docker CLI、Git、编译工具链和项目源码实际位于 WSL，这已经是 Web 开发与 AI 工程的常见配置。

这不是增加一个终端选项，而是把智能体搬进真实环境

WSL 支持的核心价值是让智能体看到的开发环境与代码实际运行的环境保持一致。没有原生连接时，Antigravity 即使能打开 Windows 中的项目文件，也可能在错误的系统上下文中执行命令，最终出现“代码改对了，但依赖装错地方”“测试能生成，但无法运行”的情况。

WSL 2 是基于轻量级虚拟机运行真实 Linux 内核的 WSL 架构，相比早期 WSL 1，它对 Linux 系统调用、容器和复杂开发工具链的兼容性更完整。开发者可以在 Ubuntu 等发行版中使用 apt、Bash、SSH、Linux 版 Git 和语言运行时，同时继续使用 Windows 桌面应用。

“直连 WSL”通常意味着编辑器界面仍运行在 Windows，但文件扫描、终端命令、语言服务和智能体工具调用进入指定的 WSL 发行版执行。不过，谷歌目前尚未公开 Antigravity 的具体实现架构，因此它会采用远程扩展宿主、WSL 内守护进程，还是其他通信机制，仍需等待正式版本确认。

这一区别对普通对话助手不算重要，对拥有终端权限的编程智能体却决定了功能是否可靠。一个智能体如果读取的是 Windows 路径，却在 WSL 中执行测试，就可能同时面对路径映射、文件权限、换行符、符号链接和环境变量差异；当任务扩展到安装依赖、启动服务和调用容器时，问题会进一步放大。

Windows 用户此前最痛的不是模型能力，而是环境割裂

Windows 与 Linux 的路径体系差异是当前智能体工具最容易踩中的第一类问题。Windows 项目可能位于 C:\Users\用户名\project，WSL 项目则通常位于 /home/用户名/project，Windows 侧还可能通过 \\wsl.localhost 访问 Linux 文件系统，但这种访问方式不等于工具已经进入 Linux 执行环境。

终端上下文不一致是第二类问题。智能体在 PowerShell 中执行 python、node 或 git，调用到的可能是 Windows 版本；同样的命令进入 WSL 后，版本、全局依赖、证书、SSH 配置和环境变量都可能完全不同。

文件语义差异是第三类问题。Linux 默认区分文件名大小写，并依赖 POSIX 权限与可执行位，而 Windows 文件系统的默认行为不同；AI 智能体如果在宿主侧批量创建脚本或重命名文件，可能直到 CI 在 Linux 上运行时才暴露错误。

长时间运行的智能体任务还会放大跨文件系统的性能成本。大型仓库的索引、依赖目录扫描和 Git 状态检查都涉及大量小文件操作，如果项目放置位置和执行环境没有匹配，即使模型推理足够快，整个任务仍可能卡在 I/O 和文件监听上。

原生 WSL 支持如果实现到位，最应该解决的不是“能打开 Linux 文件”，而是让以下能力处于同一个上下文：

• 项目根目录与文件索引位于同一 WSL 发行版；
• 智能体终端直接调用 Linux Shell 和工具链；
• 语言服务器使用 WSL 内安装的 SDK 与依赖；
• Git、SSH、环境变量和证书沿用 Linux 配置；
• 测试、构建及调试命令在项目真实运行环境中执行；
• 智能体重启后能够恢复此前选择的发行版、工作区和权限设置。

GitHub Copilot 已经先走了一步

GitHub Copilot 桌面端已于 8 月 26 日宣布实验性支持 WSL，比谷歌这次确认早了数日。用户可以在“设置 → 实验性功能”中启用“WSL hosts（预览）”，连接通过 wsl.exe 安装的 WSL 2 发行版，并使用 Linux 绝对路径注册项目。

微软与 GitHub 的优势是掌握 Windows、WSL、Visual Studio Code 和 GitHub 这条完整开发链路。谷歌如果只是提供基础文件访问，Antigravity 很难在 Windows 开发体验上形成差异；谷歌真正需要证明的是，它能否把多智能体编排、终端执行和安全权限一起带进 WSL，而不是停留在“项目能够打开”的层面。

| 对比项 | Antigravity 当前 Windows 体验 | Antigravity 计划中的 WSL 支持 | GitHub Copilot 桌面端 WSL 预览 | |---|---|---|---| | 截至 2026 年 8 月 30 日状态 | Windows 版本可用，但 WSL 原生体验仍在完善 | 官方确认开发中，尚未公布上线时间 | 8 月 26 日开始提供实验性功能 | | Linux 项目连接 | 可能依赖现有编辑器能力或社区方案 | 目标是原生连接 Windows 内的 Linux 环境 | 可连接经 wsl.exe 安装的 WSL 2 发行版 | | 项目路径 | Windows 与 Linux 路径可能需要手动处理 | 预计围绕 Linux 工作区统一处理，细节待公布 | 使用 Linux 绝对路径注册项目 | | 智能体执行环境 | 容易出现 Windows 与 WSL 上下文分离 | 目标应是让命令和项目位于同一环境 | 预览功能已提供 WSL host 连接 | | 支持范围 | Windows、macOS 及特定 Linux 发行版 | WSL 发行版清单尚未公布 | 当前明确指向 WSL 2 | | 价格变化 | 本次消息未涉及 | 本次更新未披露单独定价 | WSL 预览本身未披露独立价格 | | 性能数据 | 无官方跨环境基准 | 暂无延迟、索引速度或资源占用数据 | 暂无可直接横向比较的官方数据 |

这张表也说明，现阶段不能根据功能名称判断双方胜负。GitHub 已经把功能交给用户测试，而谷歌目前只确认开发计划；在产品更新的时间线上，前者是可用的预览版，后者仍是一张明确但尚未兑现的路线图。

社区绕行方案存在，但不等于官方原生支持

社区此前已经尝试通过 Remote-WSL 类入口在 WSL 中使用 Antigravity，但配置体验并不完整。有社区 SDK 开发者反馈，通过命令菜单进入 Remote-WSL 后，界面虽然相似，全局指令、MCP 等数据却可能需要重新设置；这类信息来自社区实践，不能视为谷歌的正式支持承诺。

MCP 是 Model Context Protocol 的缩写，是让 AI 应用以统一方式连接外部工具、数据源和服务的协议。在智能体开发环境中，MCP 配置不仅包括服务器地址，还可能涉及本地进程、命令路径、权限与环境变量，因此 Windows 侧配置未必能直接迁移到 WSL。

官方原生支持的价值就在于减少这类重复配置和隐式差异。理想状态下，Antigravity 应明确区分 Windows 宿主配置与 WSL 工作区配置，并告诉用户某个 MCP 服务、Shell 命令或文件访问动作究竟运行在哪里，而不是让用户通过报错猜测执行上下文。

安全权限会成为这次更新真正的技术难点

WSL 连接会扩大 Antigravity 智能体能够触达的系统范围。谷歌官方 Codelabs 已提醒用户检查 Antigravity 的高级设置与智能体安全模式，因为终端命令和文件系统访问权限决定了智能体可以自主执行到什么程度。

Windows 与 WSL 同时开放后，权限边界会比单一操作系统复杂得多。WSL 可以挂载 Windows 磁盘，Windows 也能访问 WSL 文件；如果智能体既能修改 Linux 项目，又能进入 /mnt/c，一次错误的清理命令就可能影响宿主机文件。

成熟的 WSL 支持至少需要提供四层防护：工作区范围限制、危险命令确认、跨系统路径提示和可审计的操作记录。对于删除文件、修改权限、安装系统软件、读取 SSH 凭据和访问 Windows 挂载目录等动作，Antigravity 不应只给出笼统的“允许终端访问”开关。

企业用户还会关注 WSL 中的网络与凭据隔离。智能体可能需要访问私有代码仓库、内部包源和本地服务，但这些能力不应自动意味着它可以读取所有 Shell 配置、云服务凭据或宿主机目录。

这次更新对谁最有用

全栈与后端开发者会是原生 WSL 支持最直接的受益者。这类项目经常依赖 Linux 容器、Bash 脚本、原生编译模块和与生产环境一致的软件包，智能体进入 WSL 后，生成代码、安装依赖和执行测试才可能真正形成闭环。

AI 工程师同样需要统一的 Linux 上下文。Python 虚拟环境、CUDA 工具链、模型文件、Jupyter 服务和本地推理程序常常部署在 WSL 2 中，如果 Antigravity 只能从 Windows 侧读取源码，却无法调用对应解释器和运行时，它的智能体能力会被削弱成高级文本编辑。

跨平台项目维护者也能减少 CI 才暴露问题的概率。让智能体在 Linux 环境中直接执行格式检查、单元测试和构建任务，可以更早发现大小写、权限、Shell 语法和依赖差异，但这并不能替代正式的 CI 流程。

纯 Windows 技术栈用户获得的收益则相对有限。如果项目主要使用 .NET、PowerShell、Windows SDK 或桌面 UI 框架，直接在 Windows 宿主中运行 Antigravity 可能更自然，强行迁移到 WSL 反而增加路径和调试复杂度。

谷歌补的是基础设施，不是一个炫技功能

Antigravity 对 WSL 的支持看起来只是平台适配，实际上决定了 AI 编程智能体能否在 Windows 上完成可靠的端到端任务。模型可以生成正确代码，但如果智能体连错解释器、装错依赖或在错误文件系统中执行命令，再强的推理能力也会被环境问题抵消。

谷歌此时跟进 WSL 也说明，AI 编程工具的竞争已经从“谁更会补全代码”转向“谁更懂开发环境”。模型质量仍然重要，但编辑器、终端、容器、权限、版本控制与远程环境之间的连接质量，正在成为影响智能体成功率的基础变量。

Antigravity 的下一步观察重点不是发布按钮何时出现，而是三个更具体的问题：命令是否真正运行在 WSL、配置能否在 Windows 与 Linux 间稳定迁移、危险操作是否有清晰的权限边界。只有这三项都做好，谷歌才算补齐 Windows 原生 AI 开发体验；如果只是增加一个 Remote-WSL 入口，它与成熟竞品之间仍有距离。

参考来源

• IT之家：谷歌确认开发 WSL 支持，Antigravity 将直连 Win11 Linux 环境——汇总 Windows Latest 报道、Rody Davis 的确认信息，以及 GitHub Copilot WSL 预览的上线时间与启用方式。
• Reddit：Antigravity 社区 SDK 开发者讨论 Remote-WSL 与配置问题——社区用户对现有 Remote-WSL 使用方式、全局指令与 MCP 配置迁移问题的经验反馈，属于非官方信息。