OpenClaw 换成 AIGoCode 后旧会话没切模型？先查 primary 再建新会话

默认模型改了，旧会话为什么还在用原来的模型

给 OpenClaw 写入 AIGoCode 配置后，检查命令已经显示新模型，回到 Dashboard 的旧会话却发现选择没有变化？先分清全局默认模型与会话当前模型。

AIGoCode 官方教程明确说明：最后配置的模型会成为新会话的默认模型，已有会话可能继续使用此前选中的模型。因此，验收不能只读默认值，也不能一直在原来的会话里反复发送消息。

本文围绕“配置已写入但会话没切换”这项任务，将 Provider、默认值、Gateway 与 Dashboard 分开检查，不替代完整安装教程。

向导跳过内置模型，不等于没有后续配置

官方 OpenClaw 接入教程先完成安装与基础设置，再选择 OpenAI、Claude 或 Gemini 之一接入。基础向导的 Model/auth provider 选择 Skip for now，Default model 选择 Keep current；教程解释，AIGoCode 是自定义 Provider，后续才写入 Key 和请求地址。

所以，向导当时显示的模型名称与目标不同，先不要据此反复重装。完成后续自定义 Provider 配置，再检查真正写入的默认值。本文不执行安装脚本，也不把教程中的终端命令当成已在你电脑上运行过的结果。

Provider 名称和 primary 要对应

官方三份配置使用不同 Provider 名称：aigocode-openai、aigocode-claude、aigocode-gemini。对应的 agents.defaults.model.primary 示例分别是 aigocode-openai/gpt-6-astra、aigocode-claude/claude-sonnet-5-5、aigocode-gemini/gemini-3.8-flash。

检查时要同时看前面的 Provider 标识与后面的模型 ID，不只看显示名称。若你刚添加了 Gemini 配置，却在默认模型里仍看到 OpenAI 那一项，应先核对自己最后写入了哪份配置，而不是把所有差异都归到 API Key。

文档的三路配置采用 models.mode 为 merge，并说明后续配置不会覆盖已经添加的模型。不过，“已有模型仍保留”和“默认模型仍不变”是两件事；最后配置的模型会成为新会话默认模型。修改自己已有配置前，仍建议保留副本并核对改动范围。

按协议匹配分组、api 和 baseUrl

下面是官方示例中的三组配套值，供你检查 Provider 本身是否接对。它们不构成全部可用模型或账号权限的承诺。

尤其注意 OpenAI 示例在 OpenClaw 中使用 openai-responses；不要因其他工具的教程讲 Chat Completions，就直接给这里换成同名猜测值。Key 也应来自该行指定分组，不能只改模型 ID 后假设协议与认证会自动匹配。

先检查配置，再重新启动 Gateway

写入配置后，按教程执行 openclaw config validate，再执行 openclaw config get agents.defaults.model.primary。前者应显示 Config valid，后者应显示你刚配置的模型。

这两个结果说明配置已经写入并通过教程要求的检查，但还不等于请求已经发出。继续执行 openclaw gateway restart，随后用 openclaw dashboard 打开界面。本文列出的是你自己验收时的步骤，没有替你在本机执行这些操作。

如果配置检查阶段就没有看到预期值，先回到配置本身；不要在 Dashboard 一直刷新，试图用会话操作修复尚未写入的默认值。

在新会话里核对模型，再发消息

浏览器打开后，新建一个会话，点击输入框下方的模型名称，明确选择刚配置的模型，再发送一条不含敏感信息的消息。也可以在已有会话手动切换，但要确认切换的是当前会话，而不只是修改全局默认设置。

验收需要两项同时对上：OpenClaw 能正常回复，AIGoCode 用量记录出现对应模型的请求。记录测试时间与模型 ID，有助于自己对照这次调用；不要把别的客户端的历史用量当成本次验证。

如果模型不可用，官方建议确认 Key 来自对应分组，并检查 Key 和请求地址。遇到 401、403、429 时转到错误码说明；也可以读本站401 与 403 的认证、额度排查。

结束时留三条明确结果：primary 的实际值、新会话选中的模型、对应请求的回复与用量记录。这样才能区分“默认值没写入”“旧会话没切换”和“请求本身失败”，避免对已经正确的 Provider 反复重配。