谷歌 Antigravity 团队的一名开发者关系工程师在社交媒体上发了一条推文，说了两件事：团队正在为 Antigravity 开发 WSL 支持；同时在改善这款 AI 编程平台在 Windows 上的原生体验。就在同一周，GitHub Copilot 桌面端刚刚宣布了实验性 WSL 支持。
放在一年前，这条新闻大概只够在开发者社区里激起几轮技术讨论。但在 2026 年 8 月底这个节点上，它传递的信号远不止“又多了一个工具支持 WSL”——它意味着 AI 编程赛道上一场关于“操作系统底座”的暗战，正在从后台走到前台。
一周内，两个 AI 编程头号选手同时表态
先看事实。8 月 29 日，科技媒体 Windows Latest 援引谷歌 Antigravity 与 DeepMind 团队高级开发者关系工程师 Rody Davis 的推文报道称，谷歌正为其 AI 编程智能体平台 Antigravity 开发 WSL（Windows Subsystem for Linux）支持。具体来说，这项功能将让 Antigravity 直连 Windows 11 的 Linux 子系统环境，完善对 Windows 10 和 Windows 11 的原生支持。
几天前，GitHub Copilot 在 8 月 24 日那周的更新中刚刚为桌面端加入了实验性 WSL 支持。用户可以在“设置 → 实验性功能”中启用“WSL hosts（预览）”，连接已安装的 WSL 2 发行版，并使用 Linux 绝对路径注册项目。Copilot 产品负责人 Pierce Boggan 展示的 Demo 中，AI Agent 在 WSL 环境中顺利完成了文件和 Git 操作。
两个 AI 编程领域的头号选手，在一周之内就同一件事相继表态。这当然不是巧合。
为什么 AI IDE 们突然集体盯上 WSL？答案藏在 Windows 开发者生态的一个核心矛盾里。
Windows 开发者的“身份分裂”
WSL 诞生于 2016 年，最初只是一个勉强能跑 Linux 命令行的兼容层。十年后的今天，它已经进化成微软在开发者生态中最成功的战略投资之一——微软在 2025 年 Build 大会上将 WSL 开源，社区贡献每月超过 200 个 PR。2026 年 6 月的 Build 大会上，微软又推出了 WSL Containers，把容器运行时直接集成到了 WSL 中。
但 WSL 之于 Windows 开发者，一直是个“不得已的选择”。原因很简单：绝大多数 Web 服务器运行在 Linux 上，容器、Kubernetes、CI/CD 基础设施几乎全是 Linux 原生的。一台 Windows 机器要成为真正能用的开发工具，WSL 几乎是必装项。但 WSL2 的跨文件系统 I/O 性能一直是公认的痛点——项目文件如果放在 Windows 分区（/mnt/c），通过 9P 协议翻译层访问的速度比 WSL 内部 ext4 卷慢了 30% 到 60%。更别提网络模式下 localhost 通信的种种曲折。
AI 编程工具的出现，让这个矛盾从“麻烦”升级成了“瓶颈”。AI Agent 的工作模式与传统 IDE 截然不同：它不仅要补全你的代码，还要自主操作终端、运行测试、安装依赖、甚至启动浏览器进行验证。这些操作在 WSL 环境下每多一层抽象，就多一分出错的概率。
GitHub Copilot 和 Antigravity 几乎同一周选择攻克 WSL 支持，说明它们对一件事达成了共识：AI Agent 能不能在 Windows 上“跑起来”，已经不再是加分项，而是必备项。
两种路线，同一个终局
尽管目标一致，Copilot 和 Antigravity 切入 WSL 的方式体现了完全不同的产品哲学。
GitHub Copilot 走的是“轻量适配”路线。其 WSL 支持以实验性功能的形式藏在设置菜单里，用户需手动启用“WSL hosts（预览）”，然后连接已安装的 WSL 2 发行版。这种方式门槛低、交付快，体验上更像一个“补丁”——在 Copilot 已有的 IDE 扩展能力之上，新增一个连接 Linux 环境的通道。
Antigravity 的选择则激进得多。它不是简单地在现有产品上打补丁，而是从架构层面重新设计了对 WSL 的支持。根据 Rody Davis 的表态，谷歌正在“为智能体开发平台 Antigravity 开发 WSL 支持，并改善其原生 Windows 使用体验”。这句话的隐含信息是：Antigravity 的 WSL 支持将是深度的、平台级的——它不是让 Antigravity 能识别 WSL 里的文件，而是让 Antigravity 的智能体能够在 WSL 环境中原生地执行任务。
这两种路线的差异，本质上来自两者对“AI Agent”这件事的定义不同。在 GitHub 的语境中，Copilot 是一个“AI 编程助手”——它帮你写代码、做补全、回答技术问题。WSL 支持的核心需求是让 Copilot 能准确理解 Linux 环境的项目文件。而在谷歌的语境中，Antigravity 是一个“智能体优先的开发平台”——它生来就是为了让 AI Agent 自主完成复杂的开发任务。WSL 支持的核心需求是让 Agent 能在 Linux 环境中运行命令、调试代码、部署服务。一个是辅助工具，一个是自主平台，WSL 支持的技术纵深完全不同。
一个关键的微观案例能说明这种差异。Antigravity 的核心差异化之一是“智能体可自主操作浏览器”，这意味着 Agent 需要在 Windows 上操控 Chrome 浏览器。但在 WSL2 的虚拟化网络架构下，Linux 端的 Agent 和 Windows 端的 Chrome 之间默认无法通过 localhost 通信。社区不得不通过端口转发、防火墙规则甚至 socat 隧道等方式手动打通。这种体验连“可用”都勉强，更谈不上“流畅”。如果谷歌能在本次 WSL 开发中从平台层面解决这些网络和通信问题，Antigravity 在 Windows 上的用户体验将出现质的飞跃。
WSL 成 AI IDE 新战场，微软角色耐人寻味
这场 WSL 竞赛中最微妙的一层，是微软的立场。
一方面，微软是 WSL 的构建者和维护者。WSL 生态的繁荣直接受益的是 Windows 平台本身。从 Build 2025 开源 WSL 到 Build 2026 推出 WSL Containers，微软不断把 Linux 开发者拉回 Windows 生态。从这个角度看，无论 Copilot 还是 Antigravity 把 WSL 体验做得更好，都符合微软的利益。
但另一方面，Copilot 是微软亲儿子，Antigravity 是谷歌的王牌。微软在 WSL 底层基础设施上的持续投入，客观上降低了谷歌产品在 Windows 上落地的门槛。这是一个典型的“基础设施悖论”：微软建的桥，谷歌的车也能走。
更值得玩味的是，Antigravity 最初发布时对 Windows 的支持只能算“能用”，离“好用”有不小的差距。社区中大量开发者反馈 Antigravity 在 WSL 环境下的配置繁琐、浏览器 Agent 无法直连 Windows 端的 Chrome、agy 命令行工具在 WSL 内无法开箱即用。这些问题的本质，是 Antigravity 作为一个基于 VS Code 构建的产品（2025 年 11 月发布），在 Windows 端的适配深度远不如其 Linux 和 macOS 端。
如今，谷歌主动表态要解决这个问题，动机既清晰又复杂。清晰的是，Windows 开发者市场不能丢——全球数以千万计的 Windows 开发者是 AI 编程工具最大的增量用户池。复杂的是，这个市场的地基（WSL）掌握在微软手中，后者恰好也是 AI 编程赛道最直接的竞争对手。
这种局面在 AI 史上并非没有先例。2024 年到 2025 年，苹果和微软在 AI 领域的竞合关系就呈现出类似模式：苹果在 Mac 上引入 AI 功能，微软则通过 Azure 为苹果的 AI 服务提供算力。技术与商业从来不是非黑即白的零和游戏。
从模型竞争到生态竞争：AI 编程赛道的转折点
WSL 支持只是表层动作。真正值得关注的，是 AI 编程赛道正在经历的一个结构性转变。
过去两年，AI 编程的竞争焦点是模型能力——谁能生成更长的代码、谁在 SWE-bench 上拿更高分数、谁能写更复杂的多文件修改。Cursor 凭借 72% 的代码补全接受率领先，Copilot 靠 GitHub 生态构建护城河，Antigravity 拿 Gemini 3 Pro 打差异化，Windsurf 在被 Cognition 收购后整合为 Devin Desktop。
但到 2026 年下半年，模型能力之间的差距正在快速缩小。Gemini 3 Pro、Claude Sonnet 4.5、GPT-5 这些顶级模型的代码生成能力已经难分伯仲。竞争的天平开始从“谁的模型更强”转向“谁的工作流更厚”。而“工作流厚度”的核心衡量标准之一，就是 AI Agent 在多大程度上能在开发者实际使用的操作系统环境中无缝运行。
换句话说：当所有工具都能写出差不多的代码时，开发者选择哪一个，取决于它能不能在自己的 Windows 笔记本上、通过 WSL 连接到 Linux 开发环境后、依然流畅地完成从编辑到部署的完整流程。
这不是一个小问题。Antigravity 当前处于一个微妙的窗口期。它发布于 2025 年 11 月，至今不到 10 个月，在 AI IDE 市场的认知度和装机量尚不及 Copilot 和 Cursor。尽管凭借谷歌的品牌影响力和 Gemini 3 Pro 的模型优势，它在开发者社区中迅速建立了口碑，但市场份额的积累需要时间。
侧面，Cursor 在 2026 年 3 月推出了 JetBrains 插件，正在突破 VS Code 生态的限制。Windsurf 被 Cognition 收购后整合为 Devin Desktop，Cognition 在 2026 年 4 月的估值已达 250 亿美元。Copilot 最大的优势，从来不是模型能力或技术架构，而是它的生态位置——GitHub 是全球最大的代码托管平台，Copilot 天然站在开发者工作流的正中间。
当 Copilot 能够在 WSL 中稳定运行时，它不需要开发者做任何额外的切换：打开 VS Code，连接 WSL，Copilot 就在那里。Antigravity 和其他 AI IDE 则需要开发者主动下载、安装、配置。
这就是谷歌必须在 WSL 上“打好这一仗”的原因。在 AI 编程的竞争已经从模型能力转向生态体验的当下，Windows 开发者体验绝不能再是短板。
一条推文背后的行业信号
回到最初那条推文。Rody Davis 发的信息量其实不大——没有发布时间表，没有功能细节，甚至连“正在开发”这个表述本身都是软性的。但在这个时间点放出这个消息，本身就是一种策略：告诉市场、告诉开发者、告诉竞争对手——谷歌看到了 Windows 的重要性，而且正在行动。
Copilot 在 8 月 24 日那周已经打出了 WSL 支持的第一张牌。Antigravity 紧随其后。Cursor 和 Devin Desktop 大概率也不会缺席太久。到 2026 年底或 2027 年初，AI IDE 们在 WSL 上的支持深度，可能成为重新划分市场份额的关键变量。
工具链的竞争，终究会回到一个朴素的命题：在开发者实际工作的那台电脑上，你的 Agent 到底能不能好好干活。
当所有 AI 都能写代码的时候，那个让你的 AI 能在 Windows 加 WSL 上平稳运行的公司，才是最后赢家。
快报