GLM 系列接入 Continue.dev 配置指南：provider 设置与多轮对话问题排查
阅前说明 ：本文涉及的 GLM 模型 ID 均来自可用模型真值表。文中部分细节（如
name字段的具体触发条件）在不同 Continue.dev 版本间存在差异，请以你当前安装版本的官方文档为准。
适合谁看
- 正在用 Continue.dev 做 AI 辅助编码，想接入 GLM 系列模型的开发者
- 配置后发现多轮对话出现异常响应，不知道从哪里排查
- 想通过聚合网关一个 base_url 同时调 GLM 和其他模型
- 第一次在 Continue.dev 里接第三方模型，需要完整流程参考
整体流程
- 获取 API Key（智谱官方或聚合网关）
- 修改 Continue.dev 的配置文件------设置 provider 和 model ID
- 验证基础单轮对话
- 检测多轮对话是否正常
- 排查 messages 结构问题
- 跑通流式输出与多轮上下文
第一步：拿到 API Key
路径 A：智谱官方直连
登录 open.bigmodel.cn → 控制台 → API 密钥 → 创建新密钥。旧版控制台生成的 Key 为两段式 JWT 格式（xxxxxx.yyyyyy），新版控制台已改为标准 Bearer Token 格式（不含点号分隔）。以控制台实际生成的格式为准，不要依赖本文描述做格式校验。
路径 B：通过聚合网关
如果你同时需要调用 Claude、GPT 等模型，使用聚合网关更方便------一个 Key 切换多个模型，只需修改 base_url。目前常见的聚合网关包括 OpenRouter、Together AI、ofox.io 等，各平台支持的模型目录和定价策略各有差异，请直接查阅各平台当前的定价页面。
第二步：修改配置文件
Continue.dev 的配置文件路径：
- macOS/Linux：
~/.continue/config.yaml或~/.continue/config.json（早期版本） - Windows：
%USERPROFILE%\.continue\config.yaml或对应的config.json
Continue.dev 较新版本将配置文件迁移至 config.yaml，早期版本使用 config.json。请以实际存在的文件为准。
直连智谱官方的写法：
yaml
models:
- title: "GLM-5.3"
provider: openai-compatible
model: glm-5.3
apiBase: https://open.bigmodel.cn/api/paas/v4/
apiKey: your_api_key关于 apiBase 末尾斜杠：部分版本的 Continue.dev 会自动规范化路径，部分版本对斜杠敏感。建议保留末尾斜杠，遇到连接问题时可尝试去掉后对比。
apiBase为驼峰命名，是 Continue.dev 配置文件的字段规范；Python 代码中对应字段为base_url（下划线），两者命名风格不同属正常现象。字段名以当前版本官方文档为准。
走聚合网关的写法（以 OpenRouter 和 ofox.io 为例）：
OpenRouter 的配置示例：
yaml
models:
- title: "GLM-5.3 via OpenRouter"
provider: openai-compatible
model: zhipuai/glm-5.3
apiBase: https://openrouter.ai/api/v1
apiKey: your_openrouter_keyofox.io 的配置示例：
yaml
models:
- title: "GLM-5.3 via ofox"
provider: openai-compatible
model: glm-5.3
apiBase: https://api.ofox.io/v1
apiKey: your_ofox_key注意 ：model ID 的具体格式取决于你使用的聚合平台规范。部分平台要求带厂商前缀（如
zhipuai/glm-5.3），部分平台直接使用短名。请以你所用平台的模型目录为准。
provider 字段说明：
较新版本的 Continue.dev 使用 openai-compatible 作为通用的 OpenAI 兼容 provider；早期版本使用 openai。如果你的版本报告无法识别当前 provider 值，可尝试切换为 openai。
第三步：验证单轮对话
改完配置后重启 VS Code，在 Continue 面板发送一条简单请求，如"用 Python 写个快排"。能正常返回说明 Key 和 provider 配置没有问题。
常见报错参考：
AuthenticationError: Error code: 401 -
{'error': {'code': '1113', 'message': 'Invalid Authorization'}}API Key 格式不对或已过期，去控制台重新生成。
Error code: 400 -
{'error': {'code': '1210', 'message': 'model not found'}}model 字段与平台实际支持的 ID 不匹配，检查你所用平台的模型目录。
上述错误码来自智谱 API，具体含义以智谱官方文档为准，本文描述仅供参考。完整错误码列表见文末报错对照表（含 1301 等）。
第四步：检测多轮对话是否正常
单轮正常不代表多轮没问题。建议主动测试：在 Continue 面板连续对话 4 轮以上，观察第 4 轮及之后是否有异常（空响应、截断、报错等）。
关于 name 字段的问题：
Continue.dev 在某些版本和路径下，构建 messages 数组时可能会附加 name 字段。部分模型的 API 对 messages 中的额外字段处理方式不同------有的忽略，有的可能返回异常。
如果你遇到多轮对话异常，建议通过抓包或打印请求体的方式确认实际发送的 messages 结构，再针对性排查，而不是直接假设是 name 字段导致的。
第五步：排查 messages 结构
方法一：打印实际请求体确认问题
用 Python 脚本直接调用 API，对比带 name 字段和不带 name 字段的响应差异。此脚本为非流式调用，仅用于排查：
python
from openai import OpenAI
client = OpenAI(
api_key="your_key",
base_url="https://open.bigmodel.cn/api/paas/v4/"
)
# 构造带 name 字段的多轮对话（最后一条为用户消息，无对应 assistant 回复）
msgs_with_name = [
{"role": "user", "name": "u", "content": "第1轮"},
{"role": "assistant", "name": "a", "content": "回复1"},
{"role": "user", "name": "u", "content": "第2轮"},
{"role": "assistant", "name": "a", "content": "回复2"},
{"role": "user", "name": "u", "content": "第3轮"},
{"role": "assistant", "name": "a", "content": "回复3"},
{"role": "user", "name": "u", "content": "第4轮"},
]
r = client.chat.completions.create(
model="glm-5.3",
messages=msgs_with_name
)
print("带 name 字段:", repr(r.choices[0].message.content))
# 去掉 name 字段再试
msgs_clean = [
{k: v for k, v in m.items() if k != "name"}
for m in msgs_with_name
]
r2 = client.chat.completions.create(
model="glm-5.3",
messages=msgs_clean
)
print("不带 name 字段:", repr(r2.choices[0].message.content))通过对比结果可以判断 name 字段是否是问题所在。
方法二：使用官方 zhipuai SDK（仅限自行编写脚本的场景）
python
from zhipuai import ZhipuAI
client = ZhipuAI(api_key="your_api_key")官方 SDK 构建请求时通常不会附加 name 字段。此方式无法在 Continue.dev 中直接使用，仅适合自行编写调用脚本的场景。
关于
requestOptions.removeMsgFields：网络上部分资料提到可通过此配置项在 Continue.dev 中过滤 messages 字段，但经查 Continue.dev 公开文档及源码，该配置项并未出现在已知版本中。若你在某个版本的文档中确认了此字段的存在，可自行尝试；否则不建议依赖它作为排查手段。
GLM 系列模型速查
以下模型 ID 适用于直连智谱官方 API，走聚合网关时请以平台模型目录为准：
| 模型 ID | 定位 | 适合场景 |
|---|---|---|
glm-5.3 |
旗舰版 | 复杂推理、长上下文代码生成 |
glm-5.3-flash |
快速版 | 日常补全、速度与质量均衡场景 |
glm-5.3-flashx |
极速版 | 实时 autocomplete、高并发、对延迟要求极高的场景 |
glm-5.2 |
上一代旗舰 | 参考备用 |
glm-5.1 |
更早版本 | 兼容旧配置 |
glm-5 |
基础版 | 轻量、低频任务 |
glm-5-turbo |
加速版 | 相比 glm-5 延迟更低，适合高频调用；与 flash 系列定位不同 |
flash 与 flashx 的选择 ：flashx 是 flash 的进一步提速版本，延迟更低，但在复杂推理任务上可能不如 flash 稳定。Tab 补全优先选 glm-5.3-flashx，对话式问答优先选 glm-5.3。
关于 Function Calling ：glm-5.3 旗舰版对 tools 参数的支持较为完整；flash 和 flashx 系列的 Function Calling 支持情况请以智谱官方文档的当前版本为准，使用前建议确认。
不同场景怎么选
| 你的情况 | 推荐方案 | 原因 |
|---|---|---|
| 只用 GLM，不用其他模型 | 直连智谱官方 API | 少一层中转，调用路径更直接 |
| 同时用 GLM + Claude + GPT | 聚合网关 | 一个 base_url 管理多个模型 |
| 团队共用，需要用量管理 | 聚合网关 + 管理后台 | 按 Key 查看消耗，便于管理 |
| 只做 Tab 补全 | glm-5.3-flashx |
延迟优先 |
| 需要 Function Calling | glm-5.3 旗舰版 |
tools 参数支持最完整，flash 系列请先查官方文档确认 |
聚合网关方案中，OpenRouter、Together AI、ofox.io 均提供 OpenAI 兼容接口，apiBase 替换为对应平台地址即可；各平台在模型覆盖范围、请求路由策略上存在差异，建议根据实际需要查阅各平台文档后选择。
完整报错对照表
| 报错信息 | 可能原因 | 排查方向 |
|---|---|---|
Error code: 401 - {'code':'1113','message':'Invalid Authorization'} |
API Key 格式错误或过期 | 去控制台重新生成，注意新旧 Key 格式差异 |
Error code: 400 - {'code':'1210','message':'model not found'} |
model 字段与平台支持的 ID 不匹配 | 查阅所用平台的模型目录，确认正确的 model ID |
Error code: 429 - {'code':'1301','message':'Rate limit exceeded'} |
请求频率超限 | 降低并发或升级套餐 |
Unknown provider "xxx" |
provider 枚举值不被当前版本支持 | 较新版本用 openai-compatible，早期版本用 openai |
httpx.ConnectError: [Errno 11001] getaddrinfo failed |
DNS 解析失败，网络不通 | 检查网络环境，确认 apiBase 地址可达 |
| 多轮对话出现空响应或截断，无报错 | 可能原因多样，包括 messages 结构问题 | 打印实际请求体排查，参考第五步 |
常见问题 FAQ
Q: Continue.dev 的配置文件改完不生效怎么办？
需要完整重启 VS Code，不是重新打开 Continue 面板。另外检查 YAML 缩进是否正确------嵌套字段缩进错误会导致配置被忽略。
Q: 多轮对话异常只在 Continue.dev 里出现吗？自己写代码调 API 会不会？
如果你自己构建 messages 数组时没有附加额外字段，通常不会出现此类问题。如果使用了某些框架（如 LangChain 的消息对象 HumanMessage、AIMessage 等），建议发请求前打印 messages 结构确认实际内容。
Q: GLM-5.3 支持流式输出吗？
支持。Continue.dev 默认启用流式输出，配置文件中无需额外设置（如需关闭，请查阅当前版本官方文档中对应的配置字段）。自行编写脚本时加 stream=True 参数即可，返回流式 SSE 响应。
Q: 走聚合网关和直连智谱，延迟差多少？
延迟受网络环境、地理位置、并发情况等多种因素影响，差异较大。建议在自己的实际环境中实测，不同时间段的结果也可能不同。
Q: GLM-5.3-flash 和 GLM-5.3-flashx 有什么区别？
flashx 是 flash 的进一步提速版本，延迟优化力度更大，适合实时 autocomplete 等对响应速度要求极高的场景；flash 在速度和输出质量之间相对均衡。具体性能差异请参考智谱官方文档或在实际场景中对比测试。
小结
接入 GLM 系列模型的核心配置要点：
provider使用openai-compatible（较新版本），早期版本使用openaimodelID 以所用平台的实际模型目录为准- 遇到多轮对话异常时，优先通过打印请求体的方式定位问题，而不是直接套用某个固定解法
模型目录和 API 行为随版本迭代会有变化，请以智谱官网 open.bigmodel.cn 和 Continue.dev 官方文档的当前版本为准。