ai-agent-papers : une taxonomie à quatre couches pour la recherche sur les agents

Le problème : trier un flux arXiv qui bouge chaque semaine

La recherche sur les agents produit un volume d'articles qui rend la lecture exhaustive irréaliste. Le README assume ce constat et prend une position claire : plutôt que la couverture complète, il annonce ajouter un article seulement quand celui-ci introduit une approche ou un concept qui se distingue des méthodes existantes. La sélection s'appuie sur des recherches arXiv hebdomadaires avec des mots-clés définis. Le public visé est donc l'ingénieur ou le chercheur qui veut savoir ce qui a changé dans un sous-domaine précis, pas celui qui veut un inventaire de tout ce qui a été publié. Le dépôt se présente comme un ensemble de listes de lecture ordonnées par date, et non comme un moteur de recherche ou une base de données interrogeable. Cette distinction compte : vous y trouvez un parcours de lecture, pas une API.

Quatre couches, et une règle de rangement qui décide de tout

Le classement repose sur quatre couches : les capacités (ce que l'agent sait faire), l'architecture (comment il est construit), les opérations (comment il est exploité) et les applications (où il est déployé). Chaque couche se subdivise, et certaines branches portent un compteur d'ajouts récents entre parenthèses, par exemple Skills (+18) ou Harness (+34). Ces compteurs ne mesurent pas la qualité d'un domaine, seulement le nombre d'entrées ajoutées sur la fenêtre affichée. Le README précise que les badges signalent les articles ajoutés au cours des deux derniers mois et que les en-têtes de groupe affichent la somme. La règle de rangement est décrite dans TAXONOMY.md, qui contient la carte complète des répertoires et les règles déterminant où chaque article est classé. C'est le document à lire en premier : sans lui, les compteurs et les chemins de fichiers restent opaques. Un point de friction possible : un article qui relève à la fois de la mémoire et de l'auto-évolution doit être tranché par ces règles, et le README ne donne pas d'exemple de cas limite. La cohérence du classement dépend donc entièrement de la discipline de l'auteur, pas d'un mécanisme automatique de vérification.

Le mécanisme réel : des fichiers Markdown et un script de badges

Le dépôt n'exécute rien à l'installation. Sa matière première est un ensemble de fichiers Markdown, un par sous-catégorie, comme capabilities/knowledge-context/memory.md ou applications/system/coding-agents.md. Le README affiche aussi une figure, assets/ai-agent-workflow.png, qui illustre le flux de travail d'un agent, mais elle sert de contexte pédagogique et non de schéma d'implémentation du dépôt lui-même. Le seul élément exécutable mentionné est scripts/update_readme_badges.py, dont la commande de régénération est donnée telle quelle : python scripts/update_readme_badges.py. Ce script recalcule les badges de fraîcheur affichés dans le README. Autrement dit, le dépôt est un artefact éditorial maintenu à la main, avec une petite couche de script pour éviter de compter les ajouts manuellement. Les newsletters mensuelles suivent une autre logique : le README indique que depuis 2026-06, chaque article est lu en détail dans sa version HTML sur arXiv, que des figures sont citées et que les faits sont retenus quand plusieurs articles les corroborent. La procédure est documentée dans .claude/skills/newsletter, ce qui suggère un flux de travail assisté par un agent, mais le README ne détaille pas les étapes.

Mise en route : lire, forker, régénérer

Il n'y a pas de paquet à installer ni de dépendance déclarée dans le matériel fourni. La prise en main consiste à cloner le dépôt, puis à ouvrir TAXONOMY.md pour comprendre la carte des répertoires, et enfin à suivre les listes de lecture qui vous concernent. Si vous modifiez les entrées, la commande python scripts/update_readme_badges.py régénère les badges du README. Le README ne précise pas la version de Python requise, ni les bibliothèques utilisées par ce script, ni s'il existe un fichier de dépendances. C'est une lacune pratique : avant de lancer le script sur un fork, il faut inspecter son contenu pour connaître ses imports. Les newsletters sont rangées par mois sous newsletters/, par exemple newsletters/aug_2026/harness_trends.md ou newsletters/jun_2026/coding_agents_trends.md, ce qui donne un chemin de lecture chronologique sans outil supplémentaire. La langue du dépôt est mixte : le README principal est en anglais, tandis que la section des newsletters est intitulée en japonais (研究トレンド) et certaines newsletters de mai 2026 portent un titre japonais.

Ce que le dépôt ne fait pas, et pourquoi cela peut poser problème

Le README annonce que la couverture exhaustive n'est pas l'objectif. C'est un choix assumé, mais il a une conséquence directe : vous ne pouvez pas utiliser ce dépôt pour affirmer qu'un domaine est vide ou qu'une méthode n'existe pas. L'absence d'un article dans une liste ne signifie rien d'autre que l'auteur ne l'a pas retenu. Deuxième limite : aucune licence n'est déclarée dans le matériel fourni. Sans identifiant de licence, la réutilisation des textes, des résumés et des figures n'est pas encadrée par une permission explicite, et les conditions de redistribution restent à clarifier auprès du mainteneur. Troisième limite : il n'y a aucune release publiée. Le dépôt est donc un document vivant, sans version figée à laquelle se référer, ce qui complique la citation dans un travail qui exige une date et un état précis. Enfin, la sélection repose sur des mots-clés arXiv et sur un jugement éditorial. Un article pertinent qui emploie un vocabulaire différent de celui des mots-clés peut passer inaperçu, et rien dans le dépôt ne permet de mesurer ce taux d'omission.

Face à une liste Awesome classique : jugement éditorial contre exhaustivité

Le README cite trois références du même genre : LLMAgentPapers, Awesome LLM-Powered Agent et Awesome LLM agents. La différence d'approche tient au filtrage. Une liste Awesome classique accumule et laisse le lecteur trier ; ici, l'auteur revendique le tri en amont et l'ajout conditionné à un caractère distinctif. Le second écart est la structure : les listes Awesome restent souvent plates ou organisées par framework, alors que ce dépôt impose une hiérarchie à quatre couches avec des compteurs de fraîcheur et des newsletters mensuelles qui citent des figures et croisent plusieurs articles. Le troisième écart est la maintenance : les badges et les compteurs suggèrent un rythme régulier, mais le README ne publie aucun engagement de fréquence au-delà de la mention des recherches hebdomadaires et de la mise à jour bimensuelle annoncée dans la description du dépôt. Si vous voulez un index large pour une recherche par mot-clé, une liste Awesome ou une recherche arXiv directe sera plus adaptée. Si vous voulez une sélection argumentée avec un chemin de lecture, la structure en couches apporte quelque chose que les listes plates n'apportent pas.

Coût de maintenance et implications de licence

Le coût de maintenance se répartit en trois tâches visibles dans le matériel : la recherche arXiv hebdomadaire, le classement dans l'arborescence, et la rédaction des newsletters mensuelles avec lecture du HTML arXiv et citation de figures. La commande python scripts/update_readme_badges.py automatise une partie de l'affichage, mais pas la sélection ni la rédaction. Pour un fork, cela signifie que la valeur dépend d'un effort éditorial continu, difficile à déléguer à un script. Sur le plan juridique, l'absence d'identifiant de licence dans le matériel fourni empêche de savoir si vous pouvez republier les résumés ou les figures. Les articles arXiv eux-mêmes restent soumis à leurs propres licences, distinctes de celle du dépôt, et le README ne traite pas ce point. Si vous comptez intégrer ces listes dans une documentation interne ou un produit, la première démarche concrète est de demander au mainteneur quel identifiant de licence s'applique au contenu du dépôt. Rien dans le matériel fourni ne permet de répondre à cette question à sa place.

Conclusion éditoriale

À adopter si vous cherchez un point d'entrée classé pour la littérature récente sur les agents et que vous acceptez de vérifier vous-même chaque lien arXiv, puisque le dépôt ne fournit ni licence ni version publiée. À éviter si vous avez besoin d'un paquet installable, d'un cadre d'évaluation reproductible ou d'une garantie de couverture exhaustive : le README annonce explicitement le contraire. Avant de vous engager, ouvrez TAXONOMY.md, vérifiez les règles de classement, puis lancez python scripts/update_readme_badges.py sur un fork pour voir si la régénération des badges reste cohérente avec l'arborescence.

Sources officielles

1. Issues
2. masamasa59/ai-agent-papers on GitHub
3. README