Guide d’appel d’outils MiniMax M3

Oui, MiniMax M3 prend en charge l’appel d’outils.

MiniMax positionne M3 spécifiquement pour les charges de travail de codage et d’agents qui impliquent une décomposition autonome des tâches, l’invocation d’outils et un raisonnement en plusieurs étapes. Le modèle prend également en charge une fenêtre de contexte allant jusqu’à 1 million de jetons, conçue pour aider les flux de travail d’agents et de codage de longue durée.

Mais l’appel d’outils ne signifie pas que MiniMax M3 exécute directement vos API ou fonctions.

Le processus réel est le suivant :

Définir les outils
    ↓
Envoyer les outils à MiniMax M3
    ↓
M3 renvoie tool_calls
    ↓
Votre application exécute la fonction
    ↓
Renvoie le résultat à M3
    ↓
M3 continue ou renvoie une réponse finale

Comprendre cette boucle est la clé pour utiliser correctement MiniMax M3 dans un agent.

Qu’est-ce que l’appel d’outils MiniMax M3 ?

Une requête LLM normale ressemble à ceci :

Utilisateur → Modèle → Réponse

Le modèle reçoit du texte et renvoie du texte.

Cela fonctionne pour les questions auxquelles le modèle peut répondre à partir du contexte dont il dispose déjà.

Mais supposons que l’utilisateur demande :

Quel temps fait-il à Tokyo en ce moment ?

Le modèle ne doit pas inventer de données météo actuelles.

Avec l’appel d’outils, vous pouvez donner à M3 accès à une fonction telle que :

get_weather(city)

Le flux de travail devient :

Utilisateur
  ↓
MiniMax M3
  ↓
get_weather(city="Tokyo")
  ↓
Votre API météo
  ↓
Résultat météo actuel
  ↓
MiniMax M3
  ↓
Réponse finale

M3 décide quel outil utiliser et de quels arguments il a besoin.

Votre application décide ce que l’outil fait réellement.

API d’appel d’outils MiniMax M3

La documentation actuelle de l’API de génération de texte de MiniMax inclut MiniMax-M3 comme modèle pris en charge et expose :

tools
tool_choice
tool_calls

Le point de terminaison documenté est :

POST /v1/text/chatcompletion_v2

et l’identifiant actuel du modèle M3 est :

MiniMax-M3

MiniMax documente deux tool_choice modes :

auto
none

Avec auto, M3 décide s’il doit appeler un outil.

Avec none, l’utilisation d’outils est désactivée.

Étape 1 : définir un outil

Supposons que nous voulions que M3 vérifie les informations météo.

Nous décrivons d’abord la fonction au modèle :

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a city",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "The city to get weather for"
        }
      },
      "required": ["city"]
    }
  }
}

MiniMax prend actuellement en charge fonction comme type d’outil. Son schéma API exige un nom de fonction, une description et une définition des paramètres.

La qualité de ce schéma compte.

Si la description de votre outil est vague, le modèle dispose de moins d’informations pour savoir quand l’appeler.

Comparez :

Mauvais :
Obtenir des données.

avec :

Mieux :
Obtenez la météo actuelle, la température et les conditions pour une ville spécifiée.
Utilisez cet outil lorsque l'utilisateur demande la météo actuelle ou future.

La deuxième description fournit au modèle des directives de sélection d’outil beaucoup plus claires.

Étape 2 : Envoyez les outils à MiniMax M3

Une requête Python simplifiée ressemble à ceci :

import requests

url = "https://api.minimax.io/v1/text/chatcompletion_v2"

headers = {
    "Authorization": "Bearer YOUR_MINIMAX_API_KEY",
    "Content-Type": "application/json"
}

payload = {
    "model": "MiniMax-M3",
    "messages": [
        {
            "role": "user",
            "content": "What's the weather in Tokyo?"
        }
    ],
    "tools": [
        {
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "Get the current weather for a city",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "city": {
                            "type": "string"
                        }
                    },
                    "required": ["city"]
                }
            }
        }
    ],
    "tool_choice": "auto"
}

response = requests.post(
    url,
    headers=headers,
    json=payload
)

data = response.json()
print(data)

La documentation actuelle de l’API MiniMax répertorie explicitement MiniMax-M3 et les tools et tool_choice, champs de requête pour ce point de terminaison.

Étape 3 : Lire l’appel d’outil de M3

Si M3 décide qu’un outil est nécessaire, la réponse de l’assistant peut inclure un tableau tool_calls.

MiniMax documente chaque appel avec :

id
type
function.name
function.arguments

Conceptuellement, le résultat peut ressembler à ceci :

{
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Tokyo\"}"
      }
    }
  ]
}

Le point important est :

M3 n’a encore rien exécuté.

Il a généré une requête structurée indiquant :

Veuillez exécuter get_weather avec city="Tokyo".

Votre application doit maintenant analyser les arguments et exécuter la fonction réelle.

Étape 4 : Exécuter l’outil dans votre application

Par exemple :

import json

tool_call = data["choices"][0]["message"]["tool_calls"][0]

function_name = tool_call["function"]["name"]
arguments = json.loads(
    tool_call["function"]["arguments"]
)

if function_name == "get_weather":
    result = get_weather(**arguments)

Votre propre fonction pourrait appeler un véritable service météo et retourner :

{
  "city": "Tokyo",
  "temperature": 29,
  "condition": "Rain"
}

Ce résultat provient de votre outil, et non de MiniMax.

Cette distinction est essentielle lors de la création d’agents de production.

Étape 5 : Renvoyer le résultat de l’outil à M3

Maintenant, la conversation doit continuer.

Votre application devrait conserver le message de l’assistant de M3 qui contenait l’appel d’outil et ajouter le résultat de votre fonction à la conversation.

Le modèle peut ensuite utiliser le résultat réel pour générer la réponse finale.

MiniMax documente spécifiquement que les conversations d’appel de fonction à plusieurs tours devraient conserver la réponse complète de l’assistant, y compris les informations relatives à son appel d’outil, afin que la continuité du raisonnement ne soit pas perdue.

Conceptuellement, l’historique devient :

Utilisateur :
Quel temps fait-il à Tokyo ?

Assistant :

[tool call: get_weather(city=”Tokyo”)]

Outil : Tokyo : 29 °C, pluie Assistant : Il fait actuellement 29 °C et il pleut à Tokyo.

C’est la boucle d’agent de base.

Pourquoi vous devez conserver l’historique des appels d’outil

Il s’agit de l’un des détails d’implémentation les plus importants de la documentation de MiniMax.

Lorsqu’un appel d’outil se produit, ne conservez pas uniquement le texte visible.

Conservez le message complet de l’assistant.

Pourquoi ?

Parce que la prochaine requête du modèle doit comprendre :

• Quel outil il a demandé
• Quels arguments il a générés
• Quel résultat appartient à quel appel
• À quelle étape de la tâche il se trouve actuellement

Si vous ne conservez pas cet état, les flux de travail multi-étapes d’outils peuvent devenir incohérents.

Cela devient de plus en plus important à mesure que l’agent effectue plus d’appels.

Utiliser plus d’un outil

Les agents réels exposent généralement plus d’une fonction.

Un agent de codage pourrait fournir :

read_file
search_code
write_file
run_command
run_tests
git_diff

Un assistant d’entreprise pourrait fournir :

search_customer
get_order
issue_refund
create_ticket
send_email

L’utilisateur n’a pas à spécifier quelle fonction doit être appelée.

Avec tool_choice="auto", le modèle peut sélectionner parmi les outils disponibles en fonction de la demande.

Par exemple :

Utilisateur :
Trouvez pourquoi les tests de connexion échouent et corrigez le problème.

Un agent de codage pourrait effectuer :

search_code
    ↓
read_file
    ↓
run_tests
    ↓
read_file
    ↓
write_file
    ↓
run_tests
    ↓
git_diff

C’est là que l’appel d’outil se transforme en un “workflow d’agent.

Pourquoi MiniMax M3 est conçu pour cela

L’appel d’outil en soi n’est pas propre à M3.

GPT, Claude, Gemini, Qwen, GLM et de nombreux autres modèles prennent également en charge les outils.

Ce qui rend M3 intéressant, c’est à quel point MiniMax concentre le modèle sur l’exécution d’outils de longue durée.

MiniMax affirme que M3 dispose de capacités de décomposition autonome des tâches, d’invocation d’outils et de raisonnement en plusieurs étapes.

L’entreprise a également publié une expérience d’optimisation CUDA de longue durée au cours de laquelle M3 a réalisé :

147 soumissions de benchmark
1,959 appels d’outils

au cours d’un processus d’optimisation autonome d’environ 24 heures.

Cela ne signifie pas que chaque application doit exécuter des milliers d’appels d’outils.

Cela démontre le type de comportement à long horizon que MiniMax vise.

Fenêtre de contexte de MiniMax M3

M3 prend en charge jusqu’à 1M de tokens de contexte.

MiniMax indique que son API M3 prend en charge jusqu’à 1M de contexte, avec un contexte d’infrastructure minimum garanti de 512K jetons.

Pourquoi est-ce important pour l’appel d’outils ?

Parce que les agents longs accumulent du contexte.

Après de nombreuses étapes, le modèle peut avoir besoin de se souvenir :

• Instructions utilisateur d’origine
• Instructions système
• Appels d’outils précédents
• Résultats des outils
• Code source
• Fichiers
• Erreurs
• Plans
• Décisions intermédiaires

Par exemple :

Invite initiale
+ contexte du dépôt
+ 20 appels d'outil
+ 20 résultats d'outil
+ sortie de test
+ code modifié
+ instructions utilisateur supplémentaires

Tout cela consomme du contexte.

Une grande fenêtre de contexte offre à M3 une capacité accrue pour les workflows de longue durée, sans écarter immédiatement l’état antérieur.

MiniMax M3 pour les agents de codage

Le codage est l’un des cas d’utilisation les plus évidents pour l’appel d’outils de M3.

Le modèle lui-même ne modifie pas directement votre dépôt.

Votre framework d’agent expose plutôt des outils tels que :

read_file(path)
write_file(path, content)
search_code(query)
run_command(command)
run_tests()

M3 peut ensuite utiliser ces outils pour accomplir la tâche.

Par exemple :

Corrigez le bug d’authentification dans ce projet.

Le flux de travail peut devenir :

1. Rechercher le code d'authentification
2. Inspecter les fichiers concernés
3. Exécuter les tests en échec
4. Identifier la cause probable
5. Modifier l'implémentation
6. Relancer les tests
7. Inspecter les erreurs
8. Apporter une autre modification
9. Vérifier le résultat final

C’est beaucoup plus proche de l’ingénierie logicielle réelle qu’un prompt unique tel que :

Écrivez une fonction de connexion.

MiniMax positionne explicitement M3 autour des agents de codage et des flux de travail automatisés, plutôt que de la simple complétion de code.

MiniMax M3 est également multimodal

M3 est nativement multimodal.

MiniMax indique que l’entraînement multimodal a été inclus dès le début, plutôt que d’être ajouté plus tard comme un adaptateur séparé, et que le modèle prend en charge la compréhension visuelle dans le cadre de ses capacités d’agent.

Cela peut étendre les agents basés sur des outils au-delà du texte.

Par exemple :

Inspecter la capture d’écran
      ↓
Comprendre l’état de l’interface
      ↓
Déterminer l’action suivante
      ↓
Appeler l’action ordinateur/outil
      ↓
Inspecter le résultat
      ↓
Continuer

C’est utile pour les agents de navigateur, les tâches d’utilisation de l’ordinateur, l’assurance qualité visuelle et les flux de travail de développement multimodaux.

Appel d’outils MiniMax M3 vs simple appel de fonctions

Il est utile de distinguer deux concepts.

Appel de fonction simple

L'utilisateur pose une question
→ le modèle sélectionne un outil
→ l'outil renvoie des données
→ le modèle répond

Exemple :

Quel temps fait-il à Tokyo ?

Appel d’outil agentique

L'utilisateur fournit un objectif
→ le modèle planifie
→ appelle un outil
→ évalue le résultat
→ appelle un autre outil
→ modifie le plan
→ appelle d'autres outils
→ vérifie le résultat
→ atteint l'objectif

Exemple :

Trouvez le bug dans ce dépôt, corrigez-le et vérifiez que les tests passent.

M3 est beaucoup plus intéressant dans la deuxième catégorie.

Erreurs courantes d’appel d’outil MiniMax M3

1. S’attendre à ce que M3 exécute la fonction

Il ne le fait pas.

M3 génère la demande d’outil. Votre application l’exécute.

2. Ne pas conserver le message d’appel d’outil de l’assistant

Pour les workflows multi-tours, conservez la réponse complète de l’assistant associée à l’appel d’outil. MiniMax le souligne spécifiquement dans sa documentation de compatibilité.

3. Utiliser des descriptions d’outils vagues

Ne définissez pas :

do_task

alors que vous pouvez définir :

search_customer_by_email

Des outils clairs donnent au modèle une meilleure chance de choisir correctement.

4. Accorder trop de permissions aux outils

Si vous exposez :

run_command

votre application doit toujours appliquer les permissions, la validation, le sandboxing et les règles de sécurité.

Le modèle ne doit pas être l’autorité finale sur ce que votre infrastructure est autorisée à exécuter.

5. Considérer le contexte long comme une mémoire illimitée

Une fenêtre de contexte de 1M est grande, mais elle reste finie.

Les exécutions d’agent longues doivent gérer le contexte délibérément plutôt que d’y ajouter continuellement tout, sans fin.

MiniMax M3 peut-il fonctionner avec des workflows compatibles OpenAI ?

MiniMax fournit une prise en charge d’API compatible OpenAI pour son écosystème de modèles de texte, et son schéma d’appel d’outils suit des concepts familiers tels que outils, assistant tool_calls, et les messages de résultat d’outil.

La documentation d’API de MiniMax évolue activement autour de M3, donc pour les intégrations en production, vous devriez toujours utiliser la documentation d’API M3 actuelle comme source de vérité pour l’endpoint exact et les champs pris en charge.

Utiliser les modèles MiniMax dans une pile d’agents multi-modèles

Si votre agent est entièrement construit autour de MiniMax, une intégration directe de MiniMax peut être judicieuse.

Mais de nombreux développeurs d’agents testent plusieurs modèles.

Vous souhaiterez peut-être comparer :

• MiniMax
• GLM
• Qwen
• DeepSeek
• Claude
• GPT
• Gemini

La qualité de l’appel d’outils peut varier en fonction de vos schémas et flux de travail réels.

Un modèle peut être meilleur pour sélectionner des outils.

Un autre peut être meilleur pour coder.

Un autre peut être moins cher pour les longues boucles d’agent.

C’est là qu’une passerelle unifiée de modèles devient utile.

Utilisation de TokenHub pour le développement d’agents

TokenHub fournit une passerelle API compatible OpenAI pour les modèles pris en charge et documente les intégrations avec des outils tels que Claude Code, Codex, Cursor, Cline, Aider, OpenCode et d’autres agents de développement.

Son URL de base compatible OpenAI est :

https://us-api.tokenhub.com/v1

Plutôt que de réécrire toute votre architecture d’agent pour chaque fournisseur de modèles, vous pouvez conserver la couche API commune et sélectionner des modèles dans le catalogue actuel de TokenHub.

C’est particulièrement utile lors de l’évaluation de modèles d’appel d’outils, car vous pouvez exécuter le même agent, les mêmes définitions d’outils et les mêmes tâches contre différents modèles pris en charge.

Utilisez toujours l’ID de modèle exact affiché dans la liste des modèles en direct de TokenHub.

MiniMax M3 est-il efficace pour l’appel d’outils ?

MiniMax M3 est clairement conçu pour les flux de travail d’agents fortement axés sur les outils.

Les raisons les plus convaincantes de l’évaluer sont :

• Invocation native d’outils
• Raisonnement multi-étapes
• Forte orientation vers le codage
• Jusqu’à 1M de contexte
• Conception d’agent à exécution longue
• Capacité multimodale native

La question de savoir si c’est le meilleur modèle d’appel d’outils pour votre produit dépend toujours de votre propre agent.

Un agent de service client et un agent de codage peuvent préférer des modèles différents.

La bonne évaluation n’est pas :

M3 prend-il en charge les outils ?

Oui.

La meilleure question est :

M3 peut-il compléter de manière fiable mon flux de travail réel en utilisant mes outils réels à un coût et une latence acceptables ?

Foire aux questions

MiniMax M3 prend-il en charge l’appel d’outils ?

Oui. La documentation actuelle de l’API de MiniMax prend en charge tools et tool_choice pour MiniMax-M3.

Quel est l’identifiant du modèle MiniMax M3 ?

Le nom actuel du modèle d’API directe est :

MiniMax-M3

Quelles valeurs MiniMax M3 prend-il en charge pour tool_choice ?

L’API texte actuelle documente :

auto
none

MiniMax M3 exécute-t-il lui-même les outils ?

Non. Le modèle génère l’appel d’outil et les arguments. Votre application exécute la fonction externe.

Que renvoie MiniMax M3 lorsqu’il souhaite appeler un outil ?

La réponse de l’assistant peut inclure un tool_calls tableau contenant un identifiant d’appel d’outil, un nom de fonction et des arguments au format JSON.

MiniMax M3 prend-il en charge une fenêtre de contexte de 1M de tokens ?

Oui. MiniMax indique que M3 prend en charge jusqu’à 1M de tokens de contexte.

MiniMax M3 est-il adapté aux agents de codage ?

Oui. Le codage et les tâches agentiques sont deux des principales charges de travail cibles de M3.

Concevez votre agent autour du workflow, pas d’un seul fournisseur.

L’appel d’outils de MiniMax M3 est utile car il s’inscrit dans une conception d’agent plus large : le modèle peut décomposer les tâches, invoquer des outils, traiter les résultats et continuer sur de longs workflows.

Pour un agent en production, il reste toutefois utile de tester plus d’un modèle.

TokenHub fournit une couche d’API unifiée pour les modèles pris en charge, vous permettant de comparer différents LLM capables d’agir en tant qu’agents sans avoir à reconstruire votre intégration autour de chaque fournisseur.

Liens internes recommandés

• Reliez TokenHub à la page d’accueil ou au catalogue de modèles.
• Reliez l’API compatible OpenAI à la documentation de l’API TokenHub.
• Reliez plus tard les meilleurs LLM chinois pour les agents et l’appel d’outils au blog correspondant.
• Faites le lien entre les noms GLM, Qwen, DeepSeek ou Kimi concernés et leurs pages de modèle TokenHub lorsque disponibles.