给 AI 编程助手装一个统一网关：用 New API / LiteLLM 管理多模型 Key

为什么需要网关

Claude Code、Codex、Gemini CLI 这类编程助手越来越好用，但 Key 越来越多：不同供应商、不同模型、不同价格，Key 散落在各个工具的配置里，轮换和统计都很麻烦。我的做法是在中间加一层统一网关：编程助手只连网关一个地址，Key、模型路由、限流都在网关里管。

常见选型有三个：New API（开箱即用的管理面板，渠道、令牌、日志、计费一条龙）、LiteLLM（纯代码/配置驱动，OpenAI 兼容接口，适合已有基础设施的人）、One API（轻量，适合个人）。我用的是 New API，因为要给多个编程助手发令牌，面板操作最快。

部署：一条命令起服务

New API 和 One API 都是单二进制 + SQLite/MySQL，LiteLLM 是 Python 包。选一个顺手的即可：

# New API 示例（Docker）
docker run -d --name new-api --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v /data/new-api:/data \
  calciumion/new-api:latest

装好后打开 http://服务器IP:3000，默认账号 root / 123456（第一时间改掉）。如果服务跑在云上，安全组只放行 3000 端口给自己的 IP，或者反代加 Basic Auth，别把管理面板裸奔在公网。

接入编程助手：一个地址，全员通用

网关的核心价值是 OpenAI 兼容的统一入口。以 Claude Code 为例，把它的请求转发到网关：

1. 在 New API 里添加渠道：填上供应商的 Base URL 和 Key，测试连通性，启用。
2. 在 New API 里新建一个令牌（Token），只给它需要用的模型权限。
3. 用社区的 claude-code-router 之类转发工具，把 Claude Code 的请求指向网关地址 + 这个令牌。

这样做的好处：

• Key 只存一处：供应商的 Key 只在网关里，编程助手这边拿到的只是网关发的令牌，泄漏了吊销令牌就行。
• 按用途发令牌：给工作机、家里机器分别发令牌，用量分开统计，超了就知道是哪台在烧。
• 换模型不用改配置：网关里做模型重定向（比如把 claude-3-5-sonnet 映射到实际可用的渠道模型），客户端配置不动。

踩过的坑

1. 流式输出被反代截断：Nginx 反代时记得关 buffering（proxy_buffering off;），否则编程助手的流式回复会一段段卡住。
2. 令牌额度设保守：New API 的令牌可以设额度，编程助手一次会话的 token 消耗比想象中大，先给足，观察几天再收紧。
3. 渠道优先级：多渠道时设置好优先级和权重，主渠道挂了自动切备用，别等半夜报错才发现。
4. 备份数据库：SQLite 文件定期备份，丢了就是丢了全部渠道和令牌配置。

一句话总结

编程助手只管写代码，Key、路由、账单都交给网关。花半小时搭好，以后加模型、换供应商、管额度都是一处操作——这就是基础设施该干的事。