Continue API Key 配置教程：多模型、环境变量与安全（2026）

在 Continue 里配置自定义模型，Key 既是通行证，也是成本和安全的边界。Key 建得太随意，常见后果是额度被异常消耗、成员用量说不清、离职后旧 Key 仍在用。

2026 年 Continue 已被 Cursor 收购，官方仓库停止活跃维护，托管 Hub 与登录服务下线。Key 管理因此回到本地：一份 config.yaml、一个 .env、若干把按人和按用途拆开的网关 Key。本文按创建、存放、多模型、轮换、策略和排查说明。

状态说明：2026 年 6 月，Continue 被 Cursor 收购，官方仓库已转为只读并停止活跃维护；托管 Hub 与登录服务已下线。扩展和 CLI 仍可使用，但不再获得功能更新和安全补丁。

商标说明：Continue 是 Continue Dev, Inc. 的商标；Cursor 是 Anysphere, Inc. 的商标。本文仅作技术说明，与上述公司无隶属或代理关系；产品状态与配置字段以官方页面和当前安装版本为准。

一、先分清 Continue 里有几种 Key

“Continue API Key”这个说法经常被混用。实际配置时，至少有三类凭证，来源和用途完全不同：

类型	谁签发	用途	现在是否适用
网关 Key	中商起航 AI 网关等兼容服务	通过 OpenAI 兼容协议调用多家模型	适用，本文重点
供应商 Key	OpenAI、Anthropic、Google 等	直连对应厂商的官方接口	适用，字段和地址不同
本地模型	无 Key，如 Ollama、LM Studio	在本机或内网推理	适用，不涉及密钥
Continue 账号或 Hub 凭证	原 Continue 平台	登录、共享助手、团队配置同步	已随 Hub 下线，不再适用

所以，“Continue API Key”通常指你填入 apiKey 字段的模型侧凭证，而不是编辑器签发的万能密钥。本文讲网关 Key；它常见以 sk- 开头，但不能登录 Continue，也不能调用原平台接口。

二、创建网关 Key：先定边界再复制

创建前先想清楚：给谁用、用在哪个项目、最多消耗多少。

1. 打开中商起航 AI 网关注册页，注册并登录控制台。
2. 进入「API 密钥」，新建密钥。
3. 名称包含使用者和设备，例如 continue-zhang-macbook，不要只写 test。
4. 设置额度上限和过期时间；如果控制台支持模型范围，按项目限制可用模型。
5. 确认余额或充值状态，避免配置完成后才发现无法调用。
6. 复制 Key 到密码管理器，不要先发到聊天工具、工单或群里。

建议一人一 Key、一台设备一 Key。共享 Key 看似省事，但出了异常消耗时无法定位到人，离职后也不好判断该不该整体停用。模型和价格会调整，以模型价格页面为准。

三、把 Key 放进 .env，不要写进 config.yaml

Continue 支持在 config.yaml 里用 Mustache 语法引用密钥：

apiKey: ${{ secrets.ZSQH_API_KEY }}

然后在 .env 文件中定义变量的值：

# ~/.continue/.env
ZSQH_API_KEY=sk-你的网关密钥

注意几个细节：

• .env 的值不要加引号，按官方 FAQ 的格式写 KEY=value。
• 不要提交 .env 到 Git，把它加入 .gitignore。
• macOS/Linux 上可以执行 chmod 600 ~/.continue/.env，限制文件权限。
• 改完 .env 后重启 IDE，确保扩展重新读取。
• 如果 config.yaml 要提交到仓库，只保留 ${{ secrets.名称 }} 占位，不要写明文 Key。

把 Key 写进 YAML 也能运行，但配置文件一旦被复制、截图或提交，Key 就跟着扩散。用 .env 加占位符，配置可以共享，密钥留在个人环境里。

四、多模型配置：一把 Key 服务多个角色

Continue 的 models 是一个列表，可以放多个模型条目。每个条目有自己的 name、model 和 roles，也可以复用同一把 Key：

name: zsqh-continue
version: 0.0.1
schema: v1

models:
  - name: 主力对话与编辑
    provider: openai
    model: YOUR_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_API_KEY }}
    roles: [chat, edit, apply]
    capabilities: [tool_use]

  - name: 自动补全
    provider: openai
    model: YOUR_FIM_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_AUTOCOMPLETE_KEY }}
    roles: [autocomplete]

两种拆 Key 的方式各有用途：

• 一把 Key 服务多个模型：适合个人开发者，管理简单，账单集中。
• 按角色拆 Key：适合团队。对话、补全、嵌入各用一把，额度异常时能快速判断是哪类请求出了问题。

拆 Key 不是硬性要求，而是成本归属手段。小团队先按人拆，补全用量变大后再把 autocomplete 单独拆出。

自动补全模型必须是支持 FIM 的模型，不能因为“聊天模型也能写代码”就直接拿来补全。网关没有合适的 FIM 模型时，可以保留网关负责 chat、edit、apply，补全改用本地小模型。

五、环境变量与密钥解析顺序

Continue 在遇到 ${{ secrets.X }} 时，按下面的顺序查找：

1. 工作区根目录的 .env。
2. 工作区 .continue/.env。
3. 全局的 ~/.continue/.env。
4. 进程环境变量。

这里有两个容易踩的坑。

第一，IDE 扩展通常读不到你在终端里 export 的变量。官方 FAQ 明确说明，在 shell 里执行 export OPENAI_API_KEY=... 不会让 VS Code 或 JetBrains 里的 Continue 读到；进程环境变量主要对 Continue CLI 生效。所以“我在终端里设过了”不能作为排查结论，仍然要写 .env。

第二，工作区 .env 优先级高于全局 .env。打开不受信任的仓库时要留意其中是否带了 .env；团队应把 .env 加入忽略规则。

六、轮换、吊销与离职处理

Key 不应“建了就一直用”。建议按季度轮换，成员变动、设备丢失或疑似泄漏时立即轮换：

1. 在网关控制台新建一把同权限、同额度上限的 Key。
2. 把新 Key 写入对应位置的 .env，保留旧 Key 一段时间。
3. 重启 IDE，分别验证 Chat、Edit 和补全。
4. 在网关日志里确认新 Key 已产生正常请求。
5. 观察一到两天，确认没有遗漏的客户端。
6. 在控制台禁用或删除旧 Key。
7. 记录轮换日期、责任人和影响范围。

如果怀疑 Key 泄漏，顺序要反过来：先禁用，再排查。不要一边观察一边继续使用，异常消耗不会等你确认。禁用后检查请求日志、用量曲线和模型调用记录，确认是否存在非预期调用，再决定是否调整额度或报警规则。

成员离职、换机或项目结束时，当天禁用对应 Key，并提醒本人删除本地 .env。共享设备上的 Key 不应长期保留。

七、密钥存储与团队策略

• Key 只放在密码管理器和 .env，不要出现在代码、截图、工单、聊天记录和录屏里。
• 一人一 Key，按项目设置额度上限和过期时间；共享服务账号单独建 Key，并限制分发范围。
• 配置模板可以进仓库，但只保留 ${{ secrets.名称 }}；每个成员用自己的 .env 填值。
• 每月对一次账：按 Key、按模型、按成员看消耗，发现异常先禁用再排查。
• 给团队维护一份模型与 Key 的映射表，写清用途、责任人、额度、轮换日期。
• Continue 已停止维护，不要把 Key 管理寄托在插件自身的团队功能上；权限、审计和吊销都在网关侧完成。
• 网关日志可能包含请求元数据。涉及敏感代码时，先确认网关的数据保留和日志策略，再决定哪些项目允许接入。

安全策略的关键是回答三个问题：这把 Key 是谁的、能用多少、出问题后怎么停。

八、故障排查：401 与配置不生效

遇到 401，按下面的顺序查：

1. .env 是否存在，路径是 ~/.continue/.env 还是工作区 .env。
2. 变量名是否和 config.yaml 里的 ${{ secrets.名称 }} 完全一致，大小写也算。
3. 值的前后是否有空格、引号或换行；从聊天窗口复制最容易带隐藏字符。
4. 改完 .env 后是否重启过 IDE。
5. Key 是否被禁用、过期，账户是否有可用余额。
6. 实际加载的是 config.yaml 还是旧的 config.json。
7. apiBase 是否指向 Key 所属的环境，测试 Key 配到生产地址也可能返回 401。

其他常见现象：

• 404：apiBase 多了或少了 /v1，或者模型 ID 不存在。
• 429：额度、速率或并发超限，先看错误体和用量，不要盲目重试。
• 补全单独失败：检查 autocomplete 模型是否为 FIM 模型，以及是否用了另一把 Key。
• uses: 解析失败：Hub 已下线，把远程引用改成内联的 provider、model、apiKey。
• 模型选择器里看不到新模型：检查 YAML 缩进、roles 和保存后的重载状态。

排查时一次只改一个变量。同时改 Key、地址和模型，即使恢复了也无法判断原因。

九、常见问题

Continue 的 API Key 是 Continue 账号发的吗？

不是。Continue 本身不签发通用的模型 Key；你填的是模型供应商或网关签发的凭证。原 Continue 平台的登录与托管服务已经下线，更不能再当作 Key 来源。

为什么终端里 export 了 Key，IDE 还是 401？

VS Code 和 JetBrains 里的 Continue 通常读不到 shell 环境变量。把 Key 写进 ~/.continue/.env 或工作区 .env，然后重启 IDE。进程环境变量主要对 CLI 有效。

Key 可以直接写在 config.yaml 里吗？

能运行，但不建议。配置文件容易进仓库、被复制或截图。推荐用 ${{ secrets.名称 }} 占位，把明文值留在 .env 和密码管理器里。

不同模型必须用不同 Key 吗？

不必须。一把 Key 可以调用多个模型。拆 Key 的目的是区分责任、额度和账单，适合团队按人、按角色或按项目拆分。

Key 泄漏后第一步做什么？

先在网关控制台禁用这把 Key，再创建新 Key 替换。之后检查用量和请求日志，确认异常调用的范围，再决定是否调整额度、报警规则或其他凭证。

下一步

先在中商起航 AI 网关创建一把测试 Key，按“.env 存放、配置引用、重启验证”的顺序跑通，再复制成团队模板。模型可用性和当期价格以模型价格为准。

相关阅读：

• API 中转与代理怎么选：稳定性、计费与迁移
• 大模型 API 聚合平台怎么选：模型、账单与风险
• OpenAI 兼容 API 完全指南：Base URL、SDK 与迁移