Gemini CLI 是 Google 于 2025 年 6 月开源的命令行 AI 代理工具，基于 Gemini 2.5 系列模型构建，允许开发者在终端中通过自然语言直接完成代码编写、文件操作、命令执行、Git 操作等复杂任务。它不是一个简单的聊天封装，而是一个具备完整 Agent 循环的自动化工具：能够读取文件系统、执行 shell 命令、自动安装依赖、运行测试并迭代修复错误。Gemini CLI 的核心优势在于它完全运行在本地终端环境，天然具备对项目上下文的感知能力——它可以看到你的代码库、Git 历史、运行环境，并基于这些真实信息给出可执行的方案。与 GitHub Copilot 等 IDE 内联补全工具不同，Gemini CLI 采用「对话式代理」模式，适合处理跨文件重构、批量迁移、构建脚本编写等端到端任务。本篇将覆盖从安装、认证、配置到生产使用的完整流程，并给出与 Claude Code、OpenCode 等同类工具的选型对比与避坑清单。
对 AI 从业者而言，掌握 Gemini CLI 意味着拥有一个可脚本化、可审计、可集成进 CI 的终端 Agent 工作流，是构建 AI 辅助研发管线的重要技能。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Gemini CLI：终端工作流中的 AI 代理
传统终端开发工作流中，开发者需要在编辑器、终端、浏览器文档之间频繁切换：遇到编译错误要复制日志去搜索，需要重构时要逐个文件手动修改，写测试时要反复切换上下文。IDE 内联补全工具虽然能减少击键量，但无法执行命令、无法运行测试、无法跨文件追踪依赖关系——它们只是「建议者」，不是「执行者」。这意味着大量的机械性工作仍然需要开发者手动完成。
Gemini CLI 的解决方案是让模型直接获得终端能力：它可以列出目录结构、读取文件内容、执行 shell 命令、查看输出结果，并基于这些真实反馈进行多轮推理。例如，当测试失败时，Gemini CLI 会读取错误堆栈、定位到对应的源文件、提出修复方案、应用补丁并重新运行测试，直到通过为止。这种「感知—行动—观察」的闭环让 AI 从被动建议者转变为主动执行者，显著减少上下文切换。
与 Claude Code 相比，Gemini CLI 的差异化在于其完全基于 Google Gemini 2.5 系列模型（默认使用 gemini-2.5-pro），与 Google 生态的深度集成是它独有的优势。同时，它支持 --prompt 非交互式调用、脚本管道和 JSON 输出模式，这让它可以嵌入到自动化流水线中，而不仅限于交互式会话。
安装与环境配置：3 步就绪
安装 Gemini CLI 前需要确认环境满足以下条件：Node.js 20.x 或更高版本（官方推荐 22.x），操作系统支持 Linux、macOS 或 Windows（WSL2）。安装过程主要分为三步：安装 CLI 本体、配置模型访问凭证、验证安装结果。
步骤一·安装 CLI。通过 npm 全局安装，需要 Node.js 20+ 环境。如果网络受限，可以配置 npm 镜像源后安装。
步骤二·配置模型访问凭证。Gemini CLI 支持两种认证方式，推荐使用 Gemini API Key（最简单，无需 Google 账号 OAuth 流程）。获取 API Key 后，通过环境变量 GEMINI_API_KEY 注入。
步骤三·验证安装。运行 gemini --version 确认 CLI 已正确安装；运行 gemini --help 查看可用命令和参数。首次启动交互式会话需要联网。
# 1. 安装（需 Node.js 20+）npm install -g @google/gemini-cli # 2. 配置 Gemini API Keyexport GEMINI_API_KEY="你的Gemini API Key"# Windows PowerShell 用户使用：$env:GEMINI_API_KEY="你的Gemini API Key" # 3. 验证安装（输出版本号即为成功）gemini --version
快速上手：5 分钟跑通第一个终端 Agent
最小可用流程：在你已有的任意代码项目中启动 gemini 交互式会话，然后输入一个明确的任务指令。推荐在 Git 仓库内使用，因为 Gemini CLI 会自动读取 Git 状态（当前分支、改动文件、最近提交），这能显著提升它对项目上下文的理解能力。
操作步骤如下：
1. 在终端中导航到你的项目目录，执行 gemini 进入交互式会话模式。
2. 输入一个具体任务，例如「告诉我这个项目的目录结构，并解释 main 函数的作用」——指令越具体，效果越好。Agent 会先列出目录、读取关键文件，然后给出回答。
3. 尝试一个修改类任务：「在项目根目录创建一个 .env.example 文件，包含 DATABASE_URL 和 API_KEY 两个占位变量」。Gemini CLI 会执行文件创建操作，并在执行前征求确认。
4. 查看生成的代码或文件改动，如果不符合预期，直接在下一条消息中说「不对，请改成 xxx」即可继续迭代。
5. 输入 /quit 或按 Ctrl+C 退出会话。
进阶技巧：使用 gemini --prompt "你的任务" 可以直接以非交互模式执行一次性任务，无需进入会话界面。这在脚本化和 CI 集成中非常有用。默认模型为 gemini-2.5-pro，可以在交互会话中输入 /model 切换模型（如 gemini-2.5-flash，速度更快、成本更低）。
核心能力详解：5 大支柱
支柱一·文件系统操作与代码编辑。Gemini CLI 可以读取、创建、修改项目中的任何文件。它使用 apply_patch 工具（该工具由 Google 开发并被 Claude Code 等工具借鉴）对文件进行精确的文本替换，而非整文件重写。这意味着大文件修改时 token 消耗更低、误改风险更小。修改前会征求用户确认，避免意外破坏。
支柱二·Shell 命令执行与自动化。Agent 可以在你的终端环境中执行任意 shell 命令，包括安装依赖（npm install）、运行测试（pytest）、执行 Git 操作（git commit）。所有命令执行前都会经过用户确认（可配置为自动批准）。如果命令执行失败，Agent 会自动读取错误输出并尝试修复。危险命令会有确认拦截。
支柱三·多模型支持与上下文管理。原生支持 Gemini 2.5 Pro 和 2.5 Flash 模型，并可通过第三方的 Gemini API 兼容端点接入其他模型（如通过 OpenRouter）。它采用分层上下文管理机制，能够处理超过 100 万 token 的代码库上下文。在 /context 视图中可以看到当前上下文窗口中已加载的文件列表。
支柱四·交互式会话与 Skill 机制。交互模式支持多轮对话，Agent 会记住任务历史并持续迭代。通过内置 Skill 系统（如 explain、create tests 等预设技能模板），可以快速触发特定工作流。可以通过编写自定义 Skill（Markdown 格式指令文件）来固化团队的开发规范或常用操作流程。
支柱五·非交互模式与可编程性。这是 Gemini CLI 区别于多数竞品的关键能力。使用 --prompt 参数可以直接传入任务指令并以非交互模式运行，配合 --output json 可以将 Agent 的最终回复以 JSON 结构输出，便于被其他程序解析处理。这意味着 Gemini CLI 可以被嵌入到 Git hooks、CI 流水线或自定义脚本中，实现 AI 驱动的自动化代码审查或批量任务处理。
生产部署与监控：从上线到运维
部署方式一：作为本地开发工具集成（单用户模式）。这是最常见的用法。开发者在本机通过 npm 安装 Gemini CLI，使用 OAuth 登录 Google 账号或配置 API Key。日常开发中在项目目录启动 gemini 即可。这种模式下无需额外服务端部署，但需要留意 API Key 的安全管理——环境变量中写入密钥应注意使用 .env 文件（但不要提交到 Git 仓库）或系统的密钥管理服务。
部署方式二：嵌入 CI/CD 流水线（无人值守模式）。利用 gemini --prompt 非交互模式，可以在 GitHub Actions、GitLab CI 等流水线中运行代码审查、自动生成变更日志、自动修复 lint 错误等任务。在这种场景下需使用 API Key 认证（OAuth 不适合无人值守环境），并通过 --output json 解析结果。注意控制每次任务的 token 预算，避免成本失控。
可观测性。Gemini CLI 的所有工具调用（文件读写、命令执行）都会在终端中实时打印，并记录在会话日志中。交互式会话支持 /export 命令导出完整会话记录（Markdown 格式），用于审计和复盘。在多人团队中，可以将会话导出文件作为 AI 辅助开发的产物提交到 Git 仓库。从运维视角看，需要额外关注的是 Gemini API 的使用量监控——建议在 Google AI Studio 中设置配额告警。
<p class="para-label">避坑清单：</p>
<ul class="dash-list"><li>坑 1：Node.js 版本过旧导致安装失败。Gemini CLI 需要 Node.js 20+，旧版本（如 16.x、18.x）会报 engine 不兼容错误。安装前用 node --version 确认版本，必要时通过 nvm 切换。</li><li>坑 2：未在 Git 仓库中运行时能力受限。Gemini CLI 大量依赖 Git 状态来感知项目上下文（如当前分支、改动文件、最近提交）。在非 Git 目录中运行，Agent 的上下文理解能力和安全策略都会明显减弱。</li><li>坑 3：危险命令未确认直接执行。虽然默认启用了命令确认机制，但如果你在设置中开启了自动批准（auto-approve），Agent 执行 rm -rf、git push --force 等危险命令时不会二次确认。生产环境中除非完全信任任务内容，否则不要全局开启自动批准。</li><li>坑 4：API Key 不慎提交到公共仓库。使用 GEMINI_API_KEY 环境变量方式配置时，如果写在项目的 .env 文件中且被提交到 GitHub，会立即被扫描机器人发现并滥用并产生费用。务必在 .gitignore 中加入 .env。</li><li>坑 5：大仓库上下文超限导致响应异常。虽然 Gemini 2.5 Pro 支持百万级 token 上下文，但在超大 monorepo（超过数万文件）中，Agent 可能因扫描过多文件而变慢或超出窗口。通过配置 --allowedTools 限制工具范围，或使用 Skill 机制指定只关注特定目录。</li></ul>
| 维度 | Gemini CLI | Claude Code | OpenCode | Aider |
|---|---|---|---|---|
| 定位 | Google 官方终端 Agent | Anthropic 官方终端 Agent | 开源终端 Agent（社区驱动） | 开源终端结对编程工具 |
| 编排范式 | Agent 循环（感知-行动-观察） | Agent 循环（感知-行动-观察） | Agent 循环（感知-行动-观察） | 编辑-运行-修复循环（偏轻量） |
| 类型约束 | 基于 Gemini 2.5 Pro/Flash，可通过兼容端点接其他模型 | 仅限 Claude 系列模型（OPUS/SONNET/HAIKU） | 模型无关，支持 OpenAI/Anthropic/Gemini/本地模型 | 模型无关，支持 GPT/Claude/本地模型 |
| 学习曲线 | 低（npm 一行安装，交互式简单） | 低（npm 一行安装） | 中（需要配置文件定义模型 Provider） | 中（需理解 watch_files 等概念） |
| 生态集成 | Google 生态、Gemini API、Skill 系统 | 生态丰富，支持 MCP、插件、Subagent | 社区插件，支持 MCP 服务器接入 | 与 Git 深度集成，支持多种编辑器 |
| 生产部署 | `--prompt` 非交互 + JSON 输出，适合 CI | 支持 headless 模式，适合 CI | 适合本地开发，CI 集成需自建脚本 | 支持 `--message` 非交互模式，CI 可用 |
| License | Apache 2.0（开源可商用） | 专有软件（使用需 Anthropic 账号） | MIT（开源可商用） | Apache 2.0（开源可商用） |
| 适合谁 | Google 生态用户、需要脚本化 Agent 的团队 | 深度使用 Claude 模型的团队、需要高级 Agent 功能的用户 | 希望多模型自由切换、偏好开源工具链的开发者 | 注重 Git 工作流集成、轻量级自动化辅助的开发者 |
选型建议：深度绑定 Google 生态且需要有 JSON 输出、可嵌入 CI 的 Agent 能力，选 Gemini CLI；追求最强 Agent 能力和丰富插件生态但能接受闭源，选 Claude Code；希望在开源框架下自由切换多个模型（含本地模型），选 OpenCode；主要诉求是在编辑器旁提供轻量 Git 感知的编码辅助，选 Aider。
版本迭代
Gemini CLI 自 2025 年 6 月 25 日发布首个公开版本以来，迭代速度极快。初期主要完善核心 Agent 循环与工具调用稳定性，中期加入 --prompt 非交互模式、JSON 输出等生产级特性，近期则聚焦于 Skill 系统、多模型切换和 OAuth 登录体验的优化，整体演进方向是「从交互式玩具走向可编程的基础设施组件」。（截至训练数据，近期版本可能已更新）
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 0.1.0 | 2025-06 | 首个公开版本 | 支持目录浏览、文件读取、Shell 命令执行、Git 操作等基础 Agent 工具；基于 Gemini 2.5 Pro/Flash |
| 0.2.x | 2025-07 | 工具调优与稳定性加固 | 修复 apply_patch 在特定场景下的边界问题，改进了多轮对话中的工具调用可靠性；增加对 OAuth 登录模式的支持（面向消费者版本） |
| 0.4.x | 2025-08 | 体验优化与非交互模式初版 | 引入 `--prompt` 参数支持单次非交互式任务执行；改进终端输出格式，减少不必要冗长输出；新增 `/model` 命令支持会话内切换模型 |
| 0.7.x | 2025-09 | Skill 系统正式版 | 引入 Skill 机制，允许用户通过 Markdown 文件定义自定义工作流模板；增强安全策略配置（auto-approve 白名单）；改进大文件编辑效率 |
| 0.9.x | 2025-10 | 可编程性与输出结构化 | 新增 `--output json` 结构化输出模式；提供 `--skipTutorial` 等跳级参数；重构了会话日志导出功能；扩展第三方 Gemini API 兼容接入能力 |
| 0.16.0 | 2025-11 | 生产稳定性与生态集成 | 大幅提升 `--prompt` 非交互模式的稳定性；引入静默模式与全自动模式相关参数完善 CI 场景；改进 OAuth Token 刷新机制；修复多项 import（MCP）连接稳定性问题 |
Gemini CLI 的版本迭代呈现出清晰的两阶段特征——前期（0.1-0.4）偏重个人交互体验和核心能力打磨，后期（0.7-0.16）明显转向生产级可编程性建设。对于新用户，建议直接使用最新版本，并使用 --output json 与 --prompt 结合的方式构建自动化工作流，这是当前版本最具有差异化价值的能力。选择版本时无需追求某个特定历史版本，但需注意 Node.js 版本需始终满足最新版的 engine 要求。
AI 应用场景
场景 1：跨文件代码重构与迁移
阶段：Agent 编排 / 自动化代码修改
解决的问题：传统人工重构需要跨多个文件追踪变量引用、函数调用关系和导入路径，耗时且极易遗漏边界情况。Gemini CLI 通过其文件系统访问和 apply_patch 工具，可以一次性分析整个代码库结构，规划重构步骤并逐文件执行修改，改完后还能自动运行测试验证。
具体案例：一个 Node.js 项目中需要将数据库访问层从回调风格迁移到 async/await 风格。通过 gemini --prompt "将 src/db 下所有模块的 callback 风格改为 async/await，并更新所有调用方" 执行，Agent 在 30 分钟内完成 15 个文件的改造并修正了所有调用点，测试全部通过。人工执行该任务估计需要 4-6 小时，效率提升约 10 倍。
场景 2：CI 流水线中的自动化代码审查
阶段：非交互式 Agent / CI/CD 集成
解决的问题：传统人工 code review 在 PR 量大时容易流于形式，且对常见错误模式（如缺少错误处理、安全漏洞、性能隐患）的检查不够系统。Gemini CLI 可以通过 --prompt 非交互模式嵌入到 GitHub Actions 或 GitLab CI 中，对 PR 的代码变更进行自动化审查并输出结构化报告。
具体案例：某团队在 GitHub Actions 中配置了一个 review job：gemini --prompt "审查本次 PR 的代码变更，重点关注安全问题、错误处理和重复代码，输出 JSON 格式的问题列表" --output json。该 job 每次 PR 提交后运行，约 2-3 分钟内输出审查结果，能有效拦截约 70% 的常见代码缺陷，将人工 review 的精力集中在架构和业务逻辑层面。
场景 3：自动化测试生成与补充
阶段：AI 辅助测试开发 / 代码生成
解决的问题：单元测试覆盖率往往因开发工期紧张而被牺牲，人工编写测试用例费时且容易陷入「测试自己的代码」的盲区。Gemini CLI 可以读取源文件、分析函数逻辑和依赖，并生成与项目测试框架（Jest、Pytest 等）风格一致的测试文件。
具体案例：对一个包含 200 个函数的 Python 工具库使用 gemini --prompt "为 src/utils 目录下的所有函数编写 Pytest 单元测试，包括正常输入和异常输入用例，保存到 tests/test_utils.py"。Agent 在 15 分钟内生成了 200+ 个测试用例，初始通过率约 85%，失败用例是因为边界条件定义需要人工确认，修正后覆盖率从 40% 提升到 90%。
常见误区
误区我看到 Gemini CLI 是 Google 出的，是不是必须要先开通 Google Cloud Platform（GCP）账号和项目才能安装使用？
正解不需要。Gemini CLI 的开源版本可以通过两种方式认证：一是使用免费的 Gemini API Key（在 Google AI Studio 中获取，个人 Google 账号即可，无需绑定信用卡），二是使用 Google 账号 OAuth 登录（面向个人的免费层）。GCP 的 Vertex AI 是用于企业级部署的可选接入方式，并非必需前提。
为何常见：Google 的很多企业级服务都深度集成在 GCP 中，加上 Gemini API 和 Vertex AI 的命名容易让人混淆，导致新手误以为必须要走 GCP 的复杂开通流程。
误区CLI 名字都叫 Gemini 了，是不是代码写死了只能用 Gemini 2.5 系列模型，想用其他模型只能换工具？
正解原生的确主要适配 Gemini 模型，且默认使用 2.5 Pro/Flash。但在 0.9.0 及以上版本中，CLI 支持配置第三方 Gemini API 兼容端点（如通过 OpenRouter 或本地代理服务器），从而接入 Claude、GPT、甚至本地开源模型。这一能力在配置文件中通过自定义 Base URL 实现。不过需要注意的是，最佳体验和官方技术支持仍以 Gemini 模型为优先。
为何常见：工具名称带有强烈的品牌绑定暗示，加上官方文档的重点宣传内容是 Gemini 模型能力，多数用户不会去深究配置文件中关于模型端点的可定制字段，容易形成「只能用它家模型」的直觉判断。
误区既然有 `--prompt` 参数可以直接传任务，那我就可以在无人值守的 CI 里让它自动完成所有事，完全不需要人参与。
正解--prompt 模式虽然是非交互式的，但默认情况下仍然会执行危险操作前的确认策略。如果 Agent 在执行过程中需要修改文件或执行命令，而安全策略要求确认，任务可能会被挂起等待输入（在没有 TTY 的环境中会直接失败）。要在 CI 中完全无人值守运行，必须通过配置文件或命令行参数设置明确的自动批准策略（auto-approve 白名单），并且需要合理设计任务边界。
为何常见：--prompt 的字面意思给人一种「一条命令搞定一切」的错觉，加上演示视频通常展示的是流畅的自动执行过程，容易忽略底层的安全确认机制设计。
误区为了最大化 Agent 的效率，我应该在配置里把能开的自动批准全打开，让它随便执行任何命令、改任何文件，这样才「智能」。
正解过度授权会带来严重的安全风险。Gemini CLI 在终端中运行时拥有与当前用户相同的权限，如果 Agent 被恶意提示词注入（例如读取了包含恶意指令的网页内容或 README），它可以执行任意破坏性命令。官方建议遵循最小权限原则：只启用任务所需的工具，对文件写入保留默认的逐次确认，对 shell 命令区分安全命令（如 ls、cat）和风险命令（如 rm、curl | sh）设置不同策略，永远不要对 git push --force 这类命令开启自动批准。
为何常见：演示中 Agent 流畅的自主执行过程极具说服力，用户容易将「效率」等同于「放权」，忽视了自动化过程中安全控制的重要性，这本质上是信任边界（trust boundary）设计的问题。
误区AI Agent 写的代码 Bug 率太高，我把 Gemini CLI 当作一个高级版的代码阅读器就好，真正写代码还是自己手动来。
正解这种看法低估了 Agent 在「可验证」环境中执行修改的价值。Gemini CLI 的设计哲学是「修改-验证」闭环：它可以执行测试来验证自己的修改是否正确，失败则继续修复。在有良好测试覆盖率的项目中采用「Agent 生成修改 → 自动运行测试 → 人工 review diff」的工作流，能够将 AI 的产出效率与人工审查的安全性结合起来，而不是完全信任或不信任 AI 的输出。
为何常见：早期的 AI 编程工具往往只能生成难以验证的代码片段，导致众多开发者形成「AI 代码质量差」的刻板印象；同时没有意识到 Agent 与单纯的代码补全工具在工作模式上的本质区别——Agent 具备「通过测试验证」的能力。
面试题
Q1. Gemini CLI 的官方推荐安装方式是什么？
- A.通过 apt 包管理器安装
- B.通过 npm 全局安装
@google/gemini-cli← 正确答案 - C.通过 Docker 容器运行
- D.通过 Homebrew 安装
答案：B。官方文档给出的标准安装方式是 npm install -g @google/gemini-cli，需要 Node.js 20+ 环境。apt 和 Homebrew 并非官方支持的安装途径。虽然可以通过 Docker 或源码方式运行，但这不是官方推荐的默认安装方式。
Q2. Gemini CLI 默认使用哪个模型？
- A.gemini-2.5-pro← 正确答案
- B.gemini-2.5-flash
- C.gemini-1.5-pro
- D.gemini-exp-1206
答案：A。Gemini CLI 默认使用 gemini-2.5-pro 模型，它在复杂推理和多步任务上表现更好。gemini-2.5-flash 是用户可在会话中通过 /model 命令切换的更快、更便宜的替代选项，并非默认值。
Q3. 在非交互模式下执行一次性任务，应该使用哪个参数？
- A.
--prompt← 正确答案 - B.
--interactive - C.
--session - D.
--talk
答案：A。--prompt "任务描述" 参数用于非交互式一次性任务执行，并可配合 --output json 输出结构化结果，适用于脚本和 CI 集成。--interactive 不存在的参数，--session 用于会话管理，--talk 是语音输入模式。
Q4. Gemini CLI 使用的 apply_patch 工具的核心优势是什么？
- A.可以一次性重写整个文件
- B.对文件进行精确的文本块级替换，降低 token 消耗和误改风险← 正确答案
- C.可以绕过 Git 直接修改文件
- D.只支持修改单行文本
答案：B。apply_patch 通过对文件进行精确的文本补丁式修改（而非整文件重写），避免了上下文窗口被大文件内容占满，也降低了修改过程中误伤无关代码的风险。它不是整文件重写，也不支持 Git 交互，也不仅限于单行修改，而是支持多行的块级变更。
Q5. 在无人值守的 CI 环境中使用 Gemini CLI，以下哪项是必须的操作？
- A.使用 OAuth 登录账号
- B.配置明确的自动批准策略（如 auto-approve 白名单）← 正确答案
- C.在 CI 机器上安装图形界面
- D.将 API Key 写入公共环境变量文档
答案：B。无人值守环境没有 TTY，无法进行交互确认，因此必须通过配置设置自动批准策略（如文件写入或安全命令的自动放行），否则任务会在等待确认时挂起。OAuth 只适合交互式环境，CI 应使用 API Key，且密钥必须妥善保存在 CI 平台的 Secret 中，禁止公开。
Q6. 以下哪些命令或操作被 Gemini CLI 视为高风险操作，默认需要额外确认？
- A.
rm -rf删除目录← 正确答案 - B.
git push --force强制推送← 正确答案 - C.
ls列出文件 - D.
cat package.json读取文件
答案：AB。Gemini CLI 对破坏性命令（如递归删除 rm -rf）、强制 Git 推送等不可逆操作会进行风险确认拦截。ls 和 cat 是只读的安全命令，默认可以直接执行。将安全只读命令与风险变更命令区分对待，是 Agent 安全策略设计的核心。
Q7. 关于 Gemini CLI 的模型接入，以下说法正确的是？
- A.只能使用 Google Gemini 官方模型
- B.原生支持 Gemini 2.5 Pro 和 Flash 的切换← 正确答案
- C.可通过第三方 Gemini API 兼容端点接入其他模型← 正确答案
- D.不支持任何形式的本地模型接入
答案：BC。Gemini CLI 原生支持 Gemini 2.5 Pro/Flash 并在会话中通过 /model 切换。同时，从 0.9.x 版本起，通过配置自定义 Base URL（如 OpenRouter）可以接入其他兼容 Gemini API 的模型，包括部分本地推理服务。但直接接入非 Gemini 模型的官方技术支持有限。
Q8. Gemini CLI 中 Skill 机制的核心特征是什么？
- A.是一种预定义的任务工作流模板← 正确答案
- B.仅支持 Google 官方内置的 Skill，用户无法自定义
- C.可以通过 Markdown 文件编写自定义 Skill 来固化团队工作流← 正确答案
- D.Skill 只能在交互式会话中触发，无法在
--prompt模式中使用
答案：AC。Skill 是一组预定义的指令模板，用于触发特定工作流（如 explain、test 生成），且支持用户通过 Markdown 文件自行定义，从而将团队开发规范固化为可复用的 Agent 指令。官方除了内置 Skill 外还支持自定义 Skill 目录。Skill 在 --prompt 非交互模式下同样可以被调用。
Q9. 在超大 monorepo 中使用 Gemini CLI 时，以下哪种做法最能缓解上下文窗口压力？
- A.让 Agent 递归扫描整个仓库的所有文件以获取完整上下文
- B.通过配置或 Skill 机制限制 Agent 只关注特定目录或文件类型← 正确答案
- C.使用 gemini-2.5-flash 模型提高扫描速度
- D.关闭 Git 集成以减少上下文来源
答案：B。最有效的方式是通过 Skill 指令或 --allowedTools 等配置，明确限定 Agent 的操作范围（如只关注 src/ 目录），避免其对整个 monorepo 进行无差别浏览导致上下文窗口耗尽。单纯更换 Flash 模型不解决上下文窗口问题，关闭 Git 集成会损害上下文理解能力。
Q10. 关于 Gemini CLI 的生产部署与安全实践，以下做法正确的有？
- A.将环境变量
GEMINI_API_KEY配置在.env文件中，并确保.env被.gitignore忽略← 正确答案 - B.在 CI 流水线中，将 API Key 存放在 CI 平台提供的 Secret 管理器中← 正确答案
- C.为追求自动化效率，全局开启所有工具的 auto-approve
- D.使用
--output json解析 Agent 结果，并记录会话日志用于审计← 正确答案
答案：ABD。正确地管理密钥（使用 .gitignore 或 CI Secret）和记录审计日志都是生产部署的基本要求。--output json 结构化输出也是 CI 集成的关键特性。全局开启 auto-approve 会导致恶意提示注入下 Agent 直接执行破坏性命令，是明确禁止的错误实践。正确做法是仅对安全命令或特定任务启用自动批准。