Antigravity 自动审批与全自动模式：怎么不再被反复询问

Antigravity 自动模式与自动同意：快速答案

Antigravity 的智能体在编辑文件、运行命令、调用 MCP 工具或打开 URL 之前都会先询问。这是安全的默认行为，但长任务会因此变慢。Google 现在已经提供了原生方式来减少提示，大多数人不再需要任何变通办法。本指南把 App/IDE 设置和 CLI 设置分开讲清楚，解释提示为什么有时还会出现，并说明自动执行到底可能对你的机器做什么。

Antigravity 怎么开启自动同意（App 和 IDE）

当前版本的 Antigravity 使用权限预设（permission preset）来控制终端命令、文件访问、MCP 工具和网页读取如何获得批准。根据 Google 的 Agent settings 和 Permissions 文档，共有四种预设：

步骤：开启 Auto (Preview) 或 Turbo

1. 把 Antigravity 更新到 v2.23.0 或更高版本。商业版和企业版账号不提供 Auto (Preview)。
2. 打开 Settings → General → Global Permissions → Permission Preset，选择 Auto (Preview) 或 Turbo。当前预设旁会显示对勾。
3. 也可以使用消息输入框里的权限选择器（v2.23.0+）。它会修改全局预设；如果该项目有自己的覆盖设置，则修改项目预设。
4. 只想对单个项目生效时，进入 Settings → Projects 设置该项目的预设。新项目默认是 Inherit Global。选择 Use Global Settings 可以移除覆盖。
5. 为智能体绝不能做的事添加 deny 规则（见 Allow 与 Deny 规则）。

注意，Auto 预设只改变终端命令和工作区文件的处理方式。MCP 工具和网络访问仍然是 Ask。如果想让它们也不再提示，请添加 mcp(server/*) 或 read_url(domain) 的 allow 规则，而不是切换到 Turbo。

计划与产物（Artifact）

计划审阅是单独的设置。自 v2.17.0 起，控制计划审阅的 Agent 设置叫做 Plan Review Policy，Google 的更新日志说明它可以设为审阅每个计划、仅在智能体认为有必要时审阅，或完全跳过审阅。权限预设不会改变它。

旧版 IDE 设置：Terminal Command Auto Execution 与 Artifact Review

Google 的 Antigravity IDE 文档仍然描述了更早的策略式设置，Agent settings 页面把它们列为"之前的权限设置"。在较旧或受管理的安装上你可能还会看到：

• Terminal command auto execution：Request Review 在执行终端命令前始终询问，Allow 列表中的命令除外。Always Proceed 自动运行命令，Deny 列表中的命令除外。Google 把它标注为"高自主性，高风险"。Agent settings 页面还列出一个中间选项 Proceed in Sandbox：命令在终端沙盒内无需提示即可运行，沙盒外的仍需审阅。
• Artifact review：Request Review（推荐）会在计划和 diff 处暂停等你批准。Always Proceed 永不为人工审阅而暂停。
• Agent non-workspace file access：默认关闭。否则智能体只能看到你的项目文件夹和它自己的应用数据目录。
• Strict mode：强制终端执行、浏览器 JavaScript 和 artifact review 都使用 Request Review，并忽略终端 allowlist。如果你的 allowlist 看起来没有作用，请关闭 Strict mode。

IDE 扩展还有 antigravity.autoAcceptOnChat，自 v1.6.0 扩展版本起默认开启。你发送新的聊天消息时，它会自动接受后台文件中待处理的内联 diff，并保持当前活动文件的 diff 打开等你审阅。自 v1.9.0 起，可以用 Alt+Enter / Alt+Shift+Enter（macOS 为 Option+Enter / Option+Shift+Enter）接受或拒绝当前聚焦的内联 diff 片段。

Antigravity CLI 自动模式：怎么用 agy --mode=auto

CLI 有四种执行模式。根据 Google 的 "Choose an execution mode" 页面：

步骤：开启 agy 自动模式

1. 更新 CLI。自动模式在 macOS 和 Linux 上需要 v1.3.5+，Windows 上需要 v1.4.4+，并且依赖终端沙盒。
2. 直接以自动模式启动：

   agy --mode=auto

3. 或者在会话中切换：按 Shift+Tab 依次切换 default > accept-edits > auto > plan。如果 auto 不可用，切换会从 accept-edits 直接跳到 plan。
4. 想永久生效，运行 /config，选中 Agent Mode 并选 auto。或者直接编辑 ~/.gemini/antigravity-cli/settings.json：

   {
       "agentMode": "auto"
   }

5. 确认生效：右下角状态栏显示 auto，输入框提示为 Auto mode: edits & safe commands auto-approved (shift+tab to cycle)。

自动模式的要求与限制

• 必须有沙盒。在 Windows 上，这意味着 Windows 11 24H2 或更高版本并安装 2026 年 8 月或更新的更新。如果沙盒不可用（Windows 10、较旧的 Windows 11 版本，或阻止非特权用户命名空间的 Linux 主机和容器），则不提供自动模式，CLI 会以 default 启动。
• 无头模式：auto 可用时，agy -p "..." --mode=auto 可以正常工作。不可用时，CLI 会打印警告并继续以 default 模式运行。
• 覆盖关系：明确的 allow、ask、deny 规则，strict 工具权限以及 --dangerously-skip-permissions 的优先级都高于模式。
• 子智能体会继承该设置，所以它们的文件写入不会排队等待批准。

怎么让 Antigravity 允许运行所有命令（agy 自动批准）

如果你想完全没有提示，CLI 提供两个开关，二者都对应 always-proceed 工具权限：

1. 单次运行：

   agy --dangerously-skip-permissions

2. 持久设置：运行 /config，把 Tool Permission 设为 always-proceed，或在 ~/.gemini/antigravity-cli/settings.json 里设置 "toolPermission": "always-proceed"。

Google 的设置参考把 always-proceed 描述为无需提示即可运行终端命令、网络请求和 MCP 工具，但匹配 ask 或 deny 规则的操作除外，并标注为风险最高。它会覆盖自动模式。在 GitHub 上一个关于自动模式的功能请求里（自动模式发布之前），Google 维护者给出了同样的 /config 修改建议；提问者反馈仍会偶尔弹窗，这只是社区反馈，并未被确认为 bug。

自 CLI v1.3.2 起，--dangerously-skip-permissions 不再自动批准 /plan 模式下的实施计划，它只跳过工具权限提示。如果你想让计划也自动通过，请在 /config 中把 Artifact Review 设为 always-proceed。

对于脚本和 CI，无头模式使用 -p 加同样的参数，还支持 --sandbox 以终端沙盒限制运行：

# 自动模式可用时，无人值守运行的首选
agy -p "Fix the failing unit tests" --mode=auto --output-format json

# 仅限一次性环境使用的全部放行
agy -p "Refactor the utils folder" --dangerously-skip-permissions --sandbox

同一份无头模式指南提到，在非交互环境中，尚未认证的运行会以 authentication required 错误退出。请先用交互式 agy 会话登录。如果流水线中的命令失败，请参阅 agy CLI 错误与排查（英文）。

Antigravity 为什么还在要权限

开启自动模式或 Turbo 后仍然弹窗，请按顺序检查：

1. 有 ask 或 deny 规则匹配。规则按 Deny > Ask > Allow 的顺序求值，始终优先于预设或模式。Ask 里放一个宽泛的 command(*)，即使 Allow 里有 command(git)，每条命令也都会提示。
2. 操作属于 MCP 或网络。Auto 预设让 MCP 和网络操作保持 Ask。请为你信任的服务器和域名添加 mcp(...) 或 read_url(...) 的 allow 规则。
3. 命令有风险或不可逆。自动模式对这类命令会按设计暂停。
4. 开启了 strict 工具权限或 Strict mode。CLI 的 strict 会覆盖自动模式；IDE 的 Strict mode 强制使用 Request Review 并忽略终端 allowlist。
5. 命令包含隐藏的 shell 结构。命令或进程替换（$(...)、反引号）、花括号展开、有风险的重定向，或会运行子命令的参数，都会禁用前缀匹配。此时只有当某条规则整行精确匹配时，命令才无需提示即可运行。例如允许了 command(git) 后，git status && git log 能运行，但 git log $(whoami) 会提示。
6. 文件在工作区之外。非工作区访问默认关闭。
7. 沙盒不可用。不提供自动模式，并且从 CLI v1.4.4 起，proceed-in-sandbox 的行为与 request-review 相同。
8. 账号类型。商业版或企业版账号不提供 Auto (Preview)。
9. 版本过旧。请更新。自动模式在 CLI v1.3.5 引入，App 预设在 v2.23.0 引入。

如果以上都不能解释，可能是智能体卡住了而不是在询问。请参阅 Antigravity 无响应修复。

Antigravity 权限：Allow 与 Deny 规则

每个敏感操作都是一个写成 action(target) 的权限资源。根据 Google 的 Permissions 文档，支持的 action 有：read_file、write_file、read_url、execute_url、command 和 mcp。优先级为 Deny > Ask > Allow，Google 明确说明 deny 规则在任何模式下都会拦截对应操作。

• command(git) 按完整单词或 token 前缀匹配。command(regex:npm run (build|lint|test)) 按正则表达式匹配。
• write_file 隐含同一路径的 read_file。拒绝某路径的 read_file 也会拒绝该路径的 write_file。
• read_url(domain) 同时也会成为终端沙盒出站网络 allowlist 的一部分，所以 curl 和 npm 只能访问你授权过的主机。
• 在 CLI 中，用 /permissions 或编辑 ~/.gemini/antigravity-cli/settings.json 来修改规则。在 App 中，使用 Global Permissions 或项目的权限设置。你还可以在权限提示卡片上编辑目标，把一次性授权放宽（终端命令不支持）。

改编自 Google 文档的 CLI 规则示例：

{
    "permissions": {
        "allow": [
            "command(git)",
            "command(regex:npm run (build|lint|test))",
            "write_file(src/)",
            "mcp(linter/*)"
        ],
        "deny": [
            "command(rm -rf)",
            "command(regex:curl .*)",
            "command(sudo)",
            "write_file(.git/)",
            "write_file(/home/user/.ssh)"
        ],
        "ask": ["command(*)", "mcp(sql/execute_mutation)"]
    }
}

注意：这个示例里 Ask 中的 command(*) 会按优先级规则覆盖 command(git) 的 allow 规则。如果你希望 allow 规则生效，请对具体的高风险前缀使用 ask，不要对 * 使用。

安全：Antigravity 自动执行能做什么

自动批准不会让智能体变聪明，它只是去掉了你本来可以发现错误的那次暂停。具体后果取决于设置：

在任何模式下都管用的做法：长任务前先提交代码，在分支或 worktree 上工作，添加上面的 deny 规则，把密钥放在工作区之外，无人值守的任务放到一次性虚拟机或容器里跑。更完整的清单请看 防止危险命令与保护文件。

关于忽略文件：Google 的 IDE 文档说明 Strict mode 会遵循 .gitignore。CLI 更新日志在一处路径补全修复中提到了 .antigravityignore，但文档并没有把它作为安全边界。要保护密钥，请使用 read_file(.env) 这样的 deny 规则，不要依赖忽略文件。（因此我们删除了之前的 .antigravityignore 模板；另见 智能体加载指南。）

Ralph Loop、SuperSmooth 等自动同意扩展：还需要吗？

在审批方面通常不需要。这些项目早于原生预设和 CLI 模式出现。下面的内容均来自各项目自己的 README，属于社区自述，不是 Google 的指引，也没有经过 Google 审核。

本指南的早期版本列出过 ralphLoop.autoRunCommands、superSmooth.autoProceed 之类的设置键。我们在当前各项目的 README 中找不到它们，所以已经删除。如果你已经安装了某个扩展，请先查看它当前的 README，不要轻信旧配置。

推荐配置：自动模式加 Deny 列表

这是我们日常工作会使用的配置。它能去掉大部分提示，同时保留硬性拦截。

1. 先提交或建分支。干净的 git 状态能让一次糟糕的运行变成一次 git restore . 或丢弃一个分支。
2. 选 auto，不选 Turbo。App：Permission Preset → Auto (Preview)。CLI：agy --mode=auto。
3. 添加 deny 规则，覆盖破坏性命令和敏感路径（command(rm -rf)、command(sudo)、command(regex:curl .*)、write_file(.git/)、read_file(.env)，以及 SSH 和云凭据目录）。
4. 放行已知安全的命令，用前缀如 command(git) 和 command(regex:npm run (build|lint|test))。
5. 保持非工作区访问关闭，并让 MCP 和网络保持 Ask，直到你信任某个具体的服务器或域名。
6. 用自然语言补充规则：权限引擎无法表达的约定，可以写到规则文件里。请看 自定义规则 和 工作流。规则只是给模型的指引，不是强制执行，所以硬性拦截仍要靠 deny 规则。
7. 合并前检查 diff。自动批准不等于正确。

2026 年的变化（以及本指南替换了什么）

• 2026 年 9 月 22 日，App v2.17.0：Artifact review 改为 Plan Review Policy（审阅每个计划、有必要时审阅，或跳过）。
• 2026 年 9 月 29 日，IDE 扩展 v1.6.0：新增 antigravity.autoAcceptOnChat。
• 2026 年 10 月 12 日，App v2.23.0：消息输入框新增权限选择器。文档列出 Auto (Preview) 从此版本起可用。
• 2026 年 10 月 14 日，CLI v1.3.5：在 Linux 和 macOS 上新增自动模式（--mode auto、/config 的 Agent Mode、Shift+Tab）。
• 2026 年 10 月 15 日，CLI v1.3.6：自动模式沙盒逃逸审查更快，不再因超时而无结论。
• CLI v1.4.4：在沙盒可用的 Windows 上支持自动模式。
• 2026 年 10 月 19 日，IDE 扩展 v1.9.0：新增接受或拒绝当前聚焦内联 diff 片段的键盘快捷键。

本指南之前的版本称 Google 没有官方的自动驾驶功能，并描述了 Off、Auto、Turbo 三档的 "Terminal Execution Policy"。这些内容已经过时。Google 现在在 App 中记录的是权限预设（Request Review、Default、Auto、Turbo），在 CLI 中记录的是执行模式。我们还删除了早期版本中没有来源的统计数字和使用情况说法。

早期指南（2026 年 3 月）

审批难题：为什么开发者需要自动接受

每当 Antigravity 的智能体想要执行操作时（无论是写入文件、运行终端命令、调用 MCP 工具还是浏览 URL），它都会暂停并请求你的批准。这是一种刻意的安全措施：它保持了人工参与，防止智能体在没有监管的情况下执行潜在的破坏性操作。

问题在于，对于常规、低风险的工作流，不断的干扰会破坏生产力。考虑一个典型场景：你要求智能体为一个新功能搭建脚手架，包括数据库迁移、API 路由、前端组件和单元测试。智能体需要：

• 创建 6–8 个新文件（每个都需要批准）
• 运行 npm install 以安装新依赖（需批准）
• 执行数据库迁移命令（需批准）
• 运行测试套件进行验证（需批准）
• 修复任何失败的测试并重新运行（每次编辑和每个命令都需要批准）

仅仅一个功能就需要 15–20 次手动批准。将其乘以一整个工作日，据开发者反馈，每个会话点击 "Accept" 或 "Run" 的次数多达 200 次以上。一些社区成员报告说，在正确配置环境后，可以让 Antigravity 运行数小时而无需干预一次。

内置的 "Always Run" 设置（以及为什么它有时会失效）

Antigravity 确实包含一个用于自动批准某些操作的内置机制。2026 年 3 月它被称为 终端执行策略，位于 Settings → Antigravity → Terminal Execution Policy，共有三种模式：

• "Off"（仅限允许列表）：智能体在没有明确批准的情况下不能执行任何命令。最安全，但最慢。
• "Auto"（默认）：智能体使用内部安全分类器来决定哪些命令是“安全”的，可以在不询问的情况下运行。诸如 ls、cat 和 npm test 之类的命令会自动执行；而诸如 rm -rf 或 chmod 仍需批准。
• "Turbo"（仅黑名单模式）：智能体会执行除明确屏蔽的命令之外的所有操作。速度最快，但也最危险。

为什么 "Auto" 模式感觉不像自动驾驶：即使在 Auto 模式下，智能体在进行文件编辑、MCP 工具调用和浏览器操作时仍会暂停。终端命令只是需要批准的其中一类，文件写入和工具调用受独立设置的管控。此外，内部安全分类器相当保守：npx prisma migrate dev、docker compose up，甚至 git commit 都常被标记为需要手动批准，因为它们会修改状态。

Ralph Loop: The Community's Go-To Auto-Accept Extension

2026 年 3 月，Ralph Loop 被描述为一个社区开发的 Antigravity 扩展：每当智能体暂停等待确认时，它会以编程方式点击 "Accept" 和 "Run" 按钮，从而自动完成审批流程。它的出现，是因为开发者发现仅靠内置设置无法实现真正的脱手操作。

What Ralph Loop Does

• 自动接受文件编辑：当智能体给出 diff 时，Ralph Loop 会自动点击 "Accept"。
• 自动运行终端命令：当智能体请求执行命令的权限时，它会点击 "Run"。
• 自动放行工具调用：MCP 工具调用和浏览器操作无需手动干预即可获批。
• 可配置延迟：你可以设置审批提示出现到自动点击之间的延迟（毫秒），给自己留出手动取消的时间窗口。

社区成员报告称，他们用 Ralph Loop 免手动生成了长达 350 页的文档站点，让 Antigravity 连续运行数小时（社区自述（2026 年 3 月），未经独立验证）。

Installation

# Install via the Antigravity Extension Marketplace
# Search for "Ralph Loop" in the Extensions panel
# 或者通过命令面板安装：
Ctrl+Shift+P > "Extensions: Install Extension" > 搜索 "Ralph Loop"

配置

2026 年 3 月的指南称，安装完成后打开 设置 → 扩展 → Ralph Loop 并进行如下配置。这些设置键属于 社区自述（2026 年 3 月），在当前 README 中未找到：

{
  "ralphLoop.enabled": true,
  "ralphLoop.autoAcceptEdits": true,
  "ralphLoop.autoRunCommands": true,
  "ralphLoop.autoApproveTools": true,
  "ralphLoop.delayMs": 1500,
  "ralphLoop.excludeCommands": [
    "rm -rf",
    "DROP",
    "git push --force",
    "chmod -R 777"
  ]
}

SuperSmooth：修复自动继续和自动滚动

SuperSmooth 被描述为一个配套扩展，用于解决另一个相关问题：即使你通过内置设置或 Ralph Loop 启用了自动接受，Antigravity UI 也经常 无法滚动 到最新输出，并且 不会自动继续 执行多步任务中的下一步。

SuperSmooth 修复的问题

• 自动继续：当智能体完成一个步骤且 UI 显示 "Proceed" 或 "Continue" 按钮时，SuperSmooth 会自动点击它。没有这个功能，即使启用了自动接受，智能体也会在步骤之间暂停。
• 自动滚动：保持聊天输出滚动到底部，以便你监控进度。在执行长时间操作时，Antigravity 的原生滚动行为经常会在对话中间卡住。
• "Always Proceed" 问题修复：Antigravity 的多个版本存在一个 Bug，即设置面板中的 "Always Proceed" 开关无法在不同会话之间持久保存。据称 SuperSmooth 通过拦截 UI 状态并强制执行继续行为来修复此问题。

# 安装 SuperSmooth
Ctrl+Shift+P > "Extensions: Install Extension" > 搜索 "SuperSmooth"

# 配置 (settings.json)，社区自述（2026 年 3 月）
{
  "superSmooth.autoProceed": true,
  "superSmooth.autoScroll": true,
  "superSmooth.fixAlwaysProceed": true
}

2026 年 3 月的说法是，SuperSmooth 与 Ralph Loop 配合良好：Ralph Loop 处理 "接受/运行" 审批，而 SuperSmooth 处理 "继续/下一步" 的转换和滚动行为。

其他社区自动接受扩展

除了 Ralph Loop 和 SuperSmooth，还有几个其他社区扩展尝试解决自动接受问题。以下是 2026 年 3 月的反馈（社区自述，未重新核实）：

AG Auto-Approve

Ralph Loop 的轻量替代品，只专注于终端命令审批。它不处理文件编辑或 MCP 工具，只处理 shell 命令。如果你想自动运行命令，但仍要手动审查文件更改，它会很有用。可配置的允许列表让你精确指定哪些命令可以自动执行。

Turbo Accept

一个更激进的扩展，零延迟地自动接受一切。没有配置选项，没有排除列表，也没有任何安全网。它本质上就是“尽可能快地对所有请求点击 yes”。当时的社区共识是：适合一次性实验和原型开发，对任何你在乎的内容都很危险。

Keyboard Macro Approach

一些开发者完全不用扩展，而是使用系统级键盘宏工具（Windows 上的 AutoHotkey 或 macOS 上的 Hammerspoon）检测审批对话框，并发送“Accept”的快捷键。这种方法比较脆弱，因为 UI 布局一变就会失效，但它不依赖扩展 API。

Security Implications: What You're Actually Risking

每个自动接受扩展本质上做的是同一件事：把人工审查这一步从智能体的执行循环中移除。在启用任何形式的自动驾驶之前，你需要了解智能体在不受限访问下能做什么：

这种风险并非纯属理论。有安全研究者写到过：获得不受限权限的智能体读取 .env 文件并把凭据发送到外部 URL；还有一起流传很广的事件称，智能体因误解一条含糊的指令而删除了用户磁盘上的内容。2026 年 3 月我们没有为这些说法给出一手来源，所以请把这些具体事件视为 社区自述（2026 年 3 月）。自动接受既是生产力的倍增器，也是风险的倍增器。

推荐方案：“受保护的自动驾驶 (Guarded Autopilot)”配置

2026 年 3 月的建议是：自动接受 安全的 操作，同时对 破坏性 的操作要求手动批准。当时的指南声称这样可以获得约 80% 的速度提升并保留约 95% 的安全性。这些百分比只是编辑的估计，并非实测结果。

步骤 1：配置终端策略

将终端执行策略设置为 "Auto"，并为危险命令添加自定义拒绝列表：

# Settings > Antigravity > Terminal Execution Policy
Terminal Execution Policy: "Auto"

# Add to your deny list:
rm -rf
rm -r /
chmod -R 777
git push --force
git reset --hard
DROP TABLE
DROP DATABASE
curl * | bash
wget * | sh
sudo *
shutdown
reboot

Step 2: Configure Artifact Review

对项目目录内的文件编辑，将 Artifact Review Policy 设置为 "Auto-Accept"。这消除了最频繁的审批提示来源，即智能体每要修改一个文件就会出现的 "Accept diff?" 对话框。（在当前版本中，工作区写入在每种权限预设下都已被允许，计划审阅则是单独的 Plan Review Policy。）

Step 3: Configure MCP Tool Approval

将 MCP Tool Approval 设置为 "Auto for known tools"。这会自动批准你已安装并配置好的 MCP 服务器中的工具，同时对未知或新增的工具仍然提示。（在当前版本中，Auto 预设让 MCP 保持 Ask；对你信任的服务器请添加 mcp(server/*) allow 规则。）

Step 4: Install Ralph Loop with Conservative Settings

{
  "ralphLoop.enabled": true,
  "ralphLoop.autoAcceptEdits": true,
  "ralphLoop.autoRunCommands": false,
  "ralphLoop.autoApproveTools": true,
  "ralphLoop.delayMs": 2000
}

思路是让 autoRunCommands 保持为 false：扩展自动接受文件编辑和工具调用，而终端命令交给内置的 "Auto" 策略和你自己来处理。这些设置键属于 社区自述（2026 年 3 月），在当前 README 中未找到。

使用 .antigravityignore 和沙箱实现安全自动化

在启用任何自动接受机制之前，请先限制 智能体可以访问的内容。这可以在出现问题时缩小影响范围。

.antigravityignore 文件

2026 年 3 月我们把这个文件描述为告诉智能体哪些文件和目录应排除在索引和编辑之外，并建议在自动驾驶工作流中用它保护敏感文件：

# .antigravityignore - protect sensitive files from agent access

# Credentials and secrets
.env
.env.*
*.pem
*.key
credentials.json
service-account.json

# Infrastructure configs
terraform/
.aws/
.gcloud/
docker-compose.prod.yml

# Build artifacts (also speeds up indexing)
node_modules/
dist/
.next/
build/
coverage/

关于如何优化 .antigravityignore 以提升性能，请参阅我们的 智能体加载速度指南。

Sandboxing with Docker

为了在自动驾驶会话期间获得最高安全性，请在 Docker 容器中运行你的项目。智能体仍然可以执行命令和编辑文件，但其访问权限仅限于容器的文件系统。如果智能体执行了破坏性操作，你损失的只是一个容器，而不是你的宿主系统。

# 创建一个隔离的开发容器
docker run -it --rm \
  -v $(pwd):/workspace \
  -w /workspace \
  --network=host \
  node:20-slim bash

# 在 Antigravity 中将容器作为工作区打开
# 智能体此时在容器沙箱内运行

Git as a Safety Net

开始自动驾驶会话之前，请务必先提交你的工作。如果智能体在几十个文件中做了不想要的更改，一条 git checkout . 就能全部还原（现代的等效写法是 git restore .）。把自动驾驶会话当作实验：建分支，让智能体工作，检查 diff，然后合并或丢弃。

Agent Command Execution Rules Configuration

除了 UI 设置之外，2026 年 3 月的指南还描述了通过 gemini.md 规则文件或工作区级的 .antigravity/settings.json 配置细粒度的命令执行规则。

Example: Per-Project Execution Rules

# .antigravity/settings.json  (community-reported, March 2026)
{
  "agent.terminalPolicy": "auto",
  "agent.terminalDenyList": [
    "rm -rf",
    "DROP",
    "git push --force"
  ],
  "agent.terminalAllowList": [
    "npm test",
    "npm run build",
    "npx prisma migrate dev",
    "npx prisma generate",
    "git add",
    "git commit"
  ],
  "agent.autoAcceptEdits": true,
  "agent.autoAcceptEditsExclude": [
    ".env*",
    "package.json",
    "*.lock"
  ],
  "agent.mcpAutoApprove": true,
  "agent.nonWorkspaceAccess": false
}

此配置的意图是自动接受大多数操作，但将敏感文件（.env、package.json、lockfile）排除在自动接受之外，拦截破坏性的终端命令，并防止智能体访问工作区以外的文件。

示例：gemini.md Autopilot 安全规则

你还可以在 gemini.md 文件中使用自然语言规则来约束智能体的行为。这些规则将作为智能体在执行过程中遵循的指令。它们只是给模型的指引，不是强制执行，所以硬性拦截仍要靠 deny 规则：

# gemini.md - Autopilot 安全规则

## 命令限制
- 严禁运行删除项目目录外文件的命令
- 严禁强制推送（force-push）到任何分支
- 未先向我展示 diff，严禁修改 .env 文件
- 严禁从不受信任的来源安装软件包

## 工作流规则
- 修改代码后务必运行测试
- 分成小而合理的块提交工作
- 如果某个测试连续失败 3 次，停下来请求指导
- 不要修改基础设施文件（Dockerfile、docker-compose.yml）

有关规则文件的完整示例和最佳实践，请参阅我们的 工作流指南 和 用户规则参考。

Future: Will Google Add a Native Autopilot Mode?

截至 2026 年 3 月，Google 尚未宣布 Antigravity 的官方自动驾驶或“无人值守智能体”模式。不过，有几个迹象表明它在路线图上：

• 自动继续现已常开：在 v1.20.3 中，Google 移除了自动继续的开关并将其设为默认行为，消除了任务步骤之间的 "Continue?" 提示（社区自述（2026 年 3 月））。
• "Turbo" 执行模式的存在：Google 推出了“仅黑名单”终端模式，说明他们对某些场景下减少人工监督持开放态度。
• 竞争压力：其他 AI 编程工具已经推出了带有可配置安全边界的自动驾驶功能。
• Gemini API 的 "function calling" 自动模式：底层 Gemini API 已经支持无需人工确认的自动函数调用，所以自动执行的基础设施在 API 层面早已存在。

当时预测的实现方式是一个带有可配置护栏的官方“Autopilot Mode”，类似本指南中手动实现的受保护自动驾驶配置，但内置到设置界面中，包含命令的允许/拒绝列表、文件保护模式以及会话级沙箱选项。实际上，这与后来推出的 Auto (Preview) 及其终端沙盒和 allow、ask、deny 规则相当接近。

2026 年 3 月的结论是：基于扩展的方式是社区标准，Ralph Loop + SuperSmooth + 受保护设置是最久经考验的方案。这一结论现已被原生预设取代。“数以千计的开发者每天都在使用”这一说法属于 社区自述（2026 年 3 月），也没有来源。

Before You Enable Autopilot

自动接受赋予智能体不受限的权力。请先确保你的环境已经加固。请阅读我们的 安全加固指南 了解风险，然后查看 智能体性能指南，确保你的智能体加载速度足够快，能够支持无人值守运行。

通过规则与工作流实现更高程度的自动化

自动接受只是第一步。将其与自定义规则和预构建工作流相结合，打造全自动化的开发环境：如何编写自定义规则、Antigravity 工作流指南。

Antigravity 自动同意常见问题

来源：Google Antigravity 文档（Agent permissions、Agent settings、Settings、Choose an execution mode、Headless mode、Artifact review）和 Antigravity 更新日志，核对日期为 2026 年 10 月 30 日。扩展相关细节来自各项目的 GitHub 或 Marketplace README。