Agenten-Ereignisse erklärt: Der Laufzeitvertrag hinter zuverlässigen KI-Agenten

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Die endgültige Antwort eines Agenten zeigt Ihnen, was der Benutzer gesehen hat. Seine Events verraten Ihrer Anwendung, was passiert ist, was gerade passiert, wo menschliches Eingreifen erforderlich ist und wie die Wiederherstellung nach einem Verbindungsabbruch gelingt.
1. Warum eine Final-Answer-API für Agenten nicht ausreicht
Ein herkömmlicher Modellaufruf folgt einem beruhigenden Muster: Eingabe senden, Ausgabe empfangen. Selbst wenn die Antwort gestreamt wird, rekonstruiert die Anwendung meist nur eine einzige Antwort. Die Ausführung von Agenten ist anders. Ein Durchlauf kann mehrere Modellaufrufe tätigen, Tools anfordern, auf eine Freigabe warten, sich bei einem MCP-Server authentifizieren, eine Sandbox erstellen, Aufgaben an Subagenten delegieren und in einer späteren Anfrage fortgesetzt werden.
Wenn die Runtime nur die letzte Textantwort offenlegt, verliert die Anwendung die Struktur, die sie für diesen Workflow benötigt. Sie kann grundlegende Fragen nicht zuverlässig beantworten:
- Denkt der Agent gerade, ruft er ein Tool auf, wartet er auf einen Menschen oder ist er fertig?
- Welche Modellnachricht hat diesen Tool-Aufruf vorgeschlagen?
- Welche Events gehören zu einem Subagenten und nicht zum Root-Agenten?
- Welche Fragmente wurden bereits gerendert?
- Sollte sich der Client nach einer Trennung wieder mit dem laufenden Prozess verbinden oder den Zustand aus dem persistenten Speicher wiederherstellen?
Deshalb sind Events so wichtig. Sie bilden die Schnittstelle zwischen der verborgenen Ausführung und allem, was darauf reagieren muss: der Benutzeroberfläche, dem Freigabeservice, der Betriebskonsole, dem Debugger und dem Evaluierungssystem.
2. Was „Event“ in TrueForge bedeutet
TrueForge organisiert die Ausführung als Agent → Session → Turn → Event → Delta. Jede Ebene beantwortet eine andere Frage:
Der Agent ist eine Definition, kein kontinuierlich laufender Prozess. Eine Session speichert den Kontext über mehrere Turns hinweg. Ein Turn repräsentiert einen Anfragezyklus, wobei innerhalb einer Session immer nur ein Turn gleichzeitig aktiv ist. Events sind die typisierten Datensätze, die innerhalb dieses Turns erzeugt werden. Einige Events – am deutlichsten bei Modellnachrichten – können schrittweise durch Deltas zusammengesetzt werden.

Diese Hierarchie verhindert zwei häufige Designfehler. Erstens sollte der Sitzungsverlauf nicht als ein unbegrenztes Transkript behandelt werden: Interaktionsschritte bieten natürliche Ausführungsgrenzen. Zweitens sollte ein gestreamtes Delta nicht so gespeichert oder ausgewertet werden, als handele es sich um das endgültige semantische Ereignis.
3. Die Ereignistaxonomie ist der Laufzeit-Zustandsautomat
Die dokumentierte Ereignis-Union von TrueForge deckt verschiedene Kategorien ab. Es geht dabei nicht um die Anzahl der Ereignistypen, sondern darum, dass jede Kategorie ein anderes Anwendungsverhalten impliziert.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.















.webp)


.png)
.png)

.png)
.png)
.png)
.png)
.png)
.png)
.png)

.png)
.png)





