DeepVCode-Server-mini

OrionStarAI/DeepVCode-Server-mini：AI 代理网关的统一之路

当 Claude 和 Gemini 打架，你的代码该怎么办？

2025 年底，一位开发者在同时使用 Google Vertex AI（调用 Claude 和 Gemini）和 OpenRouter 时，遇到了一个尴尬的问题：两个平台的 API 格式完全不同，响应结构各异，每次切换模型都要改一遍代码。终于有一天，他决定写一个"中间层"——把不同 AI 供应商的接口统一成一个标准化出口。这个中间层，就是 EasyCode Server（项目早期名为 DeepV Code Server）。

这是 OrionStarAI（猎豹移动关联团队）旗下的一个开源项目，为其 EasyCode Client 生态提供统一的 AI 后端代理服务。项目于 2025 年 12 月创建，至今不到一年，已获得 265 个 GitHub Stars，在 AI 代理中间件领域属于增长较快的新兴项目。

场景：为什么需要一个 AI 代理网关？

想象这样的场景：你正在开发一个 AI 编程助手，团队中有人偏好 Claude Sonnet，有人偏好 Gemini 2.5 Pro，还有人想用 OpenRouter 上的开源模型。每个模型的 API 格式、鉴权方式、响应结构都不同——Vertex AI 用 Google 凭证和特定的 generateContent 接口，OpenRouter 用标准的 OpenAI 兼容格式，Claude 通过 Vertex 调用的路径又不一样。如果直接在业务代码里写这些差异，代码会迅速变成一团乱麻。

DeepV Code Server 的价值就在这里：它接收统一的 Google Generative AI 格式请求，在后台自动识别目标模型，将请求转发到对应的 AI 供应商（Vertex AI 或 OpenRouter），再把响应格式统一转换回 Google AI 格式返回给客户端。客户端只需要对接一套接口，就能自由切换背后的任意模型。

技术架构：Express + TypeScript + 模块化 Client 模式

项目采用经典的 Node.js + Express + TypeScript 技术栈，代码结构清晰：

src/
├── index.ts        # Express 服务器入口，路由注册
├── routes.ts       # API 路由定义（核心业务逻辑，30KB+）
├── chat.ts         # 聊天请求规范化处理核心
├── clients.ts      # 模型配置数据库 + 动态 Client 选择
├── clients/
│   ├── vertex.ts   # Vertex AI API 客户端（支持 Claude + Gemini）
│   └── openrouter.ts  # OpenRouter API 客户端
├── config.ts       # YAML 配置管理器
├── i18n.ts         # 国际化（中英文提示）
└── types.ts        # 统一类型定义

核心设计亮点在于 clients.ts 中的 MODEL_DATABASE：一个硬编码的模型配置表（后续应迁移至数据库），定义了每个模型的 api_format（vertex 或 openai）、displayName、creditsPerRequest 等元信息。路由层根据模型名查表，自动路由到对应的 Client。这种"配置驱动"的模式比硬编码 if-else 优雅得多，也方便后续添加新模型。

AI 能力：两种代理模式 + 完整格式转换

Vertex AI 模式（clients/vertex.ts）支持通过 GoogleAuth 获取 Access Token，区分 Claude 和 Gemini 的调用路径：

• Claude 模型：走 anthropic publisher + rawPredict/streamRawPredict 接口
• Gemini 模型：走 google publisher + generateContent/streamGenerateContent 接口

OpenRouter 模式（clients/openrouter.ts）则负责将 Google 格式请求转换为 OpenAI Chat Completions 格式，发送到 OpenRouter 的 /chat/completions 端点。同时支持 tool_calls（函数调用）的累积和转发——这是当前 AI 编程助手最核心的能力之一。

流式响应（Streaming） 两端都有完整实现，Vertex AI 的 Gemini 用 ?alt=sse 参数触发 Server-Sent Events，OpenRouter 用标准 OpenAI 流式格式。项目内部做了大量格式对齐工作，包括 Content、Part、GenerationConfig 等类型定义，确保请求和响应的类型安全。

部署：开箱即用的 Docker 支持

项目提供了生产级部署方案：

• 多阶段 Dockerfile：使用 node:20-alpine 分阶段构建（builder + production），最终镜像仅包含编译产物，体积小巧
• docker-compose.yml：一行 docker-compose up -d 即可启动，自动注入环境变量（OPENROUTER_API_KEY 等）
• PM2 进程管理：非 Docker 环境下，通过 ecosystem.config.cjs 配置 PM2 热重载、日志管理、开机自启
• Systemd 服务：提供 deepx-mini-server.service 模板

Web UI 方面无前端界面，纯 REST API 服务，适合集成到现有系统或配合 EasyCode Client 使用。

开发体验：双语文档 + Mock 鉴权

项目 README 同时提供英文和简体中文两套文档，降低入门门槛。开发阶段还内置了 Mock JWT 登录接口，无需真实凭证即可测试基本流程——这对快速验证集成逻辑非常友好。

局限与挑战

1. API Key 强依赖：项目本身不提供 AI 能力，用户必须自备 OPENROUTER_API_KEY 或 Vertex AI 凭证。团队提供了商业云方案作为变现路径
2. MODEL_DATABASE 硬编码：模型列表写在代码里，每次添加/更新模型需要改代码而非改配置
3. 无测试覆盖：代码中未见测试文件，生产环境稳定性依赖手工验证
4. 安全建议待落实：README 特别提醒了 .env 凭证脱敏、Easylab-login Mock 数据清理等，生产部署需严格审计

行业意义：Agent 时代的"协议层"基础设施

随着 AI Agent（AI 代理）概念爆发，对"统一接口层"的需求正在快速增长。DeepV Code Server 代表了一种典型路径：用中间层抹平不同 AI 供应商的差异，让上层业务代码与具体模型解耦。这种"协议适配层"思路，与 OpenAI 的 Assistants API、LangChain 的 Model I/O 层异曲同工，但更轻量、更自包含。

对于需要同时调用多个 AI 模型、或希望保持模型选择灵活性的开发者，这类代理网关是值得关注的基础组件。