摘要

Google 在 I/O 2026 发布 Antigravity 2.0，把它从 AI IDE 推向多智能体工作台。本文介绍核心更新、桌面版和 CLI 的上手方法，以及实际使用时该注意的权限和边界。

tags: Antigravity, AI IDE, 开发工具, AI Agent

---

Antigravity 更新到了2.0 版本，但这次更新有点容易让人困惑。因为 Antigravity 2.0 不是简单地把原来的 AI IDE 换个皮，也不是多塞几个按钮。Google 这次更像是把它从“写代码的编辑器”往外拎了一步，变成一个专门管理 AI agents 的桌面工作台。换句话说，它现在更像一个“任务调度台”。

你可以继续写代码，但它真正想让你做的，是把任务拆出去，让多个 agent 自己读文件、改代码、跑命令、查资料、打开浏览器验证，再把结果用 artifacts 交回来给你看。

有些老用户刚更新时会奇怪：我的 IDE 呢？其实，Antigravity IDE 还在，只是 Antigravity 2.0 已经单独变成了一个桌面应用。以后你可能会同时开着自己熟悉的编辑器和 Antigravity 2.0：一个负责你手上的精细编辑，一个负责让 agent 去跑更长、更杂、更费时间的任务。

更新到2.0后，最重要的变化是什么？

第一，它从“单个仓库里的 AI 助手”变成了“项目级 agent 工作台”。

旧版本里，agent 更像跟着某个 workspace 走。到了 2.0，Google 引入了 Project 的概念。一个 Project 可以绑定一个或多个本地文件夹，比如前端仓库、后端仓库、文档目录都放进去，让 agent 在同一个上下文里处理跨仓库任务。

这个变化很实际。以前你让 AI 改一个功能，它可能只看得到前端，后端接口变了还得你手动补上下文。现在你可以把相关目录一起放进 Project，让它自己在边界内读和改。

第二，它开始认真支持多 agent 并行。

2.0 里的主 agent 可以动态创建 subagents。比如你让它“给这个项目做一次登录模块重构”，它可以把任务拆成几块：一个看前端表单，一个看 API，一个跑测试，一个整理变更说明。主 agent 不必把所有细节都塞进自己的上下文里，整个过程也不会像单线程聊天那样一直卡着。

这听起来像产品宣传，但对日常开发确实有意义。AI 最耗时间的地方，往往不是写那几行代码，而是查上下文、试错、跑验证、多轮修补。能并行之后，体感会不一样。

第三，Scheduled Tasks 出来了。

你可以用 /schedule 给 agent 安排一次性或周期性任务。比如每天早上检查依赖更新，每周跑一次文档链接检查，或者在某个时间让它汇总 issue。它不再只是在你输入一句话之后才动，而是可以按时间触发。

当然，这类功能别一上来就放权太大。自动化越强，越要把权限边界设清楚。

第四，CLI 也来了，而且它会替代一部分 Gemini CLI 的位置。

Antigravity CLI 是给终端用户准备的轻量入口。你不想开桌面应用，只想在项目目录里让 agent 干活，可以直接用 CLI。Google 也已经明确了迁移时间：2026 年 6 月 18 日起，Gemini CLI 和 Gemini Code Assist IDE 扩展将停止为 Google AI Pro、Ultra 以及免费个人用户处理请求。

如果你原来重度使用 Gemini CLI，这个日期最好记一下。不是“有空再看”的那种更新，而是会影响现有工作流。

第五，SDK 开始预览。

Antigravity SDK 是给想把 agent 能力塞进自己系统的人准备的。它是一个 Python 库，可以用 pip install google-antigravity 安装。普通开发者第一天不一定用得上，但如果你想做自己的代码机器人、内部自动化平台，或者把文件读写、命令执行、MCP、skills 这些能力接到一条自定义流程里，SDK 才是更合适的入口。

桌面版怎么上手？

先去 Antigravity 官网下载安装。2.0 支持 macOS、Windows 和 Linux；如果你只想用命令行，也可以直接安装 Antigravity CLI。

第一次打开桌面版，不要急着让它改大项目。建议按这个顺序来：

1. 新建一个 Project。

左侧点“带加号的文件夹”图标，选择 New Project。然后把你希望 agent 访问的目录加进去。一个小项目就加一个仓库；如果是前后端分离项目，可以把前端、后端、接口文档目录一起加进去。

2. 先看权限设置。

默认情况下，agent 可以在项目文件夹范围内读写文件，但运行终端命令会请求你的确认。这个默认值挺合理，别一上来就切到 Full Machine 或 Unrestricted。

最稳妥的做法是：可信项目用默认配置；陌生代码、外部项目、下载下来的 demo，用更严格的设置。

3. 第一个任务别太大。

不要一上来就说：

帮我重构整个项目。

更好的写法是：

先阅读这个项目的登录相关代码，整理登录流程、关键文件和潜在问题，不要修改文件。

这一步很关键。先让 agent 读懂项目，再让它动手。你会少很多“它改得挺快，但方向不对”的情况。

4. 第二步再让它提出计划。

可以继续说：

基于刚才的分析，给我一个最小改动方案。列出要改的文件、原因和风险点，暂时不要执行。

等它交出 implementation plan 或 artifact 后，你再决定要不要放它改。

5. 真正改代码时，优先用 New Worktree Mode。

Antigravity 2.0 支持 Local Mode 和 New Worktree Mode。Local Mode 会直接在当前目录干活，适合小修小补。New Worktree Mode 会给当前任务开一个隔离的 Git worktree，更适合复杂改动和并行任务。

我的建议很简单：能用 worktree 就用 worktree。AI agent 改代码很快，快到你不一定能立刻看清它动了哪里。隔离一下，后面 review 和回滚都会舒服很多。

常用的几个命令，值得先记住

Antigravity 2.0 这次加了几个 slash commands，其中四个很实用。

/goal：适合目标明确、你不想中途反复确认的任务。比如“把这个组件迁移到新的 API，并确保测试通过”。它会尽量跑到任务完成。

/grill-me：我觉得这是最适合新手的命令。你把目标说出来，让它先反问你。比如你想做支付模块，它会先追问边界、异常处理、成功失败状态、测试要求。很多需求问题，在写代码前就能暴露出来。

/schedule：用来创建定时任务。适合例行检查，不适合高风险写操作。比如“每周一检查依赖更新并生成报告”，比“每周一自动升级依赖并提交”安全得多。

/browser：需要 agent 明确使用浏览器时再加。Google 这次把浏览器能力改成显式触发，意思是：你说要用浏览器，它才认真用浏览器。做前端验证、登录流程、表单交互时，这个命令很有用。

还有一个小功能容易被低估：语音输入。

它不是把录音原样扔给模型，而是做实时转写，并且会清理口语里的重复、停顿和自我修正。你脑子里有个模糊需求时，可以先说出来，再让它整理成可执行 prompt。

CLI 怎么用？

如果你更习惯终端，可以装 Antigravity CLI。

macOS 或 Linux：

curl -fsSL https://antigravity.google/cli/install.sh | bash

Windows PowerShell：

irm https://antigravity.google/cli/install.ps1 | iex

装好后，CLI 会优先尝试用系统安全钥匙串里的登录状态。如果没有，会打开浏览器让你登录 Google 账号。远程 SSH 环境下，它会给你一个授权链接，你在本地浏览器打开，拿到授权码后再粘回终端。

CLI 适合三类场景：

第一，远程服务器开发。桌面应用不方便开，终端就够了。

第二，小改动、小排查。比如让它解释报错、定位测试失败、整理某个目录的依赖关系。

第三，键盘流用户。CLI 共享 Antigravity 的核心 agent 能力，但更轻，不需要在 UI 里来回点。

几个命令可以先会：

/config 或 /settings：打开配置。

/permissions：看和调整权限。

/resume：恢复之前的会话。

/rewind 或 /undo：回到前面的对话状态。

@：触发文件路径补全。

!：直接运行终端命令。

如果你以前用 Gemini CLI，还要单独检查迁移。Google 提供了一次性导入路径，可以迁移 Gemini CLI 的 extensions、skills 和 settings。但别默认所有东西都 1:1 可用，尤其是你自己写过脚本、插件或 CI 集成时，最好提前试一遍。

真正好用的 prompt，通常不是一句“帮我完成”

Antigravity 这种 agent 工具，越强越不能瞎放。

一个比较稳的写法是四段式：

目标：我要完成什么。
范围：允许你读写哪些目录，哪些不要碰。
约束：不要改 API、不要引入新依赖、必须保留兼容。
验证：改完后跑哪些测试，交付哪些结果。

比如：

目标：修复用户退出登录后偶尔仍显示头像的问题。
范围：只检查 src/auth、src/components/Header 和相关测试。
约束：不要改后端接口，不要引入新状态管理库。
验证：补一个回归测试，跑相关单测，并用 artifact 说明改动原因。

这种 prompt 不花哨，但有效。

你会发现，AI agent 并不怕任务复杂，它怕的是边界模糊。边界越清楚，它越像同事；边界越模糊，它越像一个很勤快但不太懂你项目规矩的实习生。

我会怎么用它？

如果是我自己的项目，我不会让 Antigravity 一开始就接管主线开发。

我会先把它放在三个位置：

第一个位置：读代码。

让它梳理模块关系、找历史遗留逻辑、总结测试缺口。这类任务不直接改文件，收益高，风险低。

第二个位置：做可隔离的小功能。

比如加一个设置项、补一个数据导出、修一个 UI 状态。范围清楚，验收明确，适合 agent 发挥。

第三个位置：跑重复检查。

用 Scheduled Tasks 做依赖检查、链接检查、文档过期提醒、测试失败汇总。它不一定替你决定，但可以把信息收集好。

我暂时不会把它放在这些地方：

生产数据库操作、密钥配置、大规模删除文件、跨仓库自动提交、没有测试覆盖的核心链路重构。

不是因为它一定做不好，而是这些地方出错的成本太高。agent 工具的正确姿势，不是相信它不会犯错，而是让它犯错时也别炸到主线。

这次更新该怎么看？

Antigravity 2.0 最大的信号，不是“Google 又做了一个 AI IDE”。

更准确地说，Google 在把开发工具从“人围着编辑器转”，推向“人管理一组 agents 干活”。

这一步肯定会有摩擦。有人喜欢原来的 IDE 形态，有人不想迁移 Gemini CLI，有人会觉得多 agent 太重。但方向已经很清楚：AI 编程工具不再满足于补全代码，它开始争夺任务编排的位置。

对普通开发者来说，不必急着把所有工作流都迁过去。

先拿一个不那么危险的项目试一天。建 Project，设权限，让它读代码，出计划，用 worktree 改一个小功能，再看 diff 和测试结果。

如果这个流程跑顺了，你自然会知道它适合放在哪里。

工具升级不重要，工作方式有没有真的变轻，才重要。