Lernen Sie, KI-Agenten zu erstellen und zu betreiben

Nahezu jeder Agent, unabhängig vom Rahmen, in dem er erstellt wurde, wird aus denselben wenigen Teilen zusammengesetzt. Der größte Teil des Debuggens besteht darin, zu lernen, sie voneinander zu unterscheiden, da sich Fehler sauber an ihnen lokalisieren lassen.

Das Modell ist die Argumentationsmaschine. Es liest den aktuellen Zustand und entscheidet, was als nächstes passiert. Die Wahl des Modells ist eher eine echte technische Entscheidung als eine Standardentscheidung: Ein größeres Modell hält mehrdeutigen Anweisungen besser stand, ein kleineres kostet nur einen Bruchteil und antwortet schneller. Erfahrene Agenten verwenden oft mehr als eines und behalten sich das teure Modell den Schritten vor, die wirklich einer Beurteilung bedürfen.

Bei den Anweisungen, die normalerweise als Systemaufforderung übermittelt werden, handelt es sich eher um einen Vertrag als um eine Persönlichkeit. Sie legen die Rolle, die Einschränkungen, das Ausgabeformat und vor allem die Definition von erledigt fest. Vage Anweisungen sind die häufigste Ursache dafür, dass Agenten im Kreis herumlaufen oder auf halbem Weg stehen bleiben.

Der Kontext ist alles, was das Modell während dieses bestimmten Schritts sehen kann: die Aufgabe selbst, die von Ihnen abgerufenen Datensätze, die Ergebnisse früherer Toolaufrufe. Behandeln Sie es als Budget und nicht als Container. Jeder Token, der für irrelevantes Material ausgegeben wird, kostet Geld, erhöht die Latenz und schwächt die Aufmerksamkeit des Modells auf die eine Zeile, die tatsächlich wichtig ist.

Speicher ist das, was zwischen Schritten und Läufen überlebt. Das Kurzzeitgedächtnis ist normalerweise nur das laufende Transkript. Das Langzeitgedächtnis ist eine bewusste Handlung: eine Zusammenfassung, die Sie beibehalten, eine Aufzeichnung früherer Entscheidungen, ein Profil des Benutzers. Die Verschmelzung der beiden führt dazu, dass die Agenten zwischen den Sitzungen entweder an Amnesie leiden oder langsam in ihrer eigenen Geschichte ertrinken.

Werkzeuge sind der Aktionsraum, die typisierten Funktionen, die der Agent aufrufen darf. Ihre Namen und Beschreibungen sind Teil der Eingabeaufforderung, da das Modell ein Werkzeug auswählt, indem es sie liest. Ein Tool namens „processData“ ohne Beschreibung wird schlecht ausgewählt und dem Modell angelastet.

Der Entscheidungsschritt ist der Moment, in dem das Modell entweder einen Toolaufruf mit Argumenten oder eine endgültige Antwort ausgibt. Alles, was vorgelagert ist, ist vorhanden, um diese eine Wahl gut zu treffen.

Die Ausführung ist die Laufzeit: die Komponente, die das Tool tatsächlich aufruft, Schleifen- und Wiederholungslimits erzwingt, Anmeldeinformationen anhängt, Fehler behandelt und aufzeichnet, was passiert ist. Frameworks geben Ihnen die Argumentationsteile. Die Laufzeit sorgt dafür, dass das Ergebnis sicher anderen Leuten präsentiert werden kann.

Zusammengesetzt lautet der Zyklus: Beobachten Sie den Zustand, wählen Sie eine Aktion, führen Sie sie aus, beobachten Sie das Ergebnis, wiederholen Sie den Vorgang. Wenn etwas schief geht, deutet das Symptom normalerweise auf einen Teil hin. Bei einer sicher falschen Antwort fehlt normalerweise der Kontext. Eine unangemessene Aktion ist normalerweise eine schlechte Werkzeugbeschreibung. Ein Lauf, der niemals endet, ist normalerweise eine fehlende Definition von „erledigt“.

Ein Agent ist nur so leistungsfähig wie die Aktionen und Informationen, die Sie ihm übermitteln. Hier lebt der Großteil der praktischen Technik.

Entwerfen Sie Werkzeuge, die eng und verbförmig sind. Ein Tool, das Kundenbestellungen liest, ist besser als eines, das die Datenbank verwaltet. Enge Tools führen zu klaren Entscheidungen, sind leicht zu genehmigen und scheitern auf eine Weise, die Sie interpretieren können. Umfangreiche Werkzeuge laden das Modell zum Improvisieren ein, und die Improvisation ist es, die weh tut.

Schreiben Sie die Beschreibung für das Modell, nicht für Ihre Kollegen. Es sollte angeben, was das Tool tut, wann es verwendet werden soll, wann nicht und was es zurückgibt. Geben Sie die Argumente ein und validieren Sie sie. Ein Schema ist hier keine Bürokratie, sondern der Unterschied zwischen einem abgelehnten Aufruf und einem fehlerhaften Schreibvorgang in ein Produktionssystem.

Widerstehen Sie dem spekulativen Hinzufügen von Werkzeugen. Die Qualität der Auswahl nimmt mit zunehmendem Aktionsraum ab: Bei 30 verfügbaren Werkzeugen konzentriert sich das Modell auf die Auswahl und nicht auf die Aufgabe und trifft häufiger falsch. Wenn sich zwei Werkzeuge überschneiden, führen Sie sie zusammen oder löschen Sie eines.

Der Kontext sollte abgerufen und nicht ausgegeben werden. Rufen Sie die spezifischen Datensätze ab, die diese Aufgabe benötigt, und übergeben Sie diese. Wenn die Quelle groß ist, teilen Sie sie sinnvoll auf und rufen Sie sie nach Relevanz ab, anstatt das gesamte Dokument einzufügen. Fordern Sie Zitate zurück, damit eine Antwort auf die Passage zurückgeführt werden kann, die sie hervorgebracht hat.

Trennen Sie Lesen vom Schreiben. Die meisten Agenten benötigen einen umfassenden Lesezugriff und einen sehr eingeschränkten Schreibzugriff. Wenn ein Zusammenfassungsagent diese als eine einzige Berechtigung behandelt, kann er schließlich Datensätze löschen. Wenn ein Schreibvorgang irreversibel ist, setzen Sie einen Menschen davor.

Bei Integrationen wird dies zu einem organisatorischen Problem und nicht zu einem Codierungsproblem. Jedes Team, das seine eigene Verbindung mit demselben Upstream-System verbindet, führt zu doppelten Anmeldeinformationen, inkonsistenten Richtlinien und keinem einzigen Prüfpfad. Ein offener Standard wie MCP ermöglicht es jedem kompatiblen Agenten, dieselben verwalteten Integrationen wiederzuverwenden, mit einer Bindung pro Upstream-System statt einer pro Team.

Referenzen verdienen eine eigene Regel, und um es kurz zu machen: Der Agent hat nie ein Geheimnis für sich. Es fordert die Aktion an und die Plattform hängt die Anmeldeinformationen im Moment des ausgehenden Anrufs an. Auf diese Weise wird eine durchgesickerte Eingabeaufforderung, ein ausführliches Protokoll oder ein freigegebenes Transkript niemals zu einem durchgesickerten Schlüssel.

Planen Sie schließlich einen Teilausfall ein. Echte Systeme begrenzen die Geschwindigkeit, paginieren die Antwort, geben eine Zeitüberschreitung ab und geben eine halbe Antwort zurück. Ein Agent, der jede Tool-Reaktion als Erfolg betrachtet, wird getrost auf nichts aufbauen. Geben Sie Fehler als strukturierte Daten zurück, über die das Modell nachdenken kann, und entscheiden Sie im Voraus, welche Fehler den Lauf stoppen und nicht umgangen werden sollten.

Ein Agent, der nur auf der Maschine läuft, auf der er geschrieben wurde, ist ein Prototyp. Durch die Verpackung wird daraus etwas, das eine andere Person, ein Team oder eine andere Umgebung ausführen kann, ohne Ihnen Fragen zu stellen.

Beginnen Sie mit der Reproduzierbarkeit. Fixieren Sie Ihre Abhängigkeiten, anstatt zu akzeptieren, wozu die neueste Lösung führt. Geben Sie die Ein- und Ausgaben mit einem Schema ein, damit Anrufer genau wissen, was sie senden und was zurückkommt. Halten Sie die Konfiguration außerhalb des Codes, damit dasselbe Artefakt ohne Bearbeitung für Staging und Produktion ausgeführt werden kann.

Machen Sie deutlich, was nicht mitreisen darf. Natürlich Geheimnisse, aber auch umgebungsspezifische Endpunkte, hartcodierte Kontokennungen und absolute Pfade. Wenn der Agent ohne einen Wert nicht starten kann, sollte er beim Start lautstark mitteilen, welcher Wert fehlt, und nicht erst mitten in der Ausführung.

Deklarieren Sie den Vertrag, den der Agent zum Arbeiten benötigt: welche Tools er erwartet, welche Berechtigungen diese Tools erfordern, welches Modell er annimmt und wie hoch die ungefähren Kosten pro Ausführung sind. Ein Gutachter sollte allein aufgrund dieser Erklärung entscheiden können, ob er es genehmigt.

Versionieren Sie es wie Software, denn das ist es. Behalten Sie es in Git, zeigen Sie auf eine bestimmte Version statt auf einen Zweig, vergleichen Sie zwei Versionen, um zu sehen, was sich in der Eingabeaufforderung und im Code geändert hat, und können Sie mit einem Befehl ein Rollback durchführen, wenn sich eine Änderung als schlimmer herausstellt, als sie aussah.

Versenden Sie das Evaluierungsset mit dem Agenten. Es ist die einzig ehrliche Beschreibung dessen, was der Agent tun soll, und ermöglicht es demjenigen, der es erbt, zu überprüfen, ob sich seine Umgebung wie Ihre verhält, bevor er der Ausgabe vertraut.

Schreiben Sie abschließend die Grenzen im Klartext auf: wozu dieser Agent dient, was er niemals tun darf, wem er gehört und was zu tun ist, wenn er ausfällt. Diese Notiz kostet zehn Minuten und ist der Unterschied zwischen einem Agenten, der adoptiert wird, und einem, der stillschweigend verlassen wird.

Ein Agent ist ein Projekt. Dreißig Agenten sind ein operatives Problem, und es tritt früher ein, als die meisten Teams erwarten, normalerweise ohne dass jemand darüber entscheidet.

Die Verschiebung ist eher qualitativ als quantitativ. Mit einem Agenten erinnern Sie sich daran, was er tut. Bei dreißig, verteilt auf Teams, von denen jedes seinen eigenen Rahmen wählt, hat niemand den Überblick und die wichtigen Fragen bleiben unbeantwortbar: Was läuft, wem gehört es, was kann es berühren, was hat es bewirkt und was hat es uns gekostet?

Das Inventar steht an erster Stelle, denn alles andere hängt davon ab. Jeder Agent trägt eine Identität, einen Besitzer und eine Version, was auch immer ihn hervorgebracht hat. Außerhalb der Plattform erstellte Agenten werden zu denselben Bedingungen katalogisiert wie die darauf erstellten Agenten. Nur so bleibt das Inventar ehrlich.

Die Kontrolle erfolgt zentral und wird einheitlich durchgesetzt. Ein Plattformteam legt die Richtlinien einmal fest und die Laufzeit wendet sie im Moment der Aktion auf die Agenten jedes Teams an. Dies ist die Vereinbarung, die die übliche Pattsituation zwischen der Technik, die nicht für jeden Agenten um Erlaubnis bitten möchte, und der Sicherheit, die nicht genehmigen kann, was sie nicht sehen kann, löst.

Beobachtbarkeit im Flottenmaßstab bedeutet mehr als nur die Aufbewahrung von Protokollen. Mit Traces können Sie jeden einzelnen Lauf wiedergeben. Ein unveränderlicher Prüfpfad zeichnet den handelnden Benutzer, die verwendeten Anmeldeinformationen und die erzeugten Ausgaben auf. Der Evals-Score wird kontinuierlich anhand der von Ihnen definierten Kriterien ermittelt und deckt Verhalten, Struktur, Latenz und Kosten ab. Bei einer fehlgeschlagenen kritischen Prüfung wird der Agent angehalten, anstatt einen Bericht darüber einzureichen. Das ist der Schritt von der passiven Protokollierung zur aktiven Qualitätssicherung.

Die Kosten sind die Dimension, die die Teams zuletzt entdecken und am meisten bereuen. Ausgaben, die nach Agent, Arbeitsbereich, Benutzer, Anbieter und Modell zugeordnet werden, in Währung statt in Token, verwandeln eine unerklärliche Rechnung in eine Liste von Entscheidungen. Leistungsschalterbudgets machen es dann umsetzbar: Bei achtzig Prozent warnen, bei hundert blockieren und die Überschreitung stoppen, anstatt sie erst im Nachhinein zu melden. Warnungen warnen Sie; Nur ein Unterbrecher stoppt die Ausgaben tatsächlich.

Sobald Kosten sichtbar sind, können sie systematisch und nicht anekdotisch gesenkt werden. Die Optimierung funktioniert über vier Hebel: Ausprobieren eines kleineren Modells, Beschneiden von Eingabeaufforderungen und Kontext, Entfernen von Tools, die Kosten verursachen, ohne die Ergebnisse zu verbessern, und Verschieben deterministischer Schritte aus dem Modell in normalen Code. Jede Empfehlung wird vor der Anwendung an Ihren eigenen Bewertungen gemessen, sodass Einsparungen niemals stillschweigend mit Qualität erkauft werden.

Integrationen werden auf die gleiche zentrale Weise gesteuert. Eine Bindung pro Upstream-System, einen genehmigten Katalog, den Teams anfordern können, und ein einziger Prüfpfad für das gesamte System, anstatt dass jedes Team seine eigene Verbindung und seine eigene Kopie der Anmeldeinformationen aufbaut.

Die Koordination wird im großen Maßstab zu einem echten Problem. Die Agenten geben sich gegenseitig die Arbeit ab, duplizieren sich gegenseitig, wenn zwei Teams unabhängig voneinander das gleiche Problem lösen, und konkurrieren um die gleichen Ratenlimits. Ein gemeinsam genutzter Katalog mit wiederverwendbaren Agenten und Fähigkeiten ist die kostengünstigste Lösung für Duplikate und sorgt auch dafür, dass der erste Agent eines Ingenieurs in Stunden statt in Wochen ausgeliefert wird.

Behandeln Sie schließlich die Flotte so, als hätte sie einen Lebenszyklus. Agenten werden vom Experiment in die Produktion befördert, veraltet, wenn es einen besseren gibt, und in den Ruhestand versetzt, wenn ihre Aufgabe verschwindet. Die Messung der Akzeptanz pro Team, der Kosten pro Agent und der Leistung im Vergleich zu Evaluierungen führt dazu, dass die Diskussion über das Zählen von Experimenten hinaus und hin zum Einsatz von KI geht, anstatt sie nur zu nutzen.