CrewAI
Équipes d'agents par rôles : Researcher, Writer, Validator, coordonnés d'emblée.
Vue d'ensemble
CrewAI est un framework Python sous licence MIT qui orchestre des systèmes multi-agents collaboratifs par attribution de rôles. L'abstraction centrale est le Crew : une équipe d'Agents, chacun portant un rôle, un objectif et une histoire, qui exécute une liste de Tasks selon un processus défini. Créé par Joao Moura en octobre 2023 et publié sur PyPI en décembre 2023, CrewAI avait atteint 150 clients enterprise six mois après le lancement de la société en janvier 2024.
Le positionnement est délibéré : CrewAI se situe un cran au-dessus de LangGraph dans la pile d'abstraction. Quand LangGraph expose des nodes, des edges, des reducers et un runtime Pregel à assembler soi-même, CrewAI expose des rôles. On déclare un agent Researcher, un agent Writer, un agent Validator, et le framework prend en charge la coordination. Ce choix est pertinent quand le problème se décline naturellement en rôles distincts à la façon humaine et quand le flux est séquentiel ou hiérarchique, pas cyclique.
Deux schémas d'exécution couvrent la majorité des cas. Un Crew fait tourner les agents selon un processus séquentiel ou hiérarchique : le mode séquentiel exécute les Tasks dans l'ordre de déclaration, chacune transmettant son output comme contexte à la suivante ; le mode hiérarchique délègue via un agent manager qui valide les outputs avant de continuer. Un Flow (introduit en 2024-2025) ajoute le branchement, des déclencheurs événementiels (@start, @listen, @router) et une gestion d'état structurée pour coordonner plusieurs Crews au sein d'un pipeline de plus grande envergure.
Architecture
Deux modèles mentaux couvrent la majorité des usages en production. Le modèle Crew définit les Agents par rôle et les assemble en pipeline de Tasks séquentiel ou hiérarchique. Le modèle Flow pose un coordinateur événementiel par-dessus : des méthodes décorées se connectent via @start / @listen / @router, portent un état partagé (structuré ou non) et peuvent déclencher des kickoffs de Crew comme sous-étapes. La mémoire est orthogonale aux deux : en passant memory=True à la création du Crew, un système adossé à LanceDB suit le contexte entre les appels.
Concepts clés
- Agent
- Unité autonome pilotée par un LLM, définie par un rôle (ce qu'elle fait), un objectif (ce qu'elle cherche à atteindre) et une histoire (contexte qui module sa personnalité). Champs optionnels : tools, memory, llm, max_iter (défaut 20), allow_delegation.
- Task
- Unité de travail assignée à un Agent. Porte description, expected_output, context (liste des Tasks amont dont les outputs alimentent celle-ci) et, en option, output_pydantic pour valider un output structuré.
- Crew
- L'orchestrateur : une équipe d'Agents qui exécute une liste de Tasks selon un processus (séquentiel ou hiérarchique). Paramètres clés : agents, tasks, process, memory, manager_llm (requis en mode hiérarchique), max_rpm, cache.
- Processus séquentiel
- Mode d'exécution par défaut du Crew : les Tasks s'exécutent dans l'ordre de déclaration. L'output de chaque Task est disponible comme contexte pour toutes les Tasks suivantes. Aucun agent manager n'est requis.
- Processus hiérarchique
- Mode d'exécution du Crew où un agent manager (généré automatiquement ou personnalisé) distribue les Tasks au bon agent, valide les outputs et décide de la suite. Requiert manager_llm ou manager_agent.
- Flow
- Coordinateur événementiel construit sur des décorateurs de classe Python : @start marque le point d'entrée, @listen se déclenche à la fin d'une méthode, @router aiguille selon le label retourné. Porte un état typé (Pydantic ou dict) et peut déclencher des kickoffs de Crew comme étapes intermédiaires.
- Mémoire
- Classe Memory unifiée de CrewAI, adossée à LanceDB. Quand elle est activée (memory=True sur Crew), le LLM analyse et catégorise chaque output de Task à la sauvegarde. La recherche classe les résultats par similarité sémantique, récence et importance. Persiste entre les exécutions de Crew par défaut.
Quand l'utiliser
Cas adaptés
- Pipelines par rôles : le problème se découpe naturellement en fonctions distinctes à la façon humaine, Researcher, Writer, Validator, Editor, chacune avec un périmètre clair.
- Génération de contenu séquentielle : chaque agent s'appuie sur l'output du précédent (research -> draft -> review -> final), sans cycles nécessaires.
- Automatisation de rapports et documents : pipelines multi-agents qui collectent les données, les synthétisent et mettent en forme le résultat, un cas où le concept de rôle correspond directement au flux de travail.
- Itération rapide sur les équipes d'agents : la configuration YAML et le modèle role-first de CrewAI réduisent la surface de code nécessaire pour définir et permuter les agents, raccourcissant le cycle prototype-test.
- Délégation hiérarchique : quand un agent coordinateur doit distribuer, relire et aiguiller les tâches dynamiquement, le processus hiérarchique avec manager_llm convient sans câblage de graphe personnalisé.
- Pipelines multi-Crew : quand le workflow global comporte du branchement, des exécutions de Crew en parallèle ou un état à faire persister entre les Crews, les Flows s'ajoutent par-dessus sans réécrire les Crews.
Anti-patterns
- Machines à états cycliques : si le pipeline doit reboucler sur des résultats intermédiaires (réflexion, retry, itération), préférer LangGraph. Les processus séquentiel et hiérarchique de CrewAI sont acycliques ; ajouter des cycles impose des contournements qui travaillent contre l'abstraction.
- Reprise sur crash durable : si le processus doit reprendre à un superstep précis après un crash à 3h du matin, LangGraph avec un checkpointer PostgresSaver est l'outil adéquat. Les Flows CrewAI ont une capacité de reprise, mais l'exécuteur Crew de base ne prend pas de snapshot à chaque étape.
- Topologie de machine à états précise : quand le flux de contrôle est lui-même le produit, avec des edges conditionnels, des compteurs de retry, des reducers typés par clé et des transitions d'état auditables, le modèle de graphe explicite de LangGraph offre plus de granularité que la délégation par rôle.
- Boucles d'agents non bornées : sans limite max_iter explicite ni critères expected_output clairs, les agents peuvent enchaîner les appels d'outils en brûlant des tokens. Définir max_iter sur chaque agent et des conditions de sortie concrètes dans expected_output.
- SLA de latence serrés : le processus hiérarchique passe par un appel LLM manager avant de déléguer chaque tâche, ce qui ajoute de la latence. Le mode séquentiel est plus rapide ; pour des exigences sous la seconde, envisager une boucle d'appel d'outils simple hors d'un Crew.
Exemples de code
Crew minimal : Researcher -> Writer, processus séquentiel
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool
search_tool = SerperDevTool()
researcher = Agent(
role="Senior Research Analyst",
goal="Find and summarise the latest developments on {topic}",
backstory="Expert at distilling complex information into clear insights.",
tools=[search_tool],
verbose=True,
)
writer = Agent(
role="Content Writer",
goal="Write a concise, accurate report based on the research findings",
backstory="Skilled at turning research into readable prose.",
verbose=True,
)
research_task = Task(
description="Research the current state of {topic}. Identify key trends.",
expected_output="A bullet-point summary of 5-10 key findings with sources.",
agent=researcher,
)
write_task = Task(
description="Write a 3-paragraph report based on the research findings.",
expected_output="A polished 3-paragraph report, ready to publish.",
agent=writer,
context=[research_task], # output of research_task feeds this task
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential,
verbose=True,
)
result = crew.kickoff(inputs={"topic": "CrewAI multi-agent frameworks"})context=[research_task] est le branchement clé : le Writer reçoit l'output du Researcher comme contexte. Sans cela, les agents tournent en isolation et le Writer n'a aucune recherche sur laquelle s'appuyer.
Crew hiérarchique avec manager LLM et mémoire
from crewai import Agent, Task, Crew, Process
import os
manager_llm = "claude-sonnet-4-5" # or any LLM identifier
analyst = Agent(
role="Data Analyst",
goal="Extract structured insights from raw data",
backstory="Precise, detail-oriented data specialist.",
)
validator = Agent(
role="Quality Validator",
goal="Verify accuracy and completeness of analysis outputs",
backstory="Critical thinker who catches errors before they ship.",
)
writer = Agent(
role="Report Writer",
goal="Produce a clear, stakeholder-ready report",
backstory="Expert at translating technical findings into business language.",
)
analyse_task = Task(
description="Analyse the dataset at {data_path} and extract key metrics.",
expected_output="Structured JSON with metrics: totals, trends, anomalies.",
)
validate_task = Task(
description="Check the analysis output for accuracy and completeness.",
expected_output="Validation report: pass/fail per metric with notes.",
)
report_task = Task(
description="Write an executive summary based on validated analysis.",
expected_output="2-page executive summary with charts described in text.",
)
crew = Crew(
agents=[analyst, validator, writer],
tasks=[analyse_task, validate_task, report_task],
process=Process.hierarchical,
manager_llm=manager_llm,
memory=True, # LanceDB-backed memory across calls
verbose=True,
)
result = crew.kickoff(inputs={"data_path": "/data/q2-report.csv"})En mode hiérarchique, le manager LLM distribue les tâches et valide les outputs avant de continuer. memory=True active la mémoire adossée à LanceDB : les agents rappellent le contexte des appels précédents. Surveiller le coût de l'appel LLM supplémentaire par délégation de tâche.
Flow : aiguillage événementiel entre Crews avec état typé
from crewai.flow.flow import Flow, listen, start, router
from crewai import Crew, Process
from pydantic import BaseModel
class ReportState(BaseModel):
topic: str = ""
research_summary: str = ""
needs_deep_dive: bool = False
final_report: str = ""
class ReportFlow(Flow[ReportState]):
@start()
def kick_off_research(self):
research_crew = build_research_crew()
result = research_crew.kickoff(inputs={"topic": self.state.topic})
self.state.research_summary = str(result)
@router(kick_off_research)
def route_by_depth(self):
# Send to deep dive if summary flagged gaps
if "insufficient data" in self.state.research_summary.lower():
return "deep_dive"
return "write"
@listen("deep_dive")
def run_deep_dive(self):
deep_crew = build_deep_dive_crew()
result = deep_crew.kickoff(
inputs={"summary": self.state.research_summary}
)
self.state.research_summary += " " + str(result)
@listen("write")
@listen("run_deep_dive")
def write_report(self):
write_crew = build_write_crew()
result = write_crew.kickoff(
inputs={"research": self.state.research_summary}
)
self.state.final_report = str(result)
flow = ReportFlow()
flow.kickoff(inputs={"topic": "AI agent orchestration trends 2026"})@router retourne un label qui détermine quelle branche @listen s'exécute ensuite, permettant un branchement conditionnel sans réécrire les Crews. Passer aux Flows quand la logique de coordination (branchement, transmission d'état) dépasse ce qu'un seul processus Crew peut exprimer.
Comparatif
vs LangGraph
Niveau d'abstraction, contrôle du flux, tolérance aux pannes
CrewAI monte le niveau d'abstraction : on déclare des rôles (Researcher, Writer, Validator) et le framework prend en charge la coordination. Moins de code pour les pipelines séquentiels par rôles. LangGraph expose le graphe directement : nodes, edges, reducers, un runtime Pregel avec un checkpointer qui snapshotte chaque superstep. Préférer LangGraph quand des cycles sont nécessaires, quand la topologie de la machine à états est le produit lui-même, ou quand la reprise sur crash durable est une contrainte ferme. Source : docs.crewai.com, docs.langchain.com/oss/python/langgraph.
vs AutoGen / AG2
Modèle de programmation, contrôle du flux, statut du projet
CrewAI est structuré par rôles et tâches : les agents ont des rôles explicites, les tâches ont des expected outputs déclarés, et le processus (séquentiel ou hiérarchique) est spécifié en amont. AutoGen modélise l'interaction entre agents comme une conversation à routage émergent ; les rôles sont plus souples et le contrôle du flux est implicite. CrewAI convient aux pipelines métier avec des frontières de rôles claires ; AutoGen convient aux débats multi-agents, simulations ou scénarios de recherche où les rôles évoluent. Le statut compte : l'AutoGen Microsoft d'origine est en maintenance (successeur : Microsoft Agent Framework) ; AG2 est le fork communautaire qui préserve l'API v0.2. Sources : github.com/ag2ai/ag2, pecollective.com/blog/ai-agent-frameworks-compared.
vs n8n
Code vs visuel, abstraction, parcours de montée en charge
n8n est un éditeur visuel de workflows orienté liaison d'intégrations et prototypage rapide ; son AI Agent node tourne sur LangChain sous le capot. CrewAI est code-first et orienté rôles, adapté aux équipes à l'aise en Python qui ont besoin d'un contrôle plus fin sur le comportement des agents qu'un éditeur drag-and-drop. Un parcours courant : prototyper la forme de l'équipe d'agents dans n8n pour valider le découpage par rôles rapidement, puis réécrire en CrewAI quand la logique mérite du code testé et versionné. Source : docs.n8n.io.
Ressources
FAQ
- Quelle est la différence entre un Crew et un Flow dans CrewAI ?
- Un Crew est centré sur les agents : une équipe d'Agents exécute une liste de Tasks selon un processus séquentiel ou hiérarchique. Un Flow est centré sur le processus : des méthodes Python décorées se connectent via @start / @listen / @router avec un branchement explicite et un état partagé typé. Utiliser un Crew quand un pipeline linéaire ou délégué suffit. Passer à un Flow quand on a besoin de brancher entre plusieurs Crews, de faire transiter un état entre eux ou de conditionner l'exécution.
- Quand choisir CrewAI plutôt que LangGraph ?
- Choisir CrewAI quand le problème se découpe naturellement en rôles distincts à la façon humaine (Researcher, Writer, Validator) et que le flux est séquentiel ou hiérarchique, sans cycles. Le modèle role-first s'écrit plus vite et se raisonne plus facilement pour les workflows métier. Préférer LangGraph quand des cycles sont nécessaires, quand la topologie de la machine à états est le produit lui-même, ou quand la reprise sur crash durable (checkpointing par superstep vers Postgres) est une contrainte ferme.
- CrewAI est-il open source ?
- Le framework principal est sous licence MIT : utilisation, modification et auto-hébergement libres, sans restriction commerciale. La plateforme hébergée (CrewAI Enterprise / AMP) est commerciale, avec un niveau gratuit de 50 exécutions par mois et des formules payantes à partir de 25 $/mois. L'auto-hébergement n'engendre aucun coût de plateforme : on ne paie que les tokens LLM auprès du fournisseur choisi.
- Comment fonctionne la mémoire dans CrewAI ?
- En passant memory=True à la création d'un Crew, CrewAI active une classe Memory unifiée adossée à LanceDB (stockée localement dans .crewai/memory par défaut). À la sauvegarde, le LLM analyse le contenu et en déduit la portée, la catégorie et l'importance. La recherche classe les résultats par un score composite de similarité sémantique, récence et importance. La mémoire persiste entre les kickoffs de Crew : les agents peuvent retrouver le contexte des exécutions précédentes.
- Que se passe-t-il si un Crew crashe en cours d'exécution ?
- Pour un Crew de base (processus séquentiel ou hiérarchique), il n'y a pas de snapshot automatique par superstep : en cas de crash, l'exécution repart du début. Les Flows CrewAI disposent d'une capacité de reprise via leur modèle d'état. Pour des exigences d'exécution durable strictes, LangGraph avec un checkpointer PostgresSaver est l'outil le plus adapté : il snapshotte chaque superstep et peut reprendre depuis le dernier état stable après un crash.