AI-Agenten verbessern durch angepasste CLI-Tools und APIs

Die Neubewertung von CLI-Schnittstellen für KI Es ist notwendig, unsere Kommandozeilenwerkzeuge und API-Designs zu erweitern, damit sie besser von LLM-Agenten genutzt werden können. Die derzeitigen Designs sind unzureichend, insbesondere bei lokalen Modellen mit winzigen Kontextfenstern. Agent-APIs Wie viele Entwickler bin ich in die Welt der LLM-Agenten eingetaucht. Ich habe viel experimentiert, insbesondere mit der Automatisierung von Reverse-Engineering-Aufgaben unter Verwendung von mrexodia’s IDA Pro MCP, einschließlich dessen Erweiterung. Die Entwicklung einer MCP-Schnittstelle ist ein interessanter Prozess. Es ist wichtig, die Balance zwischen der Bereitstellung zu viel oder zu wenig Informationen zu finden, um die Kontextfenster nicht zu überlasten, aber gleichzeitig genug Informationen zu liefern, um die Anzahl der Werkzeugaufrufe zu minimieren. Ein gutes Beispiel ist die Funktion get_global_variable_at, die eine Adresse entgegennimmt, den Datentyp identifiziert und die beste Zeichenkette-Darstellung dieses Werts basierend auf dem Typ zurückgibt. Diese Funktion kann jedoch fehlschlagen, weshalb wir zusätzliche Zugriffsmethoden bereitstellen, wie data_read_dword, data_read_word, read_memory_bytes usw. Diese Methoden sind in Ordnung, ignorieren aber die Typinformationen. Daher möchten wir, dass der LLM die bequemere Funktion zuerst verwendet. Um dieses Problem zu mildern, haben wir Anweisungen in die Docstrings integriert: ```python @jsonrpc @idaread def data_read_byte( address: Annotated[str, "Adresse, von der 1 Byte-Wert gelesen werden soll"], ) -> int: """ Liest den 1 Byte-Wert an der angegebenen Adresse. Verwenden Sie diese Funktion nur, wenn `get_global_variable_at` fehlgeschlagen ist. """ ea = parse_address(address) return ida_bytes.get_wide_byte(ea) ``` Dies hat größtenteils funktioniert, aber ähnliche Probleme treten bei anderen APIs ebenfalls auf. Wir haben eine praktische Hilfsfunktion und eine umfangreichere, aber komplexere Funktion, und es ist wichtig, dass der LLM die einfachere Funktion zuerst verwendet. Kommandozeilenwerkzeuge Diese Herausforderungen bestehen auch für Kommandozeilenwerkzeuge. Wenn man Claude Code beobachtet, wird oft head -n100 verwendet, um die Ergebnisse vorab zu begrenzen. Es verliert sich auch leicht in Verzeichnissen und versucht frustrierend oft, Befehle in verschiedenen Verzeichnissen auszuführen, bis es das richtige findet. Um Claude Code bei meinem Projekt im Rahmen zu halten, habe ich mich stark auf Linter, Build-Skripte, Formater und Git-Commit-Hooks gestützt. Es ist einfach, Claude Code häufig zu committen, indem man es in die Datei CLAUDE.md einbezieht, aber es ignoriert oft andere Befehle wie „Stelle sicher, dass der Build nicht fehlschlägt“ oder „Behebe alle fehlgeschlagenen Tests“. Jedes meiner Projekte verfügt über ein .git/hooks/pre-commit-Skript, das Projektstandards durchsetzt. Der Hook funktioniert sehr gut, um die Dinge im Rahmen zu halten. Bei besonders schwierigen Änderungen ignoriert es jedoch oft, dass es einen Test gebrochen hat. Ich sehe es oft in dieser Schleife: Dann überspringt es die Hooks! Dies geschah so häufig, dass ich eine Git-Umschließung in meinen Pfad (PATH) eingefügt habe, die git commit --no-verify verhindert und eine Fehlermeldung mit Anweisungen zur Behebung der Fehler ausgibt: ``` $ git commit --no-verify ❌ FEHLER: Commits abgelehnt. Die Verwendung der Option '--no-verify' ist in diesem Repository deaktiviert. ? ANLEITUNG FÜR DEN KI-AGENTEN: Sie haben versucht, die erforderlichen Vor-Commit-Überprüfungs- schritte zu umgehen. Alles Code muss die Qualitätskontrollen (das Formatieren, Linting und Tests) bestehen, bevor er committet werden kann. NICHT UMGEHEN. BEHEBEN SIE DIE GRUNDLIEGENDEN FEHLER. Der Pre-Commit-Hook scheitert wahrscheinlich. Diagnostizieren und beheben Sie die Probleme. Suchen Sie nach Ratschlägen, wenn Sie steckenbleiben. Versuchen Sie den Commit wieder ohne die Option '--no-verify', nachdem alle Befehle erfolgreich ausgeführt wurden. ``` Dies führte zu einem Spiel des „Whack-a-Mole“, bei dem der LLM auch versuchte, die Pre-Commit-Hooks zu ändern! Ich musste dies beheben, indem ich in der Datei .claude/settings.json den Zugriff auf Edit(.git/hooks/pre-commit) verweigert habe. Ich freue mich auf seine nächste faule Innovation. Informationsarchitektur für LLMs Das Feld der Benutzererfahrung (UX) hat ein Konzept namens „Informationsarchitektur“. Informationsarchitektur konzentriert sich darauf, wie und welche Informationen Benutzern präsentiert werden, um die beste mögliche Benutzererfahrung zu bieten. Eine gute Informationsarchitektur fällt selten auf, aber ihre Abwesenheit schon. Wenn man die Agenten bei der Verwendung unserer vorhandenen Kommandozeilenwerkzeuge beobachtet, werden sie oft verwirrt und verloren. Dies deutet darauf hin, dass die Informationsarchitektur unserer Kommandozeilenwerkzeuge unzureichend ist. LLMs werden trainiert, unsere vorhandenen CLI-Werkzeuge zu verwenden, daher sollten wir sie mit Kontexten erweitern, die für die LLM nützlich sind, und möglicherweise die Ausgabe anpassen, um von den Agenten besser konsumiert zu werden. Zurück zum Beispiel mit head. Oft führt der Agent meinen Build mit cargo build | head -n100 aus. Hierbei gibt es einige Probleme: Vielleicht könnten wir head durch eine Umschließung ersetzen, die die Ausgabe zwischenspeichert, in eine strukturiertere Form umwandelt und den Agenten informiert, wie viele Zeilen noch übrig sind. Ähnlich, wenn der Agent versucht, einen Befehl auszuführen, weil er sich im falschen Verzeichnis befindet, könnten wir ihm mit einem Shell-Hook etwas zusätzliche Hilfe geben: bash command_not_found_handler() { echo "zsh: command not found: '$1'" echo "zsh: current directory is $PWD" return 127 # Behalte das Standardverhalten (127 = command not found) } $ sdfsdf zsh: command not found: 'sdfsdf' zsh: current directory is /Users/ryan zsh: Möglicherweise wollten Sie: cd agent_directory; sdfsdf Dies könnte sogar etwas „fuzzier“ sein, indem es kürzlich oder Elternverzeichnisse überprüft und Vorschläge macht. Fazit Grundsätzlich kann fast jedes CLI-Werkzeug auf irgendeine Weise verbessert werden, um zusätzlichen Kontext für LLMs bereitzustellen. Dies wird die Anzahl der Werkzeugaufrufe reduzieren und die Kontextfenster optimieren. Die Agenten könnten auch von etwas Training profitieren, um die Werkzeuge innerhalb ihres Agenten besser zu nutzen. Dies wird sicherlich bei den meisten allgemeinen CLI-Werkzeugen helfen, aber speziellere Werkzeuge könnten von einer Anpassung an LLMs profitieren. Vielleicht klingt es absurd, aber es könnte sein, dass wir eine gesamte Reihe von LLM-optimierten CLI-Werkzeugen oder eine benutzerdefinierte LLM-Shell benötigen. Das UX-Feld könnte sich sogar in AI-Erfahrung entwickeln und uns eine ganz neue Informationsarchitektur bieten.