Jules退场，谷歌押注新IDE

谷歌开始收拢两条 AI 编程产品线

谷歌正在逐步停用 AI 编程助手 Jules，并把这款产品积累的异步编程 Agent 经验转移到 Antigravity。根据 Jules 官方账号发布、由IT之家报道的声明，谷歌接下来将把研发重心放在统一体验上，让 Antigravity 同时具备远程后台执行能力和以智能体为核心的开发环境。

Jules 是谷歌面向 GitHub 仓库推出的异步编程 Agent，开发者提交任务后，它会在远程云环境中克隆代码、制定计划、修改文件并返回结果。它于 2024 年 12 月推出，最初的定位很直接：处理那些开发者不想亲自完成、但又必须完成的工作，例如修复缺陷、升级依赖、补充测试和实现边界清晰的小功能。

这次调整意味着 Jules 在推出约 22 个月后进入退场流程。谷歌目前使用的是“逐步停止运营”这一表述，尚未在公开声明中给出最终关闭日期、历史任务导出方式、订阅权益变化以及自动化任务迁移方案，因此现阶段更准确的说法是“进入停服周期”，而不是服务已经立即关闭。

Antigravity 是谷歌 DeepMind 推出的智能体优先开发平台，也是一个基于 VS Code 分支构建、可独立下载的 IDE。该平台于 2025 年 11 月 18 日推出，支持 Windows、macOS 和 Linux，核心目标是让 AI Agent 在开发环境内自主完成规划、执行、验证和迭代，而不只是根据当前文件补全下一段代码。

Jules 没有失败，它只是变成了一块能力模块

Jules 的退场更像产品形态被吸收，而不是谷歌否定异步编程 Agent 的价值。谷歌在声明中明确表示，Jules 是一项用于理解异步 Agent 如何帮助开发者更快交付的实验，其经验已经影响谷歌旗下多个产品，并将直接进入 Antigravity。

异步编程 Agent 是一种无需开发者持续盯着交互窗口、可以在独立环境中长时间执行软件工程任务的 AI 系统。它与聊天式编程助手的区别，类似“把问题问给同事”和“把工单完整交给同事”：前者通常给出建议或代码片段，后者需要读取仓库、理解约束、修改多个文件、运行测试，并把执行证据交回来。

Jules 的典型工作流正是这种“工单式协作”。开发者选择 GitHub 仓库和分支，描述目标，Jules 在云端虚拟机中拉取项目并生成计划；计划确认后，它再执行修改。公开产品页面曾显示，其基础方案提供每天 15 个任务和 3 个并发任务，不同方案对应的模型权限并不完全相同，页面一度同时出现 Gemini 2.5 Pro 与 Gemini 3 Pro 相关说明。

Jules 的真正价值并不是它能写多少行代码，而是它把开发者从等待 Agent 输出的过程里释放出来。版本升级、测试补齐和结构明确的缺陷修复往往要消耗几十分钟甚至数小时，但并不要求开发者一直参与；如果 Agent 能在隔离环境中完成工作并提交可审查结果，人类就可以把注意力放在架构判断、需求澄清和代码评审上。

Jules 的产品局限也同样明显。它以 GitHub 仓库和远程任务为中心，适合边界明确、输入完整的工作，却不天然掌握开发者本地正在调试的状态、尚未提交的改动、终端上下文以及临时环境变量。开发者在 IDE 中写代码时是一条连续工作流，而把任务切到另一个网页或远程任务面板，本身就会产生上下文切换成本。

Antigravity 要解决的是“两个工作台”的问题

谷歌将 Jules 并入 Antigravity，首先是在解决交互式开发与异步委派割裂的问题。此前，开发者可能在 IDE 中使用一个助手完成即时修改，再打开 Jules 分配后台任务；两个 Agent 所看到的上下文、权限和任务记录并不一致，团队还要额外判断工作应该交给哪一边。

Antigravity 的方向是把前台协作和后台执行放进同一个智能体工作台。开发者可以在 IDE 内与 Agent 一起定位问题，也可以把依赖升级、批量补测试或跨模块重构交给远程环境继续运行；任务结束后，Agent 再把修改、测试结果和验证过程带回开发环境。

两款产品的差异可以概括如下：

| 对比维度 | Jules | Antigravity | |---|---|---| | 产品定义 | 面向 GitHub 仓库的异步编程 Agent | 智能体优先的独立开发环境 | | 推出时间 | 2024 年 12 月 | 2025 年 11 月 18 日 | | 当前状态 | 已宣布逐步停止运营 | 谷歌后续投入重点 | | 主要入口 | 网页、GitHub 仓库与任务 | Windows、macOS、Linux 桌面 IDE | | 执行环境 | 以远程云端虚拟机为核心 | IDE 交互环境与自主 Agent 工作流结合 | | 适合任务 | 修复缺陷、升级版本、编写测试、开发独立功能 | 从问题分析到执行、验证和迭代的复杂工程任务 | | 协作节奏 | 提交任务后离开，完成后回来审查 | 既可实时协作，也可委派后台任务 | | 上下文优势 | 已提交到仓库的代码和任务描述 | 编辑器、文件、终端、项目规则与任务历史 | | 主要风险 | 与本地开发流程割裂 | 权限、资源配额和长任务可靠性更复杂 |

这张表也解释了谷歌为什么没有继续把 Jules 做成一个平行产品。只要 Antigravity 能接住远程执行能力，单独维护 Jules 就会造成重复的任务系统、权限体系、模型调度和计费设计；对开发者来说，两套产品也意味着两份上下文和两种操作习惯。

真正难点不是写代码，而是证明代码写对了

Antigravity 能否接住 Jules，关键不在于模型能不能生成补丁，而在于长任务能否稳定完成闭环。一个 Agent 修改 20 个文件并不困难，困难的是它能否识别测试失败原因、处理依赖冲突、发现修改影响的下游模块，并在多次尝试后避免偏离原始需求。

自主验证是智能体 IDE 与传统代码助手之间最重要的分界线。传统助手通常把代码交给开发者后就结束任务，智能体则需要运行测试、读取日志、检查构建结果，并根据失败信息再次修改；只有形成“计划—执行—验证—迭代”的循环，Agent 才接近一名可委派工作的工程协作者。

Jules 为谷歌提供的核心经验很可能集中在四个方面：

1. 远程环境的可复现性。 Agent 必须知道如何安装依赖、选择运行时并处理项目初始化失败，否则任务会在写代码之前就终止。
2. 长任务的状态管理。 一个持续数十分钟的任务需要保存计划、执行记录和失败现场，模型切换或进程重启不能让它从头猜测。
3. 并发任务的隔离。 多个 Agent 同时处理同一仓库时，需要避免分支、文件和依赖状态相互污染。
4. 可审查的执行证据。 开发者需要看到修改了什么、运行了哪些命令、哪些测试通过，以及哪些风险仍未解决。

这些能力比换上一个更强的 Gemini 模型更难复制。基础模型决定 Agent 的代码理解和推理上限，任务编排、沙箱、权限控制、测试反馈和失败恢复则决定它能不能在真实仓库里稳定交付；后者通常需要大量产品运行数据，而 Jules 的近两年实验恰好提供了这部分经验。

统一产品并不等于体验会自动变好

谷歌的整合方向合理，但 Antigravity 仍要面对资源配额、任务锁定和环境稳定性问题。2026 年间，谷歌开发者社区已经出现过关于 Antigravity 配额限制、IDE 锁定和使用中断的反馈，官方社区人员也曾表示已将相关意见提交内部团队审查。

资源配额会直接决定异步 Agent 是生产力工具还是演示功能。开发者可以接受聊天助手偶尔达到消息上限，却很难接受一个运行了半小时、已经修改多个模块的后台任务在验证阶段突然耗尽额度；如果系统不能暂停、续跑和保留完整状态，长任务带来的时间收益会被返工抵消。

IDE 形态也让 Antigravity 承担了比 Jules 更大的安全责任。Jules 主要在隔离的远程环境中工作，而 IDE 内的 Agent 可能接触本地文件、终端、云端项目和开发凭据；权限如果太弱，Agent 无法完成任务，权限如果太宽，一次错误判断就可能执行破坏性命令。

谷歌因此需要把权限设计成分层而不是简单开关。低风险操作可以自动执行，安装依赖、修改大量文件和访问网络应记录过程，删除资源、触发部署或接触生产环境则应要求明确确认。对于企业团队，审计日志、策略模板和项目级权限边界的重要性不会低于模型跑分。

AI 编程竞争正在从模型窗口转向任务系统

Jules 停服反映了 AI 编程市场的一次产品收敛：单独的网页 Agent 正在让位于具备完整任务系统的开发环境。开发者最终需要的并不是更多聊天框，而是一个能理解代码库、调用工具、管理多个任务并提交可验证结果的协作层。

这一变化也让模型能力不再是唯一竞争指标。不同厂商的顶级模型都能完成常见代码生成，但真实体验会被仓库索引速度、上下文保持、终端控制、失败恢复、并发隔离和代码审查质量拉开差距。模型像发动机，Agent 平台则是变速箱、底盘和制动系统；只有发动机参数漂亮，并不能保证整辆车适合日常使用。

谷歌的优势是可以把 Gemini、GitHub 工作流、云端沙箱、开发工具和 Google Cloud 服务放进同一条链路。Antigravity 的官方教程已经开始展示通过 agents.md 和 skills.md 描述 Agent 规则与可复用技能，并可结合远程 Jupyter 内核、BigQuery 和分布式数据处理环境完成更复杂的开发任务。

谷歌的风险则是产品线整合速度能否跟上停服节奏。如果 Jules 在 Antigravity 补齐远程任务、GitHub 分配和自动化能力之前退出，原有用户会经历明显的功能空档；如果迁移没有保留任务历史、仓库配置和自动化规则，所谓“统一体验”就只是要求用户重新搭建工作流。

Jules 用户现在应该做什么

Jules 用户不必立刻停止现有任务，但应该开始降低对其专属工作流的依赖。谷歌尚未公布明确的最终关闭日期，这意味着团队仍有时间整理任务资产，不过不适合再把新的关键自动化流程只绑定在 Jules 上。

开发者现阶段可以优先完成以下准备：

• 保存任务模板。 整理常用提示、验收标准、测试命令和仓库约束，避免它们只存在于 Jules 历史会话中。
• 检查自动化入口。 盘点通过 GitHub Issue 标签或其他方式分配给 Jules 的任务，确认停服后不会出现无人处理的队列。
• 记录环境配置。 把运行时版本、依赖安装步骤和必要服务写入仓库文档或 Agent 规则文件，减少迁移对隐式上下文的依赖。
• 提前测试 Antigravity。 优先用低风险仓库验证其远程任务、终端操作、测试执行和权限确认是否符合团队要求。
• 保留人工审查。 无论使用 Jules 还是 Antigravity，合并前都应检查差异、测试结果和依赖变更，不能把 Agent 的“任务完成”直接等同于代码可上线。

Jules 的退场不是异步 Agent 路线的终点，而是谷歌承认独立 Agent 与 IDE 不应继续割裂。对谷歌而言，最理想的结果是把 Jules 的“你去忙，我来做”与 Antigravity 的“我们在同一工作台协作”结合起来；对开发者而言，真正值得关注的也不是产品名称，而是任务能否迁移、过程能否审计、失败能否恢复，以及结果能否被验证。

结论

谷歌停用 Jules 是一次产品整合，而不是一次技术撤退。Jules 已经完成了验证异步编程 Agent 的实验任务，Antigravity 则要把这些能力变成日常开发环境的一部分。

这次整合的方向值得肯定，但结果仍取决于执行细节。只有当 Antigravity 能稳定承接远程后台任务、并发执行、GitHub 工作流和可验证交付，同时解决配额与权限问题，Jules 的退场才会成为一次无感升级；否则，谷歌只是关闭了一款定位清楚的工具，换来一个野心更大、但尚未完全磨合的 IDE。

参考来源

• IT之家：推出不到两年，谷歌 AI 编程助手 Jules 将逐步停止服务——整理了 Jules 官方停服声明，以及相关能力将并入 Antigravity 的信息。