Bewertung und Optimierung von Agenten: Vergleich von DSPy, TextGrad, Reflexion und OPRO

Teams greifen selten direkt zur automatisierten Bewertung und Optimierung von Agenten. Der übliche Weg ist schrittweise: Zuerst kommen ein kluger Prompt sowie einige einmalige Experimente, anschließend wiederholbare Messungen, dann gezielte Anpassungen und schließlich genügend Vertrauen, um die Änderungen kontrolliert einzuführen.

In der Regel beginnt es mit einem Agenten, der über einen starken Systemprompt, einige Tools sowie eine überzeugende Demo verfügt. Das ist ein guter Ausgangspunkt, bringt aber nur begrenzte Ergebnisse. Wenn immer mehr Personen auf den Agenten angewiesen sind, werden die Fragen praktischer: Welche Arbeitsabläufe halten stand und welche kollabieren bei hohem Volumen? Was passiert mit dem Verhalten, wenn das zugrunde liegende Modell aktualisiert wird? Leistet der Agent gute Arbeit bei den Fällen, die für die Betriebsabläufe, Risikokontrolle oder Kunden am wichtigsten sind?

Prompt-Engineering ist eine wertvolle Grundfähigkeit, doch wahre Reife entsteht durch das Einbetten des Agenten in einen disziplinierten Verbesserungskreislauf. Ein Agent, der systematisch bewertet werden kann, lässt sich ebenfalls systematisch verbessern, und ein Agent, der systematisch verbessert werden kann, lässt sich mit weitaus größerer Sicherheit steuern. Der Lohn ist also mehr als nur bessere Prompts – es handelt sich um einen kontrollierten Lernkreislauf für Sprachmodellsysteme: Man bestimmt, was als gut gilt, misst das Verhalten daran, wendet gezielte Optimierungen an und führt ausreichend Aufzeichnungen, um das Ergebnis vertrauenswürdig einstufen zu können.

Fünf Ansätze teilen diesen Ansatz: DSPy mit seinen Optimierern MIPRO und COPRO, TextGrad, Reflexion und OPRO. Ihre Mechanismen, Reifegrade und Einsatzmöglichkeiten unterscheiden sich, doch jeder beantwortet dieselbe Frage: Wie gelangt ein Agent von manuellem Experimentieren mit Prompts zu wiederholbaren, metrikbasierten Verbesserungen?

Die Bewertung steht im Zentrum jedes Kreislaufs

Die einfachste Art, diese Methoden als eine Familie zu betrachten, ist als verschiedene Suchverfahren bezüglich des Verhaltens eines Agenten. Alle setzen dieselben vier Elemente voraus.

• Etwas, das verändert werden kann: ein Agentenprogramm, eine Anweisung, ein Arbeitsablauf oder eine Entscheidungspolitik.
• Eine Sammlung von Aufgaben, ein Bewertungssatz, der darstellt, was der Agent tun soll.
• Ein Maßstab – sei es eine Metrik, eine Bewertungskriterienliste, eine Belohnung oder eine Erfolgsregel –, der bessere Ergebnisse von schlechteren unterscheidet.
• Ein Optimierer, explizit oder implizit, der auf der Grundlage früherer Ergebnisse Änderungen vorschlägt.

So betrachtet drehen sich diese Techniken eher um die Optimierung in Schleifen als um das Geben von Anweisungen. In einem Unternehmen ist es selten die schwierige Aufgabe, eine bessere Anweisung zu erstellen. Vielmehr geht es darum, eine wiederholbare Methode zu finden, um das Verhalten bei vielen Aufgaben zu verbessern – schließlich hat jeder Gewinn irgendwo einen Preis:

• Genauigkeit gegenüber Latenz

Qualität im Verhältnis zu den Kosten

Abdeckung gegen Überanpassung

Autonomie gegen Kontrolle

breite Allgemeingültigkeit gegen an die Aufgabe angepasste Einstellungen

eine lokal verbesserte Schrittweise gegen die Zuverlässigkeit des gesamten Systems

Daher sollten die Bibliotheken eher als Positionen innerhalb eines Entwurfsraums zur Verbesserung von Agenten verstanden werden, nicht als konkurrierende Tricks für Prompte.

Warum der Druck zunimmt

Frühe Unternehmensprojekte mit Agenten basieren in der Regel auf der Intuition von Experten. Ein erfahrener Anwender überarbeitet die Prompts, passt die Beschreibungen der Tools an, fügt Beispiele hinzu und testet erneut, bis die Ausgabe akzeptabel erscheint. Für ein oder zwei Anwendungsfälle reicht das aus.

Es gerät ins Wanken, wenn mehrere Teams gleichzeitig Agenten entwickeln, wenn Anfragen zwischen Umgebungen abweichen, wenn Bewertungsdaten verstreut werden, wenn Teams unterschiedliche Vorstellungen von Qualität haben, wenn ein Modulupdate das Verhalten auf unvorhersehbare Weise verändert oder wenn Audit-Spuren und die Zuverlässigkeit von Veröffentlichungen an Bedeutung gewinnen.

Dann ist eine Disziplin im Stil von MLOps erforderlich, die an Systeme angepasst ist, die auf Sprachmodellen basieren. Herkömmliche Softwaretests sind notwendig, aber nicht ausreichend, und klassische ML-Bewertungen helfen zwar, decken aber nicht alles ab. Agenten bringen eigene dynamische Komponenten mit: Anfragen, Toolaufrufe, Abrufverhalten, Planungsstruktur, Speicher, Wiederholversuche sowie Empfindlichkeit gegenüber dem jeweiligen Modell. Automatisierte Bewertung und Optimierung bieten praktische Mittel, um diese Variabilität in den Griff zu bekommen.

Die vier Haupttechniken

DSPy mit MIPRO und COPRO: Optimierung des Programms

Zu diesen Werkzeugen geht DSPy am weitesten, indem es das Verhalten von Modellen programmierbar statt improvisiert macht. Prompts sind nicht mehr nur einmalige Zeichenketten, und Pipelines werden auf strukturierte Weise deklariert, was der Verbesserung eine klare Grundlage bietet.

MIPRO und COPRO sind die automatisierten Optimierer in diesem Ökosystem. MIPRO justiert Prompts, Anweisungen sowie Beispiele unter Berücksichtigung bestimmter Metriken und eignet sich für Teams, deren Aufgabenbeschreibung recht stabil ist und die eine Suche nach Prompt-Einstellungen wünschen, die besser sind als die eines Menschen per Hand. COPRO verfeinert Prompts und Programme auf ähnliche Weise. Die zugrundeliegende Idee ist dieselbe: Das Programm wird zu einem Objekt, das kompiliert, angepasst und neu bewertet werden kann – anstatt nur manuell bearbeitet zu werden.

In der Praxis führt dies zu einer automatischen Erstellung von Prompts, zur Auswahl von Few-Shot-Beispielen, zur Anpassung an Anweisungen, zu einer metrikengestützten Verbesserung sowie zu einer klareren Trennung zwischen der Aufgabelogik und dem finalen, optimierten Prompt. Der Vorteil liegt in der Reproduzierbarkeit, einer soliden Grundlage für die Offline-Bewertung, weniger Abhängigkeit von der manuellen Erstellung einzelner Prompts sowie einer Optimierung, die eher wie Ingenieurwesen wirkt als nach Aberglauben.

Für Unternehmen, die einen seriösen internen Optimierungsworkflow statt einer Ansammlung handgefertigter Prompts suchen, gehört DSPy zu den stärksten Kandidaten – insbesondere für Aufgaben, die sich in wiederholbare Module und stabile Metriken einteilen lassen. Es hat jedoch auch Grenzen: Am besten funktioniert es, wenn eine Aufgabe strukturiert genug ist, um ein Bewertungsset zur Steuerung der Suche zu ermöglichen, und es ist nicht so mächtig, wie es scheint. Bei schwachen, unvollständigen oder fehlerhaft ausgerichteten Signalen verbessert sich der Optimierer einfach nur darin, das Falsche zu tun.

TextGrad: Kritik als Gradient

TextGrad verfolgt einen kühneren Ansatz. Anstelle von numerischen Gradienten setzt es auf schriftliche Kritiken und Aktualisierungssignale, um Prompts sowie promptähnliche Komponenten zu verbessern. Die Logik dahinter ist elegant: Wenn ein Modell angeben kann, was mit einer Ausgabe nicht in Ordnung ist und wie dies behoben werden kann, können diese Kommentare als Optimierungssignale dienen.

Es ermöglicht die wiederholte Feinabstimmung von Prompt-Texten, optimiererähnliche Aktualisierungen sowie die Arbeit an Systemprompts, Bewertungskriterien, Plänen oder sogar Evaluationsanweisungen. Die Optimierung wird so zu einem iterativen Prozess statt einer einzigen Suche. Dies eignet sich für Fälle, in denen die richtige Rückmeldung in Worten leichter auszudrücken ist als in Zahlen, und es kann sowohl die Bewertungskriterien des Evaluators als auch den Aufgabeprompt verbessern.

Es ist am besten als vielversprechendes Rohkonzept und nicht als fertige Lösung für Unternehmen zu betrachten. Es eignet sich dort, wo Teams Anleitungen, Pläne und Bewertungskriterien durch sprachbasierte Rückmeldungen verfeinern möchten, ist aber keine offensichtliche Standardlösung für ganze Organisationen. Seine größte Stärke ist zugleich seine größte Gefahr: Das Aktualisierungssignal selbst ist Sprache, die von einem Modell erzeugt wird. Ohne einen disziplinierten Bewertungsmechanismus kann dies die Optimierung weniger stabil, schwerer interpretierbar und schwieriger zu prüfen machen.

Rückblick: Lernen aus gescheiterten Versuchen

Der Rückblick unterscheidet sich von den beiden vorherigen Ansätzen. Der Fokus liegt nicht auf der Offline-Kompilierung von Anleitungen, sondern auf der Selbstverbesserung während des Laufs, getrieben durch die Reflexion über Misserfolge. Nach einem fehlgeschlagenen Versuch erstellt das System eine Kritik, und diese in Erinnerung behaltene Reflexion leitet spätere Versuche. Das Ergebnis ist ein einfacher Lernzyklus, der keine Feinabstimmung des Modells erfordert.

Es bietet erneute Versuche mit Selbstkritik, ein Gedächtnis für frühere Fehlermuster, die Korrektur der Handlungsrichtung des Agenten sowie Anpassungen innerhalb oder zwischen den Versuchen. Viele Agentenprobleme sind überhaupt keine Prompt-Probleme; es handelt sich dabei um Ausführungsprobleme wie mangelhafte Schlussfolgerungswege, falsche Werkzeugnutzung oder übersprungene Überprüfungen, und Reflexion hilft dabei, daraus wieder herauszukommen. Zudem bringt es das Lernen den tatsächlichen Betriebsbedingungen näher als alleinige Offline-Benchmarks es können.

Für Agenten, die als Workflows statt als Einzelantwort-Generatoren fungieren, ist Reflexion von großer Bedeutung – insbesondere dann, wenn ein erneuter Versuch vertretbar ist und das Sammeln wiederkehrender Fehlermuster Wert schafft. Sie tritt in der Regel als im Code implementiertes Muster auf, nicht als eine kanonische Bibliothek, weshalb ein Unternehmen sie als Designmuster behandeln und in seiner Orchestrierungsschicht standardisieren sollte, anstatt sie als Entscheidung des Anbieters zu betrachten. Die Gefahr besteht in Überreflexion: unbegrenzte Selbstkritik führt zu Verzögerungen, Kosten und Inkonsistenzen. Reflexion sollte von Richtlinien gesteuert werden, selektiv ausgelöst und wie jedes andere Verhalten bewertet werden.

OPRO: Ein Modell als Optimierer

OPRO, abgekürzt für Optimization by PROmpting, macht ein Sprachmodell zum Optimierer. Es schlägt bessere Prompt-Vorschläge unter Verwendung der Historie früherer Ergebnisse vor, sodass ein Modell im Raum der Anweisungen für ein anderes Modell oder Programm sucht.

Es umfasst die schnelle Suche, die Erstellung und Rangfolgebestimmung von Kandidaten sowie iterative Verbesserungen. Seine Logik beruht darauf, dass Sprachmodelle gut darin sind, alternative Formulierungen zu finden, wodurch schnell ein vielfältiger Suchraum entsteht und der Ansatz sich an viele Arten von Aufgaben anpassen kann.

OPRO ist strategisch interessant, gehört jedoch meist eher zum Experimentierwerkzeugkasten als zur Standard-Plattformstack. Er taucht in Forschungscode oder benutzerdefinierten Schleifen auf, nicht in standardisierten Produktionsbibliotheken. Sein bestmöglicher Einsatz könnte darin liegen, als kontrollierter Suchkomponente innerhalb eines größeren Optimierungsdienstes zu dienen, anstatt als eigenständige Funktion direkt Entwicklern angeboten zu werden.

Zwei Möglichkeiten, die Optionen zu sortieren

Die Techniken können entlang zweier Achsen geordnet werden: wo die Optimierung stattfindet und was optimiert wird.

Nach Standort:

• Die Offline-Optimierung umfasst DSPy mit MIPRO und COPRO, TextGrad sowie OPRO.
• Zur Laufzeit- oder episodenweisen Anpassung gehört Reflexion.
• Auch eine hybride Nutzung ist möglich, da Signale aus Reflexion-Laufungen offline gesammelt und in Schleifen im Stil von DSPy-, TextGrad- oder OPRO eingeführt werden können.

Nach Zielgruppe:

• Aufforderungstexte und Anweisungen werden von MIPRO, COPRO, TextGrad und OPRO verarbeitet.
• Beispiele mit wenigen Beispielen werden von MIPRO und COPRO angepasst.
• Programmstruktur und Pipeline-Komponenten fallen in den umfassenderen DSPy-Ekosystem.
• Ausführungspfade und Fehlerbehebung sind das Gebiet von Reflexion.

Das Muster hinter beiden Tabellen ist, dass diese Methoden voneinander ergänzt werden, sofern sie innerhalb der richtigen Steuerarchitektur verwendet werden.

Weiter messen und verbessern als separate Schichten

Der teuerste architektonische Fehler besteht darin, Optimierungen vor dem Bestehen einer zuverlässigen Bewertungsmethode einzuführen. Bei schwacher Bewertung wird die Optimierung gefährlich, da der Optimierer alles verbessert, was ihm zur Verfügung gestellt wird – einschließlich von Faktoren, die nichts mit dem tatsächlichen Geschäftswert zu tun haben. Ein solides Design teilt die Struktur in zwei Ebenen auf.

Das Bewertungssystem definiert und führt die Messungen durch. Es sollte Benchmarksätze sowie repräsentative Aufgaben enthalten, metriken und Bewertungskriterien, die speziell für jede Aufgabe gelten, aufgezeichnete Spuren der Vorgänge, Kennzahlen zu Kosten, Latenz und Zuverlässigkeit, analysen auf Untergruppen- oder Versagensmodus-Ebene sowie Freigabekriterien mit Regressionserkennung.

Das Optimierungsframework nutzt die Bewertungsergebnisse, um Verbesserungen vorzuschlagen und zu überprüfen. Sein Aufgabenbereich umfasst die Anpassung von Anweisungen, die Auswahl von Beispielen, die Festlegung von Reflexionsrichtlinien während der Ausführung, die Erstellung und Suche nach Kandidaten, das parallele Verfolgen von Experimenten sowie Aufstiegsregeln, die entscheiden, wann ein vielversprechender Kandidat zur genehmigten Standardlösung wird.

Die Trennung ist wichtig, denn Bewertung ist eine Steuerungsfunktion, während Optimierung ein Mechanismus für Veränderungen ist. Ein Unternehmen benötigt beides – sie zu verwechseln, ist ein Fehler.

Eine enge Shortlist

Im Vergleich zu akademischen Ansätzen sollte für eine praktische Unternehmensumgebung die Shortlist streng begrenzt werden. Nicht jede vielversprechende Forschungsidee verdient es, zu einer erstklassigen Plattformabhängigkeit zu werden.

DSPy als Hauptoptimierungsframework. Es bietet die stärkste Struktur, um Modellprogramme als optimierbare Artefakte zu behandeln. MIPRO und COPRO beziehen sich direkt auf die praktische Anpassung von Prompts und Beispielen, und der gesamte Ansatz eignet sich besser für wiederholbare interne Arbeitsabläufe als für ad hoc angepasste Prompts. Seine Rolle besteht darin, der Standardmotor für stabile Aufgaben zu sein, die Grundlage für die Offline-Kompilierung von Prompts sowie die wichtigste Abstraktion für Teams, die wiederholbare, metrikbasierte Verbesserungen anstreben.

Reflexion als Standard-Laufzeitmuster. Es muss keine eigenständige Abhängigkeit sein. Es adressiert ein anderes Problem als DSPy, nämlich die Wiederherstellung während der Ausführung, und unterstützt agentenbasierte Tools sowie mehrschrittige Workflows. Es passt in Orchestrierungsschichten wie LangGraph oder einfache Python-Runner. Seine Rolle besteht darin, eine selektive Politik der Wiederholung und Reflexion für Workflow-Agenten bereitzustellen, strukturierte Fehlerdaten für spätere Offline-Anpassungen zu liefern sowie einen standardisierten Weg für begrenzte Selbstkorrektur zu schaffen.

TextGrad als fortgeschrittene, experimentelle Option. Es bietet ein neuartiges Verfeinerungsinstrument, das sich für Anfragen, Bewertungskriterien oder Pläne eignet, die von kritikgestützter Iteration profitieren. Am besten wird es hinzugefügt, sobald ein stabiles Bewertungssystem vorhanden ist. Seine Rolle ist es, ein spezialisiertes Werkzeug für Optimierungsteams zu sein, das dort eingesetzt wird, wo schriftliche Rückmeldungen ausführlicher sind als eine einfache Punktzahl.

OPRO – geringere Priorität als Plattformstandard. Es eignet sich oft besser als interne Optimierungsmodus denn als Wahl für eine zentrale Bibliothek. Viele seiner Konzepte können mit benutzerdefinierten Suchschleifen innerhalb eines stärkeren Bewertungsrahmens nachgeahmt werden, und es ist für durchschnittliche Entwickler keine so natürliche Standardlösung. Sollte es verwendet werden, sollte es als Suchstrategie innerhalb eines zentralen Optimierungsdienstes dienen oder als Experimentiermöglichkeit für Plattformteams.

Was darauf aufgebaut werden kann

Entwickler sollten nicht bei jedem Projekt diese Techniken aus Rohbibliotheken zusammenstellen müssen. Die meisten Teams haben keine Verwendung für fünf Optimierungsparadigmen auf der Anwendungs Ebene. Sie benötigen ein einfacheres internes Framework, das festlegt, wie die Qualität von Agenten definiert, gemessen, verbessert und gefördert wird. Der sinnvolle Ansatz ist eine schlanke, aber klare interne Plattform, die auf einer selektiven Auswahl an Bibliotheken basiert. Sie sollte zufällige Komplexität verbergen und gleichzeitig die wichtigen Kontrollmechanismen standardisieren.

1. Ein Evaluierungs-SDK. Eine gemeinsame Methode zur Definition von Agentenaufgaben, Datensätzen und Metriken. Es standardisiert das Schema der Testfälle, die erwarteten Ausgaben oder Bewertungskriterien, das Format der Protokollierung, die Erfassung von Kosten und Latenzzeiten, das Versionieren der Datensätze sowie die Regressionsschnittstellen. Ziel ist es, dass ein Team seinen Agenten, sein Evaluierungsset sowie seine Erfolgsmaße ohne das Schreiben eines eigenen Tools angeben kann.

Ein Optimierungsdienst. Ein kontrollierter Dienst führt Optimierungsaufgaben aus, sodass Teams keine eigenen Schleifen erstellen müssen. Er unterstützt die Anpassung von Prompts und Beispielen unter Verwendung von DSPy, optionalen TextGrad-Feinabstimmungen, eine auf OPRO inspirierte Suchfunktion, den Vergleich von Experimenten mit leistungsbasierten Berichten sowie Workflows zur Freigabe von Kandidaten. Ein Entwickler kann die Anpassung eines Agenten an einer festgelegten Dataset-Version beantragen, wobei feste Grenzen für Reaktionszeit und Kosten gelten, und erhält Kandidaten, die direkt miteinander verglichen werden können.

Eine Laufzeit-Reflexionsrichtlinien-Schicht. Reflexionsähnliches Verhalten wird in jedem Agent durch Konfiguration statt durch eigens geschriebenen Code realisiert. Die Richtlinien legen fest, wann Wiederholungsversuche erlaubt sind, wann Reflexion aktiv wird, wie viele Wiederholungen zulässig sind, welche Informationen über frühere Fehler gespeichert werden und wann ein Mensch oder ein Ersatzworkflow eingeschaltet werden soll. Dadurch erhalten Teams eine begrenzte Selbstkorrekturmöglichkeit durch Vorlagen und vermeiden es, inkonsistente Wiederholungslogiken zu entwickeln.

Ein Prompt- und Richtlinienregister. Prompts, Bewertungskriterien sowie Optimierungsartefakte werden als regulierte Ressourcen behandelt: versioniertes Speichern, Nachverfolgbarkeit vom Prompt über das Experiment bis zur Veröffentlichung, Anmerkungen zur Modellkompatibilität, Rollback-Funktion sowie Genehmigungsprotokolle für Produktionsvarianten. Dadurch verhalten sich Prompts wie einsetzbare Konfigurationen und nicht als Text, der zwischen Notizbüchern und Repositorien kopiert wird.

Anbindung an das Unternehmens-Kontrollflächen-System. Das Framework verbindet sich mit CI/CD-Schleusen, Tools zur Überwachbarkeit, Modellkatalogen, Geheimdaten-Management sowie Umgebungsverwaltung, Kontrollmechanismen zur Datenverwaltung und Freigabeprozessen für hochriskante Anwendungen. Diese Verbindung trennt eine Technikbibliothek von einer unternehmensweiten Funktionalität.

Für die meisten Entwickler sollte dies auf vier Kernpunkte reduziert werden: Definition des Vertragsmodells des Agents, Bereitstellung von Bewertungsfällen, Auswahl eines Optimierungsmodus sowie Überprüfung des ausgewählten Kandidaten zusammen mit seinem Bereitstellungsbericht. Im Hintergrund können alle vier Techniken zum Einsatz kommen, doch das, was die Entwickler sehen, sollte übersichtlich bleiben. Das Skalierungsproblem liegt selten an einem Mangel an Algorithmen, sondern vielmehr am Vorhandensein von maßgeschneiderten, inkompatiblen Verbesserungsschleifen innerhalb der Teams.

Stufenweiser Rollout

Phase eins: Bewertungsdisziplin. Bevor mit umfassender Optimierung begonnen wird, sollten gemeinsame Bewertungsschemata, sorgfältig ausgewählte Vergleichsdatensätze, Funktionen zur Protokollierung und Wiedergabe sowie Baseline-Werte für Kosten, Latenzzeit und Aufgabengüte eingerichtet werden.

Phase zwei: Offline-Optimierung mit DSPy. DSPy in Kombination mit MIPRO und COPRO soll der Hauptweg für stabile Aufgabenklassen darstellen und dabei die Erstellung von Anfragen, die Auswahl von Beispielen, die Anpassung von Anweisungen sowie einen wiederholbaren Vergleich von Experimenten abdecken.

Phase drei: reflektierter Laufzeitbetrieb mit Grenzen. Es sollten reflexionsbasierte Strategien für Agenten eingeführt werden, deren Fehler oft durch erneute Versuche unter Berücksichtigung von Kritiken, selektive Wiederholungsversuche, strukturierte Reflexionsmemorien sowie Diagnosen auf Trajektorieebene behoben werden können.

Phase vier: fortgeschrittene Modi, sparsam einsetzen. Fügen Sie TextGrad sowie suchfunktionen im Stil von OPRO nur dann hinzu, wenn ein klarer Bedarf besteht und die Bewertungsmethoden ausgereift genug sind, um sie zu steuern. Dies sollte in der Regel zunächst eine Fähigkeit des Plattform-Teams bleiben, bevor sie allen Entwicklern zur Verfügung gestellt wird.

Wo es schiefgeht

• Metrik-Überanpassung. Ein eng gefasster oder veralteter Vergleichsmaßstab lehrt den Optimierer eher den Maßstab selbst als die eigentliche Aufgabe.
• Kranke Bewertungskriterien. Wenn die Benotung auf schwachen oder inkonsistenten Modellbewertern beruht, folgt die Optimierung den Eigenheiten der Bewertenden.
• Lokale Erfolge, globale Verluste. Die Anpassung einer Unteraufgabe kann heimlich die Kosten erhöhen oder andere Schritte verlangsamen sowie das Verhalten des restlichen Workflows verändern.
• Lärmende Reflexion. Reflexion ohne Richtlinienbegrenzungen erzeugt mehr Tokens und Verzögerungen – mit nur geringem tatsächlichen Nutzen.

Organisatorische Fragmentierung. Wenn jedes Team seine eigenen Optimierungsbibliotheken und Bewertungskonventionen wählt, verliert das Unternehmen die Vergleichbarkeit und Kontrolle.

All das führt zu demselben Schluss: Die Optimierung ist nur so gut wie die dazugehörige Bewertung und Steuerung.

Die Form der Lösung

Was DSPy, MIPRO, COPRO, TextGrad, Reflexion und OPRO verbindet, ist nicht die Verbesserung von Prompts – vielmehr versucht jedes von ihnen, die Verbesserung von Agenten in ein Feedbacksystem umzuwandeln. Der strategische Ansatz besteht nicht darin, jede Idee jedem Entwickler zugänglich zu machen, sondern in der Schaffung eines kontrollierten internen Rahmens, in dem die Bewertung standardisiert, die Optimierung selektiv, die Laufzeitreflexion den Richtlinien folgt und Prompt-Varianten wie Produktionsressourcen gesteuert werden.

Zur präziseren Empfehlung ist die stärkste Vorgehensweise, DSPy mit MIPRO und COPRO zur Durchführung der Offline-Optimierung zu nutzen, Reflexion als gemeinsames Laufzeitmuster für begrenzte Selbstkorrekturen einzuführen, TextGrad speziellen Teams vorzubehalten und OPRO hauptsächlich als interne Suchtechnik statt als Abhängigkeit für Entwickler zu betrachten. Die Gewinner unter den Unternehmensagenten werden durch die Qualität des um sie herum bestehenden Feedbackloops entschieden, wobei schnelle Cleverness deutlich weniger Gewicht hat.