原来能回复，换终端后先查哪一层

fx 已经接入 AIGoCode，同一份配置在一个终端能用，另一个终端却没有正常回复，先别急着改模型。可以把检查拆成两份：磁盘里的供应商配置，以及启动 fx 的终端中是否已设置配置所引用的 Key。

这是一条配置核对路线，不能只凭“换了终端”就认定故障来自环境变量；按下面步骤保留原配置、逐项验证，才方便继续排查。

先把 settings.json 中的引用连起来

官方 fx 接入文档使用 ~/.fx/settings.json 管理自定义服务商。示例不是把 Key 直接写进 auth.env，而是让它指向名为 AIGOCODE_API_KEY 的环境变量。

对照示例，可在本机逐项检查：

位置	官方示例	应核对的关系
顶层 `provider`	`aigocode`	是否选中准备使用的供应商键
`providers.aigocode`	供应商配置对象	是否存在与顶层选择相同的键
`models.aigocode`	`gpt-6-astra`	模型是否写在同一个供应商键下
`auth.type` 与 `auth.env`	`bearer`、`AIGOCODE_API_KEY`	前者描述认证类型，后者是变量名
`protocol` 与 `base_url`	`openai-chat-completions`、`https://api.aigocode.dev/v1`	是否仍是本页示例对应的协议和地址

检查的目的，是让供应商选择、模型条目和认证来源能对上。不要把真实 Key 填到应当填写变量名称的位置，也不要只改顶层供应商名而忽略下面的对应条目。修改前保留本机原配置，避免直接用整个示例覆盖已有服务商。

文档要求先在当前 macOS 或 Linux 终端设置 Key，再从已设置 Key 的终端启动 fx。这里只展示占位符命令：export AIGOCODE_API_KEY="sk-your-api-key"，实际操作时应在本机换成对应分组的 Key，不要把真实值贴进聊天、工单或公开仓库。

如果当前终端可以使用，而重新打开终端后又需要配置，核对 shell 配置是否按文档处理：zsh 对应 ~/.zshrc，bash 对应 ~/.bashrc。文档给出的做法是将上述 export 写入当前 shell 对应的配置文件，重新打开终端后生效。

不要为确认变量而把真实值打印出来。需要记录排错材料时，只记“已设置/未设置”、使用的变量名和启动方式即可。关于长期保存凭据的边界，可以继续看 API Key 本地保存与泄露处理。

上述示例对应 ChatGPT API（Azure）分组的 Key，文档同时要求使用支持外接调用的 OpenAI 兼容分组 Key。这不是“任意分组的 Key 配上同一模型名就能用”的承诺。

确认当前终端已设置 Key 后，按文档先运行 fx provider aigocode，再运行 fx。进入会话后发送一条简单消息，检查能否收到正常回复。本文没有进行真实模型调用，也不据此承诺你的环境已接通。

若仍失败，记录这次实际使用的供应商键、模型 ID、地址和脱敏错误，再查 AIGoCode API 排错日志整理。如果出现 HTTP 错误，保留状态码再进入对应分支，避免一次同时更换地址、Key 和模型，使对照失去意义。

完成核对后，可以只记录五项非秘密信息：fx 配置文件路径、当前供应商键、模型 ID、环境变量名，以及从哪个 shell 启动。真正的 Key 保留在本机合适的凭据位置。这份记录有助于下次换终端时先检查引用和加载步骤，而不是重新照抄一遍安装教程。

本文围绕官方页面中的 OpenAI 兼容配置展开；其他协议应按 fx 当前支持的接口类型分别配置，不能从本示例推导为所有协议共用同一套设置。