Guide de référence

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Trouvez rapidement des informations détaillées sur chaque composant du framework Agent dans cette référence complète.

Structure des dossiers

Pour créer un agent, vous devez créer un dossier portant son nom et contenant au moins les fichiers suivants:

• agent.py: fichier principal de l'agent. Vous devez définir votre agent racine sous la variable globale root_agent.
• __init__.py: fichier du module Python. Il doit contenir au moins une ligne from agents import Agent pour importer la classe Agent.

Vous pouvez également ajouter les fichiers suivants:

• requirements.txt: fichier de dépendances Python de l'agent.
• README.md: fichier README de l'agent. Il doit contenir les instructions de configuration et d'exécution de l'agent.

Agent.py minimal

La création d'un agent commence par la création d'une instance de la classe Agent. L'agent minimal doit présenter les attributs suivants:

• name: nom de l'agent.
• model: nom du modèle LLM à utiliser.
• instruction: instructions en langage naturel pour l'agent.

Exemple :

from agents import Agent

root_agent = Agent(
    model='gemini-1.5-flash',
    name='root_agent',
    instruction="Be polite and answer all users' questions.",
)

Pour créer un agent minimal, vous pouvez copier le dossier _empty_agent et modifier le fichier agent.py.

Attributs

nom

  name: str

Nom de l'agent.

• Identifiant

  • Le nom doit respecter la convention d'attribution de noms des identifiants.
  • Une chaîne est considérée comme un identifiant valide si elle ne contient que des lettres alphanumériques (a-z) et (0-9), ou des traits de soulignement (_). Un identifiant valide ne peut pas commencer par un chiffre ni contenir d'espace.

• Unique

  • Le nom doit être unique dans l'ensemble de l'arborescence des agents.

• Agent racine

  • Bien que la variable de l'agent racine doive être nommée root_agent, vous pouvez définir un attribut de nom plus explicite pour l'agent racine.

modèle

  model: str

Nom du modèle LLM à utiliser.

• Obligatoire pour l'agent LLM

  • L'attribut "model" n'est obligatoire que pour l'agent LLM.
  • Vous n'avez pas besoin de définir l'attribut de modèle pour les agents séquentiels, en boucle ou autres agents non LLM.

• Agent parent

  • Vous pouvez omettre l'attribut de modèle. Dans ce cas, l'agent utilisera l'attribut de modèle de l'agent parent / ancêtre.

• Format

  • Le format du nom du modèle varie selon le fournisseur du LLM.
  • Pour Gemini, il ressemble à gemini-1.5-flash ou gemini-2.0-flash-exp.
  • Pour Anthropic sur Vertex, il ressemble à claude-3-5-sonnet-v2@20241022.
  • Bien que la conception du framework autorise n'importe quel fournisseur de modèles, nous n'acceptons actuellement que Gemini et Anthropic sur Vertex.

instruction

  instruction: str | InstructionProvider

Instructions en langage naturel pour l'agent.

• Obligatoire pour l'agent LLM

  • Cette instruction n'est obligatoire que pour l'agent LLM.
  • Vous n'avez pas besoin de définir l'attribut d'instruction pour les agents séquentiels, en boucle ou autres agents non LLM.

• Type de données

  • L'instruction peut être une chaîne.
  • L'instruction peut également être un InstructionProvider appelable.

• InstructionProvider

  • Un InstructionProvider est défini comme Callable[[InvocationContext], str].
  • Il vous permet de fournir une fonction pour générer dynamiquement l'instruction en fonction du contexte d'appel.

• État

  • L'instruction est un modèle de chaîne. Vous pouvez utiliser la syntaxe {var} pour insérer des valeurs dynamiques dans l'instruction.

  var

  permet d'insérer la valeur de la variable d'état nommée var.

  artifact.var

  permet d'insérer le contenu textuel de l'artefact nommé "var".
  • Si la variable d'état ou l'artefact n'existe pas, l'agent génère une erreur. Si vous souhaitez ignorer l'erreur, vous pouvez ajouter un ? au nom de la variable, par exemple {var?}.

• Consignes

  • Commencez par indiquer qui est l'agent, ce qu'il peut faire et ce qu'il ne peut pas faire.
  • Vous pouvez utiliser le format Markdown pour rendre les consignes plus lisibles, à la fois pour les humains et pour le modèle.
  • Si l'agent peut effectuer plusieurs tâches, fournissez-lui une liste de tâches et créez des sections distinctes pour chacune d'elles.
  • Si une tâche comporte plusieurs étapes, fournissez une liste des étapes et des instructions détaillées pour chacune d'elles.
  • Si l'agent peut utiliser des outils, listez-les sous l'attribut tools. La définition de l'outil contient des instructions sur la façon de l'utiliser, mais des instructions détaillées sur le moment où l'utiliser peuvent être ajoutées à l'instruction de l'agent pour améliorer les performances.
  • Pour un système multi-agent, décrivez quand il doit passer la main à l'autre agent.
  • Vous pouvez inclure des exemples d'entrée et de sortie attendue dans l'instruction. Vous pouvez également utiliser l'attribut examples pour fournir des exemples.
  • Soyez précis et détaillé dans vos instructions. Traitez l'agent comme un nouvel employé en cours de formation.
  • Ne vous fiez pas à des instructions sur des règles qui doivent être suivies à 100 %. Le modèle possède intrinsèquement un certain degré de liberté et peut commettre des erreurs. Aidez-vous d'outils et de rappels pour appliquer des règles strictes.

description

  description: str

Décrit ce que cet agent peut faire. Cette description est envoyée au modèle dans le cadre des instructions du système afin que:

1. L'agent lui-même comprend ses propres capacités en fonction de la description.

2. Un agent comprend ce que les autres agents peuvent faire et décide de transférer la demande en fonction de leurs descriptions.

global_instruction

  global_instruction: str | InstructionProvider

Instruction globale pour l'ensemble de l'arborescence des agents.

Alors que l'instruction indique à un agent particulier ce qu'il doit faire et comment le faire, l'instruction globale s'applique à tous les agents de l'ensemble de l'arborescence des agents.

L'utilisation de l'instruction globale est semblable à celle de l'attribut d'instruction, y compris le type de données, la prise en charge d'InstructionProvider et la possibilité d'accéder aux variables d'état et aux artefacts.

• Identification et comportement
  • Vous utilisez une instruction globale pour définir l'identité et le comportement/la norme pour l'ensemble de l'arborescence des agents, plutôt que pour savoir comment effectuer une tâche spécifique pour un agent particulier.

generate_content_config

  generate_content_config: google.genai.types.GenerateContentConfig

Configuration supplémentaire du modèle pour l'agent. Ils seront fusionnés dans la requête envoyée au modèle.

Vous ne devez pas définir certains attributs dans ce champ, car ils sont gérés par le framework: - tools - system_instruction - response_schema

examples

  examples: list[Example] | BaseExampleProvider

Exemples few-shot pour l'agent. Des études montrent que fournir des exemples à quelques reprises peut améliorer les performances de l'agent.

• Exemples statiques
  • Vous pouvez fournir une liste d'exemples statiques. Un exemple est défini comme suit, où input est le contenu d'entrée et output est le contenu de sortie attendu.

class Example(BaseModel):
  input: types.Content
  output: list[types.Content]

• Liste de sortie

  • La sortie peut être une liste de Content.
  • Vous pouvez donc définir une séquence de contenus comme sortie attendue. Par exemple, le modèle doit d'abord effectuer un appel de fonction, puis générer du texte.

• BaseExampleProvider

  • Vous pouvez également fournir une instance de la classe BaseExampleProvider.
  • La classe BaseExampleProvider comporte une méthode get_examples(query: str) et renvoie une liste de Example.
  • Avec BaseExampleProvider, vous pouvez générer dynamiquement des exemples en fonction de la requête.

greeting_prompt

  greeting_prompt: str

Vous pouvez définir une invite qui sera envoyée au modèle pour générer un message d'accueil. L'invite d'accueil est utilisée lorsque vous appelez l'agent avec une session vide et une entrée utilisateur vide.

planification

  planning: bool

Si vous définissez planning sur "True", le mode de planification est activé pour l'agent. En mode planification, l'agent génère d'abord un plan pour répondre à la requête de l'utilisateur, puis exécute le plan étape par étape.

code_executor

  code_executor: BaseCodeExecutor

L'agent que vous avez créé peut résoudre des problèmes en écrivant du code et en l'exécutant.

Il existe deux façons d'activer l'exécution du code:

1. Certains modèles peuvent exécuter du code directement. Par exemple, le modèle Gemini 2.0 en mode en direct génère et exécute automatiquement du code, sans avoir besoin d'un outil d'exécution de code distinct.

2. Vous pouvez définir l'attribut code_executor sur une instance de la classe BaseCodeExecutor pour activer l'exécution du code. Actuellement, nous proposons une classe VertexCodeExecutor et UnsafeLocalCodeExecutor (étant donné que les codes générés par le LLM peuvent être dévastateurs, n'utilisez UnsafeLocalCodeExecutor que pour le prototypage) que vous pouvez utiliser pour exécuter du code sur Vertex AI. D'autres exécuteurs de code seront ajoutés à l'avenir.

input_schema

  input_schema: type[BaseModel]

L'agent appliquera le schéma d'entrée lorsque vous spécifierez un modèle Pydantic en tant que input_schema. Le contenu de l'entrée doit être une chaîne JSON conforme au schéma.

output_schema

  output_schema: type[BaseModel]

L'agent appliquera le schéma de sortie lorsque vous spécifierez un modèle Pydantic en tant que output_schema. Le contenu de la sortie sera toujours une chaîne JSON conforme au schéma.

output_key

  output_key: str

L'agent stockera sa sortie dans la variable d'état sous le nom spécifié par l'attribut output_key.

include_contents

  include_contents: Literal['default', 'none']

Par défaut, l'agent inclut le contenu de l'historique de la session (historique des discussions). Vous pouvez définir l'attribut include_contents sur none pour désactiver ce comportement. Dans ce cas, l'agent spécifique ne verra pas l'historique des discussions. Cette option est utile lorsque l'agent n'a pas besoin de connaître l'historique de chat.

Outils

La possibilité d'utiliser des outils distingue les agents du modèle. Tout comme la capacité à utiliser des outils de manière complexe et polyvalente est considérée comme une caractéristique déterminante de l'être humain.

Dans le framework de l'agent, vous fournissez des outils à votre agent via l'attribut tools. L'attribut tools est une liste d'outils, chacun pouvant être:

• Une fonction Python.
• Classe qui implémente la classe BaseTool.

Outil de fonction Python

Vous pouvez définir une fonction Python comme un outil.

• Paramètres

  • Votre fonction peut avoir un nombre illimité de paramètres.
  • Chaque paramètre peut être de n'importe quel type, à condition que le type soit sérialisable en JSON.
  • Ne définissez pas de valeur par défaut pour vos paramètres, car ils ne sont pas acceptés par le modèle.

• Type renvoyé

  • Le type de retour doit être un dictionnaire.
  • Si vous renvoyez un élément autre qu'un dictionnaire, le framework l'encapsule dans un dictionnaire avec une seule clé result.
  • Essayez d'être descriptif dans votre valeur renvoyée. Par exemple, au lieu de renvoyer un code d'erreur numérique, renvoyez un error_message: str avec un message d'erreur lisible. N'oubliez pas que cette valeur de retour est destinée à être lue et comprise par le modèle, et non à être exécutée par un code.
  • Il est recommandé d'utiliser une clé status pour indiquer success, error, pending, etc. afin que le modèle comprenne l'état général de l'opération.

• Chaîne de documentation

  • La docstring de la fonction sera utilisée comme description de l'outil et envoyée au modèle. Plus la docstring est complète, plus le modèle peut utiliser l'outil.

• Simplicité

  • Bien que vous disposiez d'une grande liberté pour définir votre fonction, vous devez la garder simple et facile à utiliser pour que le modèle puisse l'utiliser plus précisément.
  • Il est préférable d'avoir moins de paramètres que d'en avoir beaucoup.
  • Utilisez autant que possible des types de données simples, par exemple str, int, plutôt que des classes personnalisées.
  • Le nom de la fonction et les paramètres sont très importants. Si vous avez une fonction appelée do_stuff(), même si vous indiquez au modèle qu'elle sert à annuler un vol, il peut toujours refuser de l'utiliser.
  • Séparez les fonctions complexes en fonctions plus petites. Par exemple, séparez update_profile(profile: Profile) en update_name(name: str), update_age(age: int), etc.

• Référence dans l'instruction

  • Vous pouvez faire référence à l'outil dans l'instruction en utilisant son nom.
  • Si le nom et la docstring de la fonction sont suffisamment détaillés, vous pouvez vous concentrer uniquement sur le moment où utiliser l'outil dans l'instruction.
  • Indiquez à l'agent comment gérer les différentes valeurs renvoyées. Par exemple, si l'outil renvoie un message d'erreur, l'agent doit-il abandonner, réessayer ou demander plus d'informations ?
  • Les outils peuvent être utilisés de manière séquentielle, et l'un peut dépendre de la sortie de l'autre. Décrivez la séquence dans l'instruction.

Contexte de l'outil

Dans votre fonction d'outil, vous pouvez ajouter un paramètre spécial tool_context: ToolContext pour obtenir des informations supplémentaires sur le contexte dans lequel l'outil est appelé.

La classe ToolContext se trouve dans le module agents.types et présente les attributs suivants:

• function_call_event_id: str
  • ID de l'événement au cours duquel l'appel d'outil est déclenché.
• function_call_id: str
  • ID de l'appel de fonction.
• state: State
  • Objet semblable à un dictionnaire pour lire et mettre à jour les variables d'état.
• actions: EventActions
  • Actions supplémentaires que l'outil peut effectuer.

La classe EventActions se trouve dans le module agents.events et comporte les attributs suivants pour permettre à l'outil d'effectuer des actions supplémentaires:

• skip_summarization: bool
  • Si elle est définie sur "True", le framework ignore l'étape de résumé pour l'événement où l'outil est appelé.
• transfer_to_agent: str
  • Si défini, le framework transfère l'agent avec le nom spécifié par l'attribut transfer_to_agent.
• escalate: bool
  • Si cette valeur est définie sur "True", l'agent transfère la requête à son agent parent. L'escalade d'un agent enfant dans un LoopFlow signifie la fin de la boucle.

AsyncFunctionTool

AsyncFunctionTool est une sous-classe de FunctionTool. Il est conçu pour les outils qui prennent beaucoup de temps.

Pour créer un AsyncFunctionTool, vous devez définir une fonction Python standard et l'encapsuler dans la classe AsyncFunctionTool. Par exemple : AsyncFunctionTool(func=your_function)

AsyncFunctionTool appellera toujours votre fonction Python, où vous pourrez lancer la tâche qui peut prendre beaucoup de temps. Vous pouvez renvoyer un résultat intermédiaire au modèle pour lui indiquer que la tâche n'est pas encore terminée. Ajouter des informations telles que status: 'pending', progress: 20, estimated_completion_time: '...', etc. aidera le modèle à fournir une réponse pertinente à l'utilisateur.

Plus tard, lorsque l'opération sera terminée, vous pourrez appeler l'agent avec une nouvelle fonction Response pour lui fournir le résultat final. À ce moment-là, l'agent générera une réponse finale à l'utilisateur.

AgentTool

AgentTool vous permet d'appeler un autre agent pour qu'il effectue une tâche. Cela équivaut à créer une fonction Python, à appeler un autre agent avec les arguments de la fonction et à utiliser la réponse de cet agent comme valeur renvoyée de la fonction.

Un AgentTool est différent d'un agent enfant:

• Lorsque l'agent A appelle l'agent B en tant qu'AgentTool, la réponse de l'agent B est transmise à l'agent A, qui résume la réponse et génère une réponse à l'utilisateur. Les futures entrées utilisateur seront toujours traitées par l'agent A.
• Lorsque l'agent A appelle l'agent B en tant qu'agent enfant, la responsabilité de répondre à l'utilisateur est entièrement transférée à l'agent B. L'agent A ne sera pas dans l'image. Dans ce cas, l'agent B répondra aux futures entrées de l'utilisateur.

Pour utiliser un agent comme outil, vous pouvez utiliser la classe AgentTool pour l'encapsuler. Par exemple : tools=[AgentTool(agent=agent_b)]

AgentTool dispose des attributs suivants pour personnaliser son comportement:

• skip_summarization
  • Si cette valeur est définie sur "True", le framework ignore l'appel du LLM pour résumer la réponse de l'agent de l'outil.

Rappels

Types de rappel

Vous pouvez personnaliser davantage le comportement de l'agent en définissant des rappels. Nous acceptons deux types de rappels:

• Les BeforeCallbacks sont appelés avant que l'agent n'effectue une action. Vous pouvez modifier l'action, l'ignorer ou effectuer d'autres actions.
• Les AfterCallbacks sont appelés une fois que l'agent a effectué une action. Vous pouvez utiliser ce rappel pour modifier le résultat de l'action ou effectuer d'autres actions.

Actions compatibles

Nous avons des BeforeCallbacks et des AfterCallbacks pour les actions suivantes:

• Appeler un agent
• Appel d'un LLM.
• Appel d'un outil.

Liste des rappels

Par conséquent, nous avons les six rappels suivants, qui sont tous des attributs de la classe Agent:

before_agent_callback

def before_agent_callback(invocation_context: InvocationContext) -> Content | None

• Une invocation peut inclure plusieurs appels d'agent. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un Content à partir de ce rappel, l'agent ignorera l'appel actuel et utilisera le Content renvoyé comme réponse.

after_agent_callback

def after_agent_callback(invocation_context: InvocationContext) -> Content | None

• Une invocation peut inclure plusieurs appels d'agent. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un Content à partir de ce rappel, l'agent ajoutera le Content renvoyé après sa propre réponse.

before_model_callback

def before_model_callback(
    invocation_context: InvocationContext,
    llm_request: LlmRequest) -> LlmResponse | None

• Un appel d'agent peut inclure plusieurs appels LLM. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un LlmResponse à partir de ce rappel, l'agent utilisera le LlmResponse renvoyé comme réponse et ignorera l'appel du modèle.

before_model_callback

def after_model_callback(
    invocation_context: InvocationContext,
    llm_response: LlmResponse) -> LlmResponse | None

• Un appel d'agent peut inclure plusieurs appels LLM. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un LlmResponse à partir de ce rappel, l'agent utilisera le LlmResponse renvoyé comme réponse, au lieu de la réponse générée par le modèle.

before_tool_callback

def before_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext) -> dict | None

• Un appel de modèle peut inclure plusieurs appels d'outils. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un dict à partir de ce rappel, l'agent utilisera le dict renvoyé comme réponse et ignorera l'appel de l'outil.

after_tool_callback

def after_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext,
    response: dict) -> dict | None

• Un appel de modèle peut inclure plusieurs appels d'outils. Ce rappel peut donc être appelé plusieurs fois.
• Si vous renvoyez un dict à partir de ce rappel, l'agent utilisera le dict renvoyé comme réponse, au lieu de la réponse générée par l'outil.

Sessions

Vous n'avez pas besoin de manipuler directement l'objet de session lorsque vous créez un agent. Le framework gère l'objet de session à votre place. Il est toutefois utile de comprendre en quoi consiste la session et comment elle fonctionne.

Une session dans le framework Agent comporte deux composants principaux:

• Événements: liste d'événements.
• État: objet semblable à un dictionnaire de variables d'état.

Événements

Les événements ne sont qu'une simple liste d'objets d'événement. Vous pouvez considérer cela comme un historique de chat, que ce soit entre un utilisateur et un agent ou entre différents agents. Il n'enregistre pas seulement les mots de l'utilisateur ou du modèle, mais aussi toutes les actions effectuées par l'agent, y compris l'appel d'un outil, la réponse de l'outil, l'appel d'un autre agent, etc.

La liste des événements est une liste en mode "append-only". Vous ne pouvez ajouter que des événements à la liste, mais vous ne pouvez pas en supprimer ni en modifier. Lorsqu'un événement s'est produit, il s'est produit. Il n'y a aucun moyen de le modifier. Nous avons conçu le système de cette manière pour qu'il soit simple et que nous puissions toujours revenir à un moment spécifique pour voir l'instantané exact du système.

État

L'état est un objet semblable à un dictionnaire qui contient toutes les variables d'état. Vous pouvez y accéder depuis les emplacements suivants:

• À partir de l'instruction, vous pouvez utiliser la syntaxe {var} pour insérer la valeur de la variable d'état nommée var.
• À partir des rappels, vous pouvez accéder à la variable d'état via invocation_context.state['key']. Vous pouvez également mettre à jour la variable d'état avec invocation_context.state['key'] = value.
• Dans les outils, vous pouvez accéder à la variable d'état via tool_context.state['key']. Vous pouvez également mettre à jour la variable d'état avec tool_context.state['key'] = value.

L'état est associé à une session spécifique. Il s'agit donc de l'endroit idéal pour stocker les informations utiles dans le contexte de cette session.

Tous les agents de l'arborescence des agents peuvent accéder à l'état, ce qui en fait un emplacement idéal pour communiquer entre eux. Un agent peut effectuer une action et stocker son résultat dans l'état. Un autre agent peut ensuite lire le résultat de l'état et poursuivre le travail.

Artefacts

Lorsque le modèle ou votre outil crée un fichier, qu'il s'agisse d'une image, d'une vidéo, d'un document ou de tout autre format, vous pouvez les stocker en tant qu'artefact. Un artefact est un fichier associé à une session particulière, auquel les agents ou votre propre code peuvent accéder.

Cas d'utilisation

• Lorsque votre agent travaille avec l'utilisateur pour créer / modifier un fichier. Par exemple, un agent qui aide l'utilisateur à générer et à modifier une image.
• Lorsque vous souhaitez que l'agent réponde à des questions sur un fichier ou le modifie en fonction des instructions de l'utilisateur.

Avantages en termes de performances

Une autre façon de gérer les fichiers volumineux consiste à les stocker en octets dans l'historique des discussions. Toutefois, cette approche présente quelques inconvénients:

• Cela ralentit l'historique des sessions.
• Il est difficile de récupérer le fichier dans l'historique des discussions.
• Les octets seront envoyés au modèle pour toutes les requêtes, même si la conversation n'a rien à voir avec ces fichiers.

Accéder aux artefacts

Vous pouvez accéder aux artefacts de plusieurs manières:

• Dans l'instruction, vous pouvez utiliser la syntaxe {artifact.var} pour insérer le contenu textuel de l'artefact nommé var. Les artefacts binaires ne sont pas encore acceptés.
• Dans les rappels, vous pouvez accéder à l'artefact via invocation_context.get_artifact('key'). Vous pouvez mettre à jour l'artefact en utilisant invocation_context.set_artifact('key', value).
• Dans les outils, vous pouvez accéder à l'artefact par tool_context.get_artifact('key'). Vous pouvez mettre à jour l'artefact en utilisant tool_context.set_artifact('key', value).

Systèmes multi-agents

Un seul agent et des outils de liste peuvent contribuer grandement à la création d'un système complexe. Toutefois, parfois, séparer la logique en plusieurs agents peut améliorer les performances et la facilité de maintenance du système global.

Voici les cas où vous pouvez envisager d'utiliser plusieurs agents:

• Lorsque l'instruction de l'agent devient trop longue, avec plusieurs tâches et étapes pour chaque tâche.
• Lorsque vous devez exécuter un workflow plus déterministe. Par exemple, pour un agent de recherche, il génère toujours un plan, puis l'exécute, puis résume les résultats.

Arbre des agents hiérarchique

  children: list[BaseAgent]

Vous créez un système multi-agent en créant un arbre d'agents hiérarchique. L'agent racine est le point d'entrée du système et peut appeler d'autres agents en fonction de sa configuration.

Un agent peut avoir plusieurs agents enfants. Les agents enfants peuvent également avoir leurs propres agents enfants. L'arborescence des agents peut être arbitrairement profonde, mais pour des raisons de performances, nous vous recommandons d'utiliser une arborescence moins profonde.

Pour former l'arborescence des agents, vous devez définir d'autres agents comme enfants d'un agent parent.

Flux

  flow: str | BaseFlow | FlowCallable

Lorsqu'un agent reçoit une requête d'utilisateur, il peut choisir de la traiter lui-même ou de la transmettre à un autre agent. Cela est défini par son attribut flow.

Il existe quelques flux prédéfinis, mais vous pouvez également définir vos propres flux.

• sequential: l'agent appelle ses agents enfants un par un dans l'ordre.
• loop: l'agent appelle ses agents enfants dans une boucle. Jusqu'à ce que l'un des agents enfants définisse tool_context.actions.escalate sur "True".
• single: il s'agit d'un flux basé sur un LLM. L'agent appelle le LLM pour répondre à la requête de l'utilisateur et appelle ses outils si nécessaire.
• auto: il s'agit d'un flux basé sur un LLM. L'agent appelle le LLM pour répondre à la requête de l'utilisateur et appelle ses outils si nécessaire. Il peut également transférer la requête à ses enfants, à ses frères et sœurs ou à son parent.
• Flux personnalisés: vous pouvez définir vos propres flux en implémentant la classe BaseFlow ou simplement en définissant une fonction Python conformément à l'interface.