最容易误判的地方，是把“Gemini CLI 已弃用”理解成整个项目、所有账号和所有认证方式同时消失。Google 的正式表述更窄也更重要：从 2026 年 6 月 18 日起，Gemini CLI 不再为个人免费账号、Google AI Pro 和 Google AI Ultra 账号提供请求服务，Login with Google 这条个人登录路径也不能再用于 Gemini CLI。
但这不等于所有 Gemini CLI 使用方式都已经关闭。Google 同时明确保留了 Gemini Code Assist Standard 或 Enterprise、Google Cloud，以及 API key 认证的访问。开源仓库也仍然存在。换句话说，你现在该做的第一件事不是卸载，而是确认自己到底通过哪条路径在用。
先判断：你属于哪一种情况
| 你原来的使用方式 | 2026 年 6 月 18 日后的状态 | 更合适的下一步 |
|---|---|---|
| 个人 Google 账号免费使用 | Gemini CLI 不再提供请求服务 | 迁移到 Antigravity CLI |
| Google AI Pro 或 Ultra 账号登录 | Gemini CLI 不再提供请求服务 | 迁移到 Antigravity CLI |
| Gemini Code Assist Standard / Enterprise | 官方说明访问不变 | 先按组织配置继续使用，再评估迁移 |
| 通过 Google Cloud 使用 | 不属于个人账号停服范围 | 保留现有企业路径，按组织计划升级 |
| 使用 Gemini API key 或企业 Agent Platform API key | 官方说明仍可访问 | 不要因为个人入口停服就被迫迁移 |
| 只看到 npm 包或 GitHub 仓库还能打开 | 只能证明软件和源码仍存在 | 继续检查实际认证方式，不能据此判断账号可用 |
Google 的个人账号弃用页已经明确写出，受影响的是 Gemini Code Assist for individuals、Google AI Pro、Google AI Ultra，以及对应的 Login with Google。同一页面也明确排除了 Standard 和 Enterprise 订阅。
这也解释了为什么两个人可能得到完全不同的结果：个人用户运行同一个 gemini 命令时无法继续请求，企业同事却仍能工作。二者并不矛盾，区别在后端授权路径，不在本地命令名称。
为什么“还能安装”不代表“个人账号还能用”
Gemini CLI 的 GitHub 仓库与 npm 包没有随个人账号入口一起消失。开源代码是否存在、本地二进制能否启动、某种账号能否从服务端获得响应，是三个不同问题。
当前仓库的通用 README 甚至仍然介绍个人账号免费额度和 Google 登录。这与后来更新、范围更具体的弃用页发生了明显冲突。遇到这种情况，应优先采用日期更晚、专门说明本次变更的官方页面，而不是从旧的通用安装说明推断服务状态。
Google 的迁移公告还说明，仓库会继续以 Apache 2.0 许可证开放，并继续服务企业客户。这就是“项目仍在维护”和“个人 Google 登录已停止”可以同时成立的原因。
如果你的 CLI 仍能打开，不要只看启动画面。至少确认以下信息：
- 当前使用的是
Login with Google、组织授权、Google Cloud，还是环境变量中的 API key。 - 实际请求是否成功，而不只是交互界面成功启动。
- 成功请求是否来自你预期的项目和计费主体。
- 自动化脚本是否明确设置了认证方式，而不是依赖旧会话缓存。
个人用户的官方后继是 Antigravity CLI
对受影响的个人账号，Google 给出的迁移目标是 Antigravity CLI。它不是简单把 gemini 命令改名，而是与 Antigravity 2.0 共用 agent harness 的新终端产品。Google 表示它保留了 Agent Skills、Hooks、Subagents 等核心能力，但也明确承认刚推出时并非 1:1 功能对等。
因此，合理的迁移目标不是“安装成功”，而是“我的关键工作流在新路径上可验证地继续工作”。
当前官方下载页提供 macOS、Linux 与 Windows 的安装命令。例如 macOS 和 Linux 当前显示：
bashcurl -fsSL https://antigravity.google/cli/install.sh | bash
这是直接下载并执行远程脚本的方式。使用前应先打开官方页面确认命令仍是最新版；在公司设备或受管环境中，还应先检查脚本内容与组织的软件安装政策。不要从旧教程复制长期保存的安装命令。
安装完成后的主命令是：
bashagy
首次启动时，如果系统中存在旧 Gemini CLI 配置，Antigravity CLI 会尝试检测已有 profile，并让你选择要迁移的内容。不要因为有自动检测就跳过备份：自动迁移能降低工作量，但不能替你判断哪些自定义项最重要，也不能证明实验主题、终端显示或所有扩展都完全兼容。
迁移前先保存什么
在运行新工具或修改目录前，先记录旧环境。重点不是复制整个主目录，而是知道哪些内容驱动了你的真实工作流：
GEMINI.md与项目级规则文件；- 全局及项目级 skills；
- MCP server 定义与所需环境变量名称；
- 自定义 commands、extensions、hooks 与 agents；
- headless 脚本使用的参数、输出格式和退出码处理；
- 重要项目的对话、检查点或可复用提示；
- 组织级代理、证书、权限与审计要求。
备份时不要把 API key、访问令牌或内部服务器凭证写进公开文档、截图、工单或仓库。配置结构可以保存，秘密值应继续留在安全的密钥存储中。
建议先把当前能力做成一份短清单。例如：能否读取工作区规则、能否列出 MCP 工具、能否用一个无副作用的提示完成响应、能否在需要确认时阻止文件修改。迁移完成后再用同一组安全任务验证，而不是凭“界面看起来差不多”判断成功。
不是所有配置路径都会原样保留
Google 的官方迁移文档列出了几处会直接影响结果的变化。
Skills 目录发生变化
项目内 skills 从 Gemini CLI 的：
text.gemini/skills/
迁移到 Antigravity CLI 使用的：
text.agents/skills/
全局 skills 则从 ~/.gemini/skills/ 移到 ~/.gemini/antigravity-cli/skills/。如果项目依赖自定义 skill，却只确认了安装成功，没有检查新目录是否被识别，后续命令会表现得像“能力突然消失”。
Extensions 变成 plugins
Antigravity CLI 把旧扩展转换为 plugins。当前文档提供了显式导入命令：
bashagy plugin import gemini
执行后不要只看整体成功消息。逐项核对输出中哪些 skills、agents、commands 与 MCP servers 被处理，哪些显示 skipped。skipped 可能只是原配置没有该内容，也可能意味着你依赖的文件不在工具扫描的位置。
MCP 配置结构改变
Gemini CLI 常把 MCP servers 写在 ~/.gemini/settings.json。Antigravity CLI 使用独立配置文件：
text~/.gemini/config/mcp_config.json .agents/mcp_config.json
远程 WebSocket 或 SSE server 的地址字段也统一为 serverUrl，旧配置中的 url 或 httpUrl 需要更新。迁移后如果只出现 MCP 连接失败，而普通对话正常，优先检查配置文件位置、地址字段和环境变量是否正确传入，不要先把问题归因于模型。
规则文件兼容，但仍要验证范围
官方文档说 GEMINI.md 和 AGENTS.md 的工作区规则继续受支持，全局 ~/.gemini/GEMINI.md 也会被读取。这是兼容性的好消息，但仍需确认项目实际启动目录与规则作用域。工具能解析文件，不等于你的每条旧命令、权限策略和自定义扩展都无差别运行。
一次更稳妥的迁移流程
可以把迁移分成可回退的小步骤：
- 确认受影响路径。 记录当前是个人 Google 登录还是企业、Cloud、API key，避免为未受影响的环境制造变更。
- 冻结一个可用基线。 记录 Gemini CLI 版本、关键命令、MCP 列表与安全验证任务，不记录秘密值。
- 备份配置。 保存规则、skills、扩展清单、MCP schema 与必要的非敏感会话资料。
- 从当前官方页面安装。 不使用无法追溯来源的二进制、代理或复用他人 OAuth 的第三方工具。
- 运行首次导入。 阅读每一个被导入或跳过的项目，不把“完成”当成“完全兼容”。
- 处理显式路径差异。 核对
.agents/skills/、mcp_config.json与serverUrl。 - 先做无副作用验证。 测试规则读取、MCP 列表、模型响应、权限询问和结构化输出，再允许修改文件或执行部署任务。
- 并行保留旧环境一段时间。 在确认关键自动化、退出码、输出解析和组织审计都正常前，不急于删除备份。
迁移中最危险的做法，是为了保留原有免费额度去复用第三方 OAuth、代理个人登录或绕过服务限制。Google 已明确把这类访问方式与正常 API key/Cloud 路径区分开。需要程序化调用时，应使用自己有权使用的 API key 或组织提供的 Google Cloud 认证，而不是把旧产品登录当通用凭证。
常见现象如何定位
CLI 可以启动，但请求立即失败
先查认证方式。如果是个人 Login with Google，这通常符合官方停服范围；升级旧 CLI 不会恢复已停止的服务路径。需要迁移到 Antigravity CLI，或在你确实拥有相应权限时改用 API key/企业路径。
安装页面和 README 仍写着免费个人账号
把它视为通用文档未及时收口，不要据此认定个人服务恢复。更具体、日期更晚的弃用页和 6 月 18 日团队公告才是当前判断依据。
Antigravity 启动正常，但 skills 不见了
检查项目目录是否仍停留在 .gemini/skills/。当前文档要求项目级 skills 位于 .agents/skills/，全局路径也发生变化。
普通对话正常，MCP 全部失败
检查配置是否已拆到 mcp_config.json，远程地址字段是否改成 serverUrl，以及运行进程能否读取所需环境变量。不要在排障日志中粘贴完整令牌。
企业环境仍能使用 Gemini CLI
这不是异常。Google 明确说 Standard/Enterprise、Google Cloud 与 API key 不受个人账号停服影响。是否迁移应由组织的支持周期、合规和功能需求决定，而不是跟随个人用户的时间表。
最终判断
Gemini CLI 的确发生了重大弃用，但准确说法是：个人免费、Google AI Pro 和 Ultra 的 Gemini CLI 请求路径已经停止，Google 把这些用户迁移到 Antigravity CLI；企业、Cloud 与 API key 路径并未被同一公告一并关闭。
如果你是个人 Google 登录用户，继续反复升级 Gemini CLI 不能恢复已结束的后端服务，应该保存配置并迁移。如果你使用企业授权或 API key，则先核实当前支持与组织计划，不要把个人停服误当成强制切换通知。无论走哪条路线，都用一次真实但无副作用的工作流验证结果；能安装、能启动和能可靠完成任务，从来不是同一个成功条件。
