Gemini CLI 深度评测：免费额度、1M 上下文与终端 Agent 实战

一句话结论

Gemini CLI 是 Google 官方开源的终端 AI Agent，把 Gemini 模型、文件读写、shell、web fetch、Google Search grounding 和 MCP 收进一个命令行程序里。它最实在的两个卖点是免费额度和上下文窗口：用个人 Google 账号登录即可获得官方 README 标注的 60 requests/min、1,000 requests/day，官方同时标注 1M token 上下文窗口 —— 这两项合起来意味着「零成本、大上下文地把一个中小代码库喂进去问问题」这件事，目前在终端 Agent 里它是门槛最低的选择。

但门槛低不等于能当主力。截至 2026-10-07，它的 GitHub 仓库已有 107,242 Star、14,704 Fork，活跃度没有问题（当日仍有推送）；真正需要心理准备的是产品打磨程度：长任务执行链路会漂移，跨 30 分钟以上的多文件重构不如 Claude Code 稳。

本文基于官方 README、官方 Releases 页与官方文档逐项核对整理，非厂商付费内容；未做长期一手实测，功能、版本与额度以官方实时页面为准。

Gemini CLI 到底是什么

一句话：终端里的 Gemini。你在项目根目录敲 gemini，它就地读文件、跑命令、改代码、联网查资料，并把每一步的 diff 摆给你看。这跟 Cursor 那种「IDE 内嵌 AI」是两条路：Gemini CLI 没有图形界面，靠终端 + 文本 diff 完成闭环，天然适合 SSH 到服务器、在 CI 里跑、或者脚本化批量处理。

它同时是 Google 开源项目的一部分：Apache-2.0 许可，仓库 2025-04-17 建立，主分支持续有人提交。开源这件事对它不只是姿态 —— headless 模式（gemini -p "..."）让它能直接嵌进流水线，这是闭源同类工具不方便做的。

核心能力拆解

免费额度：三条认证通道，额度和能力边界都不同

这是最容易被讲错的部分。官方 README 把认证分成三条路，各自的免费额度口径并不相同：

• 个人 Google 账号 OAuth：60 requests/min、1,000 requests/day，不需要管理 API Key，模型自动更新。官方把它推荐给「个人开发者以及持有 Gemini Code Assist License 的人」。注意这是身份绑定的额度。
• Gemini API Key：官方 README 写的是 1,000 requests/day with Gemini 3（flash 与 pro 混合），换来的是模型选择自由与按量计费升级通道。适合自动化脚本。
• Vertex AI：走 GCP 配额与 IAM，面向生产与合规场景。

也就是说，「1,000 次/天」在两条通道上都出现，但能力池不同：OAuth 通道是自动跟随最新模型、你无法指定；API Key 通道能指定模型但额度消耗口径按具体模型算。选错通道，后面会遇到「额度还有、但想用的模型不能用」这类问题。

1M token 上下文

官方 README 在「Why Gemini CLI?」里明确写的是 1M token context window。这个量级意味着一个中型前端仓库可以整体塞进去做「跨文件重构可行性判断」或「架构梳理」，而不必先做检索裁剪。代价是长上下文下的注意力衰减仍然存在 —— 大上下文擅长「找得到」，不擅长「改得准」，改动密集的任务仍建议缩小范围。

内置工具与 Google Search grounding

开箱即带四类工具：Google Search grounding、文件操作、shell 命令、web fetch。其中 Google Search grounding 是它相对 Claude Code / Codex 最实用的差异点 —— 问「某个库的最新版本与破坏性变更」时，它能直接联网取证而不是靠训练数据嘴硬。对需要频繁核对版本与定价的工程任务，这一项能省掉大量人工二次核实。

MCP 与可扩展性

支持 Model Context Protocol，可在配置里挂 MCP server，把 GitHub、数据库、内部 API 接进来。这里有个实测过的坑：在「未受信任的工作区」里，MCP server 定义出于安全考虑不会被加载 —— clone 完仓库立刻进目录开工，会发现 MCP 工具「消失」，换到受信任目录即可。

headless 脚本模式

gemini -p "解释这个代码库" 直接输出结果，可配合 --output-format json 做结构化处理。这让它成为少数能真正嵌进 shell 管道的 Agent —— 定时扫 issue、批量给 PR 生成摘要、给遗留模块生成架构说明，都可以脚本化。

版本通道现状（2026-10）

这条通道拆得很细，选版要看通道而不是看数字大小：

注意 preview 的发布时间早于 stable 12 分钟，nightly 的数字更大 —— 按数字排序会看错谁是当前稳定版。v0.63.0 这一版的主线是工程健壮性而非新功能：工具输出上限与内存生命周期管理、状态原子写与损坏恢复、文件工具串行化与原子写、认证死循环修复，以及区分「MCP 未启用」与「MCP 配置 JSON 畸形」这两种此前混在一起的报错。

免费额度与计费方式

外加一份不在官方 README 里、但决定了「能不能用」的隐性成本：网络。三条通道都要访问 Google 服务，国内网络条件下认证流程会反复失败，这部分成本无法用额度表体现。

它适合谁 / 不适合谁

适合

• 想以零成本体验终端 Coding Agent 的个人开发者 —— 免费额度是同类里最大的
• 需要在 CI / 脚本里跑「非交互式」批量分析的团队（headless + JSON 输出）
• 经常要核对库版本、协议变更、定价的工程任务（Google Search grounding）
• 需要 1M 上下文做代码库整体理解与架构梳理

不适合

• 纯内网、不能稳定访问 Google 服务的团队 —— 直接不可用
• 把 30 分钟以上的多文件重构当日常主业的团队 —— 稳定性不足
• 强依赖中文界面与本地化文档的用户

与 Claude Code / Codex 的差异

一句话：要免费额度与联网取证，选 Gemini CLI；要长任务一次做对，选 Claude Code。

局限与注意点

• 额度是「随时可调」的口径，不是承诺。官方 README 写明额度，但没承诺下限；跑批任务前先小样试跑，别把 quota 当 SLA。
• 别把大上下文当「不用拆任务」的理由。1M 能装下整个仓库，但不代表它能一次改对；改动密集的任务仍需缩小 diff 范围。
• 版本通道要按通道看，不要按数字大小选；生产环境固定 stable 并 pin 版本。
• 未受信任工作区不加载 MCP 是设计行为不是 bug，遇到「工具消失」先看工作区信任状态。

AI 之家 观点

终端 Agent 这条线，2026 年的竞争已经不在「谁的模型更强」，而在「谁能让开发者低成本地把它用起来」。Claude Code 和 Codex 走的是「把稳定性与工具体验做到极致、然后收订阅费」；Gemini CLI 走的是反向路线 —— 把免费额度和上下文窗口拉到最高，用开源和 headless 换取嵌入流水线的能力。

对国内开发者，我们的判断很直接：如果网络条件允许，Gemini CLI 是当下性价比最高的「第二意见工具」 —— 主力仍交给 Claude Code / Codex，遇到「查最新版本」「读大仓库」「批量脚本化分析」这类任务转给它，免费额度基本够用。反之，如果网络不稳，它的所有优势都会被认证失败抵消，别硬上。

相关阅读

• Gemini CLI 工具卡 · Claude Code 深度评测
• Claude Code vs Gemini CLI 对比 · Codex vs Gemini CLI 对比
• 终端 Agent 技术栈搭建方案

来源

• Gemini CLI 官方 README（Apache-2.0；免费额度、1M 上下文、内置工具、三条认证通道口径）（2026-10-07 访问）
• Gemini CLI Releases（v0.63.0 stable，2026-10-06T20:38:49Z）（2026-10-07 访问）
• Gemini CLI 官方文档站（2026-10-07 访问）
• GitHub API：仓库元信息（107,242 Star / 14,704 Fork / Apache-2.0 / 2026-10-07 仍有推送）（2026-10-07 访问）