Ein einzelner KI-Agent stößt schnell an Grenzen, sobald eine Aufgabe Recherche, Analyse und Textproduktion gleichzeitig verlangt. Wer sich einen Überblick über aktuelle Entwicklungen rund um KI und maschinelles Lernen verschaffen will, findet dort weitere Hintergründe zu Sprachmodellen und Agenten-Frameworks. CrewAI löst dieses Problem, indem es mehrere spezialisierte Agenten zu einem Team zusammenfasst, das Aufgaben untereinander aufteilt und koordiniert abarbeitet. Das Open-Source-Framework aus Python hat sich seit dem GA-Release von CrewAI OSS 1.0 zu einer der meistgenutzten Grundlagen für produktive Multi-Agenten-Systeme entwickelt und bringt es auf rund 44.000 GitHub-Sterne (Stand August 2026). Dieses Tutorial zeigt in 12 Schritten, wie Sie CrewAI installieren, ein erstes Agenten-Team aufbauen und produktionsnahe Konzepte wie Memory, Tools und hierarchische Prozesse einsetzen.

Am Ende des Artikels steht ein vollständiges Beispielprojekt: eine Recherche-und-Schreib-Crew, die eigenständig Informationen sammelt und daraus einen Artikelentwurf erstellt. Der Code lässt sich direkt in eigene Projekte übernehmen und auf andere Anwendungsfälle wie Kundensupport oder Projektplanung übertragen.

Der Artikel richtet sich an Entwickler, die bereits Python-Grundkenntnisse mitbringen und entweder erstmals ein Multi-Agenten-System bauen oder von einer Einzel-Agent-Lösung auf eine koordinierte Crew umsteigen wollen. Neben der reinen Installation und dem ersten Code-Beispiel gehen wir auf Fragen ein, die in der Praxis erst nach den ersten Testläufen auftauchen: Wie hoch fallen die Kosten für mehrere LLM-Aufrufe pro Task tatsächlich aus, welche Stolperfallen kosten am meisten Zeit bei der Fehlersuche, und wann lohnt sich der Umstieg von einem sequenziellen auf einen hierarchischen Prozess mit eigenem Manager-Agenten.

Was ist CrewAI? Multi-Agenten-Framework im Überblick

CrewAI ist ein eigenständiges Python-Framework für die Orchestrierung mehrerer autonomer KI-Agenten. Anders als viele Konkurrenten baut CrewAI nicht auf LangChain auf, sondern bringt eine eigene, schlanke Architektur mit. Das Projekt beschreibt sich selbst als produktionsreifes Framework für kollaborierende Agenten-Teams, sogenannte Crews, sowie für ereignisgesteuerte Workflows, sogenannte Flows. Mit dem Blogeintrag zum GA-Start wurde CrewAI OSS 1.0 offiziell als stabile Version markiert, während Teams mit höheren Governance-Anforderungen auf die kommerzielle Plattform CrewAI AMP wechseln können.

Der Kerngedanke: Statt einen einzelnen Agenten mit einem übergroßen Prompt zu überfordern, teilen Sie die Arbeit auf mehrere Rollen auf. Ein Rechercheur sammelt Fakten, ein Analyst bewertet sie, ein Autor formuliert das Ergebnis. Jeder Agent bekommt eine klare Rolle, ein Ziel und optional eigene Werkzeuge. CrewAI kümmert sich um die Reihenfolge, die Übergabe von Zwischenergebnissen und, bei Bedarf, um eine übergeordnete Steuerungsinstanz.

Bemerkenswert an CrewAI ist die bewusste Entscheidung, keine Abhängigkeit zu LangChain oder anderen bestehenden Agenten-Bibliotheken einzugehen. Die Entwickler haben das Framework von Grund auf neu geschrieben, um eine schlanke API zu erhalten, die sich nicht mit den Abstraktionsebenen eines größeren Ökosystems herumschlagen muss. Das zahlt sich in der Praxis vor allem beim Einstieg aus: Ein neues Crew-Projekt lässt sich oft schon nach wenigen Zeilen Code lauffähig testen, ohne vorher ein komplettes Chain- oder Graph-Konzept verstehen zu müssen. Für Teams, die produktive Agenten-Systeme betreiben wollen, kommt außerdem die Option hinzu, von der freien OSS-Version auf die kommerzielle Plattform CrewAI AMP zu wechseln, sobald Governance, Nachvollziehbarkeit und Rechteverwaltung über mehrere Teams hinweg wichtiger werden als reine Funktionalität.

Voraussetzungen: Python-Version, API-Keys und Hardware

Bevor es losgeht, sollten folgende Punkte geklärt sein. CrewAI setzt auf Pydantic v2 und moderne Typing-Features, weshalb eine aktuelle Python-Version Pflicht ist. Für die LLM-Anbindung brauchen Sie mindestens einen API-Key, alternativ reicht eine lokale Ollama-Installation für kostenlose Testläufe.

KomponenteMindestanforderungEmpfehlung
Python3.103.11 oder 3.12
Arbeitsspeicher8 GB RAM16 GB+ bei lokalen Modellen
BetriebssystemWindows, macOS oder LinuxLinux oder macOS für Docker-Deployments
CrewAI-VersionOSS 1.0 (GA)aktuellste 1.x-Version per pip
LLM-Zugangmindestens ein ProviderOpenAI oder Anthropic Claude für den Einstieg, Ollama für lokale Tests

Ein API-Key allein reicht für einfache Recherche-Aufgaben oft schon aus. Sobald Agenten im Internet suchen sollen, kommt ein Such-Tool wie Serper.dev oder eine vergleichbare Such-API hinzu. Für lokale Modelle über Ollama entfallen API-Kosten komplett, dafür steigen die Hardware-Anforderungen deutlich.

Ein Punkt wird beim Einstieg regelmäßig unterschätzt: der Netzwerkzugriff. CrewAI-Agenten kommunizieren bei jedem Aufruf mit dem gewählten LLM-Provider über das Internet, weshalb eine stabile Verbindung und, in Unternehmensumgebungen, die passenden Firewall-Freigaben für die jeweiligen API-Endpunkte vorhanden sein müssen. Wer in einer abgeschotteten Netzwerkzone arbeitet, etwa aus Datenschutzgründen, sollte von Anfang an auf lokale Modelle über Ollama oder einen selbst gehosteten vLLM-Server setzen, statt nachträglich die Infrastruktur umzubauen.

Grundkonzepte: Agents, Tasks, Crews, Tools und Processes

CrewAI baut auf fünf zentralen Bausteinen auf. Wer diese verstanden hat, kann fast jeden Anwendungsfall abbilden, von der einfachen Zwei-Agenten-Kette bis zum verzweigten System mit einem Dutzend spezialisierter Rollen.

  • Agents: einzelne KI-Akteure mit Rolle, Ziel und Backstory, ausgestattet mit eigenen Werkzeugen und optional mit Gedächtnis.
  • Tasks: klar definierte Arbeitseinheiten, die einem Agenten zugewiesen werden und eine erwartete Ausgabe beschreiben.
  • Crews: Teams aus mehreren Agenten, die gemeinsam eine Reihe von Tasks abarbeiten.
  • Tools: Funktionen, die Agenten aufrufen können, etwa Websuche, Datenbankzugriff oder Codeausführung.
  • Processes: die Ablaufsteuerung einer Crew, entweder sequenziell, hierarchisch oder als Hybrid mit Guardrails und Human-in-the-Loop-Schritten.

Zusätzlich bietet CrewAI sogenannte Flows für komplexere, zustandsbehaftete Workflows mit Start-, Listen- und Router-Schritten. Für die meisten Einstiegsprojekte reichen jedoch Agents, Tasks und Crews völlig aus, Flows kommen erst bei mehrstufigen Pipelines mit Persistenz ins Spiel. Ein Flow eignet sich beispielsweise, wenn ein Ergebnis nicht linear durch eine feste Kette von Agenten läuft, sondern abhängig vom Zwischenergebnis unterschiedliche Pfade nimmt, etwa eine Freigabe-Schleife, bei der ein Ergebnis so lange zwischen zwei Agenten hin- und hergereicht wird, bis eine definierte Qualitätsschwelle erreicht ist. Für den Einstieg in dieses Tutorial reicht das Konzept von Crews mit festen Prozessen völlig aus, Flows lassen sich später nachrüsten, ohne die bestehenden Agenten- und Task-Definitionen zu verwerfen.

Schritt 1 bis 3: Projekt anlegen und CrewAI installieren

Im ersten Block richten Sie die Entwicklungsumgebung ein. Eine virtuelle Umgebung verhindert Versionskonflikte mit anderen Python-Projekten auf demselben Rechner.

# Schritt 1: Virtuelle Umgebung anlegen und aktivieren
python3 -m venv crewai-env
source crewai-env/bin/activate      # Windows: crewai-env\Scripts\activate

# Schritt 2: CrewAI und die Tool-Bibliothek installieren
pip install crewai crewai-tools

# Schritt 3: Installation prüfen
python -c "import crewai; print(crewai.__version__)"

Nach dem Aufruf von python -c "import crewai; print(crewai.__version__)" sollte in der Konsole die installierte Versionsnummer erscheinen. Erhalten Sie stattdessen eine Fehlermeldung, prüfen Sie zuerst, ob die virtuelle Umgebung tatsächlich aktiv ist, erkennbar am vorangestellten (crewai-env) in der Kommandozeile. Ein häufiger Anfängerfehler ist, die Installation in der falschen Umgebung durchzuführen, weil das Aktivierungskommando im vorherigen Terminal-Fenster vergessen wurde.

Legen Sie anschließend eine Projektstruktur mit einem eigenen Ordner an, etwa crew_projekt/ mit einer Hauptdatei main.py und einer .env-Datei für Zugangsdaten. Diese Trennung hält Zugangsdaten aus dem Code heraus und erleichtert später das Deployment.

# .env-Datei im Projektordner
OPENAI_API_KEY=sk-ihr-schluessel
ANTHROPIC_API_KEY=sk-ant-ihr-schluessel
SERPER_API_KEY=ihr-serper-schluessel

CrewAI lädt diese Werte automatisch über die Standardbibliothek python-dotenv, sofern sie im Projektverzeichnis liegt und beim Start von main.py eingelesen wird. Tragen Sie die Datei zusätzlich in eine .gitignore ein, damit sie nicht versehentlich in ein Repository gelangt. Dieser Schritt wirkt banal, verhindert in der Praxis aber den mit Abstand häufigsten Grund für kompromittierte API-Keys bei kleineren Open-Source-Projekten.

Schritt 4 und 5: LLM-Provider konfigurieren

CrewAI nutzt eine generische LLM-Schnittstelle und funktioniert daher mit unterschiedlichsten Anbietern. In der Praxis kombinieren viele Entwickler ein leistungsstarkes Cloud-Modell für komplexe Reasoning-Tasks mit einem günstigen oder lokalen Modell für einfachere Schritte. Getestet und dokumentiert sind unter anderem OpenAI, Anthropic Claude und lokale Modelle über Ollama oder vLLM.

# Schritt 4: Cloud-LLM einbinden
from crewai import LLM

cloud_llm = LLM(
    model="anthropic/claude-fable-5.1",
    temperature=0.3
)

# Schritt 5: Alternative mit lokalem Modell über Ollama
local_llm = LLM(
    model="ollama/llama3.1",
    base_url="http://localhost:11434"
)

Für Entwicklung und Tests lohnt sich der lokale Weg über Ollama, weil dabei keine Kosten pro Anfrage anfallen. Sobald ein Projekt in Produktion geht, wechseln viele Teams zumindest für die anspruchsvollsten Agenten auf ein Cloud-Modell, weil lokale Modelle bei komplexem Reasoning oft noch zurückliegen.

Bei der Wahl des Providers zählt neben Preis und Qualität auch das Kontextfenster. Agenten, die lange Dokumente verarbeiten oder umfangreiche Zwischenergebnisse anderer Agenten als Kontext erhalten, profitieren von Modellen mit großem Kontextfenster wie den aktuellen 1M-Token-Varianten von Gemini und Claude. Für kurze, klar abgegrenzte Aufgaben, etwa das Formatieren eines Textabschnitts, reicht dagegen häufig ein kleineres und günstigeres Modell aus, ohne dass die Qualität spürbar leidet.

Schritt 6 und 7: Den ersten Agenten definieren

Ein Agent besteht aus drei Pflichtangaben: Rolle, Ziel und Backstory. Die Backstory klingt zunächst wie Spielerei, beeinflusst aber tatsächlich den Ton und die Qualität der Antworten, weil sie dem Sprachmodell zusätzlichen Kontext liefert. Zusätzlich lassen sich Tools, ein bevorzugtes LLM und Verhaltensoptionen wie Delegation festlegen.

# Schritt 6: Recherche-Agent
from crewai import Agent
from crewai_tools import SerperDevTool

researcher = Agent(
    role="Senior Research Analyst",
    goal="Aktuelle, verlässliche Informationen zu {thema} finden und belegen",
    backstory=(
        "Sie arbeiten seit Jahren als technische Rechercheurin und "
        "prüfen jede Quelle auf Aktualität und Seriosität, bevor Sie "
        "sie in einen Bericht aufnehmen."
    ),
    tools=[SerperDevTool()],
    llm=cloud_llm,
    verbose=True,
    allow_delegation=False
)

# Schritt 7: Schreib-Agent
writer = Agent(
    role="Technical Content Writer",
    goal="Aus Rechercheergebnissen einen klar strukturierten Artikel erstellen",
    backstory=(
        "Sie schreiben seit Jahren technische Artikel für ein "
        "deutschsprachiges Fachpublikum und legen Wert auf präzise, "
        "gut belegte Aussagen."
    ),
    llm=cloud_llm,
    verbose=True,
    allow_delegation=False
)

Der Parameter allow_delegation steuert, ob ein Agent Teilaufgaben an andere Agenten weiterreichen darf. Für einfache, lineare Abläufe bleibt dieser Wert meist auf False, für hierarchische Prozesse mit einem koordinierenden Agenten wird er später auf True gesetzt.

Eine bewährte Faustregel für die Rollenformulierung: je spezifischer, desto besser. Eine Rolle wie Assistent liefert deutlich unschärfere Ergebnisse als eine präzise Rolle wie Senior Research Analyst mit Schwerpunkt auf technischen Quellen. Das gilt genauso für das Ziel. Statt allgemein Informationen sammeln zu formulieren, liefert eine konkrete Zielbeschreibung mit Bezug zum Endergebnis, etwa das Finden von drei belastbaren, aktuellen Quellen zu einem Thema, deutlich konsistentere Resultate über mehrere Läufe hinweg.

Schritt 8 und 9: Tasks erstellen und Erwartungen formulieren

Ein Task beschreibt eine konkrete Arbeitsanweisung und legt fest, welche Ausgabe erwartet wird. Je präziser die Beschreibung, desto verlässlicher das Ergebnis. Über den Parameter context lassen sich Tasks verketten, sodass ein Agent auf das Ergebnis eines vorherigen Tasks zugreifen kann.

# Schritt 8: Recherche-Task
from crewai import Task

research_task = Task(
    description="Recherchiere die drei wichtigsten aktuellen Entwicklungen zu {thema}.",
    expected_output="Eine strukturierte Liste mit drei Kernpunkten inklusive Quellenangaben.",
    agent=researcher
)

# Schritt 9: Schreib-Task mit Bezug zur Recherche
writing_task = Task(
    description="Schreibe basierend auf der Recherche einen Artikelentwurf von rund 300 Wörtern zu {thema}.",
    expected_output="Ein fertiger deutschsprachiger Artikeltext mit Zwischenüberschriften.",
    agent=writer,
    context=[research_task]
)

Der Wert von expected_output wird häufig unterschätzt. CrewAI nutzt diese Beschreibung, um dem Agenten ein klares Format vorzugeben. Wer hier vage bleibt, bekommt in der Praxis inkonsistente Ergebnisse, weil das Sprachmodell keine feste Vorlage für die Antwortstruktur hat.

Der Parameter context verdient besondere Aufmerksamkeit, weil er die eigentliche Zusammenarbeit zwischen Agenten herstellt. Ohne ihn arbeitet jeder Task isoliert, mit ihm reicht CrewAI die vollständige Ausgabe der referenzierten Tasks als zusätzlichen Kontext an den nächsten Agenten weiter. Bei längeren Ketten mit vier oder fünf aufeinanderfolgenden Tasks kann der übergebene Kontext dadurch schnell wachsen, was wiederum das Kontextfenster des gewählten Modells und damit die Kosten pro Aufruf beeinflusst.

Schritt 10: Tools an Agenten anbinden

Neben vorgefertigten Tools aus der crewai-tools-Bibliothek, etwa für Websuche oder Dateizugriff, lassen sich eigene Funktionen mit wenigen Zeilen Code als Tool registrieren. Damit können Agenten auf interne APIs, Datenbanken oder Berechnungen zugreifen.

# Schritt 10: Eigenes Tool definieren
from crewai.tools import tool

@tool("Wortanzahl-Tool")
def count_words(text: str) -> str:
    """Zählt die Wörter in einem gegebenen Text und gibt das Ergebnis zurück."""
    anzahl = len(text.split())
    return f"Der Text enthält {anzahl} Wörter."

# Tool einem bestehenden Agenten hinzufügen
writer.tools.append(count_words)

Ein sauber dokumentierter Docstring ist hier keine Nebensache. CrewAI reicht diese Beschreibung an das Sprachmodell weiter, damit es entscheiden kann, wann das Tool sinnvoll eingesetzt wird. Fehlt die Beschreibung oder bleibt sie zu allgemein, ruft der Agent das Tool im schlechtesten Fall gar nicht oder zur falschen Zeit auf.

Die mitgelieferte crewai-tools-Bibliothek deckt bereits gängige Anwendungsfälle ab, darunter Websuche, das Auslesen von PDF- und CSV-Dateien, Web-Scraping einzelner Seiten sowie Datei- und Verzeichniszugriff. Für unternehmensspezifische Integrationen, etwa den Zugriff auf ein internes Ticketsystem oder eine firmeneigene REST-API, lohnt sich fast immer ein eigenes Tool nach dem oben gezeigten Muster, da sich damit exakt die Berechtigungen und Datenfelder abbilden lassen, die der jeweilige Agent tatsächlich benötigt.

Schritt 11 und 12: Crew zusammenstellen und starten

Im letzten Schritt fügen Sie Agenten und Tasks zu einer Crew zusammen und legen den Ablauf-Prozess fest. Bei Process.sequential arbeitet die Crew die Tasks strikt in der angegebenen Reihenfolge ab. Bei Process.hierarchical übernimmt ein zusätzlicher Manager-Agent die Koordination und kann Aufgaben dynamisch verteilen.

# Schritt 11: Crew mit sequenziellem Prozess
from crewai import Crew, Process

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    verbose=True
)

# Schritt 12: Crew starten
result = crew.kickoff(
    inputs={"thema": "Multi-Agenten-Systeme in der Softwareentwicklung"}
)
print(result)

Für komplexere Projekte mit mehr als zwei oder drei Agenten lohnt sich der hierarchische Prozess, weil ein Manager-Agent die Reihenfolge situativ anpassen kann, statt eine starre Kette abzuarbeiten.

# Hierarchischer Prozess mit Manager-Agent
project_manager = Agent(
    role="Projektleiter",
    goal="Die Arbeit von Researcher und Writer koordinieren und die Qualität sichern",
    backstory="Sie leiten seit Jahren redaktionelle Projekte und achten auf Termine und Konsistenz.",
    allow_delegation=True,
    llm=cloud_llm
)

crew_hierarchical = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.hierarchical,
    manager_agent=project_manager,
    verbose=True
)

Nach dem Aufruf von kickoff() gibt CrewAI im Verbose-Modus jeden Zwischenschritt in der Konsole aus. Ein typischer Ausschnitt sieht so aus:

[Senior Research Analyst] Starte Task: Recherchiere die drei wichtigsten...
[Senior Research Analyst] Nutze Tool: SerperDevTool
[Senior Research Analyst] Task abgeschlossen. Ausgabe an nächsten Agenten übergeben.
[Technical Content Writer] Starte Task: Schreibe Artikelentwurf...
[Technical Content Writer] Task abgeschlossen.

## Finales Ergebnis:
Multi-Agenten-Systeme verändern die Softwareentwicklung, indem sie
komplexe Aufgaben auf spezialisierte KI-Rollen aufteilen...

Das Ergebnis liegt als String oder, bei strukturierten Outputs mit Pydantic-Modellen, als typisiertes Objekt vor. Damit lässt es sich direkt in nachgelagerte Systeme wie ein CMS oder eine Datenbank einspeisen.

Memory, Wissensbasis und RAG-Integration

Ohne Gedächtnis vergisst jeder Agent nach Abschluss eines Laufs sofort alles. CrewAI unterscheidet drei Memory-Typen: Kurzzeit-Memory für den Kontext innerhalb eines laufenden Prozesses, Langzeit-Memory für Wissen aus früheren Läufen und Entity-Memory für Informationen zu konkreten Entitäten wie Kunden oder Projekten. Praktisch werden diese Speicher meist über eine Vektordatenbank angebunden, wodurch sich klassische RAG-Muster direkt in die Agenten-Architektur integrieren lassen.

Für den Einstieg genügt es, Memory bei der Crew-Erstellung zu aktivieren. Wer eine eigene Wissensbasis anbinden will, etwa interne Dokumentation oder Produktdaten, verbindet einen Agenten zusätzlich mit einer Vektordatenbank wie Chroma, Weaviate oder Pinecone und stellt darüber eine RAG-Pipeline bereit. Wer noch keine eigene Pipeline hat, findet in unserem Artikel zum Aufbau einer RAG-Pipeline eine Schritt-für-Schritt-Anleitung, die sich direkt als Wissensquelle für CrewAI-Agenten nutzen lässt.

In der Praxis zahlt sich Memory vor allem bei wiederkehrenden Aufgaben aus. Eine Support-Crew, die Kundenanfragen bearbeitet, kann mit aktiviertem Entity-Memory über mehrere Anfragen hinweg auf bereits bekannte Kundendaten zugreifen, statt bei jeder neuen Konversation bei null anzufangen. Eine Recherche-Crew, die regelmäßig zum gleichen Themenfeld arbeitet, profitiert wiederum vom Langzeit-Memory, weil bereits gefundene und geprüfte Quellen nicht bei jedem Lauf erneut gesucht werden müssen.

# Memory für die Crew aktivieren
crew_mit_memory = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    memory=True,
    verbose=True
)

CrewAI im Vergleich: LangGraph, AutoGen und OpenAI Agents SDK

CrewAI konkurriert mit mehreren etablierten Frameworks für Multi-Agenten-Systeme. Die Unterschiede liegen vor allem in der zugrundeliegenden Architektur und im Abstraktionsgrad.

FrameworkKernabstraktionAbhängigkeitenFokus
CrewAICrews, Tasks, Processes, FlowsStandalone, keine Abhängigkeit von LangChainRollenbasierte Agenten-Teams für produktive Workflows
LangGraphGraph mit Nodes und EdgesTeil des LangChain-ÖkosystemsExplizite Zustandsmaschinen für komplexe, verzweigte Abläufe
Microsoft AutoGenKonversationelle Multi-Agent-ChatsStandalone (Microsoft)Programmatische Agenten-zu-Agenten-Konversation
OpenAI Agents SDKAgent- und Tool-KonfigurationAn OpenAI-Plattform gebundenEinfache Single- bis Multi-Agent-Setups mit Funktionsaufrufen

Wer bereits mit LangChain arbeitet, findet in LangGraph die naheliegende Erweiterung für Multi-Agenten-Workflows. CrewAI punktet dagegen mit einer flacheren Lernkurve, weil Rollen, Aufgaben und Teams sich fast wie eine Organigramm-Struktur modellieren lassen, statt Zustandsübergänge in einem Graphen zu definieren. AutoGen eignet sich besonders für Szenarien, in denen Agenten frei miteinander diskutieren sollen, etwa bei Debatten- oder Simulationsanwendungen.

Für die Wahl des passenden Frameworks lohnt sich eine ehrliche Bestandsaufnahme des eigenen Projekts. Wer bereits tief in LangChain investiert ist und Vektorstores, Retriever und Chains im Einsatz hat, spart sich mit LangGraph den Umstieg auf ein komplett neues Ökosystem. Wer dagegen bei null anfängt und vor allem klar abgegrenzte Rollen mit definierten Aufgaben abbilden will, kommt mit CrewAI in der Regel schneller zu einem funktionierenden Prototyp. Das OpenAI Agents SDK eignet sich wiederum besonders, wenn ein Projekt ohnehin ausschließlich auf OpenAI-Modelle setzt und keine Multi-Provider-Flexibilität benötigt.

Was ein Multi-Agenten-Lauf kostet: LLM-Provider im Preisvergleich

Ein oft unterschätzter Punkt: Eine Crew mit drei Agenten und mehreren Tasks kann pro Durchlauf leicht ein Dutzend LLM-Aufrufe auslösen. Die Wahl des Modells wirkt sich deshalb direkt auf die Betriebskosten aus. Die folgende Tabelle zeigt aktuelle Modelle, die sich als LLM-Backend für CrewAI eignen, mit Stand September 2026.

Modell / ProviderKontextfensterKostenEmpfohlen für
Gemini 3.8 Flash (Google)1M Tokensab 0,75 $ / 1M Input-Tokens, 3,75 $ / 1M Output-Tokensschnelle, günstige Standard-Agenten
Claude Fable 5.1 (Anthropic)1M Tokens10 $ / 1M Input-Tokens, 50 $ / 1M Output-Tokenskomplexe Reasoning- und Coding-Tasks
DeepSeek V4 (offene Gewichte)1M TokensMIT-Lizenz, selbst gehostet ohne API-Gebührkostensensitive Produktionsläufe
Mistral Medium 3.5256.000 Tokensmodifizierte MIT-Lizenz, offene GewichteEU-Hosting und Datenschutz-Anforderungen
lokale Modelle via Ollamamodellabhängig0 € API-Kosten, nur Hardware und StromEntwicklung, Tests, abgeschottete Umgebungen

In der Praxis bewährt sich ein gemischter Ansatz: das teurere Premium-Modell nur für den Agenten, der tatsächlich komplexes Reasoning braucht, günstigere oder lokale Modelle für Routineaufgaben wie Formatierung oder einfache Zusammenfassungen. So bleiben die Kosten pro Crew-Lauf kalkulierbar, auch wenn die Anzahl der Agenten wächst.

Ein weiterer Kostenfaktor wird beim Einstieg oft übersehen: Retry-Logik. Schlägt die Validierung eines strukturierten Outputs fehl oder liefert ein Agent eine unbrauchbare Antwort, ruft CrewAI das zugrundeliegende Modell automatisch erneut auf. Bei einer Crew mit mehreren Agenten und mehreren Wiederholungsversuchen pro Task kann sich die tatsächliche Zahl der LLM-Aufrufe gegenüber der reinen Task-Anzahl leicht verdoppeln oder verdreifachen. Wer die Kosten im Blick behalten will, sollte deshalb von Anfang an ein Budget-Limit pro Crew-Lauf definieren und dieses über das eigene Logging überwachen, statt sich allein auf die Kostenübersicht des LLM-Providers zu verlassen.

Häufige Fehler beim Einstieg in CrewAI

Die folgenden fünf Fehler tauchen in Support-Foren und GitHub-Issues immer wieder auf und lassen sich mit etwas Vorbereitung vermeiden.

  • Zu vage Task-Beschreibungen: Ohne ein klar formuliertes expected_output liefert die Crew inkonsistente Ergebnisse, weil dem Sprachmodell die Zielstruktur fehlt.
  • Fehlende Fehlerbehandlung bei Tools: Ruft ein Tool eine externe API auf, die kurzzeitig nicht erreichbar ist, bricht ohne Try-Except-Block der gesamte Crew-Lauf ab.
  • Zu viele Agenten für eine einfache Aufgabe: Für eine simple Textzusammenfassung reicht meist ein einzelner Agent. Mehrere Agenten erhöhen Latenz und Kosten, ohne die Qualität spürbar zu verbessern.
  • Delegation ohne Kontrolle: Wird allow_delegation=True unüberlegt gesetzt, können Agenten Aufgaben in Schleifen hin- und herreichen, was Zeit und API-Budget frisst.
  • API-Keys im Code statt in der .env-Datei: Landen Zugangsdaten versehentlich in einem öffentlichen Repository, ist das nicht nur ein Sicherheitsrisiko, sondern verursacht häufig auch unerwartete Kosten durch Missbrauch.

Troubleshooting: Lösungen für die häufigsten Probleme

Auch bei sauberer Vorbereitung tauchen typische Stolpersteine auf. Die folgende Übersicht deckt die häufigsten Fehlermeldungen und ihre Lösung ab, gesammelt aus GitHub-Issues, Community-Foren und eigenen Testläufen mit dem oben gezeigten Beispielprojekt.

ProblemUrsacheLösung
ModuleNotFoundError: crewaiVirtuelle Umgebung nicht aktiviert oder Installation fehlgeschlagensource crewai-env/bin/activate prüfen, danach pip install crewai erneut ausführen
AuthenticationError vom LLM-ProviderAPI-Key fehlt, ist abgelaufen oder falsch benannt.env-Datei und Variablennamen mit der Provider-Dokumentation abgleichen
Agent hängt in einer EndlosschleifeDelegation ohne klare Abbruchbedingungallow_delegation=False setzen oder maximale Iterationen begrenzen
Task liefert leere oder abgeschnittene AntwortKontextfenster des Modells überschrittenEingabetext kürzen oder Modell mit größerem Kontextfenster wählen
Tool wird nicht aufgerufenDocstring des Tools zu unpräziseDocstring konkretisieren und Anwendungsfall im Task erwähnen
Sehr hohe Laufzeit pro Crew-DurchlaufZu viele sequenzielle LLM-AufrufeProzess vereinfachen oder Tasks parallelisierbar gestalten
Hierarchischer Prozess bricht abKein manager_agent oder manager_llm definiertManager-Agent oder Manager-LLM explizit angeben
Ergebnis widerspricht dem Task-ZielBackstory und Rolle des Agenten passen nicht zur AufgabeRolle, Ziel und Backstory präziser auf die Aufgabe zuschneiden

Ein Profi-Tipp für die Fehlersuche: Starten Sie jede neue Crew zunächst mit verbose=True und einem einzigen Agenten. Erst wenn dieser zuverlässig funktioniert, erweitern Sie schrittweise um weitere Agenten und Tasks. Das reduziert die Fehlerquellen bei der Diagnose erheblich und spart bei komplexen Setups viel Zeit.

Ein zweiter praktischer Kniff betrifft die Kosten während der Entwicklung. Solange Sie an Prompt-Formulierungen und der Task-Struktur feilen, lohnt es sich, testweise auf ein günstiges oder lokales Modell umzustellen. Erst wenn die Struktur der Crew steht und zuverlässig funktioniert, wechseln Sie für den finalen Test zurück auf das eigentlich vorgesehene Produktions-Modell. So vermeiden Sie, während der ohnehin fehleranfälligen Experimentierphase unnötig hohe Kosten bei einem Premium-Anbieter zu verursachen.

Deployment: Eine Crew in Produktion betreiben

Ein Crew-Skript, das lokal im Terminal läuft, unterscheidet sich deutlich von einer Crew, die zuverlässig in Produktion läuft. Für den produktiven Betrieb hat sich eine Containerisierung mit Docker bewährt, weil sie Python-Version, Abhängigkeiten und Umgebungsvariablen sauber kapselt und das Deployment auf unterschiedlichen Servern reproduzierbar macht.

# Dockerfile für eine produktive CrewAI-Anwendung
FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "main.py"]

In der requirements.txt genügen für das Beispielprojekt die Einträge crewai und crewai-tools, in größeren Projekten kommen häufig noch ein Web-Framework für einen API-Endpunkt sowie ein Client für die verwendete Vektordatenbank hinzu. API-Keys übergeben Sie beim Deployment nicht über die .env-Datei im Image, sondern als Umgebungsvariablen über die jeweilige Hosting-Plattform, etwa mit docker run --env-file .env crew-image oder über die Secrets-Verwaltung eines Kubernetes-Clusters.

Für wiederkehrende Läufe, etwa eine tägliche Recherche-Crew, reicht häufig ein einfacher Cronjob oder ein geplanter Task in der jeweiligen Cloud-Umgebung. Wichtiger als die Wahl des Schedulers ist ein durchdachtes Logging: Da jeder Agent mehrere LLM-Aufrufe auslöst, sollten Sie Start- und Endzeit jedes Tasks sowie die verbrauchten Tokens protokollieren. Nur so lassen sich Kostenanstiege oder Performance-Probleme frühzeitig erkennen, bevor sie zu einem größeren Problem werden.

Sobald mehrere Crews parallel laufen, etwa eine für Recherche und eine zweite für Kundensupport, lohnt sich eine zentrale Warteschlange, die eingehende Aufträge verteilt, statt jede Crew direkt und synchron aus einer Web-Anfrage heraus zu starten. Das entkoppelt die Antwortzeit einer Anwendung von der tatsächlichen Laufzeit eines Crew-Durchlaufs, die je nach Anzahl der Agenten und Tasks zwischen wenigen Sekunden und mehreren Minuten liegen kann. In der Praxis reicht dafür häufig eine einfache Job-Queue mit einem Worker-Prozess, der die Crew im Hintergrund ausführt und das Ergebnis anschließend über eine Callback-URL oder eine Datenbank-Tabelle zurückmeldet.

Erweiterte Tipps für den produktiven Einsatz

Sobald die Grundlagen sitzen, lohnt sich der Blick auf einige fortgeschrittene Funktionen, die den Unterschied zwischen einem Demo-Projekt und einem produktionstauglichen System ausmachen. Die folgenden fünf Punkte tauchen in produktiven CrewAI-Deployments deutlich häufiger auf als in Einstiegs-Tutorials, sind aber genau die Stellschrauben, an denen sich Zuverlässigkeit und Kosten eines Systems im Alltag entscheiden.

  • Strukturierte Ausgaben mit Pydantic: Statt reinen Text zurückzugeben, lässt sich ein Task auf ein festes Datenmodell festlegen. Das erleichtert die Weiterverarbeitung in nachgelagerten Systemen erheblich, weil Sie sich auf ein definiertes Schema statt auf freien Text verlassen können.
  • Guardrails pro Task: Über Validierungsfunktionen lässt sich prüfen, ob eine Ausgabe bestimmten Kriterien entspricht, etwa eine maximale Zeichenlänge oder das Vorhandensein bestimmter Pflichtfelder, bevor das Ergebnis an den nächsten Agenten weitergereicht wird.
  • Callbacks für Monitoring: Mit Callback-Funktionen lassen sich Zwischenschritte an ein externes Monitoring-System senden, etwa um Latenz und Tokenverbrauch pro Task in einem Dashboard sichtbar zu machen.
  • Asynchrone Task-Ausführung: Tasks, die nicht voneinander abhängen, lassen sich parallelisieren, statt sie strikt sequenziell abzuarbeiten. Das senkt die Gesamtlaufzeit einer Crew spürbar, sobald mehr als zwei bis drei unabhängige Teilaufgaben anfallen.
  • Caching von Tool-Ergebnissen: Ruft ein Tool wiederholt dieselbe externe Ressource ab, etwa eine Websuche zum gleichen Begriff, spart ein einfacher Cache sowohl Zeit als auch API-Kosten bei wiederholten Crew-Läufen.
# Strukturierte Ausgabe mit Pydantic erzwingen
from pydantic import BaseModel
from typing import List

class RechercheErgebnis(BaseModel):
    kernpunkte: List[str]
    quellen: List[str]

research_task = Task(
    description="Recherchiere die drei wichtigsten aktuellen Entwicklungen zu {thema}.",
    expected_output="Ein strukturiertes Ergebnis mit Kernpunkten und Quellen.",
    agent=researcher,
    output_pydantic=RechercheErgebnis
)

Der Parameter output_pydantic zwingt das Sprachmodell, seine Antwort in das vorgegebene Schema zu pressen. Schlägt die Validierung fehl, wiederholt CrewAI den Aufruf automatisch mit einem präzisierten Prompt. Für produktive Pipelines, die direkt in eine Datenbank oder ein CMS schreiben, ist dieser Ansatz deutlich robuster als das Parsen von Freitext mit regulären Ausdrücken.

Von Open Source zu CrewAI AMP

Die Open-Source-Version von CrewAI bleibt kostenlos und deckt die meisten Einstiegs- und Mittelstandsprojekte vollständig ab. Für Teams, die Agenten-Systeme im großen Maßstab betreiben, bietet CrewAI mit AMP eine kommerzielle Erweiterung. Laut offizieller Projektbeschreibung liegt der Fokus von AMP auf rollenbasierter Zugriffskontrolle (RBAC), sicheren Deployments sowie Auditing- und Governance-Funktionen für Unternehmen, die viele Crews parallel verwalten müssen. Konkrete Preisangaben veröffentlicht CrewAI bislang nicht öffentlich.

Öffentlich dokumentierte Sicherheitslücken oder CVEs zum Framework selbst sind mit Stand September 2026 nicht bekannt. Trotzdem gelten die üblichen Grundregeln für produktive Deployments: Zugangsdaten niemals im Code hinterlegen, Tool-Berechtigungen auf das Nötigste beschränken und externe API-Aufrufe von Agenten protokollieren, um ungewöhnliches Verhalten frühzeitig zu erkennen.

Der Wechsel zu AMP lohnt sich nach Angaben des Projekts vor allem für Organisationen, die bereits mehrere Crews parallel betreiben und dabei den Überblick über Zugriffsrechte, Kosten und Verhalten einzelner Agenten behalten müssen. Für ein einzelnes Team mit einer überschaubaren Zahl an Crews reicht die kostenlose OSS-Version in aller Regel vollkommen aus, insbesondere solange sich die Governance-Anforderungen noch über Code-Reviews und die im Tutorial gezeigten Logging-Maßnahmen abdecken lassen.

Praxisbeispiele: Wofür Unternehmen CrewAI einsetzen

In der CrewAI-Community und in offiziellen Beispiel-Repositories tauchen vor allem vier Anwendungsmuster wiederkehrend auf. Recherche-Automatisierung, bei der ein Rechercheur-Agent Quellen sammelt und ein zweiter Agent daraus eine Zusammenfassung erstellt. Content-Pipelines mit getrennten Rollen für Recherche, Text und Lektorat, ähnlich dem Beispiel aus diesem Tutorial. Projektplanung, bei der Agenten Aufgaben schätzen, priorisieren und Ressourcen zuteilen. Und mehragentige Kundensupport-Systeme, in denen ein FAQ-Agent einfache Anfragen beantwortet und komplexere Fälle an einen Eskalations-Agenten weiterreicht.

Gemeinsam ist allen Beispielen, dass die Aufteilung in klar abgegrenzte Rollen die Nachvollziehbarkeit verbessert. Wenn ein Ergebnis falsch ist, lässt sich anhand der Verbose-Logs genau erkennen, welcher Agent an welcher Stelle abgewichen ist. Das erleichtert Debugging und Qualitätssicherung deutlich gegenüber einem einzelnen, monolithischen Prompt.

Offizielle Beispiel-Repositories wie crewAI-examples zeigen zusätzlich vollständige Referenzimplementierungen, an denen sich eigene Projekte orientieren können, etwa für automatisierte Marktanalysen oder mehrstufige Content-Freigabeprozesse. Community-Projekte demonstrieren darüber hinaus Anwendungen für automatisierte Projektplanung, bei der Agenten Aufwandsschätzungen erstellen und Abhängigkeiten zwischen Arbeitspaketen erkennen, sowie für Reise- und Ressourcenplanung, bei der mehrere Agenten parallel Optionen recherchieren und anschließend gegeneinander abwägen.

Beim Übertragen dieser Beispiele auf ein eigenes Projekt hilft es, zunächst auf Papier zu skizzieren, welche Rollen tatsächlich gebraucht werden, bevor der erste Agent im Code entsteht. Häufig zeigt sich dabei, dass zwei oder drei klar getrennte Rollen ausreichen, während ein zu ambitioniert geplantes System mit sieben oder acht Agenten in der Praxis schwerer zu debuggen ist, ohne dass sich die Ergebnisqualität proportional verbessert. Ein schrittweiser Ausbau, beginnend mit der im Tutorial gezeigten Zwei-Agenten-Crew, hat sich in der Praxis als deutlich verlässlicherer Weg erwiesen als ein von Anfang an komplexes Setup.

Wer CrewAI-Agenten mit einem lokal gehosteten Modell betreiben will, findet eine passende Grundlage in unserer Anleitung zum Ollama-Setup für lokale LLMs. Für die Anbindung von Anthropic-Modellen wie Claude hilft der Artikel zum Claude API Setup, für den direkten Vergleich verschiedener Modelle eignet sich unser LLM-Benchmark-Setup. Wer die Agenten später feinabstimmen möchte, findet im Tutorial zu LLM-Fine-Tuning mit LoRA die nötigen Grundlagen, und für eine grafische Oberfläche zum Testen einzelner Modelle bietet sich Open WebUI an.

Häufig gestellte Fragen zu CrewAI

Ist CrewAI kostenlos?
Die Open-Source-Version von CrewAI ist unter einer offenen Lizenz kostenlos nutzbar. Kosten entstehen ausschließlich durch die verwendeten LLM-APIs oder durch die kommerzielle Enterprise-Plattform CrewAI AMP, falls Sie diese einsetzen.

Brauche ich LangChain, um CrewAI zu nutzen?
Nein. CrewAI ist ein eigenständiges Framework ohne Abhängigkeit von LangChain oder anderen Agenten-Bibliotheken. Sie können es direkt nach der Installation mit pip install crewai verwenden.

Welche LLMs unterstützt CrewAI?
CrewAI arbeitet über eine generische LLM-Schnittstelle mit OpenAI-Modellen, Anthropic Claude sowie lokalen Modellen über Ollama oder vLLM. Die Wahl des Modells legen Sie pro Agent individuell fest.

Was ist der Unterschied zwischen sequenziellem und hierarchischem Prozess?
Beim sequenziellen Prozess arbeitet die Crew Tasks strikt in vorgegebener Reihenfolge ab. Beim hierarchischen Prozess koordiniert ein zusätzlicher Manager-Agent die Verteilung der Aufgaben und kann flexibler reagieren, etwa wenn Zwischenergebnisse eine Anpassung erfordern.

Wie viel kostet ein typischer CrewAI-Lauf?
Das hängt stark vom gewählten Modell und der Anzahl der Agenten und Tasks ab. Da jeder Agent pro Task mindestens einen LLM-Aufruf auslöst, steigen die Kosten mit der Komplexität der Crew. Ein Mix aus günstigen und Premium-Modellen sowie ein Budget-Limit im eigenen Logging helfen, die Ausgaben im Griff zu behalten, gerade wenn Retry-Versuche bei fehlgeschlagenen Validierungen die tatsächliche Zahl der Aufrufe erhöhen.

Kann ich CrewAI mit einer eigenen Wissensdatenbank verbinden?
Ja. Über Memory-Funktionen und die Anbindung an Vektordatenbanken wie Chroma oder Weaviate lassen sich Agenten mit unternehmensinternem Wissen ausstatten und klassische RAG-Muster umsetzen.

Gibt es bekannte Sicherheitslücken in CrewAI?
Mit Stand September 2026 sind keine öffentlich dokumentierten CVEs zum Framework selbst bekannt. Wie bei jedem Agenten-System sollten Sie trotzdem Zugangsdaten schützen und Tool-Berechtigungen einschränken.

Lohnt sich CrewAI für kleine Projekte?
Für sehr einfache Aufgaben mit nur einem klaren Arbeitsschritt reicht oft ein einzelner Agent oder ein direkter API-Aufruf. CrewAI zahlt sich vor allem dann aus, wenn eine Aufgabe sich sinnvoll in mehrere spezialisierte Rollen aufteilen lässt.

Wie unterscheidet sich CrewAI von einem einfachen Prompt-Chaining?
Beim reinen Prompt-Chaining reichen Sie Text manuell von einem API-Aufruf zum nächsten weiter und kümmern sich selbst um Fehlerbehandlung, Kontextübergabe und Reihenfolge. CrewAI übernimmt diese Koordination als Framework, bietet feste Konzepte für Rollen, Speicher und Werkzeuge und lässt sich dadurch deutlich einfacher warten, sobald ein Projekt über zwei oder drei Schritte hinauswächst.

Kann ich mehrere CrewAI-Crews miteinander verknüpfen?
Ja. Größere Systeme bestehen häufig aus mehreren spezialisierten Crews, deren Ergebnisse über CrewAI Flows oder eine übergeordnete Orchestrierungsschicht miteinander verbunden werden. Das eignet sich besonders, wenn unterschiedliche Fachbereiche, etwa Recherche und Qualitätssicherung, klar getrennt bleiben sollen.