从 Llama Stack 到 OGX一次更名背后的使命重构与完整迁移指南【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogxOGXOpen GenAI Stack的前身是 Llama Stack。2026 年 4 月项目正式更名名称改变的背后是项目定位的一次系统性重构从一个AI API 标准化规范转变为一个可以原生说通 OpenAI、Anthropic、Google 三大前沿实验室 API 的服务端 Agent 循环。本文基于官方公告 docs/blog/2026-04-28-from-llama-stack-to-ogx.md 展开并结合当前仓库源码说明更名的原因、代码库层面的实际变化、新架构下的核心能力以及从旧版本升级的迁移路径。读完你将清楚理解 OGX 的定位并能无痛地把基于 Llama Stack 的服务切换到 OGX。OGX 不是一个 spec、不是 Llama 专属框架也不是又一个模型编排库——它是一个运行在服务端的 Agent 执行循环通过可插拔 Provider 架构把推理请求路由到 vLLM、Ollama、Bedrock 等任意后端同时在同一台服务器上原生暴露 OpenAI、Anthropic、Google 三套 API 表面。为什么改名三个问题公告把改名动机归结为旧名 Llama Stack 带来的三个问题1. Llama 的关联限制了项目认知。项目支持 20 个推理 Provider可以运行 GPT-4、Claude、Gemini、Mistral 等任意模型但 Llama Stack 让外界误以为它只支持 Llama 模型。名称与现实之间的差距越来越大。2. Stack 暗示了一个框架。开发者听到 stack 会联想到需要 import 进代码的库集合类似 LangChain、LlamaIndex。而 OGX 本质是一个 HTTP 服务器应用通过任意语言的任意客户端通过网络与其通信——这个架构性区别被旧名掩盖了。3. 项目已经超越了它的起源。最初围绕 Meta 模型打造 API 的项目如今是一个实现 OpenAI Responses API、Anthropic Messages API、Google Interactions API 的多 Provider、多 SDK 服务器。名称需要反映项目现在的位置而不是起点。OGX 简短、中立不绑定任何单一模型家族或公司可以随项目一起成长。实际变化了什么代码库层面的重命名这次更名不是换一个品牌名那么简单而是触及了代码库的 1,696 个文件。在当前仓库中可以直接看到这些痕迹源码目录从llama_stack变为ogx。核心实现位于 src/ogx/API 层位于 src/ogx_api/对应 inference、messages、responses、interactions、vector_io、files、batches、conversations 等命名空间。CLI 从llama变为ogx。src/ogx/cli/ogx.py 中定义了解析器self.parser argparse.ArgumentParser( progogx, descriptionWelcome to the OGX CLI, ... )其入口main()在启动时会先调用migrate_legacy_config_dir()见 src/ogx/core/utils/config_dirs.py自动完成旧配置目录的迁移。环境变量从LLAMA_STACK_*变为OGX_*。例如服务端口由OGX_PORT控制默认值为 8321见 src/ogx/cli/stack/lets_go.py 和 src/ogx/cli/connect/claude.py配置目录由OGX_CONFIG_DIR控制默认指向~/.ogx/。HTTP 头从x-llamastack-*变为x-ogx-*。例如每请求 Provider 数据头X-OGX-Provider-Data见 src/ogx/core/request_headers.py。配置目录自动迁移。config_dirs.py 定义旧目录~/.llama与新目录~/.ogx当检测到旧目录存在而新目录不存在时migrate_legacy_config_dir()会把~/.llama整体移动到~/.ogx如果两者同时存在则发出 DeprecationWarning 提示手动清理旧目录。这意味着升级后首次启动 CLI配置会无缝搬迁。OGX 到底是什么服务端 Agent 循环在 Responses API 出现之前构建 Agent 意味着在客户端手写编排循环调用模型 → 检查是否要使用工具 → 执行工具 → 把结果回传 → 重复。每个应用都重新实现一遍这个循环且各有各的 bug。Responses API 把这个循环搬到了服务端你发送一个问题加一组工具服务端在内部完成规划、工具执行与结果综合客户端拿到最终答案。OGX 的服务端 Agent 循环完整支持内置 RAGfile_search——服务端在 Agent 循环内部搜索向量库、检索相关片段并作为回答依据。在 src/ogx/providers/inline/responses/builtin/responses/streaming.py 中可以找到file_search工具被注册为服务端内置工具的实现_SERVER_SIDE_BUILTIN_TOOL_NAMES frozenset({web_search, knowledge_search, file_search})。MCP 集成——连接任意 MCP 服务器后Agent 自动发现并使用其工具。底层通过MCPSessionManager管理 MCP 会话见 src/ogx/providers/inline/responses/builtin/responses/openai_responses.pystreaming.py中则按server_label维护每个 MCP 服务器暴露的工具映射。多步推理——服务端处理链式工具调用而不是单次推理。对话状态——跨交互保持持久上下文无需客户端自行管理状态仓库中有独立的 src/ogx_api/conversations/ 命名空间承载对话管理 API。这是 OGX 的核心价值主张它不只是把推理请求路由到不同后端而是在服务端运行整个 Agent 循环——推理、工具调用、RAG、综合——让应用代码保持简单from openai import OpenAI client OpenAI(base_urlhttp://localhost:8321/v1, api_keyfake) # Single API call. Server handles multi-step tool orchestration. response client.responses.create( modelllama-3.3-70b, inputWhat documents mention our pricing strategy?, tools[ {type: file_search, vector_store_ids: [vs_123]}, { type: mcp, server_label: internal-api, server_url: http://api-server:8000/sse, }, ], )说任意前沿实验室 API三套原生 API 表面OGX 不是推理服务器——它把请求路由到 vLLM、Ollama、Bedrock 等推理后端。与普通 OpenAI 兼容网关的区别在于它不是只在前端暴露一个 OpenAI API而是原生实现了三套 API 表面让使用不同 SDK 的团队可以指向同一台服务器OpenAI API——/v1/chat/completions、/v1/responses、/v1/embeddings以及完整的配套端点files、vector stores、batches、models 等。API 层实现在 src/ogx_api/ 下各命名空间的fastapi_routes.py中。Anthropic Messages API——/v1/messages可以直接使用 Anthropic Python/TypeScript SDK格式转换由服务端完成。路由实现在 src/ogx_api/messages/fastapi_routes.py请求/响应模型在 src/ogx_api/messages/models.py。Google Interactions API——/v1alpha/interactions可以直接使用 Google GenAI SDK。请求与响应模型定义在 src/ogx_api/interactions/models.py 与 src/ogx_api/interactions/models.py。三套 API 命中同一个底层推理 Provider 集合。同一台 OGX 服务器可以同时服务使用不同 SDK 的客户端# All three work against the same OGX server, same model from openai import OpenAI openai_client OpenAI(base_urlhttp://localhost:8321/v1, api_keyfake) from anthropic import Anthropic anthropic_client Anthropic(base_urlhttp://localhost:8321/v1, api_keyfake) from google import genai google_client genai.Client(api_versionv1alpha, api_keyfake)这把两个原本耦合的决策解耦了团队偏好哪个 SDK与部署哪个模型或 Provider。用 Anthropic SDK 接 Ollama用 Google SDK 接 vLLM用 OpenAI SDK 接 Bedrock——服务器负责翻译你的代码不用改。对于原生支持某种 API 格式的 ProviderOGX 直接透传请求不产生翻译开销仓库中可见 src/ogx/providers/remote/inference/passthrough/ 目录对其他情况则在格式之间透明转换。当前仓库 src/ogx/providers/remote/inference/ 下已经包含 24 个推理 Provider 实现目录包括 anthropic、bedrock、vllm、ollama、gemini、groq、mistral、nvidia、together、watsonx 等——公告当时提到的 23 个 Provider 数量在持续增长。OGX 不是什么澄清边界公告专门澄清了四个容易误解的点不是主要做 API 标准。OGX 在已有标准处实现现有标准OpenAI API、Open Responses、Anthropic Messages API、Google Interactions API在没有对等标准的空白处如文档摄入的文件处理OGX 定义自己的 API 来补位。如果前沿实验室后续为标准缺口推出标准OGX 会采用而不是维护自己的。项目价值在服务器本身而不是 spec 作者身份。服务端优先不是框架。主要部署形态是 HTTP 服务器应用通过网络以任意语言访问。库模式in-process 嵌入也存在——src/ogx/core/library_client.py 展示了以库方式直接调用 OGX 的路径内部复用ogx_open_client或ogx_client客户端——但架构围绕服务器设计可插拔 Provider、API 翻译、Agent 编排都发生在服务端。不是 Llama 专属。从来不是现在名字也说清楚了。OGX 支持任何可通过其推理 Provider 访问的模型。不只是推理路由。把请求转发到不同后端的代理服务器有用但有限。OGX 在服务端运行完整的 Agent 循环推理、工具调用、RAG、MCP 集成、会话管理、安全与文件处理。这是代理与应用服务器之间的区别。从 Llama Stack 迁移如果你正从llama-stack升级项目旧值新值包名llama-stackogxCLIllamaogx环境变量LLAMA_STACK_*OGX_*HTTP 头x-llamastack-*x-ogx-*客户端 SDKllama_stack_client尚未变化迁移将单独进行待定其中 HTTP 头的变更可以在 src/ogx/core/request_headers.py 中看到实际落地服务端解析X-OGX-Provider-Data/x-ogx-provider-data头来读取每请求的 Provider 数据。服务器 API 本身不变。如果你的应用通过 HTTP 与 OGX 通信本来就应该如此客户端代码完全不需要改动只需指向新服务器。配置目录~/.llama→~/.ogx会由 CLI 首次启动时自动迁移见 src/ogx/core/utils/config_dirs.pyCLI 入口 src/ogx/cli/ogx.py 在main()中调用migrate_legacy_config_dir()完成这一步。安装并启动新服务器默认端口 8321可用OGX_PORT覆盖# 一行安装 curl -LsSf https://github.com/ogx-ai/ogx/raw/main/scripts/install.sh | bash # 或用 uv 安装 uv pip install ogx # 启动服务器自动从环境检测 Provider uv run ogx go启动后OpenAI、Anthropic、Google GenAI 客户端都可以指向http://localhost:8321对应的 API 路径。更详细的端点覆盖与 Provider 矩阵可以参考仓库内的 docs/api-openai/、docs/api-anthropic-messages/ 与 docs/api-google-interactions/ 文档目录。下一步方向公告给出了更名之后的三个增长方向与当前仓库结构互相印证更深的多 SDK 支持——把 Anthropic 与 Google API 的覆盖从基础推理扩展到工具调用与 Agent 能力。仓库中 docs/api-anthropic-messages/conformance.mdx 与 docs/api-google-interactions/conformance.mdx 的存在说明这两套 API 各自有独立的符合性测试跟踪。扩展 Agent 能力——更丰富的服务端编排模式、更好的会话管理、更多内置工具。性能——更快的推理路由、更高效的 Agent 循环、跨 Provider 更好的资源利用。名称是新的使命更清晰了服务器还是你一直在用的那一台——只是名字终于和它实际做的事情匹配了。【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考