AG2 v1.0: Protokollrahmen statt Chat-Muster

Was v1.0 vom AutoGen-Erbe trennt

Bis Version 0.x war AG2 das, was viele unter AutoGen verstehen: ConversableAgent, GroupChat, UserProxyAgent, register_function. Mit v1.0 zieht das Projekt eine Grenze. Der README formuliert es als Hinweis in eigener Sache: Wer ConversableAgent, GroupChat oder import autogen sucht, landet jetzt bei AG2 Classic. Das klassische Framework liegt im Repository ag2ai/ag2-classic und wird unter classic.docs.ag2.ai dokumentiert. Es wird weiter gepflegt und bleibt installierbar. Das Paket ag2 ab v1.0 liefert den Namen autogen und die klassischen Agent-Klassen nicht mehr mit. Das ist keine Umbenennung, sondern ein Schnitt durch die öffentliche API. Für Teams, die AG2 nur als Werkzeugkasten für Chat-Schleifen zwischen Rollen einsetzen, ändert sich damit die Adresse ihres Codes. Für alle anderen ist die Frage interessanter, was an die Stelle von GroupChat tritt.

Das Netzwerk: Hub und Channels statt Gruppenchat

In der Vergleichstabelle des README stehen sich zwei Modelle gegenüber. AG2 Classic orchestriert über GroupChat, Swarms und verschachtelte Chats. AG2 v1.0 orchestriert über ein Network, beschrieben als hub plus channels, dokumentiert unter docs.ag2.ai/docs/user-guide/network/overview/. Die zentrale Agent-Klasse heißt nicht mehr ConversableAgent, sondern Agent. Der README verweist für den Übergang ausdrücklich auf einen eigenen Migrationsleitfaden, der unter docs.ag2.ai/docs/user-guide/network/migration_from_group_chat/ liegt. Aus dem Material geht hervor, dass sich das Agent-Modell, die Orchestrierung und die Imports gemeinsam geändert haben. Wie ein Channel konkret adressiert wird, welche Nachrichtenformate zwischen Hub und Teilnehmern laufen und ob Channels außerhalb des Prozesses liegen können, lässt sich aus dem vorliegenden README nicht ableiten. Wer das wissen muss, kommt um die Netzwerk-Dokumentation nicht herum. Die Richtung ist dennoch erkennbar: weg von einem Gesprächsobjekt, das die Teilnehmerliste hält, hin zu einer Vermittlungsschicht, die Verbindungen verwaltet.

Der Agent-Harness: Wissen und Kompaktierung

Ein eigener Abschnitt der README-Übersicht trägt den Titel The agent harness: knowledge and compaction. Das ist der Teil, den man bei einem Framework leicht übersieht, weil er nicht in der ersten Codezeile auftaucht. Ein Harness ist die Schicht um das Modell herum: was der Agent an Kontext mitführt, wie dieses Wissen abgelegt wird und wie es verdichtet wird, wenn es zu lang wird. Kompaktierung ist dabei kein Komfortmerkmal, sondern eine Notwendigkeit, sobald Gespräche länger laufen als das Kontextfenster des gewählten Modells. Wer selbst schon Kontextverwaltung von Hand gebaut hat, weiß, wie viel Code dort verschwindet. Der README nennt den Harness als eigenen Baustein, liefert aber an dieser Stelle keine Details zu Speicherformaten, Triggern oder Grenzwerten. Ob die Kompaktierung regelbasiert oder modellgestützt arbeitet, bleibt offen. Das ist eine der Stellen, an denen die README dünn ist und die Dokumentation die eigentliche Arbeit machen muss.

Installation, Provider-Extras und API-Keys

AG2 verlangt Python >= 3.10. Die Installation erfolgt über Extras, die zum Modellprovider passen. Der README gibt für Windows und Linux pip install ag2[openai] an, für macOS die Variante pip install 'ag2[openai]' mit Anführungszeichen, weil die eckigen Klammern in der Shell sonst als Muster interpretiert werden können. Standardmäßig werden nur minimale Abhängigkeiten installiert. Weitere Extras sind ag2[anthropic], ag2[gemini], ag2[ollama] und laut Formulierung weitere dieser Art. Die API-Keys kommen aus Umgebungsvariablen, etwa export OPENAI_API_KEY="<your-api-key>", alternativ ANTHROPIC_API_KEY, GEMINI_API_KEY und so weiter. Wer keinen globalen Key setzen will, kann ihn laut README explizit übergeben, mit OpenAIConfig(model="gpt-4o-mini", api_key=...) als Beispiel. Das ist der Fall, in dem jede Anfrage ihren eigenen Schlüssel mitbringt. Der README weist außerdem darauf hin, dass AG2 durchgehend asynchron ist. Der Satz bricht im vorliegenden Material mitten im Wort ab, sodass die konkrete Signatur des Einstiegs nicht belegt ist. Wer den ersten Agenten schreiben will, sollte dafür den Quick Start unter docs.ag2.ai/docs/user-guide/quick-start/ verwenden statt zu raten.

Der harte Schnitt ist die eigentliche Einschränkung

Der README sagt es selbst und ohne Beschönigung: AG2 v1.0 ist kein Drop-in-Upgrade von Classic. Damit ist der wichtigste Vorbehalt bereits im Projekt dokumentiert. Ein Upgrade bedeutet, Imports, Agent-Modell und Orchestrierung gleichzeitig anzufassen. In einem gewachsenen System mit mehreren Agenten, eigenen Tools und angepassten Chat-Mustern ist das kein Nachmittag Arbeit, sondern ein eigenes Vorhaben. Dazu kommt die Versionierung: Zwischen v1.0.2, v1.0.3 und v1.0.4 liegen jeweils nur Tage bis wenige Wochen. Diese Kadenz spricht für Bewegung, bedeutet aber auch, dass die API in der frühen 1.x-Phase noch in Bewegung sein kann. Wer auf Stabilität über Monate angewiesen ist, sollte die Release Notes vor jedem Minor-Sprung lesen und die Version pinnen. Und wer schlicht eine Chat-Schleife zwischen zwei Rollen braucht, für den ist der gesamte Netzwerk-Apparat überdimensioniert. Der klassische GroupChat bleibt dafür die einfachere Wahl, nur eben in einem anderen Repository.

Was AG2 Classic als Alternative bedeutet

Die naheliegende Alternative ist kein anderes Projekt, sondern der Vorgänger im eigenen Haus. Wer heute import autogen, ConversableAgent, AssistantAgent, UserProxyAgent oder GroupChat im Code hat, bleibt laut README auf Classic und installiert statt ag2>=1.0 das Paket ag2-classic. Der Unterschied ist nicht kosmetisch: Classic hält einen Gesprächsverlauf mit Teilnehmerliste und Manager, v1.0 vermittelt über Hub und Channels. Wer verschachtelte Chats oder Swarms einsetzt, findet für diese Muster im neuen Modell keine Eins-zu-eins-Entsprechung, sondern muss den Migrationsleitfaden durcharbeiten. Der Preis für den Verbleib ist ein zweites Repository und eine zweite Dokumentationsseite, die man getrennt verfolgen muss. Dafür bleibt der Code unverändert lauffähig. Wer dagegen neu anfängt und die Netzwerk-Idee ohnehin braucht, hat keinen Grund, mit dem alten Modell zu starten.

Wartung, Lizenz und was das für den Betrieb heißt

AG2 steht unter Apache-2.0, demselben Lizenztyp, unter dem das Projekt bereits vor der Umbenennung veröffentlicht wurde. Für die meisten kommerziellen Einsätze ist das eine unkomplizierte Ausgangslage, weil die Lizenz Nutzung, Veränderung und Weitergabe erlaubt und eine Patentgewährung enthält. Rechtsverbindlich ist der Lizenztext, nicht diese Einordnung. Ein Punkt, der bei Apache-2.0 regelmäßig übersehen wird: Der Abschnitt zur Namensnutzung erlaubt keine Verwendung der Projektmarken ohne Erlaubnis. Wer ein Produkt auf AG2 aufsetzt, sollte den Namen nicht als eigenen Markenbestandteil führen. Auf der Wartungsseite nennt der README ein Team aus Freiwilligen aus mehreren Organisationen, mit Kontakt über support@ag2.ai für alle, die Maintainer werden wollen. Ein Freiwilligenteam ist keine Schwäche per se, aber es bedeutet, dass Support-Zusagen und Reaktionszeiten nicht vertraglich garantiert sind. Wer AG2 in einem System mit Verfügbarkeitsanforderungen einsetzt, sollte die Release-Kadenz selbst beobachten und die eingesetzte Version pinnen, statt automatisch zu aktualisieren.

Redaktionelles Fazit

Neue Projekte, die Python >= 3.10 einsetzen und bereit sind, sich auf das Netzwerk-Modell mit Hub und Channels einzulassen, finden in AG2 v1.0 ein Paket mit aktiver Release-Kadenz und klarer Trennung vom Altbestand. Wer bestehenden Code mit ConversableAgent, GroupChat oder import autogen betreibt, sollte nicht auf ag2>=1.0 wechseln, sondern ag2-classic gepinnt lassen. Vor jedem Umstieg zuerst prüfen, ob der eigene Code die klassischen Imports enthält, ob das Netzwerk-Modell die eigenen Orchestrierungsmuster abbildet, und ob die Provider-Extras für das eingesetzte Modell existieren. Erst danach installieren.

Offizielle Quellen

1. ag2ai/ag2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases