GitHub Copilot CLI 怎样确认本地模型是否真正启用

GitHub Copilot CLI 最近把本地模型选择做得更顺手了：从 CLI 1.0.94-0 开始，/model 可以发现正在运行的本地 Ollama 模型，并把它们和已经配置的模型、GitHub 托管模型放在同一个选择入口里。真正需要留意的不是“列表里出现了本地模型”，而是选择后能不能确认 provider、endpoint 和当前会话都已经切换。

官方地址：https://github.blog/changelog/2026-10-07-discover-local-models-in-github-copilot-cli/

选择本地模型只代表推理目标发生了变化，不等于 Copilot CLI 自动进入离线模式。要限制 CLI 与 GitHub 服务的连接，仍然要显式配置 COPILOT_OFFLINE=true；如果 provider 指向远程地址，提示词和代码上下文仍可能离开本机。

这次更新到底改变了什么

以前配置本地模型通常要先写好 provider 环境变量，再记住模型名。现在可以在 CLI 的 /model 入口里看到本机 Ollama 提供的可用模型，选中后查看提供方和 endpoint，再决定“添加并用于本次会话”还是“添加但不切换”。这三个动作解决的是发现和选择成本，并没有替用户完成运行时隔离。

还有一个容易忽略的细节：本地模型和 Ollama 运行时必须已经安装，发现功能不会替你下载模型，也不会替你启动服务。模型还要支持 tool calling 和 streaming，否则即使能被发现，也可能在真正执行任务时返回能力不匹配的错误。

先看 provider 和 endpoint，再看模型名称

我会把确认顺序放在模型名称之前。名称只说明“准备使用谁”，provider 和 endpoint 才说明“请求准备发给谁”。如果使用 OpenAI 兼容的本地服务，可以先准备一组不含密钥的本地配置：

# 指向本机的 OpenAI 兼容接口，避免把本地试用误认为云端调用
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434

# 本地 provider 通常不需要 API key；模型名替换成 Ollama 中实际存在的名称
export COPILOT_MODEL=YOUR-LOCAL-MODEL-NAME

# 启动 CLI，随后在交互会话中输入 /model 查看可用模型
copilot

进入 /model 后，不要只凭“local”或模型名做判断。先看 provider 类型，再看 endpoint 是否确实是本机地址；如果选择器显示连接失败，优先处理 Ollama 服务状态、模型名称和 tool calling 能力，而不是反复切换模型。

选择完成后，CLI 可以在当前会话里使用新模型，不必为了这一步重新启动。这个行为适合做小范围对照：先保持同一个任务和仓库上下文，再分别选择本地模型与云端模型，观察工具调用、响应速度和上下文承载能力。

怎样判断本地模型真的生效

我会用三个相互独立的信号交叉确认：

• 选择器中能看到本地模型，并且 provider 与 endpoint 指向预期的本地服务。
• 确认动作完成后，当前会话的模型状态发生变化，而不是只把模型加入配置但继续使用原模型。
• 执行一个低风险、短上下文的小任务时，本地 provider 能正常完成流式输出和工具调用；连接失败信息应明确落在 provider 或能力不支持，而不是笼统超时。

第三点很重要。模型名称正确不代表接口契约正确。本地服务如果只支持普通文本生成，却不支持工具调用，Copilot CLI 这类代理式工作流仍然无法完整工作。测试时不要直接把生产仓库和敏感上下文交给刚接入的 provider，可以先用一个没有凭据的示例项目验证。

选择本地模型，不等于自动离线

这是这次更新最值得单独写出来的边界。GitHub 的更新说明明确把“选哪个模型”和“是否允许 CLI 访问网络”分成两件事：前者决定推理 provider，后者决定网络策略。即使模型来自本机，CLI 仍可能与 GitHub 服务通信；反过来，如果 provider 的 base URL 指向远程服务器，所谓“自定义模型”也不是本地处理。

需要离线试用时，再显式设置网络模式：

# 只在确认 provider 位于本机或同一隔离环境后开启离线模式
export COPILOT_OFFLINE=true

# 保持本地 provider 和模型配置，再启动 CLI
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=YOUR-LOCAL-MODEL-NAME
copilot

这里的“离线”也不能被扩大解释成安全保证。它只表达 CLI 的网络隔离意图；如果 provider 实际配置成远程地址，提示词和代码上下文仍可能发往那个远程 provider。真正上线前，还要把 provider 的地址、服务日志、代理设置和组织侧策略一起纳入边界说明。

和远程 BYOK、GitHub 托管模型怎么选

官方配置文档还要求模型支持工具调用和流式输出，并建议复杂任务准备足够大的上下文窗口。这意味着“能生成一句回答”不是采用标准，至少要把工具调用、长上下文和异常连接作为试用清单。

配置参考：https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models

我会怎样安排第一次试用

第一次接入不会直接跑自动修改任务，而是准备一个没有密钥、没有生产配置的小仓库，固定同一条短指令，依次记录四件事：选择器显示的 provider、endpoint 是否为本地地址、当前会话是否切换、工具调用是否成功。然后再用同一个任务换成远程 BYOK 或托管模型，比较响应延迟、上下文长度和失败提示。

如果本地模型能回答但工具调用失败，问题多半在模型能力或兼容接口，不是“没有真正启用”。如果选择器显示已添加但当前会话没有切换，重点检查确认动作是“用于本次会话”还是“仅添加”。如果本地请求正常但仍看到网络请求，则要回到离线模式和 provider 地址分别排查。

这套试用顺序的好处是把“模型选择错误”“provider 配置错误”“网络边界误判”分开了。它不会给出所有环境都适用的结论，但能让团队在决定推广前保留一份可解释的证据。

最后的判断

GitHub Copilot CLI 的本地模型发现能力，真正降低的是选择和切换门槛。对个人开发者，它适合先用低风险仓库体验本地推理；对团队，它更像一个需要配合 provider 白名单、网络策略和模型能力清单的入口。记住两个判断就够了：看见本地模型不代表当前会话已经切换，选择本地模型也不代表网络已经离线。

常见追问

发现不到 Ollama 模型怎么办？

先确认 Ollama 已运行、模型已安装，再检查 provider endpoint 是否指向正确的本机地址。发现功能不会自动安装运行时或下载模型。

本地模型能不能直接用于代理操作？

可以尝试，但模型必须支持 tool calling 和 streaming；否则文本回答正常，也不代表能完成 CLI 的完整工具工作流。

设置了离线模式还要检查什么？

继续检查 provider 是否为本机或同一隔离环境。离线开关不能把远程 endpoint 变成本地服务，也不能替代组织侧的数据传输策略。