Gemini CLI 消费者登录退役带来的迁移提醒

书籍：Prompt Engineering Pocket Guide

我的其他作品：Thinking in Go（两册系列）——Go 编程完整指南 + Go 六边形架构

我的项目：Hermes IDE | GitHub——为使用 Claude Code 和其他 AI 编程工具交付软件的开发者打造的 IDE

关于我：xgabriel.com | GitHub

打开终端，输入 gemini，用 Google 账号登录，然后开始工作。如果你付费订阅了 Google AI Pro 或 Ultra，原本就能这样使用。但从 2026 年 6 月 18 日起，这条路走不通了。

Google 关于 Gemini Code Assist 消费者账号的弃用页面，最后更新于 10 月 9 日，已经把情况说得很清楚：从 2026 年 6 月 18 日起，Gemini Code Assist 的 IDE 扩展不再为 Gemini Code Assist for individuals、Google AI Pro 和 Google AI Ultra 这些档位处理请求。页面还补充说，“你将无法再通过 Login with Google 选项访问 IDE 扩展或 Gemini CLI”，并引导这些用户转向“Antigravity 系列产品”。

这并非毫无预告。Google 在 5 月 19 日提前一个月宣布了这项调整，当时替代产品 Antigravity CLI 已经推出。Standard 和 Enterprise 许可证在 6 月 18 日之后仍可继续访问，不过弃用页面现在表示，这两个档位另有弃用时间表。公告还说，Gemini CLI“仍可通过付费 Gemini 和 Gemini Enterprise Agent Platform API keys 访问”。Gemini CLI 的产品负责人也在 GitHub 帖子中告诉用户，代码仍以 Apache 2.0 许可证托管在 GitHub 上，The Register 引用了这段表述。

Google 在这件事上没有做错什么。但即便是一次正常、提前充分告知的产品决策，仍然迫使所有依附于单个 Agent 的工作流进行迁移。我的看法是：编程 Agent 是技术栈里最容易被替换的部分，你应该从一开始就按它将来会被替换来设计工作流。

哪些能直接沿用，哪些需要动手迁移

最有说服力的证据，就是 Google 自己的迁移指南。你可以把它当成一份清单，看看哪些东西最终具备可移植性。

项目里的 GEMINI.md 和 AGENTS.md 无须修改就能继续使用。指南说，“两个 CLI 平台使用完全相同的工作区上下文规则”，而且 Antigravity CLI 也会读取全局的 ~/.gemini/GEMINI.md。

除此之外，几乎每一项都需要额外处理：

• 扩展需要通过 agy plugin import gemini 转换成 Antigravity plugins。
• 工作区里位于 .gemini/skills/ 的 skills，必须手动移动到 .agents/skills/，才能被识别。
• MCP servers 要迁移到独立的 mcp_config.json 文件中，远程服务器还必须把 url 或 httpUrl 键改名为 serverUrl。
• 某些自定义终端主题和视觉叠加效果可能不受支持。

公告还补充说，“刚推出时不会做到 1:1 的功能对等”。Skills、hooks、subagents 和扩展在发布时就已支持迁移，其余部分 Google 没有作出承诺。

仓库里的纯 Markdown 文件原封不动地挺过了这次切换。那些围绕某个工具的目录结构和配置 schema 构建的部分，则各自需要一道迁移手续，哪怕新 Agent 也出自同一家公司。

Agent 换了，仓库里的文件还在原处。

看看 6 月这次调整，对一位订阅 Pro 的开发者究竟改变了什么。代码没变，测试没变，CI 没变，审查 pull request 的人也没变。变的是在终端里输入的可执行程序，以及它存放附加内容的目录。

除了产品下线，厂商还有很多原因会让你不得不离开某个工具。使用额度就是其中之一，而替代产品同样有额度限制。The Register 报道，Antigravity CLI 的 issue tracker 上有大量帖子，要求 Google 重新审视使用限制；在产品负责人发起的 GitHub 讨论中，也有一些评论者表示，自己只发了很少几次请求，就触及了每周额度上限。能在一天内切换 Agent 的团队，对此耸耸肩就过去了。规则、检查和审查流程都放在某个工具内部的团队，却要花上一周重新搭建这些东西。

公平地说，如果你打算留在 Google 生态里，Antigravity CLI 就是最直接的选择。公告说它用 Go 构建，“更轻快、响应更灵敏”，而 agy plugin import gemini 能替你完成大部分迁移工作。喜欢哪家厂商，就用哪家。只要确保下一次切换，无论换过去还是换回来，都能在一个下午完成。

有三件事，绝不能只存在于某个 Agent 内部：交给它的指令、判断它是否完成任务的标准，以及谁来检查它的工作。

指令应该放在 AGENTS.md 中

AGENTS.md 是仓库根目录下的一个纯 Markdown 文件。其网站表示，它“已被超过 60k 个开源项目使用”，目前由 Linux Foundation 旗下的 Agentic AI Foundation 负责维护。支持它的工具包括 Codex、Gemini CLI、Cursor、GitHub Copilot coding agent、Zed、Warp、Aider、goose 和 opencode。

Claude Code 也会读取它。Claude Code 的 memory 文档说，从 v2.1.277 开始，只要当前工作目录及其上级目录中没有 CLAUDE.md，它就会直接读取 AGENTS.md。OpenAI 的文档则明确说明了 Codex 的行为：“Codex 在开展任何工作之前，都会读取 AGENTS.md 文件”，默认读取的总量上限为 32 KiB。

内容要简短、具体：

# AGENTS.md

## Done means
Run `npm run check`. A task is not done until it exits 0.

## Rules
- Ask before adding a dependency.
- Never edit a migration that is already on main.
- New endpoints get a test in tests/api/.

默认情况下，如果你同时保留了 CLAUDE.md，Claude 就会读取它，而不读取 AGENTS.md。文档给出的解决办法是：在文件顶部导入共享文件，再把仅适用于 Claude 的说明放在下面：

# CLAUDE.md
@AGENTS.md

## Claude Code only
- Notes that only apply to Claude Code go here.

把各家厂商自己的目录（.claude/、.agents/、.codex/）当作适配层。Hooks、skills 和 MCP 配置放在那里，是因为它们必须放在那里。而新同事入职也需要了解的规则，应该放进 AGENTS.md，因为下一个 Agent 同样会读取这个文件。

“完成”是一条命令，审查通过 pull request 进行

Agent 说“所有测试都通过了”，这只是一项声明。退出码才是证据。把完成标准放进一个脚本，让任何 Agent、任何人以及 CI 都用同样的方式执行：

{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "check": "npm run lint && npm run typecheck && npm test"
  }
}

在 Go 或 Python 仓库里，一个 make check target 也能完成同样的工作。然后让 CI 在每个 pull request 上运行完全相同的命令：

# .github/workflows/check.yml
name: check
on: pull_request
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run check

很多 Agent 都自带 hook 系统，可以自动运行检查，而这些 hook 文件恰好就是迁移时需要搬动的工具专属配置。脚本才是始终不用搬的部分。Hooks 可以调用它，CI 会调用它，你也可以在 shell 中调用它。

Agent 可以有很多个，完成标准只需要一个。

同样的道理也适用于审查。如果关于某次修改为何这样实现的唯一记录，是某家厂商应用里的聊天记录，那么应用一旦不用了，这份记录也就跟着丢了。把 Agent 的工作保存在分支和 pull request 中，通过分支保护要求合并前必须通过 check job，并用 CODEOWNERS 文件为敏感路径指定负责人。这些机制都不在乎 diff 是由哪个 Agent 写出来的。

Hermes IDE 在其中扮演什么角色

我是 Hermes IDE 的开发者，阅读这一节时，请把这一点考虑在内。Hermes 是一款桌面应用，它在真正的终端里运行各个 Agent 自己的界面，使用你自己的登录身份。Antigravity CLI 是内置 Agent，与 Claude Code、Codex 并列；README 还列出了 Gemini CLI、GitHub Copilot CLI、OpenCode、goose、Aider 和 Kiro CLI，你也可以添加任意命令行 Agent。对于 Antigravity，模型选择器会实时读取 agy models，因此 Google 为你的账号新增模型后，无须更新 Hermes 就能显示出来。

与本文观点有关的是以下几点：

• 你可以为每个任务选择 Agent、模型、effort 和账号，并把常用组合保存为预设。每个 Agent 都支持配置多个账号。
• 一个 Agent 达到使用额度上限后，你可以换另一个继续完成任务。
• 每个任务都有自己的 hermes/<name> 分支和 git worktree，因此在同一张工单上尝试第二个 Agent，成本就是多建一个分支。
• .hermes/worktree.toml 中的 worktree recipe 接受一个 done_when 列表，用来定义任务的默认检查项。把它指向 npm run check，每个任务的默认检查就会与 CI 运行同一个脚本。
• 从 2.2.9 开始，New folder… 命令可以在创建项目时，直接放好一个 AGENTS.md 文件。

按同样的道理，也别让工作流只存在于 Hermes 内部。分支就是普通的 git 分支，检查用的是你自己的脚本，因此即使你不再使用 Hermes，两者仍能照常工作。Recipe 是仓库里的纯文本文件，即便换了工具，它也依然记录着“完成”的标准。

Hermes 免费，采用 BSL 1.1 许可证开放源码，可在 macOS、Windows 和 Linux 上运行。它不能替代你的 Agent 订阅，也与 Google、Anthropic、OpenAI 或 Nous Research 没有隶属关系。

检验一下你的工作环境

选出你最常用的 Agent，想象它下个月突然无法登录，就像 6 月份 Pro 和 Ultra 账号无法再登录 Gemini CLI 那样。你需要多久才能换用另一个 Agent，重新开始交付？如果答案是“一个下午”，说明你的规则、检查和审查流程已经放在仓库里了。如果答案是“一周”，你就知道该先写哪些文件了。

你现在的工作环境里，还有什么东西只存在于某个 Agent 内部？欢迎在评论区告诉我。

如果你使用不止一个 Agent，可以下载 Hermes IDE，让其中两个 Agent 在不同分支上处理同一个任务，然后分别运行你的 npm run check。如果它值得留在你的工作环境中，请到 GitHub 给它点个 star；这能帮助其他混用多个 Agent 的开发者发现它。一旦规则放进 AGENTS.md，这个文件就会成为每个 Agent 首先读取的内容，因此，里面的措辞比你运行哪个可执行程序更重要。Prompt Engineering Pocket Guide 介绍了如何编写这类指令：包括 system prompts、CLAUDE.md 和 AGENTS.md 文件，以及在模型开始工作前，该给它多少上下文。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。