Technischer Leiter des SRE-Teams bei TikTok: KI-Agenten sind letzten Endes verteilte Systeme

Ihr AI Agent ruft die Rückerstattungsschnittstelle auf, aber die Netzwerkverbindung läuft ab. Ist die Rückerstattung nun erfolgreich verlaufen oder nicht?

Salman Munaf, Site Reliability Engineer bei TikTok, erläutert mit diesem Beispiel seine These: Ein Timeout bedeutet niemals einen Fehler, sondern lediglich „Ungewissheit“. Die erste Reaktion eines Agenten bei jedem Fehler ist häufig der Versuch eines erneuten Aufrufs. Ohne Anfrage-IDs, Idempotenzschlüssel und Statusabfragen kann dieser Instinkt, „zuerst neu zu versuchen und danach nachzufragen“, dazu führen, dass dieselbe Rückerstattung zweimal ausgeführt wird.

Salman arbeitet im Bereich Site Reliability Engineering bei TikTok. Seiner Meinung nach wird das Problem, sobald Modelle externe Dienste aufrufen, nicht mehr nur zu einem Modellproblem, sondern zu einem Problem verteilter Systeme. Das bedeutet auch, dass es auf alle Arten von Fehlermustern stößt, die in diesem Bereich seit Jahrzehnten wiederholt untersucht und benannt wurden.

Kürzlich hat er in einer Präsentation systematisch erläutert, warum sich AI Agenten von reinen LLM-Aufrufen zu echten verteilten Systemen entwickelt haben und welche „Waffen“ Entwickler aus dem Werkzeugkasten verteilter Systeme heranziehen müssen, damit Agenten bei Fehlern keine unumkehrbaren Folgen verursachen. Basierend auf dem Video dieser Präsentation hat InfoQ den Inhalt aufbereitet.

Kernaussagen lauten wie folgt:

AI Agenten haben sich von Modellen, die nur Text ausgeben, zu Koordinatoren externer Systeme entwickelt, die Nebenwirkungen ausführen. Dieser Wandel hat die Systemgrenzen und das Risikoprofil vollständig verändert.

Wenn Kontext Handlungen beeinflussen kann, ist er Zustand. Und Zustände können veralten, sie können mit autoritativen Daten in Konflikt geraten und sie können die nachfolgenden Handlungen des Agenten beeinträchtigen.

Wir sollten das Gedächtnis als Cache behandeln: Es muss ungültig gemacht werden können und soll Herkunftsinformationen enthalten.

Ein harmloses Modell wird gefährlich, sobald es unsichere Operationen ausführen kann.

Protokolle reichen nicht mehr aus: Sie müssen aufzeichnen, was der Agent bei jedem Schritt gesehen hat, was er darauf basierend getan hat und warum er der Meinung war, dass dies richtig ist.

Vom Chatbot zum Produktionssystem

Heute möchte ich darüber sprechen, warum auch AI Agenten verteilte Systeme sind.

Eigentlich waren LLM-Modelle am Anfang sehr einfach: Text geht ein, Text kommt heraus, keine Aktionen werden ausgeführt. Die einzige Auswirkung, die sie erzeugen können, ist eine falsche Ausgabe. Damals war das System jedoch geschlossen: Wenn das Modell einen Fehler machte, blieb dieser in der Antwort und breitete sich nicht nach außen aus. Mit dem Aufstieg der Fähigkeiten von Agenten können heutige Agenten nun mit externen Systemen interagieren und sich zu einem verteilten System entwickeln. Daher ist es sehr wichtig, das Denken und die Konzepte verteilter Systeme in die Entwicklung von AI Agenten einzubeziehen.

Vielleicht haben Sie schon von Unfällen gehört, die von AI Agenten verursacht wurden. Der AI Agent von Replicate löschte die Produktionsdatenbank, der Chatbot von Air Canada gab falsche Rückerstattungsversprechen ab. Hinter diesen Unfällen fehlte jeweils das entsprechende Systemdenken.

Nehmen wir als Beispiel den Fall von Replicate: Wenn wir über robuste Sicherungen und berechtigte Zugriffsbereiche verfügt hätten, hätte der AI Agent niemals die Berechtigung erhalten, die Produktionsdatenbank zu löschen – dieser Vorfall wäre überhaupt nicht eingetreten. Genauso verhält es sich mit dem Fall von Air Canada: Wenn es eine autoritative Wahrheitsquelle gegeben hätte, die sichergestellt hätte, dass keine Entscheidungen auf der Grundlage veralteter oder falscher Richtlinien getroffen werden, wäre das falsche Rückerstattungsversprechen nie entstanden.

Am Anfang, als LLMs noch nur Chatbots waren, gaben wir Prompts ein und erhielten Text als Ausgabe, ohne Nebenwirkungen, der Agent interagierte mit keinem anderen System. Im Zeitalter der AI Agenten können diese Agenten nun jedoch durch Empfang von Prompts die Agent-Schleife ausführen, externe Dienste und Tools aufrufen und Zustandsänderungen durchführen. Die Architekturgrenzen gehen weit über das LLM-Modell selbst hinaus und können Nebenwirkungen auf die Außenwelt erzeugen. Daher ist es beim Erstellen von AI Agenten wichtig zu erkennen, mit welchen externen Systemen sie kommunizieren, mit welchen Zuständen sie interagieren, welche Anmeldeinformationen sie besitzen und welche Operationen sie ausführen können.

Ich möchte einen sehr wichtigen Vergleich hervorheben. In verteilten Systemen gab es früher auch Dienste, die mehrstufige Workflows koordinierten – aber diese waren deterministisch: Was in jedem Schritt geschieht und was bei Fehlern zu tun ist, war vordefiniert. AI Agenten sind anders: Sie sind im Wesentlichen probabilistische Koordinatoren. Die Bandbreite der möglichen Aktionen und der nächsten Schritte ist so groß, dass sie nicht von einem herkömmlichen Entscheidungsbaum abgedeckt werden kann. Wenn diese Operationen nicht durch deterministische Steuerungen eingeschränkt werden, können sie schwerwiegende Folgen haben. Daher ist es sehr wichtig, dass wir über deterministische Steuerungsmaßnahmen verfügen, die sicherstellen, dass der AI Agent keine potenziell problematischen Operationen ausführt.

Jeder Schritt der Agent-Schleife überschreitet Systemgrenzen

Wie sieht eine typische Agent-Schleife aus? Zuerst führt er eine Planung durch, dann führt er basierend auf der Planung eine Aktion aus, beobachtet anschließend das Ergebnis dieser Aktion, speichert das Ergebnis möglicherweise in einem Datenspeicher und entscheidet dann, was als Nächstes zu tun ist. Jeder Schritt in dieser Schleife überschreitet Systemgrenzen.

In der Planungsphase interagiert er mit Datenquellen, um Informationen abzurufen. In der Aktionsphase ruft er externe APIs, Tools und Datenbanken auf, um echte Operationen auszuführen. In der Beobachtungsphase erhält er Teilergebnisse und entscheidet basierend auf diesen Teilergebnissen über nachfolgende Aktionen. Er kann fehlerhafte Daten persistieren, bei der Entscheidung eine falsche Aktion auswählen oder im schlimmsten Fall sogar einen „Retry-Sturm“ auslösen.

Daher gibt es ein besonders wichtiges Prinzip beim Erstellen der Agent-Schleife: Jeder Schritt muss persistiert werden. Jede Aktion, die der Agent ausführt, und jeder Kontext, den er abruft, müssen aufgezeichnet werden. Warum? Denn wenn ein Schritt fehlschlägt, muss der Agent wissen, an welcher Stelle er fehlgeschlagen ist, um umkehrbare Operationen auszuführen und den Vorgang rückgängig zu machen. Gleichzeitig muss jeder Schritt eine klare Transaktionsgrenze haben. Beispielsweise: Wenn der Agent einen Aufruf durchführt und dieser fehlschlägt, was soll er tun? Was ist die Kompensation für nicht umkehrbare oder unsichere Operationen? Wenn der Agent dem falschen Kunden eine E-Mail sendet, wie kann er das wiedergutmachen? Diese Fragen müssen bereits in der Entwurfsphase beantwortet werden, nicht erst nachdem ein Unfall eingetreten ist.

Wiederholungen sind keine Tugend

Tool-Aufrufe umfassen im Wesentlichen Wrapper für externe APIs, Datenbanken, Warteschlangen und mehr. Wenn Sie einen Remote-Aufruf durchführen, müssen Sie sich den Fehlermustern stellen, mit denen verteilte Systeme schon lange konfrontiert sind: Netzwerkverzögerungen, Timeouts, doppelte Anfragen und der subtilste Fall – der Server war möglicherweise bereits erfolgreich, aber der Client erhält eine Fehlermeldung.

Wir haben viele solcher Fälle gesehen: Die Daten hat die Daten bereits geschrieben, aber aufgrund eines anderen Fehlers meldet der Server dem Client einen Fehler. Wenn ein Mensch involviert ist, können wir den tatsächlichen Zustand in der Datenbank einsehen und die richtige Korrekturmaßnahme ergreifen. Aber der Agent hat diese Intuition nicht: Er sieht den Fehler und versucht es sofort erneut, ohne zu wissen, dass er keine Ahnung vom tatsächlichen Zustand des Systems hat.

Nehmen wir ein sehr konkretes Beispiel: Der Agent ruft ein Tool für „Kundenrückerstattungen“ auf, das die Rückerstattung ausführt, und dann läuft die Anfrage ab. Ist die Rückerstattung nun tatsächlich erfolgt? Wie wird der Agent schließen? Wird er die Rückerstattung erneut durchführen? Der entscheidende Erkenntnis ist hier: Ein Timeout bedeutet keinen Fehler, ein Timeout bedeutet Ungewissheit.

Beim Entwerfen dieser Tools gibt es mehrere Dinge, die unbedingt umgesetzt werden müssen. Erstens: Es muss Anfrage-IDs und Idempotenzschlüssel geben. Wenn doppelte Anfragen eintreffen, kann das nachgelagerte System erkennen, dass es sich um dieselbe Anfrage handelt, und keine doppelten Nebenwirkungen erzeugen. Zweitens: Das System muss eine Statusabfrage durchführen können, um den Status der vorherigen Anfrage zu prüfen und herauszufinden, ob sie erfolgreich war oder fehlgeschlagen ist.

Die erste Reaktion eines AI Agenten auf einen Fehler ist der erneute Versuch – das ist sein Standardverhalten. Daher müssen Sie die Idempotenz unbedingt in der Tool-Schicht verankern. Wenn dieselbe Anfrage erneut eintrifft, muss das Tool erkennen, dass es sich um eine doppelte Anfrage handelt, und sicherstellen, dass keine Nebenwirkungen auftreten.

Aber Idempotenz löst nur das Problem, dass Wiederholungen keine Nebenwirkungen erzeugen – es löst nicht das Problem des „Retry-Sturms“. Wenn der Agent unaufhörlich versucht, die Anfrage zu wiederholen, erzeugt er einen tsunamiartigen Aufrufdruck auf Ihre externen APIs, der sich zu den nachgelagerten Systemen ausbreitet und zu Kaskadenausfällen führt. Daher müssen wir maximale Wiederholungsrunden, Budgets, Ausgabenobergrenzen und maximale parallele Aufrufe festlegen, um sicherzustellen, dass sein Fan-Out nicht zu groß wird. Außerdem muss es exponentielles Backoff geben, damit die nachgelagerten Abhängigkeiten Atemraum haben. Für Operationen mit Nebenwirkungen müssen Kompensationsoperationen im Vorfeld definiert werden.

Ihr Agent hat ein „Gedächtnis“, das veralten kann

Viele Teams behandeln den Kontext, den der Agent hält, beim Erstellen von AI Agenten nur als „Kontext“. Aber ich möchte klarstellen: Wenn der Kontext Handlungen beeinflussen kann, ist er Zustand. Und Zustände können veralten, sie können mit autoritativen Daten in Konflikt geraten und sie können die nachfolgenden Handlungen des Agenten beeinträchtigen.

Ich teile das Gedächtnis des Agenten in zwei Kategorien ein. Das Kurzzeitgedächtnis ist der Kontext innerhalb dieses Ausführungsthreads. Das Langzeitgedächtnis umfasst Projektdateien, System-Prompts, die Datenbanken, mit denen er interagiert, die Cache-Schicht und mehr. Wenn es zu Informationskonflikten zwischen diesen verschiedenen Datenquellen kommt, müssen Sie entscheiden, was die Wahrheitsquelle ist. Außerdem sollten wir das Gedächtnis als Cache behandeln: Es muss ungültig gemacht werden können und soll Herkunftsinformationen enthalten. Beispielsweise: Wenn die Datenbank aktualisiert wird und die Wahrheitsquelle sich ändert, muss der alte Kontext, den der Agent hält, ungültig gemacht werden, um sicherzustellen, dass er keine Entscheidungen auf der Grundlage veralteter Daten trifft.

Agenten führen normalerweise mehrstufige Aktionen aus: Die ersten Schritte gelingen, dann schlägt ein bestimmter Schritt fehl – das ist der Normalfall. Aber die Frage ist: Was passiert mit den bereits ausgeführten vorherigen Schritten? Sie müssen die gesamte Transaktion rückgängig machen, und diese Schritte überschreiten möglicherweise Systemgrenzen.

Nehmen wir ein Beispiel: Der Agent kann ein internes Ticket aktualisieren, dem Kunden eine E-Mail senden, und dann beim Aktualisieren des CRM fehlschlagen. In diesem Fall müssen Sie definieren, was die richtige Kompensationsoperation ist. Wie ich bereits erwähnt habe: Wenn der Agent dem Kunden eine falsche E-Mail sendet, besteht die Kompensationsoperation darin, eine Entschuldigungs-E-Mail oder eine Korrektur-E-Mail zu senden.

Der Agent läuft in der Schleife und gerät bei Fehlern in eine Wiederholungsschleife. Daher sind Sicherungen (Circuit Breaker) erforderlich, wenn er externe Abhängigkeiten aufruft. Wenn das nachgelagerte System nicht fehlerfrei funktioniert, sollte der Circuit Breaker den Agenten daran hindern, diese Abhängigkeit weiter aufzurufen. Das schützt nicht nur die nachgelagerten Systeme, sondern verhindert auch Kaskadenausfälle.

Es gibt noch eine Dimension, die viele Teams vernachlässigen: das Budget. Wenn der Agent keine Budget- und Ratenbegrenzungen hat, läuft er ständig weiter, versucht ständig die Anfrage zu wiederholen und verursacht ständig Kosten. Daher müssen maximale Runden, maximale Parallelität und maximale Ausgaben festgelegt werden, um sicherzustellen, dass das Modell die von uns festgelegten Budgetgrenzen nicht überschreitet.

Ein kluges Modell bedeutet kein sicheres System

Es gibt noch ein besonders häufiges Anti-Muster. Beim Erstellen von Agenten neigen wir immer dazu, alle verfügbaren Berechtigungen zu erteilen, in der Annahme, dass der Agent die Aufgabe dann erledigen kann. Interaktion mit der Datenbank? Geben Sie ihm direkt Leseberechtigungen für die gesamte Tabelle. Es ist jedoch sehr wichtig, ihm bereichsbegrenzte Anmeldeinformationen zu geben. Es sollte separate Lese- und Schreibberechtigungen geben, und eine Zulassungsliste sollte die Tools einschränken, die er aufrufen kann. Ein harmloses Modell wird gefährlich