L'agent de recherche ZCode de Roman : du bruit communautaire aux preuves produit
Roman, modérateur de communauté chez Z.ai, décrit le plugin ZCode qu'il a conçu et développé, avec des preuves traçables et une réponse finale écrite par une personne.
Introduction de la rédaction
Cet article présente Roman, modérateur de communauté chez Z.ai, et son projet ZCode Discord Research Agent. L'essai à la première personne qui suit raconte son travail de planification, de conception et de développement. C'est un récit personnel du projet, pas une annonce officielle de Z.ai ni une affirmation de commande, d'adoption ou de soutien de l'entreprise.
L'essai de Roman à la première personne
Le problème que j’ai choisi de résoudre
Les communautés comme le Discord de Z.ai permettent aux utilisateurs d'exprimer leurs besoins pressants avant que tout le monde y voie une tendance. Repérer les tendances en formation dans ce volume est difficile. J'ai décidé de construire une solution technique à ce problème.
La matière était déjà là, et c'était précisément la difficulté. Une communauté d'assistance peut regorger d'informations difficiles à exploiter. Une personne décrit un processus cassé dans un fil de bug, une autre signale la même panne sous un autre titre. Le seul détail de diagnostic utile se trouve dans une capture d'écran. Une longue conversation mélange plaintes directes, accords brefs et questions sur un correctif. Lire davantage de messages ne produit pas automatiquement une meilleure décision produit.
J'ai planifié, conçu et développé ZCode Discord Research Agent pour réduire la distance entre ce que dit une communauté et les actions qu'une équipe produit peut raisonnablement engager. Je voulais une méthode reproductible pour examiner les retours, conserver les preuves et produire un rapport qu'un responsable support puisse vérifier. Le but est de rendre la recherche défendable, au-delà du gain de vitesse.
Un processus de recherche
J'ai construit un plugin natif pour ZCode, reposant sur une chaîne d'outils Python locale. Le processus va du périmètre et de la collecte à l'analyse, aux rapports et, si nécessaire, à une réponse relue. Le collecteur récupère les messages des fils et les métadonnées des pièces jointes ; l'agent applique ensuite la méthode de recherche. Le générateur transforme l'analyse structurée en documents de travail.
La collecte doit préserver les propos, l'analyse expliquer leur sens et le rapport montrer la conclusion et ses limites. Un paragraphe plausible ne remplace pas cette chaîne de preuves.
Le jugement reste explicite. Regroupement sémantique, examen des captures et distinction entre plainte réelle et remarque passagère relèvent du processus guidé par l'agent. Je ne prétends pas qu'un petit script Python comprend automatiquement chaque conversation.
Tenir compte de la structure de Discord
Un outil de recherche doit respecter la structure de sa source. Les forums Discord contiennent des fils où se trouvent les conversations utiles. Le projet découvre catégories, canaux, fils récents et archivés ; il pagine les messages, télécharge les pièces jointes et crée un manifeste local de collecte. La couche API gère les nouvelles tentatives après limitation de débit ou erreur réseau.
Le collecteur est borné par des limites configurées de forums et de fils, avec un plafond par défaut de 800 messages par fil. Les fichiers de fils déjà en cache sont ignorés au lieu d'être rafraîchis continuellement. Ces choix réduisent le travail répété et limitent les conclusions : un échantillon ne prouve pas que toutes les conversations ont été lues, et un fil en cache n'est pas nécessairement actuel.
Les outils tournent localement dans l'environnement de l'opérateur, sans service hébergé distinct pour les identifiants. Ce choix architectural ne garantit globalement ni confidentialité, ni sécurité, ni approbation par la plateforme.
Repérer les tendances sans fabriquer de certitude
Dix messages ne signifient pas forcément dix utilisateurs touchés. Un auteur peut répéter sa plainte, plusieurs réponses demandent seulement des nouvelles, et un bref 'pareil' contient moins d'informations qu'une description précise de la panne.
Le processus sépare donc plaintes strictes et réponses limites, exclut les demandes de statut du décompte et ne compte qu'une fois les copies d'un même texte par un auteur. Il regroupe les signalements en familles de problèmes tout en conservant les références aux fils. Il demande aussi d'examiner les captures téléchargées lorsque des identifiants de diagnostic utiles manquent dans le texte.
Les chiffres deviennent plus faciles à contester. Un responsable doit pouvoir demander pourquoi un auteur a été compté, quel fil soutient une conclusion et quelles preuves manquent. Je voulais que le rapport résiste à ces questions.
Des rapports que l’on peut examiner
La couche de rapports crée un classeur Excel à plusieurs feuilles et du HTML prêt à imprimer, avec génération PDF native si la bibliothèque facultative ReportLab est présente. Le classeur sépare synthèse, fils par famille de problèmes, preuves détaillées, audit des réponses et vérifications des pièces jointes.
Un responsable peut commencer par les priorités, tandis qu'une personne examinant une panne précise remonte aux preuves. Si une conclusion est contestée le mois suivant, le chemin vers les fils d'origine reste dans le rapport.
Assister le support en laissant la réponse finale à une personne
La partie qui m'intéresse particulièrement est que le même processus de recherche peut aussi aider le support lui-même.
À partir d'une question, il peut rassembler les preuves des fils, retrouver la documentation dans une base de connaissances locale et proposer des solutions possibles avec leurs sources. Le spécialiste confronté à un bug inconnu dispose d'un point de départ documenté.
Une personne écrit volontairement la réponse finale. L'agent propose, l'humain décide ce que la communauté entendra. Le processus exige une documentation officielle ou un précédent approuvé par les modérateurs, des URL exactes et une remontée honnête lorsque les sources ne répondent pas. Il exclut les promesses inventées de correctifs, de dates ou de compensation. L'envoi reste une étape distincte approuvée à l'avance par une personne. Je voulais transmettre les preuves tout en préservant le jugement et la voix humains.
Rendre l’outil utilisable par d’autres
J'ai aussi traité l'installation comme une partie du produit. Le dépôt contient sa propre définition de marketplace de plugins : un ZIP téléchargé peut servir de source d'installation. Le parcours documenté permet à un responsable support de demander à ZCode d'installer le plugin local sans assembler manuellement un environnement Python.
Les scripts principaux utilisent la bibliothèque standard Python ; la génération directe de PDF nécessite une dépendance facultative. Le code comprend des chemins pour macOS, Windows et Linux ; seules des vérifications réelles sur macOS sont actuellement consignées, notamment collecte de fils, téléchargement des pièces jointes, rapports et aller-retour dans la base de connaissances. La prise en charge de Windows et Linux est implémentée, mais les notes demandent encore des tests réels sur ces systèmes.
Ce qui est construit et ce qui reste à faire
C'est une première implémentation avec des éléments fonctionnels et du travail inachevé. Les notes de validation prouvent des vérifications précises, pas une exploitation à grande échelle, une adoption ou des gains de temps mesurés. Couverture de collecte, fraîcheur du cache, comportement multiplateforme et règles applicables à la recherche communautaire automatisée nécessitent encore du travail avant un déploiement plus large. Je préfère nommer ces limites.
C'est le travail d'ingénierie que je veux faire : partir d'un problème opérationnel, choisir un processus adapté, construire les outils et limiter les affirmations aux preuves. Le souhait de mieux comprendre les utilisateurs est devenu un système qui transforme leurs retours en priorités produit vérifiables.
Quand une équipe décide de ce qui mérite son attention, elle doit pouvoir expliquer pourquoi.
Note de publication
Roman décrit les fonctions du projet et les vérifications consignées ; ces tests produit n'ont pas été reproduits indépendamment. La documentation publique de ZCode confirme le mécanisme des plugins et des marketplaces locales, pas les résultats du projet ni sa conformité aux règles de la plateforme.