# Gemini CLI 还能用吗？个人账号停服范围与迁移指南

> Gemini CLI 并非所有路径都已关闭。本文说明 2026 年 6 月 18 日停止服务的个人账号范围、仍受支持的企业与 API key 路径，以及迁移到 Antigravity CLI 时需要保存和验证的配置。

- Source: https://www.aifreeapi.com/zh/posts/gemini-cli-deprecated
- Language: zh
- Published: 2026-08-27
- Updated: 2026-08-27
- Publisher: AI Free API (https://www.aifreeapi.com)

最容易误判的地方，是把“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 的[个人账号弃用页](https://developers.google.com/gemini-code-assist/docs/deprecations/code-assist-individuals)已经明确写出，受影响的是 Gemini Code Assist for individuals、Google AI Pro、Google AI Ultra，以及对应的 `Login with Google`。同一页面也明确排除了 Standard 和 Enterprise 订阅。

这也解释了为什么两个人可能得到完全不同的结果：个人用户运行同一个 `gemini` 命令时无法继续请求，企业同事却仍能工作。二者并不矛盾，区别在后端授权路径，不在本地命令名称。

## 为什么“还能安装”不代表“个人账号还能用”

Gemini CLI 的 GitHub 仓库与 npm 包没有随个人账号入口一起消失。开源代码是否存在、本地二进制能否启动、某种账号能否从服务端获得响应，是三个不同问题。

当前仓库的通用 README 甚至仍然介绍个人账号免费额度和 Google 登录。这与后来更新、范围更具体的弃用页发生了明显冲突。遇到这种情况，应优先采用日期更晚、专门说明本次变更的官方页面，而不是从旧的通用安装说明推断服务状态。

Google 的[迁移公告](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/)还说明，仓库会继续以 Apache 2.0 许可证开放，并继续服务企业客户。这就是“项目仍在维护”和“个人 Google 登录已停止”可以同时成立的原因。

如果你的 CLI 仍能打开，不要只看启动画面。至少确认以下信息：

1. 当前使用的是 `Login with Google`、组织授权、Google Cloud，还是环境变量中的 API key。
2. 实际请求是否成功，而不只是交互界面成功启动。
3. 成功请求是否来自你预期的项目和计费主体。
4. 自动化脚本是否明确设置了认证方式，而不是依赖旧会话缓存。

## 个人用户的官方后继是 Antigravity CLI

对受影响的个人账号，Google 给出的迁移目标是 **Antigravity CLI**。它不是简单把 `gemini` 命令改名，而是与 Antigravity 2.0 共用 agent harness 的新终端产品。Google 表示它保留了 Agent Skills、Hooks、Subagents 等核心能力，但也明确承认刚推出时并非 1:1 功能对等。

因此，合理的迁移目标不是“安装成功”，而是“我的关键工作流在新路径上可验证地继续工作”。

当前[官方下载页](https://antigravity.google/download)提供 macOS、Linux 与 Windows 的安装命令。例如 macOS 和 Linux 当前显示：

```bash
curl -fsSL https://antigravity.google/cli/install.sh | bash
```

这是直接下载并执行远程脚本的方式。使用前应先打开官方页面确认命令仍是最新版；在公司设备或受管环境中，还应先检查脚本内容与组织的软件安装政策。不要从旧教程复制长期保存的安装命令。

安装完成后的主命令是：

```bash
agy
```

首次启动时，如果系统中存在旧 Gemini CLI 配置，Antigravity CLI 会尝试检测已有 profile，并让你选择要迁移的内容。不要因为有自动检测就跳过备份：自动迁移能降低工作量，但不能替你判断哪些自定义项最重要，也不能证明实验主题、终端显示或所有扩展都完全兼容。

## 迁移前先保存什么

![Gemini CLI 迁移到 Antigravity CLI 的备份、安装、skills 与 MCP 配置变化及验证清单](https://www.aifreeapi.com/posts/zh/gemini-cli-deprecated/img/migration-config-checklist.webp)

在运行新工具或修改目录前，先记录旧环境。重点不是复制整个主目录，而是知道哪些内容驱动了你的真实工作流：

- `GEMINI.md` 与项目级规则文件；
- 全局及项目级 skills；
- MCP server 定义与所需环境变量名称；
- 自定义 commands、extensions、hooks 与 agents；
- headless 脚本使用的参数、输出格式和退出码处理；
- 重要项目的对话、检查点或可复用提示；
- 组织级代理、证书、权限与审计要求。

备份时不要把 API key、访问令牌或内部服务器凭证写进公开文档、截图、工单或仓库。配置结构可以保存，秘密值应继续留在安全的密钥存储中。

建议先把当前能力做成一份短清单。例如：能否读取工作区规则、能否列出 MCP 工具、能否用一个无副作用的提示完成响应、能否在需要确认时阻止文件修改。迁移完成后再用同一组安全任务验证，而不是凭“界面看起来差不多”判断成功。

## 不是所有配置路径都会原样保留

Google 的[官方迁移文档](https://antigravity.google/docs/cli/gcli-migration)列出了几处会直接影响结果的变化。

### 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。当前文档提供了显式导入命令：

```bash
agy 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` 也会被读取。这是兼容性的好消息，但仍需确认项目实际启动目录与规则作用域。工具能解析文件，不等于你的每条旧命令、权限策略和自定义扩展都无差别运行。

## 一次更稳妥的迁移流程

![从认证路径判断到备份、安装、处理配置差异和验证关键工作流的 Gemini CLI 迁移路线图](https://www.aifreeapi.com/posts/zh/gemini-cli-deprecated/img/migration-validation-route-map.webp)

可以把迁移分成可回退的小步骤：

1. **确认受影响路径。** 记录当前是个人 Google 登录还是企业、Cloud、API key，避免为未受影响的环境制造变更。
2. **冻结一个可用基线。** 记录 Gemini CLI 版本、关键命令、MCP 列表与安全验证任务，不记录秘密值。
3. **备份配置。** 保存规则、skills、扩展清单、MCP schema 与必要的非敏感会话资料。
4. **从当前官方页面安装。** 不使用无法追溯来源的二进制、代理或复用他人 OAuth 的第三方工具。
5. **运行首次导入。** 阅读每一个被导入或跳过的项目，不把“完成”当成“完全兼容”。
6. **处理显式路径差异。** 核对 `.agents/skills/`、`mcp_config.json` 与 `serverUrl`。
7. **先做无副作用验证。** 测试规则读取、MCP 列表、模型响应、权限询问和结构化输出，再允许修改文件或执行部署任务。
8. **并行保留旧环境一段时间。** 在确认关键自动化、退出码、输出解析和组织审计都正常前，不急于删除备份。

迁移中最危险的做法，是为了保留原有免费额度去复用第三方 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，则先核实当前支持与组织计划，不要把个人停服误当成强制切换通知。无论走哪条路线，都用一次真实但无副作用的工作流验证结果；能安装、能启动和能可靠完成任务，从来不是同一个成功条件。