Proveedores de modelos: Descripción general

Los proveedores de modelos son la abstracción de ZeroClaw sobre cualquier endpoint de LLM que el agente pueda llamar. Cada solicitud de chat-completion pasa por una implementación del trait ModelProvider (zeroclaw-api::ModelProvider), ya sea que el destino sea una API remota, un servidor de inferencia autoalojado o un modelo de Ollama local.

Un agente accede a un proveedor haciendo referencia a él; consulta Agents para entender cómo encaja esa conexión.

¿Por qué proveedor de “model”? Usamos la frase “model provider” de manera consistente, también existen proveedores de TTS y proveedores de transcripción, y mantener el calificador específico evita ambigüedades.

Forma de configuración

Los providers se tipifican por familia y se direccionan como providers.models.<type>.<alias>. <type> es un slot de familia canónico (consulta el Catálogo para ver todos los slots). Hay un slot por proveedor, sin sinónimos: azure_openai, azure-openai y claude (para Anthropic) no se aceptan.

<alias> es el nombre de instancia asignado por el operador, y puedes definir tantos alias por tipo como quieras. Ejecuta varios perfiles de la misma familia de proveedor en paralelo: mismo type, alias diferentes, cada uno con su propia clave, modelo y configuración. Por ejemplo, dos cuentas de Anthropic como anthropic.personal y anthropic.work (cada una con su propio api_key y model), donde un agente elige una con model_provider = "anthropic.personal" (o "anthropic.work"). Agrega y edita estos a través de las interfaces que se indican a continuación, no manualmente:

Consulta Configuration para ver el esquema completo y Catalog para ver un ejemplo trabajado por familia.

Despacho por agente: no hay valores predeterminados globales

Una entrada de proveedor por sí sola no hace nada. Para usarla, un agente la referencia mediante model_provider (junto con un risk_profile y un runtime_profile opcional). risk_profile y runtime_profile referencian mapas de alias independientes, por lo que sus nombres no tienen que coincidir. Config::validate() falla de forma explícita al arrancar si alguna referencia no se resuelve. Cada punto de llamada elige un alias configurado o renuncia explícitamente; no existe ningún ajuste global de “proveedor predeterminado” ni de “modelo predeterminado”.

Para implementaciones multiagente, asigne a cada agente su propio model_provider. Los canales que ingieren mensajes se vinculan a un agente a la vez mediante la lista channels del agente; consulte Canales para obtener una visión completa.

Voz (TTS) y transcripción por agente

La síntesis de voz y la conversión de voz a texto siguen el mismo patrón: una entrada de proveedor de familia tipada, y luego una referencia por agente. No existen campos selectores globales de TTS o transcripción. Cada agente que quiera voz configura su propio enrutamiento.

¿Qué sigue?

• Configuración: el esquema completo de [providers.*], configuración tipada de Azure, variantes regionales y de OAuth
• Streaming: cómo fluyen los tokens, las llamadas a herramientas y los deltas de razonamiento
• Enrutamiento: despacho multiagente y OpenRouter como capa de enrutamiento
• Catálogo de proveedores: cada familia compatible con un ejemplo TOML práctico
• Proveedores personalizados: apuntar el slot custom a un endpoint compatible con OpenAI, o implementar el trait ModelProvider