Zum Inhalt
GlobalNet
Strategies

KI & Automatisierung · LOG / 705

Agent-Harness: Warum Experten-Imitation scheitern kann

Eine Salesforce-Studie zeigt: Vollständige Experten-Imitation verschlechterte kleinere Agentenmodelle in sieben Enterprise-Aufgaben. Entscheidend ist die Passung zwischen Modell und Harness.

Ein stärkeres Modell als Lehrer einzusetzen klingt logisch: Man zeichnet erfolgreiche Agentenläufe auf und trainiert ein kleineres, günstigeres Modell auf diesen Trajektorien. Eine Salesforce-Studie zeigt jedoch ein wichtiges Gegenbeispiel. Bei sieben untersuchten Enterprise-Agentenaufgaben verschlechterte die vollständige Imitation der Expertenläufe kleinere Modelle um 4 bis 30 Punkte. Entscheidend war nicht nur das Modell, sondern die Passung zwischen Modell und Agent-Harness – also Systemprompt, Werkzeugen und Ausführungslogik.

Was die Studie bestätigt

Die Forscher entwickelten Harnesses für schwächere Modelle und beobachteten, dass stärkere Modelle diese häufig besser nutzen konnten. Die naheliegende Experten-Imitation bewirkte unter den weiterentwickelten Harnesses aber das Gegenteil: Die Leistung ging bei allen sieben Aufgaben zurück. Untersucht wurden laut Quelle Qwen3-Coder und Gemma 4; die gemeldete Regression lag je nach Aufgabe zwischen 4 und 30 Punkten.

Als Erklärung nennt die Arbeit einen Bruch der Modell-Harness-Kompatibilität. Das kleinere Modell übernimmt die Planungsstrategie des Experten, kann sie aber nicht zuverlässig ausführen. Zugleich passt die neue Strategie nicht mehr zum Harness, der rund um den ursprünglichen Planungsstil entstanden war. Als Gegenansatz lokalisiert ein Meta-Agent fehlerhafte Schritte in den eigenen Rollouts des schwächeren Modells; Experten schreiben nur diese Schritte um. Dadurch soll der modelltypische Planungsstil erhalten bleiben.

Nicht belegt ist damit, dass lokale On-Policy-Korrektur jedes Modell oder jede Unternehmensaufgabe verbessert. Die Quelle beschreibt sieben Aufgaben und konkrete Modellfamilien. Übertragbarkeit, absolute Kosten und Auswirkungen auf andere Stacks müssen Unternehmen selbst testen. Die Ergebnisse sind ein Warnsignal gegen pauschale Imitation, kein allgemeines Leistungsversprechen.

Drei Anpassungswege im Vergleich

  • Nur den Harness verbessern: passend, wenn das Basismodell die Aufgabe grundsätzlich beherrscht und vor allem Werkzeuge, Kontext oder Regeln begrenzen. Das verändert keine Modellgewichte, kann den Harness aber stark modellspezifisch machen.
  • Vollständige Experten-Imitation: denkbar, wenn Schüler- und Expertenmodell ähnliche Strategien beherrschen. Das Risiko besteht darin, nicht ausführbare Pläne zu kopieren und die bestehende Harness-Passung zu verlieren.
  • Lokale On-Policy-Korrektur: sinnvoll, wenn eigene Rollouts überwiegend funktionieren, aber wiederkehrende Fehlerschritte enthalten. Der native Ablauf bleibt erhalten; Fehlerlokalisierung und Expertenkorrektur erzeugen jedoch Aufwand.

Für Unternehmen folgt daraus eine klare Reihenfolge: zuerst Prompt, Tool-Beschreibungen, Kontextgrenzen und Ausführungsregeln prüfen. Erst wenn der Harness nicht genügt, sollte eine Gewichtsänderung folgen. Dann ist die gezielte Korrektur eigener Modellläufe die vorsichtigere Hypothese als das Kopieren vollständiger Expertentrajektorien.

Ein kontrollierter Pilot in vier Phasen

  1. Baseline einfrieren: Modell, Systemprompt, Tool-Schemas, Kontextlogik, Abbruchregeln und Evaluationsset gemeinsam versionieren. Fachliche Qualität, Kosten, Laufzeit und menschliche Eingriffe erfassen.
  2. Eigene Rollouts auswerten: Reviewer markieren den ersten relevanten Fehlerschritt – etwa falsche Planung, ungeeignetes Werkzeug, fehlerhafte Parameter oder verlorenen Kontext.
  3. Varianten vergleichen: unveränderte Baseline, vollständige Experten-Imitation und lokale Korrektur auf demselben Kontrollset testen. Auch Toolaufrufe, Kosten und riskante Zwischenschritte bewerten.
  4. Begrenzt öffnen: Der Agent erstellt nur reversible Entwürfe, arbeitet mit minimalen Rechten und bleibt an menschliche Freigaben gebunden. Jede Änderung an Modell oder Harness startet die Prüfung neu.

Das Kontrollset muss während des Vergleichs unverändert bleiben. Sonst lässt sich nicht unterscheiden, ob das System tatsächlich besser wird oder lediglich leichtere Aufgaben erhält. Ein zusätzlicher Holdout mit unbekannten Varianten zeigt, ob eine Methode robust arbeitet oder nur Trainingsmuster nachahmt.

Für die Fehleranalyse sollte das Team außerdem eine einheitliche Taxonomie verwenden. Sinnvolle Kategorien sind Planung, Werkzeugwahl, Parameter, Kontext, Verifikation und Abbruchverhalten. Damit lässt sich erkennen, ob eine Korrektur wirklich dieselbe Fehlerklasse reduziert oder lediglich Fehler an eine andere Stelle verschiebt. Besonders wichtig ist der erste kausale Fehlerschritt: Spätere Symptome zu korrigieren kann einen Lauf oberflächlich verbessern, ohne die eigentliche Ursache zu beseitigen.

Freigabe-Gates für den Betrieb

  • Qualität: höhere Erfolgsquote ohne Verschlechterung kritischer Teilaufgaben.
  • Kompatibilität: keine Zunahme von Werkzeugfehlern, Schleifen oder abgebrochenen Plänen.
  • Kosten: Training, Expertenkorrektur und Reviews bleiben unter dem erwarteten Prozessnutzen.
  • Sicherheit: keine zusätzlichen Datenzugriffe oder autonomen Produktionsrechte.
  • Reproduzierbarkeit: Modell, Harness, Daten und Evaluation sind gemeinsam versioniert.
  • Rollback: Regressionen führen zur vorherigen freigegebenen Kombination zurück.

Gerade das Kosten-Gate verhindert einen Denkfehler: Ein kleineres Modell ist nicht automatisch günstiger, wenn seine Optimierung viele Expertenstunden und zusätzliche Trainingsläufe benötigt. Entscheidend sind die Gesamtkosten pro akzeptiertem, korrekt ausgeführtem Prozess – nicht nur der Preis eines Modellaufrufs.

Im laufenden Betrieb braucht jede freigegebene Kombination eine eigene Versionskennung. So kann das Team Leistungsänderungen eindeutig einem Modell-, Prompt-, Werkzeug- oder Kontext-Update zuordnen. Werden mehrere Komponenten gleichzeitig geändert, geht diese Diagnosefähigkeit verloren. Deshalb sollten Rollouts schrittweise erfolgen, mit einem stabilen Vergleichspfad und einer sofort nutzbaren Rückfallversion.

Fazit: Modell und Harness gemeinsam betreiben

Die Salesforce-Ergebnisse stellen eine verbreitete Abkürzung infrage: Vollständige Expertenläufe sind nicht automatisch gute Trainingsdaten für kleinere Agentenmodelle. Wenn ein Schüler fremde Strategien übernimmt, die er nicht stabil ausführen kann, kann mehr Supervision die Leistung verschlechtern. Ein belastbarer Unternehmenspilot beginnt daher mit eigenen Rollouts, lokalisiert Fehler, vergleicht Anpassungswege auf einem festen Kontrollset und erweitert Rechte erst nach bestandenen Gates. So wird aus dem Forschungsansatz ein prüfbarer Betriebsprozess statt eines neuen Fine-Tuning-Versprechens.

Verwendete Quelle

  1. Co-Evolving Harnesses and Models: On-Policy Correction Helps Weaker Models Catch Up Where Imitation Fails