Claude Code+LiteLLM+ECS：私人AI模型路由中心搭建指南-代码聚汇网

Claude Code+LiteLLM+ECS：私人AI模型路由中心搭建指南

Claude CodeLiteLLMECS

|难度：普通|阅读约 38 分钟

如果你最近一直在折腾 AI 编程工具，相信对 Claude Code 和 LiteLLM 这两个名字已经不陌生了。Claude Code 是 Anthropic 官方的终端智能体，能直接在命令行里帮你读代码、改文件、跑测试、提 PR，几乎把“AI 结对编程”拉满；LiteLLM 则是一个开源的大模型网关，可以把各种模型的 API 统一成 OpenAI 兼容格式，再接上 DeepSeek、Qwen、GLM 这些模型，让客户端只认一个地址。而 ECS，就是我们常说的云服务器，承担整个网关服务的长久运行。本文就把这三个东西串起来，给你一份能直接照着抄的完整部署指南。

这套方案解决的核心问题其实很现实：你不想给每款模型都注册一遍官方平台、管理一堆 API Key，也不想本地电脑关机后网关就跟着下线。把 LiteLLM 放到 ECS 上，再把 Claude Code 指到这台服务器的地址，就等于给自己建了一个“私人模型路由中心”。无论你主要用哪个大模型，Claude Code 这个壳都能稳定地接进去，想切换模型也只是改一行配置的事。这篇文章适合已经有一台云服务器、又想把 Claude Code 用出花样的开发者，也适合刚入坑、想少走弯路的小白，跟着走一遍就能跑通。

1. 项目概述：这套组合到底解决什么问题

先聊聊我为什么强烈推荐这个组合。用 Claude Code 的人通常分两种，一种是直接买了官方订阅，另一种是想把手上的国产模型 API 用起来。官方订阅当然省心，但如果你是团队协作，或者有成本敏感的业务场景，很多人的第一反应是想接入 DeepSeek、通义千问这类便宜又强的模型。问题在于，Claude Code 默认只认 Anthropic 自己的协议和地址，你不能直接丢一个“OpenAI 兼容地址”给它就算完事。

这时候 LiteLLM 的价值就出来了。它充当一个翻译层，把 Anthropic 的请求格式转换成目标模型认得的格式，再转发给 DeepSeek、Qwen、GLM 等任意上游。换句话说，你不需要改 Claude Code 的交互习惯，只需要在 LiteLLM 的配置文件里写好“哪个模型名对应哪个上游 API”，它就能全自动处理。

1.1 三个角色分别是什么

先做个简单的画像，方便后文对应：

Claude Code：终端里的 AI 编程助手。它通过 npm 安装，运行 claude 命令后会在终端里开启一个交互式会话，能读写项目文件、执行命令、调用工具，实际上是“跑在代理协议之上的智能体”。
LiteLLM：一个大模型 API 网关，提供统一的入口和鉴权。它支持几百种上游模型，能把非 OpenAI 协议转换成 OpenAI 兼容协议，也能把 Anthropic 的 /v1/messages 请求翻译给任意后端。
ECS：云服务器，或者你手头任意一台 7x24 小时在线的 Linux 主机。它负责跑 LiteLLM 服务，并对外暴露端口，让你的本地 Claude Code 随时可以连上来。

1.2 为什么不是直接用各家官方接口

直接对接官方接口的问题，在模型多了之后就变得非常明显。第一是鉴权分散，每个模型一个 Key，每个平台一个控制台，账期和额度统计五花八门。第二是格式不统一，有的 API 长得像 OpenAI，有的走自家协议，Claude Code 想要接入就得逐个适配。第三是没有灾备概念，某个平台临时限流，你的编码流程就卡住了。

有了 LiteLLM 网关，这一切都收口到一个地方：统一密钥、统一 API 地址、统一重试策略。就算今天 DeepSeek 的 API 抖动，你也可以在配置里把请求切到 Qwen 兜底，而 Claude Code 那边一切都无感知。这种“接入多模型但使用体验一致”的模式，才是现阶段 AI 编程工具落地比较舒服的姿势。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 整体架构与方案选型：为什么把网关放在服务器上

2.1 部署架构与请求链路

整个链路的走向很简单：

本地终端里的 Claude Code → HTTPS 或 HTTP 请求 → ECS 上的 LiteLLM 网关 → 上游大模型 API（DeepSeek、通义、智谱等）

整个过程里，你的 Claude Code 只需要配置一个环境变量，指向 ECS 的地址，剩下的模型分发统一交给 LiteLLM。你平时写代码时丝毫感觉不到中间多了一层，唯一的感受是“原来我可以用 Claude Code 直接驱动 DeepSeek 了”。

在架构上 LiteLLM 是有状态的吗？没有。它是个无状态代理，设计得极其轻量，重启也不丢数据。所以非常适合部署在单人开发机或小团队共享服务器上。

2.2 为什么选 ECS 而不是本地部署

我也见过有人把 LiteLLM 跑在本地笔记本上，省一张服务器钱。短期尝鲜可以，但长期用有几个硬伤：本地机器会休眠、IP 会变、带宽受家庭网络制约，团队成员想共用一个网关就只能干瞪眼。

相比之下，ECS 这类云服务器的优势是稳定且可控。选择一个低配的 2 核 4G 实例就够了，LiteLLM 本身占用资源极小，主要用于转发请求。这样你的网关是长期在线的，无论人在公司、在家还是在地铁上，只要网络通，就能连到同一个模型路由。将来加一台内网穿透或域名解析也方便，服务升级重启不会影响你的日常节奏。

2.3 备选方案对比

我整理了一个表格，把这些常见方案放在一起比较，方便你选型：

方案	稳定性	统一鉴权	成本	适合场景
本地直接装各类模型 SDK	低，依赖本机环境	无，Key 分散	最低	个人临时测试
本地跑 LiteLLM 网关	中，电脑关机即失效	有	低	单人开发，满足尝鲜
ECS 跑 LiteLLM 网关	高，常驻云上	有	每月几十元	主力开发，多模型切换
商业 API 聚合平台	高	有	有额外加价	不想自己运维、追求省心

如果你只是好奇玩一玩，本地跑 LiteLLM 完全可以；但只要你想把 Claude Code 当成日常主力编码工具，我强烈建议上 ECS。多花几十块钱，换来的是少折腾很多次“为什么连不上了”。

3. 部署前准备：服务器、域名、运行环境的取舍

3.1 ECS 服务器选型与初始化

先说服务器规格，LiteLLM 不涉及模型推理，它只做转发和格式转换，占用资源很少。我实测下来，2 核 4G 的实例跑它绰绰有余，带宽选 3M 到 5M 就够日常编码用了，毕竟请求体主要是一小段 JSON，而不是百兆级的大文件。操作系统优先选 Ubuntu 22.04 或 Debian 12，这类系统生态好、依赖安装简单，遇到问题也好搜。

服务器购买完之后第一件事是设置安全组。以阿里云为例，控制台里的“安全组规则”或“防火墙”需要放行你需要暴露的端口。如果你只打算用 HTTP 跑内网测试，就仅仅放行 4000；如果后面要配 HTTPS，则需要把 80、443 一并放行。记得不要把端口开成 0.0.0.0/0 之外的乱七八糟来源，只放行你自己的办公网 IP，或者干脆先全放开测试，等配置完 HTTPS 再收窄。

安全组这一块是新手最容易踩的坑，很多时候你发现服务起了一切正常，但本地就是连不上，十有八九是端口没放行。检验防火墙是否正常的命令很简单：

bash复制# 在本地机器上执行，观察是否能连通 ECS 的 4000 端口
nc -vz <ECS公网IP> 4000

如果 nc 提示 Connected to，说明端口通；如果卡住不动或者 Connection refused，那就要去服务器安全组和本机防火墙两层排查。

3.2 域名与 HTTPS 的取舍

如果只是个人开发，用 IP 地址直连完全可以，不用折腾域名。不过有两个场景建议上域名：一是要把服务共享给团队，写 IP 加端口既不专业也不方便记忆；二是当你想在浏览器里访问 LiteLLM 自带的 UI 控制台时，HTTPS 能避免 API Key 被中间人截获，开发者工具里查看请求也干净一些。

域名解析只需要一条 A 记录指向 ECS 公网 IP，然后用 Caddy 自动申请证书，它比 Nginx 简单太多，后面我会单独讲。你要是暂时不想搞域名，那么就老老实实把 API Key 管好，别在不信任的网络上裸奔调用。

3.3 本地环境要求

Claude Code 的安装依赖 Node.js 和 npm，官方要求 Node 版本一般在 18 以上，建议直接上最新的 LTS 版本。Windows 上要么用 WSL，要么用原生的 PowerShell 环境；macOS 和 Linux 就没什么可说的，装好 Node 直接走。

安装 Claude Code 的命令非常简单：

bash复制npm install -g @anthropic-ai/claude-code

装完之后执行 claude --version，能输出版本号就说明安装成功。注意新版 Claude Code 对 Node 版本要求变高了，如果你安装时报 engine 相关的错误，多半是 Node 版本太旧，升级 Node 到 20+ 即可解决。

4. 在 ECS 上部署 LiteLLM：两种方式任选

4.1 用 Docker Compose 跑起来（推荐）

Docker 是最省心的方式，依赖全部打包在镜像里，不怕 Python 环境乱七八糟，升级就是拉个新镜像。先准备一个 docker-compose.yml：

yaml复制services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm
    restart: always
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    environment:
      - LITELLM_MASTER_KEY=sk-your-master-key
      - DEEPSEEK_API_KEY=sk-deepseek-your-key
      - DASHSCOPE_API_KEY=sk-dashscope-your-key
      - ZHIPU_API_KEY=your-zhipu-key
    command: ["--config", "/app/config.yaml", "--port", "4000"]

这个文件里最关键的是环境变量。LITELLM_MASTER_KEY 是你访问网关时用的主密钥，所有调用这个网关的请求都要带上它。上游模型的 Key 也通过环境变量注入，而不是直接写在 YAML 里，这样你的配置文件可以提交到 Git，密钥安全系数高不少。

启动容器：

bash复制docker compose up -d

查看日志：

bash复制docker compose logs -f litellm

看到 LiteLLM proxy running on *:4000 之类的输出，就说明服务已经起来了。

4.2 用 venv 原生跑（更可控）

如果你不想依赖 Docker，或者服务器上已经有了一套成熟的 Python 环境管理方式，用 venv 跑也很舒服。在服务器上执行：

bash复制python3 -m venv .venv
source .venv/bin/activate
pip install "litellm[proxy]"

启动时指定配置文件和端口：

bash复制litellm --config ./litellm_config.yaml --port 4000

用 venv 的好处是调试方便，直接看 Python 堆栈，适合想在 LiteLLM 基础上二次开发的人。缺点是环境容易污染，需要你手动管理依赖版本。个人用 Docker，想精细控制就用 venv，两者没有绝对对错。

4.3 Master Key 与第一次验证

无论哪种方式，启动完成后都应该先做一次本地连通测试，确认网关本身没问题：

bash复制curl http://localhost:4000/health/liveliness

正常情况下会返回一个 JSON 状态，说明服务存活。然后再用刚才配置的 Master Key 做一次真实请求测试：

bash复制curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-your-master-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "你好，一句话自我介绍"}]
  }'

能拿到模型返回，就说明你的网关已经具备对外服务能力了。这一步必须做，否则直接配置 Claude Code 时出问题，你很难分清是 LiteLLM 的问题还是 Claude Code 那头的问题。

5. 配置模型路由：把 DeepSeek、Qwen、GLM 全接进来

5.1 config.yaml 核心字段解析

LiteLLM 的路由规则都写在配置文件里，我用一个看起来很直观的例子来解释：

yaml复制model_list:
  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

  - model_name: qwen-max
    litellm_params:
      model: openai/qwen-max
      api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
      api_key: os.environ/DASHSCOPE_API_KEY

  - model_name: glm-4-plus
    litellm_params:
      model: openai/glm-4-plus
      api_base: https://open.bigmodel.cn/api/paas/v4/
      api_key: os.environ/ZHIPU_API_KEY

这里面的 model_name 是“对外暴露的名字”，也就是客户端调用时填的模型名；litellm_params.model 是“上游模型标识”，LiteLLM 会根据前缀 deepseek/、openai/、ollama/ 等来判断走哪个适配器。api_base 则用于指定上游接口地址，特别是那些不是标准 OpenAI 格式的厂商，这行配置是逃不掉的。

还有一点要注意，LiteLLM 支持在 model_list 下面设置 litellm_settings，比如统一的重试次数和超时时间。我习惯在配置里加上：

yaml复制litellm_settings:
  drop_params: true
  request_timeout: 600
  retries: 2

drop_params 可以自动剔除目标模型不支持的参数，避免因为温度、top_p 等参数不兼容导致调用失败。这个选项在接不同家的模型时特别实用。

5.2 接入 DeepSeek

DeepSeek 的 API 本身是 OpenAI 兼容的，所以 LiteLLM 里只需要用 deepseek/ 前缀直接指定模型名，不需要额外写 api_base。官方默认地址是 https://api.deepseek.com，LiteLLM 自带的适配器已经处理好了。

在文件里加入环境变量 DeepSeek 的 Key 后，模型调用就只需写 model_name，比如 deepseek-chat 和 deepseek-reasoner。DeepSeek 的深度推理模型适合复杂编码任务，而 chat 模型响应更快、成本更低。我平时的用法是普通问答用 deepseek-chat，需要深度代码分析时切到 deepseek-reasoner。

5.3 接入通义千问 Qwen

阿里的通义千问 DashScope 有一个 OpenAI 兼容模式，地址是：

text复制https://dashscope.aliyuncs.com/compatible-mode/v1

所以配置里不能用 qwen/ 这种原生前缀（除非 LiteLLM 后来内置了新适配器），而是用 openai/ 前缀指向上面的兼容地址。这里有个小坑：不同版本的 DashScope 兼容端点路径可能略有差异，如果在调用时返回 404，优先检查 api_base 是否写到了 v1 那一层。通了之后，qwen-max、qwen-plus、qwen-turbo 这些模型都能按类似的规则配置进去。

5.4 接入智谱 GLM

智谱的开放平台地址是 https://open.bigmodel.cn/api/paas/v4/，同样走 OpenAI 兼容协议，所以也是 openai/ 前缀加自定义 api_base。GLM 系列里的 glm-4-plus、glm-4-flash 都是性价比不错的选择，特别是 flash 版本便宜到可以拿来做大批量任务。

配置智谱时要注意，智谱的 API Key 同时支持 v4 和旧版两种鉴权方式，但你在 LiteLLM 里只需要把 ZHIPU_API_KEY 设成新版控制台里拿到的 Key 就行。如果出现 401 鉴权错误，先单独拿 curl 测一下智谱官方接口，确认 Key 本身没问题，再回头查 LiteLLM 是否把环境变量正确传进去了。

5.5 验证多家模型可用

配置文件改完之后，重启 LiteLLM 容器让新配置生效：

bash复制docker compose restart litellm

然后用 curl 分别测每个模型。我习惯写一个小脚本，循环调用每个 model_name，只要都返回正常文本，就说明网关路由没问题。如果某个模型返回“model not found”，说明 model_name 与最终请求里携带的名字不一致，再去核对配置。

6. 配置 Claude Code：让终端智能体走代理接入

6.1 安装 Claude Code

前面已经提过安装命令，这里补充一下各平台的细节。Linux 和 macOS 直接：

bash复制npm install -g @anthropic-ai/claude-code

Windows 原生环境如果遇到权限报错，用管理员身份的 PowerShell 重新执行，或者改用 WSL。另外新版 Claude Code 也提供了桌面版，但命令行版才是我们这篇文章的主角，桌面版的使用逻辑类似，只是在 GUI 里填配置。

装完后执行：

bash复制claude --version

6.2 环境变量配置

关键步骤来了。要让 Claude Code 走 LiteLLM 网关，只需要在启动它的终端里设置两个环境变量：

bash复制export ANTHROPIC_BASE_URL="http://<ECS公网IP>:4000"
export ANTHROPIC_API_KEY="sk-your-master-key"

第一个变量告诉 Claude Code 不要连接官方地址，而是连到你的 LiteLLM；第二个变量给它一个能通过网关鉴权的密钥，也就是前面配置的 LITELLM_MASTER_KEY。

如果你希望每个项目默认都走同一套配置，可以把这两个变量写到 shell 的配置文件里，比如 ~/.bashrc 或 ~/.zshrc，这样每次打开终端就自动生效。如果你只想在当前会话里测试，就手动 export 一下即可。还有一个更精细的维度：Claude Code 支持在项目根目录的 .claude/settings.json 里设置模型，不过环境变量优先级更高，我们先用环境变量跑通再说。

6.3 模型名映射与 LiteLLM 别名设计

这里需要提醒一个容易踩的坑。Claude Code 发往网关的模型名默认是官方 Anthropic 那套，比如 claude-3-5-sonnet-20241022 这种。你如果只在 LiteLLM 里配了 deepseek-chat，它会报“model not found”。

解决办法有两个。第一，在启动 Claude Code 时显式指定模型名，通过 ANTHROPIC_MODEL 环境变量：

bash复制export ANTHROPIC_MODEL="deepseek-chat"

第二，在 LiteLLM 的 model_list 里给官方模型名做别名，把它们映射到你想用的实际模型上。例如：

yaml复制  - model_name: claude-3-5-sonnet-20241022
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

这样无论 Claude Code 怎么发请求，网关都能把 Claude 模型名替换成 DeepSeek 来调用。我个人的建议是以环境变量显式指定模型为主，别名配置作为兜底，因为显式指定更直观，排查起来也快。

6.4 实测一串命令

配置完成后，进入任意一个有代码的目录，运行：

bash复制claude

首次进入会有一个交互式引导，问你是否允许它读取文件、执行命令，选择允许即可。接着你就可以在终端里发出指令，比如“解释一下这个项目的作用”、“帮我把这个函数改成异步实现”这类日常任务。

如果你能看到模型返回的内容，说明整条链路已经从 Claude Code 到 LiteLLM 再到上游模型全部打通。从这一刻起，你的终端 IDE 就是“模型可插拔”的了，想换通义、换 GLM、换 DeepSeek，都只是改环境变量或路由配置的事。

7. 生产化：守护进程、日志、HTTPS、VSCode 联动

7.1 systemd 托管 LiteLLM 进程

如果你用的是 venv 方式启动，而不是 Docker，建议直接用 systemd 把 LiteLLM 变成常驻服务，避免 SSH 断开后进程自杀。新建服务文件：

ini复制[Unit]
Description=LiteLLM Proxy
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/litellm
ExecStart=/home/ubuntu/litellm/.venv/bin/litellm --config /home/ubuntu/litellm/litellm_config.yaml --port 4000
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

保存后执行：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now litellm

这样即使服务崩溃，systemd 也会在 3 秒后自动拉起。查看日志也很方便：

bash复制journalctl -u litellm -f

一个稳定常驻的网关服务，是安心用 Claude Code 的前提。

7.2 Caddy 反向代理自动配 HTTPS

如果你有域名，Caddy 是我最推荐的反向代理方案。配置文件很简单，你只需要在 Caddyfile 里写：

text复制litellm.example.com {
    reverse_proxy 127.0.0.1:4000
}

启动 Caddy 后它会自动申请并续期 HTTPS 证书，不用你手动维护 certbot，比 Nginx 加证书那套省心太多。带上 HTTPS 之后，你的 ANTHROPIC_BASE_URL 就可以改成：

bash复制export ANTHROPIC_BASE_URL="https://litellm.example.com"

这样既安全又好看，而且可以在多个设备上复用同一个配置。

7.3 VSCode 集成 Claude Code

Claude Code 不只有终端形态，官方还推出了 VSCode 扩展，你可以在 VSCode 的扩展市场里搜索 “Claude Code” 安装。安装后它的底层依然读取环境变量，所以前面设好的 ANTHROPIC_BASE_URL 和 ANTHROPIC_API_KEY 在这里同样生效。

有一点要提醒：VSCode 打开终端时，环境变量来自 VSCode 进程本身的启动环境，如果你刚才是在系统终端里 export 的，VSCode 里不一定继承到。稳妥做法是把这两个变量和 ANTHROPIC_MODEL 写进 ~/.bashrc，或系统环境变量文件，再重启 VSCode。这样无论图形界面还是终端里，Claude Code 都能稳定连上你的 LiteLLM 网关。

7.4 用 CC Switch 提升切换体验

社区里有一个很好用的工具叫 CC Switch，它本质上是帮你管理 Claude Code 的模型提供方配置。之前很多人拿它来切换 DeepSeek、Qwen、GLM 等模型，但 CC Switch 本身也是通过改写环境变量或配置文件来实现切换。你完全可以把它理解为“LiteLLM 网关的遥控器”：在 GUI 里选好目标模型，然后它会自动帮你改 ANTHROPIC_BASE_URL 和模型名。

不过我的建议是，如果你已经部署好 LiteLLM，就把网关当成唯一入口，所有模型都由网关转发，CC Switch 的职责就退化为“切换网关里不同的 model_name”。这样既统一又灵活，日常切换模型的时候也不用来回改终端配置了。

8. 常见问题与避坑实录

8.1 典型错误速查表

我把实际部署中最常遇到的现象和解决办法整理成了表格，方便你照着排查：

现象	原因	处理方式
Claude Code 启动后报 model not found	网关 model_list 里没有匹配的模型名	用 ANTHROPIC_MODEL 指定网关里实际配置的 model_name，或增加别名
请求返回 401 unauthorized	API Key 不对	检查 LITELLM_MASTER_KEY，以及 Claude Code 里的 ANTHROPIC_API_KEY
请求超时	安全组未放行端口、上游模型响应慢	用 nc 检查端口；增加 request_timeout 和 retries
网关能连通但返回上游 401	上游模型 Key 没配好	直接 curl 上游官方接口验证 Key
LiteLLM 提示配置加载失败	YAML 缩进写错	用 yamllint 等工具检查配置格式
Docker 容器反复重启	环境变量缺失或端口被占用	docker compose logs 看具体报错

8.2 我从实操中总结的几条经验

关于端口暴露这件事，我多说一句。你在 ECS 安全组里放行 4000 端口时，尽量限制来源 IP，别直接写成 0.0.0.0/0。虽然 LiteLLM 有 Master Key 鉴权，但暴露在公网上的服务总是扫描器重点关注对象，轻则日志里全是无效请求，重则被暴力破解。正确做法是：先给自己电脑的固定 IP 放行，如果确实需要多设备接入，配置好 HTTPS 后再放开。

模型参数不兼容是我第二个想重点提醒的坑。不同家的模型预设参数完全不一样，有些模型不接受 top_p，有些对 max_tokens 上限有限制。LiteLLM 的 drop_params 设置一定要开，不然你会碰到“同样的配置，DeepSeek 能跑通，Qwen 却报参数错误”这种诡异问题。

还有一个细节是关于日志的。LiteLLM 默认打印很多请求日志，长期跑下来磁盘会慢慢涨。我习惯在 docke compose 里挂一个日志轮转配置，或者定期手动清理日志文件。这个看起来不起眼，但在服务器上跑三个月后，你会发现磁盘告警突然出现，最后定位到的就是这些不会自我清理的日志。

8.3 从个人使用中得到的最终体会

我实际把这套东西跑起来后，最大的感受是“存在感极低”。它就像一个安静的路由器，我之前担心多一层代理会让响应变慢，实测下来增加的延迟基本可以忽略，原因在于 LiteLLM 只做转换和转发，不承担推理计算。而收益却是很明显的：一个终端工具，可以随时切换到底层不同的模型，甚至在不同任务里用不同模型，这种自由度会让你的 AI 编程体验上升一个台阶。

如果你还想继续扩展，我可以提供几个方向：在 LiteLLM 里接上本地 Ollama，把私有数据场景和云上模型混合调度；给网关加缓存，把重复请求的响应直接命中，节省成本；也可以对接项目管理系统，让 Claude Code 读取你的任务列表。第一步永远是把网关稳定跑起来，后续的道路就宽阔了。