CCX：Claude / Codex / Gemini 多协议 AI API 代理网关部署与调度实战

CCX 是一个高性能的 AI API 代理与协议转换网关，以单端口统一承载 Claude Messages、OpenAI Chat Completions、OpenAI Images、OpenAI Embeddings、Codex Responses 与 Gemini 六类协议入口，内置 Web 管理面板、渠道编排、故障转移、多密钥管理与模型路由。本文基于仓库 README.md 与源码实现，完整讲解其架构设计、四种部署方式、核心环境变量、调度与高可用机制以及客户端接入方案，帮助读者从零搭建一条可承载 Claude Code、Codex、OpenCode 等 Agent 的统一网关。

项目定位与核心能力

CCX 的核心价值在于一个网关、一套密钥、六类协议：开发者只需部署一个二进制，即可把多个上游模型供应商（Claude / Anthropic、OpenAI、Gemini 等）聚合为统一入口，并为客户端提供协议自动转换、渠道故障转移和上下文感知的路由能力。

按 README.md 的 Feature 列表，其核心能力包括：

• 一体化架构：后端（Go）与前端（Vue 3 + Vuetify）集成，单端口部署，前端构建产物通过 embed.FS 嵌入后端二进制；
• 双密钥认证：PROXY_ACCESS_KEY 认证代理 API，可选的 ADMIN_ACCESS_KEY 认证管理界面与 /api/*；
• Web 管理面板：支持渠道管理、连通性测试、请求日志与监控；
• 六大协议代理：Claude Messages、OpenAI Chat Completions、OpenAI Images、OpenAI Embeddings、Codex Responses、Gemini；
• 智能调度：优先级、促销期（Promotion）、健康检查、故障转移与熔断恢复；
• 上下文路由：按模型真实上下文窗口与最大输出能力过滤候选渠道；
• 渠道级能力：每渠道多 API Key 轮换、代理（proxyUrl）、自定义请求头、模型白名单与路由前缀；
• Responses 会话跟踪：基于 previous_response_id 的多轮工作流支持；
• 单二进制部署：无需额外安装前端资源。

统一入口架构

CCX 对外只暴露一个后端入口（默认 :3000），按路径区分 Web UI、管理 API 与六类代理协议：

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/embeddings               -> OpenAI Embeddings proxy
  |- /v1/models                   -> Models API
  `- /v1beta/models/*             -> Gemini proxy

其中 Images 入口细分为三个子端点：POST /v1/images/generations（生成）、POST /v1/images/edits（编辑）、POST /v1/images/variations（变体）。详细设计见 docs/guide/architecture.md。

请求生命周期

从源码结构与 架构文档 看，一次代理请求的典型流程为：

Client
  -> Auth Middleware
  -> Route Handler
  -> Channel Scheduler
  -> Provider / Converter
  -> Upstream API
  -> Metrics / Channel Logs
  -> Client Response

分阶段看：中间件完成认证、CORS、压缩与请求日志；各协议 handler 解析请求并选择对应渠道类型；调度器根据渠道状态、优先级、促销期、Trace 亲和性与熔断状态选路；Provider 负责上游协议转换与流式/非流式响应处理；最后指标与渠道日志记录整个请求生命周期。

核心模块划分

对应 backend-go 目录结构，核心模块职责如下：

模块	路径	职责
配置	backend-go/internal/config/	维护 .config/config.json，支持热重载与配置备份
处理器	backend-go/internal/handlers/	六类代理与管理接口、模型查询、能力测试、日志与状态切换
上游适配	backend-go/internal/providers/	屏蔽 Claude、OpenAI、Gemini、Responses 等上游差异
协议转换	backend-go/internal/converters/	主要服务 Responses 场景的结构转换
调度	backend-go/internal/scheduler/	多渠道选路核心，管理优先级、促销期、亲和性与恢复
会话	backend-go/internal/session/	Responses 的 previous_response_id 会话跟踪与 Trace 亲和信息
指标	backend-go/internal/metrics/	渠道指标、历史统计、请求日志、熔断状态与持久化
中间件	backend-go/internal/middleware/	认证、CORS、压缩、日志

前端构建产物嵌入后端的机制可以在 backend-go/main.go 看到：//go:embed all:frontend/dist 将前端 dist 目录编译进二进制，这也是"单文件部署"的实现基础。

部署方式：四种途径

方式零：CCX Desktop（桌面端）

CCX Desktop 提供原生桌面体验，通过 GUI 管理渠道、密钥和客户端配置，适合不想接触命令行的用户：

平台	安装方式	说明
Windows	在 Microsoft Store 搜索 CCX Desktop	推荐方式，自动更新、无需手动签名；也可从 GitHub Releases 下载 setup.exe
macOS	brew tap BenedictKing/ccx && brew install --cask ccx-desktop	或下载 .dmg（arm64 / amd64）
Linux	下载 .AppImage	赋予可执行权限后运行

桌面端安装与配置流程详见 docs/en/guide/desktop/ 与 docs/guide/desktop/（中文）。

方式一：直接运行二进制

1. 从 Releases 页面下载最新可执行文件；
2. 在可执行文件同目录创建 .env：

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3688
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=en

3. 启动后访问 http://localhost:3000（APP_UI_LANGUAGE=zh-CN 可切换为中文界面）。

两个容易踩坑的细节（README 明确说明）：

• Windows 客户端无法访问 localhost：如果客户端运行在 cmd、PowerShell、WSL 或 Docker 中，且 localhost 无法到达 CCX，请改用 Windows 主机的局域网 IPv4 地址，例如 http://192.168.1.23:3000；
• 监听范围：BIND_HOST 留空时 CCX 默认通过 :PORT 监听所有网卡；需要仅本机访问时设置 BIND_HOST=127.0.0.1。

需要后台运行、开机自启动时，参考 docs/service/README.md（systemd / launchd / NSSM 等非 Docker 启动方式）。

方式二：Docker

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=en \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

使用 Docker Compose 后台运行：

docker compose up -d

启用 Watchtower 自动更新：

docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d

首次部署后如需立即拉取最新镜像：

docker compose pull ccx
docker compose up -d ccx

仓库自带的 docker-compose.yml 还包含一些开箱配置：./logs:/app/logs 日志持久化（可用 LOG_DIR=none 完全依赖 docker logs）、wget http://localhost:3000/health 的容器健康检查（30s 间隔、40s 启动宽限）、restart: unless-stopped 重启策略，以及 256M 内存 / 0.5 CPU 的资源限制建议。中国网络环境可使用 Dockerfile_China 本地构建镜像。

方式三：源码构建

前置依赖：Go 1.25+、Bun 与 Make（macOS 先执行 xcode-select --install）。

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make install   # 安装所有依赖（前端 + Go 模块 + 开发工具）
make run

常用开发命令（定义在根目录 Makefile）：

make dev           # 同时启动前端开发服务器与后端热重载
make run           # 构建前端并运行后端
make build         # 构建前端并编译后端（前端产物嵌入二进制）
make frontend-dev  # 仅启动前端开发服务器

make install 会依次执行 frontend && bun install、desktop/frontend && bun install、go mod download 并安装 Air 热重载工具与 Wails 3 CLI，一条命令完成全部依赖准备。

核心环境变量：认证、监听与运行模式

README 给出的最小核心变量组：

PORT=3688
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=en
LOG_LEVEL=info

结合 docs/guide/environment.md 与 backend-go/.env.example，完整参数族如下。

认证体系（双密钥 + 多额外密钥）

变量	说明
PROXY_ACCESS_KEY	代理访问密钥，必须设置，客户端用它调用代理 API
EXTRA_PROXY_ACCESS_KEYS=key-a,key-b	可选额外代理密钥（逗号分隔），仅为多个客户端分配入口，不提供用户管理、用量统计、模型权限或限速能力
ADMIN_ACCESS_KEY	管理界面与 /api/* 的独立密钥；未设置时回退到 PROXY_ACCESS_KEY。设置 EXTRA_PROXY_ACCESS_KEYS 后必须显式设置，且不能与任何代理密钥相同

安全提示：修改访问控制类环境变量后需要重启服务；生产环境建议用 openssl rand -base64 32 生成强随机密钥。

监听与本地 HTTPS

变量	默认	说明
PORT	3688（程序内部默认 3000）	监听端口
BIND_HOST	空	留空等价于 :PORT 监听所有网卡；127.0.0.1 仅本机访问
ENABLE_HTTPS	false	在当前端口同时启用 HTTPS 与 HTTP，适配 Claude Desktop 等只接受 HTTPS Gateway 的客户端
TLS_AUTO_CERT	true	未配置证书文件时自动生成含 localhost/127.0.0.1/::1 的临时自签名证书
TLS_CERT_FILE / TLS_KEY_FILE	空	必须成对设置，使用展开后的绝对路径；只设置其一会导致启动失败

如果客户端严格要求系统信任证书，可用 mkcert 生成受信任本地证书：mkcert -install 初始化本机 CA，再为 localhost、127.0.0.1、::1（以及通过局域网 IP 访问时的该 IP）生成证书，并写入 ENABLE_HTTPS=true、TLS_AUTO_CERT=false、TLS_CERT_FILE、TLS_KEY_FILE。Claude Desktop 报 remote error: tls: unknown certificate 即说明客户端不信任临时自签名证书。

运行环境与 Web UI

变量	说明
ENV=production	生产模式：Gin ReleaseMode、关闭 /admin/dev/info、严格 CORS；development 模式输出详细日志
ENABLE_WEB_UI=true	是否启用 Web 管理界面（false 为纯 API 模式）
APP_UI_LANGUAGE	Web UI 语言：en / id / zh-CN
LOG_LEVEL	error(0) / warn(1) / info(2) / debug(3)，info 不输出 debug 级

日志与指标持久化

变量	默认	说明
ENABLE_REQUEST_LOGS / ENABLE_RESPONSE_LOGS	true / false	请求与响应日志开关（默认值为 true，禁用需显式写 false）
QUIET_POLLING_LOGS=true	-	静默前端轮询端点日志
LOG_DIR / LOG_FILE / LOG_MAX_SIZE / LOG_MAX_BACKUPS / LOG_MAX_AGE / LOG_COMPRESS	logs / app.log / 100MB / 10 / 30天 / true	内置日志自动轮转与 gzip 压缩（实现位于 backend-go/internal/logger/logger.go 的 DefaultConfig）
METRICS_PERSISTENCE_ENABLED=true	true	SQLite 持久化历史指标，重启不丢数据
METRICS_RETENTION_DAYS=366	366	保留天数（3–366），支持查询最长 1 年历史

日志脱敏方面，项目自动对 API Key 只显示前 4 位 + 后 4 位（如 sk-a***b），对 Authorization、x-api-key 请求头完全隐藏（见 backend-go/internal/guardrails/credential_masker.go）。

运行时路径的 CLI 覆盖

命令行版支持用参数覆盖运行时路径（main.go 中 --config / --statedir / --logdir / --backupdir 的实现见 backend-go/main.go）：

ccx --config ~/.config/ccx/config.json --statedir ~/.local/state/ccx --logdir ~/.local/state/ccx/logs

• --config PATH：配置文件路径（默认 .config/config.json）；
• --statedir DIR：metrics.db、thinking_cache.db、conversation_state.json、scheduled_recovery_state.json、autopilot.db 等运行时数据写入目录（默认 .config）；
• --logdir DIR：日志目录，优先级高于 LOG_DIR；使用 none / null 可禁用日志文件写入（适合 systemd/journald）；
• --backupdir DIR：配置备份目录（默认配置文件同级 backups）；
• 路径中的 ~ / ~/... 会自动按当前用户主目录展开。

六类代理入口与管理 API

CCX 内建六类渠道，每类拥有独立的调度、指标和日志空间，避免不同协议互相污染健康状态（见 docs/guide/architecture.md）：

渠道类型	代理入口	管理入口	说明
Messages	/v1/messages	/api/messages/channels/*	Claude Messages 语义
Chat	/v1/chat/completions	/api/chat/channels/*	OpenAI Chat Completions
Responses	/v1/responses、/v1/responses/compact	/api/responses/channels/*	Codex / OpenAI Responses
Gemini	/v1beta/models/*	/api/gemini/channels/*	Gemini 原生协议
Images	/v1/images/generations、/v1/images/edits、/v1/images/variations	/api/images/channels/*	OpenAI Images
Vectors	/v1/embeddings	/api/vectors/channels/*	OpenAI Embeddings

完整代理入口还包括健康检查与模型查询：

端点	方法	说明
/health	GET	健康检查（无需认证）
/v1/messages/count_tokens	POST	Messages Token 计数
/v1/responses/compact	POST	精简版 Responses API
/v1/models	GET	聚合模型列表
/v1/models/:model	GET	单模型详情
/v1beta/models/{model}:generateContent	POST	Gemini 原生协议

渠道管理通用模式

对 type ∈ messages | responses | chat | gemini | images | vectors，存在统一的管理 REST 模式（见 backend-go/README.md）：

• 渠道 CRUD：GET/POST /api/{type}/channels、PUT/DELETE /api/{type}/channels/:id；
• 排序与状态：POST /api/{type}/channels/reorder（拖拽重排）、PATCH /api/{type}/channels/:id/status；
• 运行时控制：POST .../resume（恢复渠道与保护状态）、POST .../promotion（设置促销期）；
• 观测：GET .../logs、GET /api/{type}/channels/metrics、GET .../metrics/history、GET /api/{type}/channels/:id/keys/metrics/history、GET /api/{type}/models/stats/history；
• 探测：GET /api/{type}/ping（批量）、GET /api/{type}/ping/:id（单个）；
• Key 管理：POST .../keys（添加）、DELETE .../keys/:apiKey、POST .../keys/:apiKey/top|bottom（置顶/置底）、POST .../keys/restore（恢复被拉黑 Key）；
• 能力测试：POST /api/{type}/channels/:id/capability-test 启动、GET/DELETE .../capability-test/:jobId 查询/取消、POST .../retry 重试。仅 Messages、Responses、Chat、Gemini 四类文本协议支持，Images 与 Vectors 无此路由。

另外，大多数代理入口支持 /:routePrefix/... 前缀变体：默认路由只调度 RoutePrefix == "" 的渠道，带前缀路由只调度前缀精确匹配的渠道。RoutePrefix 是候选集隔离条件，不是同一渠道的可选 URL 别名。

渠道级能力配置

每个渠道（对应 config.json 中 *Upstream[] 项）可配置：

• 多 API Key 轮换：同一渠道挂多个 Key，调度时按序/按权重使用，失败自动切换到下一把；
• proxyUrl：为该渠道单独配置 HTTP / HTTPS / SOCKS5 代理；
• customHeaders：附加或覆盖上游请求头；
• supportedModels：模型白名单，支持空列表、精确匹配与通配符，调度自动跳过不支持当前模型的渠道；
• modelMapping：把客户端请求的模型名改写到实际上游模型；
• serviceType：上游服务类型（Vectors 渠道固定为 openai）。

调度与高可用：多渠道选路机制

调度器是 CCX 的核心，位于 backend-go/internal/scheduler/channel_scheduler.go 的 SelectChannel（实现见 select.go），按固定顺序决策，命中即返回：

顺序	机制	Reason	作用域	持久化	说明
0	驾驶舱手动覆盖（Override）	manual_override	per-user + per-kind	TTL，默认数小时	驾驶舱"切换 NEXT"设置的渠道序列，按序遍历，命中第一个健康且 active 的渠道；序列全不可用时自动清除并回退
1	促销期（Promotion）	promotion_priority	全局	持久（带过期时间）	处于促销窗口的渠道，绕过健康检查，给一次尝试机会
2	Trace 亲和性	trace_affinity	per-user + per-kind	内存	同用户粘性；存在更高 priority 的健康渠道时被覆盖
3	优先级排序	priority_order	全局	持久	按 priority 字段从高到低遍历，选第一个健康、active、未熔断的渠道
4	降级兜底	fallback_*	全局	-	所有健康渠道都失败时，选失败率最低的作最后尝试

该链路与源码吻合：select.go 中 manual_override 分支短路整个流程（select.go），promotion_priority 命中即返回（select.go），trace_affinity 会因 better_priority_available 跳过低优先级亲和渠道（select.go）。调度器还跳过 failedChannels（本次请求已失败的渠道）、非 active 渠道与处于 cooldown 的限速渠道；除 Promotion 外都要求渠道通过健康检查。

各机制关系要点：

• Override 排最前，命中即短路，不再走促销/亲和/优先级，是"per-user 临时强制路由"语义；
• 置顶/拖拽排序只改 priority 字段，影响第 3 步默认路径，不撼动 Override 与 Promotion；
• Promotion vs Override：Promotion 全局、持久、带时间窗口；Override per-user、TTL 内有效；
• Trace 亲和会被高优先级渠道抢走流量：调高渠道优先级或置顶，可把原本亲和绑定到低优先级渠道的流量迁移到置顶渠道。

上述机制在测试中有完整覆盖，例如 channel_scheduler_test.go 验证 promotion_priority、priority_order 命中，channel_scheduler_metrics_test.go 验证 trace_affinity 与 priority_order 的选择原因。

上下文路由：按模型真实能力过滤

上下文路由用于解决同一渠道组内不同模型上下文窗口不一致的问题。调度前 CCX 估算本次请求需要的上下文与输出预算，结合下游 agent 模型的内置 profile 得到最小上下文窗口要求，再按渠道 modelMapping 后的实际模型能力做资格过滤；该步骤只过滤不可用渠道，不改变用户在驾驶舱设置的渠道顺序。

能力来源优先级：

下游 agentModelProfiles
> CCX 内置 agent 模型 profile

渠道 modelCapabilities
> 全局 upstreamModelCapabilities
> CCX 内置模型能力库
> 渠道 defaultCapability
> unknown 策略

关键行为：

• modelCapabilities 的 key 匹配 modelMapping 后的实际模型名，支持与 supportedModels 相同的通配符形式；
• 未知能力模型默认只允许承载不超过 contextRouting.unknownSafeWindowTokens（默认 200000 tokens）的请求；渠道设置 allowUnknownContext=true 后可承载大上下文请求；
• 显式输出上限超过实际模型 maxOutputTokens 时过滤该渠道；
• X-Channel 指定渠道仍必须满足上下文与输出能力；
• Trace 亲和按上下文桶隔离，避免 1M 请求选中的渠道污染小上下文请求。

配置示例（来自 docs/guide/architecture.md）：

{
  "contextRouting": {
    "enabled": true,
    "defaultOutputReserveTokens": 8192,
    "unknownSafeWindowTokens": 200000
  },
  "upstreamModelCapabilities": {
    "vendor-1m-*": {
      "contextWindowTokens": 1000000,
      "maxOutputTokens": 128000
    }
  },
  "upstream": [
    {
      "name": "claude-1m",
      "modelMapping": {
        "sonnet": "claude-sonnet-4-6"
      },
      "modelCapabilities": {
        "claude-sonnet-4-6": {
          "contextWindowTokens": 1000000,
          "maxOutputTokens": 64000
        }
      },
      "defaultCapability": {
        "contextWindowTokens": 200000,
        "maxOutputTokens": 64000
      }
    }
  ]
}

故障转移、熔断与恢复

失败场景下调度器自动执行故障转移，并结合熔断状态与定时恢复逻辑控制重试范围。熔断相关参数（滑动窗口大小 METRICS_WINDOW_SIZE 默认 20、失败率阈值 METRICS_FAILURE_THRESHOLD 默认 0.7、连续失败阈值 5）可在运行时通过 Web/桌面调校台写入 config.json 的 circuitBreaker 并立即生效，环境变量仅作为启动兜底/旧部署兼容。流式请求还受三类流式健康检测约束：

字段	默认值	范围	说明
streamFirstContentTimeoutMs	90000	5000-300000	HTTP 200 后等待首个有效内容的时间
streamInactivityTimeoutMs	90000	1000-180000	首字后等待后续有效输出的空闲时间
streamToolCallIdleTimeoutMs	300000	30000-300000	工具调用 pending 阶段连续无上游 SSE 帧的 idle 超时

渠道级主动限速

每个渠道可配置主动限速，在请求发往上游前限流，规避免费/低额度上游的 RPM 限制导致的 429：

字段	默认	说明
rateLimitRpm	0	每分钟请求数上限（令牌桶填充速率 = RPM/60）；0 表示不限速
rateLimitBurst	0	令牌桶突发容量；0 时自动取 rateLimitRpm
rateLimitMaxConcurrent	0	同时进行的上游请求数上限（信号量）；0 不限并发
rateLimitAutoFromHeaders	false	解析上游 Retry-After / anthropic-ratelimit-*-reset / x-ratelimit-reset* 响应头做动态冷却

限速作用域是渠道级（同渠道所有 Key 共享令牌桶，符合"单账号跨 Key 共享额度"的上游计费模型）；被限速拦截时自动 failover 到其它可用渠道，调度器跳过 cooldown 中的渠道。

可观测性：指标、日志与运行时状态

CCX 提供三类核心可观测信息（见 docs/guide/architecture.md）：

1. 渠道指标：请求量、成功率、失败率、延迟，含全局统计与按模型统计历史数据（SQLite 持久化）；
2. 渠道日志：每渠道保留最近请求日志，记录 status（pending / connecting / streaming / completed / failed / cancelled）、statusCode、requestSource、interfaceType、baseUrl、keyMask（脱敏 key）等字段，Images 请求额外记录 operation（generations / edits / variations）；
3. 运行时状态：熔断状态、黑名单 Key 恢复、Promotion / Resume 等管理动作。

渠道编排界面与流量统计界面分别对应管理面板的两大核心视图，直接支撑上述调度与观测能力：

客户端接入：Claude Code / Codex / OpenCode

接入前需完成四步：启动 CCX 并确认网关地址（如 http://localhost:3000）；设置 PROXY_ACCESS_KEY；在管理面板为目标端点添加至少一个可用渠道；用 PROXY_ACCESS_KEY 作为客户端 API Key。

客户端与协议端点映射（见 docs/en/guide/clients/index.md）：

客户端	推荐端点	CCX Base URL	场景
Claude Code	Messages	http://localhost:3000	使用 Claude Messages 协议的编码助手
Claude Desktop	Messages	https://127.0.0.1:8443（需 HTTPS 包装）	不经官方登录、经由网关使用任意上游模型
Codex CLI / Codex App	Responses	http://localhost:3000/v1	使用 OpenAI Responses 协议的 Codex 工具
OpenCode	Chat	http://localhost:3000/v1	使用 OpenAI Chat 兼容协议的编码工具

注意 Base URL 规则差异：Claude Code 用网关根路径，Codex 与 OpenCode 通常使用 OpenAI 兼容的 /v1 前缀。各客户端的详细配置见 docs/en/guide/clients/claude-code.md、docs/en/guide/clients/codex.md 等页面（中文版见 docs/guide/clients/）。

常见排障：

症状	检查项
401 Unauthorized	客户端 API Key 必须等于 CCX 的 PROXY_ACCESS_KEY
Connection refused	CCX 是否运行并监听预期端口（curl http://localhost:3000/health）
model_not_found	渠道模型白名单与 modelMapping 是否覆盖请求的模型
请求始终未达渠道	客户端是否使用了预期的协议端点（六类入口之一）

小结

CCX 以"单端口、单二进制、六类协议"的形态解决了多供应商聚合接入的复杂度：README.md 定义的统一入口与双密钥认证、docs/guide/environment.md 给出的完整参数体系、以及 internal/scheduler 中可验证的"Override → Promotion → Trace 亲和 → 优先级 → 降级兜底"选路链路，共同构成了一个适合个人与团队自托管 AI 网关的完整方案。建议按本文顺序：先选定部署方式（Desktop / 二进制 / Docker / 源码），配置好认证密钥，再添加渠道、通过 Web 面板编排优先级，最后按客户端映射表接入 Claude Code、Codex 或 OpenCode 即可投入使用。