Ein Coding Agent ist ein KI-System, das ein Large Language Model als seine logische Kernkomponente nutzt, um autonom Code zu schreiben, auszuführen und zu iterieren. Im Gegensatz zu einem Code-Assistenten, der in Ihrem Editor Vervollständigungen vorschlägt, führt ein Coding Agent einen vollständigen Observe-Decide-Act-Kreislauf aus: 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 dieser Kreislauf funktioniert – der Planer, die LLM-Inferenzschicht, die Tools und die sandboxing-Ausführungsumgebung – und zeigt dann, wie man einen mit der Novita-LLM-API und dem Agent Sandbook zusammenbaut.
Was macht etwas zu einem Coding Agent?
Der Unterschied zwischen einem Code-Assistenten und einem Coding Agent liegt in der 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 hat drei konkrete Anforderungen:
- Tool-Zugriff – die Fähigkeit, Dateien zu lesen, Dateien zu schreiben und Shell-Befehle auszuführen
- Eine sandboxing-Umgebung – einen Ort, um Code auszuführen, der das Hostsystem nicht beschädigt, falls etwas schiefgeht
- Ein persistenter Kontext – Tool-Ausgaben 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 Agent.
Der Begriff “Code Agent” wird locker verwendet und umfasst alles 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 ein Mensch für jeden Schritt eingreifen muss. Wenn Entwickler die Optionen für den “besten Code-Agenten” vergleichen, meinen sie normalerweise Letzteres: Systeme, die mehrstufige Codierungsaufgaben zuverlässig und mit minimaler Anleitung abschließen.
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 erhält die Aufgabenbeschreibung und zerlegt sie in Schritte, die der Agent ausführen wird. Bei einfachen Aufgaben geschieht dies implizit innerhalb der Argumentation 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 durcharbeitet und den Status nach jedem Schritt aktualisiert.
Die Planung bestimmt auch, wann anzuhalten ist. Ein Agent ohne Abbruchkriterium wird endlos Verfeinerungen hinzufügen oder, schlimmer noch, bei einem fehlgeschlagenen Schritt in einer Schleife hängen bleiben. Die meisten Implementierungen kodieren die Erfolgsbedingung der Aufgabe im System-Prompt und überlassen es dem Modell zu entscheiden, wann es fertig ist.
2. Die LLM-Inferenzschicht
Das LLM ist der logische Kern jedes KI-Coding Agents. 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-Agents muss das LLM lange Kontexte zuverlässig verarbeiten (Tool-Ergebnisse summieren sich schnell), wohlgeformte Tool-Aufrufe konsistent zurückgeben (ein schlecht strukturiertes JSON in Schritt 6 eines 10-Schritte-Workflows bricht den gesamten Durchlauf) und über Zustandsänderungen über viele sequentielle Tool-Aufrufe hinweg nachdenken.
Der Inferenzanbieter spielt hier eine Rolle. Sie benötigen eine API, die Funktionsaufrufe im OpenAI-kompatiblen Format unterstützt, strukturierte Ausgaben, um gültiges JSON auf Modellebene zu erzwingen, und ausreichende Nebenläufigkeitsgrenzen 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 minimalistischer Coding-Agent benötigt vier:
| Tool | Funktion |
|---|---|
read_file |
Gibt den Inhalt einer Datei unter 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 unter einem Pfad auf |
Jedes Tool muss eine vollständige Ausgabe zurückgeben. Abgeschnittene Ergebnisse oder stille Fehlschläge beschädigen das Modell des Agenten von der Codebasis und führen später zu sich verstärkenden Fehlern. 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 Suche in einer Codebasis oder ein fetch_url-Tool zum Lesen externer Dokumentation hinzu. Die richtige Menge hängt vom Aufgabengebiet ab. Für reine Codierungsarbeit 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 Benutzereingaben, abgerufener Dokumentation und abgeleiteten Mustern. Selbst ein gut gemeinter Agent kann Code erzeugen, 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 mehrere Tool-Aufrufe innerhalb einer Sitzung hinweg auf. 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.
Der Novita Agent Sandbox basiert auf Firecracker-MicroVMs, die eine Kernel-Level-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 der Ausführungskreislauf funktioniert
Ein konkretes Beispiel macht den Kreislauf leichter nachvollziehbar. Angenommen, die Aufgabe lautet: “Fügen Sie 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 Ratenbegrenzungs-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"). -
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 die Tests bestehen und das Modell keine ausstehenden Schritte hat, gibt es eine abschließende Zusammenfassung zurück.
Dieser Kreislauf 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-Chats.
Einen Coding Agent mit Novita bauen
Das folgende Beispiel verbindet die Novita LLM-API und den Agent Sandbox. Es verwendet das Python-OpenAI-SDK, das auf den Novita-Endpunkt zeigt – die Modelle von Novita verwenden dieselbe Funktionsaufruf-Schnittstelle wie die OpenAI-API, sodass die Integration kein benutzerdefiniertes Parsing 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 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 die 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 lesen Sie die Novita-Dokumentation zu Funktionsaufrufen. Eine umfassendere Anleitung mit einer Gradio-Oberfläche finden Sie unter Building a Coding Agent with Novita’s Agent Sandbox.
Das richtige LLM für Code-Agenten auswählen
HumanEval und SWE-bench messen die Codegenerierung in einem einzigen Durchgang. Agent-Workloads sind anders – was produktionsreife Code-Agenten tatsächlich zum Scheitern bringt, sind Formatierungsfehler bei Tool-Aufrufen. 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 von Tool-Aufrufen – wie konsistent gibt das Modell wohlgeformte Tool-Aufrufe über Sitzungen mit 20+ Schritten zurück?
- Kontextspeicherung – bezieht sich das Modell korrekt auf eine Datei, die es vor 40 Schritten gelesen hat?
- Befolgungsfähigkeit – 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 einer repräsentativen Menge realer Codierungsaufgaben und das Messen der Abschlussrate ist aussagekräftiger 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 Inferenzkosten summieren sich schnell im Agenten-Maßstab. Eine einzige Sitzung kann 200.000–500.000 Token über alle Durchläufe hinweg verbrauchen. Anbieter, die Prompt-Caching und wettbewerbsfähige Preise pro Token anbieten, ändern die Ökonomie erheblich, wenn Sie Hunderte von Agentensitzungen pro Tag ausführen.
Open-Source-Modelle als kosteneffizienter Weg
Closed-Source-Spitzenmodelle haben bei Codierungs-Benchmarks geführt, aber der Abstand zu den besten Open-Source-Modellen hat sich deutlich verringert. Modelle wie DeepSeek V3 und Qwen3 sind jetzt bei der Codegenerierung und Tool-Nutzung konkurrenzfähig – und da sie über OpenAI-kompatible APIs bereitgestellt werden, ist der Wechsel eine Änderung in einer Zeile im Parameter model.
Beide sind über die Novita LLM-API verfügbar. Sie erhalten denselben Endpunkt, dieselbe Funktionsaufruf-Schnittstelle und dieselbe Agent Sandbox-Integration – ohne selbst GPU-Infrastruktur verwalten zu müssen. Dies ist wichtig, weil 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 agentischer Workloads mehr 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 reduzieren, ohne seine Integrations-Code zu ändern.
Der praktische Test: Führen Sie 50 repräsentative Codierungsaufgaben mit Ihrem Zielmodell aus, messen Sie die Erfolgsrate von Tool-Aufrufen und die Aufgabenerfüllungsrate und vergleichen Sie sie 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) generiert Vervollständigungen und stoppt. Ein Coding Agent führt Code aus, liest die Ausgabe und iteriert. Das bestimmende Merkmal ist der Ausführungskreislauf: lesen, entscheiden, handeln, beobachten, wiederholen. Siehe CLI vs IDE Coding Agent für einen Vergleich, wie verschiedene Agent-Formfaktoren diesen Kreislauf 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 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 Sandboxen wie die von Novita bieten eine stärkere Kernel-Level-Trennung für Multi-Tenant- 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. Die Einschränkung des ausgehenden Datenverkehrs innerhalb der Sandbox ist sogar 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 von Tool-Aufrufen und die Aufgabenerfüllungsrate bei Ihrem tatsächlichen Workload. Öffentliche Benchmark-Rankings sind ein Ausgangspunkt für die Vorauswahl von Modellen, nicht die endgültige Antwort. Führen Sie Ihre repräsentativen Aufgaben aus, messen Sie die Erfüllungsrate und beziehen Sie die Token-Kosten pro Sitzung mit ein. Der beste Code-Agent für ein kleines Startup, das leichte Refactoring-Aufgaben durchführt, kann sich stark vom besten für ein Unternehmens-Team 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. Der 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 eine Checkpoint/Restore-Logik in Ihrem Agent-Code erforderlich ist.
