Modèle / jeu de données
zjunlp/LLMAgentPapers avatar
zjunlp/LLMAgentPapers

LLMAgentPapers: ce que la liste de zjunlp classe, et ce qu'elle ne dit pas

Must-read Papers on LLM Agents.

3 116 étoiles186 forksUnknownLa licence varie
GitHub

En bref

De quoi s’agit-il ?
Une liste de lecture sur les agents LLM, organisée en taxonomie thématique par l'équipe zjunlp. Elle sert à cartographier un champ qui bouge vite, pas à décider quoi installer.
À qui s’adresse-t-il ?
LLMAgentPapers convient à qui doit cadrer un sujet avant de coder: doctorants, ingénieurs qui cherchent l'état de l'art, équipes qui préparent une revue de littérature. Il ne convient pas à qui veut un framework à installer, ni à qui a besoin d'une liste maintenue au jour près.
Puis-je l’utiliser commercialement ?
Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
Est-il encore maintenu ?
Oui. Les derniers commits datent d’il y a 4 jours.
En quel langage est-il écrit ?
GitHub n’indique pas de langage principal pour ce dépôt.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Le problème concret: retrouver un article dans un champ qui se réécrit tous les six mois

Le dépôt répond à une question simple: quels articles lire quand on commence à travailler sur les agents à base de grands modèles de langage. Il ne fournit ni code exécutable, ni bibliothèque, ni service. C'est une liste de publications, avec titres, auteurs, liens arXiv et années. Le public visé est celui qui doit se situer dans un domaine où les sondages se succèdent: le README cite par exemple une survey de 2023.8 sur les agents autonomes, une autre de 2023.9 sur l'essor et le potentiel des agents, une troisième de 2025.5 sur les systèmes humain-agent. La valeur de l'objet tient donc à la sélection et au rangement, pas à l'outillage. Un ingénieur qui cherche une dépendance à ajouter à un projet n'y trouvera rien. Un lecteur qui cherche une carte du terrain, oui.

Une taxonomie en deux axes: l'agent seul, puis l'agent en société

La structure du README sépare d'abord les surveys de cadrage (section Overview) du reste. Vient ensuite la partie Agent, découpée en cinq sous-thèmes: Personality, Memory, Planning, Tool use, RL training. Puis la partie Multiple Agents, elle-même scindée en Task-Oriented Communication (avec Collaborative Exchanges et Adversarial Interactions) et Casual/Open Conversations. S'ajoutent des sections Application, Framework et Others, plus une partie Resources qui contient Benchmarks, Types of Tools et Tool List. Cette organisation a un mérite: elle distingue ce qui relève des capacités internes d'un agent (mémoire, planification, outils) de ce qui relève de l'interaction entre plusieurs agents. Elle a un coût: un article qui traite à la fois de planification et de communication multi-agents ne rentre proprement dans aucune case, et rien dans le README n'indique comment ces recoupements sont gérés. Le classement est thématique, pas méthodologique.

Ce que contient réellement une entrée

Chaque référence suit un format stable: titre en gras, liste d'auteurs en italique, lien abs vers arXiv, date. L'entrée sur KnowAgent, annoncée dans la section News en 2024-03, suit ce modèle. Certaines entrées ajoutent un lien code, comme la survey de 2025.9 sur l'apprentissage par renforcement agentique, qui pointe vers un dépôt séparé. D'autres pointent vers un PDF plutôt qu'une page abs. Le README ne donne aucune annotation: pas de résumé, pas de note de lecture, pas d'indication sur ce qu'il faut retenir de chaque article. C'est un choix assumé de liste brute, et c'est aussi sa principale faiblesse pour un lecteur pressé. Compter sur ce dépôt pour trier dix articles sur la mémoire demande de toute façon d'ouvrir les liens un par un.

Mise en route: cloner, lire, contribuer

Il n'y a pas d'installation. La prise en main se limite à git clone sur la branche main, puis à la lecture du README. La contribution passe par une pull request sur ce même dépôt, la section Contribution du README renvoyant à une sous-section Contributing to this paper list et à une liste de contributeurs. Aucune commande de build, aucun fichier de configuration, aucune clé d'API n'est mentionné. Le fichier de licence n'apparaît pas dans le matériel fourni, mais le badge du README indique MIT et renvoie vers opensource.org/licenses/MIT. Si vous réutilisez la structure ou le texte de cette liste dans un autre dépôt, c'est cette licence qu'il faut lire avant de copier, en gardant à l'esprit que les articles eux-mêmes ont leurs propres conditions de diffusion sur arXiv, indépendantes de celles du dépôt.

La limite structurelle: une liste sans mécanisme de fraîcheur

Le dépôt n'a pas de releases, et le README ne décrit ni script de génération, ni flux de données, ni vérification automatique des liens. La seule trace de mise à jour visible est la section News, dont les deux entrées les plus récentes datent de 2024-03 et 2023-06. Un lecteur qui s'appuie sur cette section pour juger de l'activité récente n'a donc presque rien à se mettre sous la dent, alors que le dernier push enregistré sur le dépôt est bien plus tardif. Cette asymétrie entre l'activité du dépôt et ce que le README raconte est le point à surveiller: la liste peut avoir grossi sans que la page d'accueil le signale. Autre limite, l'absence de tout indicateur de qualité par entrée. Rien ne distingue un article fondateur d'une prépublication isolée. Le dépôt ne prétend d'ailleurs pas le faire.

Face à une bibliothèque de code: deux usages qui ne se recouvrent pas

La comparaison utile n'est pas avec une autre liste de liens, mais avec un framework d'agents. Un framework fournit des abstractions exécutables: boucle d'agent, appels d'outils, gestion de contexte, et souvent des exemples lançables. LLMAgentPapers fournit l'inverse: une bibliographie. La différence d'approche est nette. Le framework répond à la question comment construire, la liste répond à la question qu'a-t-on déjà essayé. Un projet qui doit livrer une fonctionnalité en deux semaines n'a rien à faire ici. Un projet qui doit choisir entre plusieurs architectures de planification, ou justifier un choix devant une revue, y trouvera une porte d'entrée. Le README renvoie aussi vers deux listes sœurs du même groupe, Prompt4ReasoningPapers et KnowledgeEditingPapers, ce qui confirme la logique: un index par sous-domaine, pas un outil.

Coût de maintenance et implications de licence

Le coût de maintenance est entièrement porté par les contributeurs bénévoles, via des pull requests. Il n'existe ni release versionnée, ni changelog, ni règle de dépréciation. Concrètement, une entrée ajoutée reste en place, et rien n'indique qu'un lien mort sera corrigé. Pour un lecteur, cela signifie que la vérification des liens fait partie du travail de lecture. Sur le plan juridique, le badge MIT du README concerne le dépôt lui-même. Il ne s'étend pas aux articles référencés, dont les droits dépendent de leur lieu de publication. Reproduire une liste d'auteurs ou un titre pour un usage bibliographique est une chose, rediffuser un PDF en est une autre. Je ne donne pas d'avis juridique ici: la seule chose vérifiable dans le matériel fourni est la présence du badge MIT et son lien vers le texte de la licence.

Quand la liste devient le mauvais outil

Trois cas où elle ne sert à rien. Premier cas: vous cherchez un benchmark exécutable pour évaluer un agent. La section Resources liste des benchmarks et des outils, mais le dépôt ne les héberge pas et ne les fait pas tourner. Deuxième cas: vous devez suivre la parution hebdomadaire. Sans flux, sans release, sans script, la liste ne peut pas tenir ce rythme. Troisième cas: vous travaillez sur un sous-domaine absent de la taxonomie. Le découpage Personality, Memory, Planning, Tool use, RL training couvre large, mais tout ce qui touche à l'évaluation, à la sécurité ou à l'observabilité d'agents en production ne dispose pas de section dédiée dans le README. Une entrée peut exister dans Others, mais rien ne le garantit.

Conclusion éditoriale

LLMAgentPapers convient à qui doit cadrer un sujet avant de coder: doctorants, ingénieurs qui cherchent l'état de l'art, équipes qui préparent une revue de littérature. Il ne convient pas à qui veut un framework à installer, ni à qui a besoin d'une liste maintenue au jour près. Avant de vous y fier, vérifiez deux choses: la date du dernier push par rapport à la parution que vous cherchez, et si la section qui vous intéresse contient autre chose qu'une suite de titres et de liens.

Sources officielles

  1. Issues
  2. README
  3. zjunlp/LLMAgentPapers on GitHub
Notes de la communauté

Notes de la communauté