---
title: "Gemini CLI 是什么"
description: "从定位理解 Gemini CLI：它是终端里的 Google 系 AI coding agent，不是普通聊天框，也不只是 Gemini Code Assist 的命令行壳。"
verifiedAt: "2026-05-09"
---

Gemini CLI 可以先理解成一句话：**运行在终端里的 Google 系 AI coding agent（AI 编程代理）**。它能读项目、调用工具、执行命令、修改文件、接 MCP（Model Context Protocol，模型上下文协议）、进入 CI，也能和 Gemini Code Assist、Google Cloud、GitHub Action 这些入口连起来。

它不是普通聊天框。普通聊天框主要靠你复制粘贴上下文；Gemini CLI 直接站在项目目录里，能通过工具读文件、查上下文、执行命令，并根据结果继续下一步。

> [!NOTE]
> 这一篇先解决定位：Gemini CLI 的核心不是"又一个 Gemini 聊天入口"，而是一个能站在项目目录里工作的终端 agent。

> [!TIP]
> **它的运行环境是 Node.js**（≥ 20）。如果你本机连 Node 都还没装，第一步先装 Node 而不是装 Gemini CLI；或者用浏览器进 [Google Cloud Shell](https://cloud.google.com/shell)（已预装 Gemini CLI）跳过本机环境问题。详见 [安装篇](/docs/gemini-cli/official/00-getting-started/01-installation)。

## 它解决什么问题

Gemini CLI 最适合解决三类问题：

- 在本地项目里理解代码、解释结构、定位错误。
- 在终端里执行可验证的开发任务，比如改文档、生成测试、跑检查。
- 把 AI coding agent 接进自动化流程，比如 headless script、GitHub Action、issue triage。

如果任务需要大量 Google 生态能力，例如 Gemini 模型、Gemini Code Assist、Vertex AI、Google Cloud 项目、GitHub 自动化，Gemini CLI 的位置会更自然。

## 它不解决什么问题

| 误解 | 更准确的理解 |
| --- | --- |
| Gemini CLI 会自动接管项目 | 它需要上下文、权限、工具确认和验证边界 |
| Gemini CLI 只是 Gemini Code Assist 的命令行壳 | 它有独立的终端、工具、MCP、headless 和 GitHub Action 使用面 |
| 装上以后就能进 CI | CI 还要处理认证、非交互输入、权限、退出码和配额 |
| 模型强就能少写规则 | 项目规则、`GEMINI.md`、ignore、sandbox 仍然决定可控性 |

## 和 Gemini Code Assist 的关系

Gemini Code Assist 是更大的产品体系，覆盖 IDE extension、agent mode、Cloud Shell、企业控制台、配额和隐私策略。Gemini CLI 是其中面向终端和自动化的一条入口。

可以这样分：

```text
Gemini Code Assist    产品和账号体系
Gemini CLI            终端 agent 和自动化入口
Gemini API Key        API 认证入口
Vertex AI             企业和云项目入口
```

## 它怎么工作

大多数任务可以看成一个循环：

```text
读上下文 -> 形成计划 -> 调用工具 -> 观察结果 -> 调整下一步 -> 输出或继续执行
```

这个循环的质量取决于三件事：

- 你给的任务边界是否清楚。
- 项目里的 `GEMINI.md`、配置和忽略规则是否可靠。
- 工具权限、sandbox、checkpoint、人工确认是否设置正确。

## 什么时候优先选 Gemini CLI

优先选 Gemini CLI 的场景：

- 任务天然发生在终端，比如读日志、跑测试、改文档、检查仓库状态。
- 你希望把同一套能力放进本地、远程服务器、Cloud Shell 或 GitHub Action。
- 团队已经在 Google Cloud、Vertex AI 或 Gemini Code Assist 体系里。
- 你需要把 Web、Shell、MCP、文件系统和 CI 串成一个可复查流程。

不优先选的场景：

- 主要需求是 IDE 补全和鼠标式局部编辑。
- 团队完全不想接 Google 账号、API key 或 Cloud 项目。
- 任务没有可验证输出，只是泛泛聊天或头脑风暴。

## 不要怎么用

不要把 Gemini CLI 当成“自动接管项目”的按钮。它能执行命令，也就能造成副作用。第一次进入陌生项目时，应该先让它只读解释结构，再让它提出计划，最后才给写权限或执行命令。

## 读完要能做什么

读完这一篇，你应该能判断一个任务是否适合 Gemini CLI：它是否发生在项目目录里，是否需要读文件或跑命令，是否能验证结果，是否需要 Google 生态入口。如果答案都是否，普通聊天或 IDE 工具可能更合适。

把定位想清楚，后面安装、认证、工具权限和自动化才不会混乱。

## 官方资料

官方资料把 Gemini CLI 描述为 open-source AI agent，并强调它在终端中通过内置工具和 MCP 完成任务。这个定位决定了教程不能只写"怎么问 Gemini"，而要写"怎么给它安全地读、写、查、跑和验证"。

- 官方仓库：[github.com/google-gemini/gemini-cli](https://github.com/google-gemini/gemini-cli)
- 官方 docs：[docs/index.md](https://github.com/google-gemini/gemini-cli/blob/main/docs/index.md)
- Google Developers 中文：[gemini-code-assist/docs/gemini-cli](https://developers.google.com/gemini-code-assist/docs/gemini-cli?hl=zh-cn)

## 最小心智模型

```text
Gemini CLI = 模型 + 项目上下文 + 工具系统 + 权限治理 + 自动化入口
```

这比“一个更会写代码的聊天机器人”准确得多。

## 下一篇

<Cards>
  <Card title="安装、认证和第一次启动" description="先跑通低风险只读任务，再进入真实项目。" href="/docs/gemini-cli/understanding/02-install-auth-first-run" />
  <Card title="官方教程中文版" description="需要查安装、认证、CLI、工具和配置参数时，回到官方查询手册。" href="/docs/gemini-cli/official" />
  <Card title="工具对比" description="已经在比较 Codex、Claude Code、OpenCode 时，跳到横向选型页。" href="/docs/gemini-cli/understanding/11-gemini-cli-vs-codex-claude-opencode" />
</Cards>
