Richard
1e9cb789c8
- ClawdDotNet.Web: Kestrel im Prozess der Anwendung, Token-Absicherung (TokenGate mit FixedTimeEquals), Endpunkte unter /api, Ereignisstrom unter /events (Server-Sent Events) und fortlaufendes Log-Streaming. - Weboberflaeche (wwwroot/): Vollstaendiges Single-Page-Frontend mit nativem HTML5, CSS3 und ES-Modulen ohne Buildschritt (strikt textContent, #-Routing, sofortiger Login-Sprung bei fehlendem Token, Light/Dark-Theme, lokale Barlow-Schriften). - ClawdDotNet.App: Fachlogik aus den Avalonia-ViewModels in Dienste herausgeloest (AgentAdministration, JobAdministration, ServiceAdministration, RunCoordinator) und ueber InstanceChange synchronisiert. - Tests: ClawdDotNet.Web.Tests und ClawdDotNet.App.Tests hinzugefuegt, alle 684 Tests erfolgreich.
183 lines
16 KiB
Markdown
183 lines
16 KiB
Markdown
# Agenten-Orchestratoren: Marktüberblick & Lessons Learned
|
||
*Stand: 31. August 2026*
|
||
|
||
Ziel dieser Übersicht: ein Blick auf die derzeit relevantesten Agenten-Orchestratoren (Open Source, Closed Source, Frameworks und Consumer-Produkte) — mit Stärken, Schwächen und besonders mit Blick darauf, was für die Entwicklung eines eigenen Orchestrators interessant oder als Warnung wichtig ist.
|
||
|
||
Vorab zur Einordnung der beiden genannten Beispiele: **OpenClaw** ist tatsächlich aktuell eines der größten und meistdiskutierten Projekte in diesem Bereich (siehe unten, eigener Abschnitt) — ein sehr guter Referenzpunkt. **Grokbot** (xAI) ist dagegen eher eine Consumer-App auf Basis eines Orchestrators als ein Framework, das man selbst einsetzen oder studieren könnte — dazu ebenfalls mehr unten.
|
||
|
||
---
|
||
|
||
## 1. Kategorien im Markt
|
||
|
||
Grob lassen sich die Lösungen in fünf Gruppen einteilen:
|
||
|
||
1. **Code-first Frameworks (Open Source):** LangGraph, CrewAI, AutoGen/Microsoft Agent Framework, Semantic Kernel, LlamaIndex Workflows, Haystack, smolagents, Mastra, Pydantic AI, Letta, OpenHands.
|
||
2. **Low-Code/No-Code-Plattformen:** n8n, Dify, Flowise, Rasa, Botpress.
|
||
3. **Managed/Cloud-native Angebote:** OpenAI Agents SDK, Google Agent Development Kit (ADK), AWS Bedrock AgentCore, Claude Agent SDK, Temporal (als Durability-Layer dazu kombiniert).
|
||
4. **Consumer-/Endnutzer-Assistenten mit Orchestrierung im Kern:** OpenClaw, Grokbot.
|
||
5. **Spezial-Layer, die viele Orchestratoren ergänzen:** Mem0, Zep/Graphiti, Letta (Memory), Langfuse (Observability), TrueFoundry Agent Gateway u. ä. (Governance).
|
||
|
||
---
|
||
|
||
## 2. Die gängigsten Frameworks im Detail
|
||
|
||
### LangGraph (LangChain)
|
||
- **Ansatz:** Graphbasierte, zustandsbehaftete Workflows (Nodes = Agenten/Funktionen, Edges = Kontrollfluss), inkl. Checkpointing und "Time-Travel"-Debugging.
|
||
- **Vorteile:** Sehr präzise Kontrolle, deterministisches Routing, gute Human-in-the-Loop-Unterstützung, produktionsreif, Postgres-gestützte Persistenz, gute Observability über LangSmith.
|
||
- **Schwächen:** Hoher initialer Aufwand, erfordert "State-Machine-Denken", steile Lernkurve gegenüber rollenbasierten Ansätzen.
|
||
|
||
### CrewAI
|
||
- **Ansatz:** Rollenbasierte "Crews" – Agenten mit Rolle, Ziel und "Backstory", sequenziell oder hierarchisch orchestriert.
|
||
- **Vorteile:** Sehr niedrige Einstiegshürde, schnelles Prototyping, intuitives Mental Model (spiegelt echte Teamstrukturen).
|
||
- **Schwächen:** Wenig granulare Kontrolle, hoher Token-Overhead (Rolle/Ziel/Backstory wird bei jedem Call mitgeschickt), dokumentierte Fälle von unkontrollierten Retry-Schleifen mit Kosten von bis zu 7 $ pro Lauf, schwer vorhersagbares Verhalten bei Skalierung.
|
||
|
||
### AutoGen / Microsoft Agent Framework (AutoGen + Semantic Kernel, jetzt vereinheitlicht)
|
||
- **Ansatz:** Konversationsbasiert – Agenten "diskutieren" iterativ, ein Selector bestimmt Sprecherreihenfolge und Gesprächsende. Neuere Versionen (1.0 GA, April 2026) bringen Graph-Workflows und MCP-Support.
|
||
- **Vorteile:** Gut für iterative Qualitätsverbesserung, starkes Enterprise-Tooling (Audit-Trails, Azure-Integration), inzwischen sehr umfangreiches Feature-Set.
|
||
- **Schwächen:** Jede zusätzliche Gesprächsrunde kostet Tokens und Latenz, schwer vorhersagbare Antwortzeiten bei hohem Volumen, Migration zwischen Versionen war historisch aufwendig.
|
||
|
||
### Semantic Kernel
|
||
- **Ansatz:** Planner-basiert mit starkem Fokus auf Governance, Safety und Observability.
|
||
- **Vorteile:** Sehr gutes Human-in-the-Loop-Modell, enterprise-tauglich.
|
||
- **Schwächen:** Schwerere Grundstruktur, weniger Flexibilität für offenes, autonomes Verhalten.
|
||
|
||
### Google Agent Development Kit (ADK)
|
||
- **Ansatz:** Hierarchische Baumstruktur (Parent-Child-Delegation), unterstützt das **Agent2Agent (A2A)-Protokoll** für Cross-Framework-Kommunikation.
|
||
- **Vorteile:** Klarer Kontroll-/Datenfluss, Interoperabilität über A2A, gut in Google-Cloud-Umgebungen.
|
||
- **Schwächen:** Optimiert primär auf Google/Gemini, Multi-Cloud-Portabilität erfordert Zusatzaufwand.
|
||
|
||
### OpenAI Agents SDK
|
||
- **Ansatz:** Explizite "Handoffs" (werkzeugbasierte Kontrollübergabe) statt Konversationsschleifen.
|
||
- **Vorteile:** Sehr klarer, nachvollziehbarer Kontrollfluss, schnelles Prototyping, eingebaute Safety-Features.
|
||
- **Schwächen:** Stark auf OpenAI-Modelle zugeschnitten, wenig eingebautes RBAC/Compliance-Tooling.
|
||
|
||
### Claude Agent SDK
|
||
- **Ansatz:** Bewusst minimaler Baustein – liefert die Ausführungsschleife (Loop) mit parallelen Tool-Aufrufen und Hooks, ist aber kein vollständiges Orchestrierungs-"Framework".
|
||
- **Vorteile:** Volle Kontrolle, gute Parallelisierung unabhängiger Tool-Calls, Auto-Compaction des Kontexts.
|
||
- **Schwächen:** Keine eigenständige Plattform – für Langläufer-Workflows braucht es zusätzlich eine Durability-Schicht wie Temporal.
|
||
|
||
### Temporal (in Kombination mit einem Agent-SDK)
|
||
- **Ansatz:** Kein Agent-Framework, sondern eine **durable Workflow-Engine**, die die Agentenschleife umschließt.
|
||
- **Vorteile:** Fehlertolerante Ausführung, Crash-Recovery über Neustarts hinweg, Pausen für menschliche Freigaben auch über Tage hinweg.
|
||
- **Schwächen:** Zusätzliche Infrastrukturebene, muss mit einem Agent-SDK kombiniert werden.
|
||
|
||
### AWS Bedrock AgentCore
|
||
- **Ansatz:** Vollständig gemanagte, supervisor-basierte Architektur mit zwei Routing-Modi.
|
||
- **Vorteile:** VPC-Isolation, AWS-IAM-Integration, eingebaute Guardrails.
|
||
- **Schwächen:** Kein Self-Hosting, dadurch schwierig für Hybrid-/Multi-Cloud-Szenarien.
|
||
|
||
### LlamaIndex (Workflows)
|
||
- **Ansatz:** "Retrieval-first" – Agenten rund um Dokumentenindizierung und Langzeitgedächtnis.
|
||
- **Vorteile:** Starke RAG-/Memory-Patterns.
|
||
- **Schwächen:** Schwach bei komplexer Multi-Agenten-Orchestrierung.
|
||
|
||
### Haystack
|
||
- **Ansatz:** Modulare, explizite Pipelines (Retriever, Router, Memory-Layer).
|
||
- **Vorteile:** Sehr modular, exzellent für RAG.
|
||
- **Schwächen:** Mehr Infrastruktur-Setup nötig, wenig "emergente" Zusammenarbeit zwischen Agenten.
|
||
|
||
### Mastra
|
||
- **Ansatz:** TypeScript-natives Framework, kombiniert Agents, Workflows, RAG und Evals; eigenes "Observational Memory"-System.
|
||
- **Vorteile:** Passt nativ in Node.js/Next.js-Stacks, laut Anbieter 4–10x effizienter im Tokenverbrauch.
|
||
- **Schwächen:** Jüngeres Ökosystem, weniger Integrationen als etablierte Python-Frameworks.
|
||
|
||
### n8n / Dify / Flowise (Low-Code)
|
||
- **Ansatz:** Visuelle Workflow-Builder mit KI-Agenten-Knoten, teils 400+ Integrationen.
|
||
- **Vorteile:** Kein Code nötig, schnelle Anbindung bestehender Tools, gut für Business-User.
|
||
- **Schwächen:** Kein "echtes" Agenten-Framework im Sinne von Kontrollfluss-Flexibilität, für komplexe, individuelle Logik limitiert.
|
||
|
||
### Letta (ehem. MemGPT)
|
||
- **Ansatz:** Kein reines Memory-Plugin, sondern eine vollständige **Agenten-Runtime** mit Betriebssystem-inspirierter Speicherarchitektur (Core/Recall/Archival-Memory, "Paging" wie bei RAM/Disk).
|
||
- **Vorteile:** Agenten können über Sessions hinweg "lernen" und ihr Verständnis selbst aktualisieren, MCP-Unterstützung, produktionserprobt (Letta Code führt Rankings bei Open-Source-Coding-Agenten an).
|
||
- **Schwächen:** Agenten können ihr eigenes Core-Memory überschreiben und dabei ihre "Persona" verlieren – erfordert schreibgeschützte Kernblöcke, Token-Caps und periodische "Memory-Health"-Checks.
|
||
|
||
### OpenHands (ehem. OpenDevin, Coding-Agent-Spezialist)
|
||
- **Ansatz:** Event-Stream-Architektur, läuft in isolierten Docker-Sandboxes.
|
||
- **Vorteile:** Löst laut Benchmark ca. 53 % echter GitHub-Issues vollautomatisch.
|
||
- **Schwächen:** Spezialisiert auf Coding-Use-Cases, kein generischer Multi-Domain-Orchestrator.
|
||
|
||
---
|
||
|
||
## 3. Vertiefung: OpenClaw
|
||
|
||
OpenClaw ist der mit Abstand relevanteste Fall für eure eigene Entwicklung, weil es sowohl technisch interessant ist als auch ein sehr lehrreiches Negativbeispiel liefert.
|
||
|
||
**Was es ist:** Ein ursprünglich unabhängiges, quelloffenes "persönlicher KI-Assistent"-Projekt (GitHub: `openclaw/openclaw`, Slogan sinngemäß "dein persönlicher Assistent, jedes OS, jede Plattform"). Es wuchs extrem schnell (Berichte nennen 280.000–388.000+ GitHub-Stars, 80.000+ Forks, 650+ Contributor, 85.000+ Commits) und wurde im Februar 2026 von OpenAI übernommen.
|
||
|
||
**Architektur – "Trusted Gateway, Untrusted Execution":**
|
||
- Ein lokal laufendes **Gateway** als Kontrollebene für Sessions, Tools, Events und Kanal-Verbindungen.
|
||
- **Channel-Adapter** für WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage.
|
||
- Unterstützung sowohl für gehostete als auch lokal betriebene Modelle (kein Vendor-Lock-in auf ein LLM).
|
||
- MCP-Unterstützung für Tool-Integration.
|
||
- Ein **Skills-System** mit eigenem Plugin-SDK und Marktplatz ("ClawHub") mit über 13.700 Community-Skills.
|
||
- Dieselbe Gateway-Architektur läuft identisch für Einzelnutzer wie für Team-/Gruppen-Deployments – nur die Konfiguration unterscheidet sich.
|
||
|
||
**Das ist für euch interessant, weil:** Lokal-first mit optionaler Cloud-Delegation, Multi-Channel-Anbindung "wo die Nutzer eh schon sind" (Messenger statt eigener App) und ein offenes Skill-Ökosystem sind alles Designentscheidungen, die zu sehr schnellem Wachstum und hoher Adoption geführt haben.
|
||
|
||
**Die Schattenseite – ein wichtiges Warnsignal:** Genau dieses offene Skill-Ökosystem wurde zum Sicherheitsproblem. Mehrere unabhängige Analysen (Unit 42/Palo Alto, Dark Reading, eSecurity Planet u. a.) fanden im ClawHub-Marktplatz:
|
||
- **Infostealer-Skills** für macOS, die per Base64-codiertem "curl-pipe-bash"-Dropper Schadcode nachluden.
|
||
- **Scanner-Umgehung** durch künstlich aufgeblähte Dateigrößen (bis 22 MB "Padding"), um automatische Scanner wie ClawScan und VirusTotal zu überlisten.
|
||
- **Neuartigen "agentic fraud"**: Skills, die zur Laufzeit Affiliate-Links injizierten oder Front-Running betrieben, um über die Autonomie des Agenten selbst Profit zu generieren.
|
||
- Grundproblem: Skills sind "markdown-getriebene Pakete mit breitem Systemzugriff" – klassisches Sandboxing wie bei npm/PyPI reicht nicht aus, weil der Angriff über **semantische Manipulation der Agenten-Instruktionen** läuft, nicht über klassischen Exploit-Code. Schätzungen sprachen von ca. 20 % der Community-Skills mit Sicherheitsproblemen.
|
||
|
||
**Konkrete Lektion für einen eigenen Orchestrator:** Wer ein Plugin-/Skill-System plant, sollte von Anfang an mitdenken: Laufzeit-Isolation pro Skill (nicht nur statisches Scanning), Identitätsprüfung von Publishern, Verhaltensüberwachung des tatsächlichen Netzwerkverkehrs gegen die deklarierte Spezifikation, und explizite Kontrollen gegen "der Agent tut Dinge, für die er zwar semantisch überzeugt wurde, aber die nicht seiner eigentlichen Aufgabe entsprechen".
|
||
|
||
Zusätzlich: Die Übernahme durch OpenAI wirft für alle, die auf OpenClaw aufbauen, Governance- und Roadmap-Fragen auf – ein Hinweis darauf, wie wichtig eine klare, unabhängige Lizenz-/Governance-Strategie für das eigene Projekt ist, falls Community-Vertrauen ein Ziel ist.
|
||
|
||
---
|
||
|
||
## 4. Einordnung: Grokbot (xAI)
|
||
|
||
Grokbot ist **kein Orchestrierungs-Framework zum Selbstbauen**, sondern eine Consumer-App von xAI für Endnutzer ohne Code-Zugriff. Trotzdem ein paar interessante Design-Ideen:
|
||
|
||
- Jeder Chat-Thread ist ein eigener Agent; der Agent leitet seine Rolle aus dem selbstvergebenen Namen ab (z. B. "Recherche-Bot").
|
||
- Jeder Agent läuft auf einem eigenen **Cloud-Computer** (nicht lokal) mit Zugriff auf Browser, Dateimanager und Terminal – dadurch laufen Aufgaben weiter, auch wenn das Endgerät offline ist.
|
||
- Agenten können andere Agenten erzeugen und an sie delegieren; die Konversationshistorie zwischen den Agenten wird gespeichert, sodass mehrere Agenten gemeinsam auf ein Ziel hinarbeiten.
|
||
- "Routinen" (Cron-artige Zeitpläne oder Event-Trigger wie neue Slack-Nachrichten/Git-Commits) statt manueller Aufrufe.
|
||
- Nutzer können Agenten per Bildschirmaufzeichnung neue Fähigkeiten "vorführen", die daraus wiederverwendbare Skills ableiten ("Learning by demonstration").
|
||
|
||
Für euer Projekt vor allem als UX-Inspiration relevant (Delegation zwischen Agenten, Skill-Erwerb per Demonstration), weniger als Architekturvorbild.
|
||
|
||
---
|
||
|
||
## 5. Governance-Lücke als mögliche Differenzierung
|
||
|
||
Eine mehrfach genannte Beobachtung (u. a. TrueFoundry): **Kein** der etablierten Frameworks bietet out-of-the-box:
|
||
|
||
- einheitliche Zugriffskontrolle über Teams/Workflows hinweg,
|
||
- Token-Budget-Obergrenzen auf Unternehmensebene,
|
||
- compliance-taugliche Audit-Trails mit Nutzer-Identitäts-Mapping,
|
||
- konsistente Governance für MCP-Tool-Zugriffe.
|
||
|
||
Das ist eine Lücke, die separate "Agent-Gateway"-Produkte zu schließen versuchen – und potenziell auch eine Chance für einen eigenen Orchestrator, sich klar zu differenzieren, statt nur ein weiteres reines Orchestrierungs-Framework zu sein.
|
||
|
||
---
|
||
|
||
## 6. Konkrete Takeaways für die eigene Entwicklung
|
||
|
||
- **Interoperabilität von Anfang an einplanen:** MCP für Tool-Zugriff und A2A (Google) für Cross-Framework-Kommunikation sind dabei, sich als De-facto-Standards zu etablieren. Ein proprietäres, geschlossenes Protokoll zu bauen wäre ein strategisches Risiko.
|
||
- **Skill-/Plugin-Sicherheit von Tag 1 an mitdenken**, nicht nachrüsten – siehe OpenClaw/ClawHub. Laufzeit-Isolation statt nur statischem Scannen, Publisher-Verifizierung, Verhaltens- statt nur Signatur-Prüfung.
|
||
- **Kostenkontrolle einbauen:** CrewAI (unkontrollierte Retries) und AutoGen (Kosten pro zusätzlicher Konversationsrunde) zeigen, dass explizite Retry-/Turn-Budgets und Kostenobergrenzen pro Lauf kein "nice-to-have", sondern Pflicht sind.
|
||
- **Durability von Reasoning-Loop trennen:** Das Muster "leichtgewichtiges Agent-SDK + separate durable Workflow-Engine (à la Temporal)" erlaubt Crash-Recovery und mehrtägige Freigabe-Pausen, ohne die Kernlogik zu verkomplizieren.
|
||
- **Memory bewusst schichten:** Letta zeigt ein durchdachtes Modell (Core/Recall/Archival), aber auch das Risiko von selbstüberschriebenem, degeneriertem "Persona"-Gedächtnis – schreibgeschützte Kernblöcke und periodische Health-Checks sind sinnvoll.
|
||
- **Checkpointing/Time-Travel-Debugging** (LangGraph-Vorbild) erleichtert Produktionsbetrieb und Nachvollziehbarkeit erheblich.
|
||
- **Governance/Audit als Kernfeature statt Add-on** positionieren – hier haben laut Marktbeobachtung alle etablierten Player noch Lücken.
|
||
|
||
---
|
||
|
||
## Quellen
|
||
|
||
- [OpenClaw: The Future of AI Agent Orchestration – Qualcomm](https://www.qualcomm.com/news/onq/2026/04/openclaw-ai-agent-orchestration)
|
||
- [OpenClaw: Multi-Agent Orchestration, Now Under OpenAI](https://ai-native-connect.scaledagile.com/public/blogs/open-claw-multi-agent-orchestration)
|
||
- [GitHub – openclaw/openclaw](https://github.com/openclaw/openclaw)
|
||
- [The Best Open-Source AI Agent Frameworks in 2026 – AI Magicx](https://www.aimagicx.com/blog/best-open-source-ai-agent-frameworks-2026)
|
||
- [OpenClaw's Skill Marketplace and the Emerging AI Supply Chain Threat – Unit 42 / Palo Alto Networks](https://unit42.paloaltonetworks.com/openclaw-ai-supply-chain-risk/)
|
||
- [More Malicious OpenClaw Skills Threaten AI Supply Chain – Dark Reading](https://www.darkreading.com/cyber-risk/malicious-openclaw-skills-clawhub-threaten-ai-supply-chain)
|
||
- [Hundreds of Malicious Skills Found in OpenClaw's ClawHub – eSecurity Planet](https://www.esecurityplanet.com/threats/hundreds-of-malicious-skills-found-in-openclaws-clawhub/)
|
||
- [What Is Grokbot? xAI's New Agentic Assistant Explained – MindStudio](https://www.mindstudio.ai/blog/grokbot-xai-agent-app)
|
||
- [Best Multi-agent Orchestration Frameworks in 2026 – TrueFoundry](https://www.truefoundry.com/blog/multi-agent-orchestration-frameworks)
|
||
- [Top Agentic Frameworks for Building Applications 2026 – JetBrains Blog](https://blog.jetbrains.com/pycharm/2026/06/top-agentic-frameworks-for-building-applications-2026/)
|
||
- [7 Multi-Agent Orchestration Platforms: Build vs Buy in 2026 – Augment Code](https://www.augmentcode.com/tools/multi-agent-orchestration-platforms-build-vs-buy)
|
||
- [The Open Source Agent Toolkit in 2026 – O'Reilly Radar](https://www.oreilly.com/radar/the-open-source-agent-toolkit-in-2026/)
|
||
- [Letta/MemGPT Agent Memory Layer Deep Dive 2026 – Callsphere](https://callsphere.ai/blog/vw3g-letta-memgpt-agent-memory-layer-deep-dive-2026)
|