Copilot CLI 也能开本地模型了：/model 一键发现 Ollama，但遥测照收、离线另算

2026 年 10 月 7 日，GitHub 在 Changelog 上放出一条小而重要的更新：Copilot CLI 从 1.0.94-0 版本开始，可以发现并使用你本机 Ollama 里的模型了。 在 CLI 里敲 /model，它会列出本机 Ollama 实例中的可用模型，和你配置过的模型、GitHub 提供的云端模型摆在一起任选。

这条更新不大——没有新模型、没有新功能键，却是 Copilot 产品哲学的一次转向：编程助手的「大脑」第一次可以不是 GitHub 的云，而是你自己的机器。

怎么用：发现 ≠ 自动接入

流程设计得很谨慎，一共三步：/model 发现本机 Ollama 里的模型 → 你检查它的 provider 和 endpoint → 手动确认「Add and use for this session」（本会话使用）或「Add without switching」（只添加不切换）。发现不会自动接入，每个模型都要你亲手点确认；选中后当前会话直接可用，不用重启 CLI。

有两个硬性前提，官方写得很清楚：Ollama 和模型必须你自己先装好——这个流程不装运行时、也不下载模型；模型必须支持工具调用（tool calling）和流式输出，否则进不了列表。连接失败的 provider 会在选择器里直接显示原因，方便排查。

这个设计延续了 Copilot App 里的 provider 体验（Settings → Model providers 添加第三方 provider），现在 CLI 补上了同一套逻辑：「选哪个模型干活，由你决定」。

细则里藏着的三句实话

Changelog 正文不长，但有三句话值得逐字读：

第一，「选本地模型不会开启离线模式，也不会关闭 GitHub 遥测。」 离线依然是显式选择：COPILOT_OFFLINE=true。换句话说，就算推理跑在你本机，prompt 和代码上下文依然可能发往远端——本地模型 ≠ 本地处理你的代码。对代码有合规要求的团队，这条必须读三遍。

第二，官方同时预告了「本地模型的智能路由」（intelligent routing with local models）。 细节指向了微软 Command Line 博客的一篇公告。智能路由的意思是：简单任务自动走本地小模型、复杂任务上云——如果落地，这将是 Copilot 第一次在「成本/速度/质量」之间替你做自动调度。

第三，工具调用是硬门槛。 能进列表的本地模型必须支持 tool calling，这实际上给本地模型划了条线：纯补全模型不行，得是正经的 agent 型模型。Ollama 生态里支持工具调用的模型不少，但质量参差——选模型之前先拿你的真实任务跑一圈，别只看参数量。

为什么是现在：三股力量撞到了一起

这条更新不是拍脑袋，是三股趋势同时成熟的结果：

一是本地模型真的能干活了。2026 年的本地模型在代码任务上的可用性，和两年前不可同日而语——改个小 bug、写个测试、解释一段祖传代码，本地 30B 级别的模型已经够用。云端大模型留给架构设计和疑难杂症，分工自然形成。

二是成本压力。Agent 式编程的 token 消耗是补全时代的数倍，高频次的小任务（改格式、补注释、跑单测修 bug）全走云端，账单肉眼可见地涨。本地模型跑这些「体力活」，边际成本接近零。

三是数据主权。越来越多团队的要求是「代码不出内网」，本地模型是目前唯一解——尽管如上文所说，Copilot 的遥测条款让这个「唯一解」打了折扣，真正的 air-gapped 场景还得看后续的离线模式演进。

给 vibe coder 的实操建议

1. 先分流，再谈替换。 别一上来就把主力模型换成本地。建议的分工：本地模型负责高频低风险任务（单测修补、格式整理、简单重构、文档生成），云端大模型负责架构决策和复杂 debug。等智能路由 GA，这个分工可能会被自动化。

2. 模型先过「工具调用」考试。 在 Ollama 里拉起模型后，先扔一个需要连续调 3-5 个工具的真实任务（比如「给这个模块加测试并跑通」），看它会不会中途掉链子。Tool calling 的稳定性比 benchmark 分数重要得多。

3. 遥测条款先看，再谈合规。 如果你的代码有保密要求，记住：/model 选本地 ≠ 数据不出网。去读 CLI provider 与离线模式的官方文档，把 COPILOT_OFFLINE 的行为、哪些数据仍会被发送，逐条确认后再进内网项目。

4. 盯住智能路由。 这是 Copilot 下一步最值得关注的功能点——「本地便宜模型打头阵、云端大模型兜底」的自动调度一旦好用，个人开发者的 token 账单可能直接砍半。

Ollama 侧的准备工作：三步就绪检查

Copilot CLI 只负责「发现」，Ollama 和模型得你自己先装好。就绪检查三步：

1. Ollama 在跑。 ollama serve 起服务，ollama list 确认模型已拉到本地。CLI 发现的是「运行中的 Ollama 实例里的模型」——服务没起，列表就是空的。

2. 模型支持工具调用。 这是硬门槛。在 Ollama 里先用 ollama run 简单验证：让它调个工具（比如读文件、跑命令），看能不能走完多步工具链。纯补全模型、老架构模型直接出局。

3. 显存/内存够。 本地模型的体验下限是硬件：显存不够就疯狂掉速，掉速到一定程度还不如走云端。先跑个真实任务计时——如果简单重构任务本地要 3 分钟、云端 40 秒，这分流就没有意义。

实测走一遍：从 /model 到第一个本地任务

完整流程大概是这样：升级 CLI 到 1.0.94-0；ollama serve 起好、模型就位；CLI 里敲 /model，在列表里找到本机模型，检查 provider 和 endpoint 无误后选「Add and use for this session」；扔一个低风险任务试水——比如「给这个函数补单元测试并跑通」，全程不用重启 CLI。

建议的试水任务分三级：第一级纯生成（写测试、写文档）——只读或低风险；第二级小步修改（修一个已知 bug）——看它调工具的稳定性；第三级才上真实需求。任何一级掉链子（工具调用中断、幻觉严重、速度不可接受），就退回云端模型——本地模型的引入应该是渐进的，不是信仰之跃。

智能路由前瞻：Copilot 的下一步棋

Changelog 里还藏了个预告：「本地模型的智能路由」（intelligent routing with local models），细节指向微软 Command Line 博客。按字面理解，这是 Copilot 第一次尝试按任务难度自动分流：简单任务本地小模型秒回，复杂任务自动上云端大模型。

如果落地且好用，它解决的是 vibe coder 最大的隐性成本：决策疲劳。现在每次开任务都要想「这个问题值不值得上大模型」——路由自动化之后，这个决策消失了，账单自动优化。这也是整个行业的共同方向（各家的路由功能、小模型降价都是同一逻辑）：2026 年下半场的竞争不在单个模型，而在调度。

不过在官方细节公布前，先别按这个做架构决策。预告就是预告，等 GA 再说——vibe 项目的铁律：不追预告，只追 GA。

和 Copilot App 的 provider 体验对比

这次 CLI 的更新，其实是把 Copilot App 里已有的 provider 体验（Settings → Model providers）补到了终端。两边的逻辑一致：「选哪个模型干活，由你决定」。区别在于场景：App 面向 IDE 里的交互式编程，CLI 面向终端里的 agent 式工作流——后者恰恰是本地模型最擅长的场景（批量小任务、脚本化调用）。

一个值得注意的信号：GitHub 正在把「模型选择权」从产品手里交还给用户。从云端模型全家桶，到 App 的第三方 provider，再到 CLI 的本地 Ollama，路线很清晰——Copilot 在从「卖模型」转向「卖调度」。对用户这是好事：模型越卷，调度层越值钱，而你站在收银台这边。

算一笔账：本地模型到底省多少钱

来算笔粗账。假设你每天让 Agent 跑 50 个小任务（补测试、修 lint、写文档），每个任务平均消耗 30k tokens。云端中等模型按每百万 tokens 约 3 美元计，一天 4.5 美元，一个月（22 个工作日）约 100 美元。如果其中 70% 的任务本地模型能胜任，月账单直接砍到 30 美元——省下的 70 美元，够买一块不错的硬盘。

但账的另一面是硬件和电：一台能流畅跑 30B 级模型的机器，显卡/内存投入是几千美元起步，外加常年开机的电费。结论是：如果你本来就有闲置算力（本地开发机、NAS、旧显卡），本地模型是纯赚；如果为了省 token 专门买卡，回本周期按年算——先拿现有机器试，别为省钱先花钱。

还有一笔不好量化的账：延迟。本地模型省了网络往返，小任务的端到端延迟经常比云端还低——「秒回」的体感对心流的价值，独立开发者都懂。

最后补一个视角：这次更新发在 10 月 7 日 Changelog 的「Improvement」区划里，而不是单独开博客大张旗鼓——说明在 GitHub 内部，本地模型支持已被视为「水到渠成」而非「战略发布」。当大公司开始用 Improvement 的口吻发这种功能，意味着本地模型是真的可用了，而不是停留在 demo。

一句话总结：Copilot CLI 接入本地模型，标志着编程助手从「云端大一统」走向「混合调度」。大脑可以放在本地，但别忘了看清条款——模型跑在哪，和数据去哪，是两回事。