Harness Lens zeigt den Aufbau von Coding-Agenten

Was Harness Lens tatsächlich zeigt

Spannend ist hier nicht die nächste Modellschau, sondern der Versuch, eine Schicht zu ordnen, die normalerweise hinter der Oberfläche eines Coding-Agenten verborgen bleibt. Im README und Repository von Harness Lens auf Hugging Face wird das Projekt als interaktives Werkzeug zur Analyse von Harness-Systemen beschrieben: Codex, OpenCode, pi, Qwen Code und Claude Code.

Gleichzeitig lassen sich zwei bis vier Umgebungen vergleichen. Die Oberfläche stellt Systemprompts, Modi und Kompaktierungsanweisungen nebeneinander, zeigt Token-Zahlen, Überschneidungen bei Tools und Unterschiede bei den Fähigkeiten. Eine eigene Taxonomie umfasst Bearbeitungsformate, Kontextverwaltung, Subagenten, Berechtigungen, Projektanweisungen, Erweiterbarkeit und Provider-Integrationen.

Es handelt sich ausdrücklich nicht um einen Visualisierer für Gewichte, Attention-Karten oder Aktivierungen. Harness Lens zeigt die Architektur des Agentenprodukts um das Modell herum: Was darf es verwenden, wie verändert es Dateien, was erhält es im Systemkontext und wie verdichtet es den Verlauf? Diese Ebene erklärt oft besser als ein ansprechendes Diagramm eines neuronalen Netzes, warum sich zwei Agenten mit demselben Modell unterschiedlich verhalten.

Das Projekt verfolgt zudem einen disziplinierten Umgang mit Datenherkunft. Die verfügbaren Materialien beschreiben das Extrahieren von Prompts aus fixierten Revisionen, die Prüfung von Verweisen auf Quellzeilen sowie eine strenge Validierung von Schema und Taxonomie. Die Befehle extract, verify und validate betreffen die Datenintegrität, nicht die Qualität beim Lösen von Aufgaben.

Deshalb wäre es falsch, Harness Lens als automatisierte Benchmark-Suite zu verstehen. Mit Stand vom 7. November 2026 enthalten die verfügbaren Quellen keine standardisierten Ergebnisse zu Genauigkeit, Latenz, Kosten, SWE-bench oder zur Pass-Rate des Werkzeugs selbst. Es ist eine Ebene für vergleichbare Beobachtbarkeit und Dokumentation, keine Rangliste.

Warum man das Harness und nicht nur das Modell vergleichen sollte

Die praktische Schlussfolgerung ist einfach: Der Name eines Modells reicht zur Bewertung eines Coding-Agenten nicht mehr aus. Systemprompt, Werkzeugbestand, Aktionsrechte und Kompaktierungsstrategie können das Ergebnis verändern, bevor überhaupt die Frage nach der „besten“ Basisintelligenz gestellt wird.

Ich würde eine solche Karte als Beginn eines Audits nutzen, nicht als endgültiges Urteil. Zuerst wird sichtbar, wo sich Berechtigungen, Bearbeitungsprotokolle und der Umgang mit Projektanweisungen unterscheiden; anschließend lassen sich diese Unterschiede in eigene überprüfbare Szenarien überführen. Davon profitieren Entwickler, die die Ursache eines Verhaltens verstehen wollen, statt nur einen Gesamtwert zu erhalten.

Auch die Einschränkung ist klar: Gute Nachvollziehbarkeit der Quellen beweist nicht die Wirksamkeit eines Agenten. Ein fixierter Prompt lässt sich Zeichen für Zeichen prüfen, doch daraus folgt nicht, dass das Harness in einem realen Repository schneller, günstiger oder zuverlässiger ist. Die entscheidende offene Frage lautet daher präziser: Welche Unterschiede in der Harness-Architektur erzeugen tatsächlich messbare Effekte?

Pydantic Monty zeigt, wie sich von LLMs erzeugter Code ohne Container sicher ausführen lässt. Das ergänzt Harness Lens, wo neben Modellexperimenten auch die Kontrolle der Laufzeitumgebung wichtig ist.