前两天才聊完 Kimi 把用 Python 写的 kimi-cli 推倒重来，换成了 TypeScript 版的 kimi-code。当时我顺手抛了个观察：终端编程 Agent 的语言栈，似乎正在朝 TypeScript + Node 这一系收敛。
结果这周谷歌就甩出了一个完全相反方向的动作。
5 月 20 日凌晨，Gemini CLI 官方推特挂出公告：Gemini CLI 这条产品线不再单独迭代了，接下来谷歌会把精力收拢到一个叫 Antigravity 的新平台上，其中面向终端的工具叫 Antigravity CLI，用 Go 重写。
Kimi 那边刚押注 TS + Node，谷歌这边直接把自家原本 TS + Node 写的 Gemini CLI 换成了 Go。两家公司隔着一周给同一个问题打出了几乎相反的答案。
这次公告到底说了什么
公告本身不长，但信息量挺密。可以拆成三层来看：
• 品牌层面：Gemini CLI 这个产品线被并入 Antigravity 平台，Antigravity CLI 成为新的终端入口 • 技术层面：Antigravity CLI 从头用 Go 写，官方对它的形容是「snappier and more responsive」 • 产品层面：Antigravity 不止 CLI，还包括 Antigravity 2.0 桌面应用，公告挂图里另外列出了 Antigravity SDK 和 Antigravity IDE 两条线
谷歌给出的理由是，2025 年那一波只让你跟一个模型对话的工具，已经满足不了当下「多个 Agent 互相协作拆解任务」的工作流，所以与其分散维护多个产品，不如把所有力气押到一个统一平台里。
把 Gemini CLI 推倒重写，代价不小
值得多说一句的是，被换掉的不是一个边角项目。
Gemini CLI 在 GitHub 上是 105k star 量级的开源项目，仓库的语言占比里 TypeScript 接近 98%，对外通过 npm 分发，包名叫 @google/gemini-cli。它是一个标准的、活得很好的 Node CLI。
把这种体量的 TypeScript 工程整个推倒，换成 Go 重写一遍，工作量肯定不小。谷歌愿意付这个代价，本身就是个信号：他们认为新栈带来的体验差，值得这次重新造轮子。
30 天搬家窗口，谁要动谁不用动
公告里把现有用户分成了三类，迁移规则也写得很明白：
• Google AI Pro / Ultra 用户：30 天迁移窗口，6 月 18 日之后 Gemini CLI 不再为他们提供服务 • 个人版 Gemini Code Assist 用户：同上时间表，一个月内需要切到 Antigravity CLI • 企业用户和付费 API Key 用户：不用动，Gemini CLI 通过付费的 Gemini 与 Gemini Enterprise Agent Platform API Key 继续可用，还能用最新的 Gemini 模型
也就是说，对绝大多数用 Google AI Pro / Ultra 或者免费 Gemini Code Assist 接入 Gemini CLI 的开发者来说，5 月 19 日（美西时间）到 6 月 18 日，就是一段强制搬家窗口。GitHub 仓库这一波也会停止接收新的安装请求，老用户的工作流由谷歌帮忙迁。
为什么是 Go
公告里给的官方理由只有一句话「Built in Go」加一句形容词「snappier and more responsive」，没有给出启动耗时或内存占用的对比数字。这一段其实是整份公告最薄的地方。
但反过来看，Node CLI 的痛点也都不是秘密：
• 冷启动慢：Node + npm 全局包，进程拉起来动辄几百毫秒 • 依赖膨胀：node_modules 一装就是几百兆，CLI 升级时尤其难受 • 分发笨重：用户机器上要预装 Node，跨版本兼容是长期负担
Kimi 这次走的是同一组痛点，但解法不同。它仍然用 TypeScript 写，通过 SEA（Single Executable Application）把整个工具打成一个单文件二进制，对用户来说就像装一个原生命令行软件，不需要预装 Node，也不会和全局包打架。
谷歌选的路更激进，直接换语言，从源头规避运行时和依赖问题。从产物的角度看，Go 编出来的二进制和 Node SEA 打出来的二进制，对最终用户其实差别不大，都是一条 curl ... | bash 装完就能用。但对维护团队来说，是两套完全不同的开发体验和招人门槛。
Antigravity 是个更大的盘子
Antigravity 这个名字之前已经露过头，这次是把它推到主角位置。公告里能看出来的主线有这么几条：
• 统一的 Agent harness：Antigravity CLI 和 Antigravity 2.0 桌面应用共用同一套底层 Agent 框架 • 异步工作流：支持大规模重构或者长时间研究类的任务在后台跑，不会把终端锁死 • 保留旧能力：Agent Skills、Hooks、Subagents、Extensions 这些 Gemini CLI 时代的概念继续在用，其中 Extensions 改叫 plugins
从产品视角看，谷歌这一手等于承认了一件事：开发者要的早就不是「在终端里跟一个模型聊天」，而是一个能让多个 Agent 协作、能跑长任务、能把终端和桌面统一起来的工作台。Antigravity 是这个工作台的品牌名，Gemini CLI 只是被合并进去的其中一块。
想立刻试试可以怎么装
Antigravity CLI 的官方仓库已经挂出来了，地址是 github.com/google-antigravity/antigravity-cli，目前 600 多 star，还在早期阶段。装完进去长这样，命令名直接简化成了 agy，启动界面挂着一个像素风的彩虹 logo，默认接的是 Gemini 3.5 Flash：
安装方式跟 Kimi 那边非常像，一条命令搞定：
macOS 和 Linux：
curl -fsSL https://antigravity.google/cli/install.sh | bash
Windows PowerShell：
irm https://antigravity.google/cli/install.ps1 | iex
更多产品入口、迁移文档和企业版说明在 antigravity.google 这个主站上，下载页是 antigravity.google/download。
有意思的是，这一组安装命令跟 Kimi 那边的写法几乎是一个模子刻出来的：用一条 curl 把官方脚本拉下来跑，跑完就是一个本地的单文件可执行程序。语言选型不一样，最终给用户的安装体验反而越来越像。
跟 Kimi 那次重写并排看
把两件事摆在一起看，画面就比较有意思：
Kimi 是从 Python 这头朝 Node 走了一步，谷歌是从 Node 那头朝 Go 又走了一步。两个团队对「上一代 CLI 哪里不好」的判断高度一致，但对「下一代 CLI 该用什么写」的判断完全相反。
之前看 Claude Code 选 Bun、Kimi 选 Node、Gemini 选 Node，一度让我觉得这条赛道的语言生态正在收敛到 TypeScript 这一系。谷歌这一手直接把这个判断打散了。终端 Agent 的语言选型仍然是开放命题，远没有所谓「正确答案」。
留给开发者的现实问题反而很简单。手上还在用免费版 Gemini CLI 的，30 天后必须迁到 Antigravity CLI；用付费 API Key 接的，可以再观望一阵；至于自己团队还在选 AI Agent CLI 技术栈的，看着两家方向完全相反的选择，恐怕得回去重新算一遍自己这盘账。
