CLI-Designmuster für KI-Agenten: Missverständnisse und praktische Ansätze

Klarstellung zum CLI-Interface-Protokoll

Das größte Missverständnis aus Teil 1 war, dass "CLI" bedeutete, einem LLM ein Linux-Terminal zu geben. CLI ist tatsächlich ein Interface-Protokoll: Textbefehl rein → Textergebnis raus. Die Implementierung kann auf zwei Arten erfolgen:

• Als Binary oder Skript im PATH der Shell – wird zu einem CLI-Tool, das in einer echten Shell läuft
• Als Befehlsparser in deinem Code – wenn das LLM run(command="weather --city Tokyo") ausgibt, parsest du den String und führst ihn direkt in deinem Anwendungscode aus, ohne dass eine Shell beteiligt ist

Der Schlüssel ist, das LLM das Gefühl geben zu lassen, als würde es eine CLI verwenden. Im System des Autors berühren die meisten Befehle nie das Betriebssystem – sie sind Go-Funktionen, die von einem Command-Router ausgeführt werden. Nur Befehle, die wirklich ein echtes Betriebssystem benötigen (Skripte ausführen, Pakete installieren), gehen zu einer isolierten Micro-VM. Der Agent weiß nicht und kümmert sich nicht darum, welche Ebene seinen Befehl verarbeitet.

Agentenfreundliche CLI-Design-Prinzipien

Zwei Kernphilosophien

Philosophie 1: Unix-artiges Hilfe-Design

• tool --help → Liste der Top-Level-Befehle
• tool <command> --help → spezifische Parameter und Nutzung für diesen Unterbefehl

Dies ermöglicht es dem Agenten, Fähigkeiten bei Bedarf zu entdecken, ohne alle Dokumentationen von vornherein in den Kontext zu stopfen.

Philosophie 2: Tipps-Denken

Jede Antwort – besonders Fehler – sollte Anleitungen enthalten, die unnötige Erkundung reduzieren.

Schlechtes Beispiel:

> cat photo.png [error] binary file

Gutes Beispiel:

> cat photo.png [error] cat: Binärdatei erkannt (image/png, 182KB). Verwende: see photo.png (Bild anzeigen) Oder: cat -b photo.png (base64 kodieren)

Warum das wichtig ist: Ungültige Erkundung verschwendet Tokens. In mehrteiligen Konversationen summiert sich diese Verschwendung – jeder fehlgeschlagene Versuch bleibt im Kontext und verbraucht Aufmerksamkeit und Inferenz-Ressourcen für jeden folgenden Zug. Ein einziger hilfreicher Hinweis kann signifikant viele Tokens für den Rest der Konversation einsparen.

Sicheres CLI-Design

Wenn CLI-Befehle gefährliche oder irreversible Operationen beinhalten, sollte das Tool selbst Sicherheitsmechanismen bereitstellen.

Trockenlauf / Änderungsvorschau – Fehler verhindern

Für Operationen innerhalb der Autorität des Agenten, aber mit schwer rückgängig zu machenden Konsequenzen. Das Ziel ist, dem Agenten (oder Menschen) zu zeigen, was passieren wird, bevor es ausgeführt wird.

> dns update --zone example.com --record A --value 1.2.3.4 ⚠ TROCKENLAUF: A-Eintrag für example.com: 5.6.7.8 → 1.2.3.4 Verbreitung: ~300s. Nicht sofort umkehrbar. Zum Ausführen: --confirm hinzufügen

Die Vorschau sollte klar zeigen, was der aktuelle Zustand ist und was sich ändern wird. Der Agent bestätigt mit --confirm.

Menschliche Autorisierung – Operationen jenseits der Autonomie des Agenten

Für Operationen, die menschliches Urteilsvermögen oder Genehmigung erfordern – egal wie zuversichtlich der Agent ist, er kann diese nicht alleine abschließen.

Ansatz 1: Blockierende Push-Genehmigung

> pay --amount 500 --to vendor --reason "office supplies for Q2" ⏳ Genehmigung erforderlich. Benachrichtigung an dein Gerät gesendet. Warte auf Antwort... ✓ Genehmigt. Zahlung von $500 abgeschlossen. [exit:0 | 7.2s]

Wie Apples Geräte-Login-Verifizierung – die CLI sendet eine Push-Benachrichtigung direkt an das Gerät des Menschen mit vollem Kontext (Betrag, Empfänger, Grund). Die CLI blockiert, bis der Mensch genehmigt oder ablehnt, und gibt dann das Ergebnis an den Agenten zurück.

Ansatz 2: Verifizierungscode / 2FA

> transfer --from savings --to checking --amount 10000 ⚠ Diese Operation erfordert 2FA-Verifizierung. Grund: Überweisung von $10.000 zwischen Konten. Ein Code wurde an deinen Authenticator gesendet. Erneut ausführen mit: --otp <code>