先说核心结论：Antigravity 的 Browser Subagent 会在一个独立的浏览器配置文件（Profile）中驱动本地 Chrome，而遇到浏览器不工作的反馈时，首先要检查的通常是 Chrome 是否可用、Browser Tools 开关是否打开，以及 URL 允许列表。这些检查并不能排除操作系统权限、扩展程序状态、网络策略或产品回归等问题。
这个独立的浏览器配置文件（Profile）按设计也不会带上你平时 Chrome 里的登录态。Antigravity 较新的 Remote Control 功能解决的是另一个问题：从另一个浏览器访问 Antigravity 会话及其本地工作区，而不是把该会话导入到一个中立的自动化工具里。
Antigravity 在浏览器这块的做法确实有辨识度：IDE 里的 Agent 可以“打开、读取并操作本地 Chrome 浏览器”，并把做过的事记录成可回放的过程产物（artifact）：附在任务上的截图和操作视频。
所以本文的结构是：先用一节讲清架构，再讲正确的安装配置，然后按症状顺序给出修复清单，最后说明在哪些边界上应该换用别的工具。下面引用的内容全部来自 Google 官方的 Antigravity 文档，随着产品演进，你可以逐条对照原文核实。
Antigravity 的浏览器自动化是如何工作的？
按 Google 文档的说法，一共三块。驱动者是专门的 Browser Subagent，它“按需在浏览器标签页上操作”：你的主 Agent 把浏览器工作委派给它，而不是自己握着方向盘。
操作界面是本地 Chrome，但不是你的 Chrome：工作“在一个完全独立的 Chrome 配置文件（Profile）中进行，以保护你的个人数据”，这是一个真实的安全决策，也带来一个真实的后果，后面会讲到。
而输出可以成为证据：这个 subagent 的工作方式是“抓取截图，并把操作视频保存为可交互的过程产物”，因此有记录的浏览器运行会在 IDE 里留下可回放的记录。
这条过程产物链路是 Antigravity 有、而大多数 Agent 浏览器没有的特性：验证被内建在媒介里。当 Agent 说它测试过你的注册流程时，有一段视频为证。
它对评审的改善，大于它对自动化本身的改变。一次包含流程执行录像的任务运行，会给评审者提供测试和日志之外的又一份过程产物；但它不能替代对涉及安全或数据的流程重新跑一遍。
委派、隔离、记录。这就是它的设计。
如何正确完成安装配置？
按顺序做四项检查，就能完成一次有用的初次安装配置。先确保有一个受支持且版本较新的 Chrome 安装；文档中的 Browser Subagent 路径要操作本地 Chrome，所以缺少二进制文件或版本不兼容都会让这条路径无法启动。
确认总开关：Browser Tools 位于 User Settings 的 Browser 区域，它是整个能力的开关。检查 URL 安全模型：两层的 Denylist 和 Allowlist 决定 subagent 可以访问哪些 URL，而当 Agent 静默地访问不到你的目标时，allowlist 收得太窄和功能坏掉是分不出来的。
然后跑一个端到端走完整条链路的第一项任务：“打开 localhost:3000，截图落地页，并附上录像”，确认过程产物出现。
如果这第一项任务产出了截图和视频，核心路径就是通的；之后的失败仍可能来自提示词、权限、allowlist 变更、浏览器更新或目标站点的策略。具体到 allowlist，把 subagent 限定在你实际使用的开发域名和文档站点上，这样两层模型才能保持为一个有效的边界。
浏览器不工作或打不开：检查清单
按症状排序，先做成本最低的检查。这些检查对应的是上面的架构，而不是什么秘密知识，这正是它们有效的原因。
| 检查项 | 为什么它是最可能的原因 |
|---|---|
| Browser Tools 开关确实已打开 | 它是总开关，位于 User Settings 的 Browser 下，被关掉时会显示为“broken” |
| Chrome 已安装、版本较新，且没有卡死 | 子 Agent 会启动一个本地 Chrome 浏览器配置文件（Profile）；Chrome 缺失、版本过旧或反复崩溃都会导致启动失败。请退出所有 Chrome 进程后重试 |
| 目标 URL 通过了允许列表/拒绝列表检查 | 双层模型会在用户看不到的情况下静默拦截；某个任务在特定网站上“毫无反应”，通常就是这个原因 |
| 更改 Chrome 或设置后重启 IDE | 子 Agent 与浏览器之间的连接在会话级别建立；修复之前的状态可能残留，直到重新启动才会清除 |
| 更新 Antigravity 本身 | 浏览器功能仍在积极开发中（文档跟随 IDE 版本更新）；落后一个版本可能意味着你遇到的是已知已修复的行为 |
按设计，它的边界在哪里？
三个边界，都是合理决策的结果。你日常 Chrome 的登录态不会被带过去：隔离的配置文件（Profile）保护了你的个人数据，同时也意味着子 Agent 以陌生访客的身份浏览，因此仪表盘、门户网站以及任何需要账号才能访问的内容，都需要单独配置的会话和经过批准的工作流。
它带有 Google 技术栈的形态：浏览器是 Antigravity IDE 及其 Agent 的一项能力，而不是其他 Agent 可以借用的通用执行层。它也是开发循环工具：产物系统围绕验证你项目的页面而构建，而不是围绕你去做别的事时全天候运行后台网页任务。Remote Control 把这一开发循环扩展到多设备，但不会改变谁拥有机器、文件、凭证或正在暴露的环境变量。
在这些边界之内（测试应用、阅读文档、记录证据），Antigravity 提供了一套内置的验证循环，并会记录产物。一次配置文件（Profile）登录或一条允许列表条目，并不会把这种开发工作流变成通用的无人值守账号任务执行器。
超出这些边界后有哪些替代方案？
根据你遇到的边界来选择合适的替代方案。
需要登录的日常任务：可以考虑 ego (lite)，一款免费的 Chromium 浏览器，可以导入 Chrome 配置文件（Profile），让 Agent 基于你已有的登录态工作，而不是从空配置文件开始。会话过期、账号权限、网站政策以及受支持 Agent 列表仍然适用。
为这个推荐提供一个数据点：在 Real-World Bench 上，使用相同模型和评判器对真实网站执行 31 个任务，ego (lite) 完美完成了其中 93.5%，这描述的是该任务集，而非所有工作负载。数据集和评判工具已在 GitHub 上开源。
深度页面诊断（trace、堆快照）：Chrome DevTools MCP，可与上述任何方案搭配使用。跨浏览器测试基础设施：Playwright，一如既往。
对 Antigravity 用户来说，务实的终点是组合使用，而非替换：保留 Browser Subagent，用于其有文档记录的验证并记录循环；当日志任务在 Agent 支持、账号权限和审查控制方面都匹配时，使用单独配置的浏览器来完成需要登录的工作。
实际效果大致是这样：Antigravity 记录功能可用的证据，ego (lite) 执行与你代码库无关的周一早晨仪表盘拉取任务，两者都不被要求伪装成对方的形态。
免费下载 Mac 版 ego (lite)，或阅读 登录墙指南了解会话模型。
什么是 Antigravity Remote Control，如何启用？
Antigravity Remote Control 是一个浏览器仪表盘，用于连接并驱动运行在你自己笔记本、台式机或服务器上的 Antigravity 2.0 会话。它让你查看对话、启动任务、审阅计划、检查产物，并从另一台设备继续工作；它是对 Antigravity 工作区的远程访问，而不是新的浏览器配置文件（Profile），也不是让另一个 Agent 借用会话的方式。
Google 官方给出的安装配置步骤很短：
- 在 Antigravity 2.0 中打开 Settings（macOS 上为 Cmd + ,，Windows/Linux 上为 Ctrl + ,），选择 App，然后打开 Enable Remote Control。如果你运行多台机器，给该实例起一个昵称。
- 在任意设备上打开 Antigravity Remote Control Dashboard，用桌面应用所用的同一个 Google 账号登录。在实例切换器中选择已命名的机器，然后在启动或批准工作之前先审阅会话。
- 对于无头的 Linux 或 macOS 机器，用文档中给出的 agy-daemon.sh 命令安装 Google 的 Remote Control 守护进程；Windows 安装需要管理员命令提示符。守护进程的一次性登录与编辑器登录相互独立，其服务在重启后仍可保留访问权限。
安全边界很容易被忽略：Remote Control 保留了对主机文件、构建工具、凭证和环境变量的访问权限。请把仪表盘和守护进程账号视为对该机器的特权访问，只在你控制的机器上启用，使用清晰的实例名，并在主机不应再被访问时关闭它或退出登录。如果机器处于睡眠、离线、守护进程已退出登录，或使用了不同的 Google 账号，它就不会出现或重新连接；正在运行的本地任务只有在主机保持可用时才会继续。
阅读Google 的 Remote Control 文档了解当前的命令 flag、设置文件位置、服务生命周期和故障排查。当你需要从手机或另一个浏览器继续同一个 IDE 会话时，这个功能很有用；它并不能消除上文所述的独立配置文件限制。
Antigravity 的配额和 Token 成本是怎么算的？
Antigravity 的用量由 Google 账号、套餐、模型和当前容量决定，而不是由某个统一的 Token 单价决定。浏览器任务在循环、重试、截图，或让模型检查大型页面时，可能消耗更多配额。请把配额指示器和任何套餐文档当作权威依据，并按每个被接受的结果来衡量成本，而不是数提示词条数。
- 设定任务预算。 使用有界的目标、最大操作次数和时间限制。在重复相同操作后停止运行，而不是等到配额警告出现。
- 减少观察量。 一次只请求一个元素或一种状态，避免不必要的截图，对重复的导航或解析使用确定性脚本。
- 在你的任务上比较模型。 更便宜或更快的模型对静态页面可能够用，但在动态 UI 上会失败。在更换方案之前，记录重试次数、被接受的输出和手动恢复情况。
当某个 Gemini 模型看起来异常快速地消耗配额时，停止并行任务，保存当前工作，并检查模型、上下文、截图和重试历史。轮换密钥或使用第二个账号并不能解决过大的工作流，还可能违反账号政策。
如何修复 Antigravity 浏览器连接和扩展程序故障？
按依赖顺序诊断连接失败：IDE、Chrome 二进制文件、Browser Tools 设置、配置文件、允许列表，以及 CDP 或扩展程序路径。先在一个无害的公开页面上复现，再接触需要登录的工作流。新打开的、未安装扩展程序的 Chrome 配置文件是另一个浏览器目标，不能证明该功能本身不可用。
- 确认浏览器目标。 验证配置的 Chrome 可执行文件存在、能正常启动，并且就是 Antigravity 所期望的那个配置文件或二进制文件。不要在未确认支持的情况下指向随意的 Chromium 构建。
- 检查 Browser Tools 和权限。 确保 Browser Tools 已启用，扩展程序已安装在当前活动的配置文件中，并且目标 URL 被文档所述的拒绝列表/允许列表模型所允许。更改这些设置后重启 IDE。
- 检查连接边界。 对于 WSL 或 VPS 上的 CDP，只绑定并转发预期的本地接口和端口。确认防火墙、代理和用户权限；绝不要将调试端口暴露到公网。
如果缺少环境变量或自定义路径，请在受支持的服务或 shell 配置中恢复它，并启动一个新会话。不要设置宽泛的主目录、禁用操作系统安全机制，或复制其他用户的配置文件作为变通办法。
如何阻止 Antigravity 浏览器循环和控制失误？
通过让每个浏览器步骤可观察且有界来防止循环：命名预期状态，使用一个稳定的定位器，设置重试上限，并在页面没有变化时停止。一个不断点击确认按钮或反复重写同一个文件的模型，需要的是终止开关和更小的任务，而不是让它再努力一点的指令。
- 先定义完成标准。 明确写出结束任务的依据：URL、可见的成功标志、预期生成的文件，或测试断言。让 Agent 汇报这些证据。
- 把计划和执行分开。 在执行破坏性修改前，先审批一份简短的计划，然后一次只运行一个浏览器操作。终端命令和浏览器操作要保留在同一个可见的任务日志里。
- 状态没变化就停下来。 如果连续两次截图、URL 或 DOM 状态完全相同，就暂停并人工检查。记录下错误，只有提出新的假设后才继续。
提示词注入（Prompt Injection）是另一类控制失效：页面文本可以指示 Agent 忽略任务或泄露机密。要把页面内容视为不可信，对有副作用的操作保持审批开启，并把浏览器配置文件和允许列表限定在当前任务范围内。
如何从 Antigravity 超时、429 和数据丢失中恢复？
恢复的思路是：保留最后一个已知可用的状态，对错误分类，只重试安全的那一类。遇到 429、503 或容量不足的提示，应当退避并缩小队列；遇到 Agent 主动终止的运行，应当从保存的检查点恢复；遇到数据丢失的报告，应当先做版本控制和备份，再考虑下一次重构。
- 重试之前先保存。 提交或复制当前代码，保留截图和产物，并记录确切的提示词、模型和任务状态。绝不能让自动重试覆盖掉结果的唯一副本。
- 容量类错误要退避。 按照服务方的指引等待，降低并发，然后重试一次。如果容量或频率限制仍然存在，就把任务安排到之后执行，或改用已获批准的模型；不要跑紧凑的重试循环。
- 从检查点恢复。 把大型重构或抓取任务拆成有名字的步骤，并逐个验证已接受的结果。重新打开上一个产物，而不是让 Agent 去重建一个未知状态。
扩展程序或 MCP 让 Antigravity 一直卡在“working”，并不代表任务还在推进。应当取消它，检查进程和日志，逐个禁用可选的集成，再用一个最简单的页面重试。对于无法安全重放的工作，要保留一条手动路径。
如何修复 Antigravity 登录和会话问题？
Antigravity 的 Browser Subagent 使用单独的 Chrome 配置文件，所以缺少 Google、Salesforce 或社交账号的登录态是正常现象，而不是 Cookie 出了问题。只在你可控的配置文件里通过网站正常的登录流程登录，并预期 MFA、设备检查和账号策略会要求人工介入。Remote Control 还要求仪表盘和主机使用同一个 Google 账号；切换账号可能让一台本来正常的机器从列表中消失。
- 核对账号边界。 检查 Antigravity、Remote Control 仪表盘以及任何守护进程当前登录的是哪个 Google 账号。给机器起一个清晰的名字，并登出你已不再控制的旧会话。
- 人工完成验证。 遇到 OAuth、两步验证（2FA）、验证码（CAPTCHA）、账号找回或账号解锁步骤时，应当暂停。不要自动化验证码，不要抓取 refresh token，也不要从个人浏览器复制 Cookie。
- 撤销过期的访问权限。 在安装配置失败或结果不明之后，检查 Google 账号会话、扩展程序权限和守护进程服务。移除你无法对应到某台机器或某个工作流的访问权限。
Antigravity 用户应该启用哪些安全和隐私控制？
把 Antigravity 当作特权工具来用：使用范围很窄的配置文件、显式审批和可回退的任务。Browser Subagent 能读取页面内容，IDE 能访问项目文件、终端命令、产物，并通过 Remote Control 访问主机。单独的 Chrome 配置文件能保护个人会话不受日常浏览影响，但它并不能让页面内容变得可信，也不能让主机变成可随意丢弃的。
- 别把机密放进任务里。 使用限定范围的环境变量和最小权限账号。不要把 API Key、密码导出文件或恢复码放进提示词、截图、产物或版本控制中。
- 审查扩展程序和集成。 只从你能验证的来源安装 Browser Tools 以及任何 cockpit 或 MCP 集成。移除不再使用的扩展程序，并在更新后检查它们的主机权限。
- 保护远程访问。 只在需要时开启 Remote Control，为 Google 账号启用强身份验证，当这台机器不应被远程访问时，关闭守护进程或退出登录。
本地执行、VPN 或密码管理器都不能保证免受提示词注入或有害的已批准操作。把网页视为不可信输入，限制允许列表，发布或发送前要求人工审核，并在 Agent 之外保留一个紧急停止开关。
如何在 Linux 上安装和升级 Antigravity？
使用 Google Antigravity 当前发布的 Linux 安装包和安装说明，升级前校验压缩包并保留工作区。Antigravity 的发行方式和包格式可能变化，不要把非官方的 Flatpak、deb 转换包或复制的二进制文件当作受支持版本。
- 备份并记录当前版本。 提交代码，导出重要产物，记录扩展程序和设置，并确认守护进程或 Remote Control 服务可以干净地停止。
- 安装受支持的 tar 包或软件包。 从 Antigravity 官方渠道下载，解压到用户自有目录，仅在文档给出的路径下创建桌面入口或服务。检查可执行权限和 Chrome 依赖。
- 把升级当作受控变更。 停止正在运行的 Agent，把新版本与旧版本并排安装，启动一个冒烟测试工作区，然后逐个重新启用扩展程序或守护进程。在新版本通过验证前保留旧安装包。
如果 tar 安装以交互方式可用但作为服务不可用，请对比服务用户的 PATH、HOME、显示/会话访问权限、Chrome 二进制路径和可写目录。不要用 root 运行 IDE 或守护进程来掩盖权限错误。
如何迁移 Antigravity 或把它与其他工具集成？
迁移到其他 IDE、CLI 或浏览器 Agent 时，把 Antigravity 的项目、浏览器产物和凭证分开保存。导出代码和有文档记录的配置；不要假设对话、扩展程序状态、OAuth 授权或 MCP 连接在应用拆分后仍然存在。通过服务商重新认证，并在一次性工作区中验证每个集成。
- 用于 Gemini CLI 或其他编码 Agent。 迁移仓库和任务说明，然后通过受支持的 MCP 或外部浏览器接口重建浏览器访问。Antigravity 的 Browser Subagent 和产物不会自动对其他客户端可用。
- 用于手机或远程监控。 当主机和账号在线时，对同一个 Antigravity 工作区使用 Remote Control。它不是公共 API，也不会把 Browser Subagent 变成通用的远程浏览器。
- 用于需要登录态的周期性浏览器工作。 使用明确受支持的外部浏览器工作流，例如 ego (lite)，配合已授权的会话，并把 Antigravity 留给它验证并记录的开发循环。不要在工具之间共享原始 Cookie 或调试端口。
迁移后运行一组小型验收用例：打开一个公开页面，测试一个允许访问的内部页面，生成一个产物，停止 Agent，并确认密钥和权限仍在限定范围内。能正常启动并不能证明所有旧连接或策略都已迁移过来。
FAQ
什么是 Google Antigravity Remote Control？
它是一个 Web 仪表盘，可连接到你控制的机器上运行的 Antigravity 2.0 桌面会话或无头守护进程会话。你可以在另一个浏览器中查看对话和产物、启动或继续任务，并在 Agent 需要你时做出响应。它是对现有工作区的远程访问，而不是匿名的云端浏览器。
如何启用 Antigravity Remote Control？
打开 Antigravity 2.0 的 Settings，选择 App，开启 Enable Remote Control。然后在另一个浏览器中打开 Remote Control Dashboard，用同一个 Google 账号登录。无头 Linux 或 macOS 请使用 Google 文档提供的 agy-daemon.sh 安装脚本；Windows 需要管理员命令提示符。
我可以用手机使用 Remote Control 吗？
可以，前提是主机在线且 Remote Control 服务已登录。Google 文档提供了基于浏览器的仪表盘，并可选安装为移动 Web 应用以接收推送通知。手机可以监控和批准 Antigravity 会话，但不会把主机变成通用远程桌面，也无法绕过处于睡眠、离线或已退出登录状态的机器。
Remote Control 会把我的 Antigravity 登录态共享给其他 Agent 吗？
它会把你授权的 Google 账号和浏览器会话所对应的现有 Antigravity 工作区暴露出来，包括主机的文件、构建工具、凭证和环境变量。它不会把这些资源公开，但这仍然是特权访问。只在你自己控制的机器上使用，保护好账号，批准操作前审查提示，并在不再需要远程访问时关闭该功能。
Google Antigravity 有浏览器扩展程序吗？
文档描述的架构是 Browser Subagent 驱动本地 Chrome 浏览器配置文件（Profile），而不是从应用商店安装的扩展程序；IDE 自己管理连接。如果你是因为安装配置失败才去找扩展程序，上面那份检查清单才是真正的修复路径。
Antigravity 的浏览器能用我登录的账号吗？
按设计不能：自动化运行在一个完全独立的 Chrome 浏览器配置文件（Profile）里，正是为了让你的个人数据留在外面。你可以在这个配置文件里手动登录网站，但那样就要维护两份重复的会话；如果工作以账号为中心，用能继承会话的浏览器是更干净的架构。
我能把浏览器自动化完全关掉吗？
可以：在 User Settings 的 Browser 区域里，Browser Tools 设置项会禁用这些工具；即使工具处于开启状态，denylist 也能把特定 URL 挡在可达范围之外。对 Agent 浏览心存顾虑的团队，有一个真正的关闭开关。
我能控制 Agent 浏览哪些网站吗？
可以，而且是双重控制：两层的 Denylist 和 Allowlist 决定哪些 URL 可达，Browser Tools 开关则直接关掉整个能力。实用做法是：日常用一份限定范围的 allowlist，再加上 denylist 挡住绝对不能碰的东西，并在项目列表变化时重新检查。
它和Cursor 内置浏览器相比怎么样？
属于同一类（由 IDE 管理、隔离、面向开发循环），但各有特点：Antigravity 的 artifact 系统（操作视频）是它的独有优势，Cursor 可 grep 的日志和基于图片的截图则是 Cursor 的。两者有同样的边界：都不会带上你的个人登录态，这类工作都要交给外部浏览器。