Kategorie: Erklärer

Wie viel Autonomie sollte ein KI-Agent bekommen? Das ist keine theoretische Frage mehr, sondern eine operative Entscheidung. Viele Teams stehen vor einer binären Wahl: Vollzugriff oder read-only. Vollzugriff ist riskant, weil Agenten unvorhersehbar scheitern können. Read-only lässt den größten Teil des Nutzens ungenutzt.

Die Differenz zwischen dem, was ein Agent tun könnte, und dem, was ein Betreiber ihm zutraut, nennen Dev Arora, Meera Kezhukoot und Sathish Kumar Prabakaran in einem Beitrag im AWS-Architecture-Blog die Vertrauenslücke. Der Text stammt damit von AWS selbst und beschreibt das Muster entlang der hauseigenen Dienste wie Amazon Bedrock AgentCore – eine Herstellerperspektive, auch wenn das Grundmuster übertragbar ist. Um sie zu schließen, schlagen sie ein architektonisches Muster vor: abgestufte Autonomie. Agenten verdienen sich erweiterte Berechtigungen durch nachgewiesene Zuverlässigkeit – und verlieren sie wieder, wenn die Leistung nachlässt. Klingt nach einem vernünftigen Prinzip. Aber wie setzt man das technisch um?

Die Vertrauenslücke und die sechs Schichten des Frameworks

Herkömmliches Identity and Access Management beantwortet die Frage „Wer darf was?“ genau einmal, bei der Bereitstellung. Dieses Modell setzt voraus, dass sich ein Prinzipal konsistent verhält. Ein Agent auf Basis eines großen Sprachmodells bricht diese Annahme. Derselbe Agent kann am Montag präzise arbeiten und am Dienstag nach einer Prompt-Änderung oder einem Modell-Update halluzinieren.

Um die Lücke zu schließen, braucht es drei Fähigkeiten, die rohe API-Logs kaum liefern. Erstens: Sichtbarkeit. Logs zeigen Ingenieuren, was passiert ist, sagen einem Compliance-Verantwortlichen aber nichts darüber, ob eine Aktion sicher war. Zweitens: Entscheidungsherkunft. Man muss eine Aktion zurückverfolgen können zu dem Signal, das sie ausgelöst hat, zu den betrachteten Alternativen und zur Konfidenz des Agenten. Drittens: Umkehrbarkeit. Der Zustand vor der Aktion muss erfasst werden, damit Betreiber falsche Handlungen rückgängig machen können.

Der Beitrag beschreibt ein Framework aus sechs architektonischen Schichten, das genau diese drei Fähigkeiten liefert. Jede Schicht übernimmt eine klar abgegrenzte Aufgabe. Das gesamte System ist als geschlossener Regelkreis konzipiert. Vertrauen wird nicht einmalig zugewiesen, sondern laufend neu verdient.

Das Framework besteht aus einer Scoring-Engine, einem Stufensystem, einer Pre-Execution-Schicht, einer Enforcement-Schicht, einer Post-Execution-Schicht und einem Delivery-Gate. Die Scoring-Engine berechnet einen gewichteten Vertrauensscore. Das Stufensystem übersetzt dauerhafte Scores in Autonomiestufen. Die Pre-Execution-Schicht blockiert gefährliche Aktionen, bevor sie ausgeführt werden. Die Enforcement-Schicht setzt die Stufen über Cedar-Richtlinien auf Infrastrukturebene durch. Die Post-Execution-Schicht bewertet Ergebnisse, protokolliert Entscheidungen und speist Signale zurück in die Scoring-Engine. Das Delivery-Gate hält degradierte Agentenversionen aus der Produktion fern.

Jede Schicht ist austauschbar. Die Scoring-Modelle, Stufengrenzen, Pre-Execution-Signale und Bewertungskriterien sind Konfiguration, kein Code. Das erleichtert die Anpassung an eigene Anforderungen. Wer das Muster verstehen will, sollte sich die zentrale Designentscheidung jeder Schicht ansehen. Genau das tun die Autoren in den weiteren Abschnitten.

Scoring-Engine: Vertrauen messbar machen

Die Scoring-Engine bewertet jeden Agenten über ein rollierendes Fenster von 50 Aktionen. Daraus entsteht ein gewichteter Score zwischen 0 und 100. Fünf Dimensionen fließen ein: Korrektheit mit 25 Prozent, Sicherheit mit 20 Prozent, Konsistenz mit 20 Prozent, Compliance mit 20 Prozent und Effizienz mit 15 Prozent. Korrektheit misst, ob Aufgaben erwartungsgemäß abgeschlossen wurden. Sicherheit erfasst, ob Grenzen respektiert, gegnerische Inhalte erkannt und erlaubte Werkzeuge verwendet wurden.

Konsistenz bewertet die Verhaltensvorhersagbarkeit, also die Abweichung des Werkzeugnutzungsmusters. Compliance prüft die Qualität der Begründung vor der Handlung und das Einhalten von Guardrails. Effizienz zählt unnötige Wiederholungen und Ressourcenverschwendung. Der zusammengesetzte Score treibt Dashboards und Stufenzuweisungen. Doch Sicherheit wirkt als unabhängige Untergrenze. Ein gefährlicher Einzelwert kann nicht durch starke andere Kennzahlen weggemittelt werden.

Die Sicherheitsuntergrenze zieht sich durch das gesamte Framework. Ein Agent, der bei Korrektheit glänzt, aber regelmäßig Sicherheitsgrenzen überschreitet, bleibt unten. Vertrauen wird so nicht zu einem bloßen Rechenexempel.

Vom T1 bis T4: Das Stufensystem der Autonomie

Jeder neue Agent startet auf Stufe T1, der Bewährungsstufe, unabhängig von Testergebnissen. In T1 sind nur Lese- und Auflistungsrechte erlaubt, und es stehen zwei Werkzeuge zur Verfügung. Steigt der Score auf 41 bis 70, erreicht der Agent T2 und darf Schreiboperationen ausführen, wobei der Mensch bei hohen Risiken zustimmen muss. Ab einem Score von 71 bis 90 gilt T3 als vertrauenswürdig: Der Agent darf ausführen und ändern, Anomalien werden zur Überprüfung markiert. Die höchste Stufe T4 ab 91 erlaubt vollen Zugriff – nur noch eine nachträgliche Prüfung findet statt.

Drei Regeln steuern die Übergänge. Erstens: Eine Beförderung erfordert anhaltende Leistung. Der Score muss während des gesamten rollierenden Fensters über der Beförderungsschwelle liegen. Zweitens: Eine Herabstufung erfolgt sofort. Sobald die Sicherheit unter ihre Untergrenze fällt oder eine Injektion erkannt wird, sinkt der Agent. Drittens: Hysterese verhindert Oszillation. Für den Aufstieg in eine Stufe sind fünf Punkte über dem Mindestwert nötig. Die Herabstufung passiert dagegen schon an der Untergrenze selbst.

Der Vertrauenszustand liegt in Amazon DynamoDB, als aktueller Datensatz plus Zeitserienverlauf pro Agent. Die Durchsetzungskomponenten lesen die aktuelle Stufe bei jedem Aufruf. DynamoDB liefert diesen Lookup typischerweise im einstelligen Millisekundenbereich. Diese Geschwindigkeit ist nötig, denn Vertrauen muss in Echtzeit wirken.

Zwei Verteidigungslinien: Pre-Execution und Enforcement

Eine Bewertung nach der Ausführung kann Schaden nicht mehr rückgängig machen. Deshalb bewertet die Pre-Execution-Schicht jeden Werkzeugaufruf und kann ihn blockieren, bevor er ausgeführt wird. Sechs Signale fließen in diese Bewertung ein. Zuerst die Erkennung von gegnerischen Injektionen: Bekannte Injektionsphrasen lösen sofort eine Blockierung und eine Vertrauensstrafe aus. Dazu kommt die Erkennung sensibler Ziele durch Regex-Abgleich von Zugangsdaten, Tokens und privaten Schlüsseln in Werkzeugargumenten.

Gefährliche Werkzeuge werden über Muster erkannt, die auf destruktive Operationen hinweisen. Die Verhaltenskonsistenz vergleicht den aktuellen Werkzeugaufruf mit der historischen Verteilung der Werkzeugnutzung des Agenten. Die Konfidenzkalibrierung prüft, ob die angegebene Konfidenz zur tatsächlichen Genauigkeit passt. Übermäßig selbstsichere Fehler werden doppelt so stark bestraft. Schließlich wird die Begründungsqualität geprüft: Hat der Agent vor der Handlung eine Begründung geliefert?

Diese Checks sind schnelle Erstfilter, keine vollständige Verteidigung. Die Autoren betonen, dass die Enforcement-Schicht mit ihren Deny-by-default-Richtlinien alles abfangen muss, was die Pre-Execution-Schicht übersehen hat. Zwei Verteidigungslinien also. Die erste ist schnell und pragmatisch, die zweite ist hart und prinzipientreu.

Die Pre-Execution-Schicht ist Anwendungscode innerhalb des Agentenprozesses. Die Enforcement-Schicht arbeitet außerhalb, auf Infrastrukturebene. AgentCore Gateway, eine Fähigkeit von Amazon Bedrock AgentCore, sitzt zwischen dem Agenten und seinen Werkzeugen. Jede MCP-Werkzeuginvokation wird durch Policy in Amazon Bedrock AgentCore geleitet, das Cedar-Richtlinien mit Forbid-Wins-Semantik auswertet. Eine einzige erfüllte Forbid-Regel überstimmt beliebig viele Permit-Regeln.

Die Stufe des Agenten bildet sich direkt im Richtlinienzustand ab. Auf der Bewährungsstufe blockiert eine Forbid-Richtlinie Schreib-, Ausführungs- und Löschaktionen. Nach einer Beförderung wird die Forbid-Richtlinie entfernt und breitere Permits treten in Kraft. Bei einer Herabstufung wird die Forbid-Richtlinie wieder aktiviert. Im Enforce-Modus listet das Gateway nur die Werkzeuge auf, die die Richtlinie erlauben würde. Ein Agent ruft ein Werkzeug, das er nie gesehen hat, höchstwahrscheinlich nicht auf.

Das Auflisten ist eine Meta-Aktion. Jede Invokation wird trotzdem einzeln und mit vollem Kontext bewertet, einschließlich Eingabeparametern. Cedar verweigert standardmäßig. Die Durchsetzung hängt also nie von der Bereitschaft des Agenten ab, sich zu benehmen. Für die Sicherheit auf Modellebene ergänzt Amazon Bedrock Guardrails die Policy-Schicht und filtert schädliche Inhalte sowie sensible Informationen, unabhängig von der Stufe.

Nach der Tat: Post-Execution, Audit-Trail und Delivery Gate

Nach jedem Werkzeugaufruf bewertet das System das Ergebnis anhand von acht Signalen. Dazu gehören Konfidenzkalibrierung, Verhaltensdrift, menschliche Übersteuerungen und die Erkennung von unnötigen Wiederholungen. Jede Aktion erzeugt einen Audit-Datensatz, der die Kette Think, Plan, Act, Observe, Score abbildet. Think steht für die Gedankenkette des Agenten. Plan enthält das ausgewählte Werkzeug, die vorbereiteten Eingaben und den Pre-Execution-Score.

Act protokolliert, welche Cedar-Richtlinie gegriffen hat und wie die Gateway-Route verarbeitet wurde. Observe hält Erfolg oder Misserfolg sowie die Ausgabedaten fest. Score erfasst die Vertrauenswirkung, die Einzeldimensionen und die Stufenänderung. Genau die Plan- und Act-Aufzeichnungen machen eine Wiederherstellung möglich, weil sie den Zustand vor der Aktion festhalten. Ohne diese Information kann man eine falsche Handlung nicht gezielt rückgängig machen.

Betreiber können Fragen in natürlicher Sprache stellen. Ein Provenance-Query-Endpunkt liefert eine menschenlesbare Erklärung jeder Entscheidung. Die Audit-Einträge landen dauerhaft in DynamoDB. Diese Nachvollziehbarkeit ist mehr als Compliance-Pflicht. Sie schafft die Grundlage dafür, dass Menschen einem Agenten mehr Autonomie zugestehen können.

Zur Nachvollziehbarkeit im Betrieb kommt die Qualitätssicherung vor dem Deployment. Jede Änderung am Prompt, an der Konfiguration oder an den Werkzeugdefinitionen des Agenten löst einen AWS-CodePipeline-Lauf aus. Die Pipeline deployed den Kandidaten in einer Staging-Umgebung und führt ihn gegen Ground-Truth-Testfälle aus, unterstützt durch Amazon Bedrock AgentCore Evaluations. Die Testfälle enthalten gegnerische Szenarien wie Prompt-Injection und Datenexfiltration. Ein einziger unbefugter Werkzeugaufruf in einem dieser Fälle lässt den Lauf scheitern. Die Version, die besteht, wird zur letzten bekannten stabilen Version erklärt.

Im laufenden Betrieb injiziert das Framework synthetische Honeypot-Fälle mit bekanntem erwartetem Verhalten in einen kleinen Teil des Datenverkehrs. Die Validierung prüft die Werkzeugaufruf-Trajektorie: erwartete Werkzeuge, erwartete Reihenfolge, keine verbotenen Werkzeuge. Natürlichsprachige Ausgaben sind nicht deterministisch, aber die Trajektorie muss stimmen. Eine Abweichung signalisiert eine echte Anomalie. Die Honeypot-Ergebnisse fließen nicht in die Produktionsmetriken ein.

Sinkt die Sicherheitsuntergrenze, wird der Agent herabgestuft und die letzte bekannte stabile Version erneut bereitgestellt. So kehren bekanntermaßen guter Code und ein engerer Berechtigungssatz gemeinsam zurück. Gleichzeitig werden die Betreiber alarmiert. Deren Urteil fließt direkt in das System ein: Die Quote der abgelehnten Aktionen deckelt die effektive Sicherheitsmetrik. Wenn Betreiber 30 Prozent der Aktionen ablehnen, ist die Sicherheit bei 70 Prozent gedeckelt.

Für den Notfall gibt es einen Stopp-Knopf. Ein einziger Cedar-Deny-All-Richtlinienbefehl wird verbreitet und aktiviert sich in der Regel innerhalb von Sekunden. Das Gateway verweigert dann alle Werkzeugaufrufe ohne neue Bereitstellung. In Multi-Agenten-Systemen gilt: Die effektive Stufe einer delegierten Aktion ist das Minimum über die gesamte Delegationskette. Damit ist der Privilegien-Eskalationspfad über Delegation geschlossen.

Was das konkret bedeutet

Abgestufte Autonomie ist kein theoretisches Modell, sondern ein umsetzbares Architekturmuster. Es umgeht die binäre Wahl zwischen Vollzugriff und Read-only, indem es Vertrauen als kontinuierliche Größe behandelt. Agenten bekommen genau so viel Freiheit, wie ihr nachgewiesenes Verhalten rechtfertigt. Und sie verlieren diese Freiheit wieder, wenn sie sie missbrauchen.

Für Teams, die das einführen wollen, geben die Autoren eine konkrete Startempfehlung: Dimensionen, Gewichte und Stufengrenzen aus den Tabellen als Ausgangsvorlage für einen einzigen Agenten nehmen. Diesen Agenten auf T1 starten. Dann den Delivery-Gate-Prozess mit Amazon Bedrock AgentCore Evaluations aufbauen und die Stufenrichtlinien mit Policy in Amazon Bedrock AgentCore umsetzen. Das Muster lässt sich iterativ anpassen.

Fazit: Vertrauen in KI-Agenten ist kein einmalig vergebenes Gut. Es ist ein Betriebszustand, den man messen, überwachen und durchsetzen muss. Wer das akzeptiert, kann Agenten sicherer betreiben und gleichzeitig mehr von ihrem Potenzial nutzen. Wer es ignoriert, wird sich zwischen Risiko und Nutzlosigkeit entscheiden müssen.

Quelle: aws.amazon.com

KI-Assistenten produzieren Code, der plausibel aussieht – aber ohne Begrenzung driften sie ab. Das ist die Beobachtung, die Birgitta Boeckeler in ihrem Artikel auf martinfowler.com beschreibt, und sie dürfte jedem Team bekannt vorkommen, das KI-Coding-Assistenten ernsthaft einsetzt. Der Code kompiliert, die Tests laufen grün, und trotzdem verschlechtert sich die interne Konsistenz der Codebasis langsam aber sicher. Naming-Konventionen werden aufgeweicht, Architekturregeln umgangen, und irgendwann ist das Projekt ein Flickenteppich, den kein Mensch mehr überblickt. Das Tückische: Der Verfall ist leise. Er passiert nicht auf einen Schlag, sondern in vielen kleinen, plausibel wirkenden Abweichungen, die keine bestehende Prüfung bemerkt.

Ein Harness für KI-Code: Die Logik der Tests übertragen

Die Lösung liegt in einer Übertragung einer alten Idee. Tests machen Code nicht korrekt, indem sie ihn erstellen; sie erkennen, wenn er aufhört, korrekt zu sein. Ein Test-Harness ist kein Zwang, der den Entwickler einschränkt, sondern ein Mechanismus, der fortlaufend prüft, ob das Geschriebene den Standard erfüllt. Diese Logik lässt sich auf die KI-gestützte Entwicklung übertragen – nur mit einem breiteren Prüfumfang. Während Tests funktionale Korrektheit abfragen, braucht es für KI-generierten Code eine Harness, die auch Architekturentscheidungen, Namenskonventionen, Sicherheitsregeln und strukturelle Vereinbarungen überwacht. Genau das nennt Boeckeler Harness Engineering. Von ihr stammen Begriff und Grundgedanke. Alles Weitere in diesem Text — die drei Säulen, die Reifegrade, die Schleifen — ist die Ausgestaltung des Plugins ai-literacy-superpowers, dessen Dokumentation die Quelle dieses Beitrags ist.

Der Unterschied ist entscheidend. Ein funktionaler Test sagt dir, ob das Programm das tut, was es soll. Er sagt dir nicht, ob die neue KI-generierte Funktion die Abstraktionsschicht für Datenbankzugriffe umgangen hat oder eine veraltete Logging-Bibliothek benutzt, die im Projekt längst abgeschafft wurde. Solche Verstöße bleiben unter dem Radar funktionaler Tests, weil das Programm weiterhin korrekt arbeitet – bis später jemand an der falschen Stelle refactort. Ein Harness für KI-Code schließt genau diese Lücke. Er ist das Sicherheitsnetz, das die unsichtbaren Abweichungen sichtbar macht.

Die drei Säulen: Kontext, Architektur, Entropie

Der Kern von Harness Engineering besteht aus drei Komponenten, die zusammenwirken. Die erste ist Context Engineering: Die KI kann nur mit dem arbeiten, was sie weiß. Kennt sie die projekteigene Logging-Bibliothek nicht, erfindet sie eine eigene. Weiß sie nicht, dass globaler Zustand strikt verboten ist, benutzt sie ihn, sobald es bequem erscheint. Deshalb muss der Harness dem KI-Assistenten eine Wissensbasis liefern – in der Praxis ein Dokument namens HARNESS.md, das den Stack, die Architekturentscheidungen, Namenskonventionen und deren Begründung festhält. Das ist kein README für Menschen, sondern ein Kontextdokument für die Maschine, und es muss präzise und aktuell sein.

Die zweite Säule sind Architektur-Constraints. Dass die KI die Regeln kennt, heißt nicht, dass sie sie befolgt. Ein KI-Assistent ist ein probabilistisches System, das Plausibilität optimiert, kein regelbefolgender Roboter. Context Engineering reduziert Verstöße, eliminiert sie aber nicht. Deshalb braucht es Verifikationsslots – definierte Momente im Workflow, in denen eine Prüfung läuft und entweder grün gibt oder den Fortschritt blockiert. Die entscheidende Frage ist dabei, ob die Prüfung mit einem deterministischen Tool wie einem Linter oder Skript erfolgt oder mit einem agentenbasierten Review durch ein Sprachmodell. Deterministische Checks sind schnell und zuverlässig, wenn sich die Regel präzise ausdrücken lässt. Agenten sind teurer und unzuverlässiger, können aber auch semantische Verstöße erkennen, die kein Skript abbilden kann.

Die dritte Säule ist Garbage Collection, das Aufräumen. Eine Codebasis ist ein lebendes System, in dem mit der Zeit Entropie entsteht: toter Code, veraltete Abhängigkeiten, TODO-Kommentare, die niemand mehr anfasst, Konventionen, die still beerdigt wurden. Anders als die ersten beiden Komponenten arbeitet diese nicht beim Schreiben oder Reviewen, sondern nach Zeitplan. Regelmäßig – täglich, wöchentlich – prüfen Agenten oder Skripte, ob die Codebasis bestimmte Sauberkeitskriterien noch erfüllt. Der Output ist keine PR-Blockade, sondern ein Bericht, der auf akkumulierende Probleme aufmerksam macht, bevor sie kritisch werden.

Der lebendige Harness: Selbstreferenz als Feedback-Schleife

Der wichtigste Unterschied zu statischen Regelwerken ist, dass ein Harness selbst lebendig bleibt. Ein einmal geschriebenes Harness-Dokument spiegelt den Wissensstand des Teams zu einem bestimmten Zeitpunkt. Die Codebasis entwickelt sich weiter, neue Muster entstehen, alte Regeln verlieren ihre Bedeutung, und neue KI-Fehler tauchen auf, die ursprünglich niemand vorhergesehen hat. HARNESS.md ist deshalb selbstreferentiell aufgebaut: Es beschreibt nicht nur die geltenden Constraints, sondern auch deren Status – ob sie ungeprüft, per Agent oder deterministisch durchgesetzt werden. Dieses Dokument deklariert, was wahr sein soll; Agenten, Hooks und CI-Checks verifizieren, ob es wahr ist. Der Harness-Audit, ein geplanter Agent, liest die Ergebnisse und aktualisiert die Statuseinträge – so entsteht eine Feedback-Schleife.

Die Selbstreferenzialität ist das, was einen lebendigen Harness von einem toten Dokument unterscheidet. Weil der Harness selbst Gegenstand der Durchsetzung ist – der Audit prüft, ob HARNESS.md den Realzustand korrekt abbildet – wird Vernachlässigung sichtbar statt unsichtbar. Der Alltagszugang zu dieser Selbstkontrolle ist der Befehl /harness-sync, der die Erkennungslogik des Audits ausführt und eine einheitliche Abweichungstabelle präsentiert. Du siehst dann auf einen Blick, wo deklarierte Regeln und tatsächliche Verifikation auseinanderlaufen, ohne ein separates Diagnosetool bemühen zu müssen. Das ist praktische Transparenz.

Progressive Härtung: Vom Bekenntnis zur harten Regel

Nicht jede Constraint ist von Anfang an bereit für eine deterministische Durchsetzung. Progressive Hardening ist die Karriereleiter, auf der Regeln sich entwickeln. Am Anfang steht der Zustand Unverified: Du hast eine Regel in HARNESS.md notiert, weil du sie für wichtig hältst, aber es gibt noch keinen Mechanismus, sie zu prüfen. Das ist kein Scheitern, sondern ehrliche Buchführung – ein ungeprüfter Constraint ist ein Versprechen, eine Prüfung zu bauen, nicht die Behauptung, dass bereits eine existiert.

Der nächste Schritt ist Agent. Jetzt gibt es einen Agent-Prompt, der die Regel beim PR-Review oder in einer regelmäßigen Inspektion prüft. Der Agent ist ein Sprachmodell, das ein Urteil fällt – er erwischt die meisten Verstöße, ist aber nicht perfekt und braucht menschliche Kontrolle. Irgendwann folgt der Zustand Deterministic: Du hast die Regel präzise genug formuliert, um sie als Skript, Linter-Regel oder Strukturcheck zu kodieren. Sie läuft in CI, gibt entweder grün oder blockiert den Merge – ohne Urteilsvermögen, aber auch ohne Verwechslungsgefahr. Die Bewegungsrichtung ist immer von weich nach hart. Wenn ein Agent immer wieder dieselbe Verletzungsklasse findet, ist das ein Signal: Das Muster ist jetzt verstanden genug für Automatisierung. Schreib das Skript, pensioniere den Agenten für diese konkrete Regel, und aktualisiere den Status in HARNESS.md.

Progressive Härtung verhindert zwei Fehlermodi. Der erste wäre der Versuch, von Anfang an alles deterministisch durchzusetzen – das scheitert an neuartigen oder semantisch komplexen Regeln. Der zweite wäre, Agenten als Dauerzustand zu akzeptieren – das ist teuer und unzuverlässig. Die Leiter gibt dir einen Pfad dazwischen. In der Praxis heißt das: Wer klug härtet, gewinnt mit der Zeit ein Regelwerk, das immer weniger Nachsehen braucht.

Drei Schleifen: Wie die Umsetzung konkret aussieht

Damit das Ganze nicht graue Theorie bleibt, setzt ai-literacy-superpowers die Verifikationsslots in drei Durchsetzungsschleifen um, die sich in Frequenz und Härte unterscheiden. Die innere Schleife arbeitet beraterisch zur Bearbeitungszeit. Wenn du eine Datei speicherst oder eine Coding-Session abschließt, laufen leichte Checks, die potenzielle Probleme als Vorschlag anzeigen – nicht als Blockade. Sie ist auf geringen Reibungsverlust optimiert und soll deinen Fluss nicht unterbrechen, sondern Probleme früh sichtbar machen.

Die mittlere Schleife ist streng und läuft zur PR-Zeit. Beim Öffnen eines Pull Requests kommt eine volle Suite aus Agenten- und Deterministischen Checks zum Einsatz. Diese Schleife darf einen Merge blockieren. Sie ist der Hauptdurchsetzungspunkt für Architektur-Constraints. Fehler hier müssen behoben werden, bevor der Code landet. Die äußere Schleife schließlich ist investigativ und arbeitet nach Zeitplan: Garbage-Collection-Regeln, Fitness-Funktionen und Harness-Audits laufen täglich oder wöchentlich. Sie erzeugt Berichte statt Blockaden, und ihre Erkenntnisse fließen als neue Constraints oder Updates zurück in den Harness.

Die drei Schleifen korrespondieren mit den drei Säulen: Die innere dient dem Context Engineering – sie hält die KI im Moment informiert. Die mittlere dient den Architektur-Constraints – sie erzwingt Standards beim Integration-Zeitpunkt. Die äußere dient der Garbage Collection – sie erkennt langsame Entropie zwischen Integrationsereignissen. Wichtig ist: Agenten im Plugin arbeiten mit begrenztem Vertrauen. Kein Agent hat einseitig die Macht, Produktionscode zu ändern oder Merges zu beschließen. Agenten prüfen, schlagen vor, berichten und markieren. Menschen entscheiden. Das ist eine bewusste Designentscheidung: Der Harness verstärkt menschliches Urteilsvermögen, er ersetzt es nicht.

Dazu kommt eine selbst-verbessernde Dimension. Nach jeder Coding-Session protokolliert der Befehl /reflect, was gut lief, was scheiterte, welche Konventionen verletzt wurden und welche neuen Muster auftauchten. Diese Reflexionen sammeln sich in einem Log, das die Harness-Agenten bei ihren Entscheidungen lesen. So beeinflussen vergangene Fehler die aktuelle Review. Auch die Regressionserkennung wirkt in dieselbe Richtung: Der Harness-Audit prüft nicht nur, ob aktuelle Constraints erfüllt sind, sondern ob die Abweichungsmuster sich wiederholen. Das Harness lernt also aus seiner eigenen Betriebsgeschichte – ein evolutionärer Vorteil, den statische Regelwerke nie haben.

Was das für deine Arbeit bedeutet

Harness Engineering ist keine Zauberei, sondern eine konsequente Anwendung alter Ingenieursprinzipien auf eine neue Generation von Werkzeugen. Du musst keine KI haben, die perfekt ist – du brauchst einen Rahmen, der ihre Schwächen abfängt. Der Preis ist Arbeit: Ein Kontextdokument führen, Constraints formulieren, Checks pflegen, Audits lesen. Der Gewinn ist ein weitgehend ruhigeres Gewissen beim Einsatz von KI-Coding-Assistenten. Der Code bleibt kohärent, nicht weil die KI immer richtig liegt, sondern weil dein Harness die Abweichungen sichtbar macht und in geordnete Bahnen lenkt.

Die konkrete Bedeutung für deinen Alltag: Wenn du mit KI-Assistenten arbeitest, solltest du nicht nur auf Tests vertrauen. Du brauchst eine zweite Ebene aus Kontext, Constraints und regelmäßigem Aufräumen. Starte mit einem HARNESS.md, dokumentiere die wichtigsten Architekturregeln, führe einen einfachen Agent-Check bei PRs ein, und härtete nach und nach die Regeln, die sich wiederholen. So nutzt du die Produktivität der KI, ohne ihre Drift zu erben. Das ist die eigentliche Superpower – nicht die KI selbst, sondern die Disziplin, sie in einen stabilen Rahmen zu zwingen.

Quelle: habitat-thinking.github.io

Ein Coding-Agent durchsucht das Projektverzeichnis, zieht Ausschnitte aus früheren Sessions und führt nach einigen gezielten Editierungen die Testsuite aus. Er meldet zurück, alles sei grün – und doch wäre es fahrlässig, das als Beleg für korrektes Arbeiten zu nehmen.

Agentic Engineering verlagert das Vertrauen vom Selbstbericht des Modells auf die Struktur des Systems, in dem es arbeitet. Wer schon einmal mit Coding-Agents gearbeitet hat, kennt das Muster: Das Modell formuliert einen Plan, schreibt Code und besteht darauf, dass alle Prüfungen bestanden sind. Scott Spence fasst es in seinem Leitfaden so: Agentic Engineering bettet Coding-Agents in ein technisches System ein, das Kontext, Umfang, Validierung, Beweise und menschliche Überprüfung explizit macht. Das Modell darf planen und Code schreiben, aber es darf nicht selbst bestimmen, dass seine Arbeit korrekt ist.

Was ist Agentic Engineering? Eine Definition für die Praxis

Agentic Engineering ist Softwareentwicklung, bei der Agents wesentliche Teile des Entwicklungszyklus übernehmen, während Ingenieure die Umgebung gestalten, in der diese Arbeit stattfindet. Ein Coding-Agent kann ein Repository durchsuchen, Dokumentation lesen, Dateien editieren, Befehle ausführen und auf die Ergebnisse reagieren. Das macht ihn mächtiger als eine Autovervollständigung – aber Fehler bekommen einen Ort, an dem sie sich festsetzen. Eine falsche Annahme wird zu einer Codeänderung. Eine fehlende Randbedingung wird zu einer neuen Abhängigkeit. Und eine selbstbewusste Zusammenfassung kann behaupten, dass die Validierung erfolgreich war, obwohl der entscheidende Test nie lief.

Die eigentliche Arbeit verschiebt sich eine Ebene nach oben. Du kümmerst dich nicht mehr nur um den Code, sondern auch darum, wie der Agent den passenden Kontext findet, welche Aktionen er ausführen darf, wie eine Aufgabe begrenzt ist, welche Prüfungen er nicht stillschweigend überspringen kann und wie Fehler aufgezeichnet werden. Dazu kommen die Fragen, die sich bei jeder Zusammenarbeit stellen: Wer prüft das Ergebnis – ein anderer Agent oder ein Mensch – und was passiert, wenn der ursprüngliche Plan falsch war?

Populär wurde der Begriff durch Andrej Karpathy, der Anfang 2026 darüber reflektierte, dass sich die Programmierung mit Agents weiterentwickelt hat und seine frühere Beschreibung als „Vibe Coding“ nicht mehr ausreicht. Doch so neu der Name ist, so alt sind die dahinterliegenden Prinzipien: Spezifikationen, Werkzeuge, Berechtigungen, Tests, Beobachtbarkeit und Review – angewendet auf ein Arbeitsgerät, das schnell und nützlich, aber eben auch stochastisch ist. Das ist Agentic Engineering in der Praxis.

Vibe Coding vs. Agentic Engineering: Wo verläuft die Grenze?

Vibe Coding ist ergebnisorientiert und bewusst lose. Du beschreibst, was du willst, lässt das Modell etwas generieren, probierst das sichtbare Ergebnis aus und promptest so lange erneut, bis es sich richtig anfühlt. Für Prototypen, Wegwerf-Tools oder das Erkunden einer Idee kann das großartig sein. Das Problem entsteht, wenn du denselben Vertrauensmechanismus für Produktionssoftware nutzt.

Eine Produktionscodebasis hat Dinge, die eine schnelle Demo gut versteckt: Berechtigungen, Datenmigrationen, Fehlerbehandlung, Audit-Trails, Barrierefreiheit, Performance, bestehende Konventionen und Nutzer, die Dinge in falscher Reihenfolge tun. „Es hat funktioniert, als ich geklickt habe“ ist kein Beweis dafür, dass diese Systeme weiterhin funktionieren. Agentic Engineering behält die Geschwindigkeit, verändert aber die Abnahmekriterien. Der Agent darf weiterhin viel tippen – abgeschlossen ist die Arbeit erst, wenn die Checks des Repositories und die eigentlichen Erfolgsbedingungen der Aufgabe es bestätigen.

Die Grenze ist unscharf. Simon Willison hat darauf hingewiesen, dass sich Vibe Coding und Agentic Engineering im Laufe der Zeit annähern, wenn die Modelle besser werden und unüberwachte Erfolge das Vertrauen erhöhen. Die Gefahr liegt nicht in der zunehmenden Autonomie, sondern darin, dass wiederholter Erfolg die Kontrollen leise abschafft, die beim nächsten Lauf warnen. Der Unterschied zwischen Vibe Coding und Agentic Engineering ist keine Frage des Werkzeugs, sondern des Trust-Modells: Liegt das Vertrauen im Prompt-Gefühl oder im Kontrollsystem?

Der Baukasten für einen zuverlässigen Agentic-Engineering-Workflow

Der Workflow aus „my-pi“, einem Eigenbau-Setup, ist keine universelle Lösung, aber einige Bausteine haben sich in der Praxis bewährt. Zuerst muss der Agent die Quelle der Wahrheit rekonstruieren. Eine frische Session kennt nur den Prompt und den vom Harness eingefügten Kontext. Sie weiß nicht, warum eine Architektur gewählt wurde, was letzte Woche fehlschlug oder welche Nutzerkorrektur die Aufgabe verändert hat. Deshalb beginnt die Arbeit mit Recherche: Repository und lokale Anweisungen ansehen, aktuelle Implementierung und Tests finden, frühere Sessions durchsuchen, externe APIs aus Primärquellen recherchieren und Annahmen offenlegen.

Das Ziel ist nicht maximaler Kontext. Ein riesiges Instruction-File kann die eigentliche Aufgabe verdrängen. Relevant ist der Kontext, den der Agent bei Bedarf abrufen kann. Dafür gibt es den Session-History-Abruf „pirecall“ und einen SQLite-Kontext-Storage für große Tool-Ausgaben. Beides verwandelt eine Wand aus Text in etwas Durchsuchbares. Der zweite Baustein ist ausführbares Projektwissen. Eine AGENTS.md-Datei ist nützlich für stabile Regeln, aber sie ist kein Schutzschild. Wenn eine Regel so wichtig ist, dass ihr Verstoß die Codebasis beschädigen würde, dann formuliere sie als Typ, Lint-Regel, Boundary-Check, Test, Hook oder CI-Befehl. Prosa beschreibt, wie guter Code aussieht; deterministische Checks verhindern, dass ein plausibler Abkürzungsweg zur neuen lokalen Konvention wird.

Für Aufgaben mit materialem Risiko kommt ein externer Task-Harness zum Einsatz. Dieser hält die erlaubten Pfade, verbotenen Operationen, Validierungskommandos, Aufgabenstatus und gesammelte Beweise außerhalb des Arbeitskontexts des Ausführenden fest. Der Agent kann seinen Umsetzungsplan an neue Fakten anpassen, aber er kann nicht leise seine Berechtigungen erweitern oder lästige Prüfungen entfernen. Ein guter Harness beantwortet vier Fragen: Was darf sich ändern? Was darf nicht passieren? Wie wird Erfolg geprüft? Welche Beweise wurden gesammelt? Und wann sollte der Agent anhalten und um Hilfe fragen? Nicht jede Aufgabe braucht einen Harness – eine Rechtschreibkorrektur in eine Mini-Softwarefabrik zu verpacken ist Zeremoniell, nicht Sorgfalt.

Auch die Validierung gehört in die Hände des Agents. Ein Agent kann keinen Fehler beheben, den er nicht sieht. Deshalb sollten Typfehler, Unit- und Integrationstests, Browser-Checks, Lint-Ausgaben, Build-Ergebnisse und Language-Server-Diagnostik genauso verfügbar sein wie für einen menschlichen Entwickler. Das Hinzufügen von LSP-Unterstützung hat mehr gebracht als erwartet: Der Agent kann Diagnosen für die geänderte Datei anfordern, statt nach jedem Edit das ganze Projekt zu prüfen, und er kann Definitionen und Referenzen nachschlagen. Entscheidend ist, dass der Abschluss-Check nicht „der Agent sagt, dass es gut aussieht“ ist, sondern ein unabhängiger Befehl oder ein beobachtbares Ergebnis. Für eine Nutzerreise bedeutet das, die Seite tatsächlich zu laden und zu nutzen; für eine Migration, das resultierende Schema und die Daten zu inspizieren.

Telemetrie, Secrets und Multi-Agent-Betrieb

Wenn jede Session spurlos im Transkript verschwindet, lässt sich die Arbeit von Coding-Agents kaum verbessern. Der Autor hat deshalb lokale Telemetrie eingeführt, die Session, Modell und Werkzeugnutzung aufzeichnet, sowie durchsuchbare Session-History und fokussierte Evals, wenn sich eine Prompt-, Tool- oder Retrieval-Strategie ändert. Damit lassen sich konkrete Fragen beantworten: Hat der Agent das neue Tool genutzt? Hat er die richtige Quelle gefunden? Hat die Änderung verschwendete Ausgaben reduziert? Hat der Guard den Fehler abgefangen, für den er gebaut wurde? Evals sind nicht nur Checks gegen den letzten Absatz, den ein Agent schreibt. Entscheidend ist das Ergebnis. Ein Beispiel: Ein Flugbuchungs-Agent mag behaupten, den Flug gebucht zu haben, aber die eigentliche Frage ist, ob die Reservierung existiert. Bei Coding-Arbeit gilt dasselbe. Bewerte den Zustand des Repositories und die Nutzerreise, nicht die Selbstsicherheit der Zusammenfassung.

Ein weiterer Aspekt sind Secrets und Berechtigungen. Ein Coding-Agent mit Shell-, Dateisystem- und Netzwerkzugriff hat einen größeren Blast Radius als ein Chat-Fenster. Prompt Injection kann nicht nur über Nutzereingaben kommen, sondern auch über eine Webseite, ein Ticket, eine README-Abhängigkeit oder eine Tool-Antwort. Im Setup gelten schmale Tool-Berechtigungen, explizite Genehmigungsgrenzen und eine Implementierung namens „nopeek“, mit der ein Agent einen prozessabhängigen Befehl ausführen kann, ohne vorher die ganze .env-Datei in den Kontext zu drucken. Das macht nicht jede Kindprozess-Ausgabe sicher, beseitigt aber einen häufigen unnötigen Expositionspfad.

Mehrere Agents einzusetzen lohnt sich nur, wenn die Arbeit wirklich parallel ist: Ein Agent recherchiert eine API, während ein anderer die bestehende Implementierung kartiert, oder getrennte Agents arbeiten in isolierten Worktrees und ein Lead prüft die Ergebnisse. Wenn dagegen fünf Agents dieselben Dateien, Kontexte und Entscheidungen brauchen, schaffst du ein Koordinationsproblem und nennst es Skalierung. In seinem „Team Mode“ gelten die Prinzipien Eigentum, dauerhafte Übergaben und explizites Review. Delegation verschiebt die Verantwortung nicht auf eine schwarmförmige Wolke – der Lead muss das kombinierte Ergebnis weiterhin verstehen.

Erfahrungswerte: Was der Workflow tatsächlich bringt

Einen sauberen Benchmark hat der Autor nicht. Dafür gibt es Zahlen aus dem Betrieb: Zwischen dem 28. Juni und dem 25. Juli 2026 erzeugten Agents 173 aufgezeichnete Task-Harnesses in 104 Sessions und 10 echten Projekt-Workspaces. 144 davon erreichten mindestens einmal einen abgeschlossenen Zustand, 155 haben Validierungs- oder Review-Beweise aufgezeichnet, und 133 Enforcement-Blocks traten in 69 Sessions auf. Diese Zahlen beweisen nicht, dass jede abgeschlossene Änderung gut war. Sie zeigen aber, dass das System außerhalb einer Demo genutzt wurde, dass Agents regelmäßig überprüfbare Beweise erzeugten und dass durchsetzbare Grenzen tatsächliches Verhalten abfingen.

Die Zahlen offenbaren auch Schwächen: Manche verbotenen Kommandos-Muster waren zu grob, Pläne brauchten öfter legitime Ergänzungen als erwartet, veralteter Aufgabenstatus machte spätere Sessions verwirrend, und fehlgeschlagene Harnesses brauchten immer noch einen Menschen, der das Ergebnis interpretierte. Zudem wurden risikoarme Aufgaben langsamer, wenn sie durch dieselbe Zeremonie liefen. Agentic Engineering bedeutet also nicht „mehr Harness“, sondern genügend System für das Risiko und die Komplexität der jeweiligen Aufgabe. Für eine kleine Änderung reicht ein einfacher Workflow; für eine Migration braucht es die volle Kontrollstruktur.

Was nicht funktioniert – und warum

Einige Muster scheitern konsistent, egal welches Modell. Dazu gehört das härtere Prompting: Wiederholt zu sagen „nicht driften“, „sei vorsichtig“ oder „sorge dafür, dass die Tests laufen“ hilft für einen einzelnen Turn, erzeugt aber keine dauerhafte Kontrolle. Wenn eine Regel wichtig ist, gib ihr einen Test oder lege sie außerhalb der Autorität des Ausführenden ab. Ebenso scheitert das Prinzip „alles in den Kontext laden“. Mehr Kontext ist nicht automatisch besserer Kontext. Riesige Instruction-Files, jedes verfügbare MCP-Tool und komplette Session-Transkripte machen das relevante Signal schwerer auffindbar. Progressive Disclosure und durchsuchbare Quellen sind der Ausweg.

Auch das Selbst-Review des Agents gehört auf den Prüfstand. Es ist nützlich, aber nicht unabhängig. Ein Agent, der über die eigene Arbeit urteilt, ist leicht zu optimistisch. Deshalb braucht es externe Mechanismen wie Tests, Harness-Evidenz und menschliche Überprüfung. Das erinnert an die Qualitätssicherung in klassischen Ingenieurdisziplinen: Wer prüft, darf nicht derjenige sein, der gebaut hat. Und genau dieses Prinzip macht Agentic Engineering zu einer echten Ingenieursdisziplin.

Du kannst Coding-Agents vertrauen, wenn du das System, in dem sie arbeiten, kontrollierst. Das bedeutet nicht, jedem Agenten zu misstrauen. Es bedeutet: Die Entscheidung über die Korrektheit fällt nicht im Bauch des Modells, sondern in der Struktur, die du um es herum gebaut hast. Agentic Engineering ist in erster Linie Systemdesign – und erst danach die Arbeit mit dem nächsten Modell.

Quelle: scottspence.com

„Qwen-3-Coder-Next ist ein Modell mit 80 Milliarden Parametern und belegt 159,4 GB Speicher. Das ist ungefähr so viel RAM, wie du zum Ausführen bräuchtest – und da ist der Kontext noch gar nicht eingerechnet. Das gilt nicht einmal als großes Modell.“ Mit dieser Einordnung beginnt der Entwickler seinen Blogpost auf ngrok über Quantisierung. Heutige Spitzenmodelle bringen Gerüchten zufolge bereits über eine Billion Parameter mit, wofür mindestens 2 TB RAM nötig wären. Diese Hardware steckt in kaum einem normalen Rechner. Trotzdem, so seine Kernbotschaft, ließen sich große Sprachmodelle rund viermal kleiner und doppelt so schnell machen, sodass sie auf einem durchschnittlichen Laptop laufen – bei nur fünf bis zehn Prozent Genauigkeitsverlust. Quantisierung macht das möglich. Genau darum geht es in diesem Text.

Warum große Sprachmodelle so groß sind

Der Großteil dessen, was ein LLM auf der Festplatte oder im Arbeitsspeicher ausmacht, sind seine Parameter, oft auch Gewichte genannt. Wer schon einmal mit neuronalen Netzen zu tun hatte, kennt den Begriff. Für alle anderen: Parameter sind die gelernten Zahlen, die ein Modell dazu befähigen, Sprache zu verstehen und zu erzeugen. Ein neuronales Netz ist ein „enormes Diagramm aus Milliarden sorgfältig angeordneter Operationen“, wie der Autor es formuliert. Der einfachste Baustein besteht aus einem Eingabewert, der mit einem Parameter multipliziert wird und einen Ausgabewert erzeugt. Aus diesen Bausteinen setzen sich moderne KI-Systeme zusammen.

Modelle werden groß, weil sie Milliarden solcher Parameter besitzen und in Schichten organisiert sind. Jede Verbindung zwischen zwei Knoten hat ein eigenes Gewicht. Treffen mehrere Verbindungen an einem Knoten aufeinander, werden ihre Werte addiert. Schon bei einem winzigen Netz mit wenigen Eingaben, Ausgaben und drei Schichten kommt man auf 64 Parameter. Moderne LLMs haben Hunderttausende Ein- und Ausgaben, dutzende Schichten mit jeweils Tausenden Knoten, allesamt dicht miteinander verbunden. Multipliziert man das durch, landet man unweigerlich im Bereich von Milliarden bis hin zu Billionen Parametern. Und jeder einzelne Parameter muss irgendwo gespeichert werden, am liebsten mit hoher Präzision.

Wie Computer Zahlen speichern

Computer arbeiten bekanntermaßen mit Bits, also den Zuständen 0 und 1. Ganze Zahlen, in der Fachsprache Integer, lassen sich damit wunderbar abbilden: jedes Bit steht für eine Zweierpotenz, und die Summe ergibt den Wert. Zwischen 1 und 3 existiert exakt eine ganze Zahl, nämlich 2. Das ist diskret und damit ideal für Maschinen. Komplizierter wird es bei Dezimalzahlen, denn zwischen 1 und 3 liegen unendlich viele reelle Werte, und unendlich viele Dinge kann kein Computer speichern. Also wird ein Kompromiss eingegangen: Die Maschine verspricht Genauigkeit bis zu einer bestimmten Anzahl signifikanter Stellen und liefert danach nur eine Annäherung.

Eine 32-Bit-Gleitkommazahl, englisch float32, deckt einen Bereich von etwa ±3,4 × 10³⁸ ab und garantiert rund sieben signifikante Stellen Genauigkeit. Diese 32 Bits werden auf drei Bereiche aufgeteilt: ein Vorzeichenbit, acht Bits für den Exponenten und 23 Bits für die Mantisse, auch Significand genannt. Mehr Exponentenbits bedeuten einen größeren Wertebereich, mehr Bits in der Mantisse bedeuten mehr Präzision. Auffällig ist, dass die darstellbaren Werte nicht gleichmäßig verteilt sind. Im Bereich zwischen −0,5 und 0,5 gibt es über zwei Milliarden verschiedene float32-Werte, während weiter draußen die Abstände zwischen den darstellbaren Zahlen rapide wachsen. Das ist Absicht: Modelle tendieren dazu, ihre Parameter klein zu halten, und kleine Werte werden bei dieser Verteilung am genauesten abgebildet.

Der Autor hat sich sechs populäre Open-Source-Modelle vorgenommen und die Verteilung ihrer Parameter analysiert. Das Ergebnis: Nahezu alle Gewichte sitzen extrem nahe an der Null. Es gibt zwar Ausreißer, aber die sind selten. Diese Beobachtung ist der Schlüssel zur gesamten Quantisierung, denn sie zeigt, dass der enorme Wertebereich von float32 in der Praxis gar nicht ausgenutzt wird.

Kleinere Gleitkommazahlen als Ausweg

Wenn Modelle ihre Parameter sowieso im engen Bereich nahe Null halten, dann brauchen sie auch keine 32 Bits pro Wert. Eine 16-Bit-Gleitkommazahl (float16) verwendet fünf Exponentenbits und zehn Bits für die Mantisse, kommt auf etwa drei signifikante Stellen und einen Bereich von rund ±65.504. Schon diese Halbierung des Speicherplatzes ist ein großer Gewinn. Noch weiter geht bfloat16, ein Format, das vom Google-Brain-Team entwickelt wurde: acht Exponentenbits für einen riesigen Bereich, aber nur sieben Bits für die Mantisse, also nur zwei verlässliche Stellen. Google stellte fest, dass zwei signifikante Stellen für das Training großer Modelle völlig ausreichen, sofern der Wertebereich groß genug ist, um Überläufe zu vermeiden.

Danach wird es drastisch. Formate wie float8 und float4 nutzen nur noch acht beziehungsweise vier Bits pro Wert. Deren Genauigkeit lässt sich zeigen, indem man eine Sinuskurve nachbildet: Während float32 die Welle fast perfekt zeichnet, wirken float8 bereits leicht stufig, und float4 driftet sichtbar von der glatten Kurve ab. Das ist der Präzisionskompromiss, mit dem jede Form von Quantisierung leben muss. In der Praxis mischen Entwickler Exponenten- und Mantissenbits je nach Anforderung, um das beste Verhältnis aus Reichweite und Genauigkeit herauszuholen.

Was Quantisierung eigentlich bedeutet

Quantisierung bedeutet, Werte aus einem großen Wertebereich in einen kleineren zu pressen. Es ist eine verlustbehaftete Kompression. Wenn ein float16-Wert in einen float8-Wert umgewandelt wird, wird in der Regel auf den nächstgelegenen darstellbaren Wert gerundet. Diese Methode heißt „round-to-nearest“ und ist die einfachste Variante der Quantisierung. Das grundlegende Prinzip: Schiebe einen Schieberegler entlang einer Zahlengeraden und beobachte, welcher Wert im jeweiligen Format am nächsten liegt. Das funktioniert, ist aber für LLMs meist keine gute Idee.

Der Autor demonstriert das Problem an einem Mini-Netzwerk. Wird von bfloat16 auf float8 gerundet, bleiben die Ergebnisse noch brauchbar. Geht man weiter zu float4, bricht das Modell komplett zusammen. Manche Parameter werden zu null, und da kein Pfad vom Eingang zum Ausgang mehr ohne Multiplikation mit null existiert, ist der Ausgang zwangsläufig null. Der Grund: float4 deckt den Bereich −3 bis 3 ab, die tatsächlichen Parameter liegen aber zwischen −0,89 und 0,16. Hinzu kommen Sonderwerte wie Unendlich und NaN, die beim Quantisieren schlicht nutzlos sind. So verschenkt man wertvolle Bits an Bereiche, die im Modell gar nicht vorkommen.

Symmetrische Quantisierung als smartere Lösung

Die naheliegende Idee: Statt den starren float4-Bereich zu nutzen, sollte man den verfügbaren Wertebereich passend zur tatsächlichen Parameterverteilung zuschneiden. Genau hier setzt symmetrische Quantisierung an. Der Trick besteht darin, die Daten zu skalieren, damit sie optimal in das vorgegebene Raster passen. Anstatt also von −3 bis 3 darzustellen, was bei Parametern zwischen −0,89 und 0,16 völlig überdimensioniert wäre, wird der Bereich zusammengeschoben. So lassen sich die begrenzten Stufen eines 4-Bit-Formats weitaus effizienter nutzen.

In der Praxis funktioniert das so: Man bestimmt den größten absoluten Parameterwert, teilt alle Werte dadurch und multipliziert sie mit dem gewünschten Skalenfaktor. Das Ergebnis ist eine Verteilung, die exakt in den verfügbaren Wertebereich passt. Dadurch erhöht sich die effektive Präzision drastisch, ohne dass mehr Bits nötig wären. Das ist der Grund, warum Modelle nach der Quantisierung häufig noch gut funktionieren: Der theoretische Verlust an Genauigkeit ist hoch, aber die tatsächliche Information steckt in einem engen Bereich, der nun vollständig abgedeckt wird.

Es gibt allerdings einen Haken: Ausreißer in der Parameterverteilung. Wenn ein einziges Gewicht weit außerhalb des typischen Bereichs liegt, zwingt es den gesamten Skalenfaktor in die Höhe. Alle anderen Parameter verlieren dadurch an Präzision. Deshalb gibt es neben der symmetrischen noch weitere Verfahren, etwa die asymmetrische Quantisierung oder spezielle Methoden zum Umgang mit Ausreißern. Welche Strategie am besten funktioniert, hängt vom konkreten Modell und vom Einsatzzweck ab.

Was das für den Alltag bedeutet

Quantisierung ist kein Zaubertrick, sondern ein durchdachtes Komprimierungsverfahren. Es baut auf einer simplen Beobachtung auf: Neuronale Netze nutzen ihren theoretisch riesigen Zahlenbereich gar nicht aus. Wenn du also das nächste Mal ein 70-Milliarden-Parameter-Modell auf deinem Laptop ausführen möchtest, ist Quantisierung der Grund, warum das möglich ist. Die Modelle verlieren etwas Genauigkeit, aber in den meisten Anwendungen fallen fünf bis zehn Prozent nicht ins Gewicht. Für Entwickler sinkt dadurch die Hürde, lokal mit ernstzunehmenden Modellen zu experimentieren. Die Abhängigkeit von riesigen Cloud-Instanzen wird kleiner.

Quelle: ngrok.com

Die gängige Annahme lautet: Ein Sprachmodell muss erst seine Antwort fertig formuliert haben, bevor es ein Werkzeug aufruft. Genau diese Annahme stellt ein neuer Ansatz namens Speculative Programmatic Tool Calling infrage. Der Entwickler Alex Zhang zeigt in seinem aktuellen Blogbeitrag, dass ein LLM-Agent Werkzeuge bereits starten kann, während die Token-Generierung noch läuft – und damit spürbar Latenz einspart.

Wenn du schon einmal mit LLM-Agenten gearbeitet hast, kennst du das Muster: Das Modell generiert einen Text, am Ende steht ein Tool-Call, und erst nach dem vollständigen Text wird die Funktion ausgeführt. Bei klassischen JSON-Tool-Calls ist das in Ordnung, weil die Generierung selbst kein Engpass ist. Anders sieht es aus, wenn das Modell in einer Code-REPL arbeitet und Codezeilen als Aktionen nutzt. Dann wartet das System erst auf das komplette Programm, um dann die Tools auszuführen – eine Verschwendung von Rechenzeit, die man vermeiden kann.

Die Grundidee: Speculation statt Warten

sPTC überträgt ein Konzept aus der CPU-Entwicklung auf LLM-Harnesses: spekulative Ausführung. In CPUs werden Befehle vorzeitig ausgeführt, bevor klar ist, ob sie tatsächlich gebraucht werden. Ähnlich schlägt Zhang vor, Tool-Aufrufe aus dem bereits generierten Code vorab zu starten, während das Modell noch weitere Tokens produziert. Wenn der vollständige Code dann tatsächlich diese Tools aufruft, liegen die Ergebnisse bereits im Cache vor.

Das ist besonders relevant für Systeme, die auf Recursive Language Models (RLMs) setzen. Hier ist die zentrale Idee, dass Code in einer REPL das einzige Tool ist, das ein System braucht – alle anderen Tools sind Funktionen in dieser Code-Umgebung. Und weil Sub-Agenten oder Such-APIs in solchen Architekturen oft die teuersten und langsamsten Operationen sind, machen sie den Großteil der Latenz aus.

Die Beobachtung ist simpel: Die Generierung des Hauptkontexts dauert lange, und die darin geplanten Tool-Aufrufe warten derweil. Wenn man sie schon während der Generierung startet, überlappt man zwei latenzintensive Prozesse.

Zwei Hebel, die Zeit sparen

Zhang identifiziert zwei klare Zeitgewinne. Der erste liegt im Overlapping: Statt nach der vollständigen Generierung die Tools auszuführen, startet sPTC die Tool-Calls bereits, während die Tokens gestreamt werden. Das macht besonders viel aus, wenn Modelle lange „denken“ und viele Zwischenschritte generieren.

Der zweite Gewinn ist subtiler und erinnert an einen JIT-Compiler. In einer REPL können Tool-Aufrufe in einer Reihenfolge stehen, die scheinbar sequenziell ist, aber eigentlich voneinander unabhängig. Zwei Sub-Agenten, die nacheinander aufgerufen werden, könnten auch parallel laufen. sPTC erkennt solche Fälle und startet die Aufrufe gleichzeitig – eine primitive, aber effektive Optimierung, die sich über Sprachen und REPL-Designs hinweg verbessern lässt.

Das bedeutet konkret: Das System profitiert doppelt – von der Überlappung mit der Token-Generierung und von der Parallelisierung unabhängiger Calls. Je langsamer die Tools sind, desto größer der Vorteil.

Die Technik dahinter: Schatten-REPL und Promises

Der Implementierungsansatz im Codebase von Zhang ist bemerkenswert einfach. Die zentrale Idee ist ein Hook um spekulierbare Tool-Funktionen. Während die LLM-Ausgabe gestreamt wird, parst ein Schatten-REPL den bereits erzeugten Code und führt potenzielle Tool-Aufrufe vorzeitig aus. Die Ergebnisse werden als Future beziehungsweise Promise in einem globalen Speicher abgelegt.

Wenn der echte Code später ausgeführt wird, greifen die Original-Funktionen auf diesen Speicher zu und holen sich das bereits berechnete Ergebnis. Das funktioniert über eine Umbenennung von Namespaces: Der reale Namensraum enthält die echten Tools, der Schatten-Namensraum die spekulativen Versionen. Während des Streamings arbeitet der Schatten-REPL mit dem partiellen Code; nach der vollständigen Generierung läuft der echte Code und findet die vorab berechneten Werte.

Wichtig ist dabei, dass der Schatten-REPL nicht als echter Ausführungskontext dient. Er ist eine tiefe Kopie der REPL-Umgebung, so dass Nebenwirkungen den Hauptzustand nicht verändern. Externe Funktionen wie `open` gelten als unsicher und werden nicht spekuliert. Der gesamte REPL-Code wird als Einheit betrachtet: Wenn das Modell fehlerhaften Code produziert, bleibt der reale Zustand sauber.

Was sich überhaupt spekulieren lässt

Nicht jeder Tool-Aufruf kann vorzeitig gestartet werden. Zhang unterscheidet mehrere Fälle. Der einfachste Fall sind Literale: Ein Aufruf wie `llm_query(„Gib mir einen Titel für: Die Odyssee“)` kann direkt parst und ausgeführt werden, sobald die Zeile im Stream auftaucht. Auch Abhängigkeiten von Variablen sind möglich, solange die vorgelagerten Berechnungen als sicher gelten – also pur, ohne Seiteneffekte.

Es gibt aber auch Fälle, in denen die Spekulation blockiert ist. Wenn die Eingabe eines Tool-Calls von einer Datei abhängt oder von einer Funktion, die externe Zustände verändert, wird nicht spekuliert. Gleiches gilt für Aufrufe innerhalb von Schleifen oder Bedingungen, deren Laufzeit oder Ergebnis nicht vorhersehbar ist. Hier verhält sich das System konservativ.

Ein weiterer Punkt ist die Eindeutigkeit von Tool-Aufrufen. Zwei identische Aufrufe an denselben Sub-Agenten sollen nicht doppelt ausgeführt werden, es sei denn, sie sind deterministisch. Deshalb werden Instanzen individuell verfolgt. Das ist wichtig für Mehrheitsvoten über mehrere Agenten hinweg.

Benchmarks: Realistische Verbesserungen zwischen 1 und 1,2x

Wie viel bringt das Ganze? Zhang hat mit seinem Team auf OOLONG-Datensätzen (trec-coarse, 132k und OOLONG-Pairs, 32k) gemessen, mit einer vLLM-Server-Instanz auf 8xH100-GPUs und dem Modell Qwen3-30B-A3B-Instruct. Sie testeten sowohl mit temperture 0,7 als auch mit 0,0, um die Varianz der RLM-Trajektorien zu kontrollieren. Jede Konfiguration lief fünfmal.

Die Ergebnisse zeigen Speed-ups im Bereich von 1 bis 1,2x gegenüber einer Basis-Architektur ohne Spekulation. Das klingt bescheiden, ist aber wichtig einzuordnen: Die tatsächliche Verbesserung hängt stark von der Latenz der Tools, der Anzahl der generierten Tokens, der Server-Auslastung und den Entscheidungen der Harness-Komponente ab. Bei langsameren Tool-Aufrufen oder längeren Denk-Phasen fällt der Vorteil deutlich größer aus.

Auch die Parallelisierung unabhängiger Sub-Agenten wurde in der Auswertung berücksichtigt. In der Praxis zeigt sich: Je mehr unabhängige Aufrufe im Code stecken, desto mehr profitiert das System von der „naiven JIT-Compiler“-Rolle. Die vorgestellten Zahlen sind daher als unterer Grenzwert zu verstehen.

Eine Designphilosophie, die offene Fragen lässt

Der Vorschlag von Zhang ist keine ausgereifte Theorie, sondern eine pragmatische Harness-Technik. Er selbst weist darauf hin, dass die Idee in viele Richtungen weiterentwickelt werden könnte – etwa durch bessere Vorhersagen über Bedingungen oder durch detailliertere Analysen des partiellen Codes. Die derzeitige Implementierung priorisiert Sicherheit und Einfachheit.

Für dich als Entwicklerin oder Entwickler bedeutet das: sPTC ist ein konkretes Werkzeug, das du in eigene Systeme einbauen kannst, wenn du mit Code-REPLs und sub-LLM-Calls arbeitest. Der Code ist kurz, lesbar und auf GitHub verfügbar. Die Technik zeigt, dass die größten Latenzgewinne nicht unbedingt aus besseren Modellen kommen, sondern aus klügerem Harness-Design.

Am Ende bleibt eine nüchterne Erkenntnis: Overlapping und Parallelisierung sind keine Zauberei, sondern handwerkliche Optimierung. Genau solche Bausteine werden den Unterschied machen, wenn LLM-Agenten in Echtzeit-Umgebungen eingesetzt werden sollen.

Quelle: alexzhang13.github.io