Die Optimierung von KI-Agenten endet nicht beim Modell. Teams verändern Prompts, Tools, Laufzeitlogik und Sicherheitsregeln eines Agenten-Harnesses und müssen jede Variante erneut prüfen. Wird dabei in jeder Runde das vollständige Validierungsset ausgeführt, steigen Rechenzeit und Kosten schnell. Task-CoEvolve schlägt einen anderen Weg vor: Nicht die Zahl der Kandidaten oder Iterationen wird zuerst reduziert, sondern die Auswahl der Evaluationsaufgaben wird an die sich entwickelnden Harnesses angepasst.
Was Task-CoEvolve laut Studie verändert
Die Primärarbeit beschreibt drei Kernelemente. Erstens werden Validierungsaufgaben gemeinsam mit dem Harness adaptiv ausgewählt. Zweitens priorisiert die Methode Aufgaben, bei denen verschiedene Kandidaten zu unterschiedlichen Ergebnissen kommen, weil diese Aufgaben mehr zur Unterscheidung beitragen sollen. Drittens wird aus den geprüften Teilmengen eine Leistung für das vollständige Set geschätzt; dabei werden die jeweiligen Auswahlwahrscheinlichkeiten berücksichtigt.
Die Autoren berichten Experimente mit Online-Textklassifikation und Terminal-Bench 2.1. Dort habe Task-CoEvolve die Endleistung einer Vollset-Suche mit bis zu 80 Prozent weniger Evaluationen erreicht. Diese Zahl ist ein Ergebnis der beschriebenen Versuche, keine bestätigte Einsparung für beliebige Unternehmensprozesse. Die vorliegende Quelle belegt weder eine identische Wirkung in anderen Domänen noch Produktionsreife im konkreten Betrieb.
Wann der Ansatz wirtschaftlich interessant wird
Task-CoEvolve ist vor allem dort interessant, wo ein Team viele Harness-Varianten über ein großes, kostspieliges Aufgabenportfolio vergleicht. Das kann bei Coding-Agenten der Fall sein, wenn jede Aufgabe eine isolierte Umgebung, Toolaufrufe und Tests benötigt. Bei einfachen Prompt-Änderungen mit wenigen günstigen Prüffällen ist der zusätzliche Auswahl- und Schätzmechanismus möglicherweise aufwendiger als eine vollständige Evaluation.
- Geeignet: viele Optimierungsrunden, große Aufgabenmenge und merkliche Kosten je Durchlauf.
- Geeignet: Kandidaten unterscheiden sich nur noch auf einem kleineren Teil anspruchsvoller Aufgaben.
- Vorsicht: seltene, aber geschäftskritische Fehler dürfen durch die Auswahl nicht aus dem Blick geraten.
- Vorsicht: Aufgabenverteilung oder Werkzeuge verändern sich während des Projekts stark.
- Eher ungeeignet: kleines Validierungsset, niedrige Ausführungskosten oder nur wenige Varianten.
- Eher ungeeignet: regulatorische oder vertragliche Vorgaben verlangen jeden Prüffall bei jeder Freigabe.
Die geschäftliche Entscheidung sollte deshalb nicht auf der Zahl der eingesparten Einzelprüfungen beruhen. Maßgeblich sind die Gesamtkosten bis zu einer belastbaren Freigabe: Rechenaufwand, Infrastruktur, Fehlersuche, menschliche Prüfung und das Risiko einer falschen Rangfolge zwischen Kandidaten. Eine kleinere Stichprobe ist nur dann wertvoll, wenn sie die Optimierung beschleunigt, ohne später teure Fehlentscheidungen zu verursachen.
Pilotaufbau mit zwei strikt getrennten Aufgabensets
Ein kontrollierter Unternehmenspilot sollte einen adaptiven Entwicklungspool und ein unverändertes Kontrollset trennen. Aus dem Entwicklungspool darf Task-CoEvolve informative Aufgaben auswählen und seine Auswahl im Zeitverlauf anpassen. Das Kontrollset bleibt dagegen für die Methode unsichtbar und wird nur zu vorher definierten Prüfpunkten vollständig ausgeführt. So lässt sich erkennen, ob die geschätzte Verbesserung auch außerhalb der adaptiv gewählten Aufgaben trägt.
- Referenzlauf erstellen: Alle Ausgangskandidaten einmal auf dem vollständigen Entwicklungs- und Kontrollset prüfen.
- Geschäftskritische Fälle markieren: Sicherheits-, Rechte- und Datenverlustszenarien aus der adaptiven Reduktion ausschließen.
- Adaptiven Pool aktivieren: Auswahlentscheidung, Wahrscheinlichkeit und Ergebnis für jede Aufgabe protokollieren.
- Vollprüfungen terminieren: Nach festen Meilensteinen alle Aufgaben ausführen und Schätzung gegen Realität vergleichen.
- Drift beobachten: Neue Fehlerarten und veränderte Tools als Anlass nehmen, Aufgabenverteilung und Kontrollset neu zu prüfen.
- Abbruchkriterien anwenden: Bei instabiler Rangfolge, wachsenden Schätzfehlern oder übersehenen kritischen Fehlern zur Vollset-Evaluation zurückkehren.
- Freigabe trennen: Der adaptive Suchlauf empfiehlt Kandidaten; die Produktionsfreigabe folgt erst nach unabhängiger Kontrolle.
Die drei wichtigsten Risiken
Das erste Risiko ist Auswahlverzerrung. Wenn häufig gelöste oder häufig gescheiterte Aufgaben seltener geprüft werden, können Veränderungen an genau diesen Fällen unbemerkt bleiben. Das zweite Risiko ist eine bewegliche Fähigkeitsgrenze: Mit neuen Tools oder Regeln können ehemals einfache Aufgaben wieder relevant werden. Das dritte Risiko ist falsche Sicherheit durch geschätzte Vollset-Werte. Eine statistisch korrigierte Schätzung ersetzt nicht automatisch die fachliche Prüfung seltener Schäden.
Daraus folgt eine Governance-Regel: Die adaptive Auswahl darf nur den Such- und Entwicklungsprozess beschleunigen, nicht Sicherheitskontrollen heimlich verkleinern. Kritische Prüffälle werden immer ausgeführt. Änderungen an Sampling, Gewichtung und Aufgabenset brauchen Versionen und einen nachvollziehbaren Owner. Außerdem sollte das Team protokollieren, welche Kandidaten nur geschätzt und welche vollständig geprüft wurden.
Welche Kennzahlen über den Pilot entscheiden
Neben der Zahl ausgeführter Evaluationen sollten Teams die Rangfolge der Kandidaten, die Abweichung zwischen geschätztem und vollständig gemessenem Ergebnis sowie übersehene kritische Fehler erfassen. Hinzu kommen Kosten und Durchlaufzeit bis zur Freigabe. Ein erfolgreicher Pilot spart nicht bloß Testläufe, sondern führt wiederholt zur gleichen belastbaren Auswahl wie die Referenz – mit dokumentierter Unsicherheit und ohne Verlust an Sicherheitsabdeckung.
Task-CoEvolve liefert damit einen interessanten Forschungsansatz für teure, iterative Agenten- und Harness-Optimierung. Unternehmen sollten das berichtete Einsparpotenzial als Hypothese behandeln und im eigenen Aufgabenmix prüfen. Der sinnvolle Einstieg ist kein umfassender Umbau, sondern ein begrenzter Paralleltest: adaptive Suche auf einem Entwicklungspool, regelmäßige Vollprüfungen und ein unangetastetes Kontrollset. Erst wenn Nutzen, Schätzqualität und Risikogrenzen gemeinsam überzeugen, ist ein breiterer Einsatz vertretbar.