KI-Agenten-Frameworks im Vergleich: das richtige Framework für den Mittelstand

Es gibt inzwischen viele Agenten-Frameworks, und ihre Funktionslisten gleichen sich immer mehr: Werkzeugaufrufe, Gedächtnis, mehrere Agenten, Tracing. Für eine IT-Leitung im Mittelstand ist deshalb nicht die Frage, welches Framework am meisten kann, sondern welches zu Team, Systemlandschaft und Datenschutzanforderungen passt. Dieser Überblick ordnet die verbreiteten Kandidaten entlang von fünf Entscheidungskriterien ein. Stand der Angaben: Oktober 2026, geprüft an der jeweiligen Hersteller-Dokumentation.

Was ist ein KI-Agenten-Framework und wofür brauchen Sie es?

Ein Agenten-Framework ist eine Programmbibliothek, die die wiederkehrende Mechanik eines KI-Agenten übernimmt: das Sprachmodell aufrufen, Werkzeuge ausführen, Ergebnisse zurückgeben, Zustand halten und den Ablauf steuern. Sie brauchen es, sobald ein Agent mehr tut als eine einzelne Frage zu beantworten, etwa ein Angebot aus mehreren Systemen zusammenstellen oder ein Ticket über mehrere Schritte bearbeiten.

Ohne Framework schreiben Sie diese Schleife selbst: Modell fragt nach einem Werkzeug, Ihr Code führt es aus, das Ergebnis geht zurück an das Modell, bis die Aufgabe erledigt ist. Das ist für einfache Fälle machbar und manchmal die bessere Wahl. Die Microsoft-Dokumentation formuliert es selbst so: Wenn sich eine Aufgabe mit einer gewöhnlichen Funktion lösen lässt, sollten Sie lieber die Funktion schreiben statt einen Agenten einzusetzen. Schwierig wird es bei den Dingen, die in der Praxis immer dazukommen: Ein Lauf bricht nach zehn Minuten ab und soll an derselben Stelle weitermachen. Ein Mensch muss vor dem Versand freigeben. Zwei Agenten teilen sich Arbeit. Jemand will nachvollziehen, warum der Agent eine bestimmte Entscheidung getroffen hat. Genau dafür liefern Frameworks fertige Bausteine.

Wer Agenten für konkrete Abteilungen plant, findet die fachliche Seite unter KI-Agenten für Angebot, Service, Wissen und Vertrieb. Dieser Artikel behandelt die technische Grundentscheidung darunter.

Wie funktioniert ein Agenten-Framework? Die Bausteine

Fast jedes Framework besteht aus denselben fünf Bausteinen: einer Modellanbindung, einer Werkzeugschicht, einer Ablaufsteuerung, einem Zustandsspeicher und einer Beobachtungsschicht. Die Unterschiede liegen weniger darin, ob ein Baustein existiert, sondern darin, wie viel davon das Framework vorgibt und wie viel Sie selbst entscheiden.

Modellanbindung. Ein Adapter übersetzt zwischen Ihrem Code und der Programmierschnittstelle eines Modellanbieters. Manche Frameworks sind eng an einen Anbieter gebunden, andere bieten Adapter für viele Anbieter und für lokal betriebene Modelle.

Werkzeuge. Funktionen, die der Agent aufrufen darf: Datenbankabfrage, ERP-Lookup, Dateizugriff, E-Mail-Entwurf. Ein wachsender gemeinsamer Nenner ist das Model Context Protocol (MCP), ein offener Standard, um KI-Anwendungen mit externen Systemen zu verbinden. Werkzeuge, die Sie als MCP-Server bauen, lassen sich von mehreren Frameworks nutzen.

Ablaufsteuerung. Hier unterscheiden sich die Frameworks am stärksten. Am einen Ende steht ein expliziter Graph, in dem Sie jeden Schritt und jeden Übergang festlegen. Am anderen Ende steht eine offene Agentenschleife, in der das Modell selbst entscheidet, welches Werkzeug es als Nächstes nutzt.

Zustand und Gedächtnis. Gesprächsverlauf, Zwischenergebnisse, Checkpoints für die Wiederaufnahme nach einem Abbruch und gegebenenfalls ein Langzeitgedächtnis über mehrere Sitzungen.

Beobachtung. Tracing jedes Modellaufrufs und jedes Werkzeugaufrufs. Ohne diese Schicht können Sie Fehler im Betrieb kaum nachvollziehen. Wichtig für den Datenschutz: Prüfen Sie, wohin das Tracing seine Daten schickt.

Wie diese Bausteine in einer Gesamtarchitektur zusammenspielen, inklusive Abruf aus Dokumenten und Rechtesystem, ist ein eigenes Thema; hier geht es um die Wahl der Bibliothek.

Welche Frameworks kommen in Frage? Die Kandidaten im Überblick

Für den Mittelstand sind im Oktober 2026 sechs Kandidaten relevant: LangGraph, CrewAI, das Claude Agent SDK, das OpenAI Agents SDK, das Microsoft Agent Framework und das Google Agent Development Kit (ADK). Sie unterscheiden sich vor allem in Steuerungsphilosophie, Programmiersprache und Modellbindung, weniger im Funktionsumfang.

LangGraph beschreibt sich als Orchestrierungs-Framework und Laufzeit auf niedriger Ebene für langlaufende, zustandsbehaftete Agenten. Schwerpunkte laut Doku sind dauerhafte Ausführung mit Wiederaufnahme nach Fehlern, menschliche Eingriffe in den Zustand, Kurz- und Langzeitgedächtnis und das Mischen deterministischer Schritte mit Modellschritten im selben Graphen. LangChain wird dafür nicht benötigt. Neben Python gibt es LangGraph.js; lokale Modelle lassen sich etwa über das Paket langchain-ollama anbinden.

CrewAI ist ein eigenständiges Python-Framework unter MIT-Lizenz mit eigenen Grundbausteinen. Die Doku trennt Flows, die Ablauf und Zustand festlegen, von Crews, also Teams autonomer Agenten, an die ein Flow-Schritt Arbeit delegiert. Modelle von OpenAI, Anthropic und Google sind direkt angebunden, alle weiteren einschließlich Ollama laufen über LiteLLM.

Das Claude Agent SDK stellt laut Anthropic dieselben Werkzeuge, dieselbe Agentenschleife und dasselbe Kontextmanagement bereit, auf denen Claude Code läuft, programmierbar in Python und TypeScript. Eingebaut sind Datei- und Shell-Werkzeuge, Hooks, Subagenten, MCP, Berechtigungen und Sitzungen. Als Anbieter nennt die Schnellstart-Anleitung die Anthropic-API, Amazon Bedrock, Claude Platform on AWS, Google Cloud und Microsoft Foundry.

Das OpenAI Agents SDK versteht sich als schlankes Paket mit sehr wenigen Abstraktionen: Agenten, Übergaben zwischen Agenten, Guardrails, Sitzungen und Tracing. Es ist Python-zuerst, eine JS/TS-Variante existiert. Andere Anbieter lassen sich über OpenAI-kompatible Endpunkte oder die als Beta gekennzeichneten Adapter für LiteLLM und Any-LLM einbinden.

Das Microsoft Agent Framework ist nach eigener Darstellung der direkte Nachfolger von Semantic Kernel und AutoGen, entwickelt von denselben Teams. Es verbindet Agenten mit graphbasierten Workflows und nennt als Modellanbieter unter anderem Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic und Ollama. Die Go-Variante ist laut Doku noch in der öffentlichen Vorschau.

Google ADK ist laut Repository für Gemini optimiert, aber modell- und bereitstellungsunabhängig. Die Doku nennt fünf Sprachen, Adapter auch für lokal laufende Modelle und den Betrieb auf eigener Infrastruktur oder in Google Cloud.

Den direkten Detailvergleich der vier meistgenannten Kandidaten und eine kompakte Auswahl-Checkliste behandeln eigene Artikel dieses Themenbereichs.

Nach welchen Kriterien entscheiden Sie? Die Entscheidungsmatrix

Entscheiden Sie entlang von fünf Kriterien in fester Reihenfolge: Team-Sprache, Kontrollbedarf, Modellbindung, Betrieb im eigenen Haus und Lebenszyklus. Die ersten beiden schließen meist schon die Hälfte der Kandidaten aus. Funktionslisten helfen dagegen kaum, weil die Frameworks sich dort angeglichen haben.

1. Welche Sprache spricht Ihr Team?

Ein Framework, das Ihr Team nicht in seiner Hauptsprache betreiben kann, wird im Alltag zum Fremdkörper. Arbeitet Ihre Entwicklung überwiegend in C# und .NET, ist das Microsoft Agent Framework der naheliegende Startpunkt, weil es .NET als gleichwertige Sprache behandelt. Für Java- oder Kotlin-Häuser bietet Google ADK native Unterstützung. Reine TypeScript-Teams haben mit LangGraph.js, dem Claude Agent SDK, dem OpenAI Agents SDK in der JS/TS-Variante und ADK mehrere Optionen. Python ist überall abgedeckt; CrewAI ist ein reines Python-Framework.

2. Wie viel Kontrolle brauchen Sie über den Ablauf?

Das ist das wichtigste fachliche Kriterium. Ein Prozess wie „Anfrage prüfen, Preise aus dem ERP holen, Angebot entwerfen, Vertrieb gibt frei, Versand" hat feste Schritte und Prüfpunkte. Hier wollen Sie einen expliziten Ablauf, in dem das Modell nur innerhalb einzelner Schritte entscheidet. Dafür sind LangGraph, die Workflows im Microsoft Agent Framework und die Flows in CrewAI gebaut.

Eine offene Rechercheaufgabe dagegen, etwa „finde in Handbüchern, Tickets und Wartungsprotokollen die wahrscheinliche Ursache", profitiert von einer Agentenschleife, die selbst entscheidet, welche Quelle sie als Nächstes liest. Hier spielt das Claude Agent SDK seine Stärke aus, weil es eine erprobte Schleife mit Datei-, Such- und Shell-Werkzeugen sowie einem Berechtigungssystem mitbringt. Viele reale Systeme kombinieren beides: ein fester Ablauf außen, eine offene Schleife in einem einzelnen Schritt.

3. Wie stark darf das Framework Sie an einen Modellanbieter binden?

Modellbindung ist kein Makel, sondern eine bewusste Abwägung. Ein eng gekoppeltes Framework nutzt die Fähigkeiten eines Modells oft vollständiger und hat weniger Übersetzungsschichten. Ein offenes Framework erlaubt den Wechsel, wenn sich Preise, Verfügbarkeit oder Qualität verschieben.

Das Claude Agent SDK ist bewusst auf Claude ausgelegt. Das OpenAI Agents SDK nutzt standardmäßig die OpenAI-Schnittstelle und erreicht andere Modelle über Kompatibilitätsschichten, deren Funktionsumfang laut Doku je nach Anbieter variieren kann. LangGraph, CrewAI, das Microsoft Agent Framework und ADK sind von vornherein auf mehrere Anbieter ausgelegt. Prüfen Sie bei offenen Frameworks trotzdem, ob Werkzeugaufrufe, strukturierte Ausgaben und Streaming mit genau dem Modell funktionieren, das Sie betreiben wollen.

4. Muss alles im eigenen Haus laufen?

Alle sechs Frameworks sind Bibliotheken, die in Ihrem eigenen Prozess laufen. Die Frage nach dem Betrieb im eigenen Rechenzentrum ist deshalb eigentlich eine Frage nach dem Modell und nach dem Tracing-Ziel. Wenn Daten das Haus nicht verlassen dürfen, brauchen Sie ein lokal betriebenes Modell, und das Framework muss es ansprechen können.

LangGraph, CrewAI, das Microsoft Agent Framework und ADK nennen lokale Modelle in ihrer Doku ausdrücklich, das OpenAI Agents SDK erreicht sie über OpenAI-kompatible Endpunkte. Das Claude Agent SDK läuft zwar in Ihrem Prozess, spricht aber Claude-Modelle bei Anthropic oder bei einer der genannten Cloud-Plattformen an; für einen vollständig abgeschotteten Betrieb ist es daher nicht vorgesehen. Wie ein souveräner Betrieb mit eigener Hardware insgesamt aussieht, beschreibt die Seite zu souveräner KI im eigenen Haus.

Prüfen Sie außerdem die Beobachtungsschicht: Manche Frameworks verweisen für Tracing auf gehostete Dienste. Für sensible Daten sollte das Tracing in eine selbst betriebene Lösung schreiben oder abschaltbar sein.

5. Wie sieht der Lebenszyklus aus?

Agenten-Frameworks entwickeln sich schnell, Schnittstellen ändern sich zwischen Versionen. Für ein System, das Sie drei Jahre betreiben wollen, zählt deshalb, wer hinter dem Projekt steht, wie Migrationen dokumentiert werden und wie gut sich Ihr Code vom Framework trennen lässt.

Ein Beispiel für einen solchen Bruch: Microsoft hat Semantic Kernel und AutoGen in das Agent Framework überführt und bietet Migrationsleitfäden für beide an. Das ist sauber gelöst, zeigt aber, dass auch Frameworks großer Hersteller nicht unverändert bleiben. Achten Sie auf veröffentlichte Changelogs, auf die Lizenz (MIT und Apache 2.0 erlauben Weiterbetrieb und Anpassung auch dann, wenn der Hersteller ein Projekt aufgibt) und darauf, dass Ihre Werkzeuge über MCP oder schlanke eigene Schnittstellen angebunden sind statt tief in Framework-Klassen.

Welche Voraussetzungen müssen vor der Framework-Wahl stehen?

Bevor Sie ein Framework wählen, sollten drei Dinge geklärt sein: ein konkreter Prozess mit messbarem Ergebnis, ein Zugang zu den Daten, die der Agent braucht, und eine Person, die den Agenten später fachlich verantwortet. Ohne diese drei Punkte wird die Framework-Wahl zur Technikdiskussion ohne Entscheidungsgrundlage.

Prozess. Beschreiben Sie einen Ablauf so genau, dass ein neuer Mitarbeiter ihn mit Ihrer Beschreibung ausführen könnte: Eingangsdokument, Schritte, Systeme, Freigaben, Ausgabe. An dieser Beschreibung lesen Sie den Kontrollbedarf ab.

Daten und Systeme. Welche Systeme muss der Agent lesen oder schreiben, und gibt es dafür Schnittstellen? Ein ERP ohne Programmierschnittstelle ist ein größeres Hindernis als jede Framework-Frage.

Datenschutz und Mitbestimmung. Klären Sie früh mit Datenschutzbeauftragtem und gegebenenfalls Betriebsrat, welche Daten der Agent sehen darf und wo das Modell laufen muss. Diese Antwort entscheidet Kriterium 4. Die Hinweise hier sind eine technische Orientierung und keine Rechtsberatung.

Team. Wer schreibt und wartet den Code? Ein Framework in einer Sprache, die nur eine Person im Haus beherrscht, ist ein Betriebsrisiko.

Wie gehen Sie bei der Auswahl Schritt für Schritt vor?

Gehen Sie in fünf Schritten vor: Kriterien gewichten, auf zwei Kandidaten eingrenzen, denselben kleinen Prototyp mit beiden bauen, gegen feste Testfälle messen, dann entscheiden. Ein solcher Doppel-Prototyp kostet einige Tage, verhindert aber, dass Sie eine Entscheidung auf Basis von Marketingseiten treffen.

1. Kriterien gewichten. Legen Sie fest, welches der fünf Kriterien bei Ihnen ein Ausschlusskriterium ist. Häufig sind das Sprache und Betrieb im eigenen Haus.
2. Auf zwei Kandidaten eingrenzen. Mehr als zwei parallel zu prüfen, verwässert den Vergleich.
3. Gleichen Prototyp bauen. Ein echter, kleiner Prozessausschnitt, etwa eine Kundenanfrage lesen, zwei Werkzeuge aufrufen und einen Antwortentwurf erzeugen. Die Werkzeuge bauen Sie einmal, möglichst als MCP-Server, und nutzen sie in beiden Kandidaten.
4. Gegen Testfälle messen. Zwanzig bis dreißig reale, anonymisierte Beispiele mit erwarteter Ausgabe. Achten Sie auf Fehlerverhalten, Nachvollziehbarkeit im Tracing und darauf, wie viel eigener Code nötig war.
5. Entscheiden und dokumentieren. Halten Sie fest, warum Sie sich entschieden haben und welche Version Sie geprüft haben. Diese Notiz ist bei der nächsten Neubewertung Gold wert.

In unserem eigenen Betrieb hat sich bewährt, die Werkzeugschicht strikt vom Framework zu trennen. Dann ist die Framework-Wahl eine Entscheidung, die sich revidieren lässt, und keine Festlegung auf Jahre. Wer diese Grundentscheidung zusammen mit Prozessauswahl und Rollen strukturiert angehen will, findet unter KI-Aufbau im Unternehmen den organisatorischen Rahmen dazu.

Wo liegen Grenzen und Risiken?

Das größte Risiko ist nicht die falsche Framework-Wahl, sondern ein Agent ohne klare Grenzen: zu viele Werkzeuge, zu weite Berechtigungen, keine Tests. Dazu kommen schnelle Versionswechsel der Frameworks und eine Abhängigkeit von gehosteten Zusatzdiensten, die beim ersten Prototyp nicht auffällt.

Abstraktion versteckt Verhalten. Je mehr ein Framework vorgibt, desto schwerer ist im Fehlerfall zu erkennen, welcher Prompt tatsächlich an das Modell ging. Prüfen Sie im Prototyp, ob Sie den vollständigen Modellaufruf im Tracing sehen.

Schnelle Versionsfolge. Pinnen Sie Versionen fest und planen Sie Aktualisierungen bewusst ein, statt automatisch die neueste Version zu ziehen.

Kompatibilitätsschichten. Adapter für fremde Modelle decken nicht immer jede Funktion ab. Das OpenAI Agents SDK weist selbst darauf hin, dass der Funktionsumfang über Adapter je nach Anbieter schwanken kann. Testen Sie genau die Kombination aus Framework und Modell, die Sie betreiben.

Zu viel Autonomie. Eine offene Agentenschleife mit Schreibrechten auf Produktivsysteme ist ein Sicherheitsrisiko. Nutzen Sie Berechtigungssysteme und Freigabeschritte, die die Frameworks anbieten, und beginnen Sie mit Lesezugriff.

Multi-Agenten ohne Grund. Mehrere zusammenarbeitende Agenten sind reizvoll, erhöhen aber Kosten, Latenz und Fehlersuche. Ein einzelner Agent mit gut geschnittenen Werkzeugen reicht für viele Prozesse.

Wann passt keines davon? Wenn Ihr Prozess vollständig regelbasiert ist und das Modell nur einen Text zusammenfasst, brauchen Sie kein Agenten-Framework. Ein Modellaufruf aus Ihrem bestehenden Code genügt.

Wie fangen Sie an?

Beginnen Sie mit einem Prozess, nicht mit einem Framework. Wählen Sie einen Ablauf mit klarer Ein- und Ausgabe, beantworten Sie für ihn die fünf Kriterien und bauen Sie mit den zwei verbleibenden Kandidaten denselben kleinen Prototyp. Die Entscheidung fällt danach meist eindeutig aus.

Eine einfache Faustregel als Ausgangspunkt, nicht als Urteil:

• .NET-Team, Microsoft-Umgebung, Azure: Microsoft Agent Framework prüfen.
• Fester Prozess mit Freigaben und Wiederaufnahme, Python oder TypeScript: LangGraph prüfen.
• Python-Team, das schnell mit Agenten-Teams experimentieren will: CrewAI prüfen.
• Offene Arbeitsaufgaben auf Dateien, Dokumenten und Code, Claude als gesetztes Modell: Claude Agent SDK prüfen.
• OpenAI-Modelle als Standard, schlanke Abstraktion gewünscht: OpenAI Agents SDK prüfen.
• Java- oder Kotlin-Team, Google Cloud oder Gemini im Einsatz: Google ADK prüfen.

Müssen Daten das Haus nicht verlassen, streichen Sie zuerst alle Kandidaten, die Ihr lokales Modell nicht ansprechen können, und wenden Sie die Faustregel danach an. Wenn Sie wissen wollen, welche Agenten-Typen sich für einzelne Abteilungen typischerweise lohnen, ist die Übersicht zu Agenten für Angebotserstellung ein guter konkreter Einstieg.