LongWoF-Bench: Verifizierte Agenten-Erfahrung kontrolliert wiederverwenden

Lange Agenten-Workflows scheitern nicht nur an fehlendem Wissen. Häufig geht auch verloren, welche Schritte unter realen Bedingungen tatsächlich funktioniert haben. LongWoF-Bench untersucht deshalb, ob sich bestätigte Ausführungserfahrung als strukturierte „Genes“ wiederverwenden lässt. Laut Studie umfasst der Benchmark 778 maschinenprüfbare Aufgaben aus Codegenerierung, Agenten-Umgebungssynthese, Mathematik und Regelbefolgung. Für Unternehmen ist der relevante Punkt nicht das neue Etikett, sondern die Herkunft des wiederverwendeten Wissens: Wurde lediglich eine Anleitung verdichtet, oder stammt sie aus einem Lauf, dessen Ergebnis ein Verifier akzeptiert hat?

Was LongWoF-Bench tatsächlich untersucht

Bestätigt ist das Vergleichsdesign der Primärarbeit. EvoMap verdichtet durch Verifier bestätigte Ausführungstrajektorien zu strukturierten Genes. Die Autoren vergleichen diese mit klassischen Skills und mit Genes, die nur aus Referenzmaterial verdichtet wurden. Auf 252 Aufgaben mit bestätigten Opus-Trajektorien lagen die entwickelten Genes laut Studie bei allen sieben getesteten Modellen 8,7 bis 15,5 Prozentpunkte vor Skills. Für Claude Opus berichten die Autoren außerdem 39 zusätzliche gelöste Aufgaben und 9,9 Prozent weniger Tokenverbrauch zur Lösungszeit.

Diese Werte sind Autorenangaben aus einem neuen Benchmark, keine unabhängige Replikation und kein Business Case. Sie belegen insbesondere nicht, dass beliebige Unternehmensprozesse um denselben Betrag besser oder günstiger werden. Aussagekräftiger ist der interne Vergleich: Referenzverdichtete Genes erreichten nicht denselben Vorteil. Daraus leiten die Autoren ab, dass nicht allein eine kompakte Darstellung zählt, sondern die Provenienz aus verifizierter Ausführung. Für Beschaffung und Betrieb ist das eine prüfbare Hypothese, die im eigenen Prozess getestet werden sollte.

Skill, Referenz-Gene oder verifizierte Erfahrung?

• Ein Skill beschreibt Vorgehen, Regeln oder Werkzeugnutzung. Er kann fachlich gut sein, ohne jemals einen vollständigen Lauf bestanden zu haben.
• Ein referenzverdichtetes Gene fasst vorhandene Dokumente oder Lösungen kompakt zusammen. Es trägt jedoch keinen Nachweis, dass genau diese Strategie unter den Zielbedingungen erfolgreich war.
• Ein aus verifizierter Trajektorie erzeugtes Gene verbindet Handlungswissen mit einer bestätigten Ausführung. Sein Nutzen bleibt trotzdem auf Aufgabe, Umgebung, Werkzeuge und Verifier des Ursprungs begrenzt.
• Für Unternehmen ist daher die Herkunft wichtiger als der Name des Artefakts. Ohne Provenienz, Version und Gültigkeitsbereich entsteht lediglich ein schwer prüfbarer Prompt-Baustein.

Die praktische Konsequenz: Ein Erfahrungsartefakt sollte niemals global für alle Agenten freigegeben werden, nur weil es einmal erfolgreich war. Der ursprüngliche Verifier kann unvollständig gewesen sein, Abhängigkeiten können sich ändern und ein erfolgreicher Pfad kann Sicherheits- oder Compliance-Regeln umgehen. Wiederverwendung braucht deshalb denselben Änderungsprozess wie Code, Automationslogik oder Runbooks.

Sechs Schritte für ein internes Erfahrungsregister

1. Erfassen: Nur vollständig protokollierte Läufe übernehmen; Aufgabe, Eingaben, Werkzeuge, Modell, Umgebung und Ergebnis gemeinsam speichern.
2. Verifizieren: Fachliche Akzeptanzkriterien, automatisierte Prüfungen und menschliches Review festlegen. Die Selbsteinschätzung des Agenten zählt nicht als Nachweis.
3. Begrenzen: Gültige Repositories, Prozessvarianten, Datenklassen und erlaubte Werkzeuge am Artefakt vermerken.
4. Bereinigen: Secrets, personenbezogene Daten, Kundeninhalte und unnötige Zwischendaten vor jeder Wiederverwendung entfernen.
5. Versionieren: Änderungen, verantwortliche Freigabe, Ablaufdatum und Rückrufmöglichkeit dokumentieren. Veraltete Genes dürfen nicht still weiterlaufen.
6. Messen: Erfolgsquote, Nacharbeit, Token- und Laufzeitkosten sowie neue Fehlermuster gegen einen Lauf mit bestehendem Skill vergleichen.

Dieser Pfad verwandelt Agenten-Erfahrung in ein kontrolliertes Betriebsobjekt. Er verhindert zugleich, dass ein einzelner guter Lauf zur vermeintlichen Wahrheit wird. Für einen ersten Pilot eignen sich wiederkehrende, mehrstufige Aufgaben mit reproduzierbarer Umgebung und striktem End-to-End-Verifier. Produktive Freigaben, Zahlungen, Löschungen oder breit privilegierte Infrastrukturänderungen sind ungeeignet, solange Rücknahme und Verantwortlichkeit nicht belastbar getestet sind.

Kosten und Risiken gemeinsam messen

Wiederverwendung kann Suchschritte sparen, verursacht aber neue Pflegekosten. Erfahrung muss klassifiziert, geprüft, aktualisiert und gegebenenfalls zurückgerufen werden. Ein scheinbar günstiger Lauf ist wertlos, wenn das Artefakt später falsche Annahmen verbreitet oder auf eine andere Umgebung übertragen wird. Deshalb sollte die Wirtschaftlichkeitsrechnung nicht beim Tokenverbrauch enden. Relevant sind Kosten je akzeptiertem Ergebnis, Zeit bis zur Freigabe, menschlicher Prüfaufwand, Wiederholungen, Rücknahmen und Fehler nach der Übergabe.

Auch Sicherheit gehört in dieselbe Rechnung. Gespeicherte Trajektorien können sensible Pfade, Daten oder Fehlversuche enthalten. Ein Gene kann unpassende Werkzeugaufrufe konservieren. Unternehmen brauchen deshalb minimale Rechte, isolierte Testumgebungen, Inhaltsfilter, nachvollziehbare Logs und einen zentralen Sperrmechanismus. Je breiter ein Erfahrungsartefakt verteilt wird, desto wichtiger sind Signatur, Versionsbindung und ein nachweisbarer Rückruf.

Entscheidungsrahmen für den Pilot

• Starten, wenn die Aufgabe häufig wiederkehrt, maschinenprüfbar ist und bisher viel erneute Suche oder Fehleranalyse verursacht.
• Begrenzen, wenn sich Umgebung, Daten oder Regeln schnell ändern; dann braucht jedes Artefakt eine kurze Gültigkeit und erneute Prüfung.
• Stoppen, wenn die Herkunft nicht vollständig dokumentiert ist, sensible Inhalte nicht sicher entfernt werden können oder kein unabhängiger Verifier existiert.
• Skalieren erst dann, wenn verifizierte Erfahrung gegenüber dem bestehenden Skill über mehrere Läufe stabil bessere akzeptierte Ergebnisse liefert.

Der Pilot sollte mindestens drei Varianten unter identischen Bedingungen vergleichen: ohne Zusatzwissen, mit bestehendem Skill und mit freigegebener verifizierter Erfahrung. Modelle, Budgets, Werkzeuge und Verifier bleiben dabei konstant. So lässt sich erkennen, ob die Verbesserung wirklich aus der Erfahrung stammt oder aus mehr Kontext, zusätzlichen Tokens oder einer günstigeren Aufgabenverteilung.

Fazit: Provenienz vor Reichweite

LongWoF-Bench liefert einen nützlichen Impuls für den Betrieb langer Agenten-Workflows: Erfolgreiche Ausführung kann wertvoller sein als eine abstrakte Anleitung. Der Benchmark beweist aber keine allgemeine Produktivitätssteigerung. Für DACH-Unternehmen ist der richtige nächste Schritt ein begrenztes Erfahrungsregister mit strenger Provenienz, eigener Verifikation und Rückrufbarkeit. Erst wenn Nutzen, Kosten und Risiken über wiederholte Läufe belastbar sind, sollte ein Artefakt weitere Agenten oder Prozesse erreichen.