重磅，VS Code要做大模型的app store了

过去我们在 VS Code 里装扩展，心智模型一直很清楚：装语言支持、装调试器、装主题、装 Git 增强、装数据库工具。现在到了 1.125，VS Code 又往前走了一步：它开始把“模型”也当作一种可安装、可切换、可配置的基础能力。

这件事表面看只是 “Language Models” 页面多了一个入口，实质上却很不一样。因为它意味着 VS Code 不再把 AI 视为某个单独产品功能，而是在平台层承认一件事：未来 IDE 里的 AI，不会只来自一家，也不该只接一种。

这就是 model provider 机制最重要的意义。

model provider 到底是什么

简单说，model provider 可以理解成“给 VS Code 提供模型能力的后端来源”。它可能来自云端，也可能来自本地；可能是商业 API，也可能是企业私有部署；可能是通用大模型，也可能是专门针对代码任务优化过的模型。

在 VS Code 的设计里，用户真正要做的不是“给 AI 聊天框装一个皮肤”，而是：

1. 1. 安装对应的 provider 扩展
2. 2. 选择它提供的模型
3. 3. 配置认证、端点和默认行为

这套思路很像当年的 LSP。当年 VS Code 没有把每种语言硬编码进编辑器，而是让语言服务通过统一接口接进来；现在它也不打算把某一家模型写死在 IDE 里，而是让模型通过统一抽象层进入工作流。这不是小修小补，这是平台哲学。

怎么安装 model provider

从使用层面看，安装过程其实不复杂，核心就是“装扩展 - 选模型 - 配凭据”。

第一步：安装 provider 扩展

打开 Extensions 扩展市场，搜索你要接入的模型提供方扩展并安装。常见的 provider 类型包括：GitHub Copilot / Microsoft 生态模型、Azure 上的模型服务、OpenAI 兼容接口、本地模型运行器（如 Ollama）、云厂商模型平台等。

先点击模型选择栏里面的other model

就会跳转到

安装好之后，就会在other model里面出现新安装的model

到这一步之后，一般模型还需要额外的配置，这个时候vscode也会打开模型配置的json文件：chatLanguageModels.json

VS Code 并没有把“模型来源”做成一个单独封闭系统，而是继续延续它最擅长的扩展化策略。因为模型世界变化太快，今天流行这个，明天流行那个，如果编辑器要亲自追每一家接口，最后只会把自己拖成一个永远补不完的兼容层。让扩展承担接入，平台只维护抽象，这才是 VS Code 一贯成熟的做法。

第二步：选择默认模型

安装完 provider 后，下一步是在设置里选择默认模型。在现代 AI 编程场景里，模型已经不是越大越好，而是要看任务类型：代码补全更适合响应快的小模型；聊天问答需要更强的通用理解能力；重构和跨文件修改往往更依赖长上下文和稳定推理；本地敏感项目可能更适合本地模型或私有端点。

VS Code 把 provider 做成统一入口之后，未来最有价值的地方不是“能接更多模型”，而是能把不同模型按任务进行路由。这一步现在看像是设置项，往后看其实是调度系统的起点。

第三步：配置认证和端点

真正落地时，provider 的配置核心通常包括几类信息：API Key、Base URL / Endpoint、模型名或部署名、区域/项目/组织信息、本地服务地址和端口、代理/证书与企业网络设置。

为什么 VS Code 要这么做

如果只是为了“让 AI 能用”，其实最省事的做法很简单：直接和一家模型厂商深度绑定，内置聊天、内置补全、内置购买入口，全部打包，用户点开就能用。很多产品确实就是这么干的。

从用户角度来讲，以前接入大模型的最简单的方式解释api key，后面就始终使用这个api key 对应的模型，而安装model provider则给了用户更多的选择模型的机会。

但 VS Code 没这么走。它选择的是更慢、也更平台化的一条路：把模型能力抽象成 provider。我认为这背后有四个非常清晰的战略判断。

编辑器的生命周期很长，模型的生命周期很短。一个 IDE 可以统治十年，一个热门模型可能一年内就换代、降价、重排座次。如果 VS Code 把 AI 能力深度绑定到某个固定模型上，它就等于把自己的基础能力押注到一个变化极快的外部变量上。这在商业上危险，在工程上也不优雅。

做 provider 抽象的本质，就是把这层风险隔开：上层是稳定的 IDE 工作流，下层是不断变化的模型供应商。这样无论模型世界怎么卷，VS Code 自己都还能站在中间做“平台”。微软显然不想让 VS Code 变成某个模型的启动器，它想让 VS Code 继续做所有模型进入开发现场的总入口。

个人开发者在意的是“好不好用”，性价比高不高，企业更在意的是：数据会不会出内网、调用能不能审计、成本能不能控、模型能不能替换、合规策略能不能统一。如果 AI 入口只能绑死某一家服务，那么企业采用时会很痛苦。尤其很多公司并不想把所有代码和上下文都发给同一个外部提供方。

provider 模式恰好满足这种需求。它把“AI 是否可用”提升成“AI 如何被治理”。这一点很关键，因为真正能让 AI 进入企业开发主流程的，从来不只是模型能力，而是治理能力。如果一个工具只能 demo 很猛，却不能接企业权限、审计和网络策略，那它在大团队里永远只能做边角工具。VS Code 显然不满足于做边角工具。

统一 provider 层之后，AI 体验才有可能真正一致

现在很多 AI 编程工具最大的问题，不是模型不强，而是每接一家模型就像换一套产品逻辑：设置页面不同、对话能力不同、报错信息不同、历史记录不同。结果就是，开发者在切换模型时，不是在换“后端能力”，而是在换整套交互习惯。

VS Code 想做的显然不是这样。它想把差异留在 provider 层，把一致性留给用户层。无论你接的是本地模型、云模型还是企业模型，至少在 IDE 里：入口尽量一致、设置路径尽量一致、使用方式尽量一致、任务集成方式尽量一致。这种统一体验的价值，远比表面看上去大。因为 AI 工具真正难普及的地方，不是第一次用，而是长期用。长期用最怕的不是模型笨，而是工作流不稳定。

vscode的这一做法会极大强化 VS Code AI生态

这其实是我最看重的一点。过去十年，VS Code 最大的护城河不是编辑器本身，而是它把自己做成了一个生态底座。语言、调试、远程开发、容器、笔记本、主题、数据库、测试、Git 工作流，几乎所有重要能力最后都能被纳入扩展体系。现在 AI 也被拉进来了。

一旦模型 provider 变成标准入口，扩展开发者就不必各自重复造轮子：不用每个插件都重新写一套聊天 UI、鉴权流程、模型切换逻辑、错误处理面板。他们可以更专注于自己真正擅长的那部分：接某个平台、优化某类任务、提供某种模型能力、增加某个领域工作流。

这会带来一个很现实的结果：VS Code 会继续像当年吃掉编辑器生态一样，进一步吃掉 AI 编程接入层生态。以后很多模型厂商如果想进入开发者桌面，最合理的路径不是自己单独做一个 IDE，而是先成为 VS Code 里的一个 provider。

如果只看短期热闹，大家会更容易关注“哪个模型更强”“哪个回答更准”“哪个补全更快”。但从平台演进角度看，provider 抽象反而是更重要的那一步。

因为模型强弱会持续变化，今天领先的不代表明天还领先；可一旦编辑器先把“模型接入标准”和“统一工作流”掌握在自己手里，它就不怕外部世界怎么波动。说难听一点，模型厂商都想做入口，VS Code 则想继续做“入口的入口”。

这也是为什么我觉得 1.125 里安装 model provider 这件事，远比表面看起来更值得重视。它不是给 AI 加一个插座，而是在告诉所有人：

未来的 IDE，不会只内置 AI；未来的 IDE，会管理 AI。

而这，才是 VS Code 最可怕也最聪明的地方。