ToolSpace : déduction d'environnements exécutables et de tâches longues à partir de trajectoires réelles d'appels d'outils (Synthèse d'environnements centrés sur les outils pour l'extension des agents à horizon long)

Les extensions actuelles d'environnements MCP consistent souvent à « créer d'abord la base de données et le scénario, puis en déduire les outils et les tâches », ce qui entraîne une incompatibilité entre les interfaces des outils et la réalité, ainsi que l'absence de validation par exécution des combinaisons d'outils. ToolSpace procède à l'inverse : il utilise des règles déterministes (sans recourir au jugement d'un grand modèle) pour extraire trois types de dépendances — données, état et réessai — à partir des appels adjacents dans les services MCP réels et les trajectoires d'agents open source. Il construit ensuite un graphe pondéré de combinaisons d'outils qu'il regroupe en clusters formant des environnements ; il ne synthétise une base de données que pour les environnements modifiant l'état, tandis que les outils de requête et sans état rejouent les valeurs de retour enregistrées. Il effectue ensuite une marche aléatoire sensible à l'état avec retour arrière (rollback), décompile chaque chaîne d'appels en tâches en langage naturel assorties de vérifications par assertions, et ne conserve que les échantillons pouvant être rejoués avec succès depuis l'état initial.

Les extensions actuelles d'environnements MCP consistent souvent à « créer d'abord la base de données et le scénario, puis en déduire les outils et les tâches », ce qui entraîne une incompatibilité entre les interfaces des outils et la réalité, ainsi que l'absence de validation par exécution des combinaisons d'outils. ToolSpace procède à l'inverse : il utilise des règles déterministes (sans recourir au jugement d'un grand modèle) pour extraire trois types de dépendances — données, état et réessai — à partir des appels adjacents dans les services MCP réels et les trajectoires d'agents open source. Il construit ensuite un graphe pondéré de combinaisons d'outils qu'il regroupe en clusters formant des environnements ; il ne synthétise une base de données que pour les environnements modifiant l'état, tandis que les outils de requête et sans état rejouent les valeurs de retour enregistrées. Il effectue ensuite une marche aléatoire sensible à l'état avec retour arrière (rollback), décompile chaque chaîne d'appels en tâches en langage naturel assorties de vérifications par assertions, et ne conserve que les échantillons pouvant être rejoués avec succès depuis l'état initial.

J'aime 34 · Étoiles du code 28

Raisons

  • Les auteurs affirment que sur sept benchmarks de tâches longues centrées sur les outils, la moyenne des scores de Qwen3.6-35B-A3B passe de 23.0 à 41.0 (et atteint 43.2 avec l'ajout du RL), tandis que GLM-5.2 passe de 44.6 à 56.6, égalant ainsi Claude Opus 5. Les ablations montrent que les « arêtes de dépendance observées pendant l'exécution » sont nettement plus efficaces que celles déduites par un grand modèle, et que les scores augmentent avec la quantité de données et d'environnements.
  • Le même processus permet de créer des versions Pro plus difficiles à partir d'AutomationBench et de tau3-Bench Banking ; les auteurs rapportent que parmi 7 modèles de pointe, le score maximal chute de 38.2 points. Le dépôt publie les paquets de tâches et les scripts d'évaluation pour AutomationBench Pro et Tau3 Banking Pro.
  • Les poids sont disponibles : sur Hugging Face, dongguanting/ToolSpace-8B (MIT), ToolSpace-35B-A3B (SFT + RL agentique, Apache-2.0) et ToolSpace-744B-A40B (base GLM-5.2, SFT uniquement, MIT). Les likes du jour sur Hugging Face s'élèvent à 34 et les étoiles du code à 28 (représentant uniquement le niveau d'attention).

Utilisation

  • Expérience hors ligne du processus de synthèse (sans clé API nécessaire) : cd Tool-Space && uv sync --locked, puis uv run python run_pipeline.py demo --output outputs/demo, et enfin uv run python run_pipeline.py verify --tasks outputs/demo/tasks. L'exécution des environnements et le rejeu sont réels, tandis que les réponses du modèle utilisent des exemples fixes.
  • Déploiement du modèle (exemple de carte modèle, 4 cartes GPU, fenêtre de contexte de 64K) : vllm serve dongguanting/ToolSpace-35B-A3B --tensor-parallel-size 4 --max-model-len 65536 --enable-auto-tool-choice --tool-call-parser qwen3_xml --reasoning-parser qwen3.
  • Évaluation : copiez benchmark/.env.example vers benchmark/.env et renseignez l'adresse du modèle à tester, puis exécutez cd benchmark && bash setup_all.sh, suivi de SCOPE=smoke RUN_NAME=my-model-smoke bash AutomationBench/run.sh pour un test de fumée. Pour la version Pro, utilisez evaluate.py validate / run dans le répertoire Automation-Pro/.

Risques

  • L'évaluation en ligne par défaut nécessite une clé API du service tiers Boyue (simulateur d'utilisateur, recherche et modèle d'évaluation), ainsi que des clés Serper / SerpAPI et un jeton Hugging Face. Il est possible de remplacer ces services par d'autres compatibles OpenAI, mais la configuration doit être effectuée manuellement.
  • La version publique ne fournit qu'AutomationBench comme exemple (47 services, 758 interfaces) ; le graphe complet des outils décrit dans l'article n'est pas inclus. Le README précise que l'article décrit 600 tâches AutomationBench Pro, mais que le paquet public ne contient que 300 tâches figées.
  • Il n'y a pas de fichier LICENSE à la racine du dépôt ; le README indique que les composants tiers conservent leurs propres licences. Les trois points de contrôle ont des licences différentes et tous les scores rapportés sont ceux fournis par les auteurs.

Ouvrir · Code · Page Hugging Face de l'article

Hugging Face Daily Papers

Parcourir les dernières actualités IA