Effektives Benchmarking von KI-Agenten im Softwareentwicklungsprozess

Die rapide Entwicklung von KI-Agenten und großen Sprachmodellen (LLMs) revolutioniert die Art und Weise, wie Software entwickelt und genutzt wird. Coding-Agenten übernehmen zunehmend komplexe Aufgaben, von der Bibliotheksauswahl über die Code-Generierung bis hin zur Fehlerbehebung. Dies führt zu einer neuen Anforderung an die Softwareentwicklung: Code muss nicht nur korrekt und schnell sein, sondern auch so gestaltet sein, dass ein Agent ihn effektiv nutzen kann. Eine unübersichtliche API oder veraltete Dokumentation kann einen Agenten auf einen längeren und kostspieligeren Pfad führen. Traditionelle Benchmarks, die lediglich das Endergebnis bewerten, sind in diesem Kontext oft unzureichend, da sie den Prozess und den Aufwand, der zum Ergebnis führt, ignorieren.

Die Herausforderung des Agenten-Benchmarking

Die reine Überprüfung, ob ein Agent die richtige Antwort liefert, greift zu kurz. Es ist ebenso wichtig zu verstehen, wie der Agent zu dieser Antwort gelangt ist. Hat er dafür eine 40-zeilige Python-Routine geschrieben und Fehler behoben, oder hat er einen einzigen Kommandozeilenbefehl ausgeführt? Beide Wege können zum gleichen korrekten Ergebnis führen, unterscheiden sich jedoch erheblich in Bezug auf Kosten, Latenz, Token-Nutzung und Fehlerraten. Diese Aspekte sind entscheidend für die Optimierung von Software für den Einsatz durch Agenten. Wenn eine Änderung an einer Bibliothek – sei es eine CLI-Verbesserung, bessere Fehlermeldungen oder ein neuer "Skill" – tatsächlich Agenten hilft, sollte dies messbar sein.

Agent-eval: Ein neues Benchmarking-Tool

Um dieser Herausforderung zu begegnen, wurde ein spezifisches Benchmarking-Tool namens "agent-eval" entwickelt. Dieses Tool konzentriert sich darauf, wie die Antwort gefunden wurde, und bietet eine Implementierung, die vollständig auf offenen Modellen läuft, angetrieben durch den pi Coding-Agenten. Die Ausführung erfolgt über Hugging Face Jobs, um identische Hardwarebedingungen für jede Modell-Revisions-Aufgaben-Kombination zu gewährleisten. Dies ermöglicht eine faire und skalierbare Vergleichbarkeit.

Software für Agenten optimieren: Testen und Dokumentieren

Die Prinzipien "Wenn es nicht getestet ist, funktioniert es nicht" und "Wenn es nicht dokumentiert ist, existiert es nicht" bleiben auch im Bereich der agentenoptimierten Tool-Entwicklung gültig. Für Agenten bedeutet dies, dass ein Tool auffindbar sein muss: Die API muss klar sein, und die Dokumentation muss umfassend und so strukturiert sein, dass der Agent schnell auf nützliche Dateien und Beispiele zugreifen kann. Um ein Tool für den agentischen Gebrauch zu validieren, sollte es explizit auf agentische Nutzungsszenarien getestet werden.

Evaluierung von Agenten: Der Prozess

Die Evaluierung von Agenten erfolgt in "agent-eval" über drei Varianten oder "Tiers", die unterschiedliche Arten der Interaktion eines Agenten mit einer Bibliothek wie transformers simulieren:

• bare: Der Agent hat nur die Bibliothek installiert (z.B. pip install transformers).
• clone: Der Agent hat den vollständigen Quellcode der Bibliothek im Arbeitsverzeichnis.
• skill: Der Agent erhält eine verpackte "Skill"-Definition, die die Dokumentation der CLI und aufgabenspezifische Beispiele im Kontext lädt.

Diese Tiers sind nicht hierarchisch; jeder bietet dem Agenten eine andere Art von Unterstützung. Die Aufgaben sind deterministisch und erfordern eine exakte Übereinstimmung, was eine präzise Experimentiergrundlage bietet. Jede Ausführung wird als separater Hugging Face Job gestartet, um Parallelität und identische Hardwarebedingungen zu gewährleisten. Die Ergebnisse und Traces werden in einem Hugging Face Bucket gespeichert, um schnelle Zugriffe und hohe Schreibkonkurrenz zu ermöglichen.

Messgrößen für die Agentenleistung

Das Tool bewertet jede Ausführung anhand mehrerer Achsen, um die Leistung von Agenten und Modellen detailliert zu analysieren:

• Match %: Gibt an, ob die endgültige Antwort das erwartete Ergebnis enthielt.
• Medianzeit und Mediane Token: Misst den Zeitaufwand und die Anzahl der genutzten Tokens (neu, zwischengespeichert, generiert).
• Fehlerrate: Der Prozentsatz der Läufe, die zu einem Fehler führten oder kein Ergebnis lieferten.
• Marker-Adoption: Verfolgt die Nutzung spezifischer, vom Tool definierter Verhaltensmarker.

Alle Ergebnisse werden in einem interaktiven HTML-Bericht dargestellt, der eine detaillierte Analyse ermöglicht. Zusätzlich werden die nativen Agenten-Traces jedes Laufs erfasst, die über den Hubs Agent-Traces Viewer eingesehen werden können, um den genauen Verlauf der Agentenaktionen nachzuvollziehen.

Modellspezifische Benchmarking-Strategien

Die Art und Weise, wie Benchmarks durchgeführt werden, hängt stark von den Eigenschaften der zugrunde liegenden Modelle ab.

Große offene Modelle: Variation der Revision

Bei großen, leistungsfähigen offenen Modellen, die in der Regel die richtige Antwort finden, steht nicht die Korrektheit im Vordergrund, sondern der Aufwand, der dafür betrieben wird. Hat der Agent zehn Schritte oder nur einen benötigt? Hat er eine veraltete API verwendet, weil die Dokumentation nicht aktuell war? Ist er auf einen unerwarteten Fehler gestoßen? Hierbei wird ein starkes Modell fixiert und die Revisionen des Tools variiert, um zu beobachten, wie sich der Aufwand für den Agenten verändert. Die Experimente mit transformers zeigten, dass die Einführung einer dedizierten CLI und eines Skills die Arbeitszeit der Agenten reduzierte, obwohl dies bei der clone-Variante zu einem Anstieg der Token-Nutzung führte, da die Agenten den neuen Code zur CLI-Implementierung und die Beispiele im Repository lesen mussten.

Kleine Modelle: Variation des Modells

Bei kleineren Modellen ist die Fähigkeit zur Tool-Nutzung und zur Aufgabenbewältigung kritischer. Hier wird die Revision konstant gehalten und das Modell variiert, um zu sehen, welche Modelle die Aufgaben tatsächlich bewältigen können und welche nicht. Die Intuition besagt, dass kleinere Modelle mehr Schwierigkeiten mit der Tool-Nutzung und den Aufgaben haben. Die Ergebnisse zeigten, dass eine agentenoptimierte Schnittstelle, wie eine CLI und ein Skill, die Leistung größerer Modelle verbessern kann, aber kleinere Modelle möglicherweise überfordert oder sogar verwirrt. Einige kleine Modelle könnten sich auf memorierte API-Muster verlassen, die sie in ihren Trainingsdaten gesehen haben, und neue Konzepte könnten für sie eine größere Fehlerquelle darstellen.

Ein Beispiel hierfür ist das Qwen3-14B-Modell, dessen Trefferquote bei der skill-Variante drastisch sank. Die Analyse der Traces zeigte, dass das Modell die CLI fälschlicherweise als direkt aufrufbaren Tool missverstand, anstatt als Dokumentation, die im Kontext geladen wird. Dies führte dazu, dass es entweder einen nicht registrierten Tool-Aufruf auslöste oder die Aufgabe als unlösbar einstufte und aufgab. Dies verdeutlicht, dass agentenorientierte APIs über verschiedene Modellgrößen hinweg evaluiert werden müssen, da eine neue Funktion für starke Modelle vorteilhaft sein kann, aber für kleinere Modelle zu Mehrdeutigkeiten führen kann.

Marker und Ergebnisse: Tiefere Einblicke

Neben den grundlegenden Metriken wie Match %, Token und Zeit bietet das Konzept der "Marker" tiefere Einblicke in das Verhalten eines Agenten. Ein Marker ist ein benanntes Muster, das das Profil des Tools (ein Plugin, das dem Harness beibringt, wie eine Bibliothek zu bauen und zu betreiben ist) mit einer Ausführung abgleicht. Dies kann das Ausführen von Shell-Befehlen, das Schreiben von Code, das Lesen von Dateien oder die endgültige Antwort betreffen. Für transformers wurden Marker wie cli (Agent ruft das Kommandozeilen-Tool auf) und pipeline (Agent verwendet die High-Level-Python-API) definiert. Diese Marker helfen, zu verfolgen, ob eine Änderung das Verhalten des Agenten beeinflusst hat.

Die Analysen zeigten beispielsweise, dass größere Modelle die neu eingeführte CLI stärker nutzten, während kleinere Modelle eher auf ihre "Erinnerungen" zurückgriffen. Dies unterstreicht die Bedeutung einer genauen Evaluation über verschiedene Modellgrößen hinweg.

Fazit für die B2B-Zielgruppe

Für Unternehmen, die KI-Agenten in ihren Workflows einsetzen oder Software für diese entwickeln, ist ein detailliertes Benchmarking unerlässlich. Es geht nicht nur darum, ob ein Agent eine Aufgabe lösen kann, sondern auch darum, wie effizient und zuverlässig er dies tut. Die Implementierung von agentenoptimierten Schnittstellen kann die Leistung erheblich beeinflussen, birgt jedoch das Risiko, dass nicht alle Modelle gleichermaßen davon profitieren. Ein robustes Benchmarking-Framework, das den gesamten Prozess der Problemlösung abbildet und Modelle über verschiedene Größen und Konfigurationen hinweg bewertet, ist daher entscheidend für die Entwicklung und Optimierung von KI-gestützten Systemen. Es ermöglicht eine fundierte Entscheidungsfindung bei der Auswahl von Modellen, der Gestaltung von APIs und der kontinuierlichen Verbesserung von Tools für die agentische Nutzung.

Bibliografie

• Hugging Face Blog: "Is it agentic enough? Benchmarking open models on your own tooling" (Published: June 18, 2026)
• GitHub Repository: HuggingFace/is-it-agentic-enough (Created: April 22, 2026)
• Agentosaurus Blog: "Can Open-Source Models Actually Use Tools? We Tested 22 Models on 44 Tasks" (Published: April 10, 2026)
• Towards AI: "I Built My Own Agent Benchmark. My Coding Kit's Result Surprised Me." by Caspar Bannink (Published: June 8, 2026)
• GitHub Repository: SeraphimSerapis/tool-eval-bench (Created: April 17, 2026)
• TheCoding.Club: "Reproducible LLM Benchmarking for Dev Workflows" (Published: May 4, 2026)
• arXiv: "Establishing Best Practices for Building Rigorous Agentic Benchmarks" (URL: arxiv.org/html/2507.02825v3)
• Agent Engineering: "MASEval: Why Your Agent Benchmark Is Missing Half the Picture" by Daniel Huber (Published: June 17, 2026)
• The End of Coding: "How to Build Your Own AI Benchmark (And Why It's Critical)" by Nicolas Bouvrette (Published: May 18, 2026)
• GitHub Repository: OmnionixAI/AgentBench (Created: March 29, 2026)