CrewAI + Ollama : mehrere KI-Agenten in lokal

#Warum eine Crew mit CrewAI lokal orchestrieren?

Der Multi-Agenten-Ansatz geht von einer einfachen Beobachtung aus: Eine komplexe Aufgabe auf mehrere spezialisierte Agenten aufzuteilen, liefert bessere Ergebnisse als ein einziger riesiger Prompt. Jeder Agent hat eine klare Rolle, ein präzises Ziel und sieht nur seinen Teil der Arbeit. CrewAI ist das Python-Framework, das diese Aufteilung formalisiert — Rollen, Aufgaben, sequenzielle oder hierarchische Zusammenarbeit — ohne den Aufwand eines Zustandsgraphen, den man selbst verknüpfen muss.

Diese Crew mit Ollama statt mit GPT-4 oder Claude zu betreiben, verändert drei Dinge. Erstens die Vertraulichkeit: Eine Multi-Agent-Pipeline vervielfacht die Modellaufrufe und damit die möglichen Datenabflüsse an Dritte; lokal verlässt nichts den Rechner. Zweitens die Kosten: Eine gesprächige Crew kann pro Ausführung Hunderttausende Tokens verbrauchen, was bei einer pro Token abgerechneten API schnell teuer wird – lokal sind die Grenzkosten null. Drittens die Kontrolle: Sie wählen das Modell, die Quantisierung und den Kontext und können ohne Kontingente oder Rate-Limits iterieren.

#Die 4 Bausteine von CrewAI

Bevor Sie eine Zeile schreiben, müssen Sie die Begriffe kennen. CrewAI basiert auf vier Objekten, die ineinandergreifen. Wer sie versteht, vermeidet 90 % der Fehler beim Entwurf einer Crew.

Agent

Ein LLM mit einer Identität: eine Rolle („Marktanalyst“), ein Ziel (goal) und eine Hintergrundgeschichte (backstory), die seinem Verhalten einen Rahmen geben. Jeder Agent kann sein eigenes Ollama-Modell verwenden.

Task

Eine Arbeitseinheit, die einem Agenten übertragen wird: eine Beschreibung, ein erwartetes Ergebnis (expected_output) und häufig auch Werkzeuge. Die konkrete Anweisung steckt in der Aufgabe, nicht im Agenten.

Tool

Eine externe Funktion, die ein Agent aufrufen kann: Websuche, Lesen einer Datei, SQL-Abfrage, Berechnung. Ohne Werkzeuge kann ein Agent nur über das nachdenken, was er bereits weiß.

Crew

Das Team: die Liste der Agenten, die Liste der Aufgaben und der Prozess, der die Ausführungsreihenfolge bestimmt (sequential oder hierarchical). Dieses Objekt starten Sie mit kickoff().

Zum Prozess ist eine Klarstellung nötig. Im Modus sequential werden die Aufgaben in der festgelegten Reihenfolge ausgeführt, und die Ausgabe einer Aufgabe dient als Eingabe für die nächste – ideal für eine Kette aus Recherche → Schreiben → Korrekturlesen. Im Modus hierarchical delegiert und koordiniert ein „Manager“-Agent (ein eigens dafür vorgesehenes LLM) die anderen Agenten. Der hierarchische Modus ist leistungsfähiger, stellt aber deutlich höhere Anforderungen an ein lokales Modell, da der Manager überlegen muss, wer was übernimmt: Beginnen Sie immer mit dem sequenziellen Modus.

#Voraussetzungen und Modellauswahl

Ollama funktionsfähig

Daemon gestartet, Endpunkt unter http://localhost:11434. Prüfen Sie mit „ollama list“, ob mindestens ein Modell vorhanden ist, das Tools verwenden kann.

Python 3.10+ und ein venv

CrewAI lässt sich sauber in einer isolierten virtuellen Umgebung bereitstellen. Vermeiden Sie die Installation in der Python-Umgebung des Systems.

VRAM und Geduld

Multi-Agenten-Systeme führen Modellaufrufe nacheinander aus: Jede Aufgabe erfordert einen oder mehrere Anfrage-Antwort-Zyklen mit dem Modell. Planen Sie mindestens ein Modell mit 8 Milliarden Parametern ein, idealerweise mit 12 bis 24 Milliarden, damit das Schlussfolgern zuverlässig bleibt.

Ein toolfähiges Modell

Um Agenten mit Werkzeugen auszustatten, benötigt man ein Modell, das Funktionen aufrufen kann: Qwen 3.5, Qwen 3.8, Mistral Small oder GLM 4.7 Flash. Ein Modell ohne Werkzeugverwendung kann nur textbasiert denken.

#CrewAI installieren und mit Ollama verbinden

CrewAI wird über pip installiert. Das Paket crewai-tools bietet zusätzlich eine Bibliothek von fertigen Werkzeugen (Suche, Dateien, Scraping) an.

# Créer et activer un environnement virtuel
python -m venv .venv
source .venv/bin/activate   # Windows : .venv\Scripts\activate

# Installer CrewAI et sa bibliothèque d'outils
pip install crewai crewai-tools

Der entscheidende Punkt bei der lokalen Anbindung: CrewAI nutzt LiteLLM, um mit den Modellen zu kommunizieren. Um Ollama anzusprechen, stellt man dem Modellnamen das Präfix „ollama/“ voran und setzt die Basis-URL auf die Adresse des lokalen Daemons. Stellen Sie sicher, dass Sie das Modell zuvor heruntergeladen haben.

# Un modèle solide et tool-capable pour les agents
ollama pull qwen3.5:9b

# Un modèle plus léger pour les tâches simples (optionnel)
ollama pull qwen3.5:4b

from crewai import LLM

# Un LLM CrewAI branché sur Ollama en local
local_llm = LLM(
    model="ollama/qwen3.5:9b",
    base_url="http://localhost:11434",
    temperature=0.3,   # bas = plus déterministe, utile pour une crew
)

#Erste Crew: Rollen und Aufgaben definieren

Bauen wir eine klassische und sofort nützliche Crew auf: einen Rechercheur, der Informationen zusammenträgt, und anschließend einen Redakteur, der sie aufbereitet. Dieses Grundgerüst verwenden wir für die laufende Informationsbeobachtung, die Zusammenfassung von Dokumenten oder die Erstellung von Inhalten wieder. Zuerst definieren wir die Agenten mit klaren Rollen.

from crewai import Agent

chercheur = Agent(
    role="Analyste de recherche",
    goal="Rassembler des faits précis et vérifiables sur {sujet}",
    backstory=(
        "Tu es un analyste rigoureux. Tu distingues les faits "
        "des opinions et tu ne retiens que l'information solide."
    ),
    llm=local_llm,
    verbose=True,
)

redacteur = Agent(
    role="Rédacteur technique francophone",
    goal="Produire une synthèse claire et structurée en français",
    backstory=(
        "Tu écris pour un public technique. Tu vas droit au but, "
        "sans jargon inutile ni remplissage marketing."
    ),
    llm=local_llm,
    verbose=True,
)

Die Rolle, das Ziel und die Hintergrundgeschichte sind keine bloße Dekoration: Sie bilden den Systemprompt jedes Agenten. Eine vage Rolle („Assistent“) ergibt einen vagen Agenten. Seien Sie konkret und geben Sie eine Haltung vor – das verhindert, dass ein kleines Modell den vorgegebenen Rahmen verlässt. Beachten Sie den Platzhalter {sujet}: CrewAI setzt ihn beim Start anhand der Eingaben ein.

Dann folgt der Kern der Arbeit: die Aufgaben. Jede Aufgabe verweist auf einen Agenten, beschreibt, was er erstellen soll, und legt vor allem expected_output fest. Dieses Feld ist der am meisten unterschätzte Hebel zur Verbesserung der Qualität in CrewAI: Je konkreter es ist, desto genauer ist die Ausgabe vorgegeben.

from crewai import Task

tache_recherche = Task(
    description=(
        "Recherche les points clés sur {sujet}. Identifie 5 à 7 "
        "faits marquants, chiffrés quand c'est possible."
    ),
    expected_output="Une liste à puces de 5 à 7 faits sourcés et concis.",
    agent=chercheur,
)

tache_redaction = Task(
    description=(
        "À partir des faits rassemblés, rédige une synthèse "
        "structurée de 300 mots sur {sujet}, en français."
    ),
    expected_output="Un texte de ~300 mots avec un titre et 3 sections.",
    agent=redacteur,
    context=[tache_recherche],   # nourrie par la sortie de la recherche
)

Der Parameter context verknüpft die Aufgaben ausdrücklich: Die Schreibaufgabe erhält die Ausgabe der Recherche. Im sequenziellen Modus ist die Abfolge bereits implizit vorgegeben, aber die Angabe von context macht die Abhängigkeit nachvollziehbar und sorgt für eine zuverlässigere Informationsübertragung. Zum Schluss wird die Crew zusammengestellt und gestartet.

from crewai import Crew, Process

crew = Crew(
    agents=[chercheur, redacteur],
    tasks=[tache_recherche, tache_redaction],
    process=Process.sequential,
    verbose=True,
)

resultat = crew.kickoff(inputs={"sujet": "les LLM open-weight en 2026"})
print(resultat)

1. 01
   Der Recherche-Agent wird ausgeführt

   Sein lokales LLM erhält seine Rolle sowie die Beschreibung der Rechercheaufgabe und erstellt die erwartete Liste von Fakten.
2. 02
   Die Ausgabe wird weitergeleitet

   CrewAI übermittelt das Suchergebnis als Kontext an die Aufgabe der Texterstellung gemäß dem Feld 'context'.
3. 03
   Der Redakteur macht sich an die Arbeit

   Sein Agent erhält die Fakten und verfasst die Zusammenfassung mit 300 Wörtern gemäß den Vorgaben in expected_output.
4. 04
   kickoff() gibt das endgültige Ergebnis zurück

   Die Ausgabe der letzten Aufgabe wird zurückgegeben. verbose=True zeigt sämtliche Zwischenschritte der Argumentation im Terminal an.

#Agenten Werkzeuge zur Verfügung stellen

Ein Agent ohne Werkzeuge kann nur auf Grundlage dessen Schlussfolgerungen ziehen, was das Modell bereits weiß – damit stößt er schnell an Grenzen und ist anfällig für Halluzinationen. Werkzeuge geben ihm konkrete Fähigkeiten: eine Datei lesen, im Web suchen, eine Datenbank abfragen. crewai-tools stellt eine Reihe sofort einsatzbereiter Werkzeuge bereit, und Sie können eigene schreiben.

from crewai_tools import FileReadTool
from crewai.tools import tool

# Outil intégré : lire un fichier local
lecteur = FileReadTool()

# Outil maison : décoré avec @tool
@tool("Compteur de mots")
def compter_mots(texte: str) -> int:
    """Compte le nombre de mots d'un texte donné."""
    return len(texte.split())

# On équipe l'agent des deux outils
chercheur = Agent(
    role="Analyste de recherche",
    goal="Analyser des documents locaux sur {sujet}",
    backstory="Tu analyses des sources internes avec rigueur.",
    tools=[lecteur, compter_mots],
    llm=local_llm,
    verbose=True,
)

Hier wird die Modellwahl entscheidend. Um ein Tool zu verwenden, muss der Agent einen strukturierten Funktionsaufruf (function calling) erzeugen, den CrewAI abfängt und ausführt. Ein Modell, das den Einsatz von Tools nicht beherrscht, ignoriert das Tool oder erzeugt ungültiges JSON. Qwen 3.5, Qwen 3.8, Mistral Small und GLM 4.7 Flash beherrschen diesen Mechanismus gut; viele kleine Allzweckmodelle dagegen nicht.

#Welche lokalen Modelle eignen sich für den Multi-Agenten-Betrieb?

Das ist die entscheidende Frage dieses Leitfadens. Der Einsatz mehrerer Agenten ist deutlich anspruchsvoller als ein Chat: Jeder Agent muss seiner Rolle folgen, ein Ausgabeformat einhalten und häufig Tools aufrufen – und dabei Aufgaben nacheinander bearbeiten, ohne den Faden zu verlieren. Ein zu kleines Modell verliert dabei den Anschluss. Hier sind die realistischen Größenklassen in Q4_K_M mit dem jeweils zugehörigen VRAM-Bedarf.

8B (≈5-7 GB) — Mindestwert

Granite 4.2 8B (5,3 GB), Qwen 3.5 9B (6,6 GB). Sie bewältigen ein einfaches, sequenziell arbeitendes Team aus 2 Agenten mit grundlegenden Werkzeugen. RTX 3060 12 GB, RTX 4070. Unterhalb dieser Modellgröße wird der Einsatz mehrerer Agenten unzuverlässig.

16 GB (≈14 GB) — empfohlen

gpt-oss 20B oder Mistral Small 24B (≈14 GB, letzteres sehr gut auf Französisch), oder Qwen 3.5 9B in Q8 (11 GB). Ein guter Kompromiss: solides Schlussfolgern, zuverlässige Tool-Nutzung, Einhaltung der Rollen ohne Abdriften. Von der RTX 4070 mit 12 GB (knapp) bis zur RTX 4080 mit 16 GB. Das ist der ausgewogene Mittelweg für die meisten Crews.

24 GB (≈18–19 GB) — komfortabel

Qwen 3.8 27B (18 GB, 262k Kontext) oder das MoE-Modell Qwen3-Coder 30B-A3B (19 GB). Bewältigt längere Crews, mehrere Tools und einen einfachen hierarchischen Modus. RTX 4090 mit 24 GB oder Mac M4 Pro mit vereinheitlichtem Speicher. Denken Sie daran, das Reasoning von Qwen 3.8 auf „low“ zu setzen, sonst denkt das Modell innerhalb einer Crew übermäßig lange nach.

MoE 35B+ (≈23–32 GB) — nahe an der Cloud-Qualität

Qwen 3.6 35B-A3B (23 GB) oder Qwen3-Coder 30B-A3B in Q8 (32 GB). Die Koordinationsqualität nähert sich der von Cloud-APIs an und ist dank MoE-Architekturen nun schon ab 32 GB erreichbar. Mac Studio mit großem gemeinsamem Speicher oder ein System mit mehreren GPUs. Nur für ambitionierte Agententeams.

Architekturtipp: Nicht alle Agenten müssen dasselbe Modell verwenden. Übertragen Sie einfache Aufgaben (Umformulieren, Zählen, Extraktion) einem kleinen, schnellen Modell (Qwen 3.5 4B, Granite 4.2 8B), und reservieren Sie Qwen 3.8 27B oder ein 35B-MoE-Modell für Agenten, die schlussfolgern oder orchestrieren. Dazu instanziiert man einfach zwei LLM-Objekte und weist sie den jeweiligen Agenten zu.

gros = LLM(model="ollama/qwen3.8:27b", base_url="http://localhost:11434")
petit = LLM(model="ollama/granite4.2:8b", base_url="http://localhost:11434")

stratege = Agent(role="Stratège", goal="...", llm=gros)
assistant = Agent(role="Assistant", goal="...", llm=petit)

#Kosten und Grenzen im Vergleich zu einer Crew, die eine Cloud-API nutzt

Das stärkste Argument für den lokalen Betrieb sind die Kosten. Eine Crew ist von Natur aus gesprächig: Jeder Agent liest den Kontext erneut, führt Denkschritte aus und ruft Tools auf. Mit den aufeinanderfolgenden Aufgaben wächst der Kontext und damit die Anzahl der Tokens. Schon ein einzelner etwas ambitionierter Durchlauf kann Hunderttausende Tokens verbrauchen. Bei einer API mit Abrechnung pro Token wird eine während der Entwicklung immer wieder ausgeführte Pipeline schnell teuer; lokal ist jede Iteration nach dem Kauf der Hardware kostenlos.

Kosten — Vorteil des lokalen Betriebs

Keine Kosten pro Token. Sie iterieren, starten erneut und beheben Fehler, ohne dass ein Kostenzähler mitläuft. Anwendungen mit mehreren Agenten verbrauchen besonders viel; bei ihnen amortisiert sich die GPU durch den lokalen Betrieb am schnellsten.

Vertraulichkeit — Vorteil der lokalen Nutzung

Keiner der Aufrufe – und es sind viele – verlässt den Rechner. Entscheidend für proprietären Code, Kundendaten oder alles, was unter eine NDA oder die DSGVO fällt.

Qualität der Koordination – Vorteil im Cloud-Modus

GPT-4 und Claude bewältigen den hierarchischen Modus, lange Ketten und komplexe Tool-Nutzung mit einer Zuverlässigkeit, die ein lokales 14B-Modell nicht erreicht. Der Abstand wächst, wenn die Crew komplexer wird.

Geschwindigkeit – hängt von der Hardware ab

Die Cloud antwortet bei großen Modellen oft schneller als eine GPU für Endverbraucher. Ein Team aus 4 Agenten mit einem lokalen 32B-Modell kann pro Durchlauf mehrere Minuten benötigen.

Eine ehrliche Einschätzung: Der lokale Betrieb eignet sich hervorragend für klar strukturierte Agententeams mit sequenziellen Abläufen, in denen jeder Agent eine eindeutige Rolle und eine klar begrenzte Aufgabe hat. Bei anspruchsvoller hierarchischer Orchestrierung zeigt er seine Grenzen: Ein 14B-Modell hat Schwierigkeiten, die Rolle eines Managers zu übernehmen, der Aufgaben delegiert. Eine gute Strategie ist häufig ein hybrider Ansatz – lokal Prototypen erstellen und betreiben und die Cloud den Schritten vorbehalten, bei denen die Koordination die Fähigkeiten Ihres Modells übersteigt. Ein Proxy wie LiteLLM ermöglicht genau das Routing zwischen beiden.

#Fehlerbehebung

Der Agent ignoriert seine Tools

Das Modell unterstützt kein Function Calling. Wechseln Sie zu Qwen 3.5, Qwen 3.8, Mistral Small oder GLM 4.7 Flash und prüfen Sie, ob die Liste tools=[...] beim Agenten hinterlegt ist.

« Connection refused » / litellm-Fehler

Der Ollama-Daemon läuft nicht oder base_url ist falsch. Prüfen Sie „ollama ps“ und stellen Sie sicher, dass die URL http://localhost:11434 lautet.

Der Agent läuft in einer Schleife oder hört nicht auf

Das Modell ist zu klein für die Aufgabe, oder es gibt zu viele Tools. Wechseln Sie zu einem größeren Modell (mindestens Qwen 3.5 9B), reduzieren Sie die Anzahl der Tools, senken Sie die Temperatur und legen Sie max_iter für den Agenten fest.

Ausgaben im falschen Format / expected_output ignoriert

Die Rolle ist zu vage oder die expected_output-Angabe unklar. Formulieren Sie sie sehr konkret und bevorzugen Sie ein leistungsfähigeres Modell (Qwen 3.8 27B, Mistral Small 24B), das Formatvorgaben zuverlässiger befolgt.

Crew ist sehr langsam

Wegen zu wenig VRAM wird das Modell teilweise in den Arbeitsspeicher ausgelagert und auf der CPU ausgeführt („ollama ps“ zeigt das), oder mehrere Modelle verdrängen sich gegenseitig aus dem Speicher. Wechseln Sie zu einem Modell der nächstkleineren Größe oder verwenden Sie durchgehend ein einziges Modell.

Der hierarchische Modus wird instabil

Das Manager-LLM ist der Aufgabe nicht gewachsen. Kehren Sie zu Process.sequential zurück oder reservieren Sie ein Qwen 3.8 27B oder ein MoE-Modell mit 35B für die Managerrolle.

#Weiterführende Informationen

Eine lokale CrewAI-Crew baut auf Bausteinen auf, die bereits auf der Website behandelt werden. Diese Anleitungen führen diesen Leitfaden weiter:

Lokalen KI-Agenten in Python mit LangChain und Ollama erstellen

Die Grundlagen eines einzelnen Agenten – Werkzeuge und eine Schlussfolgerungsschleife – vor dem Übergang zu mehreren Agenten.

Function Calling und strukturierte JSON-Ausgaben mit Ollama

Um den Mechanismus der Tool-Nutzung zu verstehen, von dem die Tools Ihrer Agenten abhängen.

LiteLLM: Ein einheitlicher Proxy für lokale Dienste und Cloud-Dienste

Um eine Crew im Rahmen einer hybriden Strategie je nach Aufgabe zwischen lokalem Ollama und einer Cloud-API zu routen.