OpenClaw 接入 Claude 订阅：防封中转方案实战教程

翔宇打开 OpenClaw 后台看了一眼：10 个 Agent 昨晚总共调了 347 次 Claude，情报部采集完热点、微信部写好了初稿、研发部审查完了代码。额外 API 费用：0 刀。

不是白嫖，是翔宇订了 Claude 的 200 刀月付套餐——本来只能在终端里一问一答地用。但翔宇在本机跑了一个中转服务，把订阅的能力变成了标准 API，10 个 Agent 随便调。Anthropic 后台看到的？就是一个正常用户在终端里用 Claude Code。没有任何可疑之处。

翔宇花了一个月研究怎么做到这件事。GitHub 上能找到的中转方案全翻了一遍，四条路线，三条都有坑。最后选了一条最笨但指纹最干净的路：直接让 Claude Code 的命令行帮你发请求。

读完这篇，你将获得：

1. 一张中转方案全景图：四条路线的能力与风险对比
2. 一套设计拆解：三个核心设计决策的「为什么」
3. 一份文末提示词：复制给 Claude Code，从零搭建你自己的中转服务

⚠️ 阅读提示：这是一篇硬核技术文章，涉及 API 指纹、TLS 握手、子进程调度等底层概念。如果你不是开发者，可以直接跳到第 5 节「一键复刻」——把提示词复制给 Claude Code，它会帮你搞定一切。

目录

• 一、什么是中转
  • 1.1 但中转有个核心风险：API 指纹
• 二、四条路，该走哪条
  • 2.1 方案 A：OAuth Token → Developer API
  • 2.2 方案 B：Web Cookie → 网页聊天接口
  • 2.3 方案 C：SDK 封装
  • 2.4 方案 D：CLI 子进程（本文方案）
  • 2.5 翔宇的选择
• 三、CLI 方案：设计与实现
• 四、实战验证：从启动到 OpenClaw 跑通
• 五、一键复刻

1. 什么是中转

你买了 Claude 订阅，每个月 200 刀，可以在 Claude Code 终端里随便用。但这个「随便用」有个前提——你得亲自在终端里一问一答地用。

翔宇的 OpenClaw 有 10 个 AI Agent 需要调 Claude。它们不是人，不会打开终端敲键盘。它们需要的是一个标准接口——发一个请求过去，拿一个响应回来。

中转就是：把你的 Claude 订阅能力，转换成一个标准接口，让程序能调用。

翔宇踩过一个坑：最早没做中转，直接花钱买 Anthropic 的 API 额度。200 刀订阅之外又花了 80 刀 API 费——等于交了两次钱。中转的意义就是把订阅复用到程序调用场景，避免双重付费。

但中转有个核心风险：API 指纹

Anthropic 的后台不只看你发了什么请求——它还能看到你用的是什么工具发的、请求头长什么样、调用频率是什么模式。这些「行为特征」加起来，就是你的 API 指纹。

不同方式发出的请求，指纹全不一样。用 Claude Code 命令行发的、用开发包发的、用第三方工具发的——Anthropic 一眼就能分辨。

指纹不同 = 有被检测的风险。 所以选中转方案时，指纹是否「正常」就成了最关键的考量。

2. 四条路，该走哪条

翔宇把 GitHub 上的方案全翻了一遍，逐个拆解。每个方案用同一套标准评估：10 个维度，从功能覆盖到指纹风险，逐项对比。

方案 A：OAuth Token → Developer API

原理：你用 Claude Code 登录的时候，Anthropic 会给你的终端颁发一个 OAuth Token（格式为 sk-ant-oat-...）。这个方案就是通过 PKCE 流程（一种安全的登录验证协议）获取这串 Token，然后绕过 Claude Code，自己写代码直接 POST 到 Anthropic 的开发者接口 api.anthropic.com/v1/messages。

GitHub 代表项目：cliproxy-api（15,900+ stars，Go 实现）——名字带 CLI 但实际是 OAuth 方案，通过浏览器完成 PKCE 登录后把 Token 存到本地文件，每次请求用这个 Token 直接调开发者 API，伪装请求头为 claude-cli/2.1.63，支持多账号轮换。

翔宇第一个试的就是这个——15000+ stars，看着最靠谱。跑了两天，总觉得哪里不对。后来一抓包，发现请求头说自己是 Node.js，TLS 握手却是 Chrome 的指纹。就像你穿着西装但脚上踩着拖鞋，Anthropic 低头一看就露馅。

功能最全，但底裤漏了。 请求头可以伪造，TLS 指纹、TCP 行为这些底层特征很难完美模拟。

方案 B：Web Cookie → 网页聊天接口

原理：你在浏览器里登录 claude.ai 网页版时，浏览器会存一个 Cookie。这个方案就是把这个 Cookie 复制出来，用代码模拟浏览器直接访问网页版的聊天接口——和你在浏览器里打字聊天走的是同一条路。

GitHub 代表项目：clewdr（989 stars，Rust 实现）——同时支持 Web Cookie 模式和 OAuth API 模式，Web 模式下伪装 Chrome136 浏览器指纹发请求。clove（626 stars，Python 实现）——通过 Cookie 登录后先尝试开发者 API，失败后自动降级到 Web 接口。

翔宇也试过这条路。能用的模型确实最多，Opus 也能跑。但 Cookie 三天两头过期，每次都得打开浏览器手动复制一遍——跑了一个月翔宇就受不了了。

能调的模型最多，但 Cookie 过期太频繁，维护成本劝退。

方案 C：SDK 封装

原理：Anthropic 官方提供了一个开发工具包（Agent SDK），开发者可以用它在自己的程序里调用 Claude。这个方案就是用这个工具包接收 OpenAI 格式的请求，在内部转成 Claude 格式调用，再把结果转回 OpenAI 格式返回。

GitHub 代表项目：claude-code-openai-wrapper（441 stars，Python 实现）——用 claude_agent_sdk 的 query() 函数直接调用 Claude，FastAPI 对外暴露 OpenAI 兼容端点，默认禁用 Claude Code 的内置工具以兼容 OpenAI 客户端。ccproxy-api（195 stars，Python 实现）——混合架构，同时支持 OAuth API 直连和 Agent SDK 调用两条路径，SDK 路径自动复用本地 CLI 的登录凭证。

翔宇纠结最久的就是 C 和 D 之间的选择。SDK 方案功能确实更完整，Tool Calling 是结构化的，不存在解析失败。但那组空参数像在 Anthropic 后台举了个牌子：「我不是正常用户」。翔宇最终还是选了更笨但更隐蔽的 D。

功能最完整，但指纹有暗伤。 目前没有封禁案例，但指纹差异客观存在——翔宇把它留作备用方案。

方案 D：CLI 子进程（本文方案）

原理：你在终端里敲 claude -p "你好"，Claude Code 就会帮你发请求并返回结果。这个方案就是让程序自动帮你敲这个命令——每来一个请求，就在本机启动一个真实的 Claude Code 命令行进程，让它去和 Anthropic 通信。Anthropic 后台看到的，就是一个正常用户在终端里用 Claude Code。

GitHub 同类项目：claudex（Go 实现）和 claude-max-api-proxy-rs（Rust 实现）——都是通过 claude -p 启动子进程的方案，但 star 数均为个位数。CLI 子进程方案在开源社区中几乎没有成熟项目，翔宇的实现在 Tool Calling 文本提取、双模式指纹策略、多模态路由等方面做了大量工程优化，这些是开源项目不具备的。

指纹最干净，长期运行最稳。 代价也明确：Tool Calling 靠正则提取文本，偶尔会解析失败；流式输出是模拟的，不如方案 C 精确。风险不是零——调用频率远超正常人类使用，还是可能触发异常检测。

翔宇的选择

翔宇选方案 D 的理由就一个：指纹最干净。OpenClaw 需要的 System Prompt、Tool Calling、流式、多模态全部能覆盖，虽然不是原生实现，但够用。风险排序：D（指纹最干净）> C（中危）> B（中高危）> A（高危）。

重要提醒：方案 A/B/C/D 都不在 Anthropic 官方授权范围内。Anthropic 的服务条款、速率策略、检测机制随时可能调整，任何中转方案都存在账号被限制或封禁的风险。翔宇在本地跑了两周没出问题，但这不代表方案本身没有风险——只是目前还没触发而已。账号风险自担，翔宇自己也做好了随时被封的心理准备。

3. CLI 方案：设计与实现

核心思路：每个请求进来，在本机启动一个真实的 Claude Code 命令行进程，让它去和 Anthropic 通信。进程拿到回答后，翻译成 OpenAI 标准格式返回。OpenClaw 的 10 个 Agent 只需要像调 OpenAI 一样发请求，完全不用关心背后是 Claude。

整个系统拆成五层，每层只干一件事：

数据流：客户端发请求 → Server 接收 → Bridge 转换 → CLI 启动命令行 → 拿到回答 → Bridge 转回 → 返回客户端。遇到图片？整条请求不走命令行，改走 Gemini。纯文本保指纹，图片保功能。

三个关键设计决策：

沙箱隔离——每个请求创建一个临时目录，结束立刻删除。翔宇最早没做隔离。有天晚上情报部在采集热点，研发部同时在审代码，两个请求撞在一起——情报部的 Agent 突然开始审查代码，研发部的 Agent 突然开始分析新闻。排查了半小时才发现：两个进程共用了同一个临时目录，文件互相串了。加了沙箱之后，每个请求完全隔离，用完即删。

双模式指纹——普通聊天不加任何自定义参数，指纹和正常用户完全一致。带工具的请求把工具定义注入到系统指令里，同时禁用命令行自带工具，两种模式自动切换。

文本分块——命令行一次性吐出一大段文字，但客户端期望逐段蹦出来。分块模块在标点和换行处自然断开，模拟流式效果。翔宇最早按固定长度切，经常把中文句子从中间切断，加了标点感知才自然。

💡 划重点

沙箱保隔离、双模式保指纹、分块保体验——理解了「为什么」，换任何语言都能重写。

运维保障：Watchdog（看门狗）守护进程——服务异常崩溃自动重启，5 分钟内连续崩 5 次就停下排查，日志超 10MB 自动截断。翔宇的 Mac Mini 24 小时开机，配了 macOS 自带的开机自启，中转服务开机就跑。

4. 实战验证：从启动到 OpenClaw 跑通

理论讲完，上数据。

启动服务：执行启动脚本，Watchdog 拉起服务，健康检查确认端口 3457 就绪。

OpenClaw 配置：在 OpenClaw 的 Provider 设置里填上本机地址和端口，模型选 Claude Sonnet。10 个 Agent 的请求全部走这个中转服务。

实际运行数据（翔宇最近 7 天的统计）：

翔宇在本地跑了两周多，目前没有收到 Anthropic 的警告或封号通知。但这不代表方案没有风险——Anthropic 的检测策略随时可能更新，翔宇的经验仅供参考，不构成任何安全承诺。

🔧 实操技巧

翔宇把并发数设成 4，不是不能更高，而是故意控制节奏。同时跑 10 个命令行进程，调用频率太密集反而容易触发异常检测。4 路并发 + 排队等待，既保证了 10 个 Agent 的基本需求，又不会在调用频率上太显眼。

5. 一键复刻

准备两样东西：一台装了 Claude Code 的电脑（已登录订阅账号）、Node.js 20 以上。然后把下面这段提示词复制给 Claude Code：

「帮我搭建一个 Claude CLI Proxy 中转服务，通过 claude -p 命令行子进程中转请求，对外暴露 OpenAI 兼容 API。TypeScript + Express，ES Modules，端口 3457。

五层架构，每层只干一件事：

CLI 层——启动 claude -p 子进程，真正跟 Claude 通信。每个请求创建临时沙箱目录，结束立刻删除，防止并发请求互相干扰。进程超时强杀（默认 5 分钟）。环境变量清理，防止子进程套娃启动新的代理。双模式指纹策略：普通聊天不加任何自定义参数，指纹和正常用户一致；带工具的请求把工具定义注入到系统指令里，同时用 --allowedTools "" 禁用命令行自带工具。

Bridge 层——OpenAI 格式和 Claude 格式互相翻译。消息转换：把 OpenAI 的 messages 数组转成 Claude 能理解的格式。工具注入：如果请求带了 tools 参数，把工具定义写进 System Prompt，指示 Claude 用特定文本格式输出工具调用。工具解析：从 Claude 的文本回复中提取工具调用，解析成 OpenAI 标准的 tool_calls 格式返回。

Server 层——Express 服务器，暴露三个端点：/v1/chat/completions（主接口，接收 OpenAI 格式请求）、/health（健康检查）、/metrics（运行统计）。

Infra 层——并发队列管理（p-queue，默认 4 路并发，满载排队，超载返回 429）。JSONL 格式日志，按日期轮转。请求计数、成功率、平均响应时间等运行指标统计。统一错误处理。

Types 层——定义 OpenAI 请求/响应格式和内部数据格式的 TypeScript 类型。

多模态路由：自动检测请求中的图片、音频、视频内容，整条请求不走命令行，改走 Gemini API（环境变量 GEMINI_API_KEY 配置密钥，GEMINI_MODEL 配置模型）。纯文本保指纹，多媒体保功能。

流式输出：命令行一次性返回完整回答，用文本分块模块模拟逐段输出——在中文标点（句号、问号、感叹号、逗号）和换行处自然断开，发送 SSE 格式的 Server-Sent Events。

启动脚本 start.sh 内置 Watchdog 守护：服务异常崩溃自动重启，5 分钟内连续崩 5 次停止重启并报警（防抖动），日志超 10MB 自动截断。支持 start/stop/restart/status 四个命令。

macOS 开机自启：生成 LaunchAgents plist 文件，开机自动拉起服务。

环境变量（均有默认值）：PROXY_PORT（端口，默认 3457）、PROXY_CONCURRENCY（并发数，默认 4）、PROXY_TIMEOUT_MS（超时，默认 300000）、GEMINI_API_KEY（多模态密钥）、GEMINI_MODEL（多模态模型）。」

Claude Code 会自动生成全部代码。搭建完成后验证：访问 127.0.0.1:3457/health 确认服务就绪，然后在 OpenClaw 或任何 OpenAI 兼容客户端填入 Base URL 127.0.0.1:3457/v1，Model 填 claude，即可使用。

翔宇花了一个月趟完四条路，最后选了最笨的那条——但两周多跑下来，它也是最稳的那条。有时候最笨的办法，就是最好的办法。

这篇讲的是 CLI 版中转方案。翔宇同时也写了一套 SDK 版（方案 C），功能更完整、Tool Calling 原生支持——后续会单独发一篇拆解。两套方案互为备份，CLI 版主力运行，SDK 版随时可切。

CLI Proxy 和 SDK Proxy 都是「AI 编程实操课」中 Claude 订阅系列的实战项目。在课程中，你还会学到：OpenClaw 多 Agent 组织架构设计、OpenClaw Bridge 让 Agent 自动调 Skill、Claude Code 安装与 Skill 入门、syncthing 四机配置同步、以及从零搭建 10 Agent 自动化军团的完整流程。如果你想获取完整源码、系统学习 AI Agent 自动化工作流，欢迎加入翔宇工作流：AI 编程实操课。