GitHub Copilot CLI 在 1.0.94-0 版本中把本地模型发现直接嵌入了原有交互流程：输入 /model，CLI 会从正在运行的本地 Ollama 实例中发现受支持的模型，并与已配置模型、GitHub Copilot 提供的云端模型并列展示。这个改动的核心价值不在于“多了一个模型来源”，而在于把模型选择收敛到同一个入口，减少在终端、配置文件与外部工具之间来回切换的成本。
发现不等于自动接入
需要明确一个关键边界：发现不会自动添加模型。流程是“发现—选择—确认”。选中一个被发现的模型后，CLI 会展示其 provider 与 endpoint，由开发者确认 Add and use for this session 或 Add without switching。前者添加并立即切换，后者只添加不切换。确认后可在当前会话中直接使用，无需重启 CLI。
这条路径有两个前置条件：Ollama 与目标模型必须已经安装完成。该流程不负责安装运行时，也不负责下载模型。换句话说，CLI 只做发现与接入编排，环境准备仍由开发者自行完成。此外，模型必须支持 tool calling 与 streaming，否则无法满足 Copilot CLI 的交互要求。
失败可见性
provider 连接失败时，错误会直接出现在模型选择器中，并附带说明。这一点在工程上比“静默失败”更有价值：当本地 Ollama 未启动、端口不通或 endpoint 配置错误时，开发者能在选择模型的位置直接定位问题，而不是等到发起请求后才看到超时或连接拒绝。
与现有工作流的集成
从集成角度看，/model 把本地模型纳入了 Copilot CLI 既有的模型选择语义。开发者不需要为本地模型单独维护一套调用习惯，模型来源的差异被收敛到 provider 与 endpoint 两个字段上。这与 GitHub Copilot app 的 provider 体验思路一致：在 app 中通过 Settings > Model providers 添加受支持的 provider，在 CLI 中则通过 /model 完成发现与确认。
对于已经在使用 Copilot CLI 的团队，这意味着本地模型的接入成本主要是环境侧的准备，而不是工作流侧的改造。会话内切换、无需重启，也降低了在“云端模型处理常规任务、本地模型处理特定任务”之间来回切换的摩擦。
离线与内网环境的关键边界
这里有一个容易被误读的点：选择本地模型并不会开启离线模式，也不会关闭 GitHub 遥测。在 CLI 中，离线模式仍然是一个显式选择，通过 COPILOT_OFFLINE=true 开启。
更重要的是，即使在离线模式下，远程 provider 仍可能通过网络接收提示词与代码上下文。这意味着“用了本地模型”与“数据不出内网”不是等价命题。在内网或强合规场景下做选型时，需要分别确认三件事：
- 当前会话实际使用的是本地 provider 还是远程 provider；
- 离线模式是否已通过
COPILOT_OFFLINE=true显式开启； - 所选 provider 的 endpoint 是否指向内网地址，而非公网服务。
把这三项分开检查，可以避免把“本地模型发现”误当成“数据本地化”的完整方案。具体的配置方式与限制，应参考 CLI provider 与离线模式文档。
工程选型建议
在离线或内网环境下，建议按以下顺序推进：
- 先确认 Ollama 与候选模型已就绪，并验证模型支持 tool calling 与 streaming；
- 通过
/model发现模型，检查 provider 与 endpoint 是否符合内网预期； - 用 Add without switching 先添加、后验证，确认可用后再切换；
- 显式设置
COPILOT_OFFLINE=true，并单独核查远程 provider 是否仍会收到上下文； - 把 provider 连接失败的选择器提示纳入日常排障路径。
官方同时提到正在推进 local models 的 intelligent routing，并建议关注后续可用性公告。在該能力正式可用前，模型选择仍以手动确认为主。
总体来看，/model 的本地模型发现把本地模型接入从“配置任务”变成了“会话内决策”，但它没有改变离线模式与遥测的既有语义。把发现、确认、离线开关与 provider 边界分开理解，才能在内网与离线场景下做出可靠的工程判断。