Agent IA

Vous êtes peut-être habitué à ce type d'interaction : vous posez une question et l'IA donne une réponse.

• Vous lui demandez d'écrire un article, et il écrit un article.

• Vous lui demandez de traduire une phrase, et il traduit une phrase.

Dans ce mode, l'IA ressemble davantage à un consultant — elle vous donne des conseils, mais n'agit pas directement.

Mais que se passe-t-il si la tâche est légèrement plus complexe ? Par exemple : aidez-moi à vérifier la météo de demain à Pékin. Si la température dépasse 25 degrés, recommandez une chemise à manches courtes dans un budget de 300 yuan, puis rassemblez les résultats dans un e-mail et envoyez-le à mon chef.

Avec une IA conversationnelle ordinaire, vous devez la décomposer en plusieurs étapes :

• Étape 1 : Vérifiez la météo de demain à Pékin.

• Étape 2 : Si elle dépasse 25 degrés, recommandez une chemise à manches courtes dans la limite de 300 yuan.

• Étape 3 : Écrire un e-mail à mon patron avec le contenu ...

Chaque étape vous oblige à avancer manuellement.

etAgent IAL'idée est : vous dites simplement « aidez-moi à faire ceci » une fois, et il s'occupera tout seul du reste.

Il déterminera automatiquement ce qui doit être fait, quels outils appeler, dans quel ordre les exécuter, et comment s'adapter lorsque des problèmes surviennent, jusqu'à ce que la tâche soit terminée.

Compréhension simple : un LLM classique est un stratège qui vous donne des conseils ; un agent IA est un exécutant qui prend l'objectif et va accomplir les choses par lui-même.

Qu'est-ce qu'un agent IA ?

Un agent IA est un système autonome qui peut percevoir son environnement, prendre des décisions et entreprendre des actions.

Une définition plus académique est :Un Agent est une entité située dans un environnement ; il perçoit l'environnement au moyen de capteurs et agit sur l'environnement au moyen d'actionneurs afin d'atteindre un ensemble d'objectifs.。

Cette définition semble un peu abstraite, alors décomposons-la en langage simple.

Agent vs. LLM classique

Tout d'abord, jetez un œil à un tableau comparatif :

Prenons un exemple concret : « Aide-moi à réserver un vol de Shanghai à Pékin demain, à un prix inférieur à 1,500 yuan. »

Un LLM classique pourrait répondre : « D'accord, je peux t'écrire un extrait de code pour interroger les prix des vols, ou te dire quel site web consulter. » Mais il ne va pas réellement rechercher des vols, encore moins t'en réserver un.

Un Agent qualifié, en revanche, fera ce qui suit :

• 1. Comprendre l'objectif : Réserver un vol de Shanghai à Pékin demain, pour moins de 1,500 yuan.

• 2. Décider d'une action : Je dois appeler une API de recherche de vols.

• 3. Exécuter l'action : Appeler l'API et obtenir la liste des vols.

• 4. Observer les résultats : 10 vols obtenus, dont 3 à moins de 1,500 yuan.

• 5. Réfléchir à nouveau : Lequel choisir ? Peut-être faut-il vérifier les horaires de départ et d'arrivée, ou demander les préférences de l'utilisateur.

• 6. Continuer d'agir : Peut-être appeler une autre API pour vérifier les taux de ponctualité, ou recommander directement des options à l'utilisateur.

• 7. Terminer la tâche : Aider l'utilisateur à réserver une place et générer un lien de commande.

Voyez-vous la différence ?Un LLM classique vous donne des réponses ; un Agent vous donne des résultats.。

Capacités principales d'un Agent

Un Agent complet possède généralement les trois capacités principales suivantes :

• Perception, signifie que l'Agent peut voir ce qui se passe. Par exemple, un utilisateur envoie un message, une API renvoie un résultat, ou un nouveau fichier est ajouté au système de fichiers—ce sont toutes des entrées de perception.

• Décision, signifie que l'Agent décide quoi faire ensuite en fonction des informations perçues. Doit-il répondre directement à l'utilisateur ? A-t-il besoin d'appeler un outil ? Doit-il décomposer une grande tâche en sous-tâches plus petites ? Ce sont toutes des décisions.

• Action, signifie que l'Agent exécute réellement les décisions. Appeler une API de recherche, lire un fichier, envoyer un e-mail, exploiter une base de données—ce sont toutes des actions.

Architecture de base d'un Agent

Voyons maintenant le « puzzle en quatre pièces » standard de l'Agent : cerveau, outils, mémoire et planification.

Tout d'abord, examinons un diagramme d'architecture :

Cerveau : le LLM en tant que cœur du raisonnement

Le cerveau d'un Agent est généralement un grand modèle de langage, tel que GPT-4, Claude, Llama, etc.

Ce LLM est responsable de :

• 1. Comprendre l'intention de l'utilisateur : lorsque l'utilisateur dit « aide-moi à réserver un billet », que veut-il vraiment ?

• 2. Prendre des décisions : que dois-je faire ensuite ?

• 3. Générer les paramètres d'appel d'outil : quels paramètres sont nécessaires pour appeler une API de recherche de vols ?

• 4. Organiser la réponse finale : maintenant que suffisamment d'informations ont été collectées, comment donner à l'utilisateur un résumé clair ?

Le LLM est le cœur d'un Agent, mais pas tout — tout comme le cerveau humain est important, mais il vous faut quand même des mains et des pieds pour mener les choses à bien.

Outils : étendre les frontières des capacités de l'IA

Les LLM natifs ont deux limites évidentes :

• 1. Limite de connaissances : il ne sait pas ce qui s'est passé après la fin de l'entraînement.

• 2. Aucune capacité d'interaction : il ne peut pas lire directement des fichiers, interroger des bases de données ou appeler des API.

Les outils sont conçus pour résoudre ces problèmes.

Types d'outils courants :

Donner des outils à un agent, c'est comme équiper une personne d'un ordinateur — il passe instantanément du simple fait de pouvoir penser à celui de pouvoir agir.

Mémoire : court terme vs. long terme

Les LLMs sont naturellement amnésiques — chaque conversation repart de zéro, sauf si vous y intégrez le contexte.

Et un agent doit se souvenir de beaucoup de choses :

• Mémoire à court terme : Que vient de dire l'utilisateur ? Quel outil ai-je appelé à l'étape précédente ? Quel résultat ai-je obtenu ?

• Mémoire à long terme : Quelles sont les préférences de l'utilisateur ? Comment des tâches similaires ont-elles été traitées dans le passé ? Quelles leçons ont été tirées ?

Approches d'implémentation courantes pour les systèmes de mémoire :

Un bon système de mémoire peut donner à un Agent l'impression qu'il se souvient de vous, plutôt que d'agir comme s'il vous rencontrait pour la première fois à chaque fois.

Planification : décomposition des tâches

Les tâches complexes ne seront pas accomplies en une seule étape ; un Agent doit pouvoir décomposer un grand objectif en étapes plus petites.

Par exemple : Aidez-moi à planifier une fête d'anniversaire pour 10 personnes.

L'Agent pourrait le planifier ainsi :

• 1. D'abord clarifier : Quel est le budget ? Quand est-ce ? Où est-ce ? Quelles sont les préférences de la personne fêtée ?

• 2. Ensuite : Rechercher des lieux à proximité.

• 3. Puis : Concevoir le menu.

• 4. Ensuite : Faites une liste de courses.

• 5. Enfin : Générez un planning.

Stratégies de planification courantes :

• Chaîne de pensée : Réfléchissez étape par étape — ce qu'il faut faire d'abord, ce qu'il faut faire ensuite.

• Arbre de pensée : Envisagez plusieurs chemins possibles en même temps et choisissez le chemin optimal.

• Réflexion : Après avoir terminé une étape, revenez en arrière et vérifiez s'il y a des problèmes et si des ajustements sont nécessaires.

Utilisation d'outils / Appel de fonctions

L'appel d'outils est la capacité la plus fondamentale et la plus importante d'un Agent.

Commençons par expliquer ce que c'est.

Qu'est-ce que l'appel de fonction ?

En termes simples :L'appel de fonction, c'est lorsque le LLM produit un JSON structuré indiquant quelle fonction il souhaite appeler et quels paramètres transmettre.。

Ce n'est pas que le LLM exécute réellement la fonction — il vous dit simplement qu'il veut l'appeler, et c'est encore à vous de faire l'exécution.

L'ensemble du processus se déroule généralement comme ceci :

• 1. Vous dites au LLM : « Voici quelques fonctions que vous pouvez appeler. Le nom, les paramètres et l'objectif de chaque fonction sont... »

• 2. L'utilisateur envoie un message : « Aidez-moi à vérifier la météo de demain à Pékin. »

• 3. Le LLM répond : « Je veux appeler la fonction get_weather, avec les paramètres city='Beijing', date='tomorrow'. »

• 4. Vous appelez la fonction (en interrogeant réellement l'API météo) et obtenez le résultat.

• 5. Vous renvoyez le résultat au LLM : « L'appel de fonction précédent a renvoyé : température 25 degrés, ensoleillé. »

• 6. D'après ce résultat, le LLM donne à l'utilisateur une réponse en langage naturel : « Pékin sera ensoleillé demain, 25 degrés, très agréable. »

Vous voyez ? C'est le LLM qui réfléchit, et vous qui exécutez.

Définir le schéma JSON d'un outil

Pour que le LLM appelle des outils, vous devez d'abord lui indiquer quels outils sont disponibles.

Ce processus d'indication consiste à décrire les fonctions avec un schéma JSON.

Regardons un format standard de définition de fonction :

Points clés :

• description est très importante — le LLM s'appuie sur cette description pour comprendre ce que fait l'outil et quand l'utiliser.

• Les paramètres doivent aussi être décrits clairement — par exemple, si unit a une contrainte enum, le LLM sait qu'il ne peut choisir que parmi ces deux valeurs.

• required marque les champs obligatoires — le LLM veillera à ce que ces paramètres aient toujours des valeurs.

Code pratique : ajouter des outils de recherche et de calcul à l'IA

Écrivons maintenant un exemple complet et exécutable.

Pour la démonstration, nous utilisons Python pour simuler le flux complet de Function Calling.

Bien que cet exemple soit simple, il démontre la boucle fermée complète de l'appel de fonction :

Comprendre → Décider → Appeler l'outil → Observer le résultat → Générer une réponse.

Dans un projet réel,_decide_actioncette étape serait remplacée par un véritable appel à un LLM, laissant le modèle décider quel outil utiliser et quels paramètres transmettre.

Boucle de planification ReAct

Une fois les capacités d'appel d'outils en place, la question suivante est : quand s'arrêter ?

Les tâches simples peuvent être réalisées en une seule étape, mais les tâches complexes nécessitent souvent plusieurs cycles d'itération.

C'est le problème que le framework ReAct vise à résoudre.

Pensée → Action → Observation

Le nom ReAct vient de la combinaison du raisonnement et de l'action.

Son idée centrale est simple : laisser l'Agent, comme un humain, penser une étape, agir une étape, observer, puis répéter cette boucle jusqu'à ce que la tâche soit terminée.

Regardons un organigramme :

Chaque cycle se compose de trois étapes :

Revenez ensuite à Pensée — en fonction des résultats observés, décidez quoi faire ensuite.

Cette boucle continue jusqu'à ce que l'Agent détermine que la tâche est terminée, auquel cas il quitte la boucle et fournit la réponse finale.

Utilisons un exemple concret pour voir comment ReAct fonctionne :

• Question de l'utilisateur: En quelle année SpaceX a-t-elle été fondée ? Quel était le nom de sa première fusée à avoir réussi à atteindre l'orbite ?

• Pensée 1: Je dois trouver l'année de fondation de SpaceX et le modèle de sa première fusée à avoir réussi un lancement orbital. Ces informations peuvent provenir de sources différentes, il est donc préférable d'effectuer une recherche avec des mots-clés couvrant les deux à la fois.

• Action 1: Appeler web_search pour interroger "date de fondation de SpaceX première fusée orbitale".

• Observation 1: Le résumé des résultats de recherche indique : "SpaceX (Space Exploration Technologies Corp.) a été fondée en 2002 par Elon Musk. Sa première fusée à entrer avec succès en orbite terrestre a été Falcon 1, qui a réussi lors de son quatrième vol d'essai le 28 septembre 2008." (L'information est complète et couvre les deux sous-questions.)

• Pensée 2: Les résultats de recherche fournissent déjà à la fois l'année de fondation (2002) et la première fusée orbitale (Falcon 1). Il n'y a pas d'ambiguïté et l'information est crédible. Aucune recherche supplémentaire n'est nécessaire.

• Réponse finale: SpaceX a été fondée en 2002, et sa première fusée à atteindre avec succès l'orbite a été Falcon 1, qui a atteint ce jalon le 28 septembre 2008.

• Remarque: Vous voyez ? Chaque étape comporte clairement une "Pensée", une "Action" et une "Observation", et l'Agent juge par lui-même quand s'arrêter — ici, il n'a fallu qu'un seul tour d'action pour recueillir toutes les informations nécessaires, donc il est passé directement à la réponse finale sans boucles supplémentaires.

Conditions d'arrêt de la boucle

La boucle ReAct ne peut pas fonctionner indéfiniment ; elle a besoin d'une condition d'arrêt.

Conditions de terminaison courantes :

Lors de la conception d'un Agent, veillez à prévoir une soupape de sécurité « nombre maximal d'étapes » — sinon, il risque de tourner en rond et de ne jamais s'arrêter.

Conception du système de mémoire

Lorsqu'un agent travaille longtemps, il rencontre un problème : la fenêtre de contexte ne peut pas contenir tout l'historique de conversation.

À ce stade, un bon système de mémoire est nécessaire.

Historique de conversation : mémoire à court terme

La mémoire la plus simple consiste à sauvegarder complètement l'historique de conversation.

À chaque fois, tous les messages précédents sont injectés dans le LLM, afin qu'il puisse se souvenir de ce qui vient de se passer.

Mais cette approche présente un inconvénient évident : la fenêtre de contexte du LLM est limitée.

Par exemple, GPT-4, c'est 8K ou 32K, et Claude, 200K — même si c'est grand, ce n'est toujours pas infini.

Tout va bien quand la conversation est courte, mais dès qu'elle devient très longue, ou que chaque tour d'appels d'outils renvoie beaucoup de contenu, l'espace vient vite à manquer.

Base de données vectorielle : mémoire à long terme

Lorsqu'il y a trop de choses à mémoriser et que le contexte ne peut pas les contenir, une solution courante consiste à :stocker les mémoires dans une base de données vectorielle et « récupérer » celles qui sont pertinentes lorsque c'est nécessaire.。

Cette approche s'appelle RAG (Retrieval-Augmented Generation), et elle s'applique tout autant aux Agents.

Flux de travail :

• Chaque fois qu'une mémoire est générée (ce que l'utilisateur a dit, le résultat renvoyé par l'outil, la réflexion de l'Agent), elle est convertie en un vecteur (Embedding).

• 2. Stocker ce vecteur dans la base de données vectorielle.

• 3. Lorsque l'Agent doit se rappeler, convertir également la question actuelle en un vecteur.

• 4. Rechercher dans la base de données vectorielle les quelques mémoires « les plus similaires ».

• 5. Ne placer que ces quelques mémoires pertinentes dans le contexte du LLM.

Ainsi, même s'il y a dix mille mémoires historiques, seules les plus pertinentes doivent être récupérées et utilisées.

Compression de mémoire par résumés

Un autre schéma d'optimisation de la mémoire :Ne stockez pas les textes complets des conversations ; à la place, un grand modèle génère périodiquement des résumés concis des sessions historiques, et seuls les résumés sont enregistrés de manière persistante.。

Dialogue long d'origine :

• Utilisateur : Aide-moi à vérifier la météo.

• Agent : Quelle ville vérifier ?

• Utilisateur : Pékin.

• Agent : Quel jour ?

• Utilisateur : Demain.

• ……

Résumé compressé :

用户需要查询北京明日天气，Agent 先后确认城市与日期，用户明确查询时间为明天。

Cette approche peut réduire considérablement la surcharge de Token : une conversation complète qui occupait initialement 500 Tokens n'a besoin que d'un résumé de 50 Tokens pour conserver les informations essentielles.

Les projets de production utilisent généralement plusieurs solutions ensemble, en gérant la mémoire de conversation en couches :

• Dialogues les plus récents : entièrement conservés, directement envoyés dans le contexte du modèle ;
• Dialogues historiques éloignés : générer uniformément des résumés, en remplaçant le texte original par des résumés ;
• Informations clés à long terme : stockées dans une base de données vectorielle, récupérées à la demande.

Frameworks d'Agent courants

Après avoir compris les principes, vous pouvez écrire votre propre Agent, ou utiliser des frameworks existants.

Les plus populaires aujourd'hui sont :

Agents LangChain

LangChain est actuellement le framework de développement d'applications LLM le plus populaire, et il intègre un système d'Agent.

Concepts clés :

Agent : le cerveau, décide de ce qu'il faut faire.

Tools : liste d'outils.

Toolkits : suites d'outils (par exemple, regrouper plusieurs outils liés aux bases de données).

AgentExecutor : l'exécuteur, responsable de l'exécution de la boucle ReAct.

L'avantage de LangChain est son écosystème riche — de nombreuses intégrations d'outils prêtes à l'emploi, immédiatement utilisables.

L'inconvénient est qu'il paraît parfois un peu lourd, avec de nombreuses couches d'abstraction, ce qui rend le débogage difficile en cas de problème.

Agents LlamaIndex

LlamaIndex (anciennement appelé GPT Index) se concentre davantage sur la connexion des données — connecter vos données privées (documents, bases de données, APIs) au LLM.

Ses points forts en tant qu'Agent sont :

• 1. Interroger des données structurées et non structurées.

• 2. Effectuer le routage entre plusieurs sources de données.

• 3. Effectuer du question-réponse documentaire (RAG).

Si votre Agent doit travailler intensivement avec "vos données", LlamaIndex est un bon choix.

Principes d'AutoGPT

AutoGPT est un projet devenu populaire au début de 2023, et sa caractéristique est : l'autonomie totale.

Vous lui donnez un objectif ambitieux (par ex., "aidez-moi à créer un site web"), et il va de lui-même :

• 1. Générer une liste de tâches.

• 2. Exécuter les tâches.

• 3. S'auto-évaluer.

• 4. Ajuster le plan.

• 5. Continuer d'avancer.

AutoGPT a permis à de nombreuses personnes de découvrir pour la première fois la puissance des « Agents autonomes », mais il a aussi exposé de nombreux problèmes liés aux Agents :

Il continue souvent à avancer dans la mauvaise direction sans couper les pertes à temps.

Il est enclin à tomber dans des boucles infinies et à répéter les mêmes actions.

Coût élevé — une exécution peut dépenser des dizaines de dollars en frais d'API.

Mais AutoGPT est très instructif en tant que preuve de concept.

CrewAI multi-agents

Ce dont nous venons de parler concerne des Agents uniques, tandis que l'approche de CrewAI consiste à : laisser plusieurs Agents former une équipe et collaborer.

Par exemple, vous pouvez définir :

Agent Product Manager : responsable de la compréhension des besoins et de la rédaction des PRD.

Agent Ingénieur : responsable de l'écriture du code.

Agent Réviseur : responsable de la revue de code et de fournir des retours.

Ensuite, laissez-les collaborer comme une vraie équipe — discuter entre eux, attribuer des tâches et fournir des résultats.

Le multi-agent est une direction très prometteuse : un seul Agent peut faire des erreurs, mais plusieurs Agents peuvent se corriger mutuellement et se compléter.

Pratique : Construire un Agent automatisé de collecte d'informations

Maintenant, rassemblons les points de connaissance précédents et écrivons un Agent vraiment utilisable.

L'Agent que nous allons créer s'appelleexample-researcher— donnez-lui un sujet, et il recherchera, organisera et générera automatiquement un rapport de recherche.

Bien que cet Agent simplifie les appels au LLM (simulés avec des règles), l'ensemble du flux de travail est véritablement utilisable.

Il vous suffit de_thinkremplacer la méthode par de véritables appels à l'API LLM, et_search_webremplacez-le par une véritable API de recherche, et il pourra vraiment vous aider à faire de la recherche.

Limites et modes de défaillance des agents

Les agents IA sont puissants, mais ils ne sont pas omnipotents.

Comprendre ses limites vous aide à l'utiliser dans les bons scénarios et à éviter les pièges.

Modes de défaillance courants

1. Sélection d'outil incorrecte

Lorsqu'un utilisateur pose une question sur la météo, l'agent fait appel à une recherche ; lorsqu'un utilisateur veut effectuer une recherche, l'agent fait appel à une calculatrice.

Ce type d'erreur est très courant, surtout lorsque les définitions d'outils ne sont pas assez claires.

2. Erreurs de passage de paramètres

Mauvais format de date, paramètres obligatoires manquants, types de paramètres incorrects — tout cela peut faire échouer les appels d'outils.

3. Boucle infinie

L'agent se retrouve bloqué dans une boucle infinie de « rechercher A → introuvable → rechercher A à nouveau → toujours introuvable → rechercher A encore une fois… »

4. Arrêt prématuré

Avant d'avoir collecté suffisamment d'informations, l'Agent décide que c'est « assez » et donne une réponse incomplète.

5. Hallucination

L'Agent peut fabriquer des outils qui n'existent pas, des paramètres qui n'existent pas, ou inventer de faux résultats de recherche.

6. Manque de bon sens

Parfois, l'Agent fait des choses qui semblent stupides aux humains — par exemple, lorsqu'un utilisateur dit « réserve-moi un vol pour demain », l'Agent cherche ce qu'est « demain », alors qu'il devrait en réalité utiliser la date d'aujourd'hui plus un jour.

Comment rendre les Agents plus fiables

Pour résoudre ces problèmes, l'industrie dispose de quelques stratégies d'atténuation couramment utilisées :

Une suggestion pratique : ne visez pas l'autonomie complète dès le départ. Commencez par un mode human-in-the-loop — l'agent propose quoi faire, et un humain confirme avant l'exécution. Une fois que vous avez confiance, déléguez progressivement plus d'autorité.