Ein Coding Agent ist ein KI-System, das ein großes Sprachmodell als seine Denk-Komponente verwendet, um autonom Code zu schreiben, auszuführen und zu iterieren. Im Gegensatz zu einem Code-Assistenten, der Vorschläge in Ihrem Editor anzeigt, durchläuft ein Coding Agent eine vollständige Beobachten-Entscheiden-Handeln-Schleife: Er liest Dateien, schreibt Änderungen, führt Befehle aus, überprüft die Ausgabe und überarbeitet, bis die Aufgabe erledigt ist.
Dieser Artikel erklärt, wie diese Schleife funktioniert – der Planer, die LLM-Inferenzschicht, die Tools und die Sandbox-Ausführungsumgebung – und zeigt dann, wie man eine solche mit der Novita-LLM-API und dem Agent Sandbox zusammenstellt. Wenn Sie die verpackte Tool-Ebene anstelle der Agent-Ebene suchen, lesen Sie Beste KI-Coding-Tools im Jahr 2026. Wenn Sie die Claude-spezifische Variante dieser Schleife suchen, lesen Sie Was ist ein Claude Coding Agent?.
Für einen tieferen Einblick in praktische Modellentscheidungen innerhalb dieser Architektur lesen Sie Anwendungsfälle großer Sprachmodelle für Coding Agents.
Wenn Sie die praktische Workflow-Version derselben Schleife suchen, lesen Sie Wie man Aufgaben mit KI automatisiert.
Wenn Sie speziell Open-Source-Tools vergleichen, lesen Sie Open-Source-Coding-Agents: Beste Tools und wie man einen erstellt.
Was macht etwas zu einem Coding Agent?
Der Unterschied zwischen einem Code-Assistenten und einem Coding Agent ist die Ausführung. Ein Code-Assistent generiert einen Vorschlag und stoppt. Ein KI-Coding-Agent generiert Code, führt ihn aus, liest das Ergebnis und macht weiter, bis das Ziel erreicht ist – oder bis er nicht mehr weiterkommt.
Diese Ausführungsfähigkeit erfordert drei konkrete Voraussetzungen:
- Tool-Zugriff – die Fähigkeit, Dateien zu lesen, Dateien zu schreiben und Shell-Befehle auszuführen
- Eine Sandbox-Umgebung – einen Ort, um Code auszuführen, der das Host-System nicht beschädigt, falls etwas schiefgeht
- Ein persistenter Kontext – Tool-Ausgaben werden wieder in den Kontext des Modells eingespeist, damit es über das Geschehene nachdenken kann
Ohne alle drei haben Sie einen Chatbot, der Code schreiben kann. Mit allen drei haben Sie einen Agenten.
Der Begriff “Code-Agent” wird locker verwendet und deckt alles ab, von IDE-Inline-Vorschlägen bis hin zu vollständig autonomen Systemen, die eine vage spezifizierte Aufgabe übernehmen, herausfinden, welche Dateien betroffen sind, Änderungen vornehmen und überprüfen, ob sie funktionieren – ohne dass für jeden Schritt ein Mensch im Kreislauf sein muss. Wenn Entwickler die “besten Code-Agenten” vergleichen, meinen sie normalerweise Letzteres: Systeme, die mehrstufige Codierungsaufgaben zuverlässig und mit minimaler Anleitung erledigen.
Die vier Schichten eines Coding Agents
Jeder produktionsreife KI-Coding-Agent hat vier erkennbare Komponenten. Die Implementierungsdetails variieren – verschiedene Frameworks, verschiedene LLMs, verschiedene Sandbox-Anbieter – aber die Architektur ist konsistent.
1. Der Planer
Der Planer empfängt die Aufgabenbeschreibung und zerlegt sie in Schritte, die der Agent ausführen wird. Bei einfachen Aufgaben geschieht dies implizit im Denkprozess des Modells. Bei komplexen Aufgaben – “Migrieren Sie diesen Dienst zur Verwendung der neuen Auth-Bibliothek” – erzeugt ein expliziter Planungsschritt eine nummerierte Aufgabenliste, die das Modell abarbeitet und nach jedem Schritt den Status aktualisiert.
Die Planung bestimmt auch, wann gestoppt werden soll. Ein Agent ohne Abschlusskriterium wird endlos Verfeinerungen hinzufügen oder, schlimmer noch, in einem fehlgeschlagenen Schritt schleifen. Die meisten Implementierungen kodieren die Erfolgsbedingung der Aufgabe in den System-Prompt und lassen das Modell entscheiden, wann es fertig ist.
2. Die LLM-Inferenzschicht
Das LLM ist der Denkkern jedes KI-Coding-Agenten. Es entscheidet, welches Tool als nächstes aufgerufen wird, welche Argumente übergeben werden und wie das Ergebnis zu interpretieren ist. Diese Entscheidung wird als strukturierter Tool-Aufruf ausgedrückt – ein JSON-Objekt mit dem Funktionsnamen und den Parametern –, den das Framework an die eigentliche Ausführungsschicht weiterleitet.
Für Code-Agenten muss das LLM lange Kontexte zuverlässig verarbeiten können (Tool-Ergebnisse sammeln sich schnell an), konsistent wohlgeformte Tool-Aufrufe zurückgeben (ein schlecht strukturiertes JSON bei Schritt 6 eines 10-Schritte-Workflows zerstört den gesamten Durchlauf) und über viele sequenzielle Tool-Aufrufe hinweg über Zustandsänderungen nachdenken können.
Der Inferenzanbieter ist hier wichtig. Sie benötigen eine API, die Funktionaufrufe im OpenAI-kompatiblen Format unterstützt, strukturierte Ausgaben, um gültiges JSON auf Modellebene zu erzwingen, und ausreichende Parallelitätslimits für Agent-Workloads, die parallele Unteraufgaben erzeugen. Die Novita AI LLM-API deckt alle drei mit einem OpenAI-kompatiblen Endpunkt ab, was bedeutet, dass Sie Modelle austauschen können, ohne die Parsing-Logik für Tool-Aufrufe neu schreiben zu müssen.
3. Die Tool-Schicht
Tools sind die Schnittstelle des Agenten zur Welt. Ein minimaler Coding Agent benötigt vier:
| Tool | Was es tut |
|---|---|
read_file |
Gibt den Inhalt einer Datei an einem bestimmten Pfad zurück |
write_file |
Schreibt einen String in einen Dateipfad |
run_command |
Führt einen Shell-Befehl aus und gibt stdout + stderr zurück |
list_directory |
Listet Dateien und Verzeichnisse an einem Pfad auf |
Jedes Tool muss vollständige Ausgaben zurückgeben. Abgeschnittene Ergebnisse oder stille Fehler korrumpieren das Modell des Codebestands des Agenten und verursachen später sich verstärkende Fehler. Das run_command-Tool muss insbesondere sowohl stdout als auch stderr erfassen – der Agent lernt oft mehr aus Fehlerausgaben als aus Erfolgsausgaben.
Einige Agenten fügen ein search_files-Tool für grep-artige Suchen über den Codebestand hinzu oder ein fetch_url-Tool zum Lesen externer Dokumentation. Die richtige Menge hängt vom Aufgabenbereich ab. Für reine Code-Arbeit decken die vier oben genannten die meisten Fälle ab.
4. Die Sandbox
Die Sandbox ist eine vollständig isolierte Linux-Umgebung, in der die Befehle des Agenten tatsächlich ausgeführt werden. Dies ist aus zwei Gründen wichtig.
Erstens, Sicherheit. Agenten generieren Code aus Benutzerprompts, abgerufener Dokumentation und abgeleiteten Mustern. Selbst ein wohlmeinender Agent kann Code produzieren, der Dateien löscht, Netzwerkverbindungen öffnet oder unbegrenzte Ressourcen verbraucht. Eine Sandbox hält Schäden innerhalb einer isolierten Umgebung.
Zweitens, Zustandsbehaftung. Eine gute Sandbox bewahrt den Dateisystemzustand über Tool-Aufrufe innerhalb einer Sitzung hinweg. Wenn der Agent in Schritt 2 eine Datei erstellt, muss sie in Schritt 8 noch vorhanden sein. Zustandslose Container-Ansätze – bei denen jeder Befehl in einer frischen Umgebung ausgeführt wird – funktionieren nicht für echte Codierungsaufgaben.
Novita Agent Sandbox basiert auf Firecracker-MicroVMs, die eine Kernel-Isolation bieten, die stärker ist als bei Standardcontainern. Sitzungen können bis zu 24 Stunden laufen, der Dateisystemzustand bleibt über Befehle hinweg erhalten, und der Kaltstart dauert unter 200 ms. Das ist schnell genug, dass das Warten auf das Hochfahren der Sandbox einen interaktiven Workflow nicht unterbricht.
Wie die Ausführungsschleife funktioniert
Ein konkretes Beispiel macht die Schleife leichter nachvollziehbar. Angenommen, die Aufgabe lautet: “Füge dem /login-Endpunkt Ratenbegrenzung hinzu.”
-
Planen – das Modell liest die Aufgabe und identifiziert, was es braucht: die Login-Route finden, den aktuellen Handler verstehen, Ratenbegrenzungs-Middleware hinzufügen, mit einem Testlauf verifizieren.
-
Beobachten – der Agent ruft
list_directoryauf, um die Routendateien zu finden, dannread_filefür den Login-Handler. Die Dateiinhalte werden an den Modellkontext angehängt. -
Entscheiden – das Modell denkt über den aktuellen Code nach und entscheidet, was zu tun ist: die Rate-Limit-Bibliothek installieren, den Handler modifizieren, einen Test hinzufügen.
-
Handeln – der Agent ruft
run_command("pip install slowapi")auf, dannwrite_filemit dem modifizierten Handler, dannrun_command("pytest tests/test_login.py"). -
Wieder beobachten – die Testausgabe wird zurück in den Kontext eingespeist. Wenn Tests fehlschlagen, liest das Modell den Traceback, identifiziert den Fehler und schreibt eine korrigierte Datei.
-
Abschließen – wenn Tests bestanden sind und das Modell keine ausstehenden Schritte hat, gibt es eine abschließende Zusammenfassung zurück.
Diese Schleife läuft innerhalb einer einzigen Sitzung. Das Kontextfenster ist das Arbeitsgedächtnis des Agenten – jede gelesene Datei, jede Befehlsausgabe, jeder Tool-Aufruf sammelt sich dort an. Deshalb ist die Kontextlänge für Coding Agents so wichtig: Eine echte Refactoring-Aufgabe kann bis Schritt 15 leicht 100.000 Token füllen. Erfahren Sie, wie Agenten Inferenzanbieter anders belasten als Einzel-Chat.
Erstellen eines Coding Agents mit Novita
Das folgende Beispiel verbindet die Novita-LLM-API und den Agent Sandbox. Es verwendet das Python OpenAI SDK, das auf den Novita-Endpunkt zeigt – Novitas Modelle verwenden dieselbe Funktionaufruf-Schnittstelle wie die OpenAI-API, sodass die Integration kein benutzerdefiniertes Parsen erfordert.
import os
import json
from openai import OpenAI
from novita_sandbox.code_interpreter import Sandbox
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
sandbox = Sandbox.create(timeout=1800)
def read_file(path: str) -> str:
try:
return sandbox.files.read(path)
except Exception as e:
return f"Error: {e}"
def write_file(path: str, content: str) -> str:
try:
sandbox.files.write(path, content)
return f"Written to {path}"
except Exception as e:
return f"Error: {e}"
def run_command(cmd: str) -> str:
try:
result = sandbox.commands.run(cmd)
return str(result)
except Exception as e:
return f"Error: {e}"
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read the contents of a file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "write_file",
"description": "Write content to a file",
"parameters": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"},
},
"required": ["path", "content"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox and return output",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
dispatch = {
"read_file": read_file,
"write_file": write_file,
"run_command": run_command,
}
def run_agent(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a coding agent with access to a Linux sandbox. "
"Complete tasks by calling tools. When done, return a plain-text summary."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for call in msg.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
# Ersetzen Sie <model-id> durch ein funktionsaufrufendes Modell von novita.ai/docs
result = run_agent(
task="Schreiben Sie ein Python-Skript, das Wörter in einer Textdatei zählt, und führen Sie es für eine Beispiel-Eingabe aus",
model="<model-id>",
)
print(result)
sandbox.kill()
Einige Dinge, die Sie bei dieser Implementierung beachten sollten:
- Die
while True-Schleife läuft, bis das Modell eine Nachricht ohne Tool-Aufrufe zurückgibt – das ist das Signal, dass der Agent die Aufgabe als erledigt betrachtet. - Tool-Ergebnisse werden als
role: tool-Einträge anmessagesangehängt. Dadurch wird der gemeinsame Kontext über Schritte hinweg aufgebaut. sandbox.kill()gibt die Rechenressourcen frei. Rufen Sie es immer am Ende der Sitzung auf.
Unterstützte Funktionsaufruf-Modell-IDs finden Sie in der Novita-Dokumentation zu Funktionsaufrufen. Für eine umfassendere Anleitung einschließlich einer Gradio-Benutzeroberfläche lesen Sie Erstellen eines Coding Agents mit Novitas Agent Sandbox.
Das richtige LLM für Code-Agenten auswählen
HumanEval und SWE-bench messen die Codegenerierung in einem einzigen Durchlauf. Agent-Workloads sind anders – was produktionsreife Code-Agenten tatsächlich zum Scheitern bringt, sind Fehler bei der Formatierung von Tool-Aufrufen. Ein Modell, das in Benchmarks gut abschneidet, aber gelegentlich fehlerhaftes JSON in komplexen mehrstufigen Sitzungen zurückgibt, wird auf schwer zu debuggende Weise scheitern.
Die praktischen Bewertungskriterien für KI-Coding-Agenten:
- Zuverlässigkeit der Tool-Aufrufe – wie konsistent gibt das Modell wohlgeformte Tool-Aufrufe über Sitzungen mit 20+ Schritten zurück?
- Kontextbeibehaltung – referenziert das Modell korrekt eine Datei, die es vor 40 Schritten gelesen hat?
- Befolgung von Anweisungen – bleibt der Agent bei der Aufgabe oder beginnt er, nicht verwandte Dateien zu modifizieren?
- Code-Korrektheit – läuft der generierte Code tatsächlich oder erfordert er mehrere Korrekturschleifen?
Das Ausführen eines repräsentativen Satzes realer Codierungsaufgaben und das Messen der Aufgabenerfüllungsrate ist aufschlussreicher als jeder öffentliche Benchmark. Wählen Sie 20–30 Aufgaben aus Ihrer eigenen Codebasis aus, führen Sie sie mit Kandidatenmodellen aus und zählen Sie, wie viele ohne menschliches Eingreifen abgeschlossen werden.
Die Inferenzpreise summieren sich schnell im Agentenmaßstab. Eine einzelne Sitzung könnte 200.000–500.000 Token über alle Durchläufe hinweg verbrauchen. Anbieter, die Prompt-Caching und wettbewerbsfähige Preise pro Token anbieten, verändern die Wirtschaftlichkeit erheblich, wenn Sie Hunderte von Agentensitzungen pro Tag ausführen.
Open-Source-Modelle als kosteneffektiver Weg
Proprietäre Frontier-Modelle haben bei Coding-Benchmarks geführt, aber die Lücke zu den besten Open-Source-Modellen hat sich erheblich verkleinert. Modelle wie DeepSeek V3 und Qwen3 sind jetzt bei Codegenerierung und Tool-Nutzung wettbewerbsfähig – und da sie über OpenAI-kompatible APIs bereitgestellt werden, ist der Wechsel eine einzeilige Änderung des model-Parameters.
Beide sind über die Novita-LLM-API verfügbar. Sie erhalten denselben Endpunkt, dieselbe Funktionsaufruf-Schnittstelle und dieselbe Agent-Sandbox-Integration – ohne die GPU-Infrastruktur selbst verwalten zu müssen. Dies ist wichtig, da GPU-Orchestrierung, Batching und Zuverlässigkeitstechnik nicht trivial sind; die Delegierung an eine verwaltete API ermöglicht es Ihnen, sich auf die Agentenlogik zu konzentrieren.
Warum dies speziell für Coding Agents wichtig ist: Die Token-Kosten pro Sitzung treiben die Wirtschaftlichkeit von Agenten-Workloads stärker als Lizenzgebühren. Ein Team, das 200 Coding-Agent-Sitzungen pro Tag ausführt und mit einem Open-Source-Modell vergleichbare Aufgabenerfüllungsraten erzielt, kann die Inferenzausgaben erheblich senken, ohne den Integrationscode überhaupt ändern zu müssen.
Der praktische Test: Führen Sie 50 repräsentative Codierungsaufgaben mit Ihrem Zielmodell aus, messen Sie die Erfolgsrate der Tool-Aufrufe und die Aufgabenerfüllungsrate, und vergleichen Sie dann die Kosten pro Sitzung. Benchmark-Zahlen werden diese Frage nicht beantworten – Ihr tatsächlicher Workload wird es tun.
FAQ
Was ist der Unterschied zwischen einem Coding Agent und einem Code-Assistenten?
Ein Code-Assistent (wie die Inline-Vorschläge von GitHub Copilot) generiert Vervollständigungen und stoppt. Ein Coding Agent führt Code aus, liest die Ausgabe und iteriert. Das charakteristische Merkmal ist die Ausführungsschleife: Lesen, Entscheiden, Handeln, Beobachten, Wiederholen. Siehe CLI vs. IDE Coding Agent für einen Vergleich, wie verschiedene Agent-Formfaktoren diese Schleife nutzen.
Brauche ich eine Sandbox, um einen Coding Agent zu erstellen?
Ja, wenn der Agent Code ausführen wird, der aus Benutzereingaben oder externen Quellen generiert wurde. Ohne Isolation kann eine fehlerhafte Codegenerierung das Host-Dateisystem beschädigen oder unbegrenzte Ressourcen verbrauchen. Selbst für reine Interne-Anwendungsfälle verhindert eine Sandbox, dass außer Kontrolle geratene Prozesse den Host beeinträchtigen. Container bieten grundlegende Isolation; MicroVM-basierte Sandboxes wie die von Novita bieten eine stärkere Kernel-Level-Trennung für Multi-Tenant- oder sicherheitssensible Workloads.
Kann ein Coding Agent ohne Internetzugang arbeiten?
Für die meisten reinen Codierungsaufgaben ja. Datei-Lese-/Schreibzugriff und lokale Befehlsausführung decken die Mehrheit der Workloads ab. Die Einschränkung des ausgehenden Datenverkehrs innerhalb der Sandbox ist tatsächlich eine gute Standardeinstellung – sie verhindert, dass generierter Code unerwartete externe Anfragen stellt, und vereinfacht Ihr Bedrohungsmodell.
Was bestimmt den besten Code-Agenten für eine bestimmte Aufgabe?
Die Zuverlässigkeit der Tool-Aufrufe und die Aufgabenerfüllungsrate bei Ihrem tatsächlichen Workload. Öffentliche Benchmark-Rankings sind ein Ausgangspunkt für die Vorauswahl von Modellen, keine endgültige Antwort. Führen Sie Ihre repräsentativen Aufgaben aus, messen Sie die Erfüllungsrate und berücksichtigen Sie die Token-Kosten pro Sitzung. Der beste Code-Agent für ein kleines Startup, das leichte Refactorings durchführt, kann sich stark von der besten Option für ein Unternehmensteam unterscheiden, das automatisierte PR-Reviews in großem Maßstab durchführt.
Wie lange kann eine Coding-Agent-Sitzung laufen?
Das hängt vom Sandbox-Anbieter ab. Novita Agent Sandbox unterstützt Sitzungen von bis zu 24 Stunden, wobei der Dateisystemzustand über Befehle hinweg erhalten bleibt. Dies deckt auch umfangreiche Refactoring- oder Migrationsaufgaben ab, ohne dass eine Checkpoint/Restore-Logik in Ihrem Agenten-Code erforderlich ist.
