Cloud Mac + OpenRouter 保姆级实战：搭建个人专属企业级 AI Gateway

2026 年，个人开发者手里往往同时挂着 Cursor、OpenClaw、自建脚本和两三个 CLI Agent——每个工具都想绑自己的 API Key，每个厂商的 Base URL 还不一样。真正让人头疼的不是「模型够不够强」，而是没有一层统一的 AI Gateway：密钥散落、账单对不上、某个 Provider 宕机时全家停工。本文给你一条可照抄的路径：VPSSpark 云 Mac 做控制面与执行面，OpenRouter 做上游模型聚合，LiteLLM 做自托管 Gateway 壳——半小时内搭出带虚拟密钥、预算熔断和模型回退的「个人企业级」入口。

一句话方案：OpenRouter 负责「一个 Key 调 500+ 模型」；云 Mac 上跑 LiteLLM Proxy 做「你自己的 Gateway」——对外只暴露 http://127.0.0.1:4000，对内路由到 OpenRouter；OpenClaw / Cursor / 脚本全部改指向本地 Gateway，主密钥永远不进客户端。

图 1 · Cloud Mac + OpenRouter 个人 AI Gateway 三层栈

客户端层Cursor · OpenClaw · CLI · MCP

自托管 Gateway（云 Mac）LiteLLM Proxy · 虚拟 Key · 日志 · 预算

上游模型层OpenRouter · 多 Provider 回退

500+

OpenRouter 可用模型

对外 Gateway 端点

7×24

云 Mac launchd 常驻

为什么用「云 Mac + OpenRouter」，而不是只买 OpenRouter？

OpenRouter 本身是托管型 Gateway：注册即得 Key，官方文档写明其 API 与 OpenAI Chat Completions 高度兼容，适合快速接入。但它解决的是上游聚合，不是你的治理边界：你无法给 Cursor 和 OpenClaw 各发一把可独立吊销的 Key；也很难在 Provider 账单之外再做团队级 spend cap；更谈不上把 Gateway 与 macOS 原生工具链（Xcode、AppleScript、本地 MCP）放在同一执行面。

云 Mac 的价值在于「控制面与 Apple 生态执行面合一」。Gateway 进程用 launchd 常驻，密钥只存在服务器 .env；需要跑 OpenClaw、调本地 Git、触发 iOS 构建时，不必再把上下文搬回笔记本。若你已在 Linux VPS 跑网关，可把 VPS 专做 IM/Webhook 入口，云 Mac 专做 Gateway + 构建——分工可参考 Linux VPS 上 OpenClaw 网关与 CI/CD 决策矩阵；云 Mac 侧 launchd 常驻差异见云 Mac OpenClaw 部署与 launchd FAQ。

架构选型：三层各自干什么

先把职责划清，后面配置才不会拧巴。

层级	组件	职责	不做什么
上游	OpenRouter	多模型统一计费、Provider 回退、按 token 付费	不替代你的密钥治理与内网隔离
Gateway	LiteLLM Proxy（云 Mac）	虚拟 Key、路由表、日志、预算、OpenAI 兼容出口	不长期托管聊天会话（交给 OpenClaw）
执行	云 Mac + OpenClaw	7×24 Agent、MCP、macOS 自动化、CI 触发	不把主 API Key 下发到笔电

个人 vs 小团队

一个人用时 LiteLLM 的 Master Key + 两三个 Virtual Key 就够；三到五人小团队再加 Nginx 反代 + Tailscale 内网，Gateway 不对公网裸奔。无论规模，OpenRouter 主 Key 只写在云 Mac 的 .env，客户端永远拿 Virtual Key。

开工前清单（15 分钟自检）

按顺序打勾，能避免后面九成「连不上」类问题。

已开通 OpenRouter 账号，创建 API Key 并设置月度 credit 上限。
云 Mac 可 SSH 登录，架构为 arm64（Apple Silicon），系统 macOS 14+。
已装 Homebrew；Python 3.11+ 或 Docker Desktop（二选一，本文用 pip 路径，最轻）。
Gateway 只监听 127.0.0.1:4000；若远程调用，先接 Tailscale / SSH 隧道，不要直接把 4000 暴露到公网。
笔记本侧 Cursor / OpenClaw 已能 SSH 到云 Mac（密钥登录，禁用密码）。

云 Mac 基础概念与选购可参考 Mac VPS 与云端 macOS 选购指南（2026）。

第一步：配置 OpenRouter 上游

用 curl 在云 Mac 上验证上游可达（替换 $OPENROUTER_API_KEY）：

验证 OpenRouter 上游

export OPENROUTER_API_KEY="sk-or-v1-xxxxxxxx"

                curl -s https://openrouter.ai/api/v1/chat/completions \
                  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "model": "openai/gpt-4o-mini",
                    "messages": [{"role": "user", "content": "ping"}]
                  }' | head -c 400

返回 JSON 且含 choices 即表示上游 OK。模型 ID 格式为 provider/model，完整列表见 OpenRouter Models 页；常用写法如 anthropic/claude-sonnet-4、openai/gpt-4o、google/gemini-2.5-pro-preview。

第二步：在云 Mac 安装 LiteLLM Gateway

LiteLLM 是开源 LLM Gateway，文档入口在 docs.litellm.ai。它把 OpenRouter 包装成你自己的 OpenAI 兼容端点，并支持虚拟密钥与 spend tracking。

安装与目录初始化

# 云 Mac SSH 会话内
                brew install python@3.12
                python3.12 -m venv ~/ai-gateway/.venv
                source ~/ai-gateway/.venv/bin/activate
                pip install 'litellm[proxy]'

                mkdir -p ~/ai-gateway && cd ~/ai-gateway

创建 config.yaml——这是 Gateway 的路由心脏。下面示例把默认模型设为 Claude Sonnet，失败时回退到 GPT-4o mini（OpenRouter 的 models 数组触发回退）：

~/ai-gateway/config.yaml

model_list:
                  - model_name: smart
                    litellm_params:
                      model: openrouter/anthropic/claude-sonnet-4
                      api_key: os.environ/OPENROUTER_API_KEY
                      models:
                        - openrouter/anthropic/claude-sonnet-4
                        - openrouter/openai/gpt-4o-mini

                  - model_name: fast
                    litellm_params:
                      model: openrouter/openai/gpt-4o-mini
                      api_key: os.environ/OPENROUTER_API_KEY

                litellm_settings:
                  drop_params: true
                  set_verbose: false

                general_settings:
                  master_key: os.environ/LITELLM_MASTER_KEY
                  database_url: "sqlite:///./litellm.db"

同目录创建 .env（权限 chmod 600）：

~/ai-gateway/.env

OPENROUTER_API_KEY=sk-or-v1-xxxxxxxx
                LITELLM_MASTER_KEY=sk-local-master-xxxxxxxx

启动 Proxy（先前台试跑）：

启动 LiteLLM Proxy

cd ~/ai-gateway
                source .venv/bin/activate
                set -a && source .env && set +a

                litellm --config config.yaml --host 127.0.0.1 --port 4000

另开终端，用 Master Key 打环回测试：

环回验证 Gateway

curl -s http://127.0.0.1:4000/v1/chat/completions \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "model": "smart",
                    "messages": [{"role": "user", "content": "gateway ok?"}]
                  }'

虚拟密钥（推荐下一步）

前台验证通过后，用 LiteLLM Admin UI（litellm --config config.yaml --detailed_debug 启动后访问文档中的 /ui 路径）为 Cursor、OpenClaw 各建一把 Virtual Key，分别设 $5/$10 月预算。这样某个客户端泄露时，只吊销对应 Virtual Key，不动 OpenRouter 主 Key。

第三步：launchd 常驻（云 Mac 7×24）

验证通过后，把 Gateway 交给 launchd，避免 SSH 断开即停。创建 ~/Library/LaunchAgents/com.vpsspark.litellm.plist：

launchd plist 示意

<?xml version="1.0" encoding="UTF-8"?>
                <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
                 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
                <plist version="1.0">
                <dict>
                  <key>Label</key><string>com.vpsspark.litellm</string>
                  <key>ProgramArguments</key>
                  <array>
                    <string>/Users/YOUR_USER/ai-gateway/.venv/bin/litellm</string>
                    <string>--config</string>
                    <string>/Users/YOUR_USER/ai-gateway/config.yaml</string>
                    <string>--host</string><string>127.0.0.1</string>
                    <string>--port</string><string>4000</string>
                  </array>
                  <key>EnvironmentVariables</key>
                  <dict>
                    <key>OPENROUTER_API_KEY</key><string>sk-or-v1-xxx</string>
                    <key>LITELLM_MASTER_KEY</key><string>sk-local-master-xxx</string>
                  </dict>
                  <key>RunAtLoad</key><true/>
                  <key>KeepAlive</key><true/>
                  <key>StandardOutPath</key>
                  <string>/Users/YOUR_USER/ai-gateway/litellm.log</string>
                  <key>StandardErrorPath</key>
                  <string>/Users/YOUR_USER/ai-gateway/litellm.err</string>
                </dict>
                </plist>

加载并检查：

launchctl

launchctl load ~/Library/LaunchAgents/com.vpsspark.litellm.plist
                launchctl list | grep litellm
                curl -fsS http://127.0.0.1:4000/health || echo "check logs"

更完整的云 Mac 常驻与排障步骤，建议对照 launchd 环境校验 FAQ 里的「登录会话 vs 后台守护」章节——Gateway 与 OpenClaw 可以各用独立 plist，互不影响重启。

第四步：接入 Cursor、OpenClaw 与脚本

所有客户端统一改两处：Base URL 指向你的 Gateway，API Key 用 Virtual Key（或 Master Key 仅用于管理）。

Cursor：Settings → Models → Override OpenAI Base URL → http://127.0.0.1:4000/v1（若 Cursor 跑在笔电、Gateway 在云 Mac，先用 ssh -L 4000:127.0.0.1:4000 user@cloud-mac 做本地转发，或 Tailscale 内网地址）。模型名填 smart / fast，与 config.yaml 的 model_name 一致。

OpenClaw：在 Gateway 配置文档指定的环境变量或配置文件中，把 LLM Provider 设为 OpenAI 兼容，OPENAI_API_BASE=http://127.0.0.1:4000/v1，OPENAI_API_KEY=<virtual-key>。OpenClaw 跑在云 Mac 本机时无需隧道；跑在 Linux VPS 时，要么把 LiteLLM 迁到 VPS，要么用内网穿透——不要把 Master Key 写进 VPS 的公开 compose 仓库。

通用脚本：任何支持 OpenAI SDK 的代码只需改 base_url：

Python 示例

from openai import OpenAI

                client = OpenAI(
                    base_url="http://127.0.0.1:4000/v1",
                    api_key="sk-virtual-cursor-xxxxxxxx",
                )

                resp = client.chat.completions.create(
                    model="smart",
                    messages=[{"role": "user", "content": "总结今日 commit"}],
                )
                print(resp.choices[0].message.content)

模型路由与成本控制

企业级 Gateway 的核心不是「能调模型」，而是「知道什么时候该用贵模型」。建议在个人栈里固定三条路由策略：

默认走 fast：代码补全、格式化、简单问答用 gpt-4o-mini 级模型，成本通常是 Sonnet 的 1/10 量级。
显式升级 smart：架构设计、复杂重构、多文件推理时，客户端或 OpenClaw 路由规则切换到 smart（带 OpenRouter fallback 链）。
双层预算：OpenRouter 控制台设总 credit cap；LiteLLM Virtual Key 设 per-client cap——两层同时触发才真正「断电」。

OpenRouter 支持在请求里传 models 数组做 Provider 级回退；LiteLLM 的 model_list 则可把「业务别名」（smart/fast）与真实模型 ID 解耦，日后换模型只改 YAML，客户端零改动。

安全基线（必做，不是可选项）

个人 Gateway 最常见事故是 Key 进 Git 或 Gateway 裸奔公网。最低限度遵守下面五条：

.env、plist 里的密钥不进版本库；.gitignore 写死 .env、*.db、litellm.log。
LiteLLM 只绑 127.0.0.1；远程访问走 SSH -L 或 Tailscale，前面再加 Nginx + mTLS 若有多人共用。
OpenRouter Key 泄露时，控制台立即 Rotate；OpenRouter 已与 GitHub Secret Scanning 合作，但仍以主动轮换为准。
定期 sqlite3 litellm.db 导出 spend 日志，对照 OpenRouter Dashboard，发现异常流量立刻吊销 Virtual Key。
云 Mac 开启 FileVault，SSH 仅密钥登录；与 Linux 网关交付一样，把「变更」和「密钥」分开审计。

常见踩坑

在笔电上直接填 OpenRouter Key 给 Cursor，同时云 Mac 又跑一套 Gateway——结果账单双份、密钥两处泄露面。统一入口：笔电只连隧道，所有 LLM 流量经云 Mac Gateway 出网。

FAQ

能不能跳过 LiteLLM，客户端直连 OpenRouter？可以，适合单人极简场景。但你失去虚拟密钥、统一日志和本地路由别名；客户端一多，迟早还要补 Gateway 层。

Gateway 放云 Mac 还是 Linux VPS？只有 LLM 转发、没有 macOS 工具需求时，VPS 更省；只要涉及 OpenClaw + MCP + Xcode 自动化，云 Mac 一台搞定执行面 + Gateway 更省心。

OpenRouter 宕机怎么办？在 LiteLLM model_list 里加第二上游（例如直连 Anthropic Key 作 emergency route），或临时把 fast 指到 OpenRouter 标注的 free tier 模型做降级。

延迟会变高吗？多一跳 Proxy 通常增加个位数毫秒到几十毫秒；相对 LLM 推理时间可忽略。瓶颈更多在模型选择与区域路由，而非 LiteLLM 本身。