Imagina esto: tu equipo mantiene un gateway de inferencia compartido en tu propia infraestructura, sirviendo tus propios modelos fine-tuned además de unos cuantos de terceros a los que se accede por proxy. Cada vez que un modelo nuevo entra en producción, te toca editar a mano el config.yaml de Hermes — endpoint, API key, nombres de modelo, un campo cada vez — y luego cada compañero repite el mismo ritual en su propia máquina. ¿No sería estupendo poder envolver “cómo hablar con los modelos de nuestra empresa” en un único paquete, de modo que cualquiera haga pip install y listo? El PR #85504, fusionado el 13 de agosto, convierte eso en realidad: los model providers ahora pueden ser paquetes Python normales que se auto-registran mediante entry points. Una vez instalados, Hermes los descubre al arrancar y sus modelos aparecen en el registry igual que los de cualquier provider integrado.

El mecanismo: un solo entry point hace el registro

Un provider es la capa de adaptación de Hermes para “cómo llegar a un servicio de modelos”: conoce la forma del endpoint, dónde va la API key y cómo se envían las peticiones. Antes, los providers solo podían registrarse mediante plugins de sistema de archivos o el conjunto integrado. El PR #85504 añade un “paso 0” al flujo de descubrimiento en providers/__init__.py: escanea los entry points de todas las distribuciones Python instaladas y busca a cualquiera que se declare provider.

La configuración es mínima: en el pyproject.toml de tu propio paquete, declara un entry point que apunte a una función de registro sin argumentos:

[project.entry-points."hermes_agent.plugins"]
acme-inference = "acme_hermes_plugin:register"

La función register() construye un ProviderProfile y llama a register_provider():

# acme_hermes_plugin.py
from providers import register_provider
from providers.base import ProviderProfile

def register():
    register_provider(
        ProviderProfile(
            name="acme-inference",
            display_name="Acme Inference",
            base_url="https://inference.internal.acme.com/v1",
            env_vars=("ACME_API_KEY",),
            auth_type="api_key",
        )
    )

Los campos de ProviderProfile son exactamente lo que “conectarse a un servicio de modelos” exige: nombre, nombre visible, endpoint por defecto, la variable de entorno que guarda la API key, el tipo de autenticación y extras opcionales como una lista de modelos de respaldo (fallback_models). Los plugins de provider tipo directorio que describen los docs oficiales ($HERMES_HOME/plugins/model-providers/<name>/__init__.py) usan la misma API — el mecanismo de entry points simplemente cambia “dejar caer un directorio” por “pip install”; el código de registro es idéntico.

Además de la forma invocable module:func, el entry point también puede ser un nombre de módulo a secas (acme-inference = "acme_hermes_plugin") — Hermes importa el módulo y se apoya en su llamada a register_provider a nivel de módulo, replicando el contrato __init__.py de los plugins de sistema de archivos. Una vez instalado y habilitado a través del gate de abajo, Hermes lo invoca al arrancar y tus modelos aparecen en el selector hermes model y en cualquier otro sitio donde se listen providers.

El gate crítico: instalado ≠ habilitado

Esta es la regla más importante de todo el mecanismo, así que léela dos veces: hacer pip install de un paquete no significa que se cargue. El escaneo de entry points comparte los mismos interruptores que el gestor general de plugins — la allow-list plugins.enabled y la deny-list plugins.disabled:

plugins:
  enabled:
    - acme-inference   # only entry points listed here are loaded
  disabled:
    - some-other-plugin  # the deny-list always wins

Si tu nombre de paquete no está en plugins.enabled, Hermes ni siquiera lo importa — un paquete pip nunca se ejecuta solo por estar instalado. Eso importa para la seguridad: cualquier paquete del que hagas pip install podría declarar silenciosamente un entry point hermes_agent.plugins, pero solo el que permitiste explícitamente en la allow-list surte efecto.

Detalles de seguridad que conviene conocer

Más allá del gate de la allow-list, el diseño añade varias protecciones:

• Carril solo para providers: el grupo de entry points hermes_agent.plugins se comparte con los plugins generales (plugins de UI, de herramientas, etc.). La diferencia: las funciones de registro de los plugins generales reciben un argumento (register(ctx)), mientras que los hooks de registro de providers son sin argumentos por contrato. El escáner se salta cualquier callable que requiera argumentos, así que los plugins generales nunca se confunden con providers — y tampoco te llueven warnings de TypeError.
• Un paquete roto no puede tumbar a Hermes: si el entry point de un paquete de terceros falla al cargar, el fallo se traga entrada por entrada y se registra como warning; el descubrimiento de providers continúa. Un paquete malo no impedirá que Hermes arranque.
• Los integrados ganan siempre las colisiones de nombre: el escaneo de entry points se ejecuta primero en el orden de descubrimiento, y register_provider() funciona con “el último escritor gana” — así que un paquete pip nunca puede eclipsar a un provider incluido o a uno de $HERMES_HOME. Puede registrar un nombre nuevo, pero no secuestrar uno ya existente de primera parte.

Cuándo merece la pena

• Compartir una integración de modelos con todo el equipo: envuelve tu gateway interno como paquete pip; los compañeros ejecutan pip install más una línea en la allow-list y listo — se acabó editar endpoints máquina por máquina.
• Modelos privados / self-hosted: fine-tunes internos, clústeres vLLM autoalojados — empaqueta el provider, versiona con pip y actualiza con pip install -U.
• Publicarlo para el mundo: si tu integración de provider tiene valor general, súbela a PyPI — cualquiera puede instalarla y habilitarla con una línea de configuración.

Si ya extiendes las herramientas de Hermes con MCP (mira nuestra guía de configuración y variables de contexto de MCP), los plugins de provider completan la otra mitad del cuadro: MCP gestiona tools, los providers gestionan models — ambas son integraciones declarativas, una sobre el protocolo MCP y otra sobre entry points. Toda la superficie del CLI de plugins está en la página del comando hermes plugins; y un recordatorio — en configuraciones multi-profile, plugins.enabled se configura por profile (mira la guía de profiles multi-instancia), así que no des por hecho que una allow-list definida en un profile se aplica en todos.

En una línea: los plugins de provider convierten “conectar un nuevo servicio de modelos” de editar la config a mano en “pip install + una línea en la allow-list” — la fricción vive en la seguridad (la allow-list es explícita), la comodidad vive en la ingeniería (empaquetado, compartible, versionado).