XianyuAutoAgent : un agent LLM branché sur la messagerie d'un compte Xianyu

Le problème visé : répondre vite sur un canal qui ne dort pas

Sur Xianyu, la messagerie est le premier filtre commercial. Une question sur l'état d'un article, une demande de remise, un acheteur qui hésite : chaque message laissé sans réponse est une vente qui part ailleurs. Le README présente le projet comme une solution d'assistance 7×24, avec trois axes revendiqués : décision multi-experts, négociation de prix et conversation consciente du contexte. Le public visé est donc l'utilisateur qui gère un volume de conversations supérieur à ce qu'il peut traiter manuellement, pas l'équipe qui cherche une plateforme de support multi-canal. Le dépôt ne décrit aucune interface d'administration, aucun tableau de bord, aucun système de tickets. Tout passe par un compte Xianyu existant et par un processus Python lancé en local. C'est une contrainte de périmètre à intégrer avant de lire la suite : l'outil ne remplace pas un centre de contact, il automatise une boîte de réception personnelle.

Routage par invites : quatre fichiers texte plutôt qu'un classifieur entraîné

Le mécanisme central tient dans une ligne du tableau des fonctionnalités : une identification d'intention par prompt engineering, suivie d'une distribution dynamique vers des agents experts. Concrètement, le README nomme quatre fichiers dans le répertoire prompts : classify_prompt.txt pour la classification d'intention, price_prompt.txt pour l'expert prix, tech_prompt.txt pour l'expert technique et default_prompt.txt pour la réponse par défaut. Le routage n'est donc pas un modèle entraîné mais un appel LLM guidé par un texte que vous pouvez éditer. Deux conséquences directes. D'abord, la qualité du tri dépend entièrement de la formulation de classify_prompt.txt, et le README ne fournit aucune métrique de précision ni jeu d'évaluation. Ensuite, chaque message entrant consomme au minimum un appel pour la classification, puis un second pour la génération : le coût par conversation est structurellement supérieur à celui d'un simple prompt unique. Le README ne documente ni mise en cache, ni court-circuit, ni seuil de confiance permettant d'éviter le détour par le classifieur. C'est un choix lisible et modifiable, mais il déplace la charge de la donnée vers la rédaction des invites.

Contexte et mémoire : tout l'historique renvoyé au modèle

La ligne « contexte » du README indique une gestion de mémoire légère et l'envoi de l'historique complet de la conversation comme contexte au LLM. Autrement dit, pas de résumé, pas de fenêtre glissante annoncée, pas de base vectorielle. Le projet mentionne par ailleurs un renforcement RAG comme élément planifié, ce qui confirme qu'il n'est pas présent aujourd'hui. Cette approche fonctionne sur des échanges courts, typiques d'une négociation d'occasion : quelques dizaines de messages. Elle devient coûteuse et fragile sur un fil qui s'étale, puisque la facture d'inférence et le risque de dépassement de fenêtre croissent avec la longueur de l'historique. Le README ne précise pas de politique de purge ni de limite de tours conservés. Un déployeur prudent devrait chercher dans le code où l'historique est stocké et tronqué, car cette information ne figure pas dans la documentation fournie. Sur ce point précis, le dépôt reste en retrait par rapport à ce qu'un opérateur attend pour dimensionner un service.

Installation : cloner, installer, remplir un .env

La mise en route tient en quatre étapes documentées. Le clonage et l'installation des dépendances d'abord : git clone https://github.com/shaxiu/XianyuAutoAgent.git, puis cd XianyuAutoAgent, puis pip install -r requirements.txt. La configuration ensuite, via un fichier .env que l'on crée ou que l'on obtient en renommant .env.example. Les clés obligatoires sont API_KEY, COOKIES_STR, MODEL_BASE_URL et MODEL_NAME. Deux options sont présentées comme facultatives : TOGGLE_KEYWORDS, qui définit le mot de passe de bascule vers la prise en charge humaine (le point, par défaut, pour reprendre la main et un second envoi pour rendre la main à l'IA), et SIMULATE_HUMAN_TYPING, qui introduit un délai de frappe simulé. Le README signale que le modèle par défaut est Tongyi Qianwen et qu'il faut modifier MODEL_BASE_URL et MODEL_NAME pour un autre fournisseur. Le lancement se fait avec python main.py. Le point le plus délicat est COOKIES_STR : il faut ouvrir la console du navigateur sur la version web de Xianyu, onglet Network, filtrer sur Fetch/XHR, cliquer une requête et copier les cookies. C'est une chaîne de session liée à un compte, et le README n'aborde ni son expiration ni la conduite à tenir après déconnexion.

Les invites par défaut et la bascule vers l'humain

Le README précise que si les fichiers prompts/*_prompt.txt n'existent pas, le programme lit le contenu des quatre modèles fournis, et qu'il suffit de retirer le suffixe _example du nom pour les activer. Ce détail compte : sans cette étape, vos modifications de fichiers peuvent rester sans effet, puisque des modèles de secours prennent le relais. La personnalisation attendue porte sur le ton, les limites de remise et le vocabulaire technique. Le mécanisme de bascule mérite attention : TOGGLE_KEYWORDS repose sur un mot envoyé dans la conversation, ce qui signifie que la valeur par défaut, un simple point, peut être déclenchée par un message anodin ou par une frappe involontaire. Un utilisateur qui écrit « ok. » dans le fil bascule potentiellement l'agent en mode humain sans s'en rendre compte. Le README ne décrit pas de confirmation ni de journalisation de ce changement d'état, seulement une journalisation présentée comme basique. C'est le genre de détail qui décide de l'utilité réelle en production, et il n'est pas traité.

Négociation par paliers : une politique de prix écrite en clair

Le module de tarification est décrit comme une stratégie de baisse par paliers, illustrée par une capture d'écran intitulée « négociation par paliers ». Le README ne donne ni le nombre de paliers, ni les pourcentages, ni le plancher en dessous duquel l'agent refuse. Ces valeurs vivent donc dans les invites ou dans le code, et non dans la documentation. Le comparatif de marché est listé comme planifié, pas comme livré. Il faut en tirer une conclusion pratique : la politique de prix est entièrement sous votre responsabilité, et l'agent l'appliquera sans garde-fou documenté. Rien dans le matériel fourni n'indique une limite dure codée en dehors du prompt. Si vous fixez un plancher uniquement par une phrase dans price_prompt.txt, la robustesse de ce plancher dépend de la capacité du modèle à la respecter, ce qui n'est pas la même chose qu'une validation côté programme. Pour un vendeur, la différence entre les deux est précisément l'écart entre une marge tenue et une vente à perte.

Ce que le dépôt ne promet pas de maintenir

La section d'avertissement est explicite : le projet est présenté comme destiné à l'apprentissage et à l'échange, et l'équipe indique qu'elle peut cesser les mises à jour ou supprimer le dépôt à tout moment. Aucune version publiée n'est référencée, donc pas de cycle de correctifs ni de notes de version à suivre. Le fichier requirements.txt n'est pas détaillé dans le README, ce qui rend impossible toute évaluation des dépendances et de leur coût de mise à jour. Côté licence, le dépôt est en GPL-3.0 : si vous redistribuez une version modifiée, ou si vous exposez le logiciel modifié comme service à des utilisateurs, les obligations de cette licence s'appliquent, notamment la mise à disposition du code source correspondant. Je ne donne pas d'avis juridique ; faites vérifier votre cas si vous envisagez une exploitation commerciale. Le README mentionne enfin une référence au projet cv-cat/XianYuApis et un lien vers un guide externe hébergé sur Feishu, dont le contenu n'est pas fourni ici et que je ne peux donc pas évaluer.

Face à un script de réponse classique, et face à un framework d'agents

L'alternative la plus directe est le script maison : une boucle qui interroge l'API de messagerie, envoie chaque message à un LLM avec une consigne unique et publie la réponse. La différence d'approche est nette. XianyuAutoAgent insère une étape de classification avant la génération, ce qui permet de charger des consignes différentes selon qu'il s'agit d'une négociation ou d'une question technique, au prix d'un appel supplémentaire par message et d'une dépendance à la qualité de classify_prompt.txt. Un script unique coûte moins cher et se comporte de façon plus prévisible, mais répond au même ton à toutes les situations. Une seconde alternative consiste à utiliser un framework d'agents avec outils et mémoire externe. Là encore, l'écart porte sur la mémoire : le projet renvoie l'historique complet, sans résumé ni récupération documentaire, ce qui le place du côté simple du spectre. Le README liste d'ailleurs l'intégration RAG et l'analyse de sentiment comme évolutions prévues, ce qui situe le dépôt à un stade antérieur à ces frameworks. Le choix se joue donc entre un code court et lisible, que vous pouvez auditer en une soirée, et une pile plus lourde à installer mais dotée de mécanismes de mémoire et d'outils déjà éprouvés.

Conclusion éditoriale

À adopter si vous cherchez un point de départ en Python pour automatiser les réponses d'un compte Xianyu avec un LLM et que vous acceptez de lire le code faute de documentation détaillée. À éviter si vous vendez depuis un compte principal : la collecte de COOKIES_STR et l'absence de gestion documentée des erreurs de session rendent l'essai risqué. Avant tout, vérifiez la présence effective des fichiers prompts/*_prompt.txt, le contenu de .env.example et la manière dont main.py traite une réponse vide du modèle.

Sources officielles

1. Issues
2. License: GPL-3.0
3. README
4. shaxiu/XianyuAutoAgent on GitHub