danghuangshang : un système multi-agents calqué sur la bureaucratie impériale chinoise

Le problème visé : donner un cadre à plusieurs agents qui doivent se coordonner

Faire tourner un seul agent conversationnel est simple. En faire travailler plusieurs sur une même tâche pose une autre question : qui reçoit la demande, qui la reformule, qui l'exécute, et qui vérifie le résultat. danghuangshang répond à cette question en plaçant une hiérarchie nommée au-dessus d'OpenClaw, le framework d'agents sur lequel le projet s'appuie. Le README présente le principe ainsi : l'utilisateur est l'empereur, les agents sont les ministres, et une mention sur Discord ou Feishu suffit à déclencher l'exécution. Le public visé est donc celui qui veut un modèle d'organisation prêt à l'emploi plutôt qu'un ensemble d'agents à câbler soi-même. Le projet fournit dix-huit agents dans le régime par défaut, avec plus de soixante compétences annoncées. La valeur revendiquée tient moins à la performance brute qu'à la répartition des rôles : chaque agent porte un nom de ministère et une fonction associée, ce qui rend la délégation lisible sans avoir à inventer une nomenclature. C'est un choix éditorial autant que technique, et il faut l'accepter pour trouver le projet utile.

Trois régimes, un même socle d'orchestration

Le dépôt ne propose pas une architecture unique mais trois variantes, sélectionnables à l'installation. Le régime Ming, celui par défaut, enchaîne un premier agent (司礼监, le service intérieur) qui reçoit la demande, un second (内阁, le cabinet) qui enrichit le prompt et produit un plan, puis les six ministères qui exécutent selon ce plan. Un organe de contrôle (都察院) intervient séparément sur les push GitHub pour relire le code. Le régime Tang remplace cette chaîne par trois étapes distinctes : rédaction, examen, exécution. Le régime d'entreprise moderne adopte une hiérarchie CEO, conseil, puis directions fonctionnelles, avec une communication en anglais. Les trois partagent le même socle OpenClaw et le même mode de déclenchement par mention. Le changement de régime ne demande pas de réinstallation complète : un script dédié réécrit la configuration. Ce découpage en trois propositions plutôt qu'une seule montre que le projet assume une part de préférence organisationnelle dans son design, ce qui est rare dans ce type d'outil et mérite d'être signalé.

Deux modes de commandement, et une différence de coût qui n'est pas documentée

Le README décrit deux façons d'adresser les agents. La première passe par l'orchestrateur central : la demande est reçue, transmise au cabinet pour enrichissement, puis distribuée aux ministères concernés selon le plan produit. La seconde consiste à mentionner directement le bot du ministère voulu, ce qui saute l'étape d'enrichissement. La documentation recommande le chemin central pour les tâches complexes et la mention directe pour les tâches simples, au motif que le second est plus rapide. Ce raisonnement est plausible, mais le dépôt ne fournit aucun chiffre sur le surcoût en jetons ou en latence de l'étape d'enrichissement. Il faut donc traiter cette recommandation comme une heuristique, pas comme un résultat mesuré. Autre point que le README ne tranche pas : ce qui se passe lorsque le plan produit par le cabinet désigne un ministère qui n'existe pas dans le régime actif, ou lorsque deux ministères reçoivent des instructions contradictoires. Le mécanisme d'arbitrage n'est pas décrit dans les extraits disponibles.

Installation : quatre scripts, un choix à faire avant de commencer

L'installation locale tient en trois commandes : cloner le dépôt, entrer dans le répertoire, lancer le script d'installation complet. Une variante distante évite le clone en récupérant le script directement, et une variante allégée s'adresse à ceux qui ont déjà OpenClaw et ne veulent que les modèles de configuration. Le README précise que les trois incluent l'injection des personnalités des agents, ce qui suggère que ce n'est pas toujours le cas ailleurs. Une quatrième voie est proposée pour faire tourner le même paramétrage sur un runtime différent, Hermes Agent, en Python, les deux pouvant coexister. Le changement de régime se fait ensuite par un script qui prend le nom du régime en argument. Deux avertissements méritent attention. Le premier concerne une ancienne version du script d'installation, qui échoue en exécution distante à cause d'une erreur de chemin ; il faut utiliser le script actuel ou passer par un clone. Le second, plus sérieux, porte sur la configuration Discord : la valeur par défaut limite les réponses entre bots aux mentions, et le README interdit explicitement d'activer la réponse à tous les messages, sous peine de boucle entre bots.

Ce que la documentation ne permet pas de vérifier

Le dépôt annonce un déploiement en cinq minutes et une installation en une commande. Ces chiffres viennent du README et n'ont pas été reproduits ici. Plus gênant pour un lecteur technique : la manière dont les agents partagent leur état n'est pas décrite dans les extraits fournis. Le README mentionne une mémoire et des tâches planifiées parmi les capacités, sans expliquer si cette mémoire est commune à tous les agents ou propre à chacun, ni comment les conflits d'écriture sont gérés. De même, l'organe de contrôle est présenté comme déclenché automatiquement lors d'un push GitHub, mais le mécanisme de déclenchement, webhook ou surveillance de dépôt, n'apparaît pas. Une note de version mentionne l'ajout d'une vérification de signature sur les webhooks, ce qui suggère que ce chemin existe, sans lever l'ambiguïté. Enfin, le projet consacre une part notable de son README à une mise au point sur l'originalité de l'architecture et sur un dépôt tiers jugé similaire. C'est une information légitime sur l'historique du projet, mais elle occupe un espace qui aurait pu servir à documenter le routage.

Alternatives : orchestration écrite à la main ou cadre générique

Deux approches se distinguent nettement. La première consiste à écrire soi-même l'orchestration au-dessus d'un framework d'agents : on garde le contrôle total sur le routage, les conditions d'arrêt et le format des échanges entre agents, au prix d'un travail de conception et de maintenance qui n'est pas négligeable. La seconde consiste à utiliser un cadre générique de type CrewAI ou AutoGPT, cités dans le README à titre de comparaison. La différence tient à la nature de ce qui est fourni. Un cadre générique donne des primitives : définir un agent, lui donner des outils, décrire une séquence. danghuangshang donne une organisation déjà nommée et peuplée, avec des rôles qui correspondent à des fonctions reconnaissables. On gagne du temps sur la conception, on perd de la souplesse sur la forme. Si votre flux de travail ne ressemble pas à une chaîne de validation hiérarchique, la métaphore impériale devient un habillage sans effet sur le comportement réel des agents, et un cadre générique sera plus direct.

Licence, mises à jour et coût de maintenance

Le projet est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver la notice de licence. Le README insiste sur ce point et demande de citer l'origine en cas de fork, ce qui relève de la courtoisie communautaire et non d'une obligation supplémentaire de la MIT. Sur les mises à jour, le dépôt fournit un script de mise à jour qui sauvegarde la configuration avant de tirer les changements, et documente une procédure manuelle à base de stash et de pull. Le README signale une limite importante : la sauvegarde automatique couvre le fichier de configuration principal, mais pas les fichiers d'espace de travail, qui doivent être sauvegardés à la main. La dernière version publiée est la v3.0, datée de mars 2026, et le dernier push observé sur la branche principale est postérieur de deux mois. Le coût de maintenance réel dépend donc surtout de la fréquence à laquelle vous modifiez les fichiers de mémoire des agents, puisque ce sont eux qui échappent à la sauvegarde automatique.

Conclusion éditoriale

danghuangshang convient à ceux qui veulent une structure de rôles prête à l'emploi pour plusieurs agents sur Discord, avec un vocabulaire administratif cohérent. Ceux qui ont besoin d'un routage déterministe entre agents, ou d'une documentation détaillée sur le mécanisme d'orchestration, devraient d'abord lire docs/README.md et le contenu de scripts/full-install.sh avant de lancer l'installation.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. wanikua/danghuangshang on GitHub