Llama Stack与智能体"随处运行"开放标准的案例

为什么在已有LangChain、LangFlow和CrewAI等流行框架的情况下，我们还需要Llama Stack？

这是我们最常被问到的问题。这很合理——毕竟这些框架已经为开发者提供了丰富的检索增强生成（RAG）和智能体工具。

但我们认为Llama Stack不仅仅是"另一个智能体框架"。它更好理解为一个由四个不同层次组成的架构：

Llama Stack的4个层次

1. 构建层（客户端SDK/工具包）

为构建智能体提供的熟悉接口。在此层面上，它与LangChain、LangFlow和CrewAI有重叠。开发者可以使用通用抽象来编写智能体。

示例：使用CrewAI构建的智能体看起来像一个小型项目文件夹，包含配置文件和环境变量。

2. 智能体工件和依赖项

这些是智能体开发的有形工件。要运行这些，智能体开发者需要一个平台，提供所需的运行时和API端点，用于模型推理、工具调用或安全和遥测。

图1显示了使用CrewAI开发的简单智能体及其依赖项的示例。

还可以区分本地循环开发与部署，以及阶段和生产环境部署（见图2）。Llama Stack支持本地开发和部署环境，并提供利用远程端点的选项。此外，它允许平台提供商以Llama Stack为核心构建阶段和生产环境。Llama Stack有助于确保这些工件能够一致运行——无论选择哪种后端模型或工具。

3. 平台/API层

为核心AI服务提供的标准化API接口，包括推理、记忆、工具使用、后期训练、数据和合成生成以及评估。这是平台可以暴露和操作的Llama Stack部分。

它内置支持OpenAI兼容API和模型上下文协议（MCP）。这意味着开发者可以合并现有的智能体和工具，而无需重写它们。此外，值得注意的是，Llama Stack是OpenAI API的少数开源实现之一（例如，OpenAI的智能体API即响应API，以及其他用于file_search、vectorstores等的OpenAI API）。此外，Llama Stack还有一个更广泛的接口，超越了OpenAI API，用于评估、微调、模型定制、评分和数据集管理等功能。

示例：您已经针对OpenAI聊天补全API编写了一个智能体。通过Llama Stack平台和API服务器，它可以未经修改地运行——并且您可以将其指向在您自己的集群/环境中运行的Llama、Qwen或其他模型端点，基于vLLM等开源技术或AWS Bedrock或Azure OpenAI等托管推理服务。

4. 提供商模型

用于后端的插件系统——无论是开源还是专有。这允许您交换模型提供商、向量数据库或运行时实现，而无需接触智能体代码。

示例：您的智能体使用向量存储进行检索。今天是Pinecone，明天您想要Milvus。使用Llama Stack，您只需交换提供商，而不是您的智能体逻辑。

Kubernetes类比

为什么将Llama Stack与Kubernetes比较？

Kubernetes之所以成功，不仅仅是因为它使运行容器变得容易。它之所以成功，是因为它定义了一个控制平面+插件契约（CNI用于网络，CSI用于存储，CRI用于运行时），运营商可以依赖这些契约。它开发了工作负载API（如Deployment），开发人员和运营商依赖这些API来开发和部署工作负载/应用程序。最后，Kubernetes允许使用自定义资源（CR）扩展工作负载API，用于不适合工作负载API提供的本机功能的工作负载。这些契约实现了跨供应商和云的可移植性。

Llama Stack旨在为智能体扮演相同的角色：连接开发者和平台的"随处运行"契约。

对于开发者：您使用的（Llama Stack）API和您生成的工件（YAML配置、Python任务、工具绑定）应该在不同环境中无需更改即可运行。开发者还可以扩展Llama Stack API。

对于平台：底层基础设施（模型、向量数据库、训练运行时、工具API）应该是可插拔的提供商。

将Kubernetes视为编排容器，而Llama Stack编排智能体及其提供商。如果成功，Llama Stack可能成为更广泛的开源AI生态系统组织的"锚点项目"，就像Kubernetes为云原生计算所做的那样。

标准问题：OpenAI API与MCP

目前，OpenAI API（聊天补全，以及现在的响应API）已成为推理的事实标准。同时，MCP已成为工具调用的开放协议。

但有一个问题：OpenAI API不是开放标准。MCP是。

这对开源社区提出了一个重要问题：单个公司对塑造智能体生态系统的API应该有多大影响力？

Llama Stack提供了一种采用有效方法（OpenAI兼容性在今天至关重要）同时推进开放标准（通过MCP及更高版本）的方式。如果成功，它可能帮助奠定基础，使智能体和生成式AI的API不会继续受制于专有利益，或作为分散和扩散的开源计划。

作为一个具体示例，使用Llama Stack vector_stores/{vector_store_id}/search API，调用者可以传递search_mode参数进行混合搜索（语义+关键词），这是对OpenAI可用功能的增强。这些是开源社区项目辩论和实现的创新类型（而不是依赖一家公司进行此类增强）。

虽然Llama Stack由Meta发起，但已经有许多组织和个人为该项目做出贡献，包括Anthropic、OpenAI、NVIDIA、Groq、AI Alliance和Red Hat。

治理问题

我们讨论不够的另一部分是：治理。

Kubernetes不仅仅是一项好技术——它得到了云原生计算基金会（CNCF）下的中立治理支持，这给了企业和供应商投资信心。没有这一点，Kubernetes可能仍然是"只是另一个编排工具"。

对于Llama Stack要实现其潜力，治理也将很重要。为此，Llama Stack现已移至一个独立的中立GitHub仓库。我们从这里去哪里？我们是否需要为Llama Stack建立类似CNCF的治理结构？什么时候？答案将决定它是否真正成为"智能体的Kubernetes"。

为什么这很重要

对于开发者：确信您的智能体和工具即使基础设施和供应商发生变化也能继续运行。

对于平台运营商：可移植性、互操作性以及免于供应商锁定。

对于生态系统：有机会避免碎片化，并为智能体创建真正的开源重心。

底线：Llama Stack less关于替换您最喜欢的智能体库，更多关于在它们之下创建开放、随处运行的契约。 它建立在有效的基础上（OpenAI API、MCP），但也指向API、标准和治理开放和社区驱动的未来。

这是我们需要进行的对话——因为智能体的未来不应该只属于一家公司。