AgentScope 1.0 : un framework centré sur les développeurs pour concevoir des applications basées sur des agents

Guide de lecture

Problème et motivation

Bien que les grands modèles de langage (LLM) modernes excellent dans le raisonnement et la génération de langage naturel, leur utilité dans le monde réel nécessite des interactions concrètes avec l'environnement externe via des API, des bases de données et des outils dynamiques. Les premières architectures d'agents reposent souvent sur une exécution rigide et séquentielle des outils, manquent d'une gestion asynchrone robuste, peinent face à la prolifération d'outils (« paradoxe du choix ») et sont dépourvues d'infrastructures centrées sur le développeur pour le débogage de longues trajectoires, l'évaluation distribuée et l'exécution sécurisée. AgentScope 1.0 comble ces lacunes en passant de frameworks de raisonnement intrinsèque à un framework agentique extensible et centré sur le développeur, articulé autour de la perception des outils et de l'interaction avec l'environnement.

Idées maîtresses

AgentScope 1.0 est structuré autour de trois piliers fondamentaux :

• Composants fondamentaux : des abstractions découplées comprenant Msg (blocs multimodaux, appels d'outils et traces de réflexion), des interfaces unifiées Model avec streaming asynchrone et instrumentation OpenTelemetry, une mémoire hiérarchique Memory (tampons court terme en mémoire vive et mémoire à long terme contrôlée par le développeur ou l'agent via Mem0), ainsi qu'un Toolkit extensible.
• Infrastructure au niveau agent : centrée sur le paradigme ReAct (Reasoning + Acting), prenant en charge les appels d'outils parallèles non bloquants, les interruptions utilisateur (guidage en temps réel), l'approvisionnement dynamique d'outils (activation/désactivation par groupes) et la persistance hiérarchique de l'état via StateModule.
• Expérience développeur : des suites d'évaluation intégrées (prenant en charge GeneralEvaluator séquentiel et RayEvaluator distribué), un environnement visuel Studio avec intervalles de confiance dérivés par bootstrap et comparaison de trajectoires, un copilote intégré (Friday), et un environnement d'exécution (Runtime) isolé avec bac à sable.

Méthode (avec les équations clés)

Le système structure l'exécution autour d'abstractions standardisées :

1. Architecture des messages : les paquets d'informations sont unifiés sous forme d'objets Msg contenant name, role, content (une liste de blocs typés comme TextBlock, ToolUseBlock, ThinkingBlock), et metadata. Des formateurs spécifiques aux fournisseurs (ChatFormatter et MultiAgentFormatter) convertissent ces blocs dans les schémas propres à chaque fournisseur.
2. Exécution et regroupement des outils : les outils sont enregistrés dans Toolkit avec extraction automatique du schéma JSON à partir des docstrings. Pour limiter la dégradation de l'espace de recherche liée à un nombre excessif d'outils, ces derniers sont organisés en groupes $G_k\subset \mathcal{T}$. Grâce à update_tool_groups ou à l'appel par l'agent de reset_equipped_tools(group_names), le sous-ensemble d'outils actifs ${\mathcal{A}}_t$ est adapté dynamiquement à chaque étape du flux de travail : $${\mathcal{A}}_t=\bigcup _{k\in \text{Active}}{G}_k$$
3. Intégration de MCP : distingue les clients avec état (cycle de vie de session persistant pour les outils critiques en matière d'état, comme les sessions de navigateur) des clients sans état (connexion éphémère par appel pour réduire le surcoût).
4. Exécution asynchrone et guidage : l'exécution asynchrone de l'agent utilise des générateurs non bloquants. En cas de signal d'annulation asyncio, la boucle ReAct s'interrompt proprement, renvoie les états d'exécution partiels et ajoute des jetons d'interruption dans la mémoire en tant qu'événements observables.
5. Coordination multi-agents : prend en charge les schémas d'invocation « l'agent en tant qu'outil » (Agent as a Tool) ainsi que l'orchestration conversationnelle via des structures de type Pipeline (séquentielles, avec branchements ou en boucle) et la diffusion via MsgHub.

Résultats (avec les chiffres les plus importants)

L'article présente des implémentations concrètes du framework et des validations architecturales à travers trois agents spécialisés intégrés :

• Deep Research Agent : implémente l'expansion de requêtes (décomposition arborescente), la recherche web multisource via Tavily MCP, la réflexion de bas niveau (corrections d'outils/paramètres) et la réflexion de haut niveau (replanification des sous-tâches).
• Browser-use Agent : utilise Playwright MCP via un client standard I/O avec état (StdIOStatefulClient), incluant le traitement visuel du HTML, la coordination multi-onglets et la segmentation par fragments des pages web longues.
• Meta Planner Agent : orchestre des flux de travail complexes via RoadmapManager et WorkerManager, permettant une bascule bimodale entre un mode ReAct basique pour les tâches simples et une exécution multi-agents guidée par une feuille de route pour les tâches complexes.
• Infrastructure d'ingénierie : intégration native du déploiement avec FastAPI, traçage OpenTelemetry compatible avec Arize-Phoenix et Langfuse, et évaluation de tâches distribuées en parallèle basée sur Ray avec points de contrôle persistants.

Limites et questions ouvertes

• L'article constitue un rapport d'architecture système plutôt qu'une comparaison de précision sur des benchmarks standards (par exemple, les scores sur des benchmarks tels que SWE-bench ou GAIA sont omis du texte principal).
• L'approvisionnement dynamique des outils et le surcoût de planification au sein du Meta Planner nécessitent une fenêtre de contexte suffisante et une grande fidélité du LLM sous-jacent lors des appels d'outils.
• Le surcoût de coordination multi-agents et les coûts d'isolation en bac à sable sous une forte concurrence à grande échelle ne sont pas évalués avec des chiffres bruts de débit dans cet article.