把 Continue、Cline 这类 VS Code 插件指向聚合站接口的配置实操
面向长期使用 VS Code 的开发者，说明如何把 Continue、Cline 等 AI 编程插件从官方接口切换到 OpenAI 兼容的聚合站接口：base URL 填在哪里、哪些字段可以填自定义 key、常见填错方式，以及用日志、用量记录、报错信息验证流量确实走了聚合站。
为什么这两类插件都能改 base URL
Continue 和 Cline 虽然定位不同（前者偏补全与对话，后者偏 Agent 式多步操作），但在模型接入层都走同一套抽象：OpenAI 兼容的 Chat Completions 协议。
这意味着它们天然接受三个可配置项：
baseURL/apiBase：请求发往哪个域名apiKey：随请求发送的凭证model：请求体里声明的模型名
聚合站只要暴露 OpenAI 兼容端点，插件就不需要任何改动，只改配置即可。
关键概念：base URL 到底填到哪一级
这是最容易出错的地方。OpenAI 官方 SDK 的 baseURL 约定是包含版本段、不含资源路径：
- 正确形态：
https://<你的聚合站域名>/v1 - 错误形态一：填成完整对话端点
.../v1/chat/completions（插件会自己再拼一次，变成双份路径） - 错误形态二：只填域名根
https://<域名>（缺/v1，多数插件不会自动补）
判断标准很简单：最终请求 URL 应该是 baseURL + /chat/completions。如果你填的 base URL 已经以 /chat/completions 结尾，就一定错了。
有些插件把这一项叫 baseURL，有些叫 apiBase 或 openAiBaseUrl，含义完全一致。
Continue 的配置位置
Continue 把模型定义放在配置文件里，而不是图形界面。典型流程：
- 打开配置入口（命令面板里搜索 Continue 的配置命令，或直接编辑用户目录下的配置文件）。
- 在
models数组里新增一项，provider选 OpenAI 兼容类型（openai或标注为兼容的 provider）。 - 在该项下写
apiBase、apiKey、model、title四个字段。 title是你在 UI 里看到的显示名，随便取，不影响请求。
哪些字段接受自定义 key： apiKey 字段接受任意字符串，插件不会校验它的前缀或格式。所以聚合站签发的 key 直接粘贴进去即可，不需要伪装成 sk- 开头（即便伪装了也不会更有效）。
Config 类插件通常还支持在配置里写 env 引用环境变量，把 key 放环境变量里比写死进配置文件更安全，尤其是配置会被同步到云端或提交进仓库时。
Cline 的配置位置
Cline 走图形界面为主：
- 打开 Cline 面板，进入设置。
- API Provider 选 OpenAI Compatible（不要选 OpenAI——选 OpenAI 会锁死到官方域名，base URL 输入框可能直接不出现）。
- 出现
Base URL输入框，填到/v1一级。 API Key填聚合站签发的 key。Model ID手动填写模型标识（例如你打算用哪个厂商的哪个型号，按聚合站文档给的名称原样填）。
这一步最常见的失败原因：Provider 选错。 很多人选了 OpenAI 之后发现没有 base URL 输入框，以为是插件不支持，其实是选错了 provider 类型。选 OpenAI Compatible 才会暴露自定义端点。
Model ID 是手填字符串，拼错不会在保存时报错，只会在发请求时返回模型不存在之类的错误——所以第一次配置完一定要实际发一条消息验证。
用哪些信号验证流量确实走了聚合站
配置填完不等于生效。下面几种验证方式从弱到强：
- 报错信息里的域名：故意填一个不存在的模型名发请求。如果返回的是聚合站的错误结构，说明请求确实打到了聚合站；如果返回 OpenAI 官方风格的错误，说明 base URL 没生效。
- 插件日志/输出面板：两个插件都有输出通道。打开后能看到实际发出的请求地址和状态码，这是最直接的证据。
- 聚合站侧用量记录：发几条消息后去聚合站后台看用量是否增加。这是端到端验证，能排除「插件本地缓存了响应」这类假象。
- 断网测试法：临时把 base URL 改成一个不可达地址，请求应当立刻失败。如果仍然成功，说明有别的路径在生效（比如另一个配置项覆盖了你的修改）。
验证时建议只发一条最简单的消息，不要一上来就跑 Agent 多步任务，否则排查面太大。
几个容易踩的坑
- 配置层级覆盖：Continue 可能同时存在用户级和项目级配置，项目级会覆盖用户级。改完不生效先检查是否有第二份配置。
- 尾部斜杠：
.../v1和.../v1/在部分实现里会被拼成//chat/completions。虽然很多服务端能容忍，但遇到 404 时优先检查这个。 - 模型名与 provider 不匹配：在 OpenAI Compatible 模式下填了某家厂商的模型名，通常没问题（聚合站负责路由），但前提是模型名拼写和聚合站文档一致，大小写敏感。
- 把 key 提交进 Git：如果项目级配置文件里有明文 key，记得加进
.gitignore或改用环境变量引用。
关于计费的常识性提醒
在这类聚合站上，你的调用按官方价乘以一个固定系数扣费，系数由站点定义；贡献自有 key 的人则按另一个系数获得返还。这两件事与插件配置无关——插件只负责把请求发出去，扣费发生在服务端。所以要核对用量，去看聚合站后台，而不是插件界面里的 token 统计（那个是插件自己估算的，可能和服务端计费口径不同）。
把插件指向聚合站，本质只是换了一个 OpenAI 兼容端点。真正需要小心的不是协议，而是配置项的层级、拼写和 provider 类型选择。