📌 项目地址：BenedictKing/ccx | ⭐ 2,557 颗星 | 🔧 Go | 📜 未标注
一句话说清楚
CCX是一个Go语言写的AI API代理和协议翻译网关。它把你的应用和多个AI供应商（Claude、OpenAI、Gemini）之间的协议差异藏起来，统一成几个标准端点。同时内置了渠道管理、Key轮转、故障转移、熔断恢复这些生产环境必备的功能。
项目有2557个star，一个二进制文件部署，自带Web管理界面。
你实际面对的问题
同时用几家AI供应商，你得处理这些事：
- 不同供应商的认证方式、请求体格式、响应结构都不一样。Claude Messages API和OpenAI Chat Completions API的数据格式完全不同。
- 单个API Key有速率限制。OpenAI和Claude都限频，高并发下单Key撑不住。
- 供应商可能宕机。需要健康检查+自动切换到备用的能力。
- Key轮转、请求头注入、模型白名单限制。这些都要在代码里写if-else，改起来麻烦。
CCX直接把这些移到网关层。你的应用只认几个标准路径，背后连谁、怎么连，全在管理后台配置。
架构一瞥
CCX暴露一个后端入口（默认端口3000），按URL路径分发到不同上游：
Client -> backend :3000 ->
|- / -> Web UI
|- /api/* -> Admin API
|- /v1/messages -> Claude Messages proxy
|- /v1/chat/completions -> OpenAI Chat proxy
|- /v1/responses -> Codex Responses proxy
|- /v1/images/{...} -> OpenAI Images proxy
|- /v1/models -> Models API
`- /v1beta/models/* -> Gemini proxy图片接口目前支持三个：POST /v1/images/generations、POST /v1/images/edits、POST /v1/images/variations，用于生成、编辑和变体。你没有看错，路径上能看出它同时适配了Claude、OpenAI、Gemini三种协议。请求进来，CCX会做协议翻译和渠道调度。
快速开始
二进制部署
从Releases页面下载对应平台的二进制文件。启动时需要两个环境变量：
PROXY_ACCESS_KEY– 客户端请求代理时的认证密钥，必填。ADMIN_ACCESS_KEY– 登录Web管理后台的密钥，可选。只做代理不改配置的话，可以不设置。
运行：
export PROXY_ACCESS_KEY=your-proxy-key
export ADMIN_ACCESS_KEY=your-admin-key # 可选
./ccx浏览器访问http://你服务器的IP:3000。用ADMIN_ACCESS_KEY登录，然后添加渠道。
桌面版
README里有单独文档链接（CCX Desktop），给了桌面端的安装步骤。适合个人或开发环境，直接双击运行。
唯一的注意事项：Go二进制不带任何外部依赖，前后端界面都编译进去了。一个文件搞定，不需要Nginx或Node.js环境。
核心功能：渠道管理
CCX把每个上游服务称为“渠道”。渠道是调度的最小单位。每个渠道可以独立配置：
优先级和故障转移。高优先级渠道优先被选。CCX定期做健康检查，高优先级挂了，流量自动切到备用。你不用在代码里写条件判断。
API Key轮转。一个渠道可以配多个Key，自动轮替。应对OpenAI和Claude的速率限制场景。单Key跑满配速时，轮转机制自然分散压力。
HTTP代理。每个渠道单独指定HTTP代理。不同供应商走的网络出口不同：国内模型直连，海外模型经第三方代理。可以分别设置，互不干扰。
自定义请求头。转发时添加额外HTTP头。某些供应商需要在请求头里送用户ID、组织ID或认证token。
模型白名单。限制该渠道只能调用某些模型。防止测试环境误用GPT-4这类贵模型。这个特性在实际中很有用——开发人员写代码时容易忘掉限制，网关层兜底。
路由前缀。按路径前缀匹配复杂路由规则。比如让渠道A只处理/v1/messages开头的请求。
晋升窗口。设定一个时间段，临时提高该渠道优先级。适合灰度测试或A/B实验，让新渠道在特定时间内优先接收流量。
熔断恢复。连续错误率高，渠道会被自动熔断，过一段时间再尝试恢复。比简单失败重试更安全，保护上游服务不被过量请求打垮。
响应会话跟踪。支持多轮对话工作流。README只提了名字，内部实现细节没有展开。从命名推测，它能在网关层记录请求-响应的关联，方便调试。
管理后台
Web界面直接编译进Go二进制。启动后访问/路径就能看到。
后台几个关键页面：
- 渠道编排：拖拽调整渠道优先级，实时看健康状态。
- 添加渠道：配置上游服务类型、API Key、模型映射、请求参数。
- 流量统计：展示每个渠道的请求数量、成功率、响应延迟。
README里附了截图，界面简洁，功能指向明确。没有花哨的图表，就是几个数据表格。
我的看法
这个项目解决的是实际问题。多模型接入时的适配和运维负担，它用网关层的方式处理，不侵入应用代码。
Go单二进制加内置UI，部署成本很低。对于不想折腾基础设施的团队来说，这是个直接优势。不需要装数据库，不需要配反向代理，一个文件启动。
渠道级的控制粒度对应生产环境的真实需求。Key轮转、熔断、模型白名单，这些不是理论功能，是从实际运维痛点中长出来的。
缺点方面：README没有提供性能测试数据。如果我有百万QPS级别的并发需求，我会自己压测一下。文档以英文为主，但有中文版（README.zh-CN.md），细节还算清楚。
如果你团队手里有多个AI平台的API Key，想把接入逻辑统一、出错时自动切换，CCX值得试。花10分钟部署，看看能不能满足你的场景。