OpenOpenAI：把 OpenAI Assistants API 装进自己的服务器

背景：为什么需要一个"复刻版" Assistants API？

2023年11月，OpenAI 正式发布了 Assistants API——一种全新的有状态（Stateful）AI 交互范式。与传统的无状态对话 API 不同， Assistants API 允许开发者创建"会话助理"（Assistant），附加文件、知识库检索（RAG）工具和代码解释器，构建真正可持续的 AI 代理工作流。

但问题随之而来：企业开发者对数据主权的要求越来越严格。将用户对话数据发送到 OpenAI 的服务器，在金融、医疗、法律等行业可能触及合规红线。同时，开发者们也渴望使用开源大模型（如 Llama、Mistral）来降低成本，却受限于 OpenAI 原生 API 的绑定。

正是在这个背景下，transitive-bullshit（Travis Fischer，知名开源开发者，functional-typescript、promisory 等库作者）推出了 OpenOpenAI——一个完全自托管的 OpenAI Assistants API 实现。

图1：OpenOpenAI 运行界面（来源：项目仓库）

核心特性：100% OpenAI 兼容，但要什么模型自己说了算

OpenOpenAI 的设计哲学非常清晰：不重新发明轮子，而是做 OpenAI API 的透明替代品。

所有 API 路由定义和类型定义均从 OpenAI 官方 OpenAPI 规范自动生成，这意味着：

• 只需修改 baseURL，现有使用官方 openai SDK 的代码无需任何改动即可切换到自托管版本
• 所有参数、返回值、类型完全与官方兼容，不会出现 SDK 层面的 break change
• 随着 OpenAI 官方规范迭代，API 定义可通过自动化流程同步更新

支持的资源类型包括：

• Assistants — AI 助理实例，可附加 Instructions（系统提示）
• Threads — 会话线程，承载多轮对话上下文
• Messages — 线程中的消息内容
• Runs & RunSteps — 执行流及执行步骤追踪
• Files — 附件文件管理
• Retrieval Tool — 内置知识检索工具（当前仅支持纯文本和 Markdown 文件）

技术架构：四层服务分离，Redis 驱动异步任务

OpenOpenAI 采用前后端分离的双服务架构：

REST API Server（src/server） 基于 Hono 框架——这是一个轻量、跨平台的 Web 框架，支持 Node.js、Cloudflare Workers、Vercel、Netlify、Deno、Bun、Lambda 等多种运行时。默认使用 @hono/node-server 适配器，兼顾开发便捷性和生产可移植性。

异步任务 Runner（src/runner） 使用 BullMQ（基于 Redis 的任务队列）处理线程运行（Runs）中的异步操作。BullMQ 是 Node.js 生态中最成熟的分布式任务队列方案之一，支持任务优先级、重试、延迟执行等高级特性。Runner 服务可水平扩展，支撑高并发场景。

数据持久化层 通过 Prisma ORM 操作 PostgreSQL 数据库。所有数据模型（Assistant、Thread、Message、Run、File 等）均在 prisma/schema.prisma 中声明，采用标准的关系型设计，并使用 prisma-json-types-generator 生成增强的 JSON 类型支持。

文件存储层 通过 AWS S3 SDK 对接 S3 兼容存储（官方推荐 Cloudflare R2，R2 有免费额度且无出口流量费用）。开发者也可用 MinIO 或 LocalStack 在本地模拟 S3 环境。

依赖一览：

• hono — HTTP 框架
• @prisma/client — 数据库 ORM
• bullmq — 任务队列
• @aws-sdk/client-s3 — 文件存储
• zod — 运行时类型验证（与 OpenAPI 规范生成配合）
• openai — 底层模型调用（接入任意 OpenAI 兼容 API）

使用场景：开源模型 + Assistants = 无限可能

场景一：用开源模型驱动企业知识库

企业可以基于 Llama 3 或 Mistral 构建本地化的 AI 助手，通过 OpenOpenAI 的 Retrieval Tool 接入内部文档库，实现完全私有化的 RAG 方案，数据永不离开企业内网。

场景二：Sandbox 环境下的 GPT 开发与测试

在正式将 GPT 上线 OpenAI "GPT Store" 之前，开发者可以在 OpenOpenAI 的完全隔离环境中测试自定义 Actions、调试函数调用（Function Calling）和知识检索效果，避免在官方平台泄露未完成的创意。

场景三：多模型对比实验

OpenOpenAI 兼容任何 OpenAI 兼容的 API 端点（如 Groq、Ollama 本地模型、Azure OpenAI），开发者可以在同一套 Assistants 代码下无缝切换模型，进行性能、成本和质量的多维度对比实验。

上手门槛与局限性

上手门槛： 适中。项目对 Node.js >= 18 有要求，不提供 Docker 支持，需要手动安装 PostgreSQL 和 Redis（macOS 下有 Homebrew 一键安装脚本），S3 配置对新手略复杂。整体部署需要一定 DevOps 经验。

当前局限性：

• 内置 Code Interpreter 工具暂不支持（issue #3），目前无法在 Assistant 中执行动态代码
• Retrieval 工具仅支持纯文本和 Markdown，PDF、Word 等格式尚不支持检索
• 必须提供 OpenAI API Key 作为底层模型调用后端（支持接入兼容 API 的开源模型，但需额外配置）
• 无官方托管演示版本

行业意义

随着 GPT Store 上线和 AI Agent 生态的爆发，OpenAI Assistants API 有望成为 AI 应用开发的事实标准之一。在此背景下，OpenOpenAI 提供了一条数据主权与模型灵活性兼得的技术路径——既保留了 OpenAI 官方 API 的易用性和生态兼容性，又将控制权完整交还给开发者。

549 颗 GitHub Stars 和 49 个 Forks 说明这个方向确实击中了开发者的痛点。随着更多开源模型和本地推理方案（如 Ollama）的成熟，类似的自托管 AI Agent 基础设施将成为 AI 时代的重要基础设施之一。