Wie man KI-Agenten über die CLI steuert: ein praktischer Leitfaden

Warum man einen Agenten überhaupt von der Kommandozeile aus steuern sollte

Ich baue beruflich Integrationen, also gebe ich meine Voreingenommenheit zu: Ich führe lieber etwas von einem Terminal aus aus, als mich durch eine Einstellungsseite zu klicken, die ich jedes Quartal neu lernen muss. Aber der Fall hier ist größer als persönlicher Geschmack.

Ein Dashboard ist ein guter Ort, um einen Agenten zu verstehen. Es ist ein schlechter Ort, um einen in irgendeiner Größenordnung zu betreiben. In dem Moment, in dem du dieselbe Änderung auf drei Agenten anwenden willst, oder eine Konfiguration, die in einem Git-Repo neben deiner übrigen Infrastruktur lebt, oder einen Rollout, den ein CI-Job ohne einen Menschen ausführen kann, wird der Browser zum Flaschenhals. Alles, was du von Hand machst, ist ein Schritt, den du nicht sauber wiederholen, überprüfen oder zurückrollen kannst.

Die Kommandozeile behebt das, indem sie Agenten-Operationen in Text verwandelt. Ein Befehl, den du in ein Runbook einfügen kannst. Eine Konfiguration, die du diffen kannst. Ein Durchlauf, den du von einem Cron-Job oder einem Webhook auslösen kannst. Und, zunehmend, eine Oberfläche, die ein anderer KI-Agent bedienen kann — genau deshalb sagt die Dokumentation von eesel Coding-Agenten, sie sollen die CLI nutzen, statt in einem Browser im Dashboard herumzuklicken.

Der Rest dieses Leitfadens geht diese Schleife Schritt für Schritt durch. Ich verwende die CLI von eesel für die konkreten Befehle, weil ich weiß, dass sie real ist und ich dich auf die Dokumentation verweisen kann, aber das Prinzip gilt für jede Agenten-Plattform, die das Terminal ernst nimmt.

Was du brauchst, bevor du anfängst

Drei Dinge, und keines davon dauert lange.

• Ein aktuelles Node.js. Die CLI von eesel benötigt Node 18.17 oder neuer. Die meisten Maschinen, die in den letzten paar Jahren gebaut wurden, haben das bereits.
• Eine Agenten-Plattform mit einer echten CLI. Das ist der Punkt, den du sorgfältig prüfen solltest. Viele Tools werben mit „entwicklerfreundlich" und geben dir dann eine Einstellungsseite. Suche nach veröffentlichter CLI-Dokumentation mit einer echten Befehlsliste, bevor du dich festlegst.
• Eine zu verbindende Datenquelle. Für einen Support-Agenten bedeutet das ein Helpdesk, eine Wissensdatenbank oder vergangene Tickets. Der Agent ist nur so gut wie das, was er lesen kann.

Du brauchst nicht zwingend ein Konto, um zu starten. Die CLI von eesel kann einen anonymen Workspace hochfahren, sodass du eine Bubble auf einer Website ganz ohne Anmeldung testen kannst — eine schöne Möglichkeit, den gesamten Ablauf zu sehen, bevor du dich für irgendetwas entscheidest.

Schritt 1: die CLI installieren und einloggen

Es gibt drei Wege, an die CLI von eesel zu kommen, und sie passen zu drei unterschiedlichen Situationen.

Wenn du es einfach ohne jede Verpflichtung an einer Website ausprobieren willst:

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

Das läuft ohne Konto und richtet einen anonymen Workspace ein. Wenn du es wirklich installieren willst, hole es entweder global von npm:

npm i -g @eesel/cli

oder nutze das Install-Skript:

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

Sobald es installiert ist, authentifiziere dich:

eesel login
eesel whoami

eesel login öffnet einmal den Browser, um das Terminal mit deinem Workspace zu verknüpfen, und whoami bestätigt, mit welchem Konto und Agenten du gerade verbunden bist. Von hier an kannst du im Terminal bleiben.

Ein Detail, das für alle wichtig ist, die das skripten: Jeder Befehl gibt JSON aus, und Listen geben ein Objekt pro Zeile aus. Das bedeutet, du kannst die Ausgabe direkt in jq oder ein Skript pipen, ohne menschenlesbaren Text zu parsen. Du kannst die Ausgabe auch mit --fields eingrenzen (zum Beispiel --fields id,status), sodass ein Skript nur die Schlüssel sieht, die es braucht.

Schritt 2: einen Helpdesk oder eine Datenquelle verbinden

Ein Agent ohne irgendetwas zu lesen ist ein Partytrick. Das Erste, was du wirklich tust, ist, ihm eine Quelle zu geben.

eesel integrations connect zendesk

Ersetze zendesk durch die Plattform, die du nutzt. eesel verbindet sich mit Zendesk, Freshdesk, Gorgias, Front, Help Scout, HubSpot, Salesforce und Jira Service Management, unter anderen. Der Befehl übernimmt den OAuth-Handshake und meldet zurück, wenn die Quelle aktiv ist.

Überprüfe jederzeit den Status:

eesel status

status sagt dir, was verbunden ist, was der Agent weiß und ob noch etwas synchronisiert. Es ist der Befehl, den ich am häufigsten ausführe, weil er die einzige Frage beantwortet, die mitten im Setup wirklich zählt: Ist das Ding tatsächlich bereit.

Schritt 3: die Anweisungen des Agenten festlegen

Hier wird „Steuerung" real. Die Anweisungen sind die feststehenden Regeln, denen der Agent folgt: Tonfall, was er beantworten darf, wann er eskalieren soll, welche Aktionen er eigenständig ausführen kann.

eesel instructions

Das liest die aktuellen Anweisungen, sodass du genau siehst, unter welchen Bedingungen der Agent arbeitet, und lässt dich sie bearbeiten. Weil es Text ist, kannst du deine Anweisungen in einer Datei unter Versionskontrolle halten und eine Änderung im Verhalten des Agenten wie jede andere überprüfte Änderung behandeln, mit einem Diff und einer Historie, statt einer mysteriösen Bearbeitung, die vor drei Wochen jemand in einem Einstellungsfenster gemacht hat.

Wenn du dir eine Gewohnheit aus diesem Leitfaden mitnimmst, dann diese. Dass sich das Verhalten eines Agenten verändert, weil niemand sehen kann, wer was geändert hat, ist die häufigste Art, wie diese Rollouts leise schiefgehen.

Schritt 4: simulieren, bevor du ihn loslässt

Hier ist der Teil, den die meisten Leute überspringen, und der Teil, für den ich kämpfen würde.

Wir haben Jahre damit verbracht, KI-Agenten auf Live-Support-Warteschlangen einzusetzen, und die Lektion, die hängen geblieben ist, lautet: Ein selbstbewusst klingender Bot ist nicht dasselbe wie ein korrekter. Ein Modell gibt bereitwillig eine falsche Antwort mit beruhigender Stimme. Der einzige Weg, das zu erwischen, bevor es ein Kunde tut, ist, es zuerst gegen die Realität zu testen.

eesel macht das als Simulation, die deine vergangenen Tickets abspielt und die Antworten des Agenten gegen das bewertet, was dein Team tatsächlich geschickt hat. Du rufst es auf, indem du zum Beispiel bittest, eine Simulation an deinen letzten Tickets auszuführen. Es liefert zurück, wo der Agent mit deinem Team übereingestimmt hätte, wo er danebengelegen hätte, und was in den Anweisungen zu ändern ist. Eine Sache, die es bewusst nicht tut, ist, eine Lösungsquote oder eine Kostenprognose zu erfinden — und ich wäre bei jedem Tool vorsichtig, das das behauptet, weil diese Zahl eine als Messung verkleidete Vermutung ist.

Führe die Simulation aus, lies die Lücken, korrigiere die Anweisungen aus Schritt 3 und führe sie erneut aus. Diese Schleife ist der ganze Sinn, das vom Terminal aus zu tun: Jeder Durchlauf ist ein Befehl, den du wiederholen kannst, kein Klick-Durchlauf, den du dir merken musst.

Schritt 5: Durchläufe auslösen und das Aktivitätsprotokoll lesen

Jetzt betreibst du ihn. Sprich direkt mit dem Agenten:

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

Und lies, was er getan hat, neueste zuerst:

eesel activity

eesel activity ist die Beobachtungsoberfläche. Sie listet Durchläufe auf, sodass du Muster erkennen kannst, und du kannst einen einzelnen Durchlauf öffnen, um genau zu sehen, was der Agent gelesen, entschieden und getan hat. Wenn etwas seltsam aussieht, ist das die erste Stelle, an der du nachsiehst. Auch Fehler sind strukturiert: Ein fehlgeschlagener Befehl gibt eine einzelne JSON-Zeile auf stderr aus, mit einem error, einem hint und ob er retryable ist, und beendet sich mit einem Exit-Code ungleich null. Das ist es, was die CLI sicher genug macht, um sie in einen CI-Job einzubinden. Ein Skript kann den Unterschied erkennen zwischen „du hast den Befehl falsch eingetippt" und „der Dienst hatte einen Aussetzer, versuch es noch mal."

Schritt 6: Aktionen mit Freigaben absichern

Du musst dich nicht zwischen einem vollständig autonomen Agenten und einem nutzlosen entscheiden. Der Mittelweg ist eine Human-in-the-Loop-Freigabewarteschlange, und sie ist ein vollwertiges Feature der Kommandozeile.

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

Wenn der Agent eine Aktion ausführen will, der du noch nicht vollständig vertraust, landet sie in der Freigabewarteschlange, statt einfach zu passieren. Du überprüfst sie vom Terminal aus und genehmigst oder lehnst sie ab. Sobald sich eine bestimmte Art von Aktion dein Vertrauen verdient hat, kannst du sie zur automatischen befördern:

eesel approvals approve <id> --always

So drehst du die Autonomie schrittweise hoch, statt einen beängstigenden Schalter umzulegen. Beginne damit, dass alles abgesichert ist, beobachte, was der Agent vorschlägt, und nutze --always, um die Aktionen zu übergeben, bei denen du gesehen hast, dass er richtig liegt — eine Kategorie nach der anderen.

Jenseits der CLI: die anderen drei Steuerungsoberflächen

Die CLI ist die Oberfläche, in der du leben wirst, aber sie ist nicht der einzige Weg, den Agenten zu steuern. Es hilft, das Gesamtbild zu sehen, weil jede eine andere Frage beantwortet.

• MCP-Server, für den Fall, dass eine andere KI der Bediener ist. Jeder eesel-Workspace ist auch ein MCP-Server. Wenn du npx @eesel/cli mcp token ausführst, erhältst du eine URL, ein 30-Tage-Token und einen einfügefertigen claude mcp add-Befehl, sodass ein Client wie Claude dieselben Operationen wie Tools aufrufen kann. So lässt du einen Coding-Agenten deinen Support-Agenten verwalten.
• Webhooks, für den Fall, dass ein externes Ereignis den Agenten steuern soll. Eine eindeutige Webhook-URL weckt den Agenten, wenn anderswo in deinem Stack etwas passiert, sodass eine neue Bestellung oder ein Formular-Absenden einen Durchlauf auslösen kann, ohne dass jemand einen Befehl eintippt.
• Network Access, für den Fall, dass der Agent nach außen greifen muss. Du gibst eine Domain frei und hängst einen Auth-Header an, und der Agent kann diese REST-API dann während eines Durchlaufs mit GET, POST, PATCH oder DELETE aufrufen. Anmeldedaten werden als Header gespeichert und dem Modell nie angezeigt — das Detail, nach dem dein Sicherheitsteam fragen wird.

Für Headless-Umgebungen überspringst du den interaktiven Login komplett: Setze EESEL_API_URL und EESEL_API_TOKEN (und EESEL_AGENT_ID, um einen bestimmten Agenten festzulegen) als Umgebungsvariablen, und die CLI authentifiziert sich daraus. Das ist es, was sie sauber in eine CI-Pipeline einfügen lässt.

Häufige Fehler, die du vermeiden solltest

Ein paar Dinge, die ich Leute habe stolpern sehen, damit du dir die Lektion sparen kannst:

• Live gehen, ohne zu simulieren. Der teuerste Fehler auf dieser Liste. Führe Schritt 4 aus. Jedes Mal.
• Anweisungen in Eile von Hand bearbeiten. Wenn das Verhalten deines Agenten nicht unter Versionskontrolle steht, wirst du irgendwann einen Ausfall haben, den niemand erklären kann. Behandle die Ausgabe von eesel instructions wie Code.
• Volle Autonomie am ersten Tag einschalten. Beginne damit, dass alles in der Freigabewarteschlange steht, und verdiene dir jede --always-Beförderung. Vertrauen entsteht eine Aktionskategorie nach der anderen.
• Die Exit-Codes ignorieren. Die CLI liefert aus gutem Grund strukturierte Fehler und Exit-Codes ungleich null. Ein Skript, das sie nicht prüft, marschiert fröhlich an einem Fehlschlag vorbei.
• Annehmen, dass eine REST-API existiert. Wenn du einen Anbieter evaluierst und dein Plan von einem dokumentierten REST-Endpunkt abhängt, bestätige, dass er existiert, bevor du darauf aufbaust. Bei eesel lautet die ehrliche Antwort, dass CLI, MCP, Webhooks und Network Access die Oberfläche sind, und das reicht völlig aus, um einen Agenten zu steuern — nur eben nicht dasselbe wie ein REST-Produkt.

eesel ausprobieren

Wenn du einen Support-Agenten willst, den du wirklich vom Terminal aus betreiben kannst, ist eesel genau dafür gebaut. Die CLI installiert sich mit einem Befehl, verbindet sich mit dem Helpdesk, den du bereits nutzt, simuliert an deinen echten vergangenen Tickets, bevor sie eine Live-Konversation berührt, und hält jede Aktion hinter einer Freigabewarteschlange, bis du etwas anderes sagst. Die Preisgestaltung basiert auf der Nutzung mit 40 Cent pro bearbeitetem Ticket, und die kostenlose Testphase enthält 50 Dollar Nutzungsguthaben ohne Kreditkarte, sodass du den gesamten Rollout skripten und ihn in Aktion sehen kannst, bevor du etwas ausgibst.