Coding Agents, Harness und das Kontextfenster: Was ein Meetup über den Token-Verbrauch zeigt

Ein Sprachmodell allein kann nicht viel. Es nimmt Text entgegen und gibt Text zurück. Dass daraus plötzlich etwas wie „ein Agent" wird, der Dateien ändert, Befehle ausführt und über Stunden hinweg an einem Problem sitzt, passiert erst in dem Moment, in dem jemand um das Modell herum eine Laufzeit-Umgebung baut. Genau darum ging es im Meetup: um diese Umgebung – im Fachjargon den Harness – und um die Frage, was er mit Token-Verbrauch und Kontextfenster macht. Am Ende des Abends stand eine Einsicht, die sich durch die ganze Diskussion zog: Welches Modell man wählt, ist eine Frage. Welcher Harness davor sitzt, ist die Kostenvariable.

Dieser Text fasst zusammen, was wir besprochen haben. Er ist als Rückblick geschrieben und zugleich als Einführung gedacht – wer die Begriffe am Ende erklären kann, hat an dem Abend nichts verpasst.

Der Unterschied, mit dem alles beginnt: Assistant oder Agent?

Beim Einstieg haben wir kurz aufgeräumt, weil die Begriffe oft durcheinandergehen. Ein Coding-Assistant ist eine Software um ein Modell herum: das Modell liefert das Verständnis, ein Toolkit gibt ihm die „Arme und Beine" – Zugriff auf Dateien, auf das Terminal, auf Werkzeuge. Ohne dieses Toolkit kann ein nacktes Modell weder eine Datei öffnen noch einen Befehl ausführen, so die Systematik bei IBM. „Assistant" beschreibt eher die Rolle, wie das Werkzeug dem Menschen gegenüber auftritt. „Agent" beschreibt die technische Architektur: ein Modell, das eigene Schritte plant, Werkzeuge auswählt und das Ergebnis wieder in die Überlegung einbezieht. Beide Begriffe verschwimmen im Alltag – bei der Einordnung hat uns Anthropics Gegenüberstellung von Workflows und Agents geholfen: Workflows laufen über fest vorgegebene Codepfade, Agents steuern ihre Prozesse und ihren Werkzeugeinsatz selbst.

Wer die Szene beobachtet, sieht inzwischen drei grobe Kategorien von Coding-Tools:

Dazu kommen Angebote wie Amazon Q Developer oder Replit Agent, die ähnliche Aufgaben in ihre eigenen Produktwelten eingebaut haben. Die Liste verschiebt sich laufend; im Meetup haben wir uns deshalb nicht an konkreten Feature-Vergleichen abgearbeitet, sondern an der Mechanik, die allen gemeinsam ist. Und die sitzt im Harness.

Was ein Harness eigentlich ist

Der Begriff kam in den Diskussionen immer wieder auf und wurde an einem Punkt präzise gefasst. Die Formulierung von Microsoft für das Agent Framework deckt sich gut mit dem, was wir am Abend festgehalten haben:

LangChain hat es im „Anatomy of an Agent Harness" auf eine kurze Formel gebracht: Agent = Modell + Harness – „If you're not the model, you're the harness." Zum Harness gehören dann alles, was nicht das Modell selbst ist: die System-Prompts, die Definitionen der Werkzeuge, die Sandbox, die Orchestrierung von Unteragenten, die Hooks, die Kontext-Kompression. Bei den großen Labs ist der Begriff inzwischen selbstverständlich: OpenAI nennt die Codex-Agent-Loop einen „agent (or harness)", Anthropic bezeichnet das Claude Agent SDK als „general-purpose agent harness".

Martin Fowler und Birgitta Böckeler gehen noch einen Schritt weiter und beschreiben Harness Engineering als eine Form von Context Engineering. Sie unterscheiden zwei Bauteile: die Guides, die den Agenten führen, bevor er handelt – etwa eine AGENTS.md, Skills, Tool-Beschreibungen – und die Sensors, die danach beobachten und Korrektur ermöglichen, etwa Tests, Linter oder ein LLM als Reviewer. Ein rohes Modell sei kein Agent; erst die Verbindung mit einem Harness mache es dazu.

Der Agent-Loop und warum er Token kostet

Die eigentliche Kostenmaschine ist der Loop. Er läuft immer gleich ab: Prompt kommt rein, das Modell entscheidet, der Harness führt einen Tool-Aufruf aus, das Ergebnis wird angehängt, und es geht von vorn. Jeder dieser Turns bedeutet, dass der gesamte bisherige Kontext – Systemprompt, bisheriger Verlauf, Tool-Ergebnisse – erneut an das Modell geschickt wird. OpenAI hat die Mechanik im Beitrag „Unrolling the Codex agent loop" offen beschrieben: Mit jedem Gesprächsschritt wächst der Prompt, und ein Agent kann in einem einzigen Turn hunderte Tool-Aufrufe machen. Rechnet man das über viele Turns hoch, wächst die Menge des Gesendeten nahezu quadratisch – wäre da nicht Prompt-Caching, das beim Wiederverwenden identischer Kontext-Abschnitte den Preis drastisch senkt. Daraus folgt eine praktische Regel, die wir im Meetup als „Cache-Hygiene" bezeichnet haben: statische Inhalte nach vorn, veränderliche nach hinten. Was vor einem Cache-Breakpoint liegt, wird teuer geschrieben und günstig gelesen; alles, was die Reihenfolge durcheinanderbringt, kostet.

Wie viel das ausmacht, belegt eine Untersuchung aus Stanford (veröffentlicht unter arXiv 2604.22750), die wir am Abend ausführlich besprochen haben: Agentische Coding-Aufgaben verbrauchten dort rund 1.000-mal mehr Tokens als ein einzelner Chat. Die Kosten wurden fast vollständig von den Input-Tokens getrieben – also von allem, was wiederholt mitgeschickt wird – und nicht von der Ausgabe. Zwischen den getesteten Modellen gab es bis zu 30-fache Unterschiede im Verbrauch für dieselbe Aufgabe. Und ein Ergebnis, das man kaum laut ausspricht, aber merken sollte: Mehr Token-Verbrauch hieß nicht mehr Genauigkeit.

Das Kontextfenster als Engpass

Der zweite große Block des Abends: das Kontextfenster. Hier haben wir drei Erkenntnisse diskutiert, die sich gut herleiten ließen:

Der Begriff, der an dem Abend hängen blieb: Kontext ist eine endliche Ressource, kein Speicher. Wer ihn vollschreibt, schadet der Qualität und zahlt doppelt.

Wie man Kontext und Token unter Kontrolle hält

Aus dieser Diagnose ergaben sich die Maßnahmen. Sie waren im Meetup der längste Block, weil hier Theorie in Praxis umschlägt:

• Prompt-Caching nutzen. Wiederverwendbare Präfixe – Systemprompt, Tool-Definitionen, stabile Projektdateien – nach vorn stellen. Bei Anthropic gilt eine Cache-Haltbarkeit von 5 Minuten und 1 Stunde, bei OpenAI ist Caching automatisch aktiviert (Doku).
• Komprimieren statt wachsen lassen. Server-seitige Compaction, etwa über OpenAIs Compact-Schnittstelle oder die automatische Kompression im Claude Agent SDK, hält den Kontext klein, wenn das Fenster voll läuft.
• Weniger hineingeben. Eine Arbeit aus der „Complexity Trap"-Reihe zeigt, dass gezieltes Weglassen von Beobachtungen die Kosten halbieren kann, ohne die Erfolgsquote zu verschlechtern – manchmal schlägt das Weglassen sogar die klassische Zusammenfassung.
• Unteragenten mit eigenem Kontext. Claude Code lässt Unteragenten in eigenen Kontextfenstern arbeiten und gibt nur eine kondensierte Zusammenfassung zurück; der Hauptagent wächst kaum. Tool-Definitionen verbrauchen ihrerseits Kontext – jede Definition kostet Platz, bevor der Agent überhaupt arbeitet.

Das Bemerkenswerte an dieser Liste: Keine der Maßnahmen verlangt nach einem größeren Modell. Sie alle sind Entscheidungen im Harness.

Was die Forschung zur Harness-Wahl sagt

Der stärkste Diskussionspunkt des Abends war die Frage, wie viel die Orchestrierung gegenüber dem Modell wirklich ausmacht. Zwei aktuelle Arbeiten liefern dazu Zahlen, die wir im Detail durchgesprochen haben:

In derselben Liga bewegt sich der LangGraph-Bericht über „Improving Deep Agents with Harness Engineering": Nur durch Änderungen an Systemprompt, Tools und Middleware – Modell unverändert – ging es auf einem Benchmark von Rang 30 auf Rang 5. Umgekehrt zeigt die „Harness-Effect"-Arbeit auch eine Warnung: Schwächere Modelle können durch komplexe Orchestrierung sogar verlieren. Was für das Spitzenmodell gilt, muss für das schlanke Modell nicht gelten.

Aus der Praxis kamen zwei Muster, die wir uns notiert haben. Anthropic empfiehlt für lange, mehrstufige Projekte die Trennung in einen Initializer-Agenten und einen Coding-Agenten: Der erste richtet die Umgebung ein, der zweite arbeitet dann über mehrere Kontextfenster hinweg statt in einem überladenen Dauer-Kontext. Und das OpenAI-Team beschreibt in einem Rückblick auf den Bau einer großen Codebasis mit Harness Engineering in der Praxis, dass Repository-Wissen als „system of record" mehr bringt als ein wachsendes Regelwerk: „Gib dem Agenten eine Karte, kein tausendseitiges Handbuch."

Warum Graphen plötzlich auf dem Tisch lagen

Der zweite große Themenstrang des Abends war der Wissensgraph. Auf den ersten Blick ein technisches Randthema, auf den zweiten genau die Antwort auf die Frage „Wie halte ich Kontext klein und trotzdem reich an Zusammenhang?". Flache Kontexte skalieren schlecht, graph-basiertes Gedächtnis skaliert besser – das ist das Argument, das etwa Neo4j für sein Agent-Memory anführt: Gespräche, Fakten und Werkzeugspuren in einem Graphen statt in einem ungeordneten Kontext-Puffer. Statt den ganzen Kontext mitzuschicken, fragt man gezielt den relevanten Teilgraphen ab.

Der Punkt, der uns wichtig war: Ein Graph ist keine Modeerscheinung, sondern ein Werkzeug gegen genau die beiden Probleme, um die sich der ganze Abend drehte. Er entlastet das Kontextfenster, weil er gezielt auswählt. Und er verbindet Informationen über mehrere Schritte, die ein flacher Vektor-Index nicht hergibt – Multi-Hop-Beziehungen, Hierarchien, zeitliche Ketten.

Was das für die KI-Weiterbildung heißt

Der Abend endete mit der Frage, die dem Meetup zugrunde lag: Warum gehören diese Themen in eine KI-Weiterbildung? Die Antworten haben wir in drei Schichten sortiert – für den Einzelnen, für das Unternehmen, und für die Frage, wer dabei eigentlich in der Pflicht steht.

Für den Einzelnen: Wer die Mechanik hinter dem Hype versteht – Agent-Loop, Harness, Kontext-Budget, Graph-Retrieval –, versteht, warum dasselbe Tool bei verschiedenen Leuten so unterschiedliche Ergebnisse liefert. Das ist kein Zufall und keine Magie, sondern Harness-Design. In Stellenausschreibungen tauchen inzwischen Rollen wie Context Engineer oder Harness Engineer auf, während „Prompt Engineer" als Standalone-Titel an Bedeutung verliert. Wer Kontext-Engineering kann, kann die Frage „Was kostet das?" beantworten – und das ist eine Frage, die im Job täglich gestellt wird.

Für das Unternehmen: Die Zahlen, die wir am Abend herumgereicht haben, stammen aus kontrollierten Experimenten, nicht aus Marketing-Folien. Die GitHub-Copilot-Studie maß 55,8 % schnellere Erledigung einer Programmieraufgabe in der Gruppe mit Assistenz. Die NBER-Studie „Generative AI at Work" fand über 5.000 Support-Mitarbeitende hinweg rund 14 % mehr erledigte Anfragen pro Stunde – und bei Berufseinsteigern sogar 34 %. Produktivität ist also messbar. Aber: Diese Effekte sind an Menschen geknüpft, die das Werkzeug richtig einsetzen. Wer das nicht trainiert, bekommt die Studie nicht.

Und dann gibt es noch den Rahmen, der nicht mehr freiwillig ist. Der EU AI Act, Artikel 4, verpflichtet Anbieter und Betreiber von KI-Systemen, „nach besten Kräften" ein ausreichendes Maß an KI-Kompetenz des Personals sicherzustellen. Die Bitkom-Studie zur KI zeigt, wie viel hier noch fehlt: 43 % der Unternehmen bieten keine KI-Schulungen an, nur 8 % schulen alle Mitarbeitenden, und 70 % der Erwerbstätigen wird keine Schulungsmöglichkeit angeboten. Zugleich meldet der IW-Kurzbericht zur Kompetenzentwicklung, dass KI-Anwender deutlich häufiger an Weiterbildung teilnehmen – wer das Thema ernst nimmt, qualifiziert sich aktiv weiter. Genau dort, zwischen Verpflichtung und fehlendem Angebot, entsteht der Bedarf, über den wir am Abend gesprochen haben.

Was wir mitgenommen haben

Drei Dinge sind aus dem Abend hängen geblieben. Sie sind bewusst so formuliert, dass sie gelten, auch wenn sich einzelne Produkte und Preise längst weiterverschieben:

Wer tiefer einsteigen will, findet auf der Schedule-Seite die nächsten Termine zu Agenten, Architektur und Kontext-Engineering. Und wer den Bogen von der Token-Rechnung bis zur Unternehmens-Architektur komplett schlagen will, ist im Meetup-Format oder in der Weiterbildung richtig aufgehoben – die Themen überlappen sich stärker, als man denkt.