AIStudioToAPI

让 Gemini 变「OpenAI」：AIStudioToAPI 的核心价值

背景：Google AI Studio 的「封闭之痛」

在 AI 应用开发中，OpenAI 的 GPT-4o API 几乎是行业事实标准。全球数百万开发者早已习惯以 /v1/chat/completions 格式发送请求，Claude、Qwen 等主流模型也纷纷推出「OpenAI 兼容」接口以降低迁移门槛。然而，Google 自家的 Gemini 模型虽然能力强大，但其 API 调用方式与 OpenAI 并不一致。

对于那些已有成熟应用、想要接入 Gemini 的开发者而言，改写整个 API 调用层是一件成本极高的事——这正是 AIStudioToAPI 诞生的背景。

核心技术：三层协议转换

AIStudioToAPI 的本质是一个协议适配代理服务器。它部署在你自己的服务器上，监听标准 OpenAI 风格的 HTTP 端点，收到请求后执行三层转换：

第一层：协议格式转换

FormatConverter.js 是项目最核心的模块。它处理 OpenAI 请求格式（messages/role/content）到 Gemini API 格式（contents/parts/text）的双向映射。这包括：

• 消息结构映射：将 OpenAI 的 user/assistant/system 角色转换为 Gemini 的 user/model 角色序列
• Function Calling 转换：OpenAI 的 functions 规范与 Gemini 的 tools 规范差异巨大，转换器需要处理参数类型、嵌套对象、函数名格式等数十种边缘情况
• 多模态数据处理：图片支持（base64/URL）、音频、文档等不同模态的 MIME 类型识别与格式归一化

第二层：认证劫持

BrowserManager.js 使用 Playwright 启动无头 Firefox 浏览器（Camoufox）访问 Google AI Studio，自动完成登录认证，并将认证 Cookie 注入到后续请求中。项目的巧妙之处在于使用 WebSocket 协议将浏览器会话暴露给 Node.js 进程，这样每个 API 请求实际上是「控制浏览器访问 AI Studio → 提取响应」的流程。

第三层：响应归一化

将 Gemini 返回的 JSON 格式重新序列化为 OpenAI 流式/非流式响应格式，支持 stream: true 的 fake streaming（因为 Gemini 原生不支持 Server-Sent Events）。

为什么不用官方 Gemini API？

官方 Gemini API 是付费服务，而 AI Studio 提供免费额度（有一定速率限制）。对于个人开发者、研究者、小型项目而言，通过 AIStudioToAPI 将 AI Studio 的免费能力暴露为标准 API，是一个成本极低的解决方案。此外，AI Studio 支持的模型版本通常比官方 API 更快上线（比如 Gemini 3.x 的预览版）。

部署门槛与挑战

这个项目并非开箱即用——它有相当高的配置门槛：

1. 认证配置最复杂：需要通过 Playwright 浏览器手动登录 Google 账号并保存认证信息，支持 Camoufox（Firefox 改版）、Chrome、Firefox 三种浏览器后端
2. 多账号轮询：支持配置多个 Google 账号（通过 INITIAL_AUTH_INDEX 环境变量），实现请求级别的负载均衡
3. Docker 部署但不包含认证：Dockerfile 基于 Node.js 24 slim，但认证信息需要单独挂载配置文件
4. 依赖链长：src/core 目录下有 6 个核心模块，总代码量超过 500KB，调试需要熟悉 Node.js + Express + Playwright 三种技术栈

技术栈全景

适用场景

• ✅ 个人开发者在应用中使用 Gemini 而不想付费
• ✅ 已有 OpenAI API 架构，想要快速切换到 Gemini 测试
• ✅ 研究者批量调用 AI Studio 模型做实验
• ❌ 生产环境商业应用（认证不稳定、速率限制不保证 SLA）
• ❌ 需要高并发稳定服务的场景

项目生命力

该仓库已有 1326 颗星，维护团队包括 Ellinav、iBenzene、bbbugg 三位活跃贡献者。最新版本 1.3.2 支持 Gemini 3.1 系列模型、Thinking Mode、Web Search 强制开启等最新特性。但核心机制（浏览器劫持认证）始终未变，意味着 Google 一旦修改 AI Studio 登录流程，项目就需要紧急更新。

AIStudioToAPI 代表了一种有趣的「协议逆向工程」思路——不是正面破解 API，而是用浏览器自动化模拟人类用户行为，以复用免费资源。这既是它的优势，也是它最脆弱的地方。