Continue 接入 API 常见报错：401、404、429 与超时（2026）

Continue 是开源的 AI 编程助手，提供 VS Code 扩展、JetBrains 插件和 CLI，可以通过 OpenAI 兼容协议接入自建或第三方 API。配到网关后第一次请求就报错很常见，问题多集中在五层：凭证、地址、模型 ID、配额和网络。正确的顺序是先看状态码，再用最小请求复现，最后才动模型和上下文。本文给出一份可以直接照抄的 config.yaml 基线和排查清单。

状态说明：2026 年 Continue 已被 Cursor 收购，官方仓库转为只读、不再活跃维护。已有安装和社区分支仍可使用，但版本行为可能停留在收购前。本文基于 2026 年 10 月仍常见的 config.yaml 配置方式，排错思路对旧版本同样适用。

一、先分层：报错到底出在哪一层

不要看到报错就改模型，先按状态码分类。

状态码/现象	常见含义	先查什么	是否重试
401	Key 缺失、错误、失效或无权限	Key、认证字段、账号状态	不重试
403	Key 无该模型权限或被策略拦截	模型权限、团队设置	不重试
404	路径错误或模型不存在	`apiBase`、模型 ID	不重试
400/413	请求格式错误或上下文过长	上下文、参数、`max_tokens`	改请求后重试
429	请求频率、并发或 Token 配额超限	用量、共享 Key、重试策略	退避后重试
5xx	服务端错误或网关过载	服务状态、请求 ID	退避后重试
超时/连接失败	DNS、TLS、代理、防火墙或流式链路	网络与代理	修复后重试

排查时固定同一个 Key、地址和模型 ID，一次只改一项；一次改三处，恢复了也不知道原因。

二、配置基线：config.yaml 里只改三件事

Continue 的全局配置目录是 ~/.continue（macOS/Linux）或 %USERPROFILE%\.continue（Windows）。存在 config.yaml 时，它会优先于旧的 config.json 被加载，两种格式不能混写。一个可用的 OpenAI 兼容配置如下：

name: zsqh-gateway
version: 0.0.1
schema: v1

models:
  - name: 团队对话模型
    provider: openai
    model: <从模型列表复制的模型 ID>
    apiBase: https://api.zhongshangqihang.com/v1
    apiKey: <你的 API Key>
    roles:
      - chat
      - edit
      - apply
    capabilities:
      - tool_use

几个容易出错的点：

顶层必须有 name、version、schema: v1，models 是列表，缩进错了会直接解析失败。
兼容网关的 provider 选 openai；apiBase 通常填到 /v1 为止，不要自己拼 /chat/completions。
model 必须和网关模型列表里的 ID 完全一致，大小写、连字符、版本号都算。
roles 决定模型负责对话、编辑还是应用补丁；自动补全（autocomplete）对接口能力要求不同，普通对话模型不一定支持。
需要 Agent 模式调用工具时加 capabilities: [tool_use]，否则可能能聊天但不能执行工具。保存后如未生效，重载 IDE 窗口并查看日志。

三、401：先查 Key，再查认证字段

401 表示身份未通过验证，和模型能力、上下文无关。按顺序排查：

Key 是否完整复制，前后有没有空格、换行或引号。从聊天窗口复制最容易带隐藏字符。
Key 是否填在 apiKey 字段，并与 requestOptions.headers 中的认证头保持一致，避免重复或冲突。
Key 是否被删除、禁用或过期；账户是否有可用余额。部分网关在余额不足时返回 401 或 403，以错误体为准。
apiBase 是否指向 Key 所属的环境。测试环境的 Key 配到生产地址，通常也是 401。
配置文件是否真的被加载。改的是 config.json、实际加载的却是 config.yaml，就会出现「怎么改都没用」。

用一条最小请求先验证地址和 Key，排除 Continue 客户端因素：

export API_KEY="sk-你的密钥"

curl -sS -o /tmp/continue_resp.json -w "%{http_code}\n" \
  "https://api.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型ID>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

cat /tmp/continue_resp.json

返回 200 说明 Key、地址和模型基本可用；返回 401 就换到网关控制台的测试入口再试，不要自动重试。

四、404：Base URL 和模型 ID 各占一半

404 不一定是模型下线，最常见的是路径拼错：

apiBase 少写 /v1，请求打到站点的网页路由，返回 HTML 或 404。
apiBase 多写 /v1/chat/completions，客户端又自动拼一次，变成重复路径。
把控制台地址当成 API 地址、域名拼错，或在 OpenAI 兼容字段里填了 Anthropic 的 /v1/messages 路径。

模型 ID 也会造成 404 或 model_not_found：

大小写、连字符、版本号必须和模型列表完全一致。
模型可能未在当前账号或套餐开放，或在不同协议下使用不同的 ID。
配置界面能保存，不代表网关认可该 ID，要发真实请求确认。

排查时先访问 /v1/models（如果网关提供），从返回列表复制模型 ID，不要手打。

五、429：限流不是余额不足

429 表示请求超过速率、并发或 Token 配额。常见场景：

每分钟请求数、每分钟 Token 数或并发连接超限。
多人共用一把 Key，或 Agent 连续读文件、跑命令，短时间发出大量请求。
自动补全触发过于频繁，用户每敲几个字就发一次请求。
重试没有退避，越失败越发，形成重试风暴；长上下文请求也会挤占并发空间。

处理时先看响应头和错误体，不要盲目加倍重试。有 Retry-After 就按它等待，没有就做指数退避加随机抖动；401、403、404 不要重试。单 Key 多服务时按项目拆 Key；Agent 循环要设最大轮次和额度上限。

六、超时、流式中断与代理

超时通常不返回 HTTP 状态码，表现为请求长时间无响应、fetch failed、ECONNRESET 或回复到一半停住。排查顺序：

先用非流式、短上下文发一条请求。非流式通过，说明问题在流式链路或中间代理。
用 curl -N 直连测试，排除 Continue 客户端因素；同时检查代理是否缓冲了 SSE 响应。
检查证书链。企业代理做 TLS 检查时，需要通过 requestOptions.caBundlePath 指定 CA 证书；verifySsl: false 只适合临时调试。
检查系统时间是否准确，时间偏差过大会导致证书校验失败。
长任务要设超时和最大轮次；Agent 会连续发多轮请求，连接挂死时像「一直转圈」。超时字段因版本而异。

不要用 ping 判断 API 可用，它只证明主机可达，不证明 TLS 和路径正确。

七、上下文超限与请求体过大

上下文超限通常返回 400 或 413，错误体里会出现 context_length_exceeded、maximum context length 等字样。Continue 会把打开的文件、检索片段、引用和对话历史一起发送，实际上下文往往比看起来长。

处理方式：

用 .continueignore 或索引排除设置，把构建产物、日志、依赖目录排除掉。
关闭无关标签页，长文档先摘要，长对话新开会话。
降低单次请求的 max_tokens，先用短请求确认链路，再逐步加长。
如果只在大仓库里失败，优先怀疑检索塞进了过多片段。

八、IDE 日志怎么留，才方便排查

VS Code 中打开命令面板，选择「Developer: Toggle Developer Tools」查看 Console 输出；需要详细日志时启用「Continue: Enable Console」并重载窗口。JetBrains 查看 ~/.continue/logs/core.log，IDE 日志在「Help > Show Log」中。

日志至少记录：时间、状态码、错误码、模型 ID、apiBase 主机名、请求 ID、耗时和重试次数。请求 ID 通常在响应头里，名称可能是 request-id、x-request-id 或 x-oneapi-request-id，以网关实际返回为准。不要记录完整 Key、提示词和用户代码，Key 只留前后各四位。

一条可用的日志长这样：

2026-10-19T10:12:33+08:00 status=429 code=rate_limit_exceeded model=<模型ID> host=api.zhongshangqihang.com request_id=... latency_ms=1840 retry=2

九、排查清单

记录报错原文、状态码、发生时间和请求 ID。
用本文的 curl 命令复现，确认问题是否只在 Continue 内出现。
检查实际加载的是 config.yaml 还是 config.json，YAML 缩进是否正确。
检查 apiBase 是否到 /v1 为止，并从模型列表复制模型 ID。
换一把新 Key 测试，排除 Key 失效、额度或团队策略问题。
先用非流式、短上下文请求，再逐步加回流式和长上下文；必要时切换网络或代理。
以上都通过后，把日志和复现步骤提交给网关或插件支持。

十、常见问题

Key 在别的客户端能用，Continue 里却 401？

先看是否填错字段，再看 config.yaml 是否真的被加载。旧版 config.json 与新版 config.yaml 并存时容易改错文件；团队限制第三方 Key 时，本地配置再对也会失败。

404 一定是模型下线了吗？

不一定。多数情况是 apiBase 少了或多了 /v1，或者模型 ID 拼错。先访问模型列表，再复制 ID 测试。

429 是不是余额不足？

不一定。429 表示速率或配额超限，余额不足可能返回 401、402 或 403，以错误体和账单页为准。

为什么只有流式或自动补全失败？

优先怀疑代理缓冲、空闲超时和接口能力差异。流式问题先用非流式请求对照；自动补全失败则确认模型和接口是否支持补全或 FIM，不要直接把对话模型设为 autocomplete。

Continue 已停止维护，还值得配置吗？

已有安装和社区分支仍可运行，错误语义仍是 OpenAI 兼容接口那一套。新项目若要长期维护，建议评估仍在活跃开发的替代工具；只是复用现有环境的话，按本文顺序排查即可。

下一步

先在中商起航 AI 网关创建测试 Key，用本文的 curl 命令把鉴权、模型和流式各跑一遍，再填进 config.yaml。模型和价格以站内模型价格为准，价格会随供应商调整；排错时先固定变量，再逐项替换。