Kommentar von Matthias Patzak, AWS Simple Strands Agent – AWS-Harness pusht KI-Agenten-Leistung

Agentenbasierte KI-Systeme übernehmen zunehmend mehrstufige Aufgaben. Das reicht von der Codereparatur bis zur Bedienung von Terminalumgebungen. Wie zuverlässig sie dabei arbeiten, hängt maßgeblich von der Softwareschicht ab, die Modell und Werkzeuge miteinander verbindet. Diese Schicht wird als Harness bezeichnet und vermittelt zwischen Modell und Werkzeugen. Dabei steuert sie auch den Kreislauf aus Reasoning und Feedback. Das bringt allerdings auch neue Herausforderungen mit sich.

Mit zunehmender Modellleistung verschiebt sich der Flaschenhals von der Denkfähigkeit des Modells zur Fähigkeit der Harness, die Absicht des Modells in Aktionen zu übersetzen und Ausführungsergebnisse verständlich zurückzumelden.

Forscher von AWS haben diesen Effekt untersucht und dafür mit Simple Strands Agent (SSA) eine schlanke, quelloffene Referenz-Harness entwickelt. Sie soll die Lücke zwischen dokumentierter und tatsächlich erzielter Leistung offener Implementierungen schließen. Wie sich diese Lücke in der Praxis schließen lässt, zeigt sich an einer Reihe konkreter Design-Entscheidungen innerhalb der Harness.

Ursprung der Intent-Execution-Gap

Frühere Optimierungen wie maßgeschneiderte Prompts oder Werkzeuge lassen sich oft nicht auf neue Modelle übertragen, da sie implizit auf das Verhalten eines bestimmten Modells zugeschnitten sind. Das ist der Grund für diesen Fokus. Die Forscher richteten den Blick auf die Schnittstelle zwischen Modell und Harness, an der sich Absichten in Aktionen übersetzen. Aus dieser Perspektive ergaben sich zwei grundsätzliche Fragen: Versteht die Harness, was das Modell erreichen will? Und ist dem Modell klar, wie die Harness seine Aktion interpretiert hat?

Zwischen Modellabsicht und Ausführung kann allerdings eine Lücke entstehen. Von den AWS-Forschern wurde diese als Intent-Execution-Gap bezeichnet. Sie beschreibt die Diskrepanz zwischen dem, was ein Modell beabsichtigt, und dem, was die Harness ausführt, sowie umgekehrt zwischen Ausführung und der Rückmeldung an das Modell. Ein Beispiel aus der Codegenerierung: Ein Modell will eine einzelne Instanz einer Funktion anpassen, die Harness verändert versehentlich mehrere Vorkommen gleichzeitig.

Die Untersuchung zeigt, dass die Minimierung dieser beidseitigen Lücke ausreicht, um ohne aufgabenspezifisches Tuning Spitzenergebnisse über verschiedene Benchmarks hinweg zu erzielen. Das gilt sowohl bei der Reparatur realer Code-Repositories (SWE-Bench-Pro, SWE-Bench-Verified) als auch in interaktiven Terminalumgebungen (Terminal-Bench-2).

Fehlerquellen an der Werkzeugschnittstelle

Besonders deutlich wird die Intent-Execution-Gap an der Schnittstelle zwischen Modell und Werkzeugen, wo aus einer Absicht eine konkrete Aktion werden muss. Der untersuchte Agent für Codegenerierung nutzt ein Bash-Tool für Terminalzugriffe und einen Dateieditor für Codeänderungen. Dabei zeigte sich, dass sich ein langer Kommando-Output kürzen lässt, ohne Informationen wie Job-Status oder Erfolg einer Ausführung zu verlieren. Allerdings nur, wenn die Kürzung in der Mitte ansetzt und Anfang sowie Ende erhalten bleiben.

Beim Dateieditor, der auf String-Replace basiert, identifizierten die Forscher mehrere Fehlerquellen. Taucht der zu ersetzende Text mehrfach im Code auf, kann die Harness nicht zuverlässig ableiten, welche Stelle gemeint war. Sinnvoller als automatisches Ersetzen aller Fundstellen ist eine Rückmeldung der Mehrdeutigkeit an das Modell mit Bitte um eindeutigeren Kontext. Zudem steigt das Fehlerrisiko, wenn das Modell nur Teilzeilen oder kurze Fragmente vorschlägt, selbst bei eindeutigen Fragmenten. Belastbarere Textanker, etwa vollständige Zeilen oder klar abgegrenzte Blöcke, reduzieren solche Fehler deutlich.

Schließlich bleibt das Modell auch nach einer erfolgreichen Änderung oft im Unklaren, was genau verändert wurde, wenn die Harness nur eine Erfolgsmeldung liefert. Hilfreich ist eine Diff-Datei nach jeder Änderung, die Ergänzungen, Löschungen und unveränderten Text ausweist. So kann das Modell prüfen, ob die Änderung korrekt gelandet ist. Fehlt dieser Rückkanal, muss das Modell unbeabsichtigte Änderungen erst nachträglich erkennen. Das kostet zusätzliche Reasoning-Schritte und erhöht das Risiko, dass sich das Modell von der Aufgabe entfernt.

Balance zwischen Reasoning und Werkzeugnutzung

Reasoning hilft dem Modell, ein Problem zu zerlegen und Schritte zu planen. Zu ausgedehntes Reasoning führt jedoch dazu, dass das Modell nur Annahmen über die Umgebung trifft, statt sie per Werkzeugaufruf zu prüfen. Die Folge können schlecht fundierte Aktionen oder übersprungene Validierung sein. Die Forscher nennen dies Tool Calling mit Reasoning-Nudge. Damit ist gerade so viel Reasoning wie nötig gemeint, gefolgt von einer Priorisierung werkzeugbasierter Überprüfung.

Ein einzelner Prompt-Ansatz für alle Modellfamilien ließ sich nicht finden. Bei Claude-Modellen half eine quantitative Vorgabe, etwa ein Zielwert von mindestens fünfzig Werkzeugaufrufen, um lange Reasoning-Ketten aufzubrechen. Bei Gemini und Grok nahmen die Modelle solche Vorgaben wörtlich und setzten leere Werkzeugaufrufe ab, um den Zielwert zu erreichen. Hier erwies sich eine offenere Formulierung, etwa die Aufforderung zu möglichst intensiver Werkzeugnutzung, als wirksamer.

Auch bei identischer Funktionalität bevorzugen Modellfamilien unterschiedliche Schnittstellen. GPT-Modelle arbeiten bevorzugt mit einem apply_patch-Befehl in einem bestimmten Format, dessen Missachtung die Leistung senkt. Bei Grok-4.20 führte ein einzelnes, überladenes Werkzeug für Bearbeiten und Ansehen von Dateien zu Verwechslungen, eine Aufteilung in atomare Funktionen verbesserte die Ergebnisse bei unverändertem Funktionsumfang. Die Anzeige von Zeilennummern hilft den meisten Modellen, bei Grok erwies sie sich wegen Eigenheiten von Tokenizer und Aufmerksamkeitsmechanismus als hinderlich. Solche Vorlieben sind laut den Forschern ein Nebeneffekt des jeweiligen Trainings.

SSA im Benchmark-Vergleich

Die Forscher evaluierten SSA auf drei Benchmarks: SWE-Bench-Verified (500 Aufgaben), SWE-Bench-Pro, öffentlicher Teil (731 Aufgaben) und Terminal-Bench-2 (89 Aufgaben). Die SWE-Bench-Varianten testen die Reparatur realer Code-Repositories anhand gemeldeter Probleme, Terminal-Bench-2 deckt breitere Aufgaben aus Softwareentwicklung, maschinellem Lernen und Sicherheit ab. Jedes Modell durchlief jeden Benchmark fünfmal, ausgewiesen als durchschnittlicher Pass@1-Wert mit 95-Prozent-Konfidenzintervall. Pass@1 gibt an, welcher Anteil der Aufgaben im Schnitt bereits nach einer einzigen Korrekturrunde erfolgreich gelöst wird.

Der zentrale Befund: Bis auf eine Ausnahme (GPT 5.2 Codex auf SWE-Bench-Pro) lagen die offiziellen Release-Werte sämtlicher getesteter Modelle innerhalb oder unterhalb der Konfidenzintervalle von SSA, von Claude über GPT und Gemini bis zu Grok. Mit Claude Opus 4.6 erzielte SSA durchgehend die höchsten Werte der getesteten Claude-Modelle, mit Pass@1-Werten von 57,45 Prozent auf SWE-Bench-Pro, 80,8 Prozent auf SWE-Bench-Verified und 73,25 Prozent auf Terminal-Bench-2. Auf SWE-Bench-Verified übertraf SSA zudem mini-swe-agent, auf Terminal-Bench-2 den Standardagenten Terminus-2, beides verbreitete quelloffene Vergleichs-Harnesses.

Der Kern der SSA-Harness blieb über alle Modellfamilien identisch. Lediglich in Prompts und Werkzeugspezifikationen gab es geringfügige, gezielte Anpassungen je Modellfamilie, etwa die beschriebenen Reasoning-Nudges oder Werkzeugformate. Ziel war die Identifikation minimaler, orthogonaler Anpassungen, mit denen unterschiedliche Modellfamilien ihre Stärken innerhalb eines gemeinsamen Harness-Rahmens ausspielen können.

Infrastruktur als Störfaktor

Terminal-Bench-2 begrenzt Rechenkapazität und Laufzeit pro Projekt. Das verhindert unverhältnismäßige Ressourcennutzung zur Steigerung der Werte, macht die Ergebnisse aber empfindlicher gegenüber der Infrastruktur. Zwei Faktoren erwiesen sich als einflussreich: die Zuverlässigkeit des Inferenz-Backends, da Latenzschwankungen und Timeouts das Zeitbudget aufzehren, sowie die Anzahl gleichzeitig auf einem Knoten laufender Projekte, da sich diese die Netzwerkbandbreite beim Herunterladen von Abhängigkeiten teilen.

Ein naheliegender Ansatz gegen Timeouts ist eine Batch-Schnittstelle für mehrere Kommandos in einem Schritt. Die Ergebnisse waren gemischt: Bei Claude-Modellen glich der zusätzliche Reasoning-Aufwand für einen kohärenten Terminalzustand den Zeitgewinn durch Batching wieder aus. Bei Gemini und Grok war Batch-Ausführung von Vorteil, da sie keine zusätzlichen Reasoning-Schritte auslöste.

Zur Einordnung verglichen die Forscher zusätzlich reguläre Bedingungen mit einem unbeschränkten Setup ohne Speicher- und Zeitlimits. Die Differenz liegt typischerweise bei fünf bis zehn Prozentpunkten. Einige der 89 Projekte zeigten in der beschränkten Auswertung hohe Timeout-Raten, in der unbeschränkten Auswertung dagegen hohe Lösungsraten, darunter make-doom-for-mips, torch-pipeline-parallelism, gpt2-codegolf, caffe-cifar-10 und train-fasttext.

Fazit

Die Untersuchung von AWS legt nahe, dass sich mit der gezielten Schließung der Intent-Execution-Gap in Agenten-Harnesses ein spürbarer Leistungsgewinn erzielen lässt, unabhängig vom eingesetzten Modell. Gut gewählte Editier-Werkzeuge, verlässliches Feedback nach Werkzeugaufrufen und ein durchdachter Umgang mit langem Tool-Output verbessern die Leistung über alle untersuchten Modellfamilien. Zugleich zeigen sich deutliche modellspezifische Vorlieben bei Werkzeugschnittstellen, die eine Harness berücksichtigen sollte, statt allen Modellen dieselbe Schnittstelle vorzugeben. AWS stellt die Komponenten der SSA-Harness, darunter Agentenlogik, Werkzeuge, Prompts und Modellkonfigurationen, zur Reproduzierbarkeit quelloffen zur Verfügung.

(ID:50948464)