Agents expliqués : outils, prompts système et boucle pensée-action

Les agents d’IA modernes reposent sur un petit nombre d’idées fondamentales : des outils, une instruction système, ainsi qu’un cycle répétitif de réflexion, d’action et d’observation. Une fois ces éléments mis en place, la plupart des frameworks d’agents ressemblent à des variations d’un même thème. Les sections suivantes décrivent ce concept en partant de zéro, en commençant par la définition exacte d’un agent.

Qu’est-ce qu’un agent ?

Un agent est un système dans lequel un modèle d’IA travaille avec son environnement pour accomplir une tâche spécifique. Il combine raisonnement, planification et exécution d’actions, généralement à l’aide d’outils externes. La plupart des agents sont pilotés par un LLM, bien qu’un modèle de vision et de langage puisse remplir la même fonction.

Votre application de chat oublie tout

Voici un fait qui surprend de nombreuses personnes : lorsque vous discutez avec ChatGPT ou un assistant similaire, il n’existe aucune conversation à l’intérieur du modèle. Celui-ci ne stocke rien, ne suit aucun état en cours et ne conserve rien entre vos messages. Chaque fois que vous appuyez sur envoyer, tout l’échange jusqu’à présent est rassemblé en un long bloc de texte, que le modèle lit depuis le début.

Imaginez cet échange :

conversation = [
    {"role": "user", "content": "I need help with my order"},
    {"role": "assistant", "content": "Could you provide your order number?"},
    {"role": "user", "content": "It's ORDER-123"},
]

On voit une liste ordonnée des tours avec leurs rôles, c’est ce que les développeurs gèrent dans le code. Cependant, le modèle ne reçoit jamais de telle liste. Avant que quoi que ce soit n’arrive jusqu’à lui, les tours sont aplatis et combinés en une seule séquence de texte, et sa seule tâche, comme toujours, est de prédire le prochain token en fonction de tout ce qui a précédé.

Aucune étape spéciale de « mémorisation » n’existe. Lorsque le modèle semble se souvenir du numéro de commande, ce n’est pas de la mémoire. Ce numéro se trouve simplement encore dans le texte qu’il lit à ce moment-là.

Outils

Un outil est une fonction, de préférence ayant un but clair, qui est transmise au LLM. Parmi les exemples typiques on trouve :

• la recherche sur le web
• la génération d’images
• la récupération de documents
• l’appel à une API

Un bon outil élargit les capacités du modèle. Il doit comporter ces éléments :

• une description textuelle de ce que fait la fonction

une fonction appelable, c’est-à-dire le code qui exécute l’action

des arguments de type défini

éventuellement, une sortie de type défini

Comment un outil est réellement appelé

Le point clé est qu’un LLM ne peut pas utiliser directement d’outil externe. Le texte entre et le texte sort, rien de plus. Dire qu’un modèle « a accès à des outils » signifie en réalité qu’il a appris à écrire une requête d’appel d’outil sous forme de texte. Si l’on demande des informations météorologiques à Paris, le modèle ne récupère pas de prévision ; il émet plutôt un message structuré indiquant que l’outil météo doit être exécuté.

Une couche d’agent se situe entre l’utilisateur et le modèle. Elle détecte ce message, exécute l’outil, collecte le résultat et l’ajoute à la conversation avant de renvoyer tout cela au modèle. Grâce à ce contexte supplémentaire, le modèle rédige une réponse normale. L’utilisateur a l’impression que le modèle a directement accédé au service météo, alors qu’en réalité c’est l’agent qui a géré toute l’orchestration en coulisses.

Un petit exemple

Pour illustrer, prenons un outil de calculateur qui ne fait qu’une seule chose : multiplier deux entiers :

def multiply(a:int, b:int):
  "Multiply two integers"
  return a * b

Transformer une fonction en outil

La bibliothèque Hugging Face transformers propose un décorateur @tool qui enrobe une fonction Python ordinaire afin qu’un agent puisse la comprendre. Tout d’abord, il faut l’importer :

from transformers import tool

Ensuite, la fonction décorée :

@tool
def multiply(a: int, b: int):
    """Multiply two integers."""
    return a * b

Dans l’ombre, le décorateur collecte des métadonnées :

• le nom de la fonction
• sa description
• les noms des arguments
• les types d’arguments
• le type de retour

Ces métadonnées sont ensuite intégrées dans l’instruction, qui indique au modèle comment utiliser correctement l’outil.

Examen d’un outil

Après décoration, un outil peut se décrire lui-même par du texte :

print(multiply.to_string())

La sortie imprimée contient des détails de ce type :

Tool Name: multiply

Description:
Multiply two integers.Arguments:
- a (int)
- b (int)

Cette description structurée est précisément ce que l’agent montre au modèle. Le LLM la lit comme n’importe quel autre texte et décide si l’outil pourrait aider à répondre à la demande de l’utilisateur.

Le flux de travail de l’agent

Un agent fonctionne dans un cycle répétitif : il réfléchit (Thought), agit (Action) puis observe (Observation).

1. Thought. La partie LLM de l’agent décide de ce qu’il faut faire ensuite.
2. Action. L’agent appelle les outils avec les arguments choisis.
3. Observation. Le modèle prend en compte ce que l’outil a retourné.

L’agent reste dans ce cycle de réflexion, d’action et d’observation jusqu’à ce que son objectif soit atteint.

Le prompt système

Un prompt système est un ensemble d’instructions transmises à un modèle avant toute message de l’utilisateur. Il définit le comportement, le rôle, les contraintes et les objectifs de toute la conversation.

Lorsqu’un utilisateur écrit quelque chose, le modèle voit plus que ce texte uniquement. Il reçoit généralement quelque chose ayant cette forme :

<System Prompt>

You are a helpful programming assistant.
Always explain concepts before showing code.
If the user asks for unsafe code, refuse politely.

<User>

Explain binary search.

L’instruction système a la priorité sur l’instruction de l’utilisateur. Supposons qu’elle indique de toujours répondre en anglais, tandis que l’utilisateur demande une réponse en français. Le modèle privilégiera généralement l’instruction système, sauf si l’application permet délibérément aux demandes de l’utilisateur de la surmonter.

L’instruction système d’un agent va plus loin en décrivant les outils ainsi que le cycle lui-même :

You are an AI assistant that can answer user questions.

You have access to the following tools:

Tool: search_web
Description:
Searches the web for up-to-date information.

Arguments:
- query (string)

Tool: calculator
Description:
Evaluates mathematical expressions.

Arguments:
- expression (string)

If a user's question requires current information, use search_web.
If a calculation is required, use calculator.
Otherwise, answer directly.

Trois éléments sont définis dans ce message système :

• la manière dont l’agent doit se comporter
• les outils qu’il peut utiliser, décrits comme indiqué dans la section précédente
• le cycle Pensée, Action, Observation, intégré aux instructions du modèle

Chacune de ces trois étapes mérite une attention plus approfondie.

Pensées

Les pensées capturent le raisonnement et la planification internes de l’agent au fur et à mesure qu’il travaille sur une tâche. Deux styles courants existent :

1. chain-of-thought (CoT)
2. ReAct (raisonnement suivi d’action)

Chain-of-thought est une méthode de prompting qui incite un modèle à résoudre un problème étape par étape avant de donner une réponse finale. Le raisonnement reste interne, ce qui convient aux problèmes de logique et de mathématiques ne nécessitant pas d’outils externes.

ReAct est une méthode qui exige également une réflexion étape par étape, mais mêle des actions, telles que des appels d’outils, entre les étapes de raisonnement.

Ces deux approches permettent à un LLM de résoudre progressivement des problèmes. La différence réside dans le fait que CoT ne dépend que de ce que le modèle sait déjà, tandis que ReAct associe le raisonnement à des actions. Cela permet au modèle d’utiliser des outils externes, de collecter de nouvelles informations et de s’appuyer sur les résultats pour continuer à raisonner, ce qui le rend plus adapté aux tâches dynamiques du monde réel impliquant des systèmes externes.

Actions : du raisonnement à l’action

Les actions sont les étapes que prend un agent pour interagir avec son environnement. Un agent de service clientèle peut par exemple consulter les données des clients, suggérer des articles d’aide ou transférer un cas à un humain.

Un générateur de texte parvient à déclencher des outils réels grâce à un schéma simple appelé « stop and parse ». Le modèle ne fait jamais rien par lui-même : il génère une demande structurée décrivant ce qui doit se produire, et l’agent l’exécute au nom du modèle.

En réalité, il s’agit du même cycle que précédemment. Le modèle réfléchit à la tâche, génère une action telle qu’une requête vers une API météo, puis s’arrête. L’agent détecte cette action, exécute l’outil correspondant et renvoie le résultat sous forme d’observation. Ayant obtenu cette information, le modèle continue de réfléchir, entreprend une autre action ou fournit la réponse finale.

Historiquement, les actions étaient exprimées sous forme d’appels de fonction ou d’objets JSON indiquant un outil et ses arguments. Cette méthode fonctionne, mais devient peu pratique lorsque un flux de travail nécessite de nombreux appels d’outils. Les agents de code empruntent une autre approche : au lieu de décrire les actions en JSON, le modèle écrit du Python exécutable. Les boucles, les conditions, les variables ainsi que plusieurs appels d’outils peuvent alors partager un même bloc de code, ce qui est plus expressif et plus efficace pour des tâches complexes.

La forme JSON traditionnelle ressemble à ceci :

{
  "tool": "get_weather",
  "arguments": {"location": "Tokyo"}
}

Un développeur écrit plutôt un extrait exécutable :

# The agent writes actual Python code as its action
cities = ["Tokyo", "Paris", "New York", "London", "Sydney"]
temps = [get_weather(city) for city in cities]
avg_temp = sum(temps) / len(temps)
print(f"Average temperature: {avg_temp}")

Observations : retour d’information sur chaque action

Le raisonnement et l’action ne représentent que la moitié de l’histoire. Après avoir agi, un agent doit comprendre le résultat, et c’est là que interviennent les observations : le retour reçu une fois qu’une action a été exécutée. Il peut s’agir d’un résultat de recherche sur le web, d’une réponse API, du résultat d’un programme Python ou même d’un message d’erreur. Quoi qu’il en soit, cela devient une nouvelle information pour choisir la prochaine étape.

Le flux est simple. L’agent génère une action, le framework l’exécute, et la sortie est ajoutée à la conversation en tant qu’observation. Le LLM lit le contexte mis à jour et continue. Avec suffisamment d’informations, il fournit la réponse finale. Sinon, il planifie une autre action.

Les observations n’ont pas nécessairement à être des succès. Lorsqu’une requête échoue, que ce soit en raison d’un code 404 Not Found émis par un point de terminaison ou d’un en Python dans le code généré, cet échec reste utile. Le message d’erreur indique à l’agent ce qui a mal tourné, lui permettant ainsi d’agir correctement à la prochaine occasion au lieu de répéter la même erreur.

Cet ensemble de boucles continues est ce qui rend les agents adaptatifs. Au lieu de ne compter que sur des connaissances préenregistrées, ils collectent de nouvelles informations, apprennent à partir des résultats et affinent leur approche jusqu’à ce que la tâche soit accomplie.

Assembler les éléments

Les agents peuvent sembler représenter un paradigme entièrement nouveau, mais ils résultent de la combinaison de quelques idées simples. Un modèle de langage réfléchit à un problème, une instruction système influence son comportement, des outils l’étendent au-delà du texte, des actions le relient au monde extérieur et les observations fournissent des retours d’information lui permettant de s’adapter.

Comprendre ces éléments de base et réaliser à quel point chacun d’eux contient peu de « magie » constitue la première étape pour créer ses propres agents. Les assistants de codage, les copilotes de recherche et les flux de travail autonomes reposent tous sur le même cycle Pensée, Action, Observation. La prochaine étape logique est alors d’implémenter un premier agent à l’aide de l’écosystème Hugging Face.