GitHub Copilot CLI新增本地模型发现能力

GitHub Copilot CLI 的这次更新，解决的是“本机已经有 Ollama 和本地模型，但在 CLI 里不容易发现它们”的入口问题。官方公告说明，从 CLI 版本 1.0.94-0 起，可以在运行中的 CLI 里使用 /model，发现本地 Ollama 支持的模型，并与已经配置的模型、GitHub Copilot 云端模型放在同一个选择入口中。

官方地址：https://github.com/features/copilot

这条公告到底新增了什么

变化可以压缩成三点：第一，CLI 版本达到公告所说的起点后，/model 能从正在运行的 Ollama 实例发现可用模型；第二，发现结果会和现有配置、GitHub 提供的云端模型一起出现在选择器中；第三，连接失败会在选择器里给出解释，方便判断是端点、运行时还是模型能力出了问题。

这里的“发现”要和“安装”分开理解。Ollama 和模型仍然需要用户提前安装并启动，Copilot CLI 不会替你下载运行时或模型。发现一个模型后，还要确认它的提供者和端点，再选择“Add and use for this session”或“Add without switching”。官方公告还说明，添加后的模型可以在当前会话使用，不需要重启 CLI。

它适合哪些开发场景

如果你已经在本机维护了 Ollama 模型，希望在同一个 Copilot CLI 工作流里比较本地模型和云端模型，这次入口会更直接。比如，日常可以先看发现到的本地模型是否能满足代码解释、重构草稿或小范围命令辅助，再按任务切换到其他已配置模型。

但不要把它理解成“任何本地模型都能使用”。GitHub Docs 明确要求模型支持工具调用和流式输出；不满足任一能力时，Copilot CLI 会返回错误。官方文档还建议为更好的体验准备较大的上下文窗口，但这属于使用建议，不是这条公告对所有模型的保证。

按官方前提准备一次试用

试用前先准备三件事：已安装符合公告版本要求的 Copilot CLI；本机 Ollama 正在运行且已经有模型；目标模型支持工具调用和流式输出。下面只是配置形态示意，不能替代本机环境检查：

# 指向本机 Ollama；模型名应替换为你已经准备好的实际模型。
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=YOUR-MODEL-NAME

# 启动 CLI 后，在当前会话打开模型选择入口。
copilot
/model

进入选择器后，先看提供者和端点，再决定是只在当前会话试用，还是添加但暂不切换。连接失败提示也值得保留，因为它能把“列表里没有模型”进一步区分为 Ollama 未运行、端点不可达或模型能力不符合要求。

和原来手工配置的区别

因此，这不是把旧配置完全废掉，而是把“本地模型在哪里、能不能加入当前工作流”的发现成本降下来。已有的 OpenAI 兼容端点、Azure OpenAI、Anthropic 等 BYOK 配置仍然属于提供者配置问题，不能用本地发现入口替代。

采用前要特别注意的边界

第一，本地模型选择不会自动开启离线模式，也不会自动关闭 GitHub telemetry。第二，即使显式设置 COPILOT_OFFLINE=true，如果提供者地址指向远程服务，提示和代码上下文仍可能发送给该远程提供者；真正的隔离还取决于提供者是否也在本地或同一隔离环境内。第三，官方公告提到的智能路由是另外的后续说明，不能把它当成这次模型发现能力已经完整可用。

更稳妥的采用顺序是：先确认 CLI 版本与本地运行时，再确认提供者端点，随后确认模型能力，最后用不含敏感代码的小任务试用。这样能把“发现成功”“能加入选择器”“能在当前会话工作”和“满足组织网络要求”四个判断分开。

常见问题

发现到本地模型后会自动下载或安装吗？

不会。官方公告把发现和安装分开，Ollama 与模型必须由用户提前准备，CLI 只负责发现、展示和加入选择。

选择本地模型就等于完全离线吗？

不等于。离线模式仍需显式配置，而且远程提供者地址仍可能接收提示和代码上下文；要实现网络隔离，提供者也必须处于本地或同一隔离环境。

总结来说，GitHub Copilot CLI 的新增能力更像一个本地模型发现层：它让运行中的 Ollama 模型进入统一选择入口，却没有替用户安装运行时、保证模型能力或自动改变网络策略。满足版本、端点和工具调用/流式输出前提后，再用低敏感任务试用，才能判断它是否适合自己的日常工作流。