Antigravity 2.0 的 Remote Control 让你从手机、平板或另一台电脑的浏览器查看并继续驱动主机上的 agent 会话。它最适合“任务已经在工作站上运行，但人需要离开桌面”的场景：你可以看进度、补充指令、审阅计划和产物，也能在多个主机实例之间切换。
先把边界说清楚：手机是控制面，工作站仍是执行环境。 项目文件、构建工具、环境变量和凭据没有因此搬到手机或一个新的云端工作区。主机睡眠、断电或失去网络后，网页端也无法替它继续运行。
先选对入口：桌面开关还是 Headless Daemon
两条路线都能把主机显示在 Remote Control dashboard 中，但服务生命周期不同。
| 你的实际场景 | 更合适的入口 | 关键前提 |
|---|---|---|
| 正在 Antigravity 2.0 桌面应用里工作，偶尔离开座位 | 打开桌面应用的 Remote Control | 应用在运行，主机保持唤醒和联网 |
| 希望服务器或长期在线机器成为独立实例 | 安装 headless daemon | 接受后台服务、独立登录和更新策略 |
| 只想在另一台电脑完整接管桌面画面 | 先停一下 | Remote Control 面向 Antigravity 会话，不等同于通用远程桌面 |
| 希望关机后任务仍继续 | 无法靠 Remote Control 实现 | 执行仍依赖主机本身 |
桌面路线最简单，也最适合个人工作站。daemon 路线适合没有图形界面、需要开机常驻或要单独命名的机器。不要为了“更专业”同时启用两条路线；官方排障文档明确提到，同一机器可能因此在 Hub 中出现两个相似条目，一个来自 editor，一个来自服务。
在 Antigravity 2.0 中开启远程控制
按照官方 Remote Control 文档的当前步骤：
- 在主机上打开 Antigravity 2.0。
- 按
Cmd + ,；Windows 或 Linux 使用Ctrl + ,。也可以点击左侧边栏底部的 Settings。 - 进入
App。 - 把
Enable Remote Control切到 On。 - 可选：给机器设置容易辨认的 Nickname，例如
studio-mac或build-server。
然后在手机或另一台电脑打开 Antigravity Remote Control dashboard，用桌面应用里的同一个 Google 账号登录。在实例选择器中选中刚才的机器。连接成功后，你应能看到活跃会话，并可开始新任务、审阅 implementation plan 和查看 artifacts。
机器昵称不是装饰。多台笔记本、台式机和服务器同时在线时，清楚的名称能避免你在手机小屏上把高风险指令发到错误项目。建议使用不含客户名、内网地址或个人信息的短名称。
如果手机需要通知，可以把 dashboard 作为 Web App 加到主屏幕，并按设备提示允许通知。Google 的发布说明把完成任务或需要输入时的 push notification 列为 Remote Control 的能力；但通知不是任务仍在运行的证明，最终仍以主机实例和会话状态为准。
让没有桌面应用的机器常驻
服务器或专用工作站可以使用官方 headless daemon。先阅读脚本内容并确认设备与组织政策允许后，再考虑运行安装命令。不要因为域名看起来正确就跳过审阅，也不要在包含敏感配置的共享终端里粘贴登录码。
Linux 和 macOS 的官方安装入口是：
bashcurl -fsSL https://antigravity.google/cli/agy-daemon.sh | bash
需要同时指定名称时，官方文档给出的形式是：
bashcurl -fsSL https://antigravity.google/cli/agy-daemon.sh | bash -s -- install --name "build-box"
Windows 必须在以管理员身份运行的 Command Prompt 中安装，不是 PowerShell：
batcurl -fsSL https://antigravity.google/cli/agy-daemon.cmd -o agy-daemon.cmd && agy-daemon.cmd install
安装和卸载需要管理员权限；status 与 restart 可以在普通命令提示符中使用。daemon 第一次设置时会要求单独登录：打开终端打印的 URL，再把代码粘贴回来。即使 editor 已经登录，再次要求认证也是正常的，因为两条登录状态彼此独立。
官方还提供 --interval weekly、--no-auto-update、--no-prompt、status、restart 和 uninstall 等选项。自动更新是否合适取决于机器角色：个人开发机可以追求及时修复；受控服务器更适合先在维护窗口验证版本。不要在不了解回滚与变更窗口的情况下直接关闭或放开自动更新。
为什么重启、退出登录后表现不一样
daemon 的“已安装”不代表三个系统上的持续条件相同。当前官方文档给出的差异如下：
| 系统 | 何时启动 | 用户退出登录后 | 崩溃后的恢复 |
|---|---|---|---|
| Linux | 开机时 | 继续运行 | 自动恢复 |
| macOS | 用户登录时 | 停止，下次登录恢复 | 自动恢复 |
| Windows | 开机时 | 继续运行 | 不会立刻自动恢复；可能等下次开机、计划更新或手动 restart |
这张表能解释很多“昨天能连，今天机器不见了”的情况。macOS 服务器若停在登录窗口，daemon 不会像 Linux 服务那样继续在线；Windows 服务崩溃后也不能只等网页端自动重连。
daemon 的设置文件当前位于：
- Linux / macOS：
~/.gemini/config/config.json - Windows：
%USERPROFILE%\.gemini\config\config.json
文件中 cliRemoteControlHostname 对应 daemon，remoteControlHostname 对应同机的 Antigravity editor。只改对的字段，并避免把整个配置文件发到论坛或工单；其中可能包含不适合公开的环境信息。若安装时使用了 --name，该参数会在服务重启时覆盖文件里的名称。
实例不出现时，按依赖关系排查
不要从刷新网页开始无限重试。依次确认这些可观察条件：
- 开关或服务存在。 桌面路线确认
Enable Remote Control仍为 On；daemon 路线先运行官方脚本支持的status。 - 账号完全一致。 主机和 dashboard 必须使用同一个 Google 账号。浏览器多账号登录时尤其容易选错。
- 主机未睡眠。 屏幕关闭不一定等于睡眠；检查操作系统电源策略，而不是只看显示器。
- 主机仍有互联网。 网页端短暂断开会尝试重连，但只有主机本身保持网络时，后台 agent 任务和 shell 命令才会继续。
- 看清实例类型。 editor 和 daemon 可以同时出现，名称相近不代表重复故障。
- 检查认证状态。 daemon 日志若提示 sign-in 问题，按官方流程重新运行设置；在该机器上对
agy登出也会让服务失去访问权。 - 按 OS 生命周期恢复。 macOS 先确认用户已登录；Windows 服务异常时使用
restart，不要等待手机端修复主机服务。
如果只有远端 UI 断开，而主机网络仍正常，官方文档称 UI 会尝试自动重连，已有后台任务可继续。反过来，主机断电、睡眠或应用退出不能被“网页还开着”抵消。
远程批准前先缩小权限
Remote Control 让批准动作更方便，也让误点的距离更短。Antigravity 的权限文档采用 Deny > Ask > Allow 的优先级；工作区内的常规读写有默认便利，而命令、MCP、网页执行和工作区外文件通常回到 Ask。
在手机上操作时，至少保留三条规则：
- 不因为屏幕小就批准看不完整的 command、路径或域名；回到更大屏幕查看上下文。
- 对不信任的项目保持较窄的项目权限，不把
Full machine或Unrestricted当成解决弹窗多的快捷键。 - 给多台机器使用清晰昵称，并在执行删除、发布、付款、密钥或生产环境操作前再次确认实例与项目。
Google 把 Remote Control 称为进入 workspace 的安全窗口，但当前公开页面没有给出足以推导具体传输协议、入站端口、数据驻留或合规保证的完整说明。对受监管或企业环境，应该让安全团队基于当前正式文档与合同评估，而不是从“secure”一个词扩展出未写明的保证。
找不到开关，不要先买套餐
截至 2026 年 8 月 27 日，官方功能页和文档已经公开，但本轮核验的官方页面没有提供完整的套餐、地区与分阶段开放矩阵。因此，Enable Remote Control 缺失时，先确认：
- 正在使用 Antigravity 2.0，而不是旧版或其他 IDE 集成；
- 应用已更新并重新启动；
- 当前 Google 账号与工作区确实获得该功能；
- 管理设备或组织策略没有隐藏或限制远程入口。
不要依据社交帖里某个账号的截图，推导购买某个计划一定会解锁。更可靠的下一步是查看最新版官方文档，再按当前账号界面与官方支持信息判断。
连接完成后的验收标准很简单：你能从另一个浏览器识别正确主机、打开预期会话、看见当前计划或产物，并在一个低风险动作上收到与主机一致的权限边界。做到这一步，Remote Control 才真正从“手机上有个页面”变成可控的开发工作流。
