Kosteneinsparung und Halluzinationsprävention bei Multi-Agenten gelernt aus Ubers uReview-System
Wie man mit AST-Parsing unnötige Code-Snippets vor dem LLM-Aufruf herausfiltert
Wenn man rohe Git Diffs und den gesamten Quellcode direkt in einen Legacy-Monolithen wirft, explodieren die Kosten. Die 2025 von Uber veröffentlichte uReview-Plattform analysierte automatisch 90 Prozent der 65.000 Änderungen, die jede Woche aus sechs Monorepos hervorgehen. Wenn man das Modell jedoch ohne Bereinigung auf eine Codebasis mit unklaren Modulgrenzen loslässt, steigen die Token-Kosten um das Sechsfache. Ein Modell, das globale Factory-Klassen nicht versteht, fordert unpassende Null-Pointer-Prüfungen und erzeugt Halluzinationen. In dem Moment, in dem sich nutzlose Kommentare anhäufen, schalten Entwickler Benachrichtigungen ab und verfallen in Alarmmüdigkeit.
Man muss eine Vorverarbeitungspipeline schreiben, die das standardmäßige Python-ast-Modul verwendet, um nur geänderte Funktionssignaturen und betroffene lokale Variablen herauszufiltern. Nach dem Bereinigen der statischen Metadaten werden nicht funktionsbezogene Änderungen, die nichts mit der Modifikation zu tun haben, durch einen Hash-Vergleich verworfen. Anschließend werden die Signatur des untersten Funktionsknotens, der die geänderten Zeilen enthält, sowie die tatsächlichen Änderungsaussagen rückgeparst, um eine leichte JSON-Nutzlast zu erstellen.
Führt man einen Benchmark mit 100 Legacy-Modulen durch, ist der Unterschied deutlich. Die Einspeisung roher Dateien verbraucht 42.000 Token und 0,273 Dollar pro PR. Im Gegensatz dazu sinkt der Wert bei Verwendung der AST-Vorverarbeitung und JSON-Komprimierung auf 6.100 Token und 0,068 Dollar pro PR. Die API-Kosten sinken um 47,3 Prozent und die Rate halluzinatorischer Falsch-Positiver sinkt ebenfalls auf 9,4 Prozent.
Wie man Endlosschleifen zwischen Agenten mit einem Zustandsmaschinen-Schema bricht
Verbindet man Sicherheitsagenten und Business-Logic-Agenten in einem interaktiven Gruppenchat, schießen sie sich die Ausgaben gegenseitig zu und geraten in eine endliche Ping-Pong-Schleife. Die Analyse eines einzelnen PRs dauert viele Minuten und die API-Kosten schießen in die Höhe. Man darf Agenten nicht direkt miteinander kommunizieren lassen. Unter Verwendung von Pydantic-Schemata und LangGraph muss ein Framework für endliche Zustandsmaschinen aufgebaut werden.
Jeder spezialisierte Agent erhält nur den zentralen Pipeline-Status und gibt das Ergebnis seiner Beurteilung gemäß den Regeln seiner Domäne ausschließlich in einem festgelegten Modellformat zurück. Mit Pydantic wird eine Datenklasse definiert, die Kennungen, Dateipfade, Schweregrade und Konfidenzwerte der Agentenausgaben erzwingt. Es wird eine bedingte Kante eingerichtet, die die Zustandsmaschine zwangsweise abbricht, wenn die Anzahl der Wiederholungen 2 erreicht oder die Konfidenz aller Kommentare auf 0,85 oder höher konvergiert.
Gemäß dem Standard der OpenTelemetry GenAI Semantic Conventions sollte die Ausführung jedes Agenten in einen eindeutigen Span eingepackt und die Token-Nutzung in einem Backend für Distributed Tracing hinterlassen werden. Durch die Anwendung dieser Struktur wird die Debugging-Zeit des Tech Leads, die zuvor für das Beheben von Agentenfehlfunktionen aufgewendet wurde, um über 6 Stunden pro Woche reduziert.
Wie man mit einem Whitelist-Validierungsskript eine Akzeptanzrate der Entwickler von 70 Prozent erreicht
Laut Betriebsdaten von Googles internem statischen Analysetool Tricoder wächst die Feindseligkeit der Entwickler, wenn sie das Gefühl haben, dass ein Tool keine Korrekturen wert ist – egal wie präzise die Hinweise sind. Prüfer mit einer Rate gültiger Falsch-Positiver von über 5 Prozent werden sofort ausgemustert. Damit über 67 Prozent der automatischen Review-Kommentare akzeptiert werden, ist ein schrittweiser Rollout erforderlich, der bei Modulen mit geringem Risiko beginnt.
Schichten ohne Nebenwirkungen, wie DTO-Validierungsschichten und reine Funktionen, werden ausgewählt, um Kommentare in einem dreiwöchigen Shadow-Modus auszublenden. Nach Bestätigung einer Präzision von 85 Prozent werden Inline-Kommentare im Backend-Code von drei Domain-Squads freigegeben und die Akzeptanzrate wird verfolgt. Feedback-Protokolle werden wöchentlich gesammelt, um ein Feedback-Loop-Skript auszuführen, das Regeln mit hohen Falsch-Positiv-Raten, deren Akzeptanzrate unter 67 Prozent liegt, automatisch von der Whitelist entfernt und in eine Isolationsliste wirft. Wenn dieses Whitelist-Validierungsskript fest in die Pipeline eingebaut wird, werden die nervigen, nutzlosen Regeln der Entwickler schnell herausgefiltert, wodurch eine Akzeptanzrate des Review-Systems im Team von 70 Prozent erreicht werden kann.