Lösungen für
Bitte auswählen
Web-App testen
ki-werkzeuge

Agenten-Frameworks im Überblick

Redaktion ·

Du willst einen Agenten bauen — und ertrinkst in Framework-Namen

Wer 2026 ein agentisches System bauen will, steht vor einem überfüllten Regal: CrewAI, AutoGen, AutoGPT, DSPy, Browser Use, LangGraph — dazu die SDKs der Modellanbieter (OpenAI Agents SDK, Google ADK, Claude Agent SDK) und ein gutes Dutzend kleinerer Projekte. Die Versuchung ist groß, sich am lautesten Namen festzuhalten und loszulegen. Das rächt sich, weil diese Werkzeuge gar nicht alle dasselbe Problem lösen. Manche orchestrieren mehrere Agenten, eines optimiert Prompts, eines steuert einen Browser, eines ist eher ein Demo-Projekt als ein Produktivframework.

Dieser Artikel sortiert das Feld. Du lernst, was ein Agenten-Framework überhaupt tut, wie es sich von „Tool Use” und von einem fertigen Agenten abgrenzt, und du bekommst zu jedem der sechs genannten Werkzeuge eine ehrliche Einordnung: was es leistet, wie reif es ist, wann du es nimmst. Wenn du davor noch wissen willst, wie ein Agent intern funktioniert, lies zuerst KI-Agenten bauen — hier setzen wir die Mechanik (Agent-Loop, Tool-Call, Stop-Bedingung) als bekannt voraus.

Drei Ebenen sauber trennen: Tool Use, Agent, Framework

Bevor wir vergleichen, müssen drei Begriffe auseinander, die ständig vermischt werden.

Tool Use ist der Mechanismus

Tool Use (auch Function Calling) ist die Fähigkeit eines Modells, strukturiert ein externes Werkzeug aufzurufen. Du beschreibst dem Modell ein Tool als JSON-Schema, das Modell antwortet mit einem Tool-Call samt Argumenten, dein Code führt aus und reicht das Ergebnis zurück. Das ist eine Funktion der LLM-API, kein Framework. Tool Use ist die Zutat, aus der Agenten gebaut werden — aber für sich allein noch kein Agent.

Der Agent ist das laufende System

Ein Agent entscheidet zur Laufzeit selbst, welche Tools er wann aufruft, wie oft die Schleife dreht und wann er fertig ist. Der Unterschied zur deterministischen Workflow ist die Kontrolllogik: Beim Workflow legt dein Code die Reihenfolge fest, beim Agenten trifft das Modell die Steuerungsentscheidungen. Ein Agent ist also das konkrete laufende Ding — nicht der Werkzeugkasten, mit dem du es gebaut hast.

Das Framework ist der Werkzeugkasten

Ein Agenten-Framework ist eine Bibliothek, die dir die wiederkehrende Klempnerei abnimmt: den Agent-Loop, die Tool-Registrierung, das Gedächtnis (Konversationshistorie, ggf. Vektorspeicher), die Koordination mehrerer Agenten und oft Observability. Du könntest all das selbst schreiben — bei einem einzelnen Agenten mit drei Tools ist das sogar oft die bessere Wahl. Sobald aber mehrere Agenten zusammenarbeiten, der Zustand persistiert werden muss oder ein Mensch in die Schleife eingreifen soll, wird Eigenbau teuer, und ein Framework rechnet sich.

Was ein Agenten-Framework konkret leistet

Quer durch die Projekte tauchen dieselben vier Aufgabenbereiche auf. An ihnen lassen sich die Frameworks unterscheiden.

Orchestrierung. Die Steuerung des Agent-Loops und — bei mehreren Agenten — wer wann dran ist. Hier liegen die größten Unterschiede: von freier Konversation zwischen Agenten (AutoGen) über rollenbasierte Teams (CrewAI) bis zu explizit modellierten Graphen mit Knoten und Kanten (LangGraph).

Tool-Anbindung. Wie leicht du eigene Funktionen, APIs oder MCP-Server als Tools registrierst. Fast alle unterstützen heute das Model Context Protocol als gemeinsamen Tool-Standard.

Zustand und Gedächtnis. Kurzzeitgedächtnis (die Nachrichtenliste der laufenden Aufgabe) und Langzeitgedächtnis (Vektorspeicher, externe DB). Entscheidend für Produktion: Lässt sich der Zustand persistieren und wiederherstellen — etwa um eine abgebrochene Aufgabe fortzusetzen oder einen Schritt zurückzurollen?

Observability und Human-in-the-Loop. Tracing jedes Tool-Calls, Kostenmessung, und die Möglichkeit, an definierten Punkten auf menschliche Freigabe zu warten. Das ist der Bereich, der „Demo” von „Produktion” trennt.

Die sechs Frameworks im Einzelnen

Reifegrad-Hinweis vorweg: Die folgenden Stern- und Versionsangaben stammen aus Web-Quellen vom Frühjahr 2026 (siehe Quellen) und altern schnell. Behandle sie als Momentaufnahme, nicht als feste Größe.

LangGraph — der Graph für Produktion

LangGraph modelliert den Agenten als Graphen: Knoten sind Arbeitsschritte, Kanten der Kontrollfluss, der Zustand wandert explizit durch den Graphen. Das ist mehr Boilerplate als bei den Konkurrenten, gibt dir aber genau die Kontrolle, die Produktivsysteme verlangen: Checkpointing, Wiederaufnahme nach Abbruch, Rollback-Punkte und sauber definierte Human-in-the-Loop-Haltepunkte.

Laut den recherchierten Quellen erreichte LangGraph im April 2026 Version 0.4 mit verbesserter Zustandspersistenz und Human-in-the-Loop-Checkpoints und zog bei den GitHub-Sternen an CrewAI vorbei. Zusammen mit der hauseigenen Observability (LangSmith) gilt es als das produktionsreifste der hier genannten Frameworks. Mehr zur Graph-Idee im Glossar-Eintrag LangGraph.

Nimm es, wenn du ein zustandsbehaftetes System brauchst, das nach einem Absturz weiterläuft, das Audit-Trails liefert und an dem ein Mensch an festen Punkten freigibt. Lass die Finger davon, wenn du nur einen einfachen Single-Agent-Prototyp willst — dann ist der Graph-Overhead unnötig.

CrewAI — rollenbasierte Teams

CrewAI denkt in Crews: Du definierst Agenten als Rollen („Rechercheur”, „Texter”, „Lektor”) mit Zielen und Hintergrundgeschichte, weist ihnen Aufgaben zu und lässt sie ein Ergebnis erarbeiten. Das ist das intuitivste Modell für Multi-Agent-Prototypen — die Abstraktion liest sich fast wie eine Stellenbeschreibung.

Den Quellen zufolge hat CrewAI Enterprise-Observability und Scheduling für Multi-Agent-Koordination nachgelegt, wird mit über 44.000 GitHub-Sternen geführt und ist (laut einer der Quellen) bei vielen Fortune-500-Firmen im Einsatz — solche Adoptions-Zahlen stammen aus Marketing-nahen Quellen und sind mit Vorsicht zu lesen. Aktiv weiterentwickelt wird es weiterhin.

Nimm es, wenn du schnell ein Team aus spezialisierten Agenten zusammenstecken willst und das Rollenmodell zu deiner Aufgabe passt. Lass die Finger davon, wenn du feingranulare Kontrolle über jeden Schritt und harte Persistenz brauchst — dann passt der Graph-Ansatz besser.

AutoGen — Konversation zwischen Agenten

AutoGen (Microsoft Research) baut Multi-Agent-Systeme als Konversation: Agenten schicken sich Nachrichten, ein Agent kann Code generieren, ein anderer ihn ausführen, ein dritter das Ergebnis prüfen. Stark für komplexe, forschungsnahe Szenarien, in denen sich die Interaktion nicht in einen festen Graphen pressen lässt.

Laut den Quellen erreichte AutoGen 1.0 GA mit der v2-API als Standard. Wichtige Einordnung: Microsoft hat AutoGen in den Maintenance-Modus überführt und schiebt die Weiterentwicklung ins breitere Microsoft Agent Framework. Für neue Produktivprojekte heißt das: prüfe, ob du dich lieber gleich am Nachfolger orientierst.

Nimm es, wenn du forschungsnahe Multi-Agent-Konversationen mit Code-Ausführung untersuchst. Lass die Finger davon, wenn du langfristige Wartbarkeit für ein Produktivsystem brauchst — der Maintenance-Status ist ein echtes Risiko.

AutoGPT — der autonome Pionier

AutoGPT machte 2023 das Wort „autonomer Agent” populär: ein zielgetriebenes System, das sich selbst Teilaufgaben setzt, im Web sucht, Code schreibt, Dateien verwaltet. Mit rund 170.000 GitHub-Sternen ist es eines der bekanntesten KI-Projekte überhaupt. Die 2026er-Version setzt laut Quellen auf einen visuellen Workflow-Builder, einen Marktplatz für Agenten-Templates und eine Plugin-Architektur.

Einordnung: AutoGPT ist historisch und konzeptionell wichtig, gilt aber weniger als nüchternes Produktiv-SDK denn als zugängliche Plattform und Lernobjekt für autonome Agenten. Die frühe Faszination („setz ein Ziel, lass es laufen”) stieß schnell an Grenzen — endlose Schleifen, hohe Token-Kosten, brüchige Ergebnisse. Diese Lektionen prägen bis heute, warum reife Frameworks auf Kontrolle statt auf maximale Autonomie setzen.

Nimm es, wenn du eine Plattform mit visuellem Builder suchst und autonome Agenten ausprobieren willst. Lass die Finger davon, wenn du ein schlankes, in deinen Code eingebettetes Framework brauchst.

DSPy — kein Orchestrator, sondern Prompt-Optimierung

DSPy (Stanford NLP) fällt aus der Reihe, weil es kein Orchestrierungs-Framework ist. Statt Prompts von Hand zu schreiben, beschreibst du in DSPy die Aufgabe deklarativ als Signaturen und Module — und Optimierer wie BootstrapFewShot, COPRO oder MIPROv2 suchen automatisch die besten Prompts und Few-Shot-Beispiele für dein Modell. DSPy bringt zwar auch Agent-Bausteine (ReAct-Schleifen) mit, sein Kern ist aber die Optimierung, nicht die Koordination.

Laut Quellen liegt DSPy bei etwa 34.700 GitHub-Sternen, ist anbieteragnostisch (OpenAI, Anthropic, Gemini, Ollama u. a.) und brachte mit GEPA einen Optimierer, der auf der ICLR 2026 als Oral vorgestellt wurde.

Nimm es, wenn du die Prompt-Qualität systematisch verbessern willst, statt manuell zu tüfteln — auch ergänzend zu einem der anderen Frameworks. Lass die Finger davon, wenn du es als Multi-Agent-Orchestrator missverstehst; dafür ist es nicht gebaut.

Browser Use — der Spezialist für den Browser

Browser Use löst genau ein Problem: einen Agenten eine echte Website bedienen lassen — klicken, tippen, scrollen, Formulare ausfüllen. Es macht Webseiten für Modelle zugänglich und ist damit kein Allzweck-Orchestrator, sondern ein Werkzeug für Web-Automatisierung. Du kombinierst es typischerweise mit einem der anderen Frameworks, wenn dein Agent das Web nicht nur per API, sondern wie ein Mensch im Browser nutzen soll.

Den Quellen zufolge liegt Browser Use bei rund 78.000 bis 95.000 GitHub-Sternen (Angaben schwanken je nach Quelle und Datum), kommt aus dem Y-Combinator-Batch Winter 2025 und brachte 2026 unter anderem SOC-2-Type-2-Konformität, eine Desktop-App und Version 2.1.

Nimm es, wenn dein Agent Websites ohne API bedienen muss. Lass die Finger davon, wenn deine Ziele saubere APIs anbieten — ein API-Call ist robuster und billiger als Browser-Steuerung.

Vergleich auf einen Blick

| Framework | Kategorie | Stärke | Reife-Hinweis (Frühjahr 2026) | |-------------|----------------------------|-------------------------------------|--------------------------------------| | LangGraph | Orchestrierung (Graph) | Persistenz, Rollback, Human-in-Loop | v0.4, gilt als produktionsreifstes | | CrewAI | Orchestrierung (Rollen) | schnelle Multi-Agent-Prototypen | aktiv, ~44k Sterne | | AutoGen | Orchestrierung (Chat) | forschungsnahe Multi-Agent-Chats | 1.0 GA, jetzt Maintenance-Modus | | AutoGPT | autonome Plattform | visueller Builder, Pionierstatus | ~170k Sterne, eher Plattform | | DSPy | Prompt-Optimierung | automatische Prompt-/Few-Shot-Suche | ~34,7k Sterne, aktiv | | Browser Use | Browser-Automatisierung | echte Website-Bedienung | v2.1, YC W25, ~78–95k Sterne |

Stolperfallen bei der Framework-Wahl

Framework gewählt, bevor das Problem klar war. Der häufigste Fehler. Erst die Aufgabe analysieren (ein Agent oder mehrere? Persistenz nötig? Browser nötig? Freigabe-Schritte?), dann das Werkzeug.

Orchestrator und Optimierer verwechselt. DSPy gegen LangGraph zu „vergleichen” ist wie Schraubenzieher gegen Akkuschrauber — sie lösen verschiedene Probleme und lassen sich kombinieren.

Reifegrad mit Sternen verwechselt. GitHub-Sterne messen Bekanntheit, nicht Produktionsreife. Maintenance-Status (AutoGen), Persistenz-Fähigkeit und Observability sagen mehr über die Eignung für ein Live-System.

Multi-Agent als Default genommen. Mehrere Agenten bedeuten mehr Token, mehr Latenz, mehr Fehlerquellen. Oft löst ein gut gebauter Single-Agent oder eine feste Workflow dieselbe Aufgabe robuster.

FAQ

Was ist der Unterschied zwischen einem Agenten-Framework und Tool Use?
Tool Use ist der Mechanismus, mit dem ein Modell ein einzelnes externes Werkzeug aufruft — eine API-Funktion. Ein Agenten-Framework baut darauf auf und übernimmt die Klempnerei drumherum: Agent-Loop, Gedächtnis, Koordination mehrerer Agenten und Observability.
Welches Framework soll ich für ein Produktivsystem nehmen?
Für zustandsbehaftete Produktivsysteme mit Persistenz und Freigabe-Schritten gilt LangGraph als die ausgereifteste Wahl. Für schnelle rollenbasierte Multi-Agent-Prototypen ist CrewAI angenehmer. AutoGen ist seit dem Wechsel in den Maintenance-Modus für neue Projekte mit Vorsicht zu betrachten.
Ist DSPy ein Konkurrent zu LangGraph oder CrewAI?
Nein. DSPy optimiert Prompts und Few-Shot-Beispiele, es orchestriert keine Agenten-Teams. Du kannst DSPy zur Prompt-Optimierung sogar zusätzlich zu einem Orchestrierungs-Framework einsetzen.
Wofür brauche ich Browser Use?
Wenn dein Agent eine Website bedienen soll, die keine brauchbare API hat — klicken, tippen, Formulare ausfüllen wie ein Mensch. Bietet das Ziel eine API, ist ein direkter API-Call robuster und günstiger.
Brauche ich überhaupt ein Framework?
Nicht zwingend. Für einen einzelnen Agenten mit wenigen Tools ist Eigenbau oft die klarere und debugbarere Lösung. Frameworks lohnen sich, sobald mehrere Agenten zusammenarbeiten, Zustand persistiert werden muss oder ein Mensch in die Schleife eingreifen soll.

Fazit

Agenten-Frameworks lösen nicht alle dasselbe Problem. LangGraph, CrewAI und AutoGen orchestrieren Agenten — mit unterschiedlicher Philosophie (Graph, Rollen, Chat) und unterschiedlichem Reifegrad. AutoGPT ist eher Plattform und Pionier als nüchternes SDK. DSPy optimiert Prompts statt Agenten zu koordinieren. Browser Use ist der Spezialist fürs echte Web. Die brauchbare Reihenfolge bleibt: erst das Problem schneiden, dann die Ebene wählen (Orchestrierung, Optimierung, Browser), dann das konkrete Werkzeug — und ehrlich prüfen, ob es überhaupt ein Agent sein muss.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks