Ein Coding Agent ist ein KI-System, das ein Large Language Model als Denkzentrum nutzt, um autonom Code zu schreiben, auszuführen und zu iterieren. Im Gegensatz zu einem Code-Assistenten, der in Ihrem Editor Vorschläge macht, durchläuft ein Coding Agent eine vollständige beobachten-entscheiden-handeln-Schleife: Er liest Dateien, schreibt Änderungen, führt Befehle aus, prüft die Ausgabe und überarbeitet, bis die Aufgabe erledigt ist.
Dieser Artikel erklärt, wie diese Schleife funktioniert – den Planer, die LLM-Inferenzschicht, die Werkzeuge und die abgesicherte Ausführungsumgebung – und zeigt dann, wie man einen mit der Novita-LLM-API und dem Agent Sandboard zusammenbaut. Wenn Sie die Ebene der verpackten Werkzeuge statt der Agentenebene suchen, finden Sie diese unter Beste KI-Code-Tools im Jahr 2026. Wenn Sie die Claude-spezifische Variante dieser Schleife möchten, lesen Sie Was ist ein Claude Coding Agent?.
Wenn Sie speziell Open-Source-Tools vergleichen, lesen Sie Open Source Coding Agents: Beste Tools und wie man einen baut.
Was macht etwas zu einem Coding Agent
Der Unterschied zwischen einem Code-Assistenten und einem Coding Agent ist die Ausführung. Ein Code-Assistent erzeugt einen Vorschlag und hört auf. Ein KI-Coding Agent erzeugt Code, führt ihn aus, liest das Ergebnis und macht weiter, bis das Ziel erreicht ist – oder bis er nicht weiterkommt.
Diese Ausführungsfähigkeit hat drei konkrete Anforderungen:
- Werkzeugzugriff – die Fähigkeit, Dateien zu lesen, zu schreiben und Shell-Befehle auszuführen
- Eine abgesicherte Umgebung – ein Ort, um Code auszuführen, ohne das Host-System zu beschädigen, falls etwas schiefgeht
- Ein persistenter Kontext – Werkzeugausgaben fließen zurück in den Kontext des Modells, 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 für alles von IDE-Inline-Vorschlägen bis hin zu vollständig autonomen Systemen, die eine vage spezifizierte Aufgabe entgegennehmen, herausfinden, welche Dateien beteiligt sind, Änderungen vornehmen und überprüfen, dass sie funktionieren – ohne einen Menschen in der Schleife für jeden Schritt. Wenn Entwickler die “besten Code-Agenten” vergleichen, meinen sie normalerweise das Letztere: Systeme, die mehrstufige Codierungsaufgaben zuverlässig und mit minimaler Anleitung abschließen.
Die vier Schichten eines Coding Agent
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 erhält die Aufgabenbeschreibung und zerlegt sie in Schritte, die der Agent ausführen wird. Für einfache Aufgaben geschieht dies implizit innerhalb der Argumentation des Modells. Für komplexe Aufgaben – “Migrieren Sie diesen Dienst zur Verwendung der neuen Auth-Bibliothek” – erzeugt ein expliziter Planungsschritt eine nummerierte Aufgabenliste, die das Modell durcharbeitet und den Status nach jedem Schritt aktualisiert.
Die Planung bestimmt auch, wann aufzuhören ist. Ein Agent ohne Abschlusskriterium wird endlos Verfeinerungen hinzufügen oder, schlimmer noch, auf 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 das Denkzentrum jedes KI-Coding Agent. Es entscheidet, welches Werkzeug als nächstes aufgerufen werden soll, welche Argumente übergeben werden und wie das Ergebnis zu interpretieren ist. Diese Entscheidung wird als strukturierter Werkzeugaufruf 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 (Werkzeugergebnisse sammeln sich schnell an), wohlgeformte Werkzeugaufrufe konsistent zurückgeben (ein schlecht strukturiertes JSON in Schritt 6 eines 10-Schritte-Workflows zerstört den gesamten Lauf) und über viele sequentielle Werkzeugaufrufe hinweg über Zustandsänderungen nachdenken.
Der Inferenzanbieter ist hier wichtig. Sie benötigen eine API, die Funktionsaufrufe im OpenAI-kompatiblen Format unterstützt, strukturierte Ausgaben, um auf Modellebene gültiges JSON zu erzwingen, und ausreichende Gleichzeitigkeitslimits für Agent-Workloads, die parallele Unteraufgaben starten. Die LLM-API von Novita AI deckt alle drei mit einem OpenAI-kompatiblen Endpunkt ab, was bedeutet, dass Sie Modelle austauschen können, ohne die Parsing-Logik für Werkzeugaufrufe neu zu schreiben.
3. Die Werkzeugschicht
Werkzeuge sind die Schnittstelle des Agenten zur Welt. Ein minimaler Coding Agent benötigt vier:
| Werkzeug | Was es tut |
|---|---|
read_file |
Gibt den Inhalt einer Datei an einem angegebenen 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 Werkzeug muss vollständige Ausgaben zurückgeben. Abgeschnittene Ergebnisse oder stille Fehler beschädigen das Modell des Codebestands durch den Agenten und verursachen später sich verstärkende Fehler. Insbesondere das Werkzeug run_command muss sowohl stdout als auch stderr erfassen – der Agent lernt oft mehr aus Fehlerausgaben als aus Erfolgsausgaben.
Einige Agenten fügen ein search_files-Werkzeug für grep-ähnliche Suchen in einem Codebestand hinzu, oder ein fetch_url-Werkzeug zum Lesen externer Dokumentation. Die richtige Auswahl hängt vom Aufgabenbereich ab. Für reine Codearbeit decken die vier oben genannten die meisten Fälle ab.
4. Die Sandbox
Die Sandbox ist eine vollständige 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 Benutzeraufforderungen, abgerufener Dokumentation und abgeleiteten Mustern. Selbst ein wohlmeinender Agent kann Code erzeugen, der Dateien löscht, Netzwerkverbindungen öffnet oder unbegrenzte Ressourcen verbraucht. Eine Sandbox hält jeden Schaden innerhalb einer isolierten Umgebung.
Zweitens, Zustandsbehaftung. Eine gute Sandbox bewahrt den Dateisystemzustand über Werkzeugaufrufe 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 reale Codierungsaufgaben.
Der Novita Agent Sandbox basiert auf Firebase-MikroVMs, die eine Kernel-Isolation auf einer Ebene bieten, die stärker ist als bei Standard-Containern. Sitzungen können bis zu 24 Stunden laufen, der Dateisystemzustand bleibt über Befehle hinweg erhalten, und der Kaltstart liegt 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: “Ratenbegrenzung für den /login-Endpunkt hinzufügen.”
-
Planen – das Modell liest die Aufgabe und identifiziert, was es braucht: Finde die Login-Route, verstehe den aktuellen Handler, füge Ratenbegrenzungs-Middleware hinzu, überprüfe mit einem Testlauf.
-
Beobachten – der Agent ruft
list_directoryauf, um die Routendateien zu finden, dannread_fileauf dem 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: Installiere die Ratenbegrenzungsbibliothek, modifiziere den Handler, füge einen Test hinzu.
-
Handeln – der Agent ruft
run_command("pip install slowapi")auf, dannwrite_filemit dem geänderten Handler, dannrun_command("pytest tests/test_login.py"). -
Erneut beobachten – die Testausgabe fließt zurück in den Kontext. Wenn Tests fehlschlagen, liest das Modell den Traceback, identifiziert den Fehler und schreibt eine korrigierte Datei.
-
Abschließen – wenn Tests bestanden werden 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 Werkzeugaufruf sammelt sich dort an. Deshalb ist die Kontextlänge für Coding Agents so wichtig: Eine echte Refactoring-Aufgabe kann bis Schritt 15 leicht 100K Token füllen. Sehen Sie, wie Agenten Inferenzanbieter anders belasten als Einmal-Chats.
Erstellen eines Coding Agent mit Novita
Das folgende Beispiel verdrahtet die Novita-LLM-API mit dem Agent Sandbox. Es verwendet das Python OpenAI SDK, das auf Novitas Endpunkt ausgerichtet ist – Novitas Modelle verwenden dieselbe Funktionsaufruf-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,
}
)
# Replace <model-id> with a function-calling model from novita.ai/docs
result = run_agent(
task="Write a Python script that counts words in a text file and run it on a sample input",
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 Werkzeugaufrufe zurückgibt – das ist das Signal, dass der Agent die Aufgabe als erledigt betrachtet. - Werkzeugergebnisse werden an
messagesalsrole: tool-Einträge angehängt. Dadurch wird der gemeinsame Kontext über mehrere Schritte hinweg aufgebaut. sandbox.kill()gibt die Rechenressourcen frei. Rufen Sie es immer auf, wenn die Sitzung endet.
Für unterstützte Funktionsaufruf-Modell-IDs überprüfen Sie die Novita-Funktionsaufruf-Dokumentation. Für eine umfassendere Anleitung einschließlich einer Gradio-Oberfläche siehe Building a Coding Agent with Novita’s Agent Sandbox.
Das richtige LLM für Code-Agenten auswählen
HumanEval und SWE-bench messen die einmalige Codegenerierung. Agent-Workloads sind anders – was tatsächlich Produktionscode-Agenten zum Scheitern bringt, sind Formatierungsfehler bei Werkzeugaufrufen. Ein Modell, das in Benchmarks gut abschneidet, aber gelegentlich in komplexen Multi-Turn-Sitzungen fehlerhaftes JSON zurückgibt, wird auf eine Weise scheitern, die schwer zu debuggen ist.
Die praktischen Bewertungskriterien für KI-Coding-Agenten:
- Zuverlässigkeit der Werkzeugaufrufe – wie konsistent gibt das Modell wohlgeformte Werkzeugaufrufe über Sitzungen mit mehr als 20 Schritten zurück?
- Kontexterhaltung – bezieht sich das Modell korrekt auf eine Datei, die es vor 40 Schritten gelesen hat?
- Anweisungsbefolgung – bleibt der Agent bei der Aufgabe oder beginnt er, nicht zusammenhängende Dateien zu ändern?
- 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 Aufgabenerledigungsrate ist aussagekräftiger als jeder öffentliche Benchmark. Wählen Sie 20–30 Aufgaben aus Ihrer eigenen Codebasis, führen Sie sie mit Kandidatenmodellen aus und zählen Sie, wie viele ohne menschlichen Eingriff abgeschlossen werden.
Die Inferenzkosten summieren sich bei Agentenskala schnell. Eine einzelne Sitzung kann 200K–500K Token über alle Runden verbrauchen. Anbieter, die Prompt-Caching und wettbewerbsfähige Preise pro Token anbieten, ändern die Wirtschaftlichkeit erheblich, wenn Sie Hunderte von Agentensitzungen pro Tag ausführen.
Open-Source-Modelle als kosteneffizienter Weg
Closed-Source-Frontier-Modelle haben bei Codierungs-Benchmarks geführt, aber die Lücke zu den besten Open-Source-Modellen hat sich erheblich verringert. Modelle wie DeepSeek V3 und Qwen3 sind heute wettbewerbsfähig bei der Codegenerierung und Werkzeugnutzung – und da sie über OpenAI-kompatible APIs bereitgestellt werden, ist der Wechsel eine einzeitige Ä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 GPU-Infrastruktur selbst verwalten zu müssen. Dies ist wichtig, da GPU-Orchestrierung, Batching und Zuverlässigkeitstechnik nicht trivial sind; Ihre Delegation an eine verwaltete API ermöglicht es Ihnen, sich auf die Agentenlogik zu konzentrieren.
Warum dies speziell für Coding Agents wichtig ist: Die Tokenkosten pro Sitzung treiben die Wirtschaftlichkeit von Agent-Workloads stärker voran als Lizenzgebühren. Ein Team, das 200 Coding-Agent-Sitzungen pro Tag ausführt und mit einem Open-Source-Modell vergleichbare Aufgabenerledigungsraten erzielt, kann die Inferenzausgaben erheblich reduzieren, ohne seinen Integrationscode überhaupt zu ändern.
Der praktische Test: Führen Sie 50 repräsentative Codierungsaufgaben mit Ihrem Zielmodell aus, messen Sie die Erfolgsrate der Werkzeugaufrufe und die Aufgabenerledigungsrate, und vergleichen Sie dann mit den 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) erzeugt Vorschläge und hört auf. Ein Coding Agent führt den Code aus, liesst die Ausgabe und iteriert. Das bestimmende Merkmal ist die Ausführungsschleife: lesen, entscheiden, handeln, beobachten, wiederholen. Siehe CLI vs IDE Coding Agent für einen Vergleich, wie verschiedene Agenten-Formfaktoren diese Schleife nutzen.
Brauche ich eine Sandbox, um einen Coding Agent zu bauen?
Ja, wenn der Agent Code ausführen wird, der aus Benutzereingaben oder externen Quellen generiert wurde. Ohne Isolierung kann eine fehlerhafte Codegenerierung das Host-Dateisystem beschädigen oder unbegrenzte Ressourcen verbrauchen. Selbst für rein interne Anwendungsfälle verhindert eine Sandbox, dass außer Kontrolle geratene Prozesse den Host beeinträchtigen. Container bieten grundlegende Isolierung; MikroVM-basierte Sandboxen wie die von Novita bieten eine stärkere Kernel-Isolierung für mandantenfähige oder sicherheitskritische 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 Workflows ab. Das Einschränken des ausgehenden Datenverkehrs innerhalb der Sandbox ist tatsächlich eine gute Standardeinstellung – es 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 Werkzeugaufrufe und die Aufgabenerledigungsrate bei Ihrem tatsächlichen Workload. Öffentliche Benchmark-Rankings sind ein Ausgangspunkt für die Auswahl von Modellen, nicht die endgültige Antwort. Führen Sie Ihre repräsentativen Aufgaben aus, messen Sie die Erledigungsrate und berücksichtigen Sie die Tokenkosten pro Sitzung. Der beste Code-Agent für ein kleines Startup, das leichte Refactoring-Arbeiten durchführt, kann sich stark von der besten Option für ein Enterprise-Team unterscheiden, das automatisierte PR-Überprüfungen 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, was selbst umfangreiche Refactoring- oder Migrationsaufgaben abdeckt, ohne dass Checkpoint-/Wiederherstellungslogik in Ihrem Agentencode erforderlich ist.
