OpenAI Agents API vs Responses API : comment choisir en 2026 ? Tool Calling, Structured Output, multi-agents

En un coup d’œil

Porte	Une ligne	Ce que vous tenez
Agents API	OpenAI tourne le harness Codex	Session / Environment
Responses API	Vous appelez le modèle et tournez la boucle	input / output items
Agents SDK	La boucle reste dans votre processus	runner / handoff
Chaîne JSON	Noms, arguments, résultats restent des objets	call_id / Schema

Choisir d’abord le sujet : voulez-vous posséder la boucle ? Changer de porte ; la chaîne d’appel JSON reste.

Vous choisissez qui tourne la boucle, pas qui est plus intelligent

En 2026, l’appel d’outils de GPT-6 Astra passe déjà par Responses. Agents API est une autre couche : sessions hébergées, contexte compacté, sous-agents. Même chaîne JSON. Autre sujet.

• Vous devez posséder chaque saut — validations, retries, renvoyer function_call_output — Responses API.
• Tâches de plusieurs heures, reprise hébergée, bac à sable ou sous-agents — Agents API.
• La boucle doit rester dans votre processus, mais vous voulez un runner — Agents SDK ; souvent Responses en dessous.

Comment Agents API appelle les outils : Tour OpenAI Agents API. Si Agent et Function Calling tiennent encore en un mot : Guide complet de l’agent IA.

Chaque API possède une couche

Responses est la couche basse : /v1/responses. Vous envoyez input, vous recevez des items typés : message, reasoning, function_call. L’appel d’outils Guide GPT-6 Astra exige ce chemin. Le structured output vit dans text.format, plus dans response_format de Chat Completions.

Agents API est le harness géré : POST /v1/agents/sessions. Vous déclarez Agent, Tools, Environment ; OpenAI tourne la boucle, le compact et la reprise. Quand votre fonction doit répondre, la session émet requires_action ; vous renvoyez un tool_result clé par turn_id / call_id.

Agents SDK n’est pas un troisième protocole. C’est un runner dans votre processus : handoffs, validations, stockage restent vôtres ; les appels modèle tombent souvent sur Responses. La doc traite Session, session SDK, conversation Responses et sandbox comme quatre ressources.

Tool calling : une chaîne, deux réécritures

Sur Responses vous faites responses.create à chaque tour. La table d’outils et la carte finale peuvent tenir sur la même requête :

{
  "model": "gpt-6-astra",
  "input": "Look up order A-1042.",
  "tools": [
    {
      "type": "function",
      "name": "lookup_order",
      "parameters": {
        "type": "object",
        "properties": {
          "order_id": { "type": "string", "pattern": "^[A-Z]-\\d{4}$" }
        },
        "required": ["order_id"],
        "additionalProperties": false
      }
    }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "order_card",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "order_id": { "type": "string" },
          "status": { "enum": ["paid", "pending", "void"] }
        },
        "required": ["order_id", "status"],
        "additionalProperties": false
      }
    }
  }
}

Si le modèle doit consulter, output porte un item séparé. call_id cloue l’appel au résultat :

{
  "output": [
    {
      "type": "function_call",
      "call_id": "call_3c91",
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  ]
}

Votre app exécute la fonction, puis renvoie le résultat comme prochain item d’input :

{
  "type": "function_call_output",
  "call_id": "call_3c91",
  "output": "{\"status\":\"paid\",\"amount\":99.00}"
}

Agents API plie ces tours dans une session. Créer une fois : outils, bac à sable, multi_agent ou non :

{
  "agent": {
    "model": "gpt-6-astra",
    "tools": [
      { "type": "function", "name": "lookup_order", "parameters": {
        "type": "object",
        "properties": { "order_id": { "type": "string", "pattern": "^[A-Z]-\\d{4}$" } },
        "required": ["order_id"],
        "additionalProperties": false
      }},
      { "type": "web_search" }
    ],
    "multi_agent": { "enabled": true, "max_concurrent_subagents": 3 }
  },
  "environment": { "type": "hosted", "workspace_directory": "/workspace" },
  "input": [{ "role": "user", "content": [{ "type": "input_text", "text": "Look up A-1042." }] }]
}

Quand votre fonction est due, le harness s’arrête sur required_actions. La réécriture n’est pas function_call_output ; c’est un tool result avec turn_id :

{
  "type": "tool_result",
  "turn_id": "turn_2",
  "call_id": "call_3c91",
  "success": true,
  "output": "{\"status\":\"paid\"}"
}

Les noms diffèrent. La porte non : le Schema décide ce qui peut s’exécuter. La ligne MCP est une autre orthographe de la même table ; frontière dans MCP Tool Schema vs Function Calling.

Le structured output verrouille la carte finale, pas les arguments d’outil

Responses met la forme finale dans text.format. Cela contraint ce que l’utilisateur voit, pas les arguments d’outil. Les outils ont encore leur Schema. Contrat dans Pourquoi l’IA a besoin de JSON Schema.

• Responses : text.format.json_schema + strict: true verrouille la carte finale.
• Agents API : la boucle est hébergée ; l’artefact final veut encore un Schema. Paramètres function / MCP restent serrés.
• Les deux : le structured output n’est pas une porte. Montants, confirmation et mise en prod restent à l’hôte.

L’erreur habituelle : verrouiller la carte et laisser lookup_order en object large. La carte est propre. L’effet de bord a déjà couru.

Multi-agent : éventail hébergé, ou votre handoff

« Collaboration multi-agents » n’est pas une troisième intelligence. C’est qui tient l’orchestration :

• Agents API : multi_agent.enabled. Chaque sous-agent garde son contexte. L’agent principal utilise create / wait / interrupt. Plafonner la concurrence.
• Agents SDK : les objets handoff vivent dans votre runner. Validations et stockage restent vôtres.
• Responses : pas de sous-agent intégré. Vous enchaînez responses.create ou garez l’état dans Conversations.

Un handoff doit être du JSON auditable, pas « passez ça à la facturation ». Le capturer en Schema : JSON Schema et workflows d’agents.

Une table, trois portes

La comparaison officielle se comprime en questions d’ingénierie :

Il n’y a pas de « meilleure API ». Il y a seulement « le sujet est-il de votre côté ».

Quatre questions qui choisissent la porte

Ne pas choisir sur une page produit. Ces quatre :

1. L’effet de bord métier peut-il quitter votre processus ? Remboursements et écritures qui exigent votre accord commencent sur Responses ou le SDK.
2. Le travail survivra-t-il à une fenêtre de contexte ? Oui, et vous ne voulez pas compactez vous-même : Agents API.
3. Faut-il un bac à sable pour commandes et fichiers ? L’Environment Agents API est prêt. Responses vous laisse le monde d’exécution.
4. Faut-il des sous-agents en parallèle ? Oui, et vous ne construirez pas l’orchestration : activer multi_agent et geler le plafond.

Si les quatre « oui » tombent côté hébergé, entrer dans Agents API. Si un saut doit rester dans votre main, commencer par Responses. Le SDK est la troisième : la boucle est à vous, avec moins de colle.

Avant de comparer, étaler les deux traces JSON

Une mauvaise porte veut souvent dire que personne n’a regardé les objets. Mettre les deux traces sur la table.

• formater le output[] Responses et les items de session Agents. Vérifier que call_id correspond.
• Avec extraction JSONPath, extraire name, arguments et text.format. Ne pas scanner la doc à l’œil.
• JSON Diff la même commande sous les deux portes. Si la boucle a dérivé, d’abord la forme de réécriture, ensuite le modèle.
• Relire le Schema de la carte finale et celui des arguments d’outil séparément. Verrouiller la carte sans les arguments, c’est de la façade.
• Ne pas coller commandes ou URL MCP intranet dans un formateur public. JSONSort tourne localement dans le navigateur.

Si les deux traces se reconstruisent, vous choisissez une porte — pas un slogan.

Pièges

• Croire qu’Agents API remplace Responses. La doc liste deux points de départ. L’appel d’outils Astra passe encore par Responses.
• Traiter Session et Conversation comme une ressource. En supprimer une ne nettoie pas l’autre.
• Schema seulement sur la carte finale, arguments d’outil larges. Les effets de bord arrivent quand le function_call tourne.
• Activer multi_agent sans plafond de concurrence. L’éventail hébergé brûle encore des jetons et élargit les effets de bord.
• Utiliser le SDK et sauter la porte. Le runner tourne la boucle. Il ne valide pas le montant.
• Choisir une API sur une démo. La démo a caché la boucle. Demander où siège le sujet.

FAQ

Par quelle API un projet 2026 devrait-il commencer ?

Par Responses : vous voyez chaque saut. Ne passer la boucle à Agents API que si le travail doit traverser des fenêtres, ou si vous avez besoin d’un bac à sable hébergé ou de sous-agents.

GPT-6 Astra peut-il n’utiliser qu’Agents API et éviter Responses ?

Vous pouvez n’ouvrir qu’une session Agents. La doc d’appel d’outils Astra pointe encore vers Responses. Chaînes courtes, structured output et boucle que vous tournez restent sur Responses.

Le structured output peut-il remplacer le tool calling ?

Non. Le structured output verrouille l’objet final. Le tool calling verrouille les effets de bord. Remboursements, consultations, éditions de fichiers passent par le JSON d’outil ; la carte vue par l’utilisateur par text.format.

Le multi-agent exige-t-il Agents API ?

Non. Les handoffs SDK et votre propre chaîne d’appels Responses sont aussi du multi-agent. Agents API ne fait que rendre l’éventail hébergé.

Puis-je mélanger les deux API ?

Oui — ne pas mélanger les ressources. Extraire une carte structurée sur Responses ; lancer le long travail sur une session Agents. Créer et supprimer Session, Conversation et sandbox séparément.

Conclusion

Agents API et Responses API ne sont pas deux générations. L’une héberge la boucle. L’autre vous la donne. Tool calling, structured output et multi-agent ne sont que des objets différents sur cette chaîne.

Écrire d’abord le sujet : ce saut doit-il quitter votre processus ? Puis choisir la porte. Les modèles changeront. call_id et Schema doivent d’abord tenir.

Pour aller plus loin

• OpenAI Agents API, tour complet Comment Session, tool calling et Schema se relient
• Qu’est-ce qu’un agent IA ? Guide complet Runtime et contrat JSON
• Pourquoi l’IA a besoin de JSON Schema Schema / Function Calling / Structured Output
• JSON Schema et workflows d’agents Capturer outils et état en Schema
• MCP Tool Schema vs Function Calling Frontière de protocole du JSON d’outil
• Boîte à outils locale JSONSort Formater, valider, Diff
• Tous les articles Plus de notes JSON et IA

Journal : 2026-09-21 Première publication