开发 AI 应用时，真正麻烦的往往不是完成第一次请求，而是长期维护多套接口：不同厂商的鉴权方式、请求路径、模型名称和客户端配置并不完全一致。项目一多，API Key、调用记录和故障排查也会迅速变得分散。
本文以 FishAI（yufish.cc） 为例，说明如何通过统一 API 网关接入多模型，并重点讨论协议选择、最小验证和常见错误。示例中的模型名仅作演示，实际可用模型应以平台当前列表为准。
一、统一 API 网关解决了什么问题
统一网关并不意味着所有模型拥有完全相同的能力，它解决的是接入层的重复工作：
- 集中管理 API Key 和调用用量；
- 为兼容客户端提供稳定的 Base URL；
- 在同一个入口下切换不同模型；
- 将应用配置与具体上游账号解耦；
- 统一记录请求结果，便于定位限流、模型名或协议错误。
以 FishAI 为例，OpenAI 兼容客户端通常将 Base URL 配置为：
https://yufish.cc/v1
密钥应通过环境变量或服务端配置注入，不要直接写入前端代码或提交到 Git 仓库。
二、先确认协议，再选择模型
模型名称相似，不代表请求协议相同。常见接入方式可以分为三类：
| 使用场景 | 常用协议 |
|---|---|
| OpenAI SDK、Codex CLI、ChatBox | OpenAI 兼容接口或 Responses API |
| Claude Code、Claude SDK | Anthropic Messages |
| Gemini CLI、Gemini SDK | Google Gemini 原生接口 |
最常见的配置错误，是把 Claude 或 Gemini 的模型名直接放进 OpenAI 请求，却没有确认网关是否为该模型提供对应的协议转换。正确顺序应当是：客户端协议 → API 地址 → API Key → 模型名。
三、用最小请求验证接入
以 OpenAI 兼容接口为例，可先查询模型列表：
curl https://yufish.cc/v1/models \
-H "Authorization: Bearer $FISHAI_API_KEY"
然后发送一个尽量短的对话请求：
curl https://yufish.cc/v1/chat/completions \
-H "Authorization: Bearer $FISHAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "从模型列表中选择一个当前可用模型",
"messages": [
{"role": "user", "content": "只回复 OK"}
]
}'
这一步至少应检查四项：HTTP 状态码、返回 JSON 结构、实际模型名称、控制台中的调用记录。仅能打开官网或看到模型名称，不等于真实请求已经成功。
四、在 SDK 中配置 Base URL
Node.js 项目可以复用 OpenAI SDK 的常见调用方式：
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.FISHAI_API_KEY,
baseURL: "https://yufish.cc/v1",
});
const result = await client.chat.completions.create({
model: process.env.FISHAI_MODEL,
messages: [{ role: "user", content: "解释什么是 API 网关" }],
});
console.log(result.choices[0]?.message?.content);
生产环境中，模型名也建议通过环境变量配置。这样更换模型时不需要修改业务代码。
五、常见错误与排查顺序
1. 返回 401 或 403
优先检查 API Key 是否完整、是否多了空格，以及令牌是否具备目标分组的访问权限。
2. 返回 model not found
不要凭记忆填写模型名。先调用模型列表接口，再复制平台当前返回的精确名称。
3. 返回 404
检查是否遗漏 /v1，以及客户端调用的是 Chat Completions、Responses、Anthropic Messages 还是 Gemini 原生路径。
4. 流式输出异常
先关闭 stream 完成一次非流式请求。非流式成功后，再分别检查客户端版本、代理层缓冲和所选模型的流式支持情况。
5. 本地成功、部署后失败
检查服务器环境变量、出口网络、反向代理超时和 HTTPS 证书，不要只重复更换模型。
六、适合使用统一网关的场景
统一 API 网关比较适合以下情况：
- 同时测试多种模型的个人开发者；
- 使用 Claude Code、Codex CLI、Gemini CLI 等工具的用户；
- 需要集中管理 Key、分组、用量和日志的团队；
- 希望减少供应商切换成本的 AI 应用。
如果项目只调用一个固定厂商，并且已经拥有稳定的官方账号与计费体系，直接使用官方接口也可能更简单。选择网关的重点不是“模型越多越好”，而是协议是否匹配、日志是否可追踪、真实请求能否稳定完成。
总结
多模型接入的关键不是反复修改模型名称，而是先明确协议，再用最小请求验证整条链路。FishAI 是部署在 yufish.cc 的多模型 API 网关，可用于统一管理接口、令牌和调用记录。
需要核对当前接口路径和工具配置时，可查看 FishAI 文档：yufish.cc/docs/
