Salut tout le monde, Leo ici de agntdev.com ! Aujourd’hui, je veux parler de quelque chose qui a discrètement changé ma manière d’aborder la construction d’agents : l’essor des SDK spécialisés. Pas n’importe quel SDK, mais ceux conçus pour rendre l’orchestration des comportements complexes des agents moins pénible et plus fluide.
Pendant longtemps, mon flux de travail de développement d’agents ressemblait à une constante réinvention de la roue. J’avais une idée brillante pour un agent qui devait communiquer avec quelques API, prendre des décisions, peut-être même apprendre de ses interactions. Et ensuite je passais des jours, parfois des semaines, juste à mettre en place l’infrastructure basique : gestion de l’état, appel d’outils, mémoire, exécution concurrente. C’était épuisant. J’avais l’impression de passer 80 % de mon temps sur l’infrastructure et 20 % sur l’intelligence réelle que je voulais construire.
Cela a changé pour moi il y a environ un an et demi, juste au moment où les premiers SDK vraiment solides spécifiques aux agents ont commencé à se développer. Je ne parle pas juste de wrappers autour des LLM ; je veux dire des outils qui modifient fondamentalement la manière dont vous concevez, construisez et déployez des agents intelligents. Et aujourd’hui, je veux me concentrer sur un aspect particulier de cela : comment les SDK modernes pour agents simplifient les interactions complexes entre plusieurs agents et l’état partagé, transformant ce qui était auparavant un cauchemar en un modèle de conception gérable.
Ancienne méthode : Code spaghetti et migraines distribuées
Revenons un peu en arrière. Avant que ces SDK ne se développent, si vous vouliez que des agents collaborent, vous deviez suivre quelques modèles communs, aucun d’entre eux particulièrement amusant. Vous pouviez avoir un agent “coordinateur” central, agissant comme un contrôleur de la circulation, transmettant des messages entre les autres. Ou vous aviez un système pub/sub, ce qui est idéal pour le découplage, mais gérer l’état partagé ou les dépendances séquentielles devenait une toute autre affaire.
Je me souviens d’un projet où je construisais un système d’agent de support client. Nous avions un agent pour trier les tickets entrants, un autre pour rechercher dans la base de connaissances, et un troisième pour escalader à un humain si nécessaire. Ça semble simple, non ? La réalité était que l’agent “triage” devait connaître les capacités de l’agent “recherche”, et l’agent “recherche” devait savoir comment renvoyer les résultats à l’agent “triage”, qui décidait ensuite s’il fallait déclencher l’agent “escalade”. Chaque agent avait sa propre petite machine d’état, et les synchroniser était un cauchemar. Le débogage était comme essayer de trouver une nouille spécifique dans un bol de spaghetti – chaque changement dans un agent semblait se répercuter sur les autres de manière inattendue.
Mémoire partagée ? Oubliez ça. Nous passions des blobs JSON, espérant que tout le monde soit sur la même longueur d’onde concernant le schéma. Le versionnage était une bataille constante. Ça fonctionnait, finalement, mais c’était fragile. Et c’est le mot-clé : fragile. Au moment où vous vouliez ajouter un quatrième agent, ou changer le flux, vous deviez envisager un refactoring significatif.
Nouvelle méthode : L’orchestration comme un citoyen de première classe
Les SDK modernes pour agents modifient fondamentalement ce paradigme en traitant l’orchestration et le contexte partagé comme des fonctionnalités de base, et non comme des idées après coup. Ils fournissent des abstractions qui vous permettent de définir les rôles des agents, leurs capacités (outils), et surtout, comment ils interagissent dans un environnement partagé ou un “fil” d’exécution. Il ne s’agit pas seulement de transmettre des messages ; il s’agit de définir un espace de travail partagé, une compréhension commune de la tâche, et des moyens structurés pour que les agents contribuent à un objectif collectif.
Pour moi, le plus grand moment “aha !” est venu lorsque j’ai commencé à utiliser des SDK qui offraient un concept de “graph” ou de “flux de travail” pour les agents. Au lieu d’envoyer simplement des messages, les agents pouvaient opérer dans un flux pré-défini, et le SDK s’occupait des transitions d’état, des appels d’outils, et même de la gestion des erreurs entre eux. On avait l’impression de passer d’un langage d’assemblage à un framework de haut niveau.
Exemple 1 : Recherche collaborative avec contexte partagé
Prenons un exemple pratique. Imaginez que vous souhaitez construire un assistant de recherche. Pas juste un agent qui recherche, mais un qui peut décomposer une requête complexe, déléguer des parties, synthétiser des résultats, puis rédiger un résumé. Voici comment vous pourriez l’aborder avec un SDK moderne (j’utiliserai une syntaxe conceptuelle similaire à Python, car les SDK spécifiques varient, mais les principes sont largement applicables) :
from agent_sdk import Agent, Workflow, Tool, SharedState
# Définir quelques outils
def search_web(query: str):
# Simuler une recherche web
return f"Résultats de recherche pour '{query}' : ..."
def summarize_text(text: str):
# Simuler une synthèse
return f"Résumé de : {text[:50]}..."
# Enregistrer les outils
search_tool = Tool("web_search", search_web, "Recherche d'informations sur Internet.")
summarize_tool = Tool("text_summarizer", summarize_text, "Résume le texte donné.")
# Définir les agents
research_planner = Agent(
name="Planner",
description="Décompose des requêtes de recherche complexes en sous-tâches.",
tools=[] # Le planificateur n'utilise pas d'outils directement, il délègue
)
information_gatherer = Agent(
name="Gatherer",
description="Exécute des recherches web basées sur des sous-tâches.",
tools=[search_tool]
)
synthesizer = Agent(
name="Synthesizer",
description="Synthétise les informations recueillies en points cohérents.",
tools=[summarize_tool]
)
# Définir le flux de travail
research_workflow = Workflow(
name="Tâche de recherche complexe",
initial_state={"query": "", "sub_tasks": [], "raw_data": [], "synthesized_data": "", "final_report": ""},
agents=[research_planner, information_gatherer, synthesizer]
)
@research_workflow.step(agent=research_planner)
def plan_research(state: SharedState):
# Appel LLM ou logique basée sur des règles pour décomposer la requête
state["sub_tasks"] = ["rechercher X", "rechercher Y", "rechercher Z"]
print(f"Planner : Décomposition de '{state['query']}' en {state['sub_tasks']}")
return "gather_information" # Transition vers l'étape suivante
@research_workflow.step(agent=information_gatherer, loop_over="sub_tasks")
def gather_information(state: SharedState, sub_task: str):
result = state.call_tool("web_search", query=sub_task)
state["raw_data"].append({"task": sub_task, "result": result})
print(f"Gatherer : Terminé '{sub_task}', obtenu {len(result)} chars.")
return "synthesize_results" # Après toutes les sous-tâches effectuées, passer à l'étape suivante
@research_workflow.step(agent=synthesizer)
def synthesize_results(state: SharedState):
all_raw_text = "\n".join([d["result"] for d in state["raw_data"]])
summary = state.call_tool("text_summarizer", text=all_raw_text)
state["synthesized_data"] = summary
print(f"Synthesizer : Création d'un résumé de {len(state['raw_data'])} éléments.")
return "draft_report" # Étape finale
@research_workflow.step(name="draft_report")
def draft_report(state: SharedState):
# Appel LLM pour rédiger le rapport final basé sur synthesized_data
state["final_report"] = f"Rapport Final sur '{state['query']}':\n{state['synthesized_data']}"
print(f"Rapport Final :\n{state['final_report']}")
return "finished"
# Exécution du flux de travail
initial_query = "L'impact de l'informatique quantique sur la cryptographie dans la prochaine décennie."
result_state = research_workflow.run(query=initial_query)
print(f"\nFlux de travail terminé. Rapport final généré : {result_state['final_report'] != ''}")
Que se passe-t-il ici ? Le `Workflow` gère le `SharedState`. Les agents ne communiquent pas directement entre eux ; ils lisent et écrivent dans cet état partagé. Le décorateur `research_workflow.step` détermine quel agent est actif à quel moment et quelles transitions se produisent. Le SDK s’occupe de la transmission de l’objet `SharedState`, garantissant la cohérence. Si `gather_information` échoue pour une sous-tâche, le SDK peut être configuré pour réessayer ou alerter, sans casser toute la chaîne.
C’est une amélioration énorme par rapport au passage manuel de messages. La structure est explicite. L’état est centralisé mais accessible. Et surtout, le SDK fournit le cadre pour cette coordination, réduisant le code répétitif.
Mémoire partagée et gestion dynamique de l’état
Au-delà des graphes de flux explicites, de nombreux SDK offrent des modèles de mémoire partagée sophistiqués. Il ne s’agit pas seulement d’un dictionnaire de valeurs ; il s’agit de contextes qui peuvent être accessibles et mis à jour par n’importe quel agent impliqué dans une session. Ce contexte partagé peut inclure :
- Historique des conversations : La transcription intégrale des interactions, cruciale pour les agents alimentés par LLM.
- Résultats des appels d’outils : Sorties des exécutions précédentes d’outils que des agents subséquents pourraient nécessiter.
- Préférences / Profil utilisateur : Informations persistantes sur l’utilisateur final.
- Connaissances spécifiques au domaine : Faits ou règles pertinents pour la tâche actuelle.
La beauté de ces modèles de mémoire partagée réside souvent dans leur capacité à sérialiser et désérialiser automatiquement, à persister à travers les sessions, et parfois même à gérer des mises à jour simultanées avec grâce. C’est là que le SDK se révèle utile – gérer la complexité de l’état distribué sans que vous ayez à écrire chaque verrou et mutex.
Exemple 2 : Chaînage d’outils dynamique avec contexte partagé
Considérons un agent qui aide à planifier un voyage. Cela pourrait impliquer un agent “Réservation de vol” et un agent “Réservation d’hôtel”. Ils fonctionnent tous les deux sur un objet `TripPlan` partagé en mémoire.
from agent_sdk import Agent, Session, Tool, SharedContext
# Définitions simplifiées des outils
def find_flights(origin: str, destination: str, date: str):
return {"flight_id": "FL123", "price": 350, "departure_time": "10:00"}
def find_hotels(city: str, check_in: str, check_out: str):
return {"hotel_id": "H456", "name": "Grand Hotel", "price_per_night": 120}
flight_tool = Tool("find_flights", find_flights, "Trouve des vols entre les villes.")
hotel_tool = Tool("find_hotels", find_hotels, "Trouve des hôtels dans une ville.")
# Agents
flight_agent = Agent(name="FlightAgent", description="Gère les réservations de vols.", tools=[flight_tool])
hotel_agent = Agent(name="HotelAgent", description="Gère les réservations d'hôtels.", tools=[hotel_tool])
coordinator_agent = Agent(name="Coordinator", description="Orchestre la planification de voyages.", tools=[]) # LLM pourrait être ici
# Contexte partagé pour la session
class TripPlan(SharedContext):
origin: str = ""
destination: str = ""
travel_date: str = ""
check_in_date: str = ""
check_out_date: str = ""
booked_flight: dict = {}
booked_hotel: dict = {}
status: str = "planning"
# Une session pour gérer l'interaction
trip_session = Session(
agents=[flight_agent, hotel_agent, coordinator_agent],
context_model=TripPlan
)
# Simulation d'une interaction utilisateur et des réponses des agents
# Dans un scénario réel, le coordinator_agent (LLM) dirigerait cela
# en fonction de l'entrée de l'utilisateur et de son propre raisonnement.
# Demande initiale de l'utilisateur
trip_session.context.origin = "NYC"
trip_session.context.destination = "LAX"
trip_session.context.travel_date = "2026-06-15"
trip_session.context.check_in_date = "2026-06-15"
trip_session.context.check_out_date = "2026-06-18"
print(f"Plan initial : {trip_session.context.dict()}")
# Le coordinateur décide d'appeler l'agent de vol
# Dans une configuration réelle, cela serait un appel d'outil par un LLM
print("\nCoordinateur : Demande à FlightAgent de trouver des vols...")
flight_result = flight_agent.call_tool(
"find_flights",
origin=trip_session.context.origin,
destination=trip_session.context.destination,
date=trip_session.context.travel_date
)
trip_session.context.booked_flight = flight_result
print(f"FlightAgent a trouvé : {trip_session.context.booked_flight}")
# Le coordinateur décide d'appeler l'agent d'hôtel, en utilisant le contexte mis à jour
print("\nCoordinateur : Demande à HotelAgent de trouver des hôtels...")
hotel_result = hotel_agent.call_tool(
"find_hotels",
city=trip_session.context.destination, # Utilisation de la destination du contexte
check_in=trip_session.context.check_in_date,
check_out=trip_session.context.check_out_date
)
trip_session.context.booked_hotel = hotel_result
trip_session.context.status = "booked"
print(f"HotelAgent a trouvé : {trip_session.context.booked_hotel}")
print(f"\nStatut final du plan de voyage : {trip_session.context.status}")
print(f"Contexte complet : {trip_session.context.dict()}")
Ici, l’objet `TripPlan` agit comme la seule source de vérité pour la session. Les agents peuvent lire et écrire dessus. La `Session` orchestre quel agent doit être activé, potentiellement en fonction de la sortie de LLM de l’agent `Coordinator`. Si `flight_agent` met à jour `booked_flight`, `hotel_agent` peut immédiatement voir ce changement et adapter ses actions. C’est puissant pour construire des systèmes multi-agents réactifs et conscients du contexte.
Points à Retenir pour Votre Prochain Projet d’Agent
- Évaluez les SDK pour les Capacités d’Orchestration : Ne vous contentez pas de chercher des enveloppes LLM. Priorisez les SDK qui prennent explicitement en charge les flux de travail multi-agents, l’état partagé et les schémas de communication structurés. Recherchez des fonctionnalités comme des graphes de `Workflow`, des modèles de `SharedContext`, et une bonne intégration des outils.
- Concevez d’abord Votre État Partagé : Avant même d’écrire la logique des agents, réfléchissez à l’information à laquelle *tous* les agents pertinents devront accéder ou modifier. Définissez un schéma clair pour votre contexte partagé. Cela informera vos conceptions d’agents et préviendra les incohérences de données.
- Adoptez un Modèle d’Agent “Coordinateur” ou “Routeur” : Même avec des SDK avancés, avoir un agent désigné (souvent propulsé par un LLM) pour décider *quel* autre agent doit agir ensuite ou *quel* outil appeler peut simplifier votre conception. Le SDK gère la mécanique ; votre coordinateur gère l’intelligence.
- Adoptez une Pensée Orientée Outils : Les agents interagissent principalement avec le monde (et entre eux) à travers des outils. Définissez clairement vos outils et assurez-vous qu’ils fonctionnent sur ou produisent des données qui s’intègrent parfaitement dans votre contexte partagé.
- Commencez Simple, Itérez : N’essayez pas de construire un système multi-agents monolithique dès le premier jour. Commencez avec deux agents collaborant sur une tâche simple en utilisant un état partagé, puis introduisez progressivement plus de complexité et d’agents.
Les jours où il fallait câbler manuellement des files de messages et des machines d’état personnalisées pour chaque interaction multi-agents sont, heureusement, en train de disparaître. Les SDK modernes pour agents fournissent les abstractions nécessaires pour construire des systèmes d’agents collaboratifs sophistiqués qui ne sont pas seulement fonctionnels, mais aussi maintenables et évolutifs. Si vous luttez encore avec des architectures d’agents fragiles et en désordre, il est temps de regarder sérieusement ce que ces nouveaux SDK ont à offrir. Ils ont certainement facilité ma vie, et je pense qu’ils peuvent faire de même pour vous.
C’est tout pour celui-ci ! Faites-moi savoir dans les commentaires quels SDK vous utilisez pour l’orchestration multi-agents, et quels défis vous rencontrez encore. Bonne construction !
🕒 Published: