Lagent : construire des agents LLM comme on empile des couches PyTorch

Le problème visé : écrire un agent sans écrire un orchestrateur

Le README énonce l'intention sans détour : Lagent s'inspire de la philosophie de conception de PyTorch, avec l'idée que l'analogie des couches de réseau de neurones rend le flux de travail plus lisible. L'utilisateur, dit le texte, n'a qu'à créer des couches et à définir le passage de messages entre elles, en Python. Le public visé est donc l'ingénieur qui veut un agent sans adopter un cadre d'orchestration lourd, et qui accepte de composer lui-même ses briques. Le projet est distribué sous Apache-2.0, en Python, avec les thèmes agent, gpt, llm et transformers. Cette promesse a un corollaire : Lagent ne fournit pas de graphe de tâches, de planificateur ni de registre d'outils déclaratif. Si votre besoin est un enchaînement de plusieurs agents avec reprise sur erreur et journalisation centralisée, vous devrez l'écrire au-dessus. C'est un choix de conception assumé, pas un manque documenté comme tel.

AgentMessage et la mémoire : le mécanisme réel du tour de boucle

L'unité d'échange est AgentMessage, avec les champs content, sender, formatted, extra_info, type, receiver et stream_state. Le README montre que la mémoire est mise à jour dans __call__ et non dans forward. Le pseudo-code publié est explicite : pre_hooks, puis add_memory des messages entrants, puis self.forward, puis add_memory de la sortie, puis post_hooks. Conséquence pratique : un hook posé avant l'appel voit l'historique sans le message courant, un hook posé après voit les deux. La mémoire s'inspecte de deux façons, agent.memory.get_memory() qui renvoie une liste d'AgentMessage, et agent.state_dict() qui renvoie un dictionnaire dont la clé memory contient des dictionnaires simples, donc sérialisables. La session par défaut porte l'identifiant 0, et agent.reset() vide la mémoire de cette session. Le champ stream_state utilise l'énumération AgentStatusCode, avec la valeur END visible dans les exemples. Rien dans le matériel fourni ne décrit le comportement de plusieurs sessions simultanées ni la politique d'éviction quand la mémoire grandit.

DefaultAggregator : le point où la mémoire devient un prompt

Entre la mémoire et le modèle se trouve l'agrégateur. Le README cite l'extrait de forward où self.aggregator.aggregate reçoit la mémoire de la session, self.name, self.output_format et self.template, puis où le résultat part dans self.llm.chat. DefaultAggregator est appelé sous le capot pour assembler et convertir les AgentMessage au format de message OpenAI. C'est l'endroit le plus intéressant du cadre, parce qu'il est sous-classable. L'exemple FewshotAggregator hérite de DefaultAggregator, accepte une liste few_shot, appelle aggregate_system_intruction pour l'instruction système, insère les exemples, puis parcourt la mémoire : un message dont le sender vaut le nom de l'agent devient un rôle assistant, tout le reste devient un rôle user, et deux messages user consécutifs sont fusionnés dans la même entrée. Ce dernier détail compte : sans lui, un historique contenant plusieurs messages utilisateur d'affilée produirait une séquence que beaucoup d'API de chat refusent. La logique de fusion est donc une contrainte de format, pas un détail cosmétique.

Installation et premiers appels : ce que la documentation donne littéralement

L'installation depuis les sources tient en trois commandes : git clone https://github.com/InternLM/lagent.git, cd lagent, pip install -e . . Il existe aussi un paquet PyPI nommé lagent, référencé par le badge du README. Le premier exemple construit un VllmModel avec path='Qwen/Qwen2-7B-Instruct', meta_template=INTERNLM2_META, tp=1, top_k=1, temperature=1.0, stop_words=['<|im_end|>'] et max_new_tokens=1024, puis un Agent(llm, system_prompt) et un appel agent(user_msg). Le résultat imprimé est un AgentMessage avec content='急', sender='Agent' et stream_state=<AgentStatusCode.END: 0>. Notez que meta_template vaut INTERNLM2_META alors que le chemin du modèle pointe vers Qwen2 : le README ne commente pas cet écart, et il faut le traiter comme un exemple à adapter, pas comme une configuration recommandée. Le second exemple remplace l'agrégateur par FewshotAggregator et définit output_format via lagent.prompts.parsers.ToolParser, dont le README ne montre que l'import et la première ligne de la consigne système.

Le formatage des réponses : formatted, ToolParser et la partie tronquée

Le champ formatted d'AgentMessage est réservé à l'information extraite de la sortie du modèle par output_format. L'extrait de forward le confirme : si self.output_format est défini, parse_response est appelé sur la réponse du LLM, et l'AgentMessage est construit avec content égal à la réponse brute et formatted égal au résultat du parseur. Le README amorce un exemple avec ToolParser et la consigne système "逐步分析并编写Python代码解决以下问题。", mais le bloc de code s'arrête là dans le matériel fourni. On ne peut donc pas décrire le format exact attendu par ToolParser, ni la façon dont il signale une sortie non conforme. C'est une lacune de documentation, pas une lacune du code, et elle a un coût direct : pour brancher un outil, il faut lire le source du parseur plutôt que suivre le guide. Si votre agent dépend d'appels d'outils structurés, prévoyez ce détour avant de choisir Lagent.

Ce que Lagent ne fait pas, et à quel prix

Le README insiste sur la légèreté et sur l'analogie PyTorch, mais il ne documente ni la persistance de la mémoire hors processus, ni la concurrence entre sessions, ni la reprise après une erreur du modèle. agent.state_dict() renvoie bien des dictionnaires sérialisables, ce qui rend un stockage externe possible, mais aucune fonction de rechargement n'apparaît dans le matériel fourni. Autre limite visible : le seul exemple d'agent est mono-tour et mono-session, avec session_id=0 par défaut. Rien n'indique comment un serveur gérerait plusieurs utilisateurs en parallèle sur la même instance d'Agent, alors que la mémoire est portée par l'objet agent et indexée par session. Pour une démonstration locale, cela suffit. Pour un service multi-utilisateurs, c'est un point à vérifier dans le code avant de s'engager. Lagent est aussi le mauvais outil si vous cherchez un cadre avec planificateur intégré : ici, la planification est ce que vous écrivez dans forward ou dans un agrégateur personnalisé.

Face à un cadre d'orchestration par graphes

L'alternative la plus directe est un cadre qui décrit l'agent comme un graphe de nœuds et d'arêtes, avec un état partagé typé et des transitions conditionnelles. La différence d'approche est nette. Lagent hérite de PyTorch : une classe Agent, un forward à redéfinir, une mémoire qui s'accumule à chaque __call__, et un agrégateur qui traduit cette mémoire en messages de chat. Un cadre par graphes, lui, sépare la définition du flux de celle du modèle, ce qui rend les boucles et les branchements explicites dans la structure du programme plutôt que dans le corps d'une méthode. Concrètement, avec Lagent, ajouter une étape de vérification après la réponse du modèle signifie sous-classer Agent et modifier forward, en gardant à l'esprit que la mémoire est déjà mise à jour avant et après l'appel. Avec un graphe, cette étape serait un nœud. Aucun des deux n'est meilleur dans l'absolu : le premier demande moins de concepts, le second rend le contrôle du flux inspectable. Lagent reste plus proche du code Python ordinaire, ce qui est exactement l'argument du README.

Maintenance, versions et implications de licence

Le dépôt n'est pas archivé et le dernier push indiqué est le 2026-08-03. Les versions récentes listées sont agentrl_rc0 (2026-05-19), v0.5.0rc3 (2025-03-04) et v0.5.0rc2 (2024-11-29). Deux de ces trois étiquettes sont des release candidates, et la plus récente porte un suffixe rc0 : autrement dit, la branche publiée la plus active n'est pas une version stable au sens strict. Pour un projet qui dépend de Lagent en production, cela implique de figer une version précise plutôt que de suivre main, et de lire les notes de version avant chaque montée. La licence Apache-2.0 autorise l'usage commercial et la modification, avec conservation des mentions de copyright et du fichier de licence, et elle comporte une clause de brevets. Ce paragraphe décrit la licence telle qu'elle est identifiée dans le dépôt ; il ne constitue pas un avis juridique. Le coût de mise à jour tient surtout à l'API d'extension : si vous sous-classez DefaultAggregator ou écrivez un parseur, une évolution de la signature d'aggregate ou de parse_response vous concerne directement.

Conclusion éditoriale

Lagent convient à qui veut un cadre Python minimal, avec une mémoire par session et un point d'extension clair sur l'agrégation des messages, sans adopter une pile d'orchestration complète. Il convient moins si vous attendez une documentation détaillée des cas d'erreur, une gestion multi-utilisateurs robuste ou un écosystème d'outils prêts à l'emploi. Avant de vous engager, vérifiez le contenu réel de lagent/agents/aggregator.py et lagent/prompts/parsers.py dans la version que vous installez, puis confirmez que l'API de Agent.__call__ correspond bien à la signature décrite dans le README.

Sources officielles

1. InternLM/lagent on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases