Les créateurs d'un manager IA pour marketplaces suppriment leur agent et allègent le code de 461 lignes

Quatre jours après le lancement, l'équipe qui développe un manager IA pour les vendeurs de marketplaces a supprimé son agent en entier. Selon les tests internes, il semblait performant, mais les conversations réelles ont montré autre chose : ses réponses sonnaient juste tout en s'appuyant sur une petite partie des données. Plutôt que de le corriger, les développeurs ont jeté leur propre cœur et confié le déroulement de l'agent à Pydantic AI. Le commit est révélateur : 582 lignes supprimées, 121 ajoutées.

Les tests disaient une chose, les conversations une autre

Pour l'évaluation, l'équipe a constitué un jeu de référence : huit tâches types par poste, et un modèle-juge qui note chaque réponse de 1 à 5 et voit les données sur lesquelles l'agent s'est appuyé. Sur cette référence, l'agent a surpassé l'ancienne analyse des requêtes pour sept postes sur neuf, et le manager marketplaces a obtenu 4,28.

Les auteurs ont ensuite lu les dialogues eux-mêmes. Un propriétaire demande pourquoi ses ventes ont chuté, et l'agent examine dix produits sur cent : l'outil renvoie « jusqu'à 15 résultats », et le tableau transmis au modèle est en plus tronqué. La conclusion est fluide, mais elle porte sur un dixième de la boutique. Le juge ne détecte pas ce type d'erreur, car les données vues par l'agent concordent avec sa conclusion. C'est un angle mort classique de l'évaluation par LLM : le juge vérifie la cohérence de la réponse avec le contexte, pas l'exhaustivité du contexte lui-même.

D'autres problèmes avaient la même origine :

• Le wrapper sur les avis renvoyait les avis récents, pas tous. La demande « analyse tout sur six mois » se heurtait à l'absence de méthode, et l'agent répondait « je ne sais pas encore faire ». La liste de ces demandes dans le back-office grossissait plus vite que l'équipe n'écrivait de nouveaux wrappers.
• Les descriptions des outils contenaient des consignes comme « un ou deux appels avec des termes larges » et « jusqu'à 15 ». Le modèle les suivait même quand la tâche exigeait vingt appels.
• La limite de huit étapes par tour ne suffisait pas pour des tâches du type « comprends pourquoi une niche s'effondre ». Elle a été portée à 50 étapes et 15 minutes, mais l'effet est resté modeste : l'agent ne butait pas sur le nombre d'étapes, mais sur le fait que chaque étape ne lui fournissait qu'un fragment de données.

La conclusion des auteurs : ils craignaient la liberté de l'agent et décidaient à sa place combien regarder, quoi afficher et comment utiliser l'outil. Chaque décision semblait raisonnable, mais ensemble elles ont transformé l'agent en exécutant qui fait exactement ce que dit l'instruction.

Pourquoi jeter le cœur plutôt que le réparer

Le cœur maison comprenait la boucle, les appels d'outils, les nouvelles tentatives en cas de coupure, la compression des anciennes étapes et les groupes d'outils. Tout cela demandait de la maintenance, sans rien d'unique : les lecteurs de l'article précédent ont fait remarquer, à juste titre, qu'il s'agissait d'un simple ReAct. La valeur du produit se trouve ailleurs : dans les outils pour les plateformes, dans les règles d'écriture dans le compte vendeur et dans la présentation de la réponse au propriétaire.

L'équipe a donc remplacé la boucle par Pydantic AI. Les outils rares sont chargés via DeferredLoadingToolset, uniquement sur recherche, au lieu de figurer dans le contexte de chaque étape. Du jeu d'outils prêt à l'emploi, elle a retenu la recherche DuckDuckGo avec huit résultats et le chargement d'une page à partir d'un lien. La limite de requêtes est désactivée : usage_limits.request_limit vaut None. Les outils maison sont restés les mêmes et sont appelés via les mêmes fonctions, de sorte que les tableaux présentés au propriétaire, le journal des actions et les règles d'écriture n'ont pas changé.

Un seul outil au lieu de dizaines de wrappers

Le changement principal est un changement de principe. Auparavant, on donnait à l'agent des outils et on lui expliquait comment s'en servir. Désormais, il reçoit un accès, un outil et une documentation, et choisit lui-même comment l'utiliser.

Toute l'API Wildberries est devenue un seul outil, qui donne accès à 307 méthodes, auquel s'ajoute un outil distinct contenant la documentation officielle. Fiches produits, prix, stocks, commandes, livraisons, publicité, avis, messageries et finances sont accessibles à l'agent dans la même étendue que l'API elle-même. Si une méthode ne figure pas dans la documentation, l'outil renvoie une suggestion de vérifier via un appel de référence. Les méthodes de lecture s'exécutent immédiatement et intégralement, sans troncature. L'API du service d'analytique MPStats est branchée de la même manière. La bibliothèque de connaissances a été retirée du prompt : la documentation se trouve à côté de l'API, et l'agent cherche le reste lui-même sur le web.

Une règle a survécu à la réécriture : toute écriture dans le compte vendeur n'a lieu qu'après un « oui » du propriétaire. C'est la mécanique qui a changé. Les écritures d'un tour s'accumulent dans un seul lot, par exemple « modifier le prix de trois produits, augmenter l'enchère dans deux campagnes, répondre à quatre avis ». Le propriétaire voit la liste au format « avant → après » et répond une seule fois. Le lot s'exécute dans l'ordre et s'arrête à la première erreur.

Parmi les améliorations mineures : la lecture en parallèle (pendant que l'agent consulte les commandes, il vérifie déjà les stocks et la publicité), des modifications strictement une par une, un affichage du texte en flux avec des statuts comme « je lis les avis de mars », la mémorisation des appels d'API réussis dans le projet et la reprise du tour au même endroit après une défaillance du modèle ou de la recherche.

Pour l'instant, les auteurs ne publient pas de résultats pour la nouvelle version. Ils écrivent seulement que l'agent creuse plus profondément, ce qui les amène à se demander s'il utilise le bon modèle. L'article ne donne aucun chiffre sur la qualité ni sur le coût en tokens une fois les limites levées. Pour les équipes qui construisent des agents sur des API fermées, la leçon est pragmatique : il faut d'abord vérifier que leurs propres wrappers ne tronquent pas ce que le modèle devrait voir en entier.