AI Gateway OpenAI Wrapper：给 API 密钥加把"假锁"的代理服务

场景切入：一次意外泄露引发的思考

某天，开发者的 API 调用脚本意外提交到了 GitHub 公开仓库，其中赫然包含着他的真实 OpenAI API Key——这个 Key 可以调用 GPT-4，每分钟成本不低。几小时后，一笔意料之外的高额账单躺在邮箱里等着他。这不是段子，而是真实发生在无数开发者身上的悲剧。

那么，有没有一种方式，从根本上避免这种"手滑"？AI Gateway OpenAI Wrapper 给出了一种颇为巧妙的答案：让开发者使用一把"假钥匙"来调用 API，而真正的钥匙只存在服务端，从不现身。

项目背景：Cloudflare AI Gateway 的 OpenAI 兼容层

这个项目诞生于 Cloudflare 推出 AI Gateway 之后。Cloudflare AI Gateway 是 Cloudflare 提供的一项 AI API 代理服务，核心能力包括：

统一接入点：将来自多个 AI 提供商（OpenAI、Anthropic、Azure OpenAI 等）的 API 请求汇聚到同一个入口，方便管理和切换。
用量监控与告警：实时查看各 provider 的调用量、延迟、错误率，设置用量上限防止超支。
缓存与重试：减少重复请求带来的费用，自动重试失败的请求。
安全防护：防止 API Key 泄露、限制访问频率等。

然而，Cloudflare AI Gateway 的端点并非标准的 OpenAI API 格式，对于已经写好的代码或使用 OpenAI SDK 的应用而言，迁移成本不小。AI Gateway OpenAI Wrapper 正是来解决这个兼容性问题的——它是一个运行在 Cloudflare Worker 上的小型代理服务，将请求从标准 OpenAI API 格式转发到 AI Gateway，同时加入了一层独特的"防误用"设计。

核心机制：Foolproof 设计——用假钥匙保护真钥匙

这个项目最有意思的设计哲学在于 Foolproof（防呆） 二字。作者认为，很多 API Key 泄露的根本原因，并不是开发者的安全意识不够，而是代码中混用了"开发用 Key"和"正式环境 Key"，或者在调试时不小心把真实 Key 写进了代码。

因此，这个 Worker 强制要求用户设置两个 Key：

DUMMY_WRAPPER_KEY：用户调用 Worker 时使用的 Key，可以是任意字符串。
REAL_OPENAI_KEY：用户真实的 OpenAI API Key，只存在于 Worker 的环境变量中，永远不会出现在客户端代码里。

Worker 会检查用户传入的 Key 是否与 REAL_OPENAI_KEY 相同——如果相同，直接拒绝请求，返回错误码。这样一来，即使有人把调用代码不小心公开，也只会泄露那把"假钥匙"，无法真正使用 GPT 的能力。项目的 README 更是建议用户专门为这个 Worker 创建一个全新的 OpenAI API Key，完全隔离风险。

技术实现：极简主义的 Serverless 代理

项目代码量极小，全部核心逻辑只有一个 TypeScript 文件（约 200 行），架构清晰到几乎可以直接读懂：

请求拦截：Worker 拦截所有发往 /v1 路径的请求。
Key 校验：从请求的 Authorization Header 中提取用户传入的 Key，与环境变量中的 REAL_OPENAI_KEY 做比对，不同则放行，相同则拒绝。
请求转发：将请求转发至 AI_GATEWAY_ENDPOINT_URL，替换 Authorization Header 中的假 Key 为真 Key，保持请求体不变，redirect: follow 自动处理 AI Gateway 的响应流。
错误处理：为每种异常情况都返回结构化的 OpenAI 风格错误响应（包含 type、code、message、param 字段），保证 SDK 能正确解析错误。

// 核心转发逻辑（简化）
const trimmedURL = aiGatewayEndpintUrl + requestURL.pathname.substring('/v1'.length);
const gptRequest = new Request(trimmedURL, {
    headers: request.headers,
    method: request.method,
    body: request.body,
    redirect: 'follow',
});
gptRequest.headers.set('Authorization', 'Bearer ' + realOpenAIKey);
return await fetch(gptRequest);

技术栈：

Cloudflare Workers：全球边缘部署，冷启动毫秒级，无需管理服务器。
TypeScript：类型安全，配合 @cloudflare/workers-types 提供完整的 Worker 类型定义。
Wrangler 3：Cloudflare Workers 官方 CLI，wrangler deploy 一键发布。
Vitest + @cloudflare/vitest-pool-workers：针对 Workers 环境的单元测试框架。

无 AI 模型参与：需要澄清的是，这个项目本身并不训练或托管任何 AI 模型，它是一个纯粹的协议转换层和 API 代理。所有实际的 AI 推理仍然发生在 OpenAI（或其他 AI Gateway 支持的）服务端。

部署流程：十分钟上线自己的 API 代理

官方提供了极其简化的部署路径：

在 OpenAI Platform 创建专用 API Key（建议新建）。
在 Cloudflare Dashboard 创建 AI Gateway，获得端点 URL（格式为 https://gateway.ai.cloudflare.com/v1/ACCOUNT_TAG/GATEWAY/openai）。
点击 README 中的 Deploy to Cloudflare Workers 按钮，自动完成 Worker 初始化。
在 Cloudflare Worker 设置页面，配置三个加密环境变量：
- AI_GATEWAY_ENDPOINT_URL：AI Gateway 端点
- DUMMY_WRAPPER_KEY：用户调用时使用的假 Key
- REAL_OPENAI_KEY：真实 OpenAI Key
获得 Worker 域名（如 openai-wrapper.xxx.workers.dev），将其作为 OpenAI API 的 base URL，DUMMY_WRAPPER_KEY 作为 API Key，直接开始使用。

部署难度极低，Cloudflare 的免费额度（每天 10 万次请求）对于个人开发者完全够用。

局限与取舍

仅支持 /v1 路径：Worker 目前仅处理 /v1 开头的请求，文件上传（/v1/files）等功能理论上支持，但非 /v1 的请求会直接返回错误。
Serverless 冷启动：虽然 Cloudflare Worker 冷启动极快（约 5-10ms），但在极高并发场景下可能产生额外延迟。
调试复杂度：假 Key 机制虽然安全，但排查"为什么请求失败了"时多了一层需要确认的因素。
Vendor Lock-in：深度绑定 Cloudflare Workers + AI Gateway，迁移成本不低。
License 限制：代码采用 AGPL-3.0 协议，商业使用需注意开源义务。

行业意义：安全意识驱动的最小化实现

这个项目在 GitHub 上获得 143 Stars，体量不大，却精准击中了一个高频痛点：API Key 管理混乱导致的财务风险。2023-2024 年间，GitHub 上因意外提交 API Key 导致的 OpenAI 账单透支案例屡见不鲜，各路开发者社区都在讨论如何防范。

AI Gateway OpenAI Wrapper 的思路并非业界首创，但它的实现足够简洁、足够专注。它没有试图做一个"大而全"的 AI 网关，而是做好一件事：让已有的 OpenAI 兼容代码在 Cloudflare AI Gateway 下工作，同时多一层安全保障。这种"小而美"的设计哲学，反而让它比很多复杂项目更容易被采纳和维护。

对于关注 AI 应用部署成本和安全的开发者而言，这个项目提供了一个低成本、高安全边际的参考范例——用 Serverless 的极简架构，解决了真实场景中反复出现的 API Key 管理难题。