Was einen CLI-Coding-Agenten von einem anderen unterscheidet
Bitten Sie einen CLI-Coding-Agenten, einen fehlschlagenden Test zu reparieren, antwortet er nicht mit einem Vorschlag. Er liest die Testausgabe, öffnet die Datei, ändert eine Zeile, führt den Test erneut aus und meldet sich zurück, sobald er grün ist. Diese Schleife ist das Produkt, nicht das Chatfenster.
Das Modell in dieser Schleife bekommt die meiste Aufmerksamkeit, und es ist auch der Teil, der sich am schnellsten ändert: Anbieter tauschen alle paar Monate ein neues ein, und bei mehreren Agenten können Sie selbst wählen. Was bleibt, ist der Harness um das Modell herum — welche Tools er erreichen kann, wie er mit Kontext umgeht, was er ohne Nachfrage ausführen darf und wo diese Befehle laufen. Zwei Agenten mit demselben Modell können sich dadurch völlig unterschiedlich verhalten. Der Harness ist es, was Sie eigentlich auswählen.
Wie die agentische Schleife funktioniert
Zieht man die Markennamen ab, läuft jeder CLI-Coding-Agent denselben Zyklus:
- Das Modell bekommt Ihre Anfrage plus den Kontext, den der Harness zusammengestellt hat: offene Dateien, aktuelle Shell-Ausgabe, Projektanweisungen.
- Statt nur Text zu schreiben, kann das Modell einen Tool Call ausgeben: „führe diesen Shell-Befehl aus", „schreibe diese Bytes in diese Datei", „suche nach diesem Muster".
- Der Harness führt diesen Aufruf tatsächlich aus, auf Ihrem echten Dateisystem oder in Ihrer echten Shell, und gibt das Ergebnis zurück in den Kontext des Modells.
- Das Modell liest das Ergebnis und entscheidet, was als Nächstes passiert: ein weiteres Tool aufrufen, oder Ihnen antworten.
Das wiederholt sich, bis das Modell die Aufgabe für erledigt hält. Es braucht keinen fertigen Plan, bevor es handelt. Es führt einen Befehl aus, liest, was passiert ist, und passt sich an — deshalb kann ein Agent auch dutzende Tool Calls verbrauchen für eine Aufgabe, die sich am Ende als simpel herausstellt.
Nichts davon braucht eine neue Modellarchitektur. Es braucht ein Modell, das gut darin ist, welches Tool es wann aufruft und wann es aufhört, und einen Harness, der ihm Tools gibt, die den Aufruf wert sind.
Welche Tools ein Coding-Agent tatsächlich bekommt
Die eingebaute Tool-Liste ist kurz und unspektakulär: eine Datei lesen, eine Datei schreiben oder bearbeiten, einen Shell-Befehl ausführen, die Codebasis nach Dateiname oder Inhalt durchsuchen, und bei vielen Agenten eine URL abrufen oder einen Browser steuern. Refactoring, Debugging, Tests schreiben, einen Stacktrace lesen — all das setzt das Modell aus diesen Primitiven zusammen, es ist kein separates Feature, das der Anbieter extra gebaut hat.
Die Design-Entscheidungen, die zählen, stecken im Detail. Braucht „Datei bearbeiten" eine exakte Übereinstimmung mit dem aktuellen Inhalt, was sicherer und leichter zu überprüfen ist, oder darf das Modell die ganze Datei überschreiben, was schneller geht und leichter danebengeht? Führt „Shell- Befehl ausführen" direkt aus, oder innerhalb einer Sandbox, die Netzwerkzugriff und Schreibzugriff außerhalb des Projekts blockiert? Setzen Sie dasselbe Modell hinter unterschiedliche Antworten auf diese zwei Fragen, und Sie bekommen Agenten, die sich überhaupt nicht ähnlich anfühlen.
Wie Coding-Agenten mit mehr Kontext umgehen, als ins Fenster passt
Eine echte Codebasis passt nicht in ein Kontextfenster, und eine lange Sitzung erzeugt weit mehr Tool-Ausgabe, als irgendjemand in einen Prompt einfügen würde. Agenten kombinieren mehrere Techniken, um damit klarzukommen:
- Selektives Lesen. Der Agent sucht nach der relevanten Datei oder
Funktion, statt das ganze Repository zu laden — derselbe Instinkt, den Sie
haben, wenn Sie erst
grep, bevor Siecatverwenden. - Compaction. Überschreitet die Konversation eine Größenschwelle, fasst der Harness die früheren Turns in kürzerer Form zusammen und arbeitet ab da weiter — Detail gegen Platz getauscht.
- Subagenten. Eine große Aufgabe wird in kleinere zerlegt, jede geht an einen frischen Modellaufruf mit nur dem Kontext, den sie braucht. Nur das Ergebnis kommt zurück in die Hauptkonversation.
- Retrieval. Manche Agenten indizieren die Codebasis und nutzen dasselbe Retrieval-Muster hinter RAG, um nur die zur aktuellen Frage passenden Abschnitte einzubeziehen. Andere verzichten auf den Index und verlassen sich allein auf Suche.
Compaction ist die Technik, die zubeißt. Ein Detail von früh in der Sitzung, etwa ein Flag, das Sie einmal erwähnt haben, kann aus der Zusammenfassung herausfallen. Fängt ein Agent an, etwas zu ignorieren, das Sie ihm vor einer Stunde gesagt haben, ist das meist die Ursache, und eine frische Sitzung mit den wichtigen Fakten erneut genannt behebt es.
Was ein Coding-Agent ohne Nachfrage ausführen darf
Der Harness entscheidet, wie weit der Agent kommt, bevor er anhält und nachfragt. Am einen Ende wartet jede Dateiänderung und jeder Shell-Befehl auf Ihre Freigabe. Sicher, und langsam: Der Agent unterbricht Sie ständig. Am anderen Ende läuft der Agent in einer Sandbox-Umgebung, ohne dass jemand zusieht — passend für Hintergrundarbeit wie einen instabilen Test zu reparieren und einen Pull Request zu öffnen, während Sie etwas anderes tun.
Der tägliche Gebrauch liegt meist dazwischen. Nur lesende Aktionen wie Suchen und Dateien öffnen laufen automatisch. Alles Destruktive oder nach außen Wirkende, etwa eine Datei löschen oder zu einem Remote pushen, wartet auf ein Ja.
Das ist Policy, durchgesetzt vom Harness, keine Eigenschaft des Modells. Dasselbe Modell verhält sich vorsichtig oder leichtsinnig, je nachdem, was es unbeaufsichtigt tun darf.
Wie MCP einem Coding-Agenten neue Tools gibt
Die eingebauten Tools decken Dateisystem und Shell ab, aber echte Arbeit braucht oft mehr: eine interne Datenbank abfragen, oder ein Ticket im eigenen Issue-Tracker öffnen. Das Model Context Protocol (MCP) ist der offene Standard, der das ermöglicht, ohne dass jeder Agent-Anbieter für jeden Dienst eine eigene Integration schreiben muss.
Ein MCP-Server beschreibt die Tools, die er anbietet, und wie man sie
aufruft. Jeder MCP-kompatible Agent kann sich verbinden, diese Tools
auflisten und sie genau wie seine eingebauten aufrufen. Der Agent braucht
keinen dienstspezifischen Code: Er liest die Tool-Beschreibungen und
entscheidet, wann sie nützlich sind — genauso, wie er entscheidet, wann er
grep ausführt.
Der Preis dafür ist Kontext. Bei vielen Agenten belegen die Tool-Beschreibungen jedes verbundenen Servers bei jedem Turn Platz im Fenster, ein Dutzend selten genutzter Server macht also jede Anfrage schwerer. Verbinden Sie nur die, die das Projekt wirklich braucht.
Was AGENTS.md- und CLAUDE.md-Dateien tun
Fast jeder Agent sucht am Wurzelverzeichnis Ihres Repositorys nach einer
Markdown-Anweisungsdatei und liest sie, bevor er irgendetwas anderes tut.
AGENTS.md ist die anbieterneutrale Konvention, manche Tools nutzen einen
eigenen Namen wie CLAUDE.md. Hier schreiben Sie, was das Modell nicht aus
dem Code ableiten kann: welcher Befehl die Tests ausführt, und welche
Verzeichnisse generiert sind und von Hand nicht bearbeitet werden dürfen.
Alles, was der Agent sonst raten müsste — und dabei falsch raten kann —
gehört hierhin.
Viele Agenten lesen auch Anweisungsdateien in Unterverzeichnissen, ein Monorepo kann also eine Root-Datei plus eine spezifischere für jedes Paket tragen. Ob eine tiefere Datei die Root-Datei überschreibt oder ergänzt, unterscheidet sich von Tool zu Tool, prüfen Sie also die Dokumentation des eigenen.
Zehn Zeilen in dieser Datei verhindern, dass der Agent seinen Testbefehl in jeder Sitzung neu entdecken muss.
Wie Sie CLI-Coding-Agenten vergleichen
Sind Schleife und Tool-Liste überall gleich, sagen Feature-Checklisten kaum noch etwas aus. Diese vier Fragen trennen die Tools auf eine Art, die Ihren Alltag tatsächlich betrifft:
| Frage | Was es für Sie bedeutet |
|---|---|
| Wo läuft er: Terminal, IDE oder im Hintergrund? | Ein Terminal-Agent lebt in Ihrer Shell und funktioniert neben jedem Editor. Ein IDE-Agent klinkt sich in die Diff-Ansicht und die Undo-Historie Ihres Editors ein. Ein Hintergrund-Agent arbeitet unbeaufsichtigt anhand einer Aufgabenbeschreibung und übergibt Ihnen einen Pull Request — das passt eher zu klar umrissener Backlog-Arbeit als zu interaktivem Debugging. |
| Ist der Harness Open Source oder proprietär? | Ein offener Harness wie OpenCode oder Aider lässt sich auf jedes Modell richten, auf das Sie API-Zugriff haben, einschließlich eines, das Sie lokal mit Ollama betreiben, und Sie können genau nachlesen, was er tut. Ein proprietärer Harness ist meist auf die eigenen Modelle des Anbieters abgestimmt und braucht weniger Einrichtung. |
| Wie zahlen Sie: pro Token über die API oder im Abo? | Abrechnung pro Token bildet den Verbrauch genau ab, lange autonome Sitzungen kosten also am meisten. Ein Abo deckelt die Ausgaben, bringt aber Nutzungslimits mit sich und bindet Sie an die Modelle eines Anbieters. |
| Wie tief geht die Sandbox? | Manche Agenten führen Befehle direkt auf Ihrer Maschine aus, andere immer innerhalb eines Containers oder einer VM — dieselbe Art Isolation, die Ihnen auch Docker-Container geben. Direkte Ausführung braucht keine Einrichtung und ist die riskantere Wahl für alles, was unbeaufsichtigt weiterläuft. |
Klassifizieren Sie den Modus, nicht die Marke. Ein Anbieter liefert oft ein Terminal-Tool, eine Editor-Erweiterung und einen Cloud-Modus, der Pull Requests öffnet; Claude Code und OpenAI Codex funktionieren beide so. Die Standardwerte für Rechte und Sandbox unterscheiden sich zwischen diesen Modi, beurteilen Sie also den, den Sie tatsächlich nutzen werden.
Wie Sie einen CLI-Coding-Agenten für Ihren Workflow wählen
Lassen Sie die Leaderboards links liegen. Benchmark-Werte bewegen sich alle paar Wochen und sagen wenig über Ihr Repository aus. Beantworten Sie stattdessen zwei Fragen: Wollen Sie den Agenten im Terminal oder im Editor, und soll er unbeaufsichtigt im Hintergrund arbeiten oder in einer Schleife mit Ihnen, die jeden Schritt freigibt? Diese Antworten verengen das Feld auf zwei oder drei Kandidaten.
Schreiben Sie dann eine AGENTS.md für Ihr Projekt, geben Sie jedem
Kandidaten dieselbe echte Aufgabe aus Ihrem Backlog, und behalten Sie den,
dessen Diff Sie mit den wenigsten Änderungen mergen würden.