Modell
Qwen 3.8 27B · NVFP4
Lokales Modell, kein Cloud-Endpoint. Alle vier Agenten sprechen es über dieselbe OpenAI-kompatible Schnittstelle an.
harness-bench
Ein Coding-Agent ist nur so gut wie das Paar aus Modell und Umgebung. Deshalb habe ich vier gängige Agenten an dasselbe, auf meinem eigenen Rechner laufende Modell angeschlossen und sie identische Terminal-Aufgaben lösen lassen. Das Ergebnis ist kein Leaderboard — es ist ein Blick darauf, was der Agent selbst aus dem Modell herausholt.
Gleiche Bedingungen für alle vier: dasselbe Modell, dieselbe Engine, dieselben Aufgaben. Was über bleibt, ist der Agent selbst.
Modell
Lokales Modell, kein Cloud-Endpoint. Alle vier Agenten sprechen es über dieselbe OpenAI-kompatible Schnittstelle an.
Engine
Eigenbau-Inferenz-Engine (C++/CUDA) auf einer RTX 5090.
Bewusst auf `max-concurrency 1` gefahren: Alle LLM-Requests laufen nacheinander durch eine einzige Decode-Lane. Das hält die Messung sauber — kein paralleles Gedränge, keine anderen Prozesse, die die Zahlen drücken.
Rahmen
Jeder Agent läuft pro Aufgabe in einer frischen, isolierten Docker-Umgebung. Versteckte Prüfungsskripte entscheiden über bestanden/nicht bestanden — der Agent sieht sie nie.
Umfang
Zehn Aufgaben aus Terminal-Bench 2.0, ein Versuch pro (Agent, Aufgabe)-Paar. Das ist ein Indikator, kein Paper-Claim: Eine einzige schwache Stichprobe kann eine Zelle dominieren.
Unterschiedliche Herkunft, unterschiedliche Philosophien — angeschlossen an denselben Endpunkt.
Standard-Adapter von Harbor
Leaner Coding-Agent (badlogic)
Eigene Provider-Konfiguration, die den lokalen Endpunkt als OpenAI-kompatible Route einrichtet.
Standard-Adapter von Harbor
Open-Source-Terminal-Agent (anomalyco)
Registriert das Modell im eigenen Config-Format, läuft mit deaktivierten Berechtigungsabfragen.
Standard-Adapter von Harbor
Agent-Framework (Nous Research)
Stock-Installation direkt aus dem Projekt, nativer OpenAI-Pfad gegen den lokalen Endpunkt.
Eigener Adapter für dieses Projekt
Agent-Harness von DeepSeek (dsh)
Headless-Modus mit Custom-Provider. Developer-Preview (0.1.0-rc) — Verhalten kann zwischen Läufen variieren.
Zehn Terminal-Aufgaben aus Terminal-Bench 2.0 — von Log-Auswertung bis Git-Reparatur bis Datenbank.
Bestanden pro Agent und — wo gemessen — die durchschnittliche Zeit pro Aufgabe.
| Agent | Bestanden | Ø Zeit / Aufgabe |
|---|---|---|
| Pi | 40 % | 7 min 21 s |
| OpenCode | 50 % | 4 min 41 s |
| Hermes | 60 % | 13 min 4 s |
| DeepSeek Harness | 60 % | 12 min 4 s |
Weil das Modell für alle vier festgelegt ist, ist jede Abweichung im Ergebnis dem Agenten zuzuschreiben: System-Prompts, Tool-Definitionen, wie der Loop abläuft, wie mit Berechtigungen umgegangen wird. Genau diese Schicht macht den Unterschied — nicht das Modell.
Eine bestellte Aufgabe heißt nicht, dass der Agent sie „versteht". Er kann sie durch Probieren, durch Suchen im Arbeitsverzeichnis oder durch eine glückliche Formulierung lösen. Die versteckte Prüfung misst den Endzustand, nicht den Weg. Für eine belastbare Aussage über einen einzelnen Agenten bräuchte man mehrere Versuche pro Aufgabe — das ist hier aus Zeitgründen weggelassen.
Ein Cloud-Modell würde die Frage verwässern: Man misst dann auch die Latenz, den Provider und dessen Feintuning. Mit einem festen, lokal laufenden Modell fällt das weg. Und mit der bewusst eingeschränkten Parallelität (eine Decode-Lane) bleibt die Messung reproduzierbar — was bei vier verschiedenen Agenten und langsamer lokaler Decode ohnehin der Fall sein muss.