FLOWKI · NEWSROOM
Kontextmanagement bei LLM-Agenten: Engineering statt Trial-and-Error
coding-mit-ki

Kontextmanagement bei LLM-Agenten: Engineering statt Trial-and-Error

coding-mit-ki4 unabhängige QuellenFlowKI Newsroom

Was passiert: Die Kontextkrise bei langen agentengestützten Aufgaben

LLM-Agenten — Systeme, in denen ein großes Sprachmodell iterativ Tools aufruft und deren Ergebnisse verarbeitet — scheitern bei Aufgaben, die über mehrere Schritte laufen, in zwei systematischen Mustern: Kontextüberlauf und Zielvergessenheit. Laut MarkTechPost beschreibt ein neuer technischer Bericht vier konkrete Harness-Mechanismen, die beide Probleme strukturell beheben. Der Bericht identifiziert dabei exakte Schwellenwerte, ab denen ein Agent "flach" wird — also die Kontrolllogik über Tool-Aufrufe verliert.

Konkret funktioniert ein flacher Agent wie folgt: Das LLM ruft ein Tool auf, erhält das Ergebnis, verarbeitet es im Prompt-Kontext, und ruft das nächste Tool auf. Bei langen Tasks (etwa mehrstündige Code-Analysen oder iterative Datenbeschaffung) führt dies zu zwei kritischen Fehlern: Erstens wächst der Kontextfenster linear mit jedem Schritt, bis das Token-Limit des Modells erreicht ist. Zweitens verliert das Modell — wie Forschung zeigt — nach 8–12 Kontextwindows seine ursprüngliche Aufgabenstellung aus den Augen.

Die neuen Harness-Mechanismen adressieren das durch Architektur-Patterns statt Prompt-Engineering. Sie gruppieren Kontextinhalte semantisch, komprimieren Zwischenergebnisse nach festen Regeln und halten einen separaten, nicht-wachsenden "Navigationspuffer" für Zielgeometrie vor. Ein zweiter Trend zeigt sich parallel: Cognition hat mit SWE-2 ein spezialisiertes Coding-Agenten-Modell veröffentlicht, das auf Kimi K3 post-trainiert wurde. Wie MarkTechPost berichtet, erreicht SWE-2 die Leistung von Frontier-Modellen bei 64 % niedrigerem Kosteneinsatz — ein Signal dafür, dass Unternehmen spezialisierte, kontexteffiziente Agenten statt Generalist:innen-LLMs bevorzugen.

Ein drittes, kontraintuitives Ergebnis kommt von der ETH Zürich: Eine neue Studie (berichtet von t3n) zeigt, dass die beliebte Praxis, Kontextdateien wie agents.md oder README-Dateien direkt in den Agenten-Prompt einzubinden, nicht nur unwirksam ist — sie verschlechtert die Leistung messbar. Der Grund liegt darin, dass Agenten solche statischen Dateien nicht als strukturierte Wissensbasis, sondern als Noise im Kontextfenster verarbeiten.

Warum für DACH relevant: Regulierung trifft auf Kontextmanagement

Für deutschsprachige Unternehmen ist Kontextmanagement bei Agenten nicht nur ein Performance-Problem, sondern auch ein Governance-Problem. Die EU-AI-Act-Anforderungen für Transparenz und Audit-Trails verschärfen sich speziell bei Multi-Step-Systemen: Ein Agent, der über 20 Schritte läuft und dabei seine Zielaufgabe vergisst, kann rechtlich nicht mehr nachgewiesen werden, wenn ein Fehler auftritt. Welche Entscheidungslogik lag der Handlung zugrunde?

Mittelständische DACH-Unternehmen (typischerweise 50–500 Beschäftigte) setzen derzeit Agenten für Szenarien ein, die genau in die "lange Task"-Kategorie fallen: automatisierte Compliance-Checks über Dokumentenbestände, iterative ERP-Datenabfragen, Multi-Step-Code-Reviews in CI/CD-Pipelines. Ein Finanzdienstleister in Frankfurt, der einen Agenten zur KYC-Datenvalidierung einsetzt, benötigt nicht nur Genauigkeit — er braucht dokumentierbare Entscheidungsketten. Die neuen Harness-Mechanismen erlauben genau das: Sie halten Navigationspuffer (das Ziel) und Tool-Aufrufe (das Audit-Trail) strukturell getrennt.

Zugleich gibt die ETH-Studie praktische Orientierung für DACH-Labs: Die übliche Praxis, umfangreiche Dokumentation direkt in Prompts einzubinden, ist nicht nur verschwendetes Token-Budget — sie widerspricht auch dem DSGVO-Gedanken der Datensparsamkeit. Bessere Architektur: Externe Vector-Stores oder spezialisierte Knowledge-Base-APIs (Retrieval-Augmented Generation, RAG) statt Kontext-Stuffing.

Besonders relevant: Durch die neue Welle spezialisierter Coding-Agenten wie SWE-2 sinken die Infrastrukturkosten für Agenten-Systeme. Ein deutsches Softwarehouse kann jetzt mit niedrigeren Durchsatzkosten mehr Agenten-Experimente fahren — womit die Amortisation von Kontextmanagement-Investitionen schneller eintritt.

Was du jetzt tun/wissen solltest: Architekturdenkweise vor Prompt-Trickserei

Die zentrale Erkenntnis aus allen drei Quellen ist: Kontextprobleme bei Agenten sind Architekturprobleme, nicht Prompt-Probleme. Ein häufiger Fehler ist, mehr Details in den System-Prompt zu packen oder "Kontextdateien" einzubinden — dies verstärkt nur die Probleme, die die neuen Harness-Mechanismen lösen.

Der konkrete Handlungsschritt: Wer heute in DACH einen Agenten in Produktion nimmt oder plant, sollte zuerst die Aufgabenlänge definieren (Anzahl der Tool-Aufrufe) und dann bewusst zwischen zwei Architekturen entscheiden. Für kurze Tasks (< 5 Aufrufe) reicht ein flacher Agent mit Standard-LLM. Für lange Tasks sollte entweder ein spezialisiertes Modell wie SWE-2 (falls Coding) oder ein generisches LLM mit expliziter Harness-Logik (separater Navigationspuffer, semantische Kontextkompression) zum Einsatz kommen. Bestandteile der Wissensbasis gehören in externe Knowledge-Stores (RAG / Vector-DB), nicht in Prompts — das reduziert Kontextfenster UND erhöht Wartbarkeit.

Entsprechend liegt der nächste Schritt darin, zu prüfen: Welche aktuellen Agenten im eigenen Tech-Stack leiden unter Zielvergessenheit oder Token-Limits? Für diese sollte ein Audit und eine Re-Architekturierung Priorität haben — nicht das Tunen von Prompts. Dies ist auch präventiv relevant, da die neuen Standards (Harness-Pattern, spezialisierte Modelle) in sechs bis neun Monaten den Markt-Standard darstellen dürften.

Mehr zum Thema im Ressort Kategorie Coding mit KI.

Quellen