MCP

agent-swarm : le MCP de système d'exploitation pour swarm multi-agents — évaluez le coût complet du déploiement avant de vous lancer

agent-swarm convient le mieux comme système d'orchestration unifié pour faire tourner un swarm multi-agents en équipe, mais son chemin d'installation officiel principal repose par défaut sur preset full + tunnel : il déploie d'un coup la pile Compose complète et écrit un état local, ce qui ne convient pas à un essai sans effets de bord.

Official source · desplega-ai/agent-swarm

Install

ui-install.sh --preset full --tunnel

À qui ça s'adresse

  • Aux équipes ou aux personnes qui veulent orchestrer plusieurs agents au sein d'un système unifié : piloter et superviser un ensemble d'agents via les outils de cycle de vie des tâches (send-task, cancel-task, task-action, poll-task, store-progress), les messages de steering, les sessions et les logs de session, ainsi que la gestion du budget (getBudget/getBudgets/upsertBudget/deleteBudget). La dernière version est la v2.7.7.
  • Sa couverture de contrats e2e couvre « chaque route, chaque outil MCP et chaque type de nœud de workflow », et chaque domaine documente plus de 32 outils MCP : un choix adapté à ceux qui considèrent la collaboration multi-agents comme une infrastructure de long terme.
  • En revanche, ce n'est pas fait pour ceux qui veulent un déploiement zéro, utilisable en un seul fichier : le chemin d'installation principal est un déploiement preset full avec tunnel, et la pile Compose comprend lead, workers, agent-fs, MinIO et Caddy ; avec le profil tls, le déploiement se fait même sur un vrai sous-domaine agent-swarm.dev.
  • Les exigences d'identifiants, les méthodes d'authentification et les seuils par défaut du budget gate ne sont pas précisés dans les éléments recueillis : à vérifier dans le README/la documentation officielle avant utilisation.

Première tentative en 3 minutes

  • Le chemin officiel principal est l'installation complète décrite dans le README et la documentation : ui-install.sh --preset full --tunnel.
  • Prérequis : une machine autorisant le lancement de plusieurs conteneurs de services, avec le runtime Bun installé (agent-swarm repose sur Bun, la couche de données étant bun:sqlite) ; les quality gates utilisent bun run lint et tsc:check, ce qui indique que le code source peut être validé via des workflows Bun.
  • Avertissement sur les effets de bord : il s'agit d'un déploiement réel, pas d'un essai en lecture seule. L'opération écrit un état local (SQLite), lance des services comme MinIO/Caddy et, avec le profil tls, occupe un vrai sous-domaine. Vérifiez avant l'exécution que ces effets de bord sont acceptables ; aucune commande officielle de rollback/annulation n'est fournie dans les éléments recueillis, ne partez pas du principe qu'un retour en arrière en un clic est possible.
  • Signal de succès : une fois le script d'installation terminé, lead, workers, agent-fs, MinIO et Caddy de la pile Compose sont en cours d'exécution, et l'état du système peut être vérifié via l'interface du dashboard (la démo officielle utilise agent-browser).
  • Si vous souhaitez seulement découvrir la surface d'outils sans déployer, aucun chemin officiel plus léger n'est fourni dans les éléments recueillis : ne devinez pas de méthode d'installation alternative.

Cas d'usage

  • Cas 1 : envoyer et suivre une tâche. Une fois le déploiement terminé, envoyez une tâche au swarm via l'appel MCP send-task, puis interrogez la progression avec poll-task et enregistrez la progression avec store-progress (l'état terminal « skipped » est pris en charge) ; utilisez cancel-task si nécessaire pour interrompre. Résultat attendu : le cycle de vie de la tâche, de la création à l'état final, est consultable dans les logs de session.
  • Cas 2 : définir un budget quotidien pour éviter les dérives. Appelez getBudget/getBudgets pour consulter le budget actuel, puis utilisez upsertBudget pour fixer un plafond de dépenses quotidien ; d'après les éléments officiels, lorsque les dépenses atteignent le gate quotidien, le système refuse d'accepter toute nouvelle tâche — c'est la façon la plus directe d'observer le mécanisme de budget en action. La suppression passe par deleteBudget.

Limites d'usage

  • Nature lecture/écriture : on trouve à la fois des requêtes en lecture seule (getBudgets, poll-task, logs de session) et des opérations d'écriture ou d'annulation (send-task, upsertBudget, cancel-task) ; avant toute opération d'écriture après la première tentative, vérifiez d'abord l'état cible dans le dashboard.
  • Données locales : la couche de données est bun:sqlite et écrit un état de base de données local sur la machine ; il s'agit bien d'une écriture locale, qui ne devient pas de la lecture seule sous prétexte que des outils de requête existent.
  • Effets de bord du déploiement : lancement en une fois d'une pile multi-services et occupation possible d'un vrai domaine ; aucun chemin de rollback n'est fourni dans les éléments recueillis.
  • Non confirmé : la valeur par défaut du gate de budget quotidien, les exigences d'identifiants et d'authentification, ainsi que les signatures complètes des paramètres de chaque outil MCP (seuls les noms des outils et leur nombre, 32+, sont confirmés) ; reportez-vous au README et à la documentation officiels avant utilisation.