Einen KI-Agenten bauen, der mit Werkzeugen untersucht, und prüfen, dass er nicht rät

## Die Untersuchungs-Engine von den Plugins für jeden Dienst trennen Gliedern Sie das System in ausdrückliche Schichten: nutzerseitige Einstiegspunkte, Laden der Konfiguration, eine Untersuchungsmaschine, eine Werkzeugverwaltung sowie austauschbare Quellen, Werkzeugsätze, Eingabeanweisungen und Ziele. Einstiegspunkte sollten Anfragen weiterleiten und die Protokollierung einrichten; die Konfiguration sollte Einstellungen prüfen und Anbindungen aufbauen; die Maschine sollte Werkzeuge auswählen, Nachweise sammeln, Ergebnisse auswerten und Erkenntnisse wahlweise an ein berechtigtes Ziel zurückgeben. Verbergen Sie anbieterspezifisches Verhalten hinter Erweiterungen, damit die Kernschleife anhand eines stabilen Werkzeugvertrags schlussfolgern kann. Laden Sie Anbindungen dynamisch aus einer geprüften Konfiguration und halten Sie Quellenaufnahme, Untersuchung und Schreibzugriffe auf Ziele getrennt, damit eine schreibgeschützte Diagnose nicht unbemerkt zu einer externen Zustandsänderung wird. ## Jedes Werkzeug als schlanke Hülle bauen, die Fehler genau erklärt Bevorzugen Sie eine schlanke Hülle um einen einzelnen externen Endpunkt oder Vorgang. Geben Sie jeder Anbindung ein kleines geprüftes Konfigurationsobjekt, eine ausdrückliche Voraussetzung oder Funktionsprüfung und eine Werkzeugfunktion, deren Parameter unmittelbar der zugrunde liegenden Anfrage entsprechen. Vermeiden Sie aufwendige Abstraktionen des aufrufenden Programms, wenn sich Verhalten und Fehler durch einen transparenten Übertragungsaufruf leichter prüfen lassen. Geben Sie genügend Fehlerkontext zurück, damit der Aufrufer sich selbst korrigieren kann: die genaue Abfrage oder den genauen Befehl, den Zeitraum, Filter, relevante Parameter, den Antwortstatus und die zugrunde liegende Fehlermeldung. Ein Ergebnis ohne Daten muss angeben, was wo gesucht wurde. Erhalten Sie Zugriffskontrollen, prüfen Sie ausführbare Befehle, halten Sie Werkzeuge standardmäßig schreibgeschützt und legen Sie Geheimnisse niemals offen oder in der Versionsverwaltung ab. ## Begrenzen, wie viele Daten ein Werkzeug liefert, bevor die KI sie liest Stellen Sie niemals eine unbegrenzte Sammlung über ein Werkzeug bereit. Verlangen Sie serverseitige Filter für Endpunkte, die große Ergebnismengen zurückgeben können, und entwerfen Sie das Schema so, dass Aufrufer den wichtigsten Begrenzungsparameter nicht auslassen können. Ein Überlauf von Texteinheiten oder Speicher durch einen uneingeschränkten Auflistungsvorgang ist ein Fehler des Werkzeugvertrags und kein Problem der Eingabeanweisung. Wenn der entfernte Dienst nicht ausreichend filtern kann, ergänzen Sie ausdrückliche Steuerungen aufseiten des aufrufenden Programms, etwa maximale Tiefe, Ergebnisgrenzen, Feldauswahl oder einen strukturierten Abfrageausdruck. Melden Sie Kürzungen und die angewendeten Grenzen. Halten Sie die Standardantwort kompakt, ermöglichen Sie aber eine gezielte Erweiterung, wenn die Untersuchung weitere Nachweise benötigt. ## Alte Konfigurationsnamen weiter annehmen und gemeinsames Verhalten auf die richtige Klassenebene legen Wenn Sie ein Konfigurationsfeld umbenennen, nehmen Sie veraltete Namen als zusätzliche Eingabe an, ordnen Sie sie dem aktuellen Feld zu und geben Sie eine Warnung vor der veralteten Bezeichnung aus. Behalten Sie im öffentlichen Schema und in der serialisierten Ausgabe nur aktuelle Namen bei, damit die Kompatibilität weder erzeugte Konfigurationen noch nachgelagerte Logik verunreinigt. Bevor Sie einer bestimmten Anbindung ein Feld, eine Methode, eine Zeitüberschreitung oder eine Wiederholungsrichtlinie hinzufügen, prüfen Sie ihre Klassenhierarchie und gleichartige Implementierungen. Ordnen Sie gemeinsames Verhalten auf der allgemeinsten Ebene an, die es tatsächlich benötigt. Verwenden Sie einen bewährten Wiederholungsmechanismus mit ausdrücklicher Versuchs- und Verzögerungsrichtlinie; schreiben Sie eine eigene Schleife nur dann, wenn der Standardmechanismus die Anforderung nicht ausdrücken kann, und dokumentieren Sie den Grund. ## In drei Schichten testen, vom Unit-Test bis zur ganzen Agentenbewertung Verwenden Sie drei einander ergänzende Schichten. Einzeltests isolieren lokales Verhalten, Integrationstests prüfen Werkzeug- und Dienstgrenzen, und Agentenbewertungen bestätigen das durchgängige Untersuchungsverhalten mit realistischen Eingabeanweisungen und Testdaten. Neues lokales Verhalten benötigt Einzeltestabdeckung, neue Anbindungen benötigen Grenzabdeckung und komplexe Untersuchungen benötigen Bewertungsfälle. Halten Sie Quelltext- und Prüfstruktur aufeinander abgestimmt. Verwenden Sie beim Prüfen des Anfrageverhaltens HTTP-Nachbildungen auf Übertragungsebene, damit Kopfzeilen, URLs, Parameter und Adapter tatsächlich durchlaufen werden, statt eine übergeordnete Funktion zu ersetzen. Führen Sie echte Werkzeuge nur in einer bewusst eingerichteten Umgebung aus und unterscheiden Sie gewöhnliche deterministische Prüfungen von Bewertungen, die Modellzugangsdaten oder externe Dienste benötigen. ## Bewertungen entwerfen, die erfundene Antworten (Halluzinationen) erkennen Lassen Sie jede Eingabeanweisung genau die Tatsachen anfordern, welche die Bewertung prüft. Bevorzugen Sie erwartete Werte, die nur durch eine Abfrage entdeckt werden können, etwa eine eindeutige eingefügte ID, eine genaue Anzahl, einen Titel oder einen Fehlercode. Die erwartete Antwort muss für den Agenten unsichtbar bleiben. Ist die Antwort zu allgemein, um die Entdeckung zu belegen, verlangen Sie einen Nachweis dafür, dass das richtige Werkzeug aufgerufen wurde. Prüfen Sie Entdeckung statt Wiedererkennung. Verwenden Sie neutrale Ressourcennamen, realistische Szenarien und Eingabeanweisungen, die weder die Umsetzung noch die wahrscheinliche Lösung verraten. Vermeiden Sie allgemeine Behauptungen, die ein Modell anhand von Fachwissen erraten könnte. Verwenden Sie nur eingetragene Prüfkennzeichnungen, eindeutige Ressourcennamen, festgeschriebene Abhängigkeits- oder Abbildversionen und einen ausdrücklichen Fehlerabbruch, wenn die Einrichtung die Funktionsfähigkeit des Dienstes nicht belegen kann. ## Mehrere Testläufe Cloud-Ressourcen teilen lassen, ohne dass sie sich stören Gehen Sie davon aus, dass sich über entfernte Rechendienste gestützte Bewertungen aus mehreren Entwicklungszweigen im selben Benutzerkonto überschneiden können. Die Einrichtung muss idempotent sein: Sie muss Ressourcen erstellen oder wiederverwenden, ohne bei bereits vorhandenen Ressourcen fehlzuschlagen. Die Bereinigung darf niemals eine fest eingerichtete gemeinsame Ressource löschen, die ein anderer Durchlauf noch verwenden könnte; lassen Sie die Bereinigung aus oder begrenzen Sie sie auf eine eindeutige durchlaufbezogene ID. Prüfen Sie die Funktionsfähigkeit anhand einer echten API-Antwort und nicht nur anhand der Bereitschaft. Fragen Sie mit begrenzten Wiederholungen ab, um Wettlaufsituationen beim Anlegen zu behandeln, brechen Sie frühzeitig mit einem Fehler ab, wenn der erwartete Inhalt nie erscheint, und erfassen Sie bei einer Zeitüberschreitung Diagnoseangaben. Verwenden Sie eine vereinheitlichte gemeinsame Infrastruktur erneut, wenn mehrere Prüfungen denselben Dienst benötigen, halten Sie jedoch Daten und IDs jeder Prüfung getrennt. ## Ursachen von Anzeigefehlern im Terminal und schlechteren Bewertungen aus echten Laufdaten finden Stellen Sie Fehler interaktiver Terminals über ein Pseudoterminal nach und erfassen Sie unverarbeitete Steuersequenzen. Vergleichen Sie Cursorbewegungen und Löschvorgänge mit der Höhe des dargestellten Anzeigerahmens und prüfen Sie die Darstellungskomponente anschließend mit einem Speicherstrom, der sich erzwungen wie ein Terminal verhält. Beheben Sie den Rahmen- oder Aktualisierungsvertrag, der die Abweichung verursacht; ändern Sie Cursorbewegungen nicht blindlings, wenn sich das Verhalten am unteren Rand des Terminals unterscheidet. Vergleichen Sie bei Regressionen in Agentenbewertungen ein Referenz-Ablaufprotokoll und ein aktuelles Ablaufprotokoll derselben Prüfung und desselben Modells, bevor Sie sich auf Quelltextunterschiede oder zusammengefasste Statistiken stützen. Prüfen Sie dargestellte Eingaben, die Reihenfolge der Werkzeugaufrufe, Kennzahlen pro Aufruf und zurückgegebene Nachweise. Eine Vorlage kann im Quelltext wachsen und zur Laufzeit schrumpfen; zusammengefasste Schwankungen können eine deterministische Änderung je Durchlauf verbergen. Lesen Sie den vollständigen Änderungssatz einer verdächtigen Revision, bevor Sie nur die auffälligste Datei zurücksetzen. ## Formatierung und Prüfungen nur auf betroffene Dateien anwenden und nicht ohne Erlaubnis pushen Befolgen Sie die projektspezifischen Richtlinien für Stil, Typisierung, Prüfungen und Versionsverwaltung. Führen Sie jedoch keine umfassenden automatischen Korrekturen, Formatierungen oder Prüfungen des gesamten Projektarchivs aus, wenn diese bekanntermaßen unbeteiligte Dateien verändern, sofern der Nutzer oder der maßgebliche Arbeitsablauf sie nicht ausdrücklich verlangt. Begrenzen Sie automatische Formatierung und statische Prüfung auf die betroffenen Dateien und halten Sie Begutachtungen zusammen mit den zugehörigen Prüfungen zielgerichtet. Ordnen Sie Einbindungen und gemeinsame Hilfsfunktionen gemäß den Projektkonventionen an, bewahren Sie einen umkehrbaren Verlauf und vermeiden Sie erzwungenes Umschreiben des Verlaufs ohne ausdrückliche Genehmigung. Eine lokale Aufgabe berechtigt für sich allein weder dazu, Änderungen einzuchecken, zu übertragen oder zu veröffentlichen, noch dazu, externe Zustände zu verändern. Berichten Sie, welche Prüfungen ausgeführt und welche bewusst ausgeschlossen wurden. ## Alle Verweise anpassen, wenn sich eine Doku-Seite oder Überschrift ändert Verwenden Sie die Dokumentation des Projektarchivs als vorrangige Quelle für das Projektverhalten, bevor Sie die öffentliche Internetseite heranziehen. Wenn eine Seite verschoben, ein Dateiname geändert oder der Anker einer Überschrift geändert wird, suchen Sie im gesamten Projektarchiv nach dem alten Pfad und Anker, einschließlich Dokumentation, Zeichenketten im Quelltext, übergeordneten Leitfäden und Kommentaren, und aktualisieren Sie anschließend jeden betroffenen Verweis. Aktualisieren Sie die tatsächlich verwendete Navigationsquelle des Dokumentationssystems und nicht eine ähnlich benannte, aber inaktive Konfiguration. Bewahren Sie darstellungsspezifische Strukturen, darunter erforderliche Leerzeilen und eine gültige Überschriftenhierarchie. Vermeiden Sie veraltete Funktionslisten und wiederholte Sicherheitsfloskeln; bevorzugen Sie knappe Beispiele und zusammengefasste Blöcke zur Fehlerbehebung. Wenn eine Anbindung hinzugefügt wird, aktualisieren Sie deren Übersicht, Index, eigene Seite, Navigationseintrag und Bildmaterial gemeinsam.