Continue IDE 助手接入统一 API

先说结论:一个带 provider openai 和 apiBase 的模型块

Continue 的 openai provider 接受 apiBase 覆盖,这是接入任何 OpenAI 兼容服务的文档路径。在 config.yaml 里加一个模型块,provider 设成 openai,apiBase 设成 https://api.kkaiapi.com/v1,填上精确的模型 ID 和你的 Key。这个模型就会出现在 Continue 的模型选择器里,它发出的每一次请求都走标准 /v1/chat/completions 打到网关。 同一个机制能覆盖任意数量的模型:一个 ID 一个块,全部共用同一个 apiBase 和 Key。因为 Continue 把 model 字段当纯字符串处理,不同厂商的 ID——Claude 挨着 GPT 挨着 DeepSeek——能并排待在一份配置文件里。

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.kkaiapi.com/v1
    apiKey: sk-你的kkaiapi密钥
    roles:
      - chat
      - edit
      - apply

Continue 怎么给模型分配工作:角色

Continue(GitHub 上的 continuedev,约 34K 星标)是给 VS Code 和 JetBrains 用的 IDE Agent,它的配置核心概念是角色。每个模型块带一个 roles 列表,Continue 会把不同类型的工作路由给持有对应角色的模型:chat 服务对话面板和 Agent 工作,edit 服务行内代码变换,apply 服务把改动合并进文件,再加上自动补全、embed、rerank 服务各自的子系统。 这正是让一个多厂商端点在 Continue 里特别有意思的杠杆。chat 想要你能负担得起的最强模型;edit 和 apply 是更短、更机械的调用,一个快速的中端 ID 就够。有了一个服务全部厂商的 apiBase,这个拆分纯粹是 YAML 的事:一个 Claude ID 持有 chat,一个快速 ID 持有 edit 和 apply,一个 Key 全覆盖。 有一条边界要说清楚:自动补全是填空式(FIM)的负载,Continue 的自动补全角色是围绕专门训练做这种补全格式的模型设计的。chat-completions 网关是 chat、edit、apply 流量的正确归宿;自动补全保留在你现在用的那套 FIM 能力的方案上,把这个角色分配给一个聊天模型不会得到好的建议。

完整配置:多个模型、拆分角色、声明上下文

配置文件在 ~/.continue/config.yaml。每个块的 name 是选择器里显示的标签;model 是网关提供的精确 ID。defaultCompletionOptions.contextLength 声明模型的上下文窗口,Continue 用它决定往一次请求里塞多少对话和文件上下文,长上下文模型如果留着保守的默认值,会比该发生的时间更早被截断。 能力大多能自动检测,但对 Continue 不认识的 ID,可以显式声明:capabilities: [tool_use] 告诉 Agent 模式这个模型可以驱动工具。 关于密钥:YAML 接受字面量 apiKey,对一份从不离开本机的本地文件来说没问题。Continue 也支持一种 secrets 模板语法 ${{ secrets.KKAIAPI_KEY }},给通过它的 hub 管理的配置用,能把字面值排除在共享文件之外。用哪种取决于你的配置文件放在哪里。

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.kkaiapi.com/v1
    apiKey: ${{ secrets.KKAIAPI_KEY }}
    roles: [chat, edit]
    capabilities: [tool_use]
    defaultCompletionOptions:
      contextLength: 200000

  - name: Claude Haiku 4.5
    provider: openai
    model: claude-haiku-4-5-20251001
    apiBase: https://api.kkaiapi.com/v1
    apiKey: ${{ secrets.KKAIAPI_KEY }}
    roles: [edit, apply]

  - name: GPT-5.5
    provider: openai
    model: gpt-5.5
    apiBase: https://api.kkaiapi.com/v1
    apiKey: ${{ secrets.KKAIAPI_KEY }}
    roles: [chat]

按角色选模型

角色分配同时也是比较的机制。固定住 edit 和 apply,把 chat 块每周换一个候选 ID,让按 Key 的用量视图在你真实的工作量上给出差价。每个候选只是三行 YAML,对着同一个端点。

• chat 承载 Agent 循环和长对话:读文件、规划改动、基于真实上下文回答问题。旗舰模型(claude-sonnet-4-6、gpt-5.5)属于这里,多数 token 也花在这里
• edit 处理选中代码的变换。调用比 chat 短、更机械,claude-haiku-4-5-20251001 或 gpt-5.4-mini 这类快速 ID 能让 edit 循环保持紧凑,不牺牲效果
• apply 把提议的改动合并进文件。是三个角色里最机械的,也是最适合放最便宜可用模型的角色,deepseek-v4-flash 完全够用
• embed 和 rerank 驱动代码库检索,是各自独立的子系统,把 chat 流量挪到网关不需要动它们

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

Continue 专属的翻车点

apiBase 没带 /v1。Continue 会在你给的 base 后面拼接 /chat/completions 这类路由路径,所以 https://api.kkaiapi.com/v1 是对的,裸域名不行。首次使用就出现 404 形状的错误,几乎都是这个原因。 YAML 缩进会悄悄改变配置结构。models 是一份块列表,一个缩进错位的 apiBase 会挂到错误的条目上,或者挂空。当一个模型能用、相邻的模型鉴权失败,先对比两者的缩进,再怀疑网关。 遗留的 legacy completions 开关。openai provider 默认用 /chat/completions,正是网关提供的接口。useLegacyCompletionsEndpoint: true 会把某个块重定向到遗留的 /completions 路由;如果某个块设了这个,那个模型的 chat 形态请求就会失效。 GPT 系 ID 上的 Responses API 期待。Continue 的某些路径可能会对特定 OpenAI 模型名尝试新的 responses 协议。chat-completions 网关不提供这个协议;如果某个 GPT 系块报出路由形状的错误,在那个块上设 useResponsesApi: false,让它留在 /chat/completions 上。 过时的 contextLength。Continue 按 defaultCompletionOptions.contextLength 打包上下文,不是按模型实际能接受的量。在一个 200k 模型上声明 32k 不会明显报错,只会悄悄丢掉你本该用上的上下文。按模型真实支持的数值声明。

哪些人会把 Continue 接到一个网关上

• IDE 优先的开发者,想在 VS Code 或 JetBrains 里选 Claude、GPT、DeepSeek,而不用为每家厂商维护一套凭证
• 按成本档拆分角色的团队:旗舰模型跑 chat,快速模型跑 edit 和 apply,每个角色放最适合的 ID,全部走一个计费面
• 在真实工作上对比 chat 模型的工程师,每个候选只是对着同一个 apiBase 加一个 YAML 块,不是新的供应商集成
• 标准化团队入职流程的负责人,一份 config.yaml 模板加一个 KKAIAPI_KEY 取代一份按厂商的密钥清单,按 Key 用量能看出每个人花了多少
• 手头没有某家厂商官方支付渠道的开发者,充值即用不需要海外卡

验证接入与排查首次请求

改 YAML 之前先列出网关提供了什么;/v1/models 返回的 ID 就是模型字段必须精确匹配的字符串。 首次请求的失败很有规律。401 意味着那个具体块里的 Key 不对,或者 secrets 引用没解析上;先查失败的那个块,而不是整份文件,因为 Continue 的 Key 是按块设置的,按块出问题。模型不存在的错误是 ID 拼错了,版本后缀也算。GPT 系 ID 上路由形状的错误指向前面提到的 responses API 开关。如果插件完全不显示自定义模型,说明 YAML 没解析成功,先校验文件结构。 请求跑通之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。因为 Continue 按角色拆分工作,用量视图也是第一个能看到你真实工作量里 chat 和 edit 流量比例的地方,这个数字才告诉你模型选择到底在哪里真正要紧。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

常见问题