症状： 2026 年 6 月 18 日起，Gemini CLI 已停止为 Google AI Pro、Google AI Ultra 及免费层个人账号提供请求服务。
最快解法： 个人账号直接迁移到 Antigravity CLI；企业许可或付费 API 用户先保留 Gemini CLI，用一周双轨测试确认兼容性后再切换。(github.com)
这篇文章适合三类人：依赖 Gemini CLI 日常编码、现在需要恢复终端工作流的开发者；维护 Skills、MCP、Hooks、Agents 或自动化脚本的高级用户；负责远程 Mac、SSH 和团队研发环境的负责人。
Last updated：2026 年 8 月 15 日。 账号范围、迁移路径、权限规则和 CLI 行为已根据 Gemini CLI 官方公告、Antigravity CLI 迁移文档、官方仓库及权限文档核对。套餐、后续路线图和长期维护期限若未获官方确认，本文不把它们当作既定事实。
先按账号类型决定 Gemini CLI 迁移 Antigravity CLI
这次调整不是“Gemini CLI 对所有用户完全下线”。官方明确区分了个人账号、企业许可和 API 认证路径：个人免费层及 Google AI Pro、Ultra 账号受到停服影响；Gemini Code Assist Standard、Enterprise 许可，以及通过 Google Cloud 或付费 API 密钥认证的用户不受同等影响。(github.com)
| 你的认证方式 | 2026 年 6 月 18 日后的状态 | 推荐动作 | 回滚空间 |
|---|---|---|---|
| 免费层个人账号 | Gemini CLI 不再提供请求服务 | 立即迁移 Antigravity CLI | 保留旧配置副本 |
| Google AI Pro / Ultra 个人账号 | Gemini CLI 个人路径停止请求 | 迁移并优先验证日常项目 | 可保留旧目录，不应继续依赖旧认证 |
| 企业 Standard / Enterprise 许可 | 官方称访问保持支持 | Gemini CLI 与 Antigravity CLI 双轨测试 | 较大，可按项目切换 |
| 付费 API 或 Google Cloud 认证 | 官方称不受同等影响 | 先评估成本、权限和自动化兼容性 | 较大，但要核对 API 配额与治理 |
因此，个人用户不宜继续等待 Gemini CLI 恢复原有 OAuth 路径。企业和 API 用户可以暂留，但“暂留”不等于无限期不动：如果你的 Skills、MCP 或无头脚本已经绑定旧目录，提前建立新旧环境对照会更安全。
迁移前先盘点配置、权限和自动化资产
典型中断场景是这样的：你打开 Mac，发现 Gemini CLI 无法继续请求，但本机仍保存着项目记忆、插件、Hooks 和定时脚本。此时直接删除旧目录，最容易把可恢复的工作流一起删掉。
先制作整个配置目录的只读副本，再开始安装。官方迁移说明提到，Antigravity CLI 可以识别已有 Gemini CLI 配置，并在首次启动时提供迁移选择；Skills、MCP Servers、Agents、项目记忆和插件并不代表“所有自动化逻辑无需检查”。(github.com)
建议按下面的清单逐项记录：
- ✅ Skills：名称、来源、依赖的环境变量和脚本路径。
- ✅ MCP Servers：本地进程、远程地址、认证方式、可调用工具和写入权限。
- ✅ Agents：系统提示词、允许的工具、项目范围，以及是否依赖旧目录结构。
- ✅ Hooks：触发时机、执行命令、退出码和失败后的处理方式。
- ✅ 项目记忆：
gemini.md等上下文文件，以及仓库中是否存在同名或覆盖规则。 - ✅ 认证方式：浏览器登录、系统钥匙串、API 密钥、远程 SSH 登录方式。
- ⚠️ 无头任务：定时任务、CI 脚本、管道输入、JSON 输出和后台执行。
- ⚠️ 自定义扩展：不要只看首次启动是否显示“已导入”，还要实际调用。
你可以把盘点结果写成一张表，避免只凭记忆迁移：
| 资产 | 迁移前检查 | 迁移后验收 | 未通过时的处理 |
|---|---|---|---|
| 项目记忆 | 文件存在、内容可读 | Agent 能引用项目约定 | 恢复旧文件并手动指定 |
| Skills / 插件 | 记录入口与依赖 | 能被发现并执行 | 重新导入或改路径 |
| MCP | 记录服务器和工具 | 能发现、授权、调用 | 单独重写配置 |
| Hooks | 保存脚本和触发条件 | 事件触发且退出码正确 | 暂时禁用，逐个恢复 |
| 无头脚本 | 保存命令与输出格式 | 能完成一次测试任务 | 继续使用旧认证或改造 |
| 权限策略 | 记录允许、询问、拒绝规则 | 危险命令仍需确认 | 回退到默认询问策略 |
如果你还没有固定的 Mac 验收环境，可以先参考 远程 Mac 算力方案 了解可持续的 macOS、SSH 和 Xcode 测试条件。这里的重点不是马上采购，而是先保证迁移测试不会因为本地设备不可用而中断。
第一小时验证自动导入，而不是相信提示完成
Antigravity CLI 的官方迁移路径支持首次启动时检测 Gemini CLI 配置，并让你选择要转换的扩展和全局配置；官方迁移文档还说明，活动会话令牌可以迁移到操作系统原生钥匙串。(antigravity.google)
但自动导入只证明“转换流程运行过”，不证明你的工作流已经可用。第一小时应使用一个最小测试仓库，不要直接在生产项目中验证。
建议顺序如下：
- 复制配置：保留 Gemini CLI 原目录和环境变量文件，不覆盖原文件。
- 安装并启动：在干净的测试目录运行 Antigravity CLI，确认版本和登录路径。
- 接受迁移选项：只导入一组可控资产，先不要一次性迁移所有插件。
- 验证项目记忆：让 Agent 解释仓库约定，但禁止修改文件。
- 验证插件和 Skills：执行一个只读任务，确认工具被发现且依赖齐全。
- 验证 MCP：先调用只读工具，再测试需要写入或外部网络的工具。
- 验证文件权限：让 Agent 修改一个测试文件，检查是否出现授权提示。
- 保存日志：记录导入结果、错误信息和未迁移资产，便于回滚。
注意： 官方称 Skills、MCP Servers、Agents 和
gemini.md具备迁移或兼容路径，但自定义 Hooks、无头脚本和外部编排器仍必须单独验收。功能名称相同，不等于命令参数、输出格式和权限行为相同。(github.com)
第一天用同一任务比较新旧终端工作流
企业许可或付费 API 用户不需要在第一天立即做“全量切换”。更稳妥的方法是让 Gemini CLI 和 Antigravity CLI 处理同一个小型仓库、同一份任务说明和同一组测试命令。
不要只比较回答速度。你真正要观察的是人工接管次数、失败后的恢复方式，以及最终代码是否通过原有测试。
可以使用以下任务序列：
- 让 Agent 阅读项目结构并列出风险，不允许改文件。
- 修改一个跨目录功能，要求保留现有接口。
- 执行格式化、单元测试和构建命令。
- 检查差异，指出可能的破坏性修改。
- 启动一个后台任务，再中断并恢复会话。
- 让 Agent 根据测试失败日志继续修复。
- 比较最终差异、测试结果和人工确认次数。
对于 Mac 项目，验收不能停在终端。涉及 Swift、Xcode、签名或模拟器的仓库，至少要把“Agent 修改代码后，能否在完整 macOS 环境中完成构建与测试”作为交付条件。远程环境还要记录 SSH 断线、重新授权和会话恢复是否需要人工介入。
这一阶段不要自行宣布“Antigravity CLI 更快”或“更省资源”。如果没有本站实测记录，就只记录任务是否成功、哪些地方需要人工接管，不把官方宣传转写成性能结论。
第一周检查 macOS、远程 SSH 与权限边界
Antigravity CLI 官方仓库将 macOS、Linux 和远程 SSH 会话列为重点使用场景；远程环境登录时，工具可以检测 SSH 会话并输出授权地址，供本地浏览器完成登录。认证信息则优先使用系统钥匙串。(github.com)
这对 Mac 开发者有两个直接影响：
- 本地 Mac 上，要检查系统钥匙串、浏览器授权和终端权限是否正常。
- 远程 Mac 上，要检查 SSH 登录、端口转发、断线重连和本地浏览器授权是否可重复。
第一周建议按四个边界验收：
终端与文件边界
确认项目目录可以读取和写入，但 .ssh、钥匙串文件、生产凭据和仓库外目录默认不能被 Agent 自动修改。不要为了减少确认提示，直接把整个用户目录加入允许范围。
命令执行边界
Antigravity CLI 的权限系统区分 allow、ask 和 deny，并对命令、文件、网络 URL 和 MCP 工具进行细粒度控制。官方文档明确说明，冲突规则按拒绝、询问、允许的优先级处理，未配置的敏感操作通常保留询问状态。(antigravity.google)
MCP 边界
先验证 MCP 服务器能否被发现，再验证具体工具是否可调用。只允许必要的服务器和工具，不要直接使用全局通配权限。尤其要检查远程 MCP 的认证令牌是否仍然有效，以及迁移后配置文件是否放在工具实际读取的位置。
Xcode 交付边界
把 xcodebuild、单元测试、签名和模拟器测试列入验收。终端 Agent 能修改 Swift 文件，不代表它已经具备完整的 iOS 交付能力；构建失败、钥匙串不可用或签名权限缺失，都应算作迁移未完成。
按一周结果决定全面迁移还是双轨保留
你可以用下面的决策表收口，不需要根据“新工具看起来更先进”做判断：
| 场景 | 关键通过条件 | 建议方案 |
|---|---|---|
| 个人开发者 | 登录、项目记忆、Skills、MCP 和主要编码任务均通过 | 全面迁移到 Antigravity CLI |
| 企业团队 | 关键仓库、权限策略、审计要求和回滚流程均通过 | 分批迁移，保留 Gemini CLI 作为回退 |
| 付费 API 用户 | API 成本、脚本输出、配额和失败重试均已核对 | 可继续使用 Gemini CLI，也可逐项目切换 |
| 远程 Mac 工作流 | SSH 授权、断线恢复、Xcode 构建和权限边界均通过 | 先保留双环境，再扩大迁移范围 |
| 自动化流水线 | 无头执行、JSON 输出、MCP 和人工审批机制均通过 | 未完成验证前不要切换生产流水线 |
正式切换前，至少满足以下条件：
- ✅ 个人账号已经完成新的认证，不再依赖旧 OAuth 路径。
- ✅ 主要项目的记忆文件、Skills、插件和 MCP 已逐项调用。
- ✅ 无头脚本能够完成一次真实测试，并保留原始输出。
- ✅ 危险命令、网络访问、文件写入和 MCP 调用仍有明确授权。
- ✅ Mac 本地或远程环境可以完成构建、测试和签名验收。
- ✅ 旧配置已归档，没有被新工具覆盖。
- ✅ 明确回滚条件，例如关键插件无法调用、生产脚本输出格式改变，或远程授权无法稳定恢复。
迁移维护成本也要算进去。官方没有在本文核实范围内固定 Antigravity CLI 后续套餐、用量或路线图，因此不要把未经确认的价格写进采购结论。对企业而言，真正的成本不只是订阅费用，还包括脚本改造、权限复核、故障恢复、日志保留和团队培训。
如果你还在评估远程环境，可以查看 Mac mini 云算力订购方案，按一次真实项目的测试周期准备 macOS、SSH 和 Xcode 条件，而不是在迁移结论出来前就长期采购设备。
当前方案与 Mac 迁移环境的最后取舍
继续依赖受影响的个人 Gemini CLI 认证，缺点已经很明确：请求路径不可用、旧自动化无法直接恢复，而且你无法把 MCP、Hooks 和无头任务的兼容性想当然地带到新工具中。只在本地偶尔测试，又会受到设备不可用、SSH 环境缺失和 Xcode 验收无法闭环的限制。
更稳妥的做法是先用一个真实项目完成一周双轨测试。若现有设备无法持续提供 macOS、远程 SSH 和 Xcode 验证环境，再考虑租用 MACCOME 的 Mac 环境，把配置导入、Agent 修改、构建测试和断线恢复放在同一套可重复的环境里验证。这样做的价值不是绕过迁移，而是把迁移风险限制在可回滚的测试周期内。