mercury-agent : un agent IA qui demande la permission avant d'agir

Le problème que Mercury attaque : l'agent qui agit sans demander

La plupart des agents capables de lire des fichiers, lancer des commandes et récupérer des URL le font sans validation intermédiaire. Mercury part du principe inverse. Le README le formule ainsi : la plupart des agents agissent en silence, Mercury demande d'abord et retient ce qui compte. Concrètement, cela se traduit par une blocklist shell (sudo, rm -rf / et d'autres commandes ne s'exécutent jamais), un cadrage lecture/écriture au niveau des dossiers, et un flux d'approbation en attente. Au démarrage, l'interface Ink demande de choisir entre Ask Me et Allow All pour la session en cours. Le public visé est donc l'ingénieur qui veut un agent réellement actif sur sa machine, mais qui ne veut pas lui donner un accès shell sans garde-fou. Ce n'est pas un assistant de chat générique : c'est un exécutant avec des permissions explicites.

Une mémoire structurée plutôt qu'un historique de conversation

Mercury décrit sa Second Brain comme une mémoire persistante et structurée reposant sur SQLite et la recherche plein texte FTS5. Le README mentionne dix types de mémoire, une extraction automatique, une résolution de conflits et une consolidation automatique. L'idée est que l'agent retienne des préférences, des objectifs et des habitudes sans saisie manuelle. C'est un choix architectural qui a un coût : la mémoire vit dans une base SQLite locale, donc la qualité de ce que l'agent retient dépend de son extraction automatique, pas d'une relecture humaine. Le README ne détaille pas comment les conflits sont arbitrés ni quel type de mémoire gagne en cas de contradiction. Si vous avez besoin d'auditer précisément ce que l'agent a mémorisé et pourquoi, cette partie reste à vérifier dans le code.

Soul, persona, taste, heartbeat : la personnalité dans des fichiers markdown

Mercury définit sa personnalité par des fichiers markdown que l'utilisateur possède : soul.md, persona.md, taste.md et heartbeat.md. Le README parle de soul-driven et précise qu'il n'y a pas d'enveloppe corporate. C'est un choix éditorial fort : le comportement de l'agent n'est pas figé dans le binaire, il est lisible et modifiable. En contrepartie, rien n'indique dans le matériel fourni qu'une validation ou un schéma encadre ces fichiers. Un soul.md mal écrit se traduit directement par un comportement inattendu, sans couche intermédiaire. Pour un usage personnel, c'est un avantage. Pour un déploiement en équipe, cela signifie que la personnalité de l'agent est un artefact de configuration à versionner et à relire comme n'importe quel autre fichier de configuration.

Budget de tokens et passage automatique en mode concis

Mercury applique un budget quotidien de tokens et devient automatiquement concis au-delà de 70 pour cent de consommation. La commande /budget affiche l'état, et /budget override permet de passer outre. Deux points méritent l'attention. D'abord, le seuil de 70 pour cent est une politique intégrée, pas un réglage documenté dans le matériel fourni. Ensuite, le mécanisme de concision n'est pas décrit : on ne sait pas s'il tronque l'historique, résume, ou change les instructions système. Pour un agent qui tourne 24/7, cette limite est ce qui évite la facture qui dérape, mais elle peut aussi dégrader la qualité des réponses au moment où vous en avez le plus besoin. La commande /budget override existe précisément pour ces cas, ce qui suppose de la surveiller.

Installation et mise en route : les commandes réelles

Le README donne trois voies. Un installeur sans Node.js, avec curl -fsSL https://mercuryagent.sh/install.sh | sh sous macOS et Linux, ou irm https://mercuryagent.sh/install.ps1 | iex sous Windows. Une exécution directe via npx @cosmicstack/mercury-agent si Node.js 20 ou plus est présent. Une installation globale avec npm i -g @cosmicstack/mercury-agent puis la commande mercury. Le premier lancement déclenche l'assistant de configuration (nom, fournisseur, Telegram en option), puis l'écran de démarrage Ink demande le mode de permission. Pour reconfigurer plus tard : mercury doctor, et mercury doctor --platform pour les diagnostics de compatibilité terminal et démon. Le mode démon tient en une commande, mercury up, qui installe le service système s'il n'existe pas, démarre le démon et vérifie qu'il tourne. Les autres commandes sont mercury restart, mercury stop, mercury start -d, mercury logs et mercury status. L'installation du service diffère selon la plateforme : LaunchAgent sous macOS, unité systemd utilisateur sous Linux, Task Scheduler sous Windows. Aucune ne demande de droits administrateur, mais Linux a besoin de linger pour démarrer au boot.

Le mode démon déplace le centre de gravité vers Telegram

C'est la contrainte la plus concrète du projet. En mode démon, le README indique que Telegram devient le canal principal et que la CLI passe en lecture de logs, faute de terminal pour l'entrée. Autrement dit, lancer mercury up revient à choisir Telegram comme interface, ou à renoncer à piloter l'agent depuis la ligne de commande. La gestion des accès Telegram est explicite : mercury telegram list, approve, reject, remove, promote, demote et reset. Le flux d'appairage par code suggère qu'un utilisateur inconnu ne peut pas parler à l'agent sans validation. La reprise après plantage est intégrée, avec un redémarrage automatique et un backoff exponentiel plafonné à dix redémarrages par minute. Ce plafond signifie qu'une boucle de crash persistante finit par s'arrêter, ce qui est sain, mais laisse l'agent hors service jusqu'à intervention.

Les skills et le fichier web-search semé au premier lancement

Mercury s'appuie sur la spécification Agent Skills et permet d'installer des skills communautaires en une commande, puis de les planifier comme tâches récurrentes. Au premier lancement, le README précise qu'un skill web-search par défaut est créé dans ~/.mercury/skills/web-search/SKILL.md. Ce fichier mérite un coup d'œil avant toute utilisation en production : c'est du contenu exécutable par l'agent, installé sans que vous l'ayez écrit. Les commandes /skills et /tools, utilisables en conversation sans consommer de tokens API, permettent de lister ce qui est chargé. Le point faible de cette architecture est la provenance : installer un skill communautaire revient à introduire du code ou des instructions dans un agent qui a accès au shell et aux fichiers. Le cadrage par dossiers limite les dégâts, il ne les supprime pas.

Alternatives et cas où Mercury n'est pas le bon outil

Si vous voulez seulement dialoguer avec un modèle depuis un terminal, un client de chat en CLI comme les interfaces TUI adossées à un fournisseur unique fait le travail sans démon, sans service système et sans base SQLite. La différence d'approche est nette : Mercury suppose un agent persistant qui agit sur la machine et doit donc être freiné par des permissions, là où un client de chat ne dispose d'aucun outil et n'a rien à freiner. À l'inverse, si vous voulez un agent qui exécute des actions sans interruption, le mode Allow All de Mercury vous donnera ce comportement, mais vous perdez alors l'argument central du projet. Mercury est aussi un mauvais choix si vous ne pouvez pas faire tourner un processus en arrière-plan : le mode démon et le service système sont au cœur de son fonctionnement, et le README ne décrit pas d'usage purement éphémère au-delà de mercury start en avant-plan.

Maintenance, licence et coût de mise à jour

Le dépôt n'est pas archivé et le dernier push date du 9 septembre 2026, avec une version 1.2.3 publiée la veille. Le rythme des versions récentes montre des correctifs cross-platform et une évolution liée au cloud entre la 1.2.2 et la 1.2.3, ce qui indique un projet actif mais encore en mouvement. La commande mercury upgrade gère la montée de version. Le coût réel se situe ailleurs : une base SQLite de mémoire, des fichiers de personnalité markdown et des skills installés dans ~/.mercury forment un état local qu'il faut sauvegarder et migrer. Le projet est sous licence MIT, ce qui autorise l'usage commercial et la modification, avec l'obligation de conserver l'avis de licence. Cela ne dit rien de la licence des skills communautaires que vous installez, ni de celle des modèles que vous branchez : ces deux points doivent être vérifiés séparément, et je ne peux pas me prononcer sur leur compatibilité à partir du matériel fourni.

Conclusion éditoriale

Adoptez Mercury si vous voulez un agent qui exécute des commandes shell et lit des fichiers sans le faire silencieusement, et si vous acceptez de gérer un démon avec un service système. Évitez-le si vous cherchez un simple client de chat en terminal ou si vous refusez qu'un agent écrive dans un dossier sans validation. Avant de l'installer, vérifiez le contenu de ~/.mercury/skills/web-search/SKILL.md et testez mercury doctor --platform pour confirmer la compatibilité de votre terminal et de votre gestionnaire de services.

Sources officielles

1. cosmicstack-labs/mercury-agent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases