Antigravity 的自动模式：难的不是“全自动”，而是“在哪里停下来”

在最近一次 Antigravity 的分享中，有人问了一个很实际的问题：自动模式确实省事，但代理有时会不经确认就动手；可如果每一步都停下来问我，我又成了整个流程的瓶颈。

这个矛盾在用代理写代码时并不罕见。我们的答案不是一个更聪明的“全自动”开关，而是把控制权拆成几层：什么时候问、什么时候停、在哪个界面跑、在什么环境里跑，以及如何把一次对话变成可重复的流程。下面这些能力，有些已经可用，有些还在推进中。

自动模式的关键，是知道什么时候停

先看最直接的一层：提问与审核。

我们最近增加了多选支持，代理可以一次性、动态地提出多个问题。提问界面底部还可以选择你已经设置好的审核政策类型。权限方面，Antigravity 现在支持自动模式，让代理自己判断一条命令是否可以安全运行。在 App 里，默认情况下操作都在沙箱里执行；如果它只是读取自己目录内的文件，不碰网络，就不需要你批准。自动模式能显著减少需要你处理的请求总数。

但“自动”不等于“不再停”。在 CLI 里，你可以用 Shift-Tab 在查看和执行之间切换。/plan 是一个更硬的例子：无论你的权限设置是什么，它都会在执行后给出计划回顾，并特意停下来等你输入。你还可以用规则进一步定制，告诉 Antigravity 哪些事情不要自动执行。权限设置是项目级的全局设置，不是每次对话都要重新交代一遍。

这也是为什么“多选提问”和“审核政策”要放在一起看。它们不是让代理问得更多或更少，而是把人的注意力分配到真正需要判断的节点上。现场有人提出一种设计思路：默认假定系统在自动运行，只在关键处让人介入。我的回应是，团队正在研究如何更好地整合这些要素；目前只有这些选项，但很快会有新方案。这个方向也是我们在探索的——自动化的价值不在于减少点击次数，而在于让人只在值得的地方出现。

我自己的用法偏“Turbo”，但前提是提前准备了很多恢复手段，确保工作能轻松接回来。速度快不等于可以不留后路。

模型选择：默认的 Gemini 够用，Flash 负责“快”

现场有人问我，是否会根据不同的情况换模型。我的回答比较简单：我个人的所有任务都用 Gemini 模型，日常任务用默认档位；只有遇到需要调用多种技能、追求不同效果的任务时，才会切换到其他模式。

Flash 是另一个常用选择。它通常更快，也不需要太多思考。比如我有一个跑健康检查的服务器，Flash 会在那里执行技能和命令，然后把结果展示出来，效果很好。我的体感是，Antigravity 尤其适合日常使用，团队协作时也能覆盖各种类型的任务。

所以模型选择不用过度设计。大多数任务用默认模型就够；需要快、需要轻的时候用 Flash；任务形状变了，再换档位。先把手上的循环跑顺，比反复比较模型更划算。

同一个代理，四种进入方式

Antigravity 并不是四个不同的产品，而是同一个代理从四个入口进来。选哪个，取决于你想介入多深。

App 是主平台，围绕多层次的多智能体监督来设计。它支持并行对话和分屏视图，有各种配置选项来触发对话；左侧边缘是对话栏杆，把鼠标悬停在回合预览上，就能看到不同日期的章节，浏览长对话时很方便。Artifacts 里的 PDF 查看器还允许你选中项目并评论，处理 Markdown 和 HTML 之外的富内容时很实用。网站上列出了完整的键盘快捷键。

CLI 面向的是想把代理放进自己环境的人。它可以用一条 Bash 命令安装，CLI 的更新几乎每天都有；Antigravity 本身也提供 macOS、Windows 和 Linux 的应用版本。CLI 的优点是控制代码在哪里跑：可以装在服务器的虚拟机管理程序上，用远程访问；也可以在无头环境里安全运行。它还有很多 App 里没有的功能，插件和 MCP 的安装管理也很简单。你可以用 agy -p 这类调用向无头 CLI 发提示并接收结果；也能在计划模式、自动执行模式和两者之间的状态之间切换。JSON Schema 支持、打印输出和格式化，都可以在无头模式下用。

IDE 扩展是“深挖某个任务”时的桥。我们宣布支持 Xcode，也覆盖 Zed、Android Studio、VS Code、Visual Studio、JetBrains IDE 和 Eclipse。底层用的是 ACP（Agent Client Protocol），所以同一套对话能力可以进入更多界面。

SDK 则是给想改工作流本身的人。Google Antigravity Python SDK 让你构建自定义流程，SDK 的代码在 GitHub 上开源。你可以完全替换模型调用的方式：Gemma 团队就用 Antigravity SDK 跑起了 Gemma 27B，完全离线、免费。它也支持 OpenAI 兼容的端点，你可以接自己偏好的本地模型，不管它跑在本地还是远程。我们在博客文章里还讨论了混合工作流：敏感数据留在设备上处理，指定部分交给 SDK 运行，再从 Antigravity 取回结果。SDK 是声明式的，上下文怎么设置、作用域怎么限定，都由你控制；内置工具、模型类型、子代理的访问权限和运行环境也都可以指定。对想把代理接进 CI/CD 流水线的人来说，这是一条更直接的路。沙箱方面，我们也不想每次启动一台慢吞吞的虚拟机或 Docker 容器，而是为 macOS 和 Windows 提供了专门的沙盒方案。

远程控制把这件事又往前推了一步。我个人已经把大约 80% 的工作流转到远程控制上；在谷歌内部，我估计 90% 的员工在用 Antigravity 的网页版。CLI 和 App 各有自己的远程控制版本，它们会共存于同一处。

自动化的底座：沙箱与权限

自动模式能不能放心用，最终取决于它跑在什么环境里。

在 App 里，默认所有操作都在沙箱中运行。CLI 也支持沙箱，但默认没有开启，需要你在设置里启用。我们为 macOS 和 Windows 都做了沙箱方案：Windows 上使用最新的 WSL API，并与微软合作确保行为正确；macOS 上还有一个容器系统，可以在受控环境中运行你不信任的命令。这些模式的目标，就是让你不必担心它擅自执行命令或删掉系统上的项目。出站网络默认全部禁用，每次都需要你明确允许，或者把它加进允许列表。

沙箱之外还有权限系统。你可以具体规定哪些工具可以读取、设置或允许访问；这套规则既适用于自定义子代理，也适用于系统本身，CLI 里也有对应的设置方法。我们还加了 Vim 模式，照顾真正喜欢 Vim 的开发者。CLI 团队也在努力缩小它和 App 之间的体验差距，遇到问题可以直接找他们。

这里有一个容易被忽略的取舍：App 把安全做成默认值，CLI 则把开关交给你。前者适合“我只想监督代理”的场景，后者适合“我知道自己在做什么、但需要完全控制运行位置”的场景。两者不是谁更安全，而是默认值不同。

工程循环：把一次对话变成一套流程

当代理可以连续跑很久之后，真正的杠杆就从“写更好的提示词”转向“设计更好的循环”。

Antigravity 里已经有一组围绕循环的命令。/grill-me 用来把需求问透，/plan 用来产出实施计划，两者都会生成可审阅的工件。生成式 UI 则提供了用 HTML 和动态工件构建复杂界面的方式。浏览器子代理从早期版本就有，可以控制 Chrome MCP；我们最近还加入了内置浏览器支持，把这类操作收进同一个地方。CLI 里可以用 /artifact 找工件，App 里则在侧面板查看。每次完成后，系统会生成操作步骤，方便你验证它到底做了什么。

UI 共享是另一个有意思的方向。它让你把每天使用的数据，用更直观、更可互动的方式呈现出来。我个人很喜欢探索可视化图表，这对非开发人员尤其有用：比如看财务信息时，可以直接在产品内部生成一个仪表盘，完全离线，作为侧边栏里的一个元素运行。我也看到团队用 Apps Script 这类技术做出了很酷的用例。如果你还没试过，我建议在动手构建其他东西之前，先用它做一个可视化原型。

视觉效果在应用开发中很容易被忽略。我们的 Chrome MCP 子代理和内置浏览器子代理可以抓取生成内容的视频和图像，再借助 Gemini 模型的视觉理解能力去改进设计。如果你想把设计再往前推一步，可以看看 Google Labs 的 Stitch：它提供一键式 MCP 支持，你可以用 Antigravity 委托它生成专门针对你应用的设计。在黑客松这类场景里尤其好用。

版本控制和终端也在同一个循环里。Antigravity 内置了原生 Git 功能，适合想完全掌控提交信息、精确指定提交内容的用户。终端在远程控制类任务里尤其有用，因为你可以在安装了软件的远程设备上直接跑命令。

多代理协作的痛点则在上下文。我们目前最好的做法之一，是给每种类型的对话使用独立的 Git 工作树；它们放在 .gemini 文件夹里，由 Antigravity 管理，删除对话时也会被彻底清除。我们还在开发更高级的协调能力，让子代理不必每次都启动整个代码库的副本。

再往外一层，是 Boost、Teamwork 这类命令，用来实现真正的并行化；/learn 则适合在一段效果不错的对话之后停下来复盘，更新、删除或重新配置技能和规则。日程安排和自动化则让代理按类似 cron 的方式运行：你不必一直盯着，只要让自动化程序发起对话，再触发你设置好的自定义流程。我自己的习惯是，在工作开始时让它看邮件、日历和事件，找出阻塞点或需要跟进的人——这样一上来就有可以查看和行动的内容。

回到开头那个问题：自动模式到底该不该放手？我的看法是，问题不在于“放手”还是“不放手”，而在于你有没有为它设计好停下来的地方。权限、计划、沙箱、工作树、斜杠命令，这些看起来是分散的功能，其实都在回答同一个问题：当代理跑得越来越久，人应该在哪些节点介入，才能既不被琐事淹没，也不把判断权交出去。