同时用 Claude Code、Codex 和 Gemini CLI？一个本地网关就能统一管理

2026年了，AI 让普通人也能实现自己的需求。Claude Code 年化收入超过 25 亿美元，Codex 周活用户突破 300 万，Gemini CLI、Qwen Code、Kimi CLI 等工具密集涌现。越来越多的工程师不再只用一个 AI 编程助手，而是同时运行两到四个 coding agent，让不同模型互相补充、互相审查。

但是多工具也带来了也大问题，比如配置管理和密钥安全。每个工具有自己的配置文件格式，API Key 跟天女的花似的，散落在 JSON、TOML、.env 文件中，模型切换需要手动改写多处配置，费用分散在不同的 Provider 账户里无从对账。这个问题不是 AI 模型能力能解决的，它需要一个专门的基础设施层。

ServBay AI Gateway 正是为此而生的本地 AI 网关。它运行在开发者自己的机器上，提供一个统一的本地端点，将所有 AI Provider 的密钥集中加密管理，并为 Claude Code、Codex、Gemini CLI 等主流编程工具提供一键接入。

为什么需要本地 AI Gateway

目前主流的 AI 编程工具各自维护一套独立的配置体系：

Claude Code 读取 ~/.claude/settings.json
Codex 使用 ~/.codex/config.toml
Gemini CLI 依赖环境变量和 Node 配置目录

同一个 OpenRouter 或 DeepSeek 的 API Key，要在三个地方各粘贴一次。一旦更换 Key，至少有一个地方会被遗漏。模型的协议格式也不统一，Codex 原生使用 OpenAI 的 Responses API，而很多第三方 Provider 只支持 Chat Completions 格式，直连会报错。

云端 AI Gateway（如 Portkey、Cloudflare AI Gateway）解决的是生产环境的可观测性和团队治理，但它们面向的是线上服务，而非开发者本机。本地开发场景有自己的特殊要求：

密钥不能离开本机
无需 Docker 或命令行即可启用
需要能直接接管各编程工具的配置
出错时要在本地就能完成排查

ServBay AI Gateway 是集成在 ServBay 桌面应用中的本地网关服务。安装 ServBay 后即可启用，不需要额外安装 Go、Python、Docker 或手写 YAML 配置。网关本身采用 Rust 编写，以独立二进制的形式运行在本地，通过代理端口 11580 接收 AI 请求，管理端口 11581 提供配置和监控接口。

统一接入：近 20 种 AI Provider 的本地管理中心

ServBay AI Gateway 内置了接近 20 种 AI Provider 的预设，覆盖了开发者常用的主流服务：

Provider 类型	代表服务
海外主流	OpenAI、Anthropic、Google Gemini
国产模型	DeepSeek、通义千问（Qwen）、Kimi
中转聚合	OpenRouter
本地推理	Ollama、LM Studio
自定义	任意 OpenAI 兼容端点

添加 Provider 时，选择对应预设、粘贴 API Key，网关会自动规范化 Base URL 并发起鉴权测试。验证通过后还会执行模型发现，列出该 Key 可用的全部模型。

对于自定义 Provider 或企业内部部署的模型服务（如 Azure OpenAI、AWS Bedrock 兼容端点），可以手动填写 Base URL 和鉴权方式。

虚拟密钥机制

每个通过网关接入的编程工具都会被分配一个专属的虚拟密钥（Virtual Key）。真实的 API Key 只存在网关的加密数据库中，编程工具的配置文件里写入的是虚拟密钥。

这带来两个好处：

降低泄露风险：即使某个工具的配置文件被误提交到 Git 仓库，暴露的也只是虚拟密钥，而非真实的 API Key。虚拟密钥只在本机网关上有效，离开了本机毫无用处。
按工具精细计量：每个虚拟密钥的请求和用量独立统计，能清晰看到 Claude Code 和 Codex 各自消耗了多少 Token、产生了多少费用。

虚拟密钥支持完整的生命周期管理------创建、轮换、撤销、过期设置，以及模型和渠道级别的权限控制。

一键接管 AI 编程工具

配置接管是 ServBay AI Gateway 与其他本地代理工具的一个明显区分点。

大多数本地代理工具的做法是提供一个地址，让开发者自己去修改各工具 of 配置文件。ServBay 的做法不同------它了解每种编程工具的配置文件路径和格式，能够一键完成配置写入。

目前支持一键接管的 AI 编程工具包括：

Claude Code
Codex
Gemini CLI
Qwen Code
Kimi CLI
CodeBuddy
OpenCode
Crush

接管流程包含几个安全措施：

写入前备份：在修改任何配置文件之前，ServBay 会对原始配置进行快照备份。如果原配置中已经存在其他设置（自定义的 MCP Server、个人化的规则文件等），这些内容不会被覆盖。
精确撤回：撤回操作只会移除 ServBay 写入的配置项，不会影响用户自己添加的其他配置。连续的接管和撤回操作是幂等的。
冲突检测：如果某个工具的配置已经指向了其他网关（比如用户之前在用 CC Switch 或其他代理），ServBay 能够识别并提示。

以 Claude Code 为例，接管后的配置变化大致如下：

json 复制代码

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:11580"
  }
}

所有发往 Anthropic 的请求都会经过本地网关，由网关使用真实的 API Key 向上游发起请求。整个过程对 Claude Code 透明，不需要修改任何使用习惯。

多协议转换与兼容

AI 工具生态中一个被忽视但影响很大的问题是 API 协议不统一。

OpenAI 有 Chat Completions API 和更新的 Responses API 两套接口。Anthropic 用的是 Messages API。Google Gemini 则是另一套协议。当开发者想用 Codex（默认走 Responses API）连接一个只支持 Chat Completions 的第三方 Provider 时，请求会直接失败。

ServBay AI Gateway 在代理层处理了这个问题。它能在请求经过网关时，将一种协议格式转换为另一种，包括流式响应（Streaming）、工具调用（Tool Call）状态的正确映射。编程工具发出的请求是原生格式，到达 Provider 的请求也是 Provider 能理解的格式，中间的转换由网关自动完成。

目前已经实现的协议入口包括：

OpenAI 兼容入口（Chat Completions、Responses、Embeddings、Images、Audio）
Anthropic Messages 入口
Gemini 入口

需要注意的是，并非所有协议组合都支持流式互转。特定方向的跨协议流式转换仍在完善中。

自动 Fallback 与负载均衡

当一个 Provider 出现故障或返回错误时，手动切换到备用服务会打断正在进行的编程任务。ServBay AI Gateway 提供了自动 Fallback 机制来处理这种情况。

可以为每个编程工具配置一组按优先级排列 of Provider 渠道。当首选渠道返回连接错误、5xx 状态码或超时时，网关会自动将请求转发到下一个可用渠道。编程工具端感知不到切换过程，正在进行的任务不会中断。

路由和调度支持以下策略：

策略	适用场景
优先级排列	明确的首选和备用 Provider
轮询（Round Robin）	在多个同类渠道间分散负载
加权分流	按比例分配请求到不同渠道
条件路由	根据额度、余额、成本等条件自动调整

网关还会对各渠道进行周期性的健康探测。连续失败的渠道会被暂时隔离，等待恢复探测通过后再重新加入调度。

一个需要了解的边界是：Fallback 机制最适合普通的模型推理请求。如果一个请求包含了有副作用的工具调用，自动重试到另一个 Provider 时可能产生重复执行的问题。

用量统计与成本监控

使用多个 AI Provider 和多个编程工具之后，费用追踪是一个真实存在的痛点。各 Provider 的计费界面分散，没办法在一个地方看到全局的消耗情况。

ServBay AI Gateway 因为处于所有请求的流经路径上，天然具备了聚合统计的条件。

网关记录的统计维度包括：

按时间：每日、每周的请求量和 Token 消耗趋势
按客户端：每个编程工具各自用了多少
按 Provider/渠道：每个上游服务的实际调用量
按模型：不同模型的使用频率和成本对比
成本估算：基于模型定价的费用汇总

统计数据支持 CSV 和 JSON 导出，方便做进一步分析或报表。

此外，网关提供了预算和配额机制。可以为虚拟密钥设置请求数限制、Token 上限或金额预算，达到阈值时自动拦截请求，避免费用失控。

需要说明的是，网关的用量统计是观测级别的数据，基于异步事件处理，不是精确到分的审计账本。在极端负载下可能存在少量事件丢弃的情况。如果需要严格的计费审计，仍应以各 Provider 官方账单为准。

ServBay 开发环境整合

与独立的 AI Gateway 工具相比，ServBay AI Gateway 有一个天然的差异化优势，它是 ServBay 本地开发环境的一部分。

ServBay 本身已经管理了 50 多种本地开发服务（MySQL、PostgreSQL、Redis、PHP、Node.js、Go 等）、域名与 DNS、SSL 证书、内网穿透。AI Gateway 与这些能力运行在同一个桌面应用中，共享安全基建（SQLCipher 加密数据库、严格的文件权限）。

这种整合带来了实实际际的好处：

无额外安装成本：不需要装 Docker、写 docker-compose.yml 或管理额外的进程。在 ServBay 中开启 AI Gateway 就像开启 MySQL 一样。
与 MCP Server 配合：ServBay 提供了自己的 MCP Server（支持 39 个工具），AI 编程工具通过 MCP 协议可以直接操作本地服务------创建数据库、启停服务、申请域名和 SSL 证书。这些操作的请求同样走网关统一管理。
macOS 和 Windows 双平台一致体验：网关的行为、配置接管逻辑、统计功能在两个平台上保持一致。这在本地 AI 工具管理领域比较少见------大部分社区项目只覆盖一个平台或以 CLI 为主。

与同类工具的比较

本地 AI 管理工具是一个正在快速发展的领域。目前市面上有几个不同思路的产品：

特性	ServBay AI Gateway	CC Switch	Claude Code Router
桌面原生 GUI	✅	✅	✅
无需 Docker/命令行	✅	✅	✅
macOS + Windows	✅	✅	✅
一键接管并备份	✅	✅	✅
虚拟密钥与权限	✅	部分	部分
自动 Fallback	✅	✅	✅
本地开发环境联动	✅	❌	❌
MCP/服务/数据库管理	✅	部分（MCP）	❌
用量/成本统计	✅	✅	✅
任务语义路由	规划中	部分	✅

CC Switch 在 MCP 同步、Session 管理和 Provider 预设数量上做得比较全面。Claude Code Router 在任务语义路由（根据 Background、Thinking、Long Context 等任务类型分配不同模型）方面走在前面。

ServBay AI Gateway 的差异化不在于单点功能的数量，而在于它和 ServBay 开发环境的深度整合。一个工具同时管理本地服务、数据库、域名、SSL、MCP 和 AI 模型接入，这是独立的 Gateway 工具做不到的。

适用场景和限制

适合使用 ServBay AI Gateway 的场景

同时使用 2 个以上 AI 编程工具，需要统一管理 API Key
持有多个 Provider 的 Key（比如 OpenAI + DeepSeek + OpenRouter），希望按任务灵活切换
在意 API Key 安全，不想让密钥散落在多个配置文件中
需要了解每天的 AI 使用成本分布

快速上手

开启 ServBay AI Gateway 的步骤如下：

下载并安装ServBay
打开 ServBay 应用，进入 AI Gateway 模块
添加 Provider，选择预设（如 DeepSeek），粘贴 API Key，等待鉴权验证通过
进入客户端管理，选择想要接管的编程工具（如 Claude Code），点击一键接管
在终端中正常启动 Claude Code，所有请求已经通过本地网关发出

如果需要添加 Fallback 备用渠道，在网关的路由设置中为当前工具再绑定一个 Provider 并设定优先级即可。

写在最后

AI 编程工具正在从单一工具走向多工具并行的工作流。模型的能力在快速提升，但围绕模型的配置管理、密钥安全、成本监控、故障切换这些基础设施层面的工作，一直没有得到足够好的解决。

ServBay AI Gateway 的思路是把这一层做进本地开发环境中，和已有的服务管理、域名配置、MCP 等能力放在同一个控制面板里。对于已经在用 ServBay 的开发者，这是一个几乎零成本的能力扩展。对于正在寻找本地 AI Key 管理和多工具统一接入方案的开发者，ServBay AI Gateway 提供了一个不依赖云端、数据不出本机的选择。