AutoGen und CrewAI im Vergleich: Aufbau von Agententeams und Berechnung ihrer Kosten.

In einem langen Zeitraum der Anwendung von Large Language Models war das Bild einer KI-Interaktion ein einfacher Kreislauf: Jemand gibt einen Prompt ein, ein Modell antwortet, und das Gespräch setzt sich fort. Das funktioniert gut für das Beantworten von Fragen. Es wird problematisch, sobald es darum geht, tatsächlich etwas zu erledigen – wie zum Beispiel ein Programm zu schreiben und zu debuggen, einen Forschungsbericht zu planen oder einen mehrschrittigen Arbeitsablauf durchzuführen, der mehrere Tools und Datensätze betrifft.

Mehre-Agenten-Systeme existieren, um diese Lücke zu schließen. Anstatt eine einzige, monolithische Anweisung zu verwenden, die alles bewältigen soll, wird die Aufgabe in Rollen aufgeteilt: ein Ingenieur, ein Kritiker, ein Forscher, ein Schreiber. Jede Rolle wird zu einem Agenten, der eine Umhüllung um ein LLM darstellt und über seine eigene Persönlichkeit, sein eigenes Gedächtnis sowie Verantwortlichkeiten verfügt. Die Agenten kommunizieren miteinander, geben teilweise fertige Ergebnisse weiter, kritisieren einander und iterieren, bis die Arbeit abgeschlossen ist. Die Erfahrung ähnelt weniger dem Konsultieren eines Orakels als vielmehr der Leitung eines kleinen, sehr schnellen Teams.

Zwei Frameworks dominieren diesen Bereich und werden hier verglichen: AutoGen, das von Microsoft Research als Open Source veröffentlicht wurde, sowie CrewAI, eine jüngere Plattform, die unter Berücksichtigung von Unternehmensworkflows entwickelt wurde. Ein drittes Tool, AgentOps, fügt eine Überwachungsschicht hinzu, sodass sichtbar wird, was die Agenten tun und welche Kosten damit verbunden sind.

Rollen statt einer einzigen großen Anweisung

Der konzeptionelle Wandel erfolgt bereits vor der Einführung jeglicher Tools. In einer Ein-Agenten-Konfiguration hat ein Systemprompt gleichzeitig zwei Aufgaben: die Definition einer Persönlichkeit sowie die Vorhersage dessen, was vom Modell erwartet werden könnte. Mehr-Agenten-Frameworks verteilen die Last. Jeder Agent erhält eine präzisere Aufgabenbeschreibung, die aus einer Persönlichkeit, einem Ziel und gegebenenfalls einer Hintergrundgeschichte besteht, die seinen Ansatz prägt.

Das ahmt die Arbeitsweise menschlicher Teams nach. Ein Senior-Engineer ist nicht gleichzeitig QA-Prüfer, Projektmanager und Technischer Redakteur. Die Aufteilung dieser Funktionen auf verschiedene Agenten bringt drei praktische Vorteile mit sich:

• Spezialisierung steigert die Qualität. Ein Agent, dessen einziger Zweck darin besteht, Code auf Sicherheitsprobleme zu überprüfen, wird ihn konsistenter prüfen als ein Generalist, der mehrere Ziele gleichzeitig verfolgt.
• Feedbackschleifen werden explizit. Das Weiterleiten der Ausgabe eines Agenten an einen anderen, dessen Aufgabe es ist, sie zu kritisieren, schafft einen gezielten Überprüfungszyklus anstelle der Hoffnung, dass dasselbe Modell seine eigenen Fehler findet.
• Parallelarbeit wird möglich. In komplexeren Systemen können Agenten gleichzeitig verschiedene Teile eines größeren Ziels bearbeiten, wobei ein Forschungsagent und ein Schreibagent separate Teilaufgaben übernehmen.

Der schwierige Aspekt, den jedes Framework auf seine eigene Weise löst, ist die Kommunikation. Wie tauschen Agenten Informationen aus? Teilen sie ein einziges Gespräch oder führen sie isolierte Austausche, die nur gelegentlich aufeinandertreffen? Die Antworten unterscheiden sich bei AutoGen und CrewAI, und dieser Unterschied prägt alles Weitere.

AutoGen: Alles ist ein Gespräch

Microsofts AutoGen betrachtet jede Interaktion zwischen Agenten als ein Gespräch. Die grundlegende Entscheidung dabei ist, dass die Agenten miteinander in natürlicher Sprache kommunizieren, genauso wie Menschen in einem Chat-Thread. Dadurch ist es intuitiv: Jeder, der schon einmal gesehen hat, wie zwei Kollegen in einem Slack-Kanal Ideen gegenseitig weiterentwickeln, kennt bereits das Konzept hinter AutoGens gesprächsfähigen Agenten.

Testen in AutoGen Studio

Bevor überhaupt Python-Code geschrieben wird, bietet AutoGen Studio eine grafische Möglichkeit zum Experimentieren. Es wird mit pip installiert, liest eine API-Schlüssel aus einer Umgebungsvariable und startet mit einem einzigen Befehl aus der Kommandozeile. Anschließend öffnet sich eine Browseroberfläche. Dort wird eine Aufgabe eingegeben, und ein Benutzer-Proxy-Agent arbeitet mit einem oder mehreren Assistenten-Agenten zusammen, bis die Aufgabe erledigt ist.

Das auftretende Muster lohnt es, gelernt zu werden, denn es tritt überall wieder auf. Nehmen wir an, die Anfrage besteht darin, die Beliebtheit eines Suchbegriffs im Laufe der Zeit darzustellen. Der Assistentenagent beginnt damit, Codeausschnitte für die Unteraufgaben zu erstellen. Der Benutzer-Proxy-Agent führt diese Ausschnitte anschließend in einer abgeschotteten Umgebung aus und prüft, ob das Ergebnis korrekt aussieht. Wenn der Code fehlschlägt oder die Ausgabe falsch ist, sendet der Proxy Feedback zurück, der Assistent überarbeitet den Code, und der Kreislauf aus Erstellen, Ausführen, Bewerten und Überarbeiten setzt sich fort, bis der Proxy zufrieden ist.

Diese Schleife automatisiert den menschlichen Anteil der Code-Review-Prozesse. In einer normalen Sitzung schreibt ein Entwickler Code, führt ihn aus, beobachtet, wie er fehlschlägt, und behebt den Fehler persönlich. Hier übernimmt der Proxy den Schritt des Ausführens und Überprüfens, sodass eine Person weggehen kann, während die beiden Agenten das Problem lösen. Es ist nicht fehlerfrei, da geänderte Bibliotheken oder veraltete Funktionen die Agenten manchmal in Verlegenheit bringen, doch bei gut abgegrenzten Problemen ist es äußerst wirksam. Bildgenerierung, Datenvisualisierung und kurze Anwendungen werden oft bereits nach ein paar Iterationen abgeschlossen.

Eine Empfehlung taucht immer wieder auf: Führen Sie AutoGen und AutoGen Studio innerhalb von Docker aus, sobald der generierte Code mit dem zugrunde liegenden Betriebssystem in Berührung kommen könnte. Die Agenten sind darauf ausgelegt, beliebigen Code zu schreiben und auszuführen, weshalb ein Container den Host vor Nebeneffekten schützt. Dieser Rat gewinnt an Bedeutung, je mehr Autonomie den Agenten eingeräumt wird.

Fähigkeiten als zusätzliche Eigenschaften

Studio kommt nur mit wenigen eingebauten Werkzeugen aus, wie zum Beispiel zum Abrufen von Webinhalten oder zur Erstellung von Bildern. Seine wahre Stärke liegt in benutzerdefinierten Fähigkeiten. Eine Fähigkeit ist eine gewöhnliche Python-Funktion mit einem klaren Namen und einer gut geschriebenen Dokumentation, und das Framework liest diese Dokumentation, um zu entscheiden, wann und wie sie aufgerufen werden soll.

Ein beispielhaftes Szenario zeigt die Funktionalität „describe_image“, die ein Bild an ein Modell mit Sehfähigkeiten sendet und eine Beschreibung zurück erhält. Wenn diese Funktion mit dem Hauptassistenten verknüpft wird, ermöglicht sie eine sehr präzise Anfrage: Es wird ein Buchumschlag für einen bestimmten Titel erstellt, anschließend wird die Funktionalität „Image-Description“ genutzt, um zu überprüfen, ob der Titeltext korrekt geschrieben ist. Bildgeneratoren sind bekanntermaßen schlecht darin, lesbaren Text zu erzeugen, wodurch sich hier ein natürlicher Überprüfungszyklus ergibt. Der Assistent erstellt ein Bild, die Sehfunktion prüft die Schrift, und falls etwas falsch ist, versucht der Assistent es erneut. Durch die Erstellung kleiner, gut dokumentierter Tools entsteht ein Verhalten, das überraschend widerstandsfähig ist.

Hinter diesem Ansatz steht eine bestimmte Designphilosophie. Anstatt davon auszugehen, dass Agenten für jeden Bedarf völlig neuen Code schreiben, ist es oft stabiler, ihnen eine feste Bibliothek mit getesteten Fähigkeiten zur Verfügung zu stellen. Code, den ein LLM spontan erstellt, kann zusammenbrechen, wenn sich Bibliotheken entwickeln oder Abhängigkeiten ändern, während überprüfte, verpackte Fähigkeiten sich vorhersagbar verhalten. Ob Agenten Code dynamisch schreiben oder vorgefertigte Tools aufrufen sollen, wird später in Diskussionen zur Planung und Ausführung behandelt – und es handelt sich dabei um eine der entscheidenderen Wahlmöglichkeiten bei der Gestaltung eines Agentensystems.

Rohcode mit pyautogen

Nach Studio ist der nächste Schritt das Schreiben von Python-Code unter Verwendung des pyautogen-Pakets. Zwei Bausteine sind dabei wichtig:

• ConversableAgent ist ein allgemein einsetzbarer Agent, der direkt mit einem LLM kommuniziert.
• UserProxyAgent vertritt den menschlichen Benutzer und kann Code in einem Arbeitsverzeichnis ausführen.

Eine minimale Einrichtung verbindet die beiden Komponenten miteinander und startet ein Gespräch, indem beispielsweise nach einer einzeiligen Lösung für FizzBuzz gefragt wird. Wenn der Proxy gestartet wird, bittet er um Feedback, nachdem der Assistent etwas vorgeschlagen hat. Das Drücken von Enter ohne Feedback signalisiert ihm, direkt den Code auszuführen. Falls ein benötigtes Paket wie Pygame fehlt, installiert der Proxy es vor der Ausführung des Programms. Diese Selbstversorgung ist ein kleines, aber aussagekräftiges Zeichen für die Freiheit, die diesen Systemen eingeräumt werden kann – mit ebenso Vorteilen wie Nachteilen.

Praktische Programmieraufgaben zur Bewertung eines Modells umfassen das Überprüfen, ob eine Zahl prim ist, das Erstellen eines Snake-Spiels sowie das Bauen eines Asteroids-Klons mit Pygame. Sie sind selbstständig, testbar und in ihrer Schwierigkeit variabel genug, um Unterschiede zwischen Modellen oder Konfigurationen aufzuzeigen.

Hinzufügen eines Kritikers durch verschachtelte Chats

Ein Assistent zusammen mit einem Proxy ist nützlich, doch Multi-Agenten-Systeme überzeugen durch spezialisierte Persönlichkeiten. Ein zweiter Assistent kann als Code-Reviewer fungieren, wobei eine Systemnachricht sicherstellt, dass die Überprüfung gründlich, streng nach Standards erfolgt und sich auf Sicherheits- sowie Qualitätsprobleme konzentriert.

Anstatt den Kritiker direkt in das Hauptgespräch einzubinden, bietet AutoGen verschachtelte Chats an. Der Benutzer-Proxy registriert einen solchen verschachtelten Chat, der jedes Mal aktiviert wird, wenn der Ingenieur-Agent neue Ausgaben erzeugt. Der Code gelangt automatisch zum Kritiker innerhalb eines eigenen Nebengesprächs; der Kritiker antwortet mit einer Bewertung, die anschließend in den Hauptthread zurückgeführt wird. So wird ein Bewertungsschritt eingefügt, ohne dass der Kritiker bei jedem Schritt stört, und er spricht nur dann, wenn es etwas Neues zu prüfen gibt.

Bei einer Aufgabe wie dem Schreiben eines Snake-Spiels mit Pygame ist der Unterschied zu einem einfachen Ablauf durch Ingenieur und Proxy deutlich spürbar. Nach der Ausführung des Codes kommt der Bewertende mit einer Liste von Vorschlägen zur Verbesserung, wodurch im Grunde die Pull-Request-Prüfung nachgeahmt wird, die menschliche Teams täglich durchführen.

Caching zur Kosteneinschränkung

Mehr-Agenten-Gespräche werden schnell teuer. Jeder Austausch verbraucht Token, und komplexe Aufgaben können Dutzende von Schritten erfordern. AutoGen verfügt über ein Caching-System: Standardmäßig wird der Gesprächszustand in einem .cache-Ordner auf der Festplatte gespeichert, sodass eine lange oder unterbrochene Aufgabe ohne doppelten Tokenverbrauch fortgesetzt werden kann.

Das Verhalten kann explizit eingestellt werden, indem der Chataufruf in einen Kontextmanager eingebettet wird, der einen cache_seed bereitstellt. Die Bedeutung dieses Ansatzes wird oft unterschätzt. Bei der Entwicklung von Agenten ist es üblich, eine frühere Ausführung abzuspielen oder zu überprüfen, anstatt sie neu zu generieren – sei es zum Debuggen oder um den Beteiligten genau zu zeigen, wie ein Agent zu einem Ergebnis gelangt ist.

Gruppenchat und das Telefonspiel-Problem

Verwandte Chats weisen eine strukturelle Schwäche auf, die an das Kinderspiel „Telefonspiel“ erinnert. Informationen werden in einer Kette von einem Agenten zum nächsten weitergeleitet, wobei Details bei jeder Übertragung verloren gehen, verzerrt werden oder neu interpretiert werden. Wenn der Kritiker niemals die vollständige ursprüngliche Aufgabe sieht, sondern nur das, was der Entwickler zur Weiterleitung entschieden hat, kann seine Rückmeldung den Kern der Sache verfehlen.

AutoGen’s Lösung ist der Gruppenchat. Ein GroupChat-Objekt bewahrt einen gemeinsamen Pool aus Agenten und Nachrichten auf, vergleichbar mit einem Teamkanal, anstelle einer Reihe von Punkt-zu-Punkt-Relais. Ein GroupChatManager koordiniert das Abwechseln der Antworten, damit nicht alle Agenten gleichzeitig antworten. Die entscheidende Eigenschaft ist, dass jedes Mitglied die gesamte Konversationsgeschichte sehen kann, nicht nur das, was ihm ausdrücklich übermittelt wurde.

Durch die Verwendung des Gruppenchats bei dem Beispiel mit Ingenieur und Kritiker entsteht eine kohärentere Zusammenarbeit. Die Rückmeldungen des Kritikers basieren auf dem gleichen vollständigen Kontext wie beim Ingenieur, und der Ingenieur kann spezifische Kritiken direkt beantworten, anstatt von einer Paraphrase auszugehen. Der Preis dafür ist, wie erwartet, die Umfangreiche Darstellung. Gruppenkonversationen verbrauchen mehr Token, da jeder Agent im Grunde jede Nachricht mitverfolgt – was bei einer Bezahlung pro Token in großem Maßstab von Bedeutung ist.

Was die frühen Beispiele lehren

Insgesamt weisen die Studio-Sessions sowie die Experimente mit Rohcode einige Punkte auf, die auf jedes Agentenprojekt übertragbar sind. Eine Aufgabe sollte klein genug sein, damit ein Erfolg überprüft werden kann, denn der Proxy-Loop funktioniert nur, wenn etwas bestimmen kann, ob die Ausgabe korrekt ist. Die Ausführung sollte isoliert sein, da dieselbe Autonomie, die den Loop nützlich macht, es ihm auch ermöglicht, Pakete zu installieren und beliebige Programme auszuführen. Bewertungen sind kostengünstig hinzuzufügen, sobald Rollen vorhanden sind, weshalb ein Kritiker fast immer einen Versuch wert ist. Zudem gehört die Kostenberechnung von Anfang an zum Design: Caching, Wiedergabe sowie eine Einschätzung, wie viele Schritte eine Aufgabe benötigt, sind Teil des Systemaufbaus und keine Nachgedanken.

Es gibt auch eine Lektion darüber, wo man Anstrengungen investieren sollte. Das Schreiben einer guten Systemnachricht für den Kritiker oder einer klaren Dokumentation für eine Fähigkeit verändert das Verhalten weitaus mehr als das Hinzufügen weiterer Agenten. Beide Frameworks belohnen präzise, detaillierte Beschreibungen davon, wofür jeder Agent dient.

CrewAI: Struktur statt Improvisation

Während AutoGen auf offene Gespräche setzt, ist CrewAI strukturierter und zielorientierter und richtet sich eindeutig an Geschäfts- und Produktionsumgebungen. Anstelle eines freien Dialogs werden drei klare Definitionen gefordert: die Agenten mit ihren Rollen, Zielen und Hintergründen; die Aufgaben, die ihnen zugewiesen werden; sowie das Team, das sie unter einer definierten Verarbeitungsstrategie zusammenführt.

Was einen Agenten ausmacht

Ein CrewAI-Agent wird über eine Handvoll Parameter konfiguriert:

• role: eine kurze Bezeichnung für die Funktion des Agenten, wie z. B. Senior Joke Researcher.
• goal: eine in natürlicher Sprache formulierte Angabe darüber, was der Agent erreichen soll, oft als Vorlage für Wiederverwendung mit unterschiedlichen Eingaben.
• backstory: eine erzählerische Darstellung zur Gestaltung der Persönlichkeit, die Kontext und Charaktereigenschaften liefert, ähnlich wie eine System-Prompt-Persönlichkeit.
• memory und verbose: Flags, die steuern, ob der Agent den Kontext über mehrere Interaktionen hinweg behält und ob er seine Überlegungen in die Konsole ausgibt.
• allow_delegation: ob der Agent Aufgaben an andere Mitglieder des Teams delegieren darf.

Die Aufgaben werden getrennt definiert. Jede enthält eine Beschreibung der Arbeit, ein Feld „erwartetes_Ergebnis“, das beschreibt, wie Erfolg für den Agenten und den Leser aussieht, einen Verweis auf den zuständigen Agenten sowie Optionen wie die asynchrone Ausführung oder das Schreiben des Ergebnisses in eine Datei.

Das Crew-Objekt bringt schließlich Agenten und Aufgaben zusammen mit Einstellungen dafür, wie die Zusammenarbeit abläuft – sequenziell oder hierarchisch – sowie Optionen zur gemeinsamen Nutzung von Speicher, Caching und einer Obergrenze für Anfragen pro Minute, um die API-Nutzung in Schach zu halten.

Ein unterhaltsames Beispiel: die Witze-Crew

Um das konkret zu machen, wird ein Team aus zwei Agenten für Witze gebildet. Ein erfahrener Witzzentrumforscher analysiert, was ein Thema lustig macht, und notiert relevante soziale Trends, während ein Witzeautor diese Erkenntnisse in einen echten Witz umsetzt. Der Forscher kann Aufgaben delegieren, der Autor hingegen nicht. Das ist eine sinnvolle Aufteilung, da der Autor als letzte Stufe im Prozess fungieren soll und nicht als Knotenpunkt, der Arbeit weiterleitet.

Bei einem Thema wie Witze über KI-Entwickler erzeugt das Team durch einen Prozess aus Forschung und anschließendem Schreiben wirklich unterhaltsame Ergebnisse anstelle eines einzigen, monolithischen Auftrags. Auch wenn es lächerlich klingt, zeigt es, warum die Trennung des Verständnisses des Themas von der Erstellung des kreativen Ergebnisses zu überlegteren Ausgaben führen kann. Die Grundarbeit des Forschers dient dem Autor als Grundlage und Kontext, ähnlich wie ein in den Arbeitsablauf integrierter Miniaturabrufschritt.

AgentOps: Beobachtung des Geldflusses

Entwickler von Agenten kehren immer wieder zu derselben Sorge zurück: Wie viel kostet dieser Ausführungsvorgang und wohin verschwindet die Zeit? Wenn mehrere Agentensysteme unüberwacht bleiben, können erhebliche Rechnungen entstehen, da jede Kommunikation zwischen Agenten, jede Delegation sowie jeder Aufruf von Tools zusammengezählt wird. AgentOps ist eine Überwachungsplattform, die speziell für das Verhalten von LLM-Agenten entwickelt wurde – im Gegensatz zu herkömmlichen MLOps-Tools, die nicht für autonome, konversationelle Agenten konzipiert sind.

Die Einbindung in ein CrewAI-Projekt erfordert nur wenig Aufwand: Installieren Sie das Paket, holen Sie sich einen API-Schlüssel, fügen Sie diesen in die Umgebungskonfiguration ein und initialisieren Sie die Bibliothek am Anfang des Skripts. Jede Ausführung wird anschließend in einem Dashboard protokolliert, das Folgendes anzeigt:

• die Gesamtdauer der Ausführung sowie die verwendete Umgebung,
• die Anzahl der Prompt- und Completion-Tokens für jeden LLM-Aufruf,
• die Dauer jedes einzelnen Aufrufs,
• die geschätzten Kosten in US-Dollar für die gesamte Ausführung.

Der letzte Punkt ist beim ersten Mal schockierend. Ein einziger Ablauf der „Joke Crew“, der für einen Menschen trivial erscheint, kostet, wenn alle Zwischenschritte wie Logikabläufe, Delegationen und Toolaufrufe berücksichtigt werden, einen nicht unerheblichen Bruchteil eines Dollars. Für alle, die Agentensysteme mit kommerziellen Ambitionen entwickeln, ist das eine nützliche Realitätsprüfung: Das Orchestrieren von Agenten ist mächtig, aber nicht kostenlos – und die Überwachbarkeit verwandelt eine abstrakte Kostengröße in eine Zahl, die budgetiert und optimiert werden kann.

Eine Spieleentwicklerteam

Zur direkten Vergleich mit den AutoGen-Beispielen wird CrewAI verwendet, um ein kleines Spieleentwicklerteam aus drei Agenten zusammenzustellen:

1. Ein Senior Software Engineer schreibt die Python-Implementierung des gewünschten Spiels.
2. Ein Software Quality Control Engineer überprüft den Code auf Fehler – von fehlenden Importen und ungleichmäßigen Klammern über Sicherheitslücken bis hin zu fehlerhafter Logik.
3. Ein Chief QA Engineer kann Aufgaben delegieren und ist letztendlich dafür verantwortlich, sicherzustellen, dass der fertige Code den ursprünglichen Anforderungen entspricht.

Die Aufgaben folgen derselben Struktur: Eine Person erstellt die ursprüngliche Implementierung, eine zweite prüft sie auf Fehler, und eine dritte fügt beide Teile zu einer endgültigen, korrigierten Version zusammen. Dieser dreistufige Überprüfungsprozess aus Erstellung, Kritik und Finalisierung ist eine weiter ausgefeilte Variante des von AutoGen verwendeten Musters aus Entwickler und Kritiker, das bei CrewAI durch die deklarative Trennung von Aufgaben und Agenten zum Ausdruck kommt.

Wenn der Code interaktiv ausgeführt wird, wobei das Skript fragt, um welche Art von Spiel es geht und wie es sich verhalten soll, ist er in der Regel deutlich ausgereifter als bei einer einzelnen, unüberwachten Programmierkraft. Ein Grund dafür ist, dass die Überwachung durch den leitenden QA-Ingenieur Probleme aufdeckt, die sonst unentdeckt bleiben könnten.

Sequenzielle versus hierarchische Verarbeitung

CrewAI bietet zwei Möglichkeiten, die Arbeitsweise einer Crew bei der Erledigung von Aufgaben zu organisieren, und die richtige Wahl ist wichtig.

Sequenzielle Verarbeitung ist die Standardmethode und zugleich die einfachste. Die Aufgaben werden in der definierten Reihenfolge nacheinander ausgeführt, wobei jede KI erst fertig wird, bevor sie die Aufgabe weitergibt. Sie eignet sich für Workflows, bei denen die Schritte tatsächlich in einer festen Reihenfolge voneinander abhängen: zunächst Forschung, dann Schreiben, oder zunächst Implementierung, anschließend Überprüfung und schließlich Abschluss.

Hierarchische Verarbeitung setzt einen Manager über das Team, in der Regel eine eigene LLM-Verbindung, die ausschließlich zur Koordination verwendet wird und die Agenten sowie Aufgaben überwacht, anstatt ihnen eine starre Abfolge aufzuzwingen. Der Wechsel ist einfach: Geben Sie Process.hierarchical anstelle von Process.sequential an und spezifizieren Sie einen manager_llm – in der Regel eine ChatOpenAI-Instanz mit einer Temperatur von null für stabile Überwachungsentscheidungen.

Ursprünglich sollte der hierarchische Modus gewinnen, da eine Managerrolle die Funktionsweise größerer menschlicher Organisationen widerspiegelt. Die Experimente zeigen jedoch das Gegenteil. Laut AgentOps kostete derselbe Spielauftrag unter der Leitung eines hierarchischen Managers mehr als doppelt so viel, und der Code war dadurch nicht signifikant besser. Das ist ein ernüchternder Datensatz. Die Hinzufügung von Koordination, Überwachung sowie zusätzlichen Agentenschichten verbessert die Ergebnisse nicht automatisch – Multi-Agentensysteme können genauso leicht in teure, unproduktive Schleifen geraten, wenn niemand genau hinschaut.

Ausbrechende Agenten stoppen

Diese Erkenntnis weist auf einen subtilen Fehlermechanismus hin: wiederholte Denkmuster. Ein Agent, der kein Vertrauen in seine eigenen Ergebnisse hat, kann statt Entscheidungen zu treffen und weiterzumachen immer wieder dieselben Ideen variiert durchgehen, wodurch Token und Geld verschwendet werden, ohne dass es zu echtem Fortschritt kommt.

AgentOps verfügt über eine Visualisierung namens „Repeat Thoughts“, die genau dafür dient, darzustellen, wie oft das Denken eines Agenten während einer Ausführung auf ähnlichen Inhalten zurückkehrt. Starke Wiederholungen sind ein Zeichen dafür, dass sich etwas Strukturelles ändern muss. Vielleicht sind die Aufgabenbeschreibungen zu unklar, vielleicht sind für die Komplexität des Problems zu viele Agenten beteiligt, oder vielleicht sollte der Verarbeitungsmodus genauer überdacht werden. Solche Diagnosewerkzeuge unterscheiden zwischen zufälligem Experimentieren und diszipliniertem, produktionsreifem Arbeiten. Es ist besser, frühzeitig zu erkennen, wenn etwas schiefgeht, anstatt auf eine auffällig hohe Rechnung warten zu müssen.

Kommunikationsstile nebeneinander

Die zu Beginn gestellte Frage, wie Agenten Informationen weitergeben, hat nun konkrete Antworten. AutoGen bietet zwei Modelle. Eingebettete Chats übermitteln Material durch Nebengespräche, was den Hauptverlauf übersichtlich hält, aber das Risiko birgt, bei jeder Übertragung Details zu verlieren. Gruppenchats stellen allen die vollständige Historie zur Verfügung, was die Kohärenz verbessert, jedoch auf Kosten von Tokens. CrewAI umgeht diese Wahl, indem es die Übertragung explizit macht: Jede Aufgabe gibt ihren Agenten sowie die erwartete Ausgabe an, und die Prozesseinstellungen entscheiden, ob die Ergebnisse weitergereicht oder über einen Manager weitergeleitet werden. Der eine Ansatz fördert eine emergente Zusammenarbeit, der andere einen vorhersehbaren Ablauf.

Keines der beiden Lösungen beseitigt die Notwendigkeit, die Rechnung im Auge zu behalten. Beide erzeugen mehr Modellaufrufe als eine einzelne Anfrage, und beide können in Schleifen geraten. Deshalb ist die Überwachungsfunktion genauso wichtig wie die Wahl des Frameworks.

Wahl zwischen den beiden

Keines der Frameworks ist eindeutig überlegen. Jedes spiegelt eine andere Auffassung darüber wider, wie viel Struktur ein Mehr-Agentensystem haben sollte. AutoGen lässt die Struktur aus dem Gespräch selbst entstehen, während CrewAI vom Entwickler verlangt, diese im Voraus festzulegen.

AutoGen eignet sich, wenn:

• maximale Flexibilität gewünscht ist und die Agenten ihren Ansatz durch offenen Dialog improvisieren können;
• die Aufgabe von explorativem Hin- und Herüberlegen profitiert, wie bei Brainstorming oder iterativem Debuggen, wobei die richtige Reihenfolge der Schritte im Voraus unbekannt ist;
• ein zugänglicher visueller Einstiegspunkt wie AutoGen Studio für nicht-technische Experimente vor dem Umsetzen in Code nützlich ist.

CrewAI eignet sich, wenn:

• vorhersehbare, überprüfbare Workflows mit klaren Rollen und Verantwortlichkeiten benötigt werden, wie in Unternehmensworkflows, wo Konsistenz der Improvisation Vorrang hat;
• Integrierte Speicherlösungen, Caching-Funktionen sowie Rate-Limiting-Mechanismen werden den selbst entwickelten Versionen vorgezogen;
• Angesichts der nahezu reibungslosen Integration von AgentOps ist eine erstklassige Überwachbarkeit von großer Bedeutung.

In der Praxis beziehen viele reale Projekte Vorteile aus beidem: Die deklarative Klarheit von CrewAI für die gut verstandenen Teile eines Pipelines sowie die konversationelle Flexibilität von AutoGen für die komplexeren, explorativen Bereiche.