Visual Studio Copilot 终于能用自定义模型了，但是用 mitmproxy 砸开的

VS Code 那边的 GitHub Copilot 早在几个月前就正式开放了 BYOK（Bring Your Own Key），Base URL、API Key、Model ID 三件套在 GUI 里点几下就能配齐。但隔壁那个真·Visual Studio——就是 Windows 上那个动辄几十 GB、做 .NET 和 C++ 开发离不开的重型 IDE——这件事一直没动静。

这两天 linux.do 上有开发者按捺不住，自己动手把这道墙凿了个洞。思路简单粗暴：既然改 Copilot 插件本体一直报错，那干脆不碰插件，直接在网络层做手脚——用 mitmproxy 拦截 api.anthropic.com 的请求，转发到本地任意一个兼容端点，同时伪造响应骗过 Copilot 对模型名的有效性校验。一晚上调通，能跑。

这事儿本身不算什么惊天技术突破，但它把 Visual Studio Copilot 用户憋了大半年的诉求摆到了台面上：为什么 VS Code 能做，Visual Studio 不能？

VS Code 和 Visual Studio，被微软区别对待

先理一下时间线，免得有人把两个 Copilot 搞混。

2025 年春天，VS Code 的 Copilot Chat v1.99 开始支持 BYOK，可以接入 Azure、Anthropic、Gemini、OpenAI、Ollama、OpenRouter 这些主流 provider。再往后，社区在 GitHub 上提的 issue（vscode-copilot-release#7518）推动微软进一步开放了「OAI Compatible」选项——任何兼容 OpenAI 格式的端点都能塞进去，DeepSeek、Kimi、通义、本地 Ollama、聚合平台，统统接得上。

到了这一步，VS Code 的 Copilot 在模型层面其实已经算半开放生态了。它走的是官方的 Language Model API，自定义模型享受和内置 GPT-4o、Claude Sonnet 一样的上下文注入、工具调用待遇，不是补丁式的二等公民。

但 Visual Studio 这边节奏完全不一样。微软官方文档里关于「在 Copilot Chat 中使用 AI 模型」的页面，长期只列了几个预置选项，BYOK 的入口若隐若现，自定义 endpoint 干脆没有。文档里还有一段挺有意思的免责声明：「使用自定义模型时，输出直接从提供程序返回，并可能绕过 Copilot 中负责任的 AI 筛选。对自定义模型的支持不适用于 Copilot Business 或 Enterprise 用户。」——翻译一下就是：企业版用户别想了，个人版用户用了出问题别赖我们。

问题是，Visual Studio 的用户画像跟 VS Code 完全不是一拨人。VS Code 上大部分是前端、Python、Go 这类轻量开发者，Visual Studio 上跑的是 C#、C++、游戏开发、企业级 .NET 项目，这群人往往受公司合规约束更紧，对内网部署、私有模型的需求反而更刚性。结果开放度反过来了，逻辑上说不通。

社区方案：mitmproxy 当中间人，骗过校验

回到这次的破解方案本身。原帖作者一开始尝试的是常规路线——直接反编译或者 hook Copilot 插件，把 endpoint 改掉。这条路在 VS Code 上有人走通过，但 Visual Studio 的 Copilot 插件结构不太一样，作者形容「一直报错遂放弃」。

于是换思路，从网络层下手：

1. 本地起一个 mitmproxy，作为系统级 HTTPS 代理
2. 拦截所有发往 api.anthropic.com 的请求，重写 host 到本地（或者任意一个兼容 Anthropic 格式的中转端点）
3. 伪造模型列表响应，把 Copilot 想要校验的模型名（比如某个特定版本的 claude-3.5-sonnet）写进 mock 数据里，让校验通过
4. 实际请求被路由到自己想用的后端——可以是本地的 Ollama，可以是任意聚合服务，可以是公司内网的私有模型

这个方案的好处是它完全不碰 Copilot 插件本体，升级 Visual Studio 或者 Copilot 不会让破解失效，只要 Anthropic 的协议格式不大改就行。坏处是配置门槛不低——你得装 mitmproxy、信任它的根证书、写好流量规则、保持代理常驻。对普通用户来说，这套链路调起来需要点耐心。

作者自己也承认这是「比较简单且粗糙的实现方法」。但「能跑」这两个字在这种灰色地带里就是硬通货。

为什么是拦 Anthropic 而不是 OpenAI？

细心的读者可能会问：Copilot 不是微软家的吗？跟 OpenAI 关系不是一直更近吗？为什么要拦 Anthropic 的 API？

答案是 Copilot Chat 现在对 Claude Sonnet 系列的依赖非常深。从去年 Claude 3.5 Sonnet 横扫各种代码评测开始，越来越多开发者把 Claude 作为日常编码主力，Copilot 这边也顺势把 Claude 系列加进了默认模型池。Visual Studio 的 Copilot 在调 Claude 时走的就是 Anthropic 官方端点。

这就给了拦截一个天然的切入点——只要伪装成 Anthropic API 的响应格式，后端实际接的是什么并不重要。Anthropic 的 messages API 协议本身相对干净，比起 OpenAI 那一堆历史包袱（chat completions、responses、assistants 三套并存），mock 起来反而容易。

这件事的连锁反应

往大了说，这种「用户自己动手凿墙」的现象，本身就说明 AI 编程工具的格局还没稳定。

一年前，Copilot 还能靠 GPT-4 的独家优势把用户锁在围墙里。但今年的情况是：Claude 4 系列在 SWE-bench 上压着 GPT 打，DeepSeek 的代码模型用极低成本逼近第一梯队，Qwen 和 GLM 在国内开发者群里口碑越来越好。任何一个 IDE 厂商如果还想把用户绑在自己钦定的两三个模型上，就是在跟整个市场对着干。

VS Code 想明白了，所以早早开放了 BYOK。Cursor、Windsurf、Cline、Roo Code 这些激进派更彻底，从第一天就支持自定义 endpoint，甚至在 Agentic Coding（自主编程）的能力上已经反超 Copilot Chat——能自动读写文件、跑测试、执行终端命令。

Visual Studio 这边显然没想明白，或者想明白了但内部决策慢半拍。结果就是社区用 mitmproxy 这种「黑帮手法」把功能补上了。

对开发者实际意味着什么

如果你是 Visual Studio 重度用户，这个破解方案值不值得折腾，取决于你的诉求：

• 想用国内可直连的模型：值得。Copilot 默认端点在国内访问体验一直不稳，走自己的代理顺便解决了网络问题
• 想用 Claude 最新版/特定 fine-tune 模型：值得。Copilot 预置的模型版本更新经常滞后
• 企业内网部署私有模型：值得，但要注意合规风险。文档明确说企业版不支持自定义模型，这条路可能踩雷
• 只是想省点 Copilot 订阅费：得算账。mitmproxy 这套链路维护成本不低，省下的钱可能还不够买杯咖啡

另外一个值得关注的方向是 API 聚合平台 的角色。这次破解方案里，「后端实际接什么」是完全自由的——你可以指向 OpenAI Hub 这类聚合服务，一个 Key 同时调 GPT、Claude、Gemini、DeepSeek，Base URL 配一次就行，省去在不同服务商之间反复切证书和配额的麻烦。对于已经在 mitmproxy 这条路上的人来说，把目标端点换成聚合平台几乎是顺手的事。

微软会堵这个洞吗？

大概率不会主动去堵。

首先，mitmproxy 这种方案对 Copilot 来说是不可见的——所有流量在客户端看来都是正常的 HTTPS 请求，没有任何 hook 或者篡改插件本体的痕迹。微软要堵就得引入证书 pinning，但这会破坏企业用户的代理审计、防火墙策略，得不偿失。

其次，社区压力摆在那里。GitHub 上关于 Visual Studio Copilot 自定义 endpoint 的 feature request 累积了几百个赞，开发者论坛上类似讨论层出不穷。微软如果还想留住这批用户，与其堵不如开。VS Code 那条路已经趟出来了，照搬到 Visual Studio 不是技术问题，是优先级问题。

我个人的判断是，Visual Studio 官方 BYOK 大概率会在今年内补齐，理由很简单：再不补，用户就要带着 mitmproxy 跑去用 Cursor 了。

写在最后

这事儿小，但折射的问题不小。AI 编程工具卷到现在这个阶段，模型本身已经不是壁垒——开发者要的是「我想用哪个模型就用哪个模型」的自由。任何一家工具厂商如果还在赌「我帮你选好的就是最好的」，注定会被社区用各种奇技淫巧凿出洞来。

mitmproxy 这一晚上的工作，可能比微软内部某个 feature request 排期会议要管用得多。

参考来源

• linux.do 社区：Visual Studio 的 Copilot 终于实现自定义 URL 和模型了 — 原帖作者分享的 mitmproxy 破解思路与实现细节
• GitHub Issue #7518：Add custom OpenAI endpoint configuration — VS Code 这边推动 BYOK 落地的关键 issue，可对比 Visual Studio 进度
• Reddit 讨论：在 GitHub Copilot 中配置自定义本地模型 — 社区关于 Copilot 自定义模型的多种实现路径讨论