一个开源项目换了名字，往往说明它换了活法。
2026 年 4 月 25 日，Meta 那个挂在 meta-llama 组织下的 Llama Stack 被整体改名成 OGX，仓库从 meta-llama/llama-stack 挪到了 ogx-ai/ogx。一次改名动了 1696 个文件，包名变成 ogx，CLI 从 llama 变成 ogx，环境变量从 LLAMA_STACK_* 换成 OGX_*，连漏洞上报都从 Meta 的赏金平台换成 GitHub Security Advisories。
不是为了好听，是它已经不是原来那个东西了。
它到底是什么
先把定位钉死。OGX 是一个开源的、OpenAI API 兼容的 Agent 服务端。注意这三个词：它是个 HTTP 服务器，不是你 import 进代码的库；它兼容 OpenAI 的接口形态，不是自己另发明一套；它是服务端，Agent 循环跑在服务器里，不在你的客户端里跑。
这一点和大多数人默认理解的「框架」是反的。我前面写过 LangChain 是什么，那是典型的 import 式框架；OGX 是把服务拉起来，你的应用用任意语言、任意 HTTP 客户端连过去。官方在改名博客里专门澄清过这个误解，说「开发者听到 stack 就以为是 LangChain、LlamaIndex 那种库，而 OGX 根本不是那回事」。
真正的能力核心是服务端 Agent 循环。以前你自己写编排，逻辑是：调模型 → 看它要不要用工具 → 执行工具 → 结果塞回去 → 重复。每个应用重写一遍，每个实现都有自己的一堆 bug。Responses API 把这圈循环搬到服务端，你发个问题和一组工具，服务器自己规划、自己调工具、综合答案，客户端只拿结果。
循环里目前支持四件事：内置 RAG（file_search 在 Agent 循环内部搜向量库、召回片段、锚定原文）、MCP 集成（接任意 MCP server，Agent 自己发现并调用工具）、多步推理（服务器处理工具调用链）、会话状态（跨轮次持久上下文）。
三个 SDK，一台服务器
这是 OGX 目前最有实际价值的一点。它原生实现了三套 API：OpenAI 的 /v1/chat/completions、/v1/responses、/v1/embeddings 外加 files、vector_stores、batches；Anthropic Messages API 的 /v1/messages；Google Interactions API 的 /v1alpha/interactions。
三个指向同一台服务器、同一个模型。OpenAI SDK 配 Ollama、Anthropic SDK 配 vLLM、Google SDK 配 Bedrock，都行，服务器负责翻译，客户端一行不用动。
它把两个原本绑死的决定解开了：团队习惯用哪家的 SDK，和你实际部署哪个模型。换模型、或不同团队技术栈不统一时，这能省下真实工程时间。
另外，Responses API 的实现是通过了 Open Responses 一致性测试套件的——注意是 Open Responses，不是 OpenAI 自己那套，这是个独立规范。
上手有多快
curl -LsSf https://github.com/ogx-ai/ogx/raw/main/scripts/install.sh | bash
# 或者
uv pip install ogx
uv run ogx go # 起服务，自动从环境探测 provider
然后任何客户端的 base_url 指到 http://localhost:8321/v1 就行。
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8321/v1", api_key="fake")
response = client.responses.create(
model="llama-3.3-70b",
input="哪些文档提到我们的定价策略？",
tools=[
{"type": "file_search", "vector_store_ids": ["vs_123"]},
{"type": "mcp", "server_label": "internal-api",
"server_url": "http://api-server:8000/sse"},
],
)
一次请求，服务器把多步工具编排全干了。硬性门槛就一条：Python 3.12 以上。
实话
星数得说实话：8.4k stars，1.4k forks。
放眼当下 Agent 生态这个数字是偏小的。LangChain 早就是 134k，Dify 也 157k 量级。8.4k 说明它一直是小众、偏企业侧、偏基础设施层的项目。
但有个数字值得单独拎出来。PyPI 月下载量 67689，前身 llama-stack 同期只有 18055。改名六个月，下载量涨了将近三倍。仓库里 Red Hat 的工程师占了一大把（Sebastien Han、Charlie Doern、Francisco Javier Arceo 都是 @redhat.com），最近几十个 PR 基本都是他们在提。
信号很明确：被大厂放手的项目，被企业软件公司接手后活得比原来好。 Meta 不再主导，Red Hat 拿走维护主导权，而他们的客户群体恰好就是需要 OpenAI 兼容、企业级管控、K8s 部署的这批人——生产需求直接变成上游路线图。
版本节奏也印证：0.8.0（5/1）→ 1.0.0（5/12）→ 1.4.0（9/11），一个月从 0.8 跳 1.0，之后四个月稳定迭代四个小版本，86 个 release、269 位贡献者。
需要泼冷水的地方也有：
别拿星数跟 LangChain、CrewAI 那几个比，那不是一个量级的项目，判断真实使用度请看下载量和 release 节奏。
这是服务端基础设施，不是拖出来就能用的成品。 你得自己准备推理后端（官方支持 23 个推理 provider），自己管向量库和安全策略。
旧用户迁移有成本。 包名、CLI、环境变量、HTTP 头全变，官方标注的 BREAKING CHANGE。好在服务器 API 本身没变，走 HTTP 的客户端一行不用改。
Google Interactions API 目前标注 alpha。 多租户隔离是 9 月才落地的，还在早期阶段。
它不是推理引擎。 官方说得很直白：OGX 路由到 vLLM、Ollama、Bedrock 这些后端，但跑的是完整 Agent 循环——推理、工具调用、RAG、MCP、会话管理、安全、文件处理。这是「代理」和「应用服务器」的分界线，也是它比纯转发代理贵的那部分价值。
适合谁
该上车：已经在用 OpenAI SDK 但想换模型换后端、不改应用代码；团队 SDK 不统一需要一个统一入口；要企业级 RAG，file_search 原生跑在循环里；要 MCP 且不想自己写发现和编排。
先别上：只想「装一个就能用」，去看 Dify；只想把请求换个后端转发，一个 nginx 或 LiteLLM 就够，OGX 是杀鸡用牛刀；Python 低于 3.12。
想对比整个横向 Agent 盘子怎么选，先看 Agent 平台横向对比。
迁移对照
| 项目 | 旧 | 新 |
|---|---|---|
| 包名 | llama-stack |
ogx |
| CLI | llama |
ogx |
| 环境变量 | LLAMA_STACK_* |
OGX_* |
| HTTP 头 | x-llamastack-* |
x-ogx-* |
| 仓库 | meta-llama/llama-stack |
ogx-ai/ogx |
Python 客户端包 llama_stack_client 暂时还没改名，官方说会单独处理。
我的判断：OGX 不是那种会出现在热搜上的项目，但它站在一个很正的位置——Agent 服务端基础设施那一层。大模型厂商在上卷模型，下面这层的空缺反而稳定。要一个能管住、能审计、能多 SDK 的服务端 Agent 循环，它是个正经答案；只想跑 Demo 的话它太重了。
我的文章都在 godsun.pro，实测和踩坑记录都写在那儿。
by 数码罗记 · godsun.pro
