Agent Harness: So haben wir Norman beschleunigt

Ein KI-Assistent kann erstaunlich lange brauchen, um sich auf eine einfache Aufgabe vorzubereiten. Du möchtest eine Transaktion finden. Er erstellt einen Plan, wählt Werkzeuge, prüft das Ergebnis und startet einen weiteren Modellaufruf, um die Antwort zu formulieren. Jeder Schritt klingt vernünftig. Zusammen können sie aus einer kurzen Suche eine lange Wartezeit machen.

Diese Erfahrung haben wir beim Einbau eines Agent Harness in Norman gemacht. Der Assistent sollte seinen Arbeitsstand festhalten und prüfen, was tatsächlich gespeichert wurde, bevor er eine Aufgabe als erledigt bezeichnet. Für ein Produkt, das mit Rechnungen, Belegen und Transaktionen arbeitet, ist das notwendig. Derselbe Planungs- und Prüfprozess für jede Anfrage verursachte allerdings zu viel Aufwand.

Unsere Antwort war, die Anforderungen an den Nachweis beizubehalten und die Steuerung an die jeweilige Aufgabe anzupassen. Während dieser Einführung beobachteten wir deutlich kürzere Bearbeitungszeiten. Interessant ist vor allem, welche Arbeit wir dafür entfernen konnten.

Was ist ein Agent Harness für KI-Agenten?

Ein Agent Harness ist die Software rund um ein Modell, die dessen Arbeit steuert: den bereitgestellten Kontext, die verfügbaren Werkzeuge, den gespeicherten Arbeitsstand und die Bedingungen für den Abschluss einer Aufgabe. Das Modell schlägt Aktionen vor. Der Harness führt sie aus und bestimmt, welche Nachweise die Anwendung für einen erfolgreichen Abschluss benötigt.

Stell dir vor, du möchtest einen Beleg mit einer Transaktion verknüpfen. Die Anfrage zu verstehen ist ein Teil davon. Die richtigen Objekte zu finden, die Änderung auszuführen, die gespeicherte Verknüpfung zu prüfen und eine Unterbrechung zu melden, gehört zur Anwendung. Ein besserer Prompt unterstützt das Verständnis. Er übernimmt diese Aufgaben jedoch nicht.

Die aktuelle Branchendiskussion beschäftigt sich zunehmend mit dieser umgebenden Software. LangChain machte im Juli-Release von Deep Agents die Planung optional und kürzte Standardanweisungen. Ein Forschungs-Preprint vom September untersucht die Auswahl relevanter Werkzeuge anstelle vollständiger Kataloge. Eine September-Analyse von PlayerZero beschreibt unnötige Entscheidungen, die ein Harness dem Modell auferlegen kann.

Für ein Produkt, das Menschen während ihres Arbeitstags nutzen, sind das praktische Fragen. Jede zusätzliche Entscheidung kostet Zeit, auch wenn die spätere Antwort stimmt.

Warum braucht ein Finanzagent einen Harness?

Eine überzeugende Antwort belegt kaum, dass eine geschäftliche Aufgabe abgeschlossen ist. Ein Assistent kann mehrere Dokumente finden, einen Teil davon bearbeiten und anschließend eine plausible Zusammenfassung schreiben. Für dich zählt, welche Änderungen tatsächlich erfolgt sind und welche Punkte offenbleiben.

Wir haben deshalb einen dauerhaft gespeicherten Ausführungszustand und ein Journal der Werkzeugaufrufe ergänzt. Die Anwendung protokolliert einen geplanten Vorgang vor dem Aufruf und sein Ergebnis danach. Spätere Prüfungen erhalten damit konkrete Anhaltspunkte. Die Bestätigung eines Werkzeugs allein beweist noch nicht, dass das gewünschte Ergebnis vorliegt.

Bei unterstützten Änderungen liest der Harness das gespeicherte Objekt erneut und vergleicht die relevanten Werte oder Verknüpfungen. Eine zurückgegebene Rechnungskennung ist hilfreich. Die Rechnung mit den erwarteten gespeicherten Werten wiederzufinden, liefert einen stärkeren Nachweis. Damit ist noch nicht jede buchhalterische Entscheidung fachlich richtig. Gespeicherte Änderungen und fachliche Urteile brauchen jeweils passende Prüfungen.

Das Journal hilft auch bei Unterbrechungen. Ist der Ausgang eines Vorgangs unklar, sollte der nächste Schritt zunächst den gespeicherten Zustand klären. Eine Änderung einfach erneut auszuführen, kann bei der Wiederherstellung ein zusätzliches Problem erzeugen.

Warum kann ein Agent Harness Antworten verlangsamen?

Unser erster Ansatz bündelte zu viel Steuerung in einer allgemeinen Ausführungsschleife. Die Planung machte das Ziel explizit. Kontrollpunkte hielten Fortschritt fest. Eine Prüfung bewertete das Ergebnis. Ein abschließender Schreibschritt formulierte die Antwort. Aus sinnvollen Bausteinen wurde ein teurer Standardweg für gewöhnliche Anfragen.

Die Verzögerung lag häufig zwischen den eigentlichen Geschäftsvorgängen. Eine Suche konnte schnell antworten, während der Assistent weiter über den nächsten Schritt entschied, bereits bekannte Informationen prüfte oder seine Schlussfolgerung neu formulierte. Eine Optimierung der Datenbank allein hätte diese Wartezeiten kaum beseitigt.

Wir messen deshalb die Zeit bis zum Abschluss getrennt von der Zeit bis zum ersten Text. Zusätzlich erfassen wir Vorbereitung, Generierung, lesende und schreibende Werkzeugaufrufe sowie Prüfungen. Einige Phasen laufen gleichzeitig. Ihre Dauern einfach zu addieren, würde eine falsche Gesamtdauer ergeben. Wir brauchen sowohl die tatsächliche Wartezeit als auch Hinweise darauf, wo Aufwand entsteht.

Damit änderte sich die Optimierungsfrage. Wir untersuchten zuerst, welche Modellaufrufe die Anwendung unnötig erzeugte. Die vollständige Ausführungsschleife war selbst zu einem wesentlichen Kostenfaktor geworden.

Wie haben wir den Norman-Agenten beschleunigt?

Zunächst wählen wir den Ausführungsweg lokal aus. Eine Begrüßung, eine Suche, eine gewöhnliche Änderung und eine große Sammelaufgabe brauchen unterschiedliche Abläufe. Diese Einordnung benötigt keinen zusätzlichen Modellaufruf.

Bei gewöhnlichen Aktionen kann ein Agentenlauf die nötigen Werkzeuge nutzen und antworten. Ein vorgeschalteter Plan, eine äußere Reparaturschleife und ein separater Antwortschreiber sind nicht obligatorisch. Innerhalb eines Laufs können weiterhin mehrere Modellaufrufe stattfinden, sobald Werkzeugergebnisse eintreffen. Wir reduzieren die Steuerung um die Arbeit herum und setzen einen Lauf nicht mit einem einzigen Modellaufruf gleich.

Lässt sich eine unterstützte Änderung durch exakte gespeicherte Werte prüfen, übernimmt Code diesen Vergleich. Das Modell muss ihn nicht wiederholen. Bei weniger eindeutigen Ergebnissen kann eine einzelne zusätzliche semantische Prüfung nötig sein. Sie klärt eine konkrete offene Frage, statt die gesamte Aufgabe erneut aufzurollen.

Auch der Kontext jedes Schritts wurde kleiner. Bei einem lokalen Vergleich für eine Transaktionssuche sank der anfragespezifische Katalog von ungefähr sechzig auf weniger als zehn Werkzeuge. Die serialisierten Werkzeugbeschreibungen schrumpften von etwa 60.000 auf etwa 12.000 Zeichen, also um rund 80 Prozent. Das sind Zeichenzahlen dieses Vergleichs, keine gemessene Tokenersparnis oder allgemeine Beschleunigung. Unser früherer Beitrag zur Auswahl der Agentenwerkzeuge beschreibt das übergeordnete Prinzip.

Der Gesprächsverlauf erhält ein begrenztes Budget. Relevante Anhänge und Bezüge auf frühere Nachrichten bleiben dabei berücksichtigt. Optionale externe Quellen werden bei Bedarf verbunden. Unabhängige Abfragen für eine Übersicht können parallel laufen. Dafür müssen wir keine Finanzdaten zwischenspeichern, die sich seit der letzten Anfrage verändert haben könnten.

Wie viel schneller wurde Norman?

Über zwei vollständige UTC-Tage während der Einführung im September verglichen wir rund vierhundert erfolgreiche Assistentenläufe mit Streaming. Die mediane Abschlusszeit sank von ungefähr 20 auf ungefähr 10 Sekunden. Das 90. Perzentil fiel von rund 90 auf rund 30 Sekunden. Dieser zweite Wert beschreibt den langsameren Bereich erfolgreicher Anfragen: Etwa neun von zehn waren innerhalb dieser Zeit fertig.

Das ist eine Beobachtung des Produktionsverkehrs am 8. und 9. September, kein kontrollierter Vergleich identischer Prompts. Die Zusammensetzung der Anfragen änderte sich, mehrere Verbesserungen wurden gemeinsam eingeführt, und fehlgeschlagene oder unfertige Läufe sind ausgeschlossen. Wir können die gesamte Differenz keiner einzelnen Optimierung zuschreiben. Ebenso wenig können wir versprechen, dass jede Aufgabe doppelt so schnell endet. Die Zahlen beschreiben diese Stichprobe.

Die wahrgenommene Geschwindigkeit betrachten wir separat. Rein lesende Antworten können während ihrer Entstehung gestreamt werden. Antworten über abgeschlossene Änderungen müssen die Prüfgrenze einhalten. Ein früher sichtbarer Satz ist hilfreich, beendet die eigentliche Aufgabe aber noch nicht. Unser Beitrag zum Streaming eines KI-Agenten behandelt diese Unterscheidung in der Oberfläche.

Unser Ziel ist ein kürzerer Weg zu einem brauchbaren, belegbaren Ergebnis. Eine schnelle Nachricht mit anschließender langer unsichtbarer Wartezeit würde dieses Ziel verfehlen.

Wie testet man einen Agent Harness?

Tests sollten den Ablauf ebenso prüfen wie die Antwort. Kommt eine normale Suche ohne unnötigen Prüfer aus? Wird eine unterstützte Änderung erneut aus dem System gelesen? Stoppt oder untersucht der Agent einen unklaren Vorgang, bevor er ihn wiederholt? Beschreibt die abschließende Antwort die tatsächlich gesammelten Nachweise?

In geskripteten Prüfungen benötigten eine einfache Suche und ein unterstützter Ablauf aus Anlegen und erneutem Lesen jeweils zwei Generierungsaufrufe. Separate Prüf- oder Schreibaufrufe waren nicht nötig. Diese Prüfungen legen ein Budget für die Steuerung fest. Sie messen weder die Antwortzeit eines live aufgerufenen Modells noch garantieren sie korrekte Antworten in allen künftigen Fällen.

Wir speichern Szenarioergebnisse, damit sich Änderungen an Werkzeugen, Kontext oder Abschlusslogik später vergleichen lassen. Produktionsmessungen ergänzen diese Szenarien durch echten Verkehr. Den übergeordneten Ansatz erläutern wir im Beitrag zum Agenten-Tracing ohne gespeicherte Kundeninhalte.

Ich möchte, dass Normans Harness seinen Aufwand dort einsetzt, wo Unsicherheit besteht. Eine große Sammelaufgabe verdient explizite Fortschrittskontrolle. Ein exakt vergleichbarer gespeicherter Wert braucht eine kleine deterministische Prüfung. Eine einfache Suche sollte den kürzesten Weg zu einer belastbaren Antwort nehmen. So wollen wir sinnvolle Kontrolle erhalten und den Agenten gleichzeitig schneller machen.