# KI-Agent-Frameworks im Überblick (Deutsch) Die Wahl des richtigen Frameworks für KI-Agenten ist keine Entweder-Oder-Entscheidung — sondern hängt von deinem konkreten Anwendungsfall ab. Viele bauen LangChain ein, wo das nackte SDK gereicht hätte, oder kämpfen mit CrewAI, obwohl ihre Aufgabe gar keine Multi-Agenten-Choreographie braucht. Dieser Überblick zeigt dir, welches Framework (oder kein Framework) für deine Situation passt. Erstellt von der [FlowKI-Community](https://flowki-club.de). Die Framework-Landschaft ändert sich schnell — neue Features, Pricing-Modelle, aufstrebende Alternativen. Deshalb ordnet dieser Überblick nach **stabilen Kriterien**: Welches Problem löst das Framework, welche Architektur bringt es mit, wann passt es — nicht nach Ranglisten oder Marktanteilen. Im Zweifel immer die aktuelle Doku des jeweiligen Frameworks prüfen. --- ## Was ist überhaupt ein "Agenten-Framework"? Ein Agenten-Framework nimmt dir Bausteine ab, die du sonst selbst verdrahten müsstest: - **Tool-Aufrufe** — wie das Modell externe Funktionen (Datenbankzugriff, APIs, eigene Skripte) aufruft und die Antworten zurück in den Kontext bekommt. - **Speicher** — wie der Agent sich Zwischenergebnisse oder frühere Konversationen merkt. - **Orchestrierung** — die Schleife, die entscheidet, ob der Agent weiterarbeitet oder fertig ist, und die Werkzeuge in der richtigen Reihenfolge aufruft. Frameworks geben dir fertige Muster, eingebaute Integrationen und oft eine höhere Abstraktionsebene. Der Preis: mehr Abhängigkeiten, mehr Lernaufwand, manchmal mehr Overhead als bei einem handgeschriebenen 50-Zeilen-Skript. ## Brauchst du überhaupt ein Framework? Die erste Frage ist nicht "welches Framework", sondern "**Framework oder kein Framework**". - **Du brauchst wahrscheinlich keins,** wenn deine Aufgabe in 1–2 festen Schritten lösbar ist (extrahieren → formatieren → speichern). Dann reicht das nackte SDK und dein eigener Code — billiger, schneller, leichter zu debuggen. Siehe den [KI-Architektur-Entscheidungsbaum](/freebies/ki-architektur-entscheidungsbaum), Archetyp 1 oder 2. - **Du profitierst von einem Framework,** wenn du tatsächlich Orchestrierung brauchst (das Modell soll selbst entscheiden, welche Werkzeuge in welcher Reihenfolge) oder wenn du viele Integrationen nutzt, die ein Framework bereits mitbringt. ## Die wichtigsten Frameworks im Vergleich | Framework | Wofür bekannt | Wann sinnvoll | |---|---|---| | **LangChain** | Breite Orchestrierung, viele fertige Integrationen (DBs, APIs, Vektor-Stores), modulare Bausteine („chains") | Wenn du schnell verschiedene Komponenten kombinieren willst, ohne alles selbst zu verdrahten. Etabliert, große Community. | | **LlamaIndex** | RAG-fokussiert: Daten-Anbindung, Indexierung, Query-Engines | Wenn dein Hauptproblem ist, eigene Wissensbasis/Daten sauber abzufragen. Oft als Ergänzung zu anderen Frameworks. | | **CrewAI** | Multi-Agenten-Zusammenspiel mit festen Rollen („Manager", „Researcher", „Writer") | Wenn du mehrere spezialisierte Agenten orchestrierst, die sich Aufgaben zuwerfen. Rollenbasiertes Denken. | | **AutoGen** | Multi-Agenten-Konversation, Agenten diskutieren untereinander | Wenn du Agenten miteinander verhandeln/diskutieren lassen willst, z.B. ein Code-Vorschlag wird von einem zweiten Agent geprüft. | | **Nacktes SDK + eigene Tool-Schleife** | Maximale Kontrolle, kein Framework-Overhead | Wenn du genau verstehen willst, was passiert, oder wenn deine Aufgabe sehr spezifisch ist und Frameworks mehr Ballast als Nutzen bringen. | ## Sie ergänzen sich — kein Entweder-Oder Wichtig zu verstehen: Diese Ansätze schließen sich nicht aus. Du kannst z.B. gleichzeitig: - **LlamaIndex** nutzen, um deine Daten sauber abfragbar zu machen (RAG-Pipeline), - **LangChain** für die Orchestrierung (wer ruft welche Tools in welcher Reihenfolge), - **MCP** als Werkzeug-Protokoll, damit deine Agenten einheitlich auf externe Tools zugreifen (z.B. Datenbanken, File-System, Cloud-APIs). **MCP ist dabei KEIN Framework**, sondern ein **Werkzeug-Protokoll** — eine Schnittstelle, über die Modelle strukturiert Tools ansprechen können. Du kannst MCP mit jedem Framework (oder keinem) kombinieren. Mehr dazu: [MCP-Server-Starter](/freebies/mcp-server-starter) und [MCP absichern & debuggen](/freebies/mcp-absichern). ## Entscheidungshilfe: Welches Framework passt? Beantworte diese Fragen: 1. **Brauchst du Multi-Agenten-Zusammenspiel?** (Mehrere spezialisierte Agenten, die sich Aufgaben zuwerfen oder miteinander diskutieren.) - **Ja** → **CrewAI** (Rollen-Fokus) oder **AutoGen** (Konversations-Fokus). - **Nein** → weiter. 2. **Ist RAG/Datenanbindung dein Hauptproblem?** (Du musst eine große eigene Wissensbasis abfragen.) - **Ja** → **LlamaIndex** (kann als Baustein in LangChain oder standalone). - **Nein** → weiter. 3. **Willst du schnell viele fertige Integrationen nutzen?** (APIs, Vektor-DBs, Prompt-Templates, vorgefertigte chains.) - **Ja** → **LangChain**. - **Nein** → weiter. 4. **Ist deine Aufgabe sehr spezifisch, und du willst maximale Kontrolle?** - **Ja** → **Nacktes SDK + eigene Tool-Schleife.** Du schreibst die Orchestrierung selbst (oft 50–100 Zeilen), behältst volle Transparenz und zahlst keinen Framework-Overhead. Wenn du bei keiner Frage sicher „ja" sagst, ist wahrscheinlich deine Aufgabe noch nicht scharf genug definiert — dann erst das Problem klären, nicht das Framework wählen. ## Drei häufige Fehler 1. **Das "trendigste" Framework nehmen, statt das passende.** LangChain ist populär, aber wenn du nur eine simple Prompt-Kette brauchst, ist das nackte SDK schneller und übersichtlicher. 2. **Framework einbauen, wo eigener Code reicht.** Viele Aufgaben sind in 30 Zeilen eigenem Code sauberer lösbar als mit einem Framework, das du erst lernen und warten musst. 3. **Sich an eine Bibliothek ketten.** Frameworks ändern sich schnell, Breaking Changes sind häufig. Wenn möglich, halte deine Kern-Logik framework-unabhängig (klare Abstraktionen), damit du später einfach wechseln kannst. ## Praktische Tipps - **Starte einfach.** Teste zuerst die simpelste Variante (ein einzelner API-Call, siehe [Architektur-Entscheidungsbaum](/freebies/ki-architektur-entscheidungsbaum)), und steigere dich nur bei Bedarf. - **Frameworks als Beschleuniger, nicht als Dogma.** Sie sollen dir Zeit sparen, nicht dich einschränken. Wenn du merkst, dass du gegen das Framework kämpfst, ist ein Framework-Wechsel oder eigener Code oft die bessere Wahl. - **Sicherheit bleibt gleich.** Egal ob LangChain, AutoGen oder selbstgebaut: Tool-Aufrufe sind Vertrauensgrenzen. Validiere Eingaben, logge Tool-Nutzung, setze harte Grenzen (max. Schritte, Budget). Siehe [Prompt-Hardening-Guide](/freebies/prompt-hardening). ## Ehrlicher Hinweis Die konkrete Framework-Landschaft (welche Bibliothek führt, welche Features/Preise gelten, welche aufsteigenden Alternativen es gibt) ändert sich im KI-Bereich im Monatsrhythmus. Deshalb ordnet dieser Überblick bewusst nach **stabilen Architektur-Kriterien** — nicht nach Momentaufnahmen. Prüfe die aktuelle Tool-Wahl kurz gegen den Stand von heute, bevor du dich festlegst. Fragen zur Framework-Wahl oder konkreten Architektur-Entscheidungen? In der [FlowKI-Community](https://flowki-club.de) kannst du dein Vorhaben zur Diskussion stellen, bevor du baust.