Fünf Kategorien, zehn Systeme, ein Entscheidungsrahmen — welches KI-Agenten-System passt wann, und wo ordnet sich Hermes ein?
SerieKI-Agenten
Teil 3 von 5
Der KI-Agenten-Markt 2026 wächst schneller als die meisten Kategorien davor. Fast wöchentlich erscheinen neue Frameworks, Builder und Editoren — jedes mit eigenem Ansatz, eigener Zielgruppe, eigenem Versprechen. Wer sich orientieren will, braucht keinen weiteren Top-10-Artikel, sondern einen Rahmen: Was sind das eigentlich für Systeme? Welche lösen welche Probleme? Und wo unterscheiden sie sich grundlegend?
Dieser Artikel ist der dritte Teil der Serie über KI-Agenten. Teil 1 erklärt, was Agentensysteme grundlegend von klassischen Chatbots unterscheidet. Teil 2 zeigt, wie Multi-Agent-Workflows die Entwicklerrolle verändern. Hier geht es um den Markt — sortiert in fünf Kategorien, mit GitHub-Stars aus Mai 2026 als grober Orientierung zur Community-Größe.
Warum Kategorien wichtiger sind als Rankings
KI-Agenten-Systeme lassen sich nicht sinnvoll in eine einzige Rangliste bringen — dazu sind die Anwendungsfälle zu verschieden. Ein Framework für Python-Entwickler, die Multi-Agent-Pipelines programmieren wollen, ist kein Konkurrent zu einem No-Code-Builder für Teams ohne Entwicklererfahrung. Ein autonomer Coding-Agent, der Pull Requests erstellt, ist kein Ersatz für ein persönliches Agentensystem, das Aufgaben über Wochen speichert.
Fünf Kategorien strukturieren den aktuellen Markt sinnvoll:
- Persönliche Agentensysteme — dauerhaft laufende Agenten mit Gedächtnis, Skills, Multi-Plattform-Anbindung
- Orchestrierungs-Frameworks — Code-basierte Werkzeuge für Entwickler, die Multi-Agent-Systeme bauen
- Visuelle Builder — Low-Code- und No-Code-Interfaces für Workflows und Agenten-Pipelines
- Autonome Coding-Agenten — Systeme, die selbstständig Code schreiben, Tests ausführen, PRs erstellen
- Editor-integrierte Agenten — KI direkt in der Entwicklungsumgebung, ohne separate Tool-Schicht
Persönliche Agentensysteme: Hermes
Hermes von NousResearch ist das Referenzsystem dieser Serie. Im Februar 2026 gestartet, über 100k GitHub-Stars in wenigen Wochen — damit wohl das am schnellsten wachsende Open-Source-Agenten-Projekt 2026.
Das Kernangebot: Agenten, die mit dem Nutzer mitwachsen. Skills entstehen automatisch aus komplexen Aufgaben und werden wiederverwendet. Gedächtnis bleibt zwischen Sitzungen erhalten. Hermes läuft auf 22 Plattformen — Telegram, Discord, Slack, WhatsApp, Signal, CLI und weitere — alle über einen einzelnen Gateway-Prozess.
Stärken: Tiefe Personalisierung durch Skills und Memory, breite Plattformabdeckung, aktive Community (v0.14.0 enthielt 808 Commits und 633 Merged PRs in einem einzigen Release). Lokale Modelle über Ollama werden vollständig unterstützt. Selbst-Verbesserungsmechanismen direkt eingebaut.
Schwächen: Noch jung — viele Teile wirken experimentell. Setup erfordert technisches Verständnis trotz wachsender Desktop-Version. Skalierung auf Unternehmensebene ist nicht der Fokus.
GitHub: NousResearch/hermes-agent — ~157k ⭐ (Mai 2026)
Orchestrierungs-Frameworks
Diese Kategorie richtet sich an Entwickler, die Multi-Agent-Systeme programmieren — nicht bedienen.
CrewAI
CrewAI ist das derzeit populärste Multi-Agent-Framework in der Python-Welt. Die Leitmetapher ist das Team: Agenten bekommen Rollen (Researcher, Writer, Reviewer), Ziele und Tools — und arbeiten dann kollaborativ an Aufgaben.
Das Framework ist vollständig unabhängig von LangChain gebaut und hat bis Mai 2026 über 2 Milliarden Agent-Ausführungen verbucht. Die Community ist entsprechend groß und aktiv.
Stärken: Sehr gute Dokumentation, schnelle Einarbeitung, klare Rollenmetapher, produktionserprobt. Eigenes Cloud-Angebot für gehostete Runs.
Schwächen: Rollenbasiertes Modell passt nicht für alle Aufgaben. Bei sehr dynamischen, nicht vordefinierten Workflows stoßen statische Crew-Definitionen an Grenzen. Python-Kenntnisse vorausgesetzt.
GitHub: crewaiinc/crewai — ~50k ⭐
AG2 / AutoGen
AutoGen begann als Microsoft-Forschungsprojekt und ist im November 2024 in zwei separate Projekte aufgeteilt worden: Microsofts eigener Rewrite als microsoft/autogen und das Community-Projekt AG2 (ag2ai/ag2), das von den ursprünglichen AutoGen-Entwicklern weitergeführt wird. Beide sind Stand April 2026 aktiv gepflegt.
Das Kernkonzept: Agenten kommunizieren über Nachrichten miteinander, nicht über starre Pipelines. Das ermöglicht flexible, konversationsbasierte Multi-Agent-Interaktionen, bei denen Agenten ihre eigenen Entscheidungen treffen, wann sie andere Agenten einbeziehen.
Stärken: Sehr flexibel, gut für dynamische Workflows, starkes akademisches und Forschungs-Ökosystem, breite Modellunterstützung, Human-in-the-Loop einfach integrierbar.
Schwächen: Höhere Einarbeitungshürde als CrewAI. Die Split-Situation zwischen microsoft/autogen und ag2ai/ag2 erzeugt Unsicherheit über die langfristige Richtung. Debugging komplexer Konversationsabläufe ist aufwändig.
GitHub: ag2ai/ag2 — ~48k ⭐ | microsoft/autogen
LangGraph
LangGraph ist LangChains Antwort auf komplexe, zustandsbehaftete Agenten-Workflows. Statt linearer Ketten oder Rollendefinitionen modelliert LangGraph Abläufe als gerichteten Graphen — Knoten sind Verarbeitungsschritte, Kanten bestimmen den Kontrollfluss.
Das ist technisch präziser als andere Frameworks, aber auch anspruchsvoller. LangGraph ermöglicht Schleifen, Bedingungen und parallele Ausführungspfade — Dinge, die andere Frameworks nur schwer abbilden können.
Stärken: Maximale Kontrolle über Agenten-Logik, gut für komplexe Entscheidungsbäume, native Checkpointing-Unterstützung, enge LangChain-Integration.
Schwächen: Steilste Lernkurve in dieser Kategorie. Graph-Denken ist für viele Teams ungewohnt. Kleinere Community als CrewAI. Für einfache Use Cases deutlich überdimensioniert.
GitHub: langchain-ai/langgraph — ~24k ⭐
Visuelle Builder
Diese Kategorie richtet sich an Teams, die Agenten-Workflows ohne Code-Kenntnisse aufbauen wollen — oder Code und Visualisierung kombinieren.
Langflow
Langflow von DataStax/IBM ist ein visuelles IDE für LangChain und LangGraph. Workflows werden durch Verbinden von Nodes auf einem Canvas aufgebaut — jeder Node repräsentiert einen LLM-Aufruf, ein Tool, einen Speicherzugriff oder eine Datenquelle.
Die Sternzahl ist außergewöhnlich hoch und spiegelt die massive LangChain-Community wider: Langflow profitiert direkt vom Ökosystem-Effekt.
Stärken: Größte visuelle Builder-Community, sehr breite LangChain/LangGraph-Kompatibilität, Enterprise-Backing durch DataStax, gut für Prototyping und schnelle Iteration.
Schwächen: Enge Kopplung an das LangChain-Ökosystem. Komplexe Workflows werden auf dem Canvas schnell unübersichtlich. Produktions-Deployment erfordert zusätzliche Infrastruktur.
GitHub: langflow-ai/langflow — ~140k ⭐
Flowise
Flowise ist einfacher gehalten als Langflow — bewusst. Drag-and-Drop-Canvas, fertige Node-Typen für gängige Patterns, automatisch generierte API für jeden erstellten Chatflow. Ziel ist die schnelle Inbetriebnahme ohne tiefes LangChain-Wissen.
Stärken: Niedrige Einstiegshürde, schnelle Ergebnisse für Standardfälle wie Chatbots mit Dokumentenzugriff, gute Self-Hosting-Option, aktive Node-Bibliothek.
Schwächen: Begrenzte Flexibilität bei komplexen Logiken. Hängt ebenfalls stark von LangChain ab. Für erfahrene Entwickler oft zu abstrakt.
GitHub: FlowiseAI/Flowise — ~30k ⭐
Dify
Dify positioniert sich als Full-Stack-Plattform für KI-Anwendungen — nicht nur als Agent-Builder. RAG-Pipelines, LLM-Gateways, Prompt-Management, Observability, Deployment: alles in einer Oberfläche.
Mit $30M Series-Pre-A-Finanzierung im März 2026 und über 130k GitHub-Stars ist Dify das am breitesten aufgestellte Open-Source-Projekt in dieser Kategorie.
Stärken: Vollständigste Feature-Abdeckung, starke RAG-Integration, produktionsreif durch eingebautes Monitoring, unterstützt viele Modell-Provider.
Schwächen: Breitester Scope bedeutet auch die höchste Komplexität beim Einstieg. Wer nur einfache Agent-Workflows braucht, bekommt viel mehr als nötig. Self-Hosting ist aufwändiger als bei Flowise.
GitHub: langgenius/dify — ~131k ⭐
Autonome Coding-Agenten
Diese Systeme sind auf eine spezifische Aufgabe spezialisiert: selbstständig Code schreiben, Fehler beheben, Tests ausführen, Pull Requests erstellen.
OpenHands
OpenHands (früher OpenDevin) ist der meistgenutzte Open-Source-Coding-Agent, der vollständig selbst gehostet werden kann. Er arbeitet in einer sandboxed Docker-Umgebung: Code schreiben, Terminal-Befehle ausführen, Browser steuern, PRs öffnen — alles ohne manuellen Eingriff.
Auf dem SWE-bench Verified löst OpenHands mit starken Modellen wie Claude 4.5 über 53 % realer GitHub-Issues. Mit $18.8M Series-A-Finanzierung und Nutzern wie AMD, Apple, Google und Netflix ist es der produktionsreifste autonome Coding-Agent im Open-Source-Bereich.
Stärken: Mächtigster autonomer Coding-Agent zum Selbsthosten, starke Benchmark-Werte, modell-agnostisch, große Contributor-Community, aktive Weiterentwicklung.
Schwächen: Docker-Abhängigkeit für die Sandbox. Für kleine Aufgaben oversized. Vollständig autonomes Handeln erfordert sorgfältige Permissions-Konfiguration, um unerwünschte Seiteneffekte zu vermeiden.
GitHub: OpenHands/OpenHands — ~74k ⭐
Aider
Aider ist das Gegenteil von OpenHands: kein separates System, keine Docker-Sandbox, keine Web-UI. Aider läuft im Terminal und bearbeitet Dateien direkt im bestehenden Projekt. Es verbindet sich mit LLMs und committet Änderungen mit sinnvollen Git-Messages.
Das macht Aider zur schlanken Option für Entwickler, die KI-Unterstützung im gewohnten Workflow wollen — ohne den Overhead eines vollständigen Agent-Systems.
Stärken: Minimaler Setup, nahtlose Git-Integration, funktioniert mit jedem Modell-Provider, sehr schnell für gezielte Code-Änderungen, leichtgewichtig.
Schwächen: Kein autonomes Agieren über mehrere Schritte hinweg — Aider reagiert auf Anweisungen, plant aber keine mehrstufigen Abläufe selbst. Kein Browsing, keine Terminal-Automatisierung jenseits des Editors.
GitHub: Aider-AI/aider — ~42k ⭐
Editor-integrierte Agenten: Zed
Zed ist kein Agenten-System in dem Sinne, wie die anderen Tools hier aufgeführt sind — es ist ein Code-Editor. Aber Zed 1.0 (April 2026) hat eine Architektur eingeführt, die den Editor selbst zur Koordinationsebene für Agenten macht.
Das Konzept: Mehrere Agenten laufen in parallelen Agenten-Sessions direkt in der IDE. Jede Session hat ihre eigene Aufgabe — eine refaktoriert Backend-Code, eine aktualisiert Frontend-Typen, eine experimentiert — bei Bedarf auf einem separaten Branch. Die Ergebnisse aller Agenten streamen in Echtzeit zurück in die Editor-Ansicht.
Zed unterstützt externe Agenten (Claude Code, Codex, Aider) als anschließbare Erweiterung, dazu MCP-Server für erweiterten Toolzugriff und beliebige Modell-Provider über eigene API-Keys oder Ollama für lokale Modelle.
Stärken: Keine separate Tool-Schicht — Agenten laufen dort, wo sowieso gearbeitet wird. Rust-basierter Editor mit bemerkenswerter Performance. Parallele Agenten-Threads nativ. Starke Flexibilität bei Modell-Wahl.
Schwächen: Kein persistentes Gedächtnis über Sessions hinweg wie bei Hermes. Agent-Fähigkeiten sind ans Editor-Paradigma gebunden — keine eigenständigen, rund-um-die-Uhr laufenden Hintergrund-Agenten. Die Kombination Editor + Agent-Layer erfordert Umgewöhnung für Entwickler, die mit VS Code oder JetBrains vertraut sind.
Einordnung: Zed zeigt eine eigene Kategorie: Agenten als native IDE-Funktion statt als externes System. Für Entwickler, die Agenten-Workflows direkt im Editor wollen, ist das der direkteste Weg — ohne Orchestrierungs-Layer davor. Für Nicht-Entwickler und für Aufgaben jenseits von Code ist Zed nicht das richtige Werkzeug.
GitHub: zed-industries/zed — ~83k ⭐
Einordnung: Welches System passt wann?
| System | Kategorie | GitHub-Stars | Zielgruppe | Lokal lauffähig |
|---|---|---|---|---|
| Hermes | Persönlicher Agent | ~157k | Alle | Ja (Ollama) |
| CrewAI | Framework | ~50k | Python-Entwickler | Ja |
| AG2 / AutoGen | Framework | ~48k | Entwickler/Forschung | Ja |
| LangGraph | Framework | ~24k | Erfahrene Entwickler | Ja |
| Langflow | Visual Builder | ~140k | Teams, Entwickler | Ja |
| Flowise | Visual Builder | ~30k | Einsteiger, Teams | Ja |
| Dify | Full-Stack-Plattform | ~131k | Teams, Unternehmen | Ja |
| OpenHands | Coding-Agent | ~74k | Entwickler | Ja (Docker) |
| Aider | Coding-Assistent | ~42k | Entwickler | Ja |
| Zed | Editor + Agents | ~83k | Entwickler | Ja (Ollama) |
Alle Sternzahlen sind Näherungswerte aus Mai 2026 und verändern sich laufend.
Die eigentliche Entscheidungsfrage ist nicht „Welches ist das beste System?”, sondern: Was soll der Agent dauerhaft tun? Wo kommt der Nutzer her? Und wie viel Infrastruktur-Overhead ist akzeptabel?
Wer einen persistenten persönlichen Agenten will, der Aufgaben über Wochen kennt und auf Messaging-Plattformen erreichbar ist, landet bei Hermes. Wer als Python-Entwickler Multi-Agent-Pipelines bauen will, evaluiert CrewAI und AG2. Wer ein Team ohne Entwicklererfahrung ausstatten will, schaut sich Flowise oder Dify an. Wer Agenten direkt im Code-Editor haben will und VS Code für zu schwerfällig hält, probiert Zed.
Was auffällt: Fast alle Systeme unterstützen lokale Modelle. Die Abhängigkeit von Cloud-APIs ist keine Pflicht mehr — sie ist eine Entscheidung.