Si vous voulez créer une application d’IA unique avec GPT, Claude, Gemini, DeepSeek et Grok, utilisez une API unifiée pour le chemin de requête commun et conservez la stratégie de routage dans votre application. CometAPI fournit une URL de base compatible OpenAI et un catalogue de modèles partagé, ce qui permet à un service Python d’appeler différents identifiants de modèle via un seul client. Votre code décide toujours quel modèle s’exécute, quels outils sont autorisés et quand un repli est sans risque.
Ce tutoriel construit un agent Grok 4.7 qui peut demander deux outils métier en lecture seule, rejette les outils inconnus et les arguments mal formés avant exécution, et bascule vers un autre modèle validé par des tests de contrat uniquement après certaines pannes transitoires sélectionnées. L’objectif n’est pas un système autonome magique. C’est une petite boucle, inspectable, qui peut être testée et exploitée en production.
Ce que vous allez construire
L’agent comporte cinq parties explicites :
- Une seule instance cliente CometAPI. Le SDK Python OpenAI utilise l’URL de base CometAPI indiquée dans la configuration ci-dessous.
- Grok 4.7 comme modèle principal. L’identifiant de modèle CometAPI actuel est
grok-4.7. - Un registre d’outils. Le modèle peut proposer un appel de fonction, mais seul le code applicatif peut exécuter une fonction présente sur la liste d’autorisation.
- Une boucle d’agent bornée. La boucle s’arrête après un nombre fixe de tours de modèle au lieu de tourner indéfiniment.
- Une stratégie de repli ordonnée. Des identifiants de modèles compatibles GPT, Claude, Gemini ou DeepSeek ne sont tentés qu’après une défaillance de modèle/API considérée comme réessayable.
Grok 4.7 prend en charge l’appel de fonctions, et CometAPI documente actuellement les routes /v1/chat/completions et /v1/responses pour le modèle. Ce tutoriel utilise Chat Completions car ses tools compatibles OpenAI, les appels d’outil de l’assistant et les messages de résultat tool correspondants se mappent directement à une boucle Python compacte et inspectable. La compatibilité de transport ne garantit pas une parité fonctionnelle sur chaque modèle ; chaque repli configuré doit donc passer les mêmes tests de contrat avant d’entrer en production.
État du raisonnement dans des agents Grok 4.7 multi-tours
Grok 4.7 accepte low, medium, high ou xhigh comme effort de raisonnement, avec high par défaut. Sur l’API Responses de xAI, chaque réponse Grok 4.7 inclut reasoning.encrypted_content ; une boucle multi-tours gérée côté client doit renvoyer les éléments de raisonnement retournés, inchangés, dans la requête suivante. Les longues boucles peuvent aussi utiliser la context compaction : conservez l’élément de compaction retourné comme état opaque et ajoutez les nouveaux tours après celui-ci. Comme il s’agit de champs de réponse avec état, spécifiques au fournisseur, vérifiez que la route CometAPI sélectionnée les renvoie de bout en bout avant d’en faire une dépendance de production.
Architecture d’agent : le modèle propose, votre application décide
Un flux d’appel d’outils sûr est simple :
User request → model response → validate tool call → execute allowlisted tool → append tool result → model response
Le modèle ne reçoit jamais d’identifiants de base de données et n’exécute jamais directement du Python. Il produit une requête structurée telle que « appeler get_order_status avec cet identifiant de commande ». Votre application vérifie le nom de l’outil, analyse les arguments, applique les règles d’autorisation et métier, exécute la fonction et renvoie un résultat sérialisé.
Cette séparation compte davantage que le choix du modèle. Un modèle de repli doit hériter de la même frontière d’outils — pas d’un périmètre plus large — et les résultats d’outils doivent être traités comme des données non fiables lorsqu’ils contiennent du contenu externe.
Comment créer un agent Grok 4.7 en Python
Étape 1 : Configurer le SDK Python OpenAI pour CometAPI
Installez le SDK OpenAI :
pip install openai
Définissez la configuration via des variables d’environnement :
export COMETAPI_KEY="your-cometapi-key"
export PRIMARY_MODEL="grok-4.7"
export FALLBACK_MODEL_1="your-compatible-gpt-model-id"
export FALLBACK_MODEL_2="your-compatible-claude-model-id"
export FALLBACK_MODEL_3="your-compatible-gemini-model-id"
export FALLBACK_MODEL_4="your-compatible-deepseek-model-id"
Ce tutoriel utilise Chat Completions car ses appels d’outils explicites côté assistant et les messages de résultat d’outil correspondants rendent le flux de contrôle facile à inspecter dans un exemple Python compact. Pour des boucles plus longues et avec état, évaluez l’API Responses comme décrit ci-dessus. De plus, ne copiez pas d’anciens identifiants de modèle depuis un billet de blog vers la production : récupérez le catalogue public GET /api/models de CometAPI lors du déploiement ou du démarrage, puis confirmez les capacités et la tarification dans le répertoire des modèles.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
max_retries=0,
timeout=30.0,
)
Le délai d’expiration explicite et la désactivation des réessais du SDK sont intentionnels. L’application classera les défaillances et décidera de répéter la requête ou de passer au modèle suivant. Les réessais cachés compliquent la compréhension de la latence, des effets de bord dupliqués et du comportement de repli.
Étape 2 : Définir d’abord des outils étroits en lecture seule
Commencez par des outils qui lisent les données plutôt que de les modifier. Les définitions suivantes permettent à l’agent de vérifier une commande et de consulter le stock. L’implémentation renvoie des données de démonstration ; remplacez-la par des appels authentifiés à vos propres services.
import json
TOOLS = [
{
"type": "function",
"function": {
"name": "get_order_status",
"description": "Lire l'état actuel d'une commande.",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"}
},
"required": ["order_id"],
"additionalProperties": False,
},
},
},
{
"type": "function",
"function": {
"name": "check_inventory",
"description": "Lire le stock disponible pour un SKU.",
"parameters": {
"type": "object",
"properties": {
"sku": {"type": "string"}
},
"required": ["sku"],
"additionalProperties": False,
},
},
},
]
def get_order_status(order_id: str) -> dict:
# Remplacez cette démo par un appel de service authentifié en lecture seule.
return {"order_id": order_id, "status": "in_transit"}
def check_inventory(sku: str) -> dict:
# Remplacez cette démo par un appel de service authentifié en lecture seule.
return {"sku": sku, "available_units": 12}
TOOL_REGISTRY = {
"get_order_status": get_order_status,
"check_inventory": check_inventory,
}
Un schéma JSON améliore la forme de la requête, mais ce n’est pas une autorisation. Validez la longueur et le format des arguments, confirmez que l’utilisateur actuel peut accéder à la commande ou au SKU demandés, et limitez la taille de chaque résultat d’outil avant de le renvoyer au modèle.
Étape 3 : Ajouter une politique de repli multi-modèles étroite
Le repli doit récupérer d’une défaillance temporaire de route, pas masquer des requêtes cassées. Le guide officiel de repli de CometAPI recommande de passer à la route configurée suivante pour les erreurs de connexion, délais d’expiration, HTTP 408, HTTP 429 et réponses 5xx temporaires. Des identifiants invalides, des paramètres non pris en charge et des requêtes invalides doivent échouer immédiatement.
from openai import APIConnectionError, APIStatusError, APITimeoutError
def configured_models() -> list[str]:
names = [
os.getenv("PRIMARY_MODEL", "grok-4.7"),
os.getenv("FALLBACK_MODEL_1"),
os.getenv("FALLBACK_MODEL_2"),
os.getenv("FALLBACK_MODEL_3"),
os.getenv("FALLBACK_MODEL_4"),
]
return [name for name in names if name]
def is_retryable(error: Exception) -> bool:
if isinstance(error, (APIConnectionError, APITimeoutError)):
return True
if isinstance(error, APIStatusError):
return error.status_code in {408, 429} or error.status_code >= 500
return False
def complete_with_fallback(messages: list[dict], tools: list[dict]):
models = configured_models()
last_error = None
for index, model in enumerate(models):
try:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
return response, model
except Exception as error:
last_error = error
final_route = index == len(models) - 1
if final_route or not is_retryable(error):
raise
raise RuntimeError("No configured model completed the request") from last_error
La liste de modèles est une configuration, pas un classement de qualité. Choisissez des replis qui prennent en charge les mêmes rôles de message, schéma d’outils, modalité d’entrée, exigences de contexte et comportement de réponse nécessaires à cet agent. Journalisez la route sélectionnée et la défaillance ayant causé chaque transition.
Étape 4 : Exécuter la boucle d’agent Grok 4.7 bornée
La boucle ci-dessous envoie la conversation, exécute les éventuels appels d’outils autorisés, ajoute les résultats avec le tool_call_id correspondant et demande au modèle sélectionné de finaliser la réponse.
def execute_tool_call(tool_call) -> str:
name = tool_call.function.name
if name not in TOOL_REGISTRY:
return json.dumps({"error": f"Outil non autorisé : {name}"})
try:
arguments = json.loads(tool_call.function.arguments)
result = TOOL_REGISTRY[name](**arguments)
return json.dumps(result)
except (json.JSONDecodeError, TypeError, ValueError) as error:
return json.dumps({"error": f"Arguments d'outil invalides : {error}"})
def run_agent(user_text: str, max_turns: int = 4) -> dict:
messages = [
{
"role": "system",
"content": (
"Vous êtes un agent d'assistance. Utilisez les outils uniquement lorsque c'est nécessaire. "
"N'inventez jamais des données de commande ou de stock."
),
},
{"role": "user", "content": user_text},
]
route_log = []
for turn in range(max_turns):
response, model = complete_with_fallback(messages, TOOLS)
route_log.append({"turn": turn + 1, "model": model})
assistant = response.choices[0].message
messages.append(assistant.model_dump(exclude_none=True))
if not assistant.tool_calls:
return {
"answer": assistant.content,
"routes": route_log,
"usage": response.usage.model_dump() if response.usage else None,
}
for tool_call in assistant.tool_calls:
messages.append(
{
"role": "tool",
"tool_call_id": tool_call.id,
"content": execute_tool_call(tool_call),
}
)
raise RuntimeError("Agent stopped after reaching max_turns")
result = run_agent("Où en est la commande A-104, et le SKU BLUE-42 est-il en stock ?")
print(result["answer"])
print(result["routes"])
Le code prend en charge plusieurs appels d’outils dans une seule réponse du modèle, car il ajoute un résultat pour chaque appel renvoyé. Si un outil modifie l’état — en envoyant un e-mail, en passant une commande ou en émettant un remboursement — ajoutez une clé d’idempotence et une étape de confirmation humaine. Ne redémarrez jamais tout le tour d’agent à l’aveugle après un délai d’expiration si un effet de bord a peut-être déjà eu lieu.
Comment GPT, Claude, Gemini et DeepSeek s’intègrent à la même application
CometAPI peut réduire la duplication au niveau de la connexion : un seul compte, une URL de base compatible OpenAI pour le chemin commun, et un identifiant de modèle sélectionné par le code applicatif. Cela fait de GPT, Claude, Gemini, DeepSeek et Grok des candidats derrière une interface interne unique.
Cela ne rend pas les modèles interchangeables. Avant d’ajouter un repli, vérifiez :
- l’identifiant de modèle actuel est renvoyé par le catalogue CometAPI ;
- la route prend en charge le schéma d’outils requis et les rôles de message ;
- les arguments d’appel d’outil et le comportement en cas d’appels multiples correspondent au contrat de l’agent ;
- la fenêtre de contexte et les modalités d’entrée conviennent à la requête ;
- la réponse peut être validée avant d’atteindre l’utilisateur ;
- la latence et le coût restent dans le budget produit.
Des fonctionnalités natives au fournisseur peuvent exiger un point de terminaison natif ou un adaptateur séparé. Gardez ces exceptions explicites au lieu de forcer chaque capacité à passer par l’interface commune.
Le repli multi-modèles Grok 4.7 n’est pas un système multi-agents
Une chaîne de repli multi-modèles choisit un autre modèle quand une route échoue. Un système multi-agents assigne des responsabilités différentes à des agents distincts — par exemple, un planificateur, un chercheur et un réviseur. Ces deux modèles résolvent des problèmes différents.
Si vous étendez cet agent Grok 4.7 vers un flux multi-agents, donnez à chaque agent un rôle étroit, une liste d’outils autorisés séparée, un budget borné et un passage de relais structuré. Ne laissez pas chaque agent appeler tous les outils ni transférer une transcription illimitée. Commencez par un seul agent jusqu’à ce que les données d’évaluation prouvent que la séparation des rôles améliore le résultat.
Garde-fous de production pour un agent Grok 4.7
Valider avant l’exécution d’un outil
Vérifiez les noms d’outils, les schémas d’arguments, l’appartenance locataire, les permissions utilisateur et les limites de débit dans le code applicatif. Considérez les descriptions d’outils comme des indications pour le modèle, pas comme un contrôle de sécurité.
Séparer les outils de lecture des outils d’écriture
Les outils en lecture seule peuvent souvent s’exécuter automatiquement après autorisation. Les outils d’écriture doivent exiger des contrôles plus stricts, l’idempotence et une confirmation pour les actions conséquentes.
Borner chaque boucle
Définissez un maximum de tours de modèle, d’appels d’outils, de temps mur, de taille d’invite et de budget de jetons. Renvoyez une erreur contrôlée ou un chemin d’escalade lorsqu’une borne est atteinte.
Enregistrer la chaîne de décision
Journalisez la tâche demandée, la version de la politique, l’identifiant de modèle sélectionné, la raison du repli, le nom de l’outil, la latence de l’outil, le résultat de validation, l’utilisation des jetons et l’état final. N’enregistrez pas de secrets ni de contenu client inutile.
Utiliser des tests contractuels, pas des suppositions
Exécutez les mêmes jeux de tests contre chaque modèle configuré. Un ensemble minimal utile couvre une réponse normale, un appel d’outil, plusieurs appels d’outils, des arguments mal formés, un outil inconnu, un délai d’expiration d’un outil, un 429 du modèle principal et une clé API invalide qui ne doit pas déclencher de repli.
Liste de contrôle de déploiement
- Récupérez les identifiants de modèle actuels et vérifiez la route Grok 4.7 avant le déploiement.
- Conservez la clé CometAPI dans un gestionnaire de secrets, jamais dans le code source ou les invites.
- Commencez avec des outils en lecture seule et des schémas JSON explicites.
- Appliquez l’authentification et l’autorisation locataire avant chaque appel d’outil.
- N’autorisez le repli que pour des erreurs transitoires classifiées.
- Testez chaque repli selon le même contrat d’appel d’outils.
- Ajoutez l’idempotence et la confirmation avant d’activer des outils d’écriture.
- Définissez des limites de boucle, de latence, de contexte et de coût.
- Mesurez le succès de la tâche, pas seulement la disponibilité de l’API.
Pourquoi construire cet agent via CometAPI ?
CometAPI est utile ici car l’intégration commune reste légère. Le SDK Python OpenAI pointe vers une seule URL de base, Grok 4.7 est sélectionné par identifiant de modèle, et des modèles compatibles d’autres fournisseurs peuvent être placés derrière la même politique de routage détenue par l’application.
Cela donne à une équipe la possibilité d’évaluer GPT, Claude, Gemini et DeepSeek sans disséminer du code de connexion spécifique à chaque fournisseur dans le produit. Cela préserve aussi une frontière importante : CometAPI fournit l’accès, tandis que votre application possède les contrôles de capacité, l’exécution des outils, la stratégie de repli, l’évaluation et le comportement face à l’utilisateur.
Consultez la page du modèle Grok 4.7, configurez le client depuis le guide de démarrage CometAPI, et récupérez les identifiants de modèles actuels avant de choisir des replis de production.
FAQ
Quelle API utiliser pour une application avec GPT, Claude, Gemini et DeepSeek ?
Pour le chemin commun de chat et d’appel d’outils, une API unifiée compatible OpenAI comme CometAPI peut réduire le travail d’intégration. Conservez la sélection de modèle et la stratégie de repli dans votre application, et utilisez des adaptateurs natifs du fournisseur lorsqu’une fonctionnalité requise ne rentre pas dans le contrat partagé.
Grok 4.7 peut-il appeler des fonctions Python directement ?
Grok 4.7 peut renvoyer des requêtes d’appel de fonction structurées. Votre application Python analyse la requête, la valide, exécute une fonction présente sur la liste d’autorisation et renvoie le résultat au modèle. Le modèle lui-même n’exécute pas Python localement.
Chaque erreur doit-elle déclencher un modèle différent ?
Non. Utilisez le repli pour certaines erreurs de connexion, délais d’expiration, 408, 429 et réponses 5xx temporaires. Les requêtes invalides, échecs d’authentification et paramètres non pris en charge doivent être corrigés plutôt qu’envoyés à un autre modèle.
Puis-je utiliser un seul schéma d’outils avec chaque modèle ?
Uniquement après test. Un transport commun ne garantit pas un comportement d’outils identique, la qualité des arguments, le comportement en appels parallèles ni l’application du schéma. Ajoutez un modèle à la chaîne seulement après qu’il a passé les tests de contrat de l’agent.
Un système de repli multi-modèles est-il un système multi-agents ?
Non. Le repli modifie le modèle utilisé pour une requête après une défaillance de route. Une architecture multi-agents assigne des tâches différentes à des agents séparés. Construisez-les comme des couches distinctes avec des tests et des contrôles séparés.