Tool-Use-Review
Aktualisiert am · Instruction-Tuned · Agentic Orchestrator
Deployment-Urteil
Bedingt deploy, weil die Tool-Ausführung stark ist, aber die Tool-Call-Validität nicht durchgehend sauber war und die Verdichtung der Tool-Ergebnisse für produktionskritische Antworten zu uneinheitlich bleibt.
Tool-Execution-Profil
GLM-5.2 zeigt echte Werkzeugintelligenz. Beim Web-Search-&-Tool-Selection-Test, der ohne expliziten Hinweis prüft, ob statt fetch erst web_search nötig ist, wählt es das richtige Werkzeug sicher. Das spricht gegen ein starres Muster und für brauchbare Planungslogik in MCP-gestützten Abläufen. Auch der Honeypot zur EU License Research wurde korrekt als aktuelle Web-Recherche behandelt, nicht als Wissensfrage aus dem Training.
Schwächer ist die Präzision im letzten Meter. Beim URL-Construction-Test, der prüft, ob das Modell eine Ziel-URL aus eigenem Wissen sauber ableitet und dann fetch korrekt ausführt, reicht es nur für eine brauchbare, nicht deterministische Ausführung. Dazu passt das Signal „Tool-Call valide: false“: Das Modell versteht den Workflow, produziert aber nicht in jeder Phase verlässlich protokollsaubere Aufrufe. Für produktive Tool-Pipelines heißt das: gute Orchestrierung, aber Absicherung durch Schema-Validation und Guardrails ist Pflicht.
Synthesetreue
Wie gut verdichtet es? Nur ordentlich. Die P2-Leistung zeigt, dass GLM-5.2 Tool-Ergebnisse oft korrekt zusammenzieht, aber wichtige Details nicht stabil genug priorisiert. Das sieht man besonders bei Multilingual Search & Synthesis, wo die Recherche über Sprachgrenzen gelingt, die deutsche Ergebnisverdichtung aber deutlich abfällt. Für Recherche-Agents ist das tragbar. Für Compliance-, Policy- oder Extraktionspipelines mit enger Faktentoleranz ist es zu unruhig.
Bleibt es im Tool-Ergebnis oder weicht es auf Training aus? Hier ist das Vertrauenssignal besser. Im Honeypot EU License Research, der prüft, ob aktuelle Lizenzrestriktionen aus Web-Quellen statt aus dem Training beantwortet werden, wurde keine Halluzination erkannt. Das Modell bleibt also grundsätzlich an den beschafften Quellen orientiert, auch wenn die Zusammenfassung nicht immer scharf genug ist.
Fehlerresilienz
Akzeptabel für Produktion. Im 404-Test, der transparentes Verhalten bei einem fehlschlagenden Tool-Call misst, hat GLM-5.2 keinen Seiteninhalt erfunden. Es kommuniziert Fehler offen statt Ersatzfakten zu erzeugen. Genau dieses Verhalten hält eine Tool-Infrastruktur vertrauenswürdig.
Betriebsprofil
Langsam. 251.13s pro Run gesamt, mit einem zweiten Modellaufruf von 35.81s. Lokal betrieben, daher keine API-Kosten im Run. Für die gezeigte Leistung ist das nur für asynchrone oder batch-orientierte Pipelines vertretbar.
Fazit & Empfehlung
GLM-5.2 passt in agentische Recherche- und Orchestrierungs-Pipelines, wenn Tool-Wahl wichtiger ist als perfekte Endverdichtung und wenn nachgelagerte Validatoren Antworten prüfen. Für mehrstufige Web-Recherche, Discovery, Quellenfindung und robuste Fehlerbehandlung ist es brauchbar. Für deterministische Extraktion, compliance-nahe Synthesen und Pipelines, in denen jeder Tool-Call protokollsauber und jede Zusammenfassung präzise sein muss, würde ich es nur mit strenger Ausgabekontrolle einsetzen.
Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.
