New API 是一套開源、可自架的 AI 閘道，由 QuantumNous 維護，在程式碼託管平台累積 50,029 顆星標與 12,036 次複製。專案以 Go 撰寫、採 AGPLv3 授權，把 OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、Vertex AI、DeepSeek 與 Qwen 等上游服務統一成一致的介面，並在同一處管理路由、存取權限、用量與成本。最新版本 v1.0.0-rc.44 於 2026 年 10 月 12 日發布。本文依據儲存庫公開說明、版本更新紀錄與官方統計資料整理，說明其協議轉換架構、部署選項、授權設計與最新更新內容。
New API 是什麼？
New API 是一套 50,029 星的自架 AI 閘道，把多個上游模型服務收斂成一致的 API 介面，並集中處理路由、權限、用量與成本，適合需要統一管理多模型存取的團隊。
此專案定位為應用程式、代理與團隊之間的 AI 閘道。運作方式是先連接上游模型服務，再對客戶端暴露一組一致的 API，所有路由、存取與用量紀錄都在同一處完成。使用情境包括在團隊內共用已授權的模型存取、切換供應商時不必重新設定每一個客戶端，以及透過網頁主控台營運私有的多模型服務。
專案自 2023 年 11 月建立，原始基礎為 MIT 授權的 One API，其後由 QuantumNous 接手並大幅擴充。儲存庫的程式語言組成以 Go 為主，約占 890 萬位元組，TypeScript 約 227 萬位元組，反映其後端為 Go 服務、前端為完整單頁應用程式的架構。儲存庫已發布超過 500 個版本、708 個標籤，並有 316 位貢獻者，專案活躍度維持在每日提交的水準。
官方文件說明其目標為合法且經授權的 AI API 閘道、組織層級身分驗證、多模型管理、用量分析、成本會計與私有部署情境。文件同時要求使用者自行合法取得上游金鑰與介面權限，並遵守各上游的服務條款。
New API 支援哪些模型供應商與介面協議？
上游涵蓋 OpenAI、Anthropic、Gemini 與 Bedrock 等服務，對外提供三套文本協議，另含影像與語音端點。
在模型存取層面，閘道同時支援 OpenAI 的 Chat Completions 與 Responses 介面、Anthropic 的 Messages 介面，以及 Gemini 的 generateContent 與 streamGenerateContent 端點，並在支援範圍內保留串流、工具呼叫、推理與多模態輸入。除文本協議之外，對外端點還涵蓋影像生成與編輯、語音合成、語音轉錄與翻譯、嵌入向量及重排序，以及透過 JavaScript 外掛擴充的非同步任務介面。
路由能力是此類閘道的核心價值之一。管理端可設定模型映射、通道路由優先序與權重、失敗重試、通道親和性，以及同一上游的多組金鑰。這組設定讓同一個模型名稱可以對應到多條上游路徑，並在成本、延遲或可用性出現變化時調整流量分配，而客戶端不需要感知底層變動。
用量與成本管理則提供配額、訂閱、用量日誌、快取計費與依運算式定義的分級定價。存取控制涵蓋使用者、群組與細粒度權限，並支援 API 金鑰限制、OAuth 與 OIDC 登入、通行金鑰、雙因素驗證及登入工作階段管理。網頁主控台提供頻道與模型設定、用量與稽核日誌檢視，以及可直接試用模型的遊樂場，介面語言包含英文、簡體中文、繁體中文、法文、日文、俄文與越南文。
RelayKit 的協議轉換架構解決了什麼問題？
RelayKit 是專案內可獨立建置的 Go 模組，負責四套文本協議之間的請求、回應與串流轉換，讓客戶端以熟悉的格式呼叫，由閘道承擔格式差異。
四套文本協議的欄位與語意並不完全對應，這是多模型閘道最難處理的部分。RelayKit 負責在請求、回應與串流三個階段完成轉換，使客戶端能用自己熟悉的格式送出請求，而實際上游可以採用另一種協議。官方說明中指出，可用功能取決於通道、上游模型與轉換路徑，特定協議專有的工具與欄位未必能精確對應，這是一項誠實且重要的限制說明。
從儲存庫結構可以觀察其分工方式。router、middleware 與 controller 目錄負責 HTTP 路由、存取檢查與 API 處理；relay 目錄存放上游適配器與請求路由；service 與 model 目錄承載業務邏輯與持久化。RelayKit 則被拆成可獨立建置的模組，其變更需通過離線建置驗證，這種做法讓協議轉換層可以脫離主程式獨立演進。
v1.0.0-rc.44 的更新內容多數落在這一層，反映協議轉換是專案維護的主要戰場。修正項目包括讓已知 Claude 模型取得其可接受的最近推理強度、在模型不支援時不送出推理參數，以及讓送往 Gemini 的工具與結構化輸出保留完整 JSON Schema，包含 const、oneOf、$ref、$defs 與非字串列舉等欄位。這些細節過去容易在轉換過程中遺失，導致結構化輸出失敗。
New API 的部署與儲存架構如何選擇？
可用 Docker 單機啟動並以 SQLite 儲存，或以 Docker Compose 部署 PostgreSQL 與 Redis，並搭配 HTTPS 主控台。
最簡部署方式是單一容器搭配 SQLite，資料目錄掛載至主機即可在容器替換後保留資料庫。這種配置適合本機試用與小規模使用。正式部署則由儲存庫提供的 Compose 設定啟動 New API、PostgreSQL 與 Redis 三個服務，並附有 MySQL 與獨立 ClickHouse 日誌資料庫的範例。
可選元件依規模遞增。主資料庫支援 SQLite、MySQL 5.7.8 以上與 PostgreSQL 9.6 以上；日誌可透過獨立連線字串分離，並支援 ClickHouse；Redis 為選用項目，用於跨節點共用速率限制與快取。多節點部署必須共用同一主資料庫與同一組驗證密鑰，否則各節點的工作階段與限流失效。
安全性設定在文件中被明確標示。官方要求部署前替換資料庫與 Redis 的範例密碼，並以隨機產生的長字串設定持久化的 SESSION_SECRET；若主控台對外提供 HTTPS，需啟用安全 Cookie 模式並設定精確的受信任來源，且不接受萬用字元。反向代理需正確處理串流與 WebSocket 升級，這些設定直接影響 Responses WebSocket 會話能否正常關閉。文件亦提醒 latest 標籤會隨發布變動，正式環境應固定版本並在升級前備份。
為何 New API 採用 AGPLv3 授權？
專案採 AGPLv3 並附加條款，要求修改版本保留作者標註與原專案連結；若組織政策不允許 AGPLv3 或希望避開其開源義務，官方提供商業聯絡管道。
授權選擇對商用整合有直接影響。AGPLv3 的特點在於網路服務形式的散布同樣會觸發開源義務，這對打算把閘道包裝成對外服務的團隊是需要評估的條件。專案在標準條款之外附加了依 AGPLv3 第七條的額外條款，要求修改版本在其法律聲明以及介面上顯著的關於、法律、頁尾或標註位置，保留作者標註文字與可見的原專案連結。
專案原始基礎為 MIT 授權的 One API，其後演進為 AGPLv3 授權。這種授權變更在衍生專案中並不罕見，通常用來確保社群貢獻能回饋上游。官方文件明確提供聯絡管道，供組織政策不允許使用 AGPLv3 軟體，或希望避免其開源義務者洽談商用方案，等於同時提供社群版與商業路徑兩種選擇。
儲存庫另附第三方授權清單與 NOTICE 檔案，完整列出依賴元件的授權資訊。對需要進行軟體組成分析的組織而言，這些檔案讓授權盤點可以在部署前完成，而不必逐一追查依賴樹。
New API 的專案數據與維護狀況如何？
專案累積 50,029 顆星標、12,036 次複製與 167 位關注者，提交次數約 6,500 次，發布超過 500 個版本，並有 316 位貢獻者參與。
專案建立於 2023 年 11 月，在接近三年的時間內累積約 6,500 次提交與超過 500 個版本發布，標籤數達 708 個。貢獻者人數為 316 位，未結議題約 1,362 個。儲存庫在觀察時點仍維持每日提交，最新一次推送與 v1.0.0-rc.44 的發布時間相隔三日。
從星標與複製的比例觀察，此專案的複製數約為星標數的四分之一，高於一般教學型專案的水準。複製行為通常代表實際部署意圖，較高的比例意味著相當比例的關注者打算自架運行，而不只是收藏。這與專案定位相符，因為閘道屬於部署後長期運行的基礎設施，而非一次性使用的工具。
生態合作關係也反映其實際採用範圍。儲存庫列出 Cherry Studio、Aion UI、北京大學、阿里雲與 IO.NET 等作為合作夥伴，其中包含桌面客戶端、企業雲服務與分散式運算平台等不同類型。這種跨類型的合作名單，顯示閘道同時被個人用戶端與組織級部署所採用。
v1.0.0-rc.44 帶來了哪些更新？
v1.0.0-rc.44 於 2026 年 10 月 12 日發布，新增用量日誌匯出 CSV、日誌保留期設定與秒級時間選擇器，並修正多項 Claude 與 Gemini 轉換問題。
此版本為 v1 正式版前的最後幾個候選版本之一。用量日誌頁面在搜尋按鈕旁新增匯出功能，可依當前篩選條件與指定時間範圍下載 CSV，檔案的欄位標題依檢視者介面語言產生。一般使用者匯出自身日誌，管理員在全部使用者檢視下則可匯出所有人的日誌；每位使用者同時僅允許一次匯出，跨分頁與跨節點亦受此限制。
日誌維護頁面同時拆分為日誌記錄、日誌搜尋與匯出、歷史日誌清理、伺服器日誌管理等區塊，並新增兩項設定：是否允許使用者匯出日誌，預設開啟；以及日誌最長時間範圍，預設 365 天。一般使用者過去的日誌搜尋沒有限制，其搜尋、匯出與看板圖表現在共同受此範圍約束。日期與時間選擇器亦支援至秒級。
協議轉換層的修正項目佔多數。已知的 Claude 模型會取得其可接受的最近推理強度，模型完全不接受推理時則不送出相關參數，這修正了 Opus 4.5、Sonnet 4.5 與 Haiku 4.5 在特定參數下回傳 400 錯誤的問題。送往 Gemini 的工具與結構化輸出保留完整 JSON Schema，無法以 Gemini 型別結構表達的結構改走 parametersJsonSchema 或 responseJsonSchema，並在模型設定為 Gemini API v1 時附帶轉換警告。
串流與會話處理亦有改善。由 Responses 介面轉往 Chat Completions 上游的圖片改用 image_url 物件形式，讓 vLLM 等嚴格實作的上游能接受；Chat 串流轉為 Claude Messages 時，保留與最後一個推理權杖同批抵達的答案文字；Responses WebSocket 會話在伺服器結束時送出關閉訊框，使客戶端看到正常關閉。遊樂場資料改為依帳號分開儲存，升級後舊有紀錄會清除一次。
出處連結有哪些？
本文資訊整理自 New API 的 GitHub 儲存庫、官方說明文件與版本更新紀錄，完整原始碼、設定參考與發行說明可由下列來源查證。
官方儲存庫位於 https://github.com/QuantumNous/new-api，內含完整原始碼、貢獻指南與部署設定。官方文件網站為 https://docs.newapi.ai，其中提供安裝說明、環境變數參考、API 參考與身分驗證指南。版本更新紀錄見 https://github.com/QuantumNous/new-api/releases，容器映像發佈於 Docker Hub 的 calciumion/new-api。專案原始基礎 One API 位於 https://github.com/songquanpeng/one-api。
常見問題有哪些？
常見疑問集中在三處：與 One API 的關係、多模型共用的實際效益，以及自架時最容易忽略的設定，以下逐項說明。
New API 與 One API 有什麼關係？
New API 以 MIT 授權的 One API 為原始基礎，由 QuantumNous 接手後大幅擴充，改用 AGPLv3 授權。兩者定位相近，都是把多個上游模型服務統一成一致的 API 介面。選擇時可比較功能覆蓋範圍、協議轉換的完整度、介面語言與授權條款是否符合自身組織政策，因為授權差異會直接影響對外服務與商用整合的可行性。
自架 AI 閘道的實際效益是什麼？
效益主要來自三處。其一是存取集中化，團隊共用已授權的模型存取，終端使用者不必各自持有上游金鑰。其二是切換成本降低，供應商或模型變更時只需調整閘道設定，客戶端不需重新配置。其三是成本可見度提升，配額、用量日誌、快取計費與分級定價讓支出可以被稽核與歸屬。
自行部署時最容易忽略的設定是什麼？
最常被忽略的是驗證密鑰與資料庫密碼的更換。官方文件要求以隨機長字串設定持久化的工作階段密鑰，並替換 Compose 設定中的範例密碼；多節點部署還必須讓所有節點共用同一組密鑰，否則工作階段與速率限制將各自獨立而失去一致性。此外，主控台若對外提供 HTTPS，需啟用安全 Cookie 模式並設定精確的受信任來源。
總結：什麼團隊適合使用 New API？
適合需要在組織內共用多個模型供應商存取、希望統一計費與權限，且能接受 AGPLv3 授權條款的團隊；若需求僅為單一供應商的個人使用，直接呼叫官方 API 更為簡單。
此專案的核心價值在於把多供應商的差異收斂到單一入口。對於同時使用 OpenAI、Anthropic 與 Gemini 的團隊，一致的介面、集中的路由設定與可稽核的用量紀錄，能實際降低維運與對帳成本。RelayKit 承擔協議轉換的複雜度，v1.0.0-rc.44 的多數修正也集中在這一層，反映維護者對相容性的投入。
選擇此類工具時，授權條款與部署成本是兩項必須先確認的條件。AGPLv3 的網路服務條款對打算把閘道包裝成對外產品者具有實質影響，官方雖提供商業聯絡管道，但這仍屬於需要事前評估的決策。部署方面，單機 SQLite 足以支撐試用與小規模場景，跨越單一節點後則需引入共用資料庫、共用密鑰與可選的 Redis 與 ClickHouse，維運複雜度會隨規模上升。
就專案成熟度而言，約 6,500 次提交、超過 500 個版本與 316 位貢獻者，構成相對穩固的維護基礎。v1 正式版仍未發布，目前處於候選階段，部署時應固定版本並在升級前備份，這既是官方建議，也是此類基礎設施元件的通用原則。
