利用容器，赋予 AI 工作负载软件工程级的严谨性

随着 AI 工作负载从实验原型阶段进入生产环境，企业面临着一个熟悉的挑战：如何像对待传统软件应用那样，以同样严格的标准来保护、管理和治理这些新组件？破解这一难题的关键，在于您的企业组织可能已广泛使用的东西——容器，特别是开放容器计划（OCI）容器。

什么是开放容器计划？

开放容器计划针对镜像格式、容器运行时和分发定义了开放规范，旨在帮助企业组织避免供应商锁定。  OCI 容器是用于打包软件应用的行业标准格式，因此它们能够在不同的环境、容器引擎（例如 Docker 或 Podman）及云平台上一致地运行。

OCI 工件与容器类似，但工件存储的不是可执行镜像，而是其他内容（例如文件和目录）。  与 OCI 兼容的工件存储库（包括 Quay、Artifactory、Docker Hub 和来自主要云提供商的镜像仓库），能够存储 OCI 容器和工件，并对它们的版本进行管理。

OCI 提供了一种标准化且可移植的软件打包和分发方法。通过使用 OCI 容器打包 AI 模型、模型上下文协议（MCP）服务器和 AI 代理，您可以使用现有的软件供应链安全防护流程、CI/CD 管道和容器编排基础架构。通过这种方法，您可以将已在应用工作负载中实施的治理和审计体系，直接复用到 AI 堆栈。

通过 ModelCar 实现 AI 模型容器化

大语言模型（LLM）和其他 AI 模型在打包方面面临着独特的挑战。它们由大型二进制文件、配置元数据和特定的文件结构要求组成。过去，企业组织依赖与 S3 兼容的对象存储来分发模型，但这种方法会与现有的基于容器的工作流及安全流程产生摩擦。我们建议使用称为 ModelCar 的特定文件结构，将 AI 模型构建到 OCI 容器中。

什么是 ModelCar 容器？

ModelCar 容器非常简单，AI 模型文件放置在容器内的 /models 文件夹中。无需额外的软件包或运行时组件，容器只需以符合 OCI 标准的格式保存模型工件即可。

这种方法的好处非常明显。将模型打包为容器后，您可以使用已用于应用容器的相同软件供应链安全流程对其进行管理。您可以在 CI/CD 管道中，为容器生成软件物料清单（SBOM）和 AI 物料清单（AI-BOM），还可以对容器进行签名和验证，生成来源证明以表明该容器由您信赖的构建系统构建而成，将容器存储在内部的 OCI 工件存储库中，并将部署策略配置为仅从已批准的存储库中拉取容器。

借助红帽 Trusted Artifact Signer，您能够签署模型，并使用 Sigstore 和 Rekor 来验证模型的真实性和透明度。 

红帽 OpenShift AI 2.14 及更高版本支持使用 KServe 直接从 ModelCar 容器提供模型，从而完全消除对 S3 兼容存储的依赖。这简化了部署流程，缩短了推理服务器的启动时间（尤其是当容器已在节点上缓存时），并为整个企业组织提供了统一的工件管理方案。

GitHub 存储库中提供了示例 ModelCar 容器的目录，其中包含用于打包各种模型类型的模板和最佳实践。

模型大小注意事项

虽然 OCI 规范并未对镜像大小施加硬性限制，但实际中仍存在各种限制。容器镜像仓库通常支持从数 GB 到数十 GB 的镜像，大多数企业镜像仓库处理 15 到 20 GB 的镜像不成问题。对于超出这些实际限制的超大模型，您可能需要考虑采用模型量化技术来减小文件大小，或考虑采用其他分发机制。但是，对于大多数生产环境中的模型，尤其是 8 位浮点（FP8）或 4 位整数（INT4）等量化变体，利用 ModelCar 实现容器化既切实可行，也是推荐的做法。

适用于模型的 OCI 工件

ModelCar 使用 OCI 容器，以最大限度地兼容不完全支持 OCI 工件的旧系统，但就模型存储而言，OCI 工件可以说是更好、更高效的选择。 

构建工程师可以将模型打包到 OCI 工件（而非容器）中，并将它们存储在 OCI 工件存储库中。在部署时，您可以使用 Kubernetes 镜像卷，将 OCI 工件直接挂载到模型服务 Pod 上作为存储使用。目前，最新版本的 podman 和 CRI-O 容器运行时已支持挂载 OCI 工件，包括 Containerd 在内的其他运行时的相关支持工作也在推进中。

容器化 MCP 服务器以实现企业级部署

MCP 已成为将 AI 助手和代理与外部工具、数据源和 API 连接的标准方式。MCP 服务器充当 AI 系统与企业资源之间的桥梁，这使得它们的安全性和治理变得至关重要。

对于将在团队之间共享或部署在生产环境中的 MCP 服务器，我们建议使用与其他应用相同的构建工具和流程，将它们构建到容器中。通过这种方法，您能够一致地管理、部署和保护这些组件。对于任何有过容器化应用经验的人来说，这个过程都再熟悉不过：编写容器文件、构建镜像、将构建好的镜像推送到镜像仓库，然后通过红帽 OpenShift、Kubernetes、Podman 或 Docker 进行部署。  您可以使用典型的构建工具完成一系列任务，例如对 MCP 服务器进行签名和验证，生成 SBOM，并将它们存储到 OCI 工件存储库中等。

与任何软件一样，恶意代码也有可能潜入 MCP 服务器。使用红帽可信配置文件分析器来分析并持续验证您的 MCP 服务器，以识别漏洞、恶意依赖项和策略违规行为。

容器化 MCP 服务器的优势

容器化 MCP 服务器可以横向扩展以处理增加的负载，使用标准可观测性工具进行监控，并通过现有的安全策略进行治理。

OpenShift Kubernetes MCP 服务器就是这一模式的范例。它可以在本地运行以供开发使用，也可通过 Streamable HTTP 传输协议部署在集群内，供团队访问。该服务器支持可配置的访问模式（只读、非破坏性或完全访问），并与 Kubernetes 基于角色的访问权限控制（RBAC）集成以实现授权。

围绕容器化 MCP 服务器的生态系统正在不断壮大。例如，MCP 生命周期 Operator 有助于部署容器化 MCP 服务器，并通过 Kubernetes 原生配置将它们连接到您的代理。Kuadrant MCP 网关提供了先进的企业安全防护功能。Docker 等其他热门工具也可与容器中的 MCP 服务器协同运作。

何时不应将 MCP 服务器容器化

并非所有 MCP 服务器都能从容器化中获益。MCP 规范支持两种主要传输机制：stdio（标准输入/输出）和基于 HTTP 的传输（包括 Streamable HTTP 和传统的服务器发送事件（SSE）传输）。这种区别对于部署决策至关重要。

基于 stdio 的 MCP 服务器通过进程流进行通信，AI 客户端会将服务器作为子进程来启动。这种模式非常适合单用户场景，例如开发人员的编码助手、本地生产力工具或个人自动化脚本。在这些情况下，MCP 服务器在用户的笔记本电脑上运行，访问本地文件和资源，并在不再需要时终止。对这些单用户本地用例而言，将 stdio MCP 服务器容器化反而会增添复杂性，却无显著收益。

相比之下，基于 HTTP 的 MCP 服务器作为独立进程运行，可以同时处理多个客户端连接。它们公开网络端点，运作方式更接近传统 Web 服务。这类服务器天生适合容器化，并能从集中部署、扩展和管理中获益。

决策框架如下： 

• 对于共享/生产环境：如果您的 MCP 服务器将在整个团队中共享、通过网络访问或部署到服务器环境中，请将其容器化。
• 对于容器化代理： 如果您的代理在某个容器中运行，则基于 stdio 的 MCP 服务器应在与代理相同的容器中运行，而基于 HTTP 的 MCP 服务器则应在单独的容器中运行。
• 对于单用户本地用例：如果 MCP 服务器使用 stdio 传输在单个开发人员的计算机上本地运行，则容器化是可选的，且可能会增加不必要的开销。 

将代理技能容器化

代理技能已成为 MCP 服务器的替代方案和补充。它们是“包含指令、脚本和资源的文件夹，代理能够发现并利用这些内容，从而更准确、高效地完成任务”。根据代理技能的规范，它们应打包为 zip 文件。 

您可以扩展构建系统，将您的技能打包到 OCI 容器或工件中，就像对待模型和 MCP 服务器一样。然后，您可以像对待模型一样，对代理技能进行签名和验证，生成 SBOM，将它们存储在 OCI 工件存储库中，并在下载后将其附加到 Pod 上。由于代理技能中可能包含特定于平台的脚本，OCI 也具备为各个平台提供不同文件集的能力。如果您的应用支持代理技能，但尚无法使用 OCI 容器或工件，您可以使用 ORAS 命令行实用程序，将代理技能提取到正确的目录中。 

或者，未来可以使用软件包管理器来管理代理技能，类似于各种编程语言中对其他共享库的管理方式。在这种情况下，代理技能将被导入容器并在容器内使用，但未必会以容器本身的形式进行分发。 

这是一项新兴技术，敬请关注后续发展！ 

将 AI 代理容器化

AI 代理是能够利用 AI 模型和其他工具来规划并执行多步骤任务的自主系统，代表着 AI 应用的下一次演进。随着代理从原型阶段迈向生产环境，企业需要一种结构化方法来构建、部署和管理它们。

Kagenti 项目提供了一个 Kubernetes 原生框架，专为这一目标而打造。Kagenti 可与任何代理框架或 SDK 搭配使用，并为生产部署提供模块化组件。从本质上讲，Kagenti 将代理视为可以使用 Kubernetes 自定义资源以声明方式定义的容器化工作负载。

Kagenti 使用 Shipwright 和 Buildah，将代理构建到容器中。如果您的企业组织使用 Tekton 或 Jenkins 进行 CI/CD，您可以将类似的 Buildah 任务添加到现有管道中。与 AI 模型和 MCP 服务器一样，您可以使用典型的构建工具完成一系列任务，例如对代理容器进行签名和验证，生成 SBOM，并将它们存储到 OCI 工件存储库中等。

与 MCP 服务器一样，容器化代理可以横向扩展以处理增加的负载，使用标准可观测性工具进行监控，并通过现有安全防护策略进行治理。  您还可以使用红帽可信配置文件分析器来分析和持续验证代理，以识别漏洞、恶意依赖项和策略违规行为。

单用户代理和子代理

与 MCP 服务器类似，并非所有代理都需要容器化。在单个用户的笔记本电脑上本地运行的代理（例如由编码助手或个人自动化代理生成的子代理），可能无需承担容器打包和 Kubernetes 部署的开销。这些轻量级代理通常作为父应用的子进程运行，并共享该应用的安全上下文。

对于这些单用户场景，重点应放在验证父应用（IDE、编码助手或自动化工具）是否受到恰当保护上，而不是对每个子组件都进行容器化。如何对这些本地代理进行企业级管理，这是一个不断发展的领域，企业组织应密切关注代理框架和工具的发展动态。

适用于沙盒的容器

由于代理、MCP 服务器以及编写和执行代码的模型会引入新的漏洞，因此最佳实践是限制它们对系统的访问，并控制它们可能造成的损害。这有时被称为“代理沙盒”或“代码沙盒”。 

容器化软件在部署时可配置网络策略，以限制与外部服务的通信，包括开放和封锁端口，以及将特定网站和服务加入白名单。Kubernetes RBAC 和服务网格功能提供了精细的访问控制。OpenShift 容器通常在没有 root 权限的情况下运行，这限制了它们对数据和计算资源的访问。  

容器在 CPU 和内存使用方面同样受到限制。在开发人员工作站上，Podman 默认在没有 root 权限的情况下运行其容器，并且还会限制容器对您网络和文件系统的访问。OpenShift 长期以来一直提供容器隔离功能，而红帽版 Podman Desktop 也支持在开发人员工作站上实现容器隔离。

另一个问题是代理运行失控，从而引发拒绝服务攻击。借助 OpenShift，集群管理员可以为每个命名空间设置资源配额，从而限制任何一个项目可以消耗的 GPU、CPU、内存和存储资源。只要设置了合理的资源配额，运行失控的代理就不会因占用过多资源而导致其他工作负载无法获得所需的集群资源。

虽然编码助手和个人代理可以在个人笔记本电脑上运行，但我们发现，将它们放在容器中运行通常是值得的。当代理在沙盒化的容器中运行时，它不会损坏您笔记本电脑上的重要文档，也无法访问您不希望它使用的数据。这意味着，您可以预先批准文件读/写等常见操作，然后让代理在较少监管的情况下运行，最后只需检查所分配任务的最终结果即可。

您还可以同时启动多个代理，让它们并行工作，互不干扰。您可以将长时间运行的代理部署到 OpenShift 中的个人命名空间，然后合上笔记本电脑回家，代理会继续为您工作。您甚至可以保存代理的容器以保留其状态，并在之后需要时进行恢复。该领域有两个新兴项目，分别是用于编码代理的 paude 和用于 OpenClaw 的 openclaw-installer。

将 AI 工作负载容器化的好处

将 AI 组件（模型、MCP 服务器和代理）容器化，可为整个企业组织带来显著且持续叠加的效益。

软件供应链安全防护

容器在部署之前可以进行签名、认证和验证。您可以要求所有 AI 组件都由您信任的 CI/CD 系统构建、经过漏洞扫描，并存储在经过批准的镜像仓库中。出处证明可提供审计跟踪记录，清晰展示每个工件的生成过程。

版本控制和回滚

容器镜像是不可变的，并且带有标签。您可以部署特定版本，在出现问题时回滚到之前的版本，并保留有关部署内容和时间的清晰历史记录。

一致的部署

相同的容器镜像在开发、预发布和生产环境中以相同的方式运行，从而降低了文件在不同环境之间无法正确复制的风险。

可观测性

容器化工作负载能够与现有的监控和日志记录基础架构集成。例如，Kagenti 原生支持 OpenTelemetry（OTEL）跟踪，让您能够使用标准的可观测性堆栈来监控代理运行。

隔离和访问控制

最后，容器提供了丰富的沙盒功能，有助于控制任何问题的影响范围。

展望未来：工作负载身份与零信任

容器化也为更高级的安全模式奠定了基础。Kagenti 项目正在探索与 SPIFFE/SPIRE 的集成，为代理和 MCP 服务器提供工作负载身份和零信任架构。尽管这些功能尚处于发展初期，但将您的 AI 组件容器化并运行在 Kubernetes 上，随着这些安全功能日趋成熟，您将能够更加轻松地采用它们。

工作负载身份可确保每个代理或 MCP 服务器都拥有一个可通过加密方式验证的身份，从而实现安全的服务间通信，而无需依赖共享密钥。当您的 AI 组件实现容器化，并能与现有的身份和访问权限管理基础架构集成时，零信任原则（即永不信任，始终验证）便能切实落地。

结语

OCI 容器提供了一种成熟可靠的标准化方法来打包和分发软件，这种方法能够自然地扩展到 AI 工作负载。通过将 AI 模型、MCP 服务器和代理进行容器化，您可以赋予 AI 堆栈与应用相同的治理机制、安全性和运维成熟度。

关键在于识别容器化何时能创造价值。对于共享的、联网的生产环境部署，容器至关重要。对于单用户本地用例，容器虽非必需，但能提供沙盒隔离和跨设备可移植性：一次构建，随处运行。通过这种务实的方法，您能够对每个组件应用恰当的治理级别，同时避免不必要的复杂性。

红帽 OpenShift AI、红帽 Trusted Artifact Signer、红帽可信配置文件分析器和红帽版 Podman，为从原型设计到生产环境的 AI 工作负载管理奠定了坚实的基础。红帽为拥有活跃社区的开源工具提供企业级支持，助您紧跟 AI 领域的最新发展。