Gemini CLI 切换模型完全指南：/model 命令与启动参数实战

在终端里跑一个简单的脚本修复，CLI 却慢得让人抓狂——它正用一个重量级推理模型处理根本不需要那么多算力的任务。反过来也一样：你在做一次真正棘手的重构，它却默认用了一个速度快但思考浅的模型，恰好漏掉了那种更强模型本能捕捉到的边界情况。这两个看似相反的问题，其实共用一个解法，而且一旦你知道它藏在哪里，整个过程只需要五秒钟。

会话内切换：/model 命令

在一个活跃的会话中，直接输入 /model 并回车，就会弹出一个对话框，里面有三个真实可选项：

• Auto（最新模型线）：在最新一代模型上自动调度
• Auto（上一代模型线）：在上一代模型上自动调度
• Manual（手动）：让你从账户可用的模型列表中直接指定某个具体模型

对绝大多数人来说，Auto 才是正确的默认选择。它会为简单请求挑选更轻、更快的模型，当任务真正变复杂时又会自动升级到更强的模型。这意味着你不用在每一次 prompt 上手动盯着它、替它做决定。

什么时候该切到 Manual

当你事先就知道任务性质时，手动模式更有价值。遇到一次真正困难的重构，或者需要谨慎的多步推理时，与其寄希望于 Auto 第一次就准确判断复杂度，不如在开始前就手动锁定最强的 Pro 级模型。

反之，重复性的小任务是另一种典型场景。手动降到一个更快的模型，能在几十个零碎请求的累积中为你省下真实的时间——在这些场景里，重量级推理除了拖慢速度之外没有任何额外收益。

启动前设定：--model 启动参数

如果你更希望在会话开始之前就把模型定下来，可以在终端启动 CLI 时直接带上 model 参数。具体语法会在启动那一刻就指定好模型名称，让你完全跳过对话框，一开始就运行在你想要的模型上。

这种方式特别适合纳入脚本或工作流中——当你对某类任务的模型偏好非常明确时，省去每次会话里手动选择的步骤。

在脚本或 CI/CD 工作流中固定模型版本，还能带来一个额外好处：可重复性。当你需要对同一类任务的输出进行基准测试或横向对比时，确保每次运行使用完全相同的模型是得到可靠结论的前提。Auto 模式下，不同时间点的调度结果可能因模型更新或任务负载而产生差异，而 --model 参数能将这个变量固定下来。此外，部分模型名称会带有版本号后缀，指定时建议查阅当前账户可用的精确模型 ID，避免因名称不匹配导致启动失败。

容易踩的坑：子代理不受你的选择约束

这里有一个让很多人误以为功能坏掉的细节。无论你是用 /model 还是启动参数切换模型，这个选择都不会覆盖子代理（sub-agents）在任务执行过程中使用的模型。

如果 CLI 为了处理某个大任务的一部分而启动了子代理，那个子代理可能运行在与你明确选定的模型不同的模型上。这一点会反映在你的用量报告里——即便你本人只选了一个模型，报告中却出现了多个。这不是 bug，而是一个值得在动手前就知道的作用域限制。

想确认主会话究竟跑在哪个模型上，查看终端底部状态栏显示的模型名称即可，因为那才是你的选择能直接控制的部分。

子代理（sub-agents）是 Gemini CLI 在处理复杂任务时自动拆解并并行或串行执行子任务的机制。主会话接收你的指令后，可能判断某些子任务适合交由独立的代理进程处理，这些子代理会根据自身对子任务复杂度的评估独立选择模型，而不继承主会话的模型设定。这种设计的出发点是效率：子代理可以针对各自负责的片段做最优的模型匹配，但副作用是用量统计会聚合所有子代理的消耗，导致报告中出现你从未手动选择过的模型。理解这一点有助于你在评估成本时建立正确的预期——总用量往往高于仅看主会话所能预估的数字。

小结

切换 Gemini CLI 模型的核心逻辑其实很清晰：

• 不确定任务难度时，交给 Auto
• 明确知道任务复杂或简单时，用 Manual 或启动参数锁定
• 对用量报告里的多模型现象保持清醒——那是子代理的作用域，而非你的选择失效

掌握这三点，你就能根据任务性质精确控制算力投入，既不浪费推理能力在琐事上，也不让关键重构栽在浅层模型上。