Comment contrôler des agents IA depuis la CLI : un guide pratique

Pourquoi contrôler un agent depuis la ligne de commande, déjà

Je construis des intégrations pour gagner ma vie, donc j'assume mon biais : je préfère exécuter quelque chose depuis un terminal plutôt que cliquer dans une page de paramètres que je dois réapprendre chaque trimestre. Mais l'argument ici dépasse le goût personnel.

Un tableau de bord est un bon endroit pour comprendre un agent. C'est un mauvais endroit pour en exploiter un à n'importe quelle échelle. Dès que vous voulez appliquer le même changement à trois agents, ou une configuration qui vit dans un dépôt Git à côté du reste de votre infrastructure, ou un déploiement qu'un job CI peut exécuter sans humain, le navigateur devient le goulot d'étranglement. Tout ce que vous faites à la main est une étape que vous ne pouvez pas répéter, réviser ou annuler proprement.

La ligne de commande règle cela en transformant les opérations de l'agent en texte. Une commande que vous pouvez coller dans un runbook. Une configuration que vous pouvez diffuser. Une exécution que vous pouvez déclencher depuis un cron job ou un webhook. Et, de plus en plus, une surface qu'un autre agent IA peut piloter, ce qui explique exactement pourquoi la documentation d'eesel dit aux agents de codage d'utiliser la CLI plutôt que d'essayer de cliquer dans le tableau de bord depuis un navigateur.

Le reste de ce guide parcourt cette boucle étape par étape. J'utiliserai la CLI d'eesel pour les commandes concrètes, car c'est celle dont je sais qu'elle est réelle et pour laquelle je peux vous renvoyer vers la documentation, mais la logique s'applique à toute plateforme d'agents qui prend le terminal au sérieux.

Ce dont vous avez besoin avant de commencer

Trois choses, et aucune ne prend longtemps.

• Un Node.js récent. La CLI d'eesel a besoin de Node 18.17 ou plus récent. La plupart des machines construites ces dernières années l'ont déjà.
• Une plateforme d'agents avec une véritable CLI. C'est le point à vérifier soigneusement. Beaucoup d'outils se présentent comme « conçus pour les développeurs » puis vous remettent une page de paramètres. Cherchez une documentation de CLI publiée avec une véritable liste de commandes avant de vous engager.
• Une source de données à connecter. Pour un agent de support, cela signifie un helpdesk, une base de connaissances, ou d'anciens tickets. L'agent ne vaut que ce qu'il peut lire.

Vous n'avez pas nécessairement besoin d'un compte pour commencer. La CLI d'eesel peut faire démarrer un espace de travail anonyme pour que vous testiez une bulle sur un site web sans aucune inscription, ce qui est une bonne façon de voir tout le déroulement avant de décider quoi que ce soit.

Étape 1 : installer la CLI et se connecter

Il existe trois façons d'obtenir la CLI d'eesel, et elles correspondent à trois situations différentes.

Si vous voulez simplement l'essayer sur un site web sans aucun engagement :

npx @eesel/cli init chat-bubble --site https://your-site.com

Cela s'exécute sans compte et fait démarrer un espace de travail anonyme. Si vous voulez l'installer pour de bon, récupérez-la globalement depuis npm :

npm i -g @eesel/cli

ou utilisez le script d'installation :

curl -fsSL https://dashboard.eesel.ai/eesel-cli/install | sh

Une fois installée, authentifiez-vous :

eesel login
eesel whoami

eesel login ouvre le navigateur une fois pour lier le terminal à votre espace de travail, et whoami confirme le compte et l'agent auxquels vous êtes rattaché. À partir de là, vous pouvez rester dans le terminal.

Un détail qui vaut la peine d'être signalé pour quiconque scripte cela : chaque commande imprime du JSON, et les listes impriment un objet par ligne. Cela signifie que vous pouvez rediriger la sortie directement vers jq ou vers un script sans avoir à extraire du texte lisible par un humain. Vous pouvez aussi restreindre la sortie avec --fields (par exemple --fields id,status) pour qu'un script ne voie que les clés dont il a besoin.

Étape 2 : connecter un helpdesk ou une source de données

Un agent sans rien à lire n'est qu'un tour de magie. La première chose réelle que vous faites, c'est lui donner une source.

eesel integrations connect zendesk

Remplacez zendesk par la plateforme que vous utilisez. eesel se connecte à Zendesk, Freshdesk, Gorgias, Front, Help Scout, HubSpot, Salesforce, et Jira Service Management, entre autres. La commande gère la poignée de main OAuth et signale quand la source est active.

Vérifiez l'état à tout moment :

eesel status

status vous indique ce qui est connecté, ce que l'agent connaît, et si quelque chose est encore en cours de synchronisation. C'est la commande que j'exécute le plus, parce qu'elle répond à la seule question qui compte en pleine configuration : est-ce que c'est vraiment prêt.

Étape 3 : définir les instructions de l'agent

C'est ici que le « contrôle » devient concret. Les instructions sont les règles permanentes que suit l'agent : le ton, ce qu'il est autorisé à répondre, quand il doit escalader, quelles actions il peut prendre de son propre chef.

eesel instructions

Cela lit les instructions actuelles pour que vous voyiez exactement sous quelles règles l'agent fonctionne, et vous permet de les modifier. Comme c'est du texte, vous pouvez conserver vos instructions dans un fichier sous contrôle de version et traiter un changement de comportement de l'agent comme n'importe quel autre changement révisé, avec un diff et un historique, plutôt qu'une modification mystérieuse faite par quelqu'un dans un panneau de paramètres trois semaines plus tôt.

Si vous ne retenez qu'une seule habitude de ce guide, que ce soit celle-ci. Le comportement d'un agent qui dérive parce que personne ne peut voir qui a changé quoi est la façon la plus courante dont ces déploiements dérapent silencieusement.

Étape 4 : simuler avant de le lâcher

Voici la partie que la plupart des gens sautent, et celle pour laquelle je me battrais.

Nous avons passé des années à déployer des agents IA sur des files de support en direct, et la leçon qui est restée, c'est qu'un bot qui semble sûr de lui n'est pas la même chose qu'un bot correct. Un modèle donnera volontiers une mauvaise réponse d'une voix rassurante. La seule façon de le repérer avant qu'un client ne le fasse, c'est de le tester d'abord contre la réalité.

eesel fait cela sous forme de simulation qui rejoue vos anciens tickets et note les réponses de l'agent par rapport à ce que votre équipe a réellement envoyé. Vous l'invoquez en demandant, par exemple, d'exécuter une simulation sur vos tickets récents. Elle vous indique où l'agent aurait correspondu à votre équipe, où il aurait manqué, et quoi changer dans les instructions. Une chose qu'elle ne fait délibérément pas, c'est inventer un taux de résolution ou une prévision de coût, et je me méfierais de tout outil qui prétend le faire, parce que ce chiffre est une estimation déguisée en mesure.

Exécutez la simulation, lisez les écarts, corrigez les instructions de l'étape 3, et relancez-la. Cette boucle est tout l'intérêt de faire cela depuis le terminal : chaque passage est une commande que vous pouvez répéter, pas un parcours de clics dont vous devez vous souvenir.

Étape 5 : déclencher des exécutions et lire le journal d'activité

Maintenant, vous l'exploitez. Parlez directement à l'agent :

eesel chat "Where is my order #DL-4821?"

Et lisez ce qu'il a fait, du plus récent au plus ancien :

eesel activity

eesel activity est la surface d'observabilité. Elle liste les exécutions pour que vous puissiez repérer des tendances, et vous pouvez ouvrir une exécution individuelle pour voir exactement ce que l'agent a lu, décidé et fait. Quand quelque chose semble anormal, c'est ici que vous regardez avant toute autre chose. Les erreurs aussi sont structurées : une commande échouée imprime une seule ligne JSON sur stderr avec un error, un hint, et indique si elle est retryable, puis se termine avec un code de sortie non nul. C'est ce qui rend la CLI sûre à intégrer dans un job CI. Un script peut faire la différence entre « vous avez mal tapé la commande » et « le service a eu un couac, réessayez ».

Étape 6 : verrouiller les actions avec des approbations

Vous n'avez pas à choisir entre un agent totalement autonome et un agent inutile. Le juste milieu est une file d'approbations avec un humain dans la boucle, et c'est une fonctionnalité de premier ordre en ligne de commande.

eesel approvals list
eesel approvals approve <id>
eesel approvals deny <id>

Quand l'agent veut effectuer une action à laquelle vous ne faites pas encore pleinement confiance, elle atterrit dans la file d'approbations au lieu de simplement se produire. Vous la révisez depuis le terminal et l'approuvez ou la refusez. Une fois qu'un type d'action particulier a gagné votre confiance, faites-le passer en automatique :

eesel approvals approve <id> --always

C'est ainsi que vous montez l'autonomie progressivement plutôt que d'actionner un interrupteur effrayant. Commencez avec tout verrouillé, observez ce que l'agent propose, et utilisez --always pour lui confier les actions que vous l'avez vu réussir, une catégorie à la fois.

Au-delà de la CLI : les trois autres surfaces de contrôle

La CLI est la surface dans laquelle vous vivrez, mais ce n'est pas la seule façon de piloter l'agent. Il est utile de voir l'ensemble, parce que chacune répond à une question différente.

• Serveur MCP, pour quand c'est une autre IA qui opère. Chaque espace de travail eesel est aussi un serveur MCP. Exécuter npx @eesel/cli mcp token imprime une URL, un jeton valable 30 jours, et une commande claude mcp add prête à coller, pour qu'un client comme Claude puisse appeler les mêmes opérations comme des outils. C'est ainsi que vous laissez un agent de codage gérer votre agent de support.
• Webhooks, pour quand un événement extérieur doit déclencher l'agent. Une URL de webhook unique réveille l'agent quand quelque chose se produit ailleurs dans votre pile technique, pour qu'une nouvelle commande ou l'envoi d'un formulaire puisse lancer une exécution sans que personne ne tape une commande.
• Network Access, pour quand l'agent doit joindre l'extérieur. Vous autorisez un domaine et attachez un en-tête d'authentification, et l'agent peut alors appeler cette API REST avec GET, POST, PATCH ou DELETE pendant une exécution. Les identifiants sont stockés comme en-têtes et ne sont jamais montrés au modèle, ce qui est le détail que votre équipe de sécurité demandera.

Pour les environnements headless, vous sautez entièrement la connexion interactive : définissez EESEL_API_URL et EESEL_API_TOKEN (et EESEL_AGENT_ID pour fixer un agent précis) comme variables d'environnement, et la CLI s'authentifie à partir de celles-ci. C'est ce qui lui permet de s'intégrer proprement dans un pipeline CI.

Erreurs courantes à éviter

Quelques choses que j'ai vues piéger des gens, pour que vous puissiez vous épargner la leçon :

• Passer en production sans simuler. L'erreur la plus coûteuse de cette liste. Exécutez l'étape 4. À chaque fois.
• Modifier les instructions à la main dans la précipitation. Si le comportement de votre agent n'est pas sous contrôle de version, vous finirez par avoir une panne que personne ne pourra expliquer. Traitez la sortie de eesel instructions comme du code.
• Activer l'autonomie complète dès le premier jour. Commencez avec tout dans la file d'approbations et méritez chaque promotion --always. La confiance se construit une catégorie d'action à la fois.
• Ignorer les codes de sortie. La CLI renvoie des erreurs structurées et des codes de sortie non nuls pour une raison. Un script qui ne les vérifie pas passera allègrement au-dessus d'un échec.
• Supposer qu'une API REST existe. Si vous évaluez un fournisseur et que votre plan dépend d'un point de terminaison REST documenté, confirmez qu'il existe avant de construire dessus. Avec eesel, la réponse honnête est que la CLI, le MCP, les webhooks et Network Access constituent la surface, et c'est amplement suffisant pour contrôler un agent, mais ce n'est pas la même chose qu'un produit REST.

Essayez eesel

Si vous voulez un agent de support que vous puissiez véritablement exploiter depuis le terminal, eesel est conçu pour cela. La CLI s'installe en une commande, se connecte au helpdesk que vous utilisez déjà, simule sur vos véritables anciens tickets avant de toucher à une conversation en direct, et maintient chaque action derrière une file d'approbations jusqu'à ce que vous en décidiez autrement. La tarification est basée sur l'usage, à 40 centimes par ticket traité, et l'essai gratuit inclut 50 dollars d'usage sans carte bancaire, pour que vous puissiez scripter tout le déploiement et le voir fonctionner avant de dépenser quoi que ce soit.