For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Définition des agents

Commencez par configurer un seul agent avant de passer à un workflow plus vaste.

L’agent est l’unité de base d’un workflow construit avec le SDK. Il réunit un modèle et des instructions. Vous pouvez aussi configurer son comportement à l’exécution avec des outils, des garde-fous, des serveurs MCP, des transferts entre agents et des sorties structurées.

Que configurer au niveau de l’agent ?

Configurez directement sur l’agent les éléments propres à sa spécialité.

Propriété Fonction Pour en savoir plus
name Donner à l’agent un nom lisible dans les traces et les interfaces d’outils et de transfert Cette page
instructions Définir la tâche, les contraintes et le style de l’agent Cette page
prompt Utiliser une configuration de prompt enregistrée pour les exécutions via l’API Responses Modèles et fournisseurs
model et paramètres du modèle Choisir le modèle et ajuster son comportement Modèles et fournisseurs
tools Définir les outils que l’agent peut appeler directement Utilisation des outils
handoffDescription Indiquer aux autres agents quand déléguer une tâche à cet agent Orchestration et transferts entre agents
handoffs Déléguer une tâche à un autre agent Orchestration et transferts entre agents
outputType Renvoyer une sortie structurée plutôt que du texte brut Cette page
Garde-fous et approbations Mettre en place des procédures de validation, de blocage et de vérification Garde-fous et vérification humaine
Serveurs MCP et outils MCP hébergés Ajouter des fonctionnalités accessibles via MCP Intégrations et observabilité

Commencez par un agent spécialisé

Définissez l’agent le plus simple capable de prendre en charge une tâche précise. Ajoutez d’autres agents uniquement si vous devez répartir les responsabilités, donner des instructions distinctes, proposer des interfaces d’outils différentes ou appliquer des politiques d’approbation différentes.

Définir un seul agent
import { Agent, tool } from "@openai/agents";
import { z } from "zod";

const getWeather = tool({
  name: "get_weather",
  description: "Return the weather for a given city.",
  parameters: z.object({ city: z.string() }),
  async execute({ city }) {
    return `The weather in ${city} is sunny.`;
  },
});

const agent = new Agent({
  name: "Weather bot",
  instructions: "You are a helpful weather bot.",
  model: "gpt-6-astra",
  tools: [getWeather],
});

Configurez les instructions, les transferts et les sorties

Trois choix de configuration méritent une attention particulière.

  • Commencez par définir des instructions statiques dans instructions. Si les consignes dépendent de l’utilisateur actuel, du locataire ou du contexte d’exécution, utilisez une fonction de rappel qui génère les instructions dynamiquement plutôt que de concaténer des chaînes de caractères au point d’appel.
  • Rédigez une description courte et concrète dans handoffDescription pour que les agents chargés du routage sachent quand choisir ce spécialiste.
  • Utilisez outputType si le code en aval a besoin de données typées plutôt que de texte libre.
Renvoyer une sortie structurée
import { Agent, run } from "@openai/agents";
import { z } from "zod";

const calendarEvent = z.object({
  name: z.string(),
  date: z.string(),
  participants: z.array(z.string()),
});

const agent = new Agent({
  name: "Calendar extractor",
  instructions: "Extract calendar events from text.",
  outputType: calendarEvent,
});

const result = await run(agent, "Dinner with Priya and Sam on Friday.");

console.log(result.finalOutput);

Utilisez prompt pour référencer une configuration de prompt enregistrée dans l’API Responses sans intégrer l’intégralité du prompt système au code.

Séparez le contexte local du contexte du modèle

Le SDK vous permet de transmettre l’état de l’application et ses dépendances à une exécution sans les envoyer au modèle. Utilisez le contexte local pour les informations sur l’utilisateur authentifié, les clients de base de données, les outils de journalisation et les fonctions utilitaires.

Transmettre le contexte local aux outils
import { Agent, run, tool } from "@openai/agents";
import { z } from "zod";

const fetchUserAge = tool({
  name: "fetch_user_age",
  description: "Return the age of the current user.",
  parameters: z.object({}),
  // TypeScript users can type this as RunContext<{ name: string; uid: number }>.
  async execute(_args, runContext) {
    return `User ${runContext?.context.name} is 47 years old`;
  },
});

const agent = new Agent({
  name: "Assistant",
  tools: [fetchUserAge],
});

const result = await run(agent, "What is the age of the user?", {
  context: { name: "John", uid: 123 },
});

console.log(result.finalOutput);

La distinction tient à ce qui est visible de chaque côté.

  • Le modèle a accès à l’historique de la conversation.
  • Votre code a accès au contexte d’exécution.

Si le modèle a besoin d’une information, fournissez-la dans les instructions, dans les données d’entrée, via un mécanisme de recherche d’informations ou via un outil. Si seul votre environnement d’exécution en a besoin, conservez-la dans le contexte local.

Quand répartir le travail entre plusieurs agents ?

Scindez un agent en plusieurs lorsqu’un seul spécialiste ne devrait pas prendre en charge toute la réponse ou lorsque les fonctionnalités à mettre en œuvre diffèrent sensiblement. Voici quelques cas courants.

  • Un spécialiste a besoin d’un outil différent ou d’une autre interface MCP.
  • Un spécialiste a besoin d’une politique d’approbation différente ou d’un garde-fou différent.
  • Une branche du workflow nécessite un autre modèle ou un autre style de sortie.
  • Vous souhaitez que les décisions de routage apparaissent explicitement dans les traces plutôt que de les confier à un seul long prompt.

Étapes suivantes

Une fois votre premier agent spécialisé bien défini, consultez le guide qui répond à votre prochaine question de conception.