llm-paper-daily : un flux arXiv pour les agents LLM, pas une bibliothèque

Un flux éditorial, pas un paquet Python

Le langage principal du dépôt est Python, mais ce détail induit en erreur. Le README ne décrit aucune API, aucun module importable, aucune commande d'installation. Ce que le dépôt livre, c'est un fichier README mis à jour quotidiennement avec une liste d'articles arXiv, chacun accompagné d'un résumé en chinois, d'un lien vers le PDF et parfois d'un lien vers un dépôt GitHub associé. La section intitulée 最新论文 organise ces entrées par mois, sous forme de tableau avec une colonne de date, une colonne Paper et une colonne Links & Summary.

Le public visé est donc précis : un lecteur qui veut suivre la production arXiv sur les agents et les grands modèles sans interroger le site chaque matin. Les sujets déclarés couvrent agent, chatgpt, large-language-models, llm et rag. Les résumés sont rédigés en chinois, y compris pour des articles dont le titre est en anglais, ce qui suppose soit une traduction, soit une rédaction directe dans cette langue. Le README signale par ailleurs une version anglaise via README_en.md, mais le contenu fourni ne permet pas de vérifier si les deux versions sont synchronisées ni à quelle fréquence.

Un point de conception mérite d'être noté : le dépôt ne prétend pas classer les articles par qualité. Il les liste. La sélection éditoriale reste donc opaque, et rien dans le matériel fourni ne décrit les critères d'inclusion ou d'exclusion.

Le tableau du README et ses marqueurs de génération

Le README contient des commentaires HTML qui encadrent les zones mises à jour automatiquement. On trouve paper-daily:readme:updates:start et paper-daily:readme:updates:end autour du bloc repliable qui liste les derniers titres, et paper-daily:readme:months:start avec paper-daily:readme:months:end autour du tableau mensuel. Ces marqueurs indiquent qu'un programme réécrit le contenu entre ces bornes sans toucher au reste du fichier.

C'est la seule information d'architecture réellement visible dans le matériel fourni. Elle ne dit pas quel ordonnanceur déclenche la mise à jour, ni comment les résumés sont produits. Le badge de statut affiche une date et une heure, par exemple Update_09.09_06:13, ce qui suggère une exécution quotidienne, mais le README ne documente ni la source des métadonnées d'institution, ni la manière dont les résumés sont rédigés. Toute personne qui voudrait reproduire la chaîne de production devra donc lire le code, que le matériel fourni ne contient pas.

Chaque entrée renvoie vers un fichier Markdown dans un répertoire summary, organisé par année et par mois, par exemple summary/2026-09/2609.09153.md. Le dépôt mélange donc deux artefacts : un index lisible dans le README et des fiches détaillées par article. Cette séparation est saine, mais elle implique que la valeur réelle se trouve dans les fiches, pas dans le tableau.

L'abonnement passe par un agent, pas par un cron manuel

La partie la plus intéressante du README concerne l'abonnement. Le dépôt ne demande pas de cloner puis d'écrire soi-même un script. Il fournit une consigne en texte brut à envoyer à un agent local, OpenClaw, Codex ou Claude Code, qui se charge de la configuration. La consigne indique l'URL du dépôt, demande de lire SUBSCRIBE.md à la racine, de créer une configuration locale, de prévisualiser le digest, d'installer une tâche planifiée, puis de rapporter l'emplacement du fichier de configuration, l'heure d'exécution, la langue, le nombre d'articles par envoi et le résultat de la vérification.

Le README précise que l'agent utilise un skill nommé paper-subscribe et qu'il ne lit que le fichier public feed-papers.json. Il ajoute que l'agent ne lance sur votre machine ni la collecte des articles ni le pipeline de résumé. C'est une décision de conception défendable : elle évite d'installer une chaîne de dépendances Python pour un simple abonnement, et elle déplace la charge de production vers l'infrastructure du mainteneur.

La contrepartie est un couplage fort à trois agents nommément cités. Si vous n'utilisez aucun de ces trois outils, la procédure décrite ne s'applique pas telle quelle. Le README ne fournit pas de commande équivalente pour un cron classique, ni de schéma de feed-papers.json, ni d'exemple de fichier de configuration. Ces éléments sont renvoyés à SUBSCRIBE.md, que le matériel fourni ne contient pas. Impossible donc de dire ici quels paramètres existent réellement.

Ce que le dépôt ne fait pas

Le README ne mentionne aucune licence, et les métadonnées du dépôt indiquent une licence inconnue. Ce n'est pas un détail cosmétique. Un dépôt qui redistribue des résumés d'articles arXiv, et dont le README est réécrit par un programme, pose deux questions distinctes : le régime applicable au contenu du README lui-même, et celui applicable aux résumés. Les articles arXiv ont leurs propres conditions de redistribution, qui varient selon la licence choisie par les auteurs. Rien dans le matériel fourni ne permet de savoir comment le mainteneur gère ce point. Il faut le vérifier avant toute réutilisation des résumés, notamment dans un produit.

Deuxième limite : le dépôt n'offre pas de recherche. Le tableau mensuel est un index chronologique. Retrouver un article sur un sujet donné suppose de parcourir les fiches summary ou de passer par un moteur externe. Pour un flux quotidien de quelques entrées, c'est acceptable. Pour constituer une base de connaissances, ce n'est pas l'outil adapté.

Troisième limite, plus structurelle : le dépôt dépend d'un mainteneur unique et d'un pipeline non documenté. Le README ne décrit ni la cadence de publication des fiches summary, ni ce qui se passe en cas d'échec de la mise à jour. Le badge de statut donne une date, pas un historique. Si la mise à jour s'arrête, rien dans le dépôt ne le signale explicitement.

Face à une simple requête arXiv

L'alternative la plus directe n'est pas un autre dépôt, c'est l'API arXiv elle-même. Une requête sur la catégorie cs.CL ou cs.AI, filtrée par date, renvoie les mêmes articles bruts, avec titre, auteurs, résumé en anglais et lien PDF. La différence tient à trois choses. D'abord, la langue : arXiv ne fournit pas de résumé en chinois, alors que llm-paper-daily en produit un pour chaque entrée. Ensuite, le filtrage : une requête arXiv renvoie tout ce qui correspond aux mots-clés, sans tri éditorial, tandis que le dépôt publie une poignée d'articles par jour, ce qui suppose une sélection. Enfin, l'effort d'intégration : une requête arXiv demande d'écrire et de maintenir un script, alors que le dépôt propose un skill prêt à configurer via un agent.

Le compromis est clair. Avec l'API arXiv, vous contrôlez les critères, vous obtenez les métadonnées complètes et vous ne dépendez d'aucun intermédiaire. Avec llm-paper-daily, vous gagnez du temps de curation et une lecture en chinois, mais vous perdez la visibilité sur les critères de sélection et vous dépendez de la continuité d'un dépôt sans licence déclarée. Pour un chercheur qui a besoin de couverture exhaustive sur un sujet précis, l'API reste le bon choix. Pour une veille de surface sur les agents, le dépôt est plus rapide à mettre en place.

Coût de maintenance et cycle de mise à jour

Du côté de l'utilisateur, le coût de maintenance est faible par construction. Le README indique que le skill ne lit que feed-papers.json et n'exécute rien localement. Il n'y a donc pas de dépendances Python à mettre à jour, pas de scraper à réparer quand arXiv change de mise en page, pas de clé d'API à gérer. La tâche planifiée installée par l'agent se contente vraisemblablement de récupérer un fichier et de formater un envoi, mais le README ne détaille pas ce point.

Le coût réel se situe ailleurs : dans la dépendance à un pipeline que vous ne contrôlez pas. Si le format de feed-papers.json change, si le fichier disparaît, ou si la mise à jour quotidienne s'interrompt, votre abonnement cesse de fonctionner sans que vous ayez de prise sur la cause. Le README ne documente ni la stabilité du format, ni une politique de version. Un consommateur prudent devrait donc traiter feed-papers.json comme une interface non versionnée.

Reste la question de la licence. Les métadonnées du dépôt ne déclarent aucune licence, et le README n'en mentionne aucune. Sans licence explicite, le droit d'auteur s'applique par défaut dans la plupart des juridictions, ce qui restreint la réutilisation, la modification et la redistribution. Je ne donne pas d'avis juridique ici : le point à retenir est qu'aucune autorisation explicite n'est visible dans le matériel fourni, et que cela doit être clarifié avant d'intégrer les résumés dans un produit ou un service.

Comment juger avant d'adopter

Le dépôt est récent dans sa forme actuelle et ne publie aucune release, ce que les métadonnées confirment. Il n'y a donc pas de version à épingler, pas de changelog, pas de notes de version décrivant une rupture de format. Pour un flux de veille, ce n'est pas rédhibitoire. Pour un composant d'infrastructure, cela suffit à écarter l'outil.

La bonne façon de l'évaluer tient en deux vérifications concrètes. Première vérification : ouvrir feed-papers.json et regarder la structure réelle des entrées, puisque c'est le seul fichier que le skill consomme. Si les champs dont vous avez besoin n'y sont pas, le reste du dépôt ne vous aidera pas. Seconde vérification : lire SUBSCRIBE.md pour connaître les paramètres de configuration, l'heure d'exécution et le nombre d'articles par envoi, trois éléments que le README annonce comme devant être rapportés par l'agent mais qu'il ne détaille pas lui-même.

Si ces deux fichiers correspondent à votre usage, la mise en place est rapide et le coût de fonctionnement quasi nul. Si l'un des deux manque ou ne correspond pas, il vaut mieux rester sur l'API arXiv et écrire votre propre filtre.

Conclusion éditoriale

Adoptez llm-paper-daily si vous voulez un flux quotidien d'articles arXiv sur les LLM et les agents, avec des résumés en chinois et un mécanisme d'abonnement qui ne fait tourner aucune collecte sur votre machine. Ne l'adoptez pas si vous cherchez du code à importer, un classement quantitatif ou une interface de recherche sur archive. Avant toute configuration, lisez SUBSCRIBE.md à la racine du dépôt et vérifiez deux points : la licence, absente des métadonnées du dépôt, et le contenu réel de feed-papers.json, puisque le README indique que le skill paper-subscribe ne lit que ce fichier public.

Sources officielles

1. Issues
2. README
3. xianshang33/llm-paper-daily on GitHub