OGX 的 README 最上面有一個警示框，開頭寫著 “Llama Stack is now OGX.”。很多人對 Llama Stack 的印象停在「配 Llama 模型用的那套東西」，而這個印象，正是它要改名的原因之一。

名字的事放到後面講。它想解的是一個很常見的麻煩：團隊裡有一支用 OpenAI Python SDK 寫好的內部工具，另一組人用 Anthropic SDK 寫了客服機器人，現在主管說資料不能出公司，模型要改跑自己機房的 vLLM。兩份程式碼都得改，改法還不一樣。OGX 給的答案是把 base_url 指過去就好。

一個請求進了這台 server 之後，要經過哪些事，「指過去就好」才站得住？下面從它內部拆起，拆完再回頭看它適合誰。

請求進門的時候，先被分到哪一個入口

OGX 在同一個 port 上開了三組路徑。依改名公告的列法，OpenAI 那組是 /v1/chat/completions、/v1/responses、/v1/embeddings，外加 files、vector stores、batches、models 這些配套端點；Anthropic 那組是 /v1/messages；Google 那組是 /v1alpha/interactions。公告的原話是 “It implements three API surfaces natively, so teams using different SDKs can all point at the same server.”

想像一間餐廳的點餐櫃檯，掛了中文、英文、日文三種菜單，後面卻只有一間廚房。客人用哪種語言點，櫃檯都收，轉成廚房看得懂的單子送進去。OGX 就是那個櫃檯。廚房不是它，公告寫得很直接：”OGX isn’t an inference server”，真正算 token 的是它後面接的 vLLM、Ollama、Bedrock 這類推論後端。

櫃檯怎麼翻譯也有講究。後端本來就支援某種格式的，OGX 直接放行，不做轉換；不支援的才由它在 server 端轉格式。所以你用 Anthropic SDK 打進來、後面接的是 Ollama，中間那層翻譯是 OGX 做的，你的程式碼看不到。

這一步拆完，「指過去就好」的前半句就成立了：你不用換 SDK。

真正讓我意外的是第二層：迴圈被搬走了

只做到上面那樣，OGX 就是一台格式轉換的 proxy。市面上這種東西不少。公告自己也把 proxy 拿出來當對照，說轉發請求的 proxy “useful but limited”。

它多做的那件事，要從寫 agent 最煩的地方講起。沒有 server 端迴圈的時候，你的程式碼得自己跑一圈：呼叫模型，看它要不要用工具，自己去執行工具，把結果塞回去，再呼叫一次，直到它給出答案。公告對這段的描述是每個應用都在重寫同一個迴圈，”and every implementation had its own bugs”。這段路大家都走過，你自己寫過一次就知道，停止條件、工具出錯的重試、對話狀態存哪裡，每一項都是自己的 bug 來源。

Responses API 的做法是把這一圈搬到 server。你送一個問題、附一組工具，server 自己規劃、自己呼叫工具、自己整合，最後回一個答案給你。OGX 實作的就是這個迴圈，公告列出它在迴圈裡處理的東西：用 file_search 查你的 vector store 做 RAG、接 MCP server 並自動發現上面的工具、多步驟的工具呼叫鏈、跨請求保存的對話狀態。

回到餐廳。以前你是自己當跑堂，一道菜要不要加料、廚房缺什麼、客人又改口，都是你在前場跟廚房之間來回跑。現在櫃檯把跑堂的工作一起包了，你只負責說「這桌要什麼」，最後端出來的是整桌菜。

公告給的範例就是這個形狀：用官方的 openai 套件、base_url 設成 http://localhost:8321/v1，呼叫一次 client.responses.create，tools 裡同時放一個 file_search 和一個 MCP server，範例的註解寫著 “Single API call. Server handles multi-step tool orchestration.”

我的看法是，這才是 OGX 值得看的地方，三種 SDK 相容反而是其次。相容層很多人做得出來，把 agent 迴圈做成 server 端的共用服務、再讓三種 SDK 都能呼叫它，才是它跟一般 proxy 拉開距離的那一步。

同一台 server 說三種語言，但說得不一樣流利

拆到這裡要踩一下煞車。

同一篇公告最後的「What’s next」，第一項寫的是要把 Anthropic 和 Google 的 API 覆蓋範圍 “beyond basic inference to include tool calling and agentic features”。也就是說，在 2026 年 4 月 28 日公告發出的時候，這兩個入口的工具呼叫與 agent 功能還列在「接下來要做」的清單上；上一節那個 server 端 agent 迴圈，公告是放在 OpenAI 的 Responses API 底下講的。

所以開頭那個情境要分開看。用 OpenAI SDK 寫的內部工具，指過去大概真的比較省事；用 Anthropic SDK、而且大量用 tool use 的客服機器人，就得先確認現在的版本到底支援到哪裡。我只讀了公告、README 和 GitHub／PyPI 上的元資料，沒有實際把 server 跑起來，這一段目前的實際覆蓋範圍我沒辦法替你確認。

會讓我改變上面那個「迴圈比相容更重要」判斷的條件，是 Anthropic 那組入口也能完整跑 tool calling。到那時候，三種 SDK 對等才算真的成立，相容這件事的份量就會跟迴圈一樣重。

OpenAI 這一側倒是有第三方的尺可以量。README 說它的 Responses API 實作 “passes the Open Responses conformance test suite”。Open Responses 是一份以 OpenAI Responses API 為藍本、由社群另外維護的開放規格，不是 OpenAI 自己發的，網站上也有一個獨立的 conformance 測試頁面。README 上還掛了一個「OpenResponses Conformance」的動態徽章，連到 repo 裡一份覆蓋率資料檔，分數跟著那份檔案走。

名字改掉的是誤會，server 沒換

拆完機制，再回頭看那次改名就比較好懂。

公告列了三個理由。第一個是 Llama 這個字：專案支援 23 個推論供應商，GPT-4、Claude、Gemini、Mistral 都能接，但 “‘Llama Stack’ made people think it only worked with Llama models. That was never true”。第二個是 Stack 這個字，開發者聽到 stack 會想成一包要 import 進程式碼的函式庫，像 LangChain 或 LlamaIndex 那樣，而 OGX 是 “an HTTP server with a pluggable provider architecture”。第三個是專案長大了，原文是 “What started as an API around Meta’s models became a multi-provider, multi-SDK server”。

第二個理由我覺得最實在。第一層和第二層拆下來，所有東西都發生在 server 端：翻譯、迴圈、RAG、MCP 都是。你把它當函式庫來理解，就會一直問「我要 import 哪個 class」，然後永遠找不到那個 agent 迴圈在哪。公告也沒把話說死，它承認有一個把 OGX 嵌進行程裡的 library mode，只是整個架構是圍繞 server 設計的。

改名實際動到的東西，公告寫得很細，整個 codebase 改了 1,696 個檔案。對已經在用的人，差別整理成下面這張表：

項目 Llama Stack 時期 OGX
套件名稱 llama-stack ogx
CLI llama ogx
環境變數 LLAMA_STACK_* OGX_*
HTTP header x-llamastack-* x-ogx-*
Python client 套件 llama_stack_client 公告當時尚未更名，會另外遷移
Server API 同一套 不變

最後一列才是重點。公告的說法是 “The server API itself is unchanged”，透過 HTTP 跟它講話的程式碼一行都不用改。這句話也說明了改名的性質：換掉的是招牌和工具鏈的名字，櫃檯後面那套流程是同一套。

時間線上看，公告前 27 天就開始動了

把 GitHub 和 PyPI 的元資料排起來，新組織和新套件名比改名公告早了將近一個月出現。以下都是 2026 年 9 月 27 日查到的資料。

Llama Stack 到 OGX

2024-06-25

GitHub repo 建立。現在的 ogx-ai/ogx 顯示的 created_at 仍是這一天，舊路徑 llamastack/llama-stack 查詢會被導到它，是同一個 repo 搬家，不是另開新 repo。

2024-09-10

llama-stack 第一個版本上 PyPI，這個套件名稱之下後來累積了 105 個版本。

2026-04-01

ogx-ai 這個 GitHub organization 建立；同一天，PyPI 上出現 ogx 的 0.1.0。

2026-04-28

官方部落格發布改名公告，距離組織建立 27 天。

2026-05-12

ogx 1.0.0 上 PyPI。

2026-07-27

舊套件 llama-stack 最後一次上傳（0.7.3），同一天 ogx 也發了 1.2.2。

2026-09-11

ogx 1.4.0 發布，PyPI 與 GitHub release 版號一致，是查詢當下的最新版。

同樣是 9 月 27 日的查詢結果：repo 採 MIT 授權，8,435 顆星、1,379 個 fork，沒有封存，最後一次 push 是 9 月 26 日。ogx 在 PyPI 上一共 20 個版本，9 月還同時在發 1.0.3、1.2.5、1.3.1 這幾條舊版號的更新，看起來有幾條版本線平行維護。README 另外寫著每週四太平洋時間早上 9 點有社群會議。

有一件事公告沒講。署名是 Charlie、Francisco、Matt、Raghu、Seb 五個名字，沒有標所屬公司；全文唯一提到 Meta 的地方就是上面那句「起源於圍繞 Meta 模型的 API」，也沒提到任何基金會接手。改名之後誰在治理這個專案，從公開資料看不出來，我也不打算猜。

拆完之後，這個形狀在別處也看得到

回頭看整台 server，它做的事可以濃縮成一句：把「你用哪家的 SDK」跟「你跑哪家的模型」拆成兩個獨立的決定。公告自己的舉例是 Anthropic SDK 配 Ollama、Google SDK 配 vLLM、OpenAI SDK 配 Bedrock，server 負責翻譯。

這個拆法不是 AI 才有。寫 Java 的人對 JDBC 應該不陌生：程式碼對著同一套介面寫，底下換哪一家資料庫是 driver 的事。只要兩個原本綁在一起的選擇被一層翻譯切開，選擇權就回到你手上，代價是多一層要維運、要追版本的服務。

OGX 多做的，是把 agent 迴圈也放進那一層。這讓它比純翻譯的 proxy 有用，也讓它更難替換：你的 RAG、MCP 連線、對話狀態都住在它裡面，哪天想拿掉它，要搬的不只是一個 base_url。

還沒解開的問題也在這裡。Anthropic 和 Google 那兩個入口哪天能跑完整的工具呼叫，公告只寫在「接下來」。如果你手上剛好有一支 Anthropic SDK 的程式，拿它去對一台本機的 OGX 跑一次 tool use，大概是回答這個問題最快的方法。

參考來源