2026-05-29 Rückblick

Was ich heute gemacht habe

Ich habe versucht, das seit gestern anhaltende Problem zu verbessern, und heute ein MCP‑Tool gefunden, das die Websuche besser einbinden kann.

Das gefundene Tool war web-search-mcp, das die Browser‑Suche von bing, brave und duckduckgo als MCP bereitstellt.

• https://github.com/mrkrsl/web-search-mcp

Später möchte ich es forken und an meinen aktuellen Arbeitsablauf anpassen.

Eindruck von Qwen 3.6

Das Qwen 3.6‑Modell war langsamer in seiner Beurteilung als erwartet.

Es sollte den Workflow im .github‑Verzeichnis von qwen-code exakt synchronisieren, pushen und anwenden, aber tatsächlich versuchte es, nur einige Dateien ins .qwen‑Verzeichnis zu kopieren. Das war das Kernproblem.

Letztlich habe ich manuell ein Clone erstellt, das .github‑ und .qwen‑Verzeichnis exakt an das Original angepasst und dann weitergemacht. Es ging nur darum, „die Originalstruktur exakt zu übernehmen“, aber das Modell vermischte Pfad und Zweck, was zu unnötigem Rumprobieren führte.

Erkenntnisse zu Qwen selbst

Qwen ist weniger ein Modell ohne Fähigkeiten, sondern eher ein Modell mit Fähigkeiten, dem jedoch die Steuerbarkeit fehlt.

Informationssuche, Code‑Änderungen, Dateimanipulation und das Ausführen langer Aufgaben macht es ziemlich gut. Das Problem ist, dass es Schwierigkeiten hat, die Benutzerabsicht konsequent bis zum Ende beizubehalten. Besonders Bedingungen wie „einfach kopieren“, „nicht ändern“, „nicht inferieren“, „nur nach offiziellen Vorgaben arbeiten“, „diesen Pfad nicht berühren“ wurden während der Arbeit vergessen oder eigenmächtig überschrieben.

Kurz gesagt, Qwen kann die Arbeit nicht einfach nicht erledigen, sondern interpretiert den Arbeitsweg nach eigenem Ermessen neu.

Das ursprüngliche Problem dieser Aufgabe war einfach.

Offizielle .github unverändert kopieren
.qwen ausschließen
Push
Test

Aber Qwen hat das ständig zu einem anderen Problem ausgeweitet.

MCP‑Problem?
workflow_call‑Problem?
Soll ein Push‑Trigger hinzugefügt werden?
Soll .qwen/commands erstellt werden?
stderr‑JSON‑Problem?
Leeres‑Review‑Problem?

Bevor das Problem gelöst wird, wurde es bereits vergrößert. Bei agentenbasierten LLMs ist dieser Punkt fatal. Je größer die Arbeitseinheit, desto eher beginnt das Modell, nicht die ursprüngliche Anfrage, sondern ein von ihm selbst erzeugtes Unterproblem zu lösen.

Selbst wenn eine Websuche angehängt wird, wird das Problem nicht vollständig gelöst. Ein guter Ablauf besteht darin, zuerst die offizielle Dokumentation oder den Quellcode zu prüfen, die Struktur zu verstehen und dann im Vergleich zur Benutzeranfrage nur die notwendigen Schritte auszuführen. Qwen hingegen zeigte zunächst eine Schlussfolgerung, bildete eine Hypothese, suchte nach Bestätigung dieser Hypothese und passte die Suchergebnisse wieder an seine eigene Hypothese an.

Deshalb wurde die Websuche eher als ein Werkzeug zur Verstärkung von Hypothesen verwendet denn als ein evidenzbasiertes Arbeitswerkzeug. Ich habe festgestellt, dass die Haltung beim Umgang mit den Suchergebnissen wichtiger ist als die reine Suchfähigkeit.

Auch die Interpretation von Fehlersituationen war schwach. Zum Beispiel muss aus dem Ergebnis von git ls-files .qwen/, wenn es leer ist, sofort geschlossen werden, dass .qwen nicht im tracked‑Zustand ist. Stattdessen wurden wiederholt Befehle wie git rm -r --cached .qwen/ ausgeführt. Es gibt zwar die Fähigkeit, Befehle auszuführen, aber die Interpretation der Ergebnisse und das Anpassen des Verhaltens sowie das Verlassen von Schleifen waren instabil.

Außerdem ist Qwen bei Erhaltungsaufgaben wie „genau so wie in der Dokumentation“ schwach. Beim Erzeugen und Modifizieren ist es aktiv, aber beim Bewahren des Originals und der genauen Synchronisation versucht es ständig, Verbesserungen vorzunehmen. Es kann das Original zerstören, indem es Annahmen trifft wie: „Vielleicht sollte man .qwen anlegen, obwohl es nicht in der Dokumentation steht“, „Vielleicht muss ein Trigger hinzugefügt werden“, oder „Vielleicht muss man es so einstellen, dass es beim Push automatisch ausgeführt wird“.

Deshalb ist es sicherer, Qwen nicht einfach „genau wie in der Dokumentation kopieren“ zu überlassen, sondern es in kleinere Schritte zu zerlegen, wie folgt.

Offizielle Dateiliste ausgeben  
Meine Dateiliste ausgeben  
Unterschied (diff) ausgeben  
Nur vom Benutzer genehmigte Dateien kopieren

Qwen zu viel Autonomie zu geben, ist ebenfalls riskant. Rechte wie das Ändern von Dateien, git add, Commit, Push, das Anpassen von Workflows oder das erneute Ändern nach automatischen Tests können, einmal falsch beurteilt, bis zur Ausführung vorangetrieben werden.

Daher sollte Qwens Rolle eher der eines Kandidaten‑Generators, Log‑Zusammenfassers und Hilfsmittels zur Interpretation von Befehls‑Ergebnissen entsprechen, nicht die eines Aufgaben‑Managers oder End‑Ausführenden.

Qwen = Kandidatengenerator / Protokollzusammenfasser / Hilfsmittel zur Interpretation von Befehlsresultaten  
Benutzer oder Skript = Endausführer

Strukturierte Ausgabe muss ebenfalls vorsichtig gehandhabt werden. Es bedeutet nicht, dass Qwen JSON überhaupt nicht kann, aber wenn man ihm komplexe Schemas oder Workflow‑Zustandsverwaltung überträgt, sinkt die Gesamtsicherheit. Das Schreiben von Markdown‑Reviews, Code‑Erklärungen, Log‑Zusammenfassungen, das Auflisten von Ursachenkandidaten und das Erstellen von Entwurfs‑Lösungen ist in Ordnung. Im Gegensatz dazu sind präzise JSON‑Schema‑Ausgaben, komplexe Workflow‑Zustandsverwaltung, Verwaltung der Reihenfolge von Werkzeugaufrufen, GitHub‑API‑Arbeiten, das Bewahren von Dateipfaden sowie die Entscheidung über Commit/Push ungeeignet.

Zusammenfassend lässt sich sagen, dass Qwen als Generator in Ordnung ist, aber als Orchestrator instabil ist.

Der Kern ist diese eine Zeile.

Qwen ist ein intelligentes Generierungsmodell, aber es ist in Bezug auf Steuerbarkeit, Zustandsinterpretation und Anweisungsbeibehaltung zu schwach, um als zuverlässiger Aufgabenmanager oder Automatisierungsagent verwendet zu werden.

Die praktische Schlussfolgerung lautet wie folgt.

Man kann Qwen zum Denken bringen.  
Man kann Qwen den Entwurf anvertrauen.  
Man sollte Qwen nicht die endgültige Repo‑Manipulation anvertrauen.

Wenn Sie Qwen künftig weiter verwenden, ist es ratsam, die Betriebsprinzipien wie folgt festzulegen.

Eigenständige Arbeit verboten  
Ein Befehl nach dem anderen  
Diff vor der Änderung ausgeben  
Commit/Push verboten  
Die offizielle Originalerhaltungsarbeit muss von einer Person genehmigt werden  
LLM-Ausgaben dürfen nur als Markdown/Text verwendet werden

Websuche MCP – Eindrücke

Durch die Integration der Websuche hat sich die Suchleistung im Vergleich zur herkömmlichen Web‑Patch‑Methode deutlich verbessert. Die Geschwindigkeit, mit der benötigte Materialien gefunden werden, und der Suchumfang haben zugenommen, und das Sammeln von Kandidaten‑Links wurde erleichtert.

Allerdings neigte das System dazu, die aus der Websuche gewonnenen Informationen seltsam zu interpretieren. Es ist gut im Suchen, aber die Fähigkeit, die Suchergebnisse im Kontext von Code‑Arbeiten zu beurteilen, war noch instabil.

Deshalb kam mir der Gedanke, dass es sinnvoll sein könnte, das Coding‑LLM und das Such‑LLM zu trennen. Die Suche könnte einem Modell bzw. Werkzeug überlassen werden, das darin stark ist, während die Codierungs‑Bewertung separat verifiziert wird – das erscheint stabiler.

Reflexion

Ein Teil der heutigen Fehlversuche war eigentlich ein einfaches Problem, dessen Lösung ich bereits kannte.

Es ging nur darum, .github und .qwen exakt wie das Original anzupassen, aber ich ließ mich von den Zwischenschritten des Modells mitreißen und betrachtete das Problem komplexer. Beim nächsten Mal werde ich zuerst prüfen, ob das vom Modell gelieferte Ergebnis mit der geforderten Struktur übereinstimmt, und die Synchronisation von Pfaden/Dateien zu Beginn direkt per Diff verifizieren.

Insbesondere sollte man die Gewohnheit entwickeln, zuerst zu prüfen, ob „was kopiert wurde“ weniger wichtig ist als „ob Quelle und Ziel dieselbe Struktur besitzen“.

Arbeitsunterbrechungs‑Problem

Nach 14 Uhr heute Nachmittag fiel das Internet aus, sodass der auf RunPod laufende Qwen‑Server nicht mehr erreichbar war. Seitdem war es unmöglich, das Modell aufzurufen, und die Arbeit konnte nicht weitergeführt werden.

Lokale Arbeiten und Aufräumungen waren noch möglich, aber der automatisierte Review‑/Such‑/Verifizierungs‑Workflow, der den Qwen‑Server voraussetzt, ist stark von der Internetverbindung abhängig – das wurde erneut deutlich.

Nächste Schritte

• web-search-mcp forken und die benötigte Such‑Engine sowie das Ausgabeformat anpassen.
• Die Fehlinterpretationen bei der Analyse von Web‑Suchergebnissen durch Qwen reduzieren, indem die Zusammenfassung der Suchergebnisse und die Codierungs‑Bewertung getrennt werden.
• Bei Aufgaben, bei denen die Synchronisation von Verzeichnisstrukturen wie .github oder .qwen wichtig ist, zuerst anhand von diff prüfen.
• Qwen nicht sofort umfassende Repository‑Rechte geben, sondern Befehle und Diff‑Kontrollen einzeln ausführen lassen.
• Qwens Ausgabe zunächst als Markdown/Text‑Entwurf erhalten; JSON‑Schemas oder GitHub‑API‑Orchestrierung werden per Skript oder manuell erledigt.
• Für den Fall eines Ausfalls des RunPod Qwen‑Servers ein Fallback‑Modell oder lokale Prüfverfahren einrichten.