【开源】Unify Chat Provider —— 为 Github Copilot 接入自定义模型的 VS Code 扩展
- 内容介绍
- 文章标签
- 相关推荐
前言
折叠内容
Github Copilot 更新至今，可用性已经有所提高，能够满足大部分日常需求。
它的优势是价格便宜（10$ 或学生包）、按请求计费、上新模型的速度第一梯队、比较稳定。
我一般配合站内 Claude Code / CodeX 的中转站一起使用，是作为备用项的一个非常好的选择。
但是众所周知的缺点是它内置模型的上下文给的是模型自身上限的一半，并且经过实测模型的参数也没有拉满，比如 GPT 5.2 实测 Juice 值是 64，也就是只有 Medium。
CleanShot 2025-12-31 at 09.49.241964×916 49.8 KB
在最近的一个版本它开放了 Language Model API 接口，使得现在可以无缝地接入自定义模型。
自定义模型没有上下文限制，模型参数也可以随意调整，性能提升非常大（缺点是需自带 Key）。
而 Copilot 现在的用户体验我认为是比其它很多插件、命令行要更好的（仅次于 Cursor）；至于实际效果则是在极大型需求上比不上 Claude Code 做得好、做得快，但除此之外都是不错的。
由于能够非常方便地添加自定义模型，我也将其作为新模型上线后进行快速测试的工具。
优势
在我开发这个扩展之前已经有好几个扩展（GCMP、Addi…）实现了同样的功能。
但我仍然花时间开发这个扩展的原因有三点：
- 用户体验（UX）
- 无法发挥出模型的最佳性能
- API 兼容性
为什么无法发挥出模型的最佳性能？
当实际接入过 API 就会发现这件事没有那么简单。
如果你对 AI 直接下令，它可能在几分钟就能写好能够正常对话的版本。
但是也仅此而已，紧接着你可能会发现模型没有思考，或者根本没有触发输入缓存，导致效果欠佳，并且成本陡增。
于是就通过翻阅 OpenAI 或者 Anthropic 的官方文档，找到说明这些特性的文档并丢给 AI 继续实现对这些特性的支持。
实现完成并测试，以为万事大吉的时候，真正的挑战才刚刚开始…
第三方供应商所谓的兼容 XXX API，如果你不仔细阅读它的文档去实现，可能真的就只是兼容而已。
比如 DeepSeek，如果你直接使用 OpenAI 兼容的接口进行对话测试，可能你不会发现任何问题。
但之后的某次对话涉及到思考和工具调用，也就是所谓的 “交错式思考” 时，DeepSeek 接口直接就报错了。
由于 OpenAI Chat Completion API 根本没有设计承载思考内容的字段，所以造成了以下问题：
- 用户界面上没有思考内容。
- 交错式思考要求回传思考内容，而由于没有回传导致直接报错。
这时候去阅读 DeepSeek 文档 - 思考模式，才发现 DeepSeek 在 OpenAI 基础上使用非标准字段 reasoning_content 去传递和接受思考内容。
CleanShot 2025-12-31 at 11.00.051596×440 42.7 KB
恍然大悟，这才去兼容这个非标准字段。
但这其实是简化过的故事，实际上：
- 如果你真的没有阅读文档，那么在请求时没有发送另一个非标准字段
thinking，甚至模型可能都没有思考。 - 你不能够强行添加这些非标准字段，其它严格的供应商在你发送额外字段时会直接抛错拒绝！
- 你也不能不添加这些非标准字段，有些供应商在缺失字段时也会直接抛错拒绝！
- CleanShot 2025-12-31 at 11.00.431952×206 44.7 KB
- 你可能永远发现不了这些问题，因为 DeepSeek 至少还会对缺失
reasoning_content进行报错，而我接入过的大部分供应商只会在文档警告会影响模型性能，但是不会抛错，导致一直使用的并非满血模型性能。
最后举个例子，在最新的 GLM 4.7 中，引入了一个叫保留式思考（Preserved thinking）的特性：
CleanShot 2025-12-31 at 11.02.221508×630 107 KB
这要求你必须：
- 在请求时发送非标准字段
clear_thinking - 将完整的、未经过修改的
reasoning_content回传，并且必须与生成时的序列完全一致
而像这些具有以上五花八门的非标准特性的供应商，直到今天，自己逐个阅读文档并支持了的有约 26 个：
已支持供应商
| Provider | Supported Features |
|---|---|
| OpenAI | |
| Google AI Studio | |
| Google Vertex AI | |
| Anthropic | |
| xAI | |
| Hugging Face (Inference Providers) | |
| OpenRouter | |
| Alibaba Cloud Model Studio (China) | |
| Alibaba Cloud Model Studio (International) | |
| Model Scope (API-Inference) | |
| Volcano Engine | |
| Volcano Engine (Coding Plan) | |
| Byte Plus | |
| Tencent Cloud (China) | |
| DeepSeek | |
| Xiaomi MiMo | |
| Ollama Local | |
| Ollama Cloud | |
| ZhiPu AI | |
| ZhiPu AI (Coding Plan) | |
| Z.AI | |
| Z.AI (Coding Plan) | |
| MiniMax (China) | |
| MiniMax (International) | |
| Moonshot AI (China) | |
| Moonshot AI (International) | |
| Moonshot AI (Coding Plan) |
对于列出的供应商，使用这个扩展可以无需担心这些问题，能够发挥出模型的最大潜力。
你也可以看看你正在使用的扩展、应用，或者模型的第三方供应商，是否遵循了官方模型文档的最佳实践。
API 兼容性
对于 API 兼容性，这个扩展应该是同类中最全的，均为半手工实现：
- OpenAI Chat Completion API
- OpenAI Responses API
- Google AI Studio (Gemini API)
- Google Vertex AI
- Anthropic Messages API
- Ollama Chat API
国外几个主流模型开发商中，Grok 比较标准地采用了 OpenAI 的协议，所以无需额外兼容，而国内的开发商几乎都采用了 OpenAI 或 Anthropic 的协议。
用户体验（UX）
这方面评价比较主观，所以我就只列一下功能：
-
原生的 VS Code 可视化用户界面和多语言支持。
image1280×1118 61.9 KB
-
内置主流供应商，支持一键配置，无需繁琐配置，开箱即用。
image1280×1004 50.2 KB
-
内置主流模型的官方推荐参数，支持一键添加，无需调参即可发挥最大潜力。
image1286×1030 115 KB
-
支持从官方模型列表一键添加模型，支持自动同步官方模型列表。
image1286×928 39.8 KB
-
开放所有接口参数的调整，支持自定义 Header 与 Request 字段。
image1296×1040 47.2 KB
-
支持从其它应用或者扩展一键迁移配置，支持完善的导入导出功能，支持兼容云同步。
image1278×482 22.8 KB
-
支持 URI 一键导入配置。
感谢佬友阅读至此，如果该扩展帮助到了你，请给我一个 Star 以资鼓励：
GitHub - smallmain/vscode-unify-chat-provider: Integrate multiple LLM API providers into VS...
Integrate multiple LLM API providers into VS Code's GitHub Copilot Chat using the Language Model API.
- 欢迎大家使用并积极提交 Issue 或者 PR，我会认真地进行处理。
- 如果你是模型提供商或者中转站站长，邀请你添加一个 <Add to Unify Chat Provider> 的按钮，方便用户可以在 VS Code 一键使用你的服务！
--【壹】--：
太强了佬
--【贰】--：
太强了大佬
--【叁】--：
代码之前只读取了环境变量，我发布了 v2.1.4 版本，现在也会从 auth.json 读取了。感谢佬的反馈～
--【肆】--：
没问题，v2.1.4 已更新～
--【伍】--：
大佬牛逼啊
--【陆】--：
kilo 也是 cline roocode 那几个的 fork 吗？还没用过，我记得用 roocode 的时候没法直接在编辑器审查
--【柒】--：
有点意思，佬友厉害
--【捌】--：
我的意思是 各家api差异的部分抹平的工作 单独做成另一个开源项目,把国内各家五花八方的 api 转换成标准的
OpenAi Chat Completion API / Responses API
Anthropic Messages API
Gemini API
--【玖】--：
厉害了佬哥
--【拾】--：
佬 codex的一键迁移要如何配置key, 之前用的ccswitch配置的, key保存在auth.json中, 迁移的时候提示要配置env_key?怎么处理
--【拾壹】--：
感谢大佬
--【拾贰】--：
厉害啊老铁
是我没想过的借用方式
--【拾叁】--：
比起这个插件,我觉得佬把各家 api差异的部分抹平的工作开源成一个项目,通用面就更广了
有点类似 vercel ai sdk 的工作
--【拾肆】--：
可惜现在jetbrains的copilot还不能单独安装provider来接入其他api
--【拾伍】--：
如果你看过代码就知道这其实只是面向 Copilot Chat 做的工作
--【拾陆】--：
是的，这次也是想借这个项目先熟悉一下当前供应商的 API 采用情况。AI SDK 没有实际用过，看起来好像封装得比较上层，后续可能做类似抹平差异的项目。
--【拾柒】--：
大佬厉害，这个和kilo code比较哪个好用呀
--【拾捌】--：
感谢大佬！
--【拾玖】--：
大佬牛 厉害啊
前言
折叠内容
Github Copilot 更新至今，可用性已经有所提高，能够满足大部分日常需求。
它的优势是价格便宜（10$ 或学生包）、按请求计费、上新模型的速度第一梯队、比较稳定。
我一般配合站内 Claude Code / CodeX 的中转站一起使用，是作为备用项的一个非常好的选择。
但是众所周知的缺点是它内置模型的上下文给的是模型自身上限的一半，并且经过实测模型的参数也没有拉满，比如 GPT 5.2 实测 Juice 值是 64，也就是只有 Medium。
CleanShot 2025-12-31 at 09.49.241964×916 49.8 KB
在最近的一个版本它开放了 Language Model API 接口，使得现在可以无缝地接入自定义模型。
自定义模型没有上下文限制，模型参数也可以随意调整，性能提升非常大（缺点是需自带 Key）。
而 Copilot 现在的用户体验我认为是比其它很多插件、命令行要更好的（仅次于 Cursor）；至于实际效果则是在极大型需求上比不上 Claude Code 做得好、做得快，但除此之外都是不错的。
由于能够非常方便地添加自定义模型，我也将其作为新模型上线后进行快速测试的工具。
优势
在我开发这个扩展之前已经有好几个扩展（GCMP、Addi…）实现了同样的功能。
但我仍然花时间开发这个扩展的原因有三点：
- 用户体验（UX）
- 无法发挥出模型的最佳性能
- API 兼容性
为什么无法发挥出模型的最佳性能？
当实际接入过 API 就会发现这件事没有那么简单。
如果你对 AI 直接下令，它可能在几分钟就能写好能够正常对话的版本。
但是也仅此而已，紧接着你可能会发现模型没有思考，或者根本没有触发输入缓存，导致效果欠佳，并且成本陡增。
于是就通过翻阅 OpenAI 或者 Anthropic 的官方文档，找到说明这些特性的文档并丢给 AI 继续实现对这些特性的支持。
实现完成并测试，以为万事大吉的时候，真正的挑战才刚刚开始…
第三方供应商所谓的兼容 XXX API，如果你不仔细阅读它的文档去实现，可能真的就只是兼容而已。
比如 DeepSeek，如果你直接使用 OpenAI 兼容的接口进行对话测试，可能你不会发现任何问题。
但之后的某次对话涉及到思考和工具调用，也就是所谓的 “交错式思考” 时，DeepSeek 接口直接就报错了。
由于 OpenAI Chat Completion API 根本没有设计承载思考内容的字段，所以造成了以下问题：
- 用户界面上没有思考内容。
- 交错式思考要求回传思考内容，而由于没有回传导致直接报错。
这时候去阅读 DeepSeek 文档 - 思考模式，才发现 DeepSeek 在 OpenAI 基础上使用非标准字段 reasoning_content 去传递和接受思考内容。
CleanShot 2025-12-31 at 11.00.051596×440 42.7 KB
恍然大悟，这才去兼容这个非标准字段。
但这其实是简化过的故事，实际上：
- 如果你真的没有阅读文档，那么在请求时没有发送另一个非标准字段
thinking，甚至模型可能都没有思考。 - 你不能够强行添加这些非标准字段，其它严格的供应商在你发送额外字段时会直接抛错拒绝！
- 你也不能不添加这些非标准字段，有些供应商在缺失字段时也会直接抛错拒绝！
- CleanShot 2025-12-31 at 11.00.431952×206 44.7 KB
- 你可能永远发现不了这些问题，因为 DeepSeek 至少还会对缺失
reasoning_content进行报错，而我接入过的大部分供应商只会在文档警告会影响模型性能，但是不会抛错，导致一直使用的并非满血模型性能。
最后举个例子，在最新的 GLM 4.7 中，引入了一个叫保留式思考（Preserved thinking）的特性：
CleanShot 2025-12-31 at 11.02.221508×630 107 KB
这要求你必须：
- 在请求时发送非标准字段
clear_thinking - 将完整的、未经过修改的
reasoning_content回传，并且必须与生成时的序列完全一致
而像这些具有以上五花八门的非标准特性的供应商，直到今天，自己逐个阅读文档并支持了的有约 26 个：
已支持供应商
| Provider | Supported Features |
|---|---|
| OpenAI | |
| Google AI Studio | |
| Google Vertex AI | |
| Anthropic | |
| xAI | |
| Hugging Face (Inference Providers) | |
| OpenRouter | |
| Alibaba Cloud Model Studio (China) | |
| Alibaba Cloud Model Studio (International) | |
| Model Scope (API-Inference) | |
| Volcano Engine | |
| Volcano Engine (Coding Plan) | |
| Byte Plus | |
| Tencent Cloud (China) | |
| DeepSeek | |
| Xiaomi MiMo | |
| Ollama Local | |
| Ollama Cloud | |
| ZhiPu AI | |
| ZhiPu AI (Coding Plan) | |
| Z.AI | |
| Z.AI (Coding Plan) | |
| MiniMax (China) | |
| MiniMax (International) | |
| Moonshot AI (China) | |
| Moonshot AI (International) | |
| Moonshot AI (Coding Plan) |
对于列出的供应商，使用这个扩展可以无需担心这些问题，能够发挥出模型的最大潜力。
你也可以看看你正在使用的扩展、应用，或者模型的第三方供应商，是否遵循了官方模型文档的最佳实践。
API 兼容性
对于 API 兼容性，这个扩展应该是同类中最全的，均为半手工实现：
- OpenAI Chat Completion API
- OpenAI Responses API
- Google AI Studio (Gemini API)
- Google Vertex AI
- Anthropic Messages API
- Ollama Chat API
国外几个主流模型开发商中，Grok 比较标准地采用了 OpenAI 的协议，所以无需额外兼容，而国内的开发商几乎都采用了 OpenAI 或 Anthropic 的协议。
用户体验（UX）
这方面评价比较主观，所以我就只列一下功能：
-
原生的 VS Code 可视化用户界面和多语言支持。
image1280×1118 61.9 KB
-
内置主流供应商，支持一键配置，无需繁琐配置，开箱即用。
image1280×1004 50.2 KB
-
内置主流模型的官方推荐参数，支持一键添加，无需调参即可发挥最大潜力。
image1286×1030 115 KB
-
支持从官方模型列表一键添加模型，支持自动同步官方模型列表。
image1286×928 39.8 KB
-
开放所有接口参数的调整，支持自定义 Header 与 Request 字段。
image1296×1040 47.2 KB
-
支持从其它应用或者扩展一键迁移配置，支持完善的导入导出功能，支持兼容云同步。
image1278×482 22.8 KB
-
支持 URI 一键导入配置。
感谢佬友阅读至此，如果该扩展帮助到了你，请给我一个 Star 以资鼓励：
GitHub - smallmain/vscode-unify-chat-provider: Integrate multiple LLM API providers into VS...
Integrate multiple LLM API providers into VS Code's GitHub Copilot Chat using the Language Model API.
- 欢迎大家使用并积极提交 Issue 或者 PR，我会认真地进行处理。
- 如果你是模型提供商或者中转站站长，邀请你添加一个 <Add to Unify Chat Provider> 的按钮，方便用户可以在 VS Code 一键使用你的服务！
--【壹】--：
太强了佬
--【贰】--：
太强了大佬
--【叁】--：
代码之前只读取了环境变量，我发布了 v2.1.4 版本，现在也会从 auth.json 读取了。感谢佬的反馈～
--【肆】--：
没问题，v2.1.4 已更新～
--【伍】--：
大佬牛逼啊
--【陆】--：
kilo 也是 cline roocode 那几个的 fork 吗？还没用过，我记得用 roocode 的时候没法直接在编辑器审查
--【柒】--：
有点意思，佬友厉害
--【捌】--：
我的意思是 各家api差异的部分抹平的工作 单独做成另一个开源项目,把国内各家五花八方的 api 转换成标准的
OpenAi Chat Completion API / Responses API
Anthropic Messages API
Gemini API
--【玖】--：
厉害了佬哥
--【拾】--：
佬 codex的一键迁移要如何配置key, 之前用的ccswitch配置的, key保存在auth.json中, 迁移的时候提示要配置env_key?怎么处理
--【拾壹】--：
感谢大佬
--【拾贰】--：
厉害啊老铁
是我没想过的借用方式
--【拾叁】--：
比起这个插件,我觉得佬把各家 api差异的部分抹平的工作开源成一个项目,通用面就更广了
有点类似 vercel ai sdk 的工作
--【拾肆】--：
可惜现在jetbrains的copilot还不能单独安装provider来接入其他api
--【拾伍】--：
如果你看过代码就知道这其实只是面向 Copilot Chat 做的工作
--【拾陆】--：
是的，这次也是想借这个项目先熟悉一下当前供应商的 API 采用情况。AI SDK 没有实际用过，看起来好像封装得比较上层，后续可能做类似抹平差异的项目。
--【拾柒】--：
大佬厉害，这个和kilo code比较哪个好用呀
--【拾捌】--：
感谢大佬！
--【拾玖】--：
大佬牛 厉害啊