MCP

agent-swarm: Multi-Agent-Swarm-Betriebssystem als MCP – erst die vollen Deployment-Kosten verstehen, dann starten

agent-swarm eignet sich am besten als einheitliches Orchestrierungssystem für Teams, die Multi-Agent-Swarms betreiben. Der offizielle Haupt-Installationspfad ist jedoch preset full + tunnel: Er deployt einen vollständigen Compose-Stack und schreibt lokale Zustände – ungeeignet für einen Zero-Side-Effect-Testlauf.

Official source · desplega-ai/agent-swarm

Install

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

Für wen geeignet

  • Geeignet für Teams oder Einzelpersonen, die mehrere Agents innerhalb eines einheitlichen Systems orchestrieren möchten: Über Tools für den Aufgaben-Lebenszyklus (send-task, cancel-task, task-action, poll-task, store-progress), Steering-Nachrichten, Sessions/Session-Logs sowie Budgetverwaltung (getBudget/getBudgets/upsertBudget/deleteBudget) lässt sich eine Gruppe von Agents steuern und überwachen. Die aktuelle Version ist v2.7.7.
  • Die e2e-Verträge decken „jede Route, jedes MCP-Tool und jeden Workflow-Knotentyp“ ab; in den einzelnen Domänen sind 32+ MCP-Tools dokumentiert. Das passt für Nutzer, die Multi-Agent-Kollaboration als langfristige Infrastruktur betrachten.
  • Nicht geeignet für Nutzer, die eine Zero-Deployment-Lösung mit einer einzigen Datei suchen: Der Haupt-Installationspfad ist ein Preset-full-Deployment mit Tunnel, und der Compose-Stack umfasst lead, workers, agent-fs, MinIO und Caddy; mit dem tls-Profil wird zudem unter einer echten Subdomain von agent-swarm.dev deployt.
  • Anforderungen an Zugangsdaten, Authentifizierungsmethode und die Standard-Schwellenwerte des Budget-Gates sind in den gesammelten Belegen nicht angegeben; vor der Nutzung im offiziellen README bzw. in der Dokumentation nachprüfen.

Erster Versuch in 3 Minuten

  • Der offizielle Hauptpfad ist die vollständige Installation laut README und Dokumentation: ui-install.sh --preset full --tunnel.
  • Voraussetzungen: Ein Host, auf dem mehrere Container-Dienste gestartet werden dürfen, sowie die installierte Bun-Runtime (agent-swarm basiert auf Bun, die Datenschicht ist bun:sqlite); die Quality-Gates verwenden bun run lint und tsc:check, was zeigt, dass sich der Quellcode mit Bun-Workflows verifizieren lässt.
  • Hinweis zu Nebenwirkungen: Dies ist ein echtes Deployment, kein rein lesender Test. Es werden lokale Zustände geschrieben (SQLite), Dienste wie MinIO/Caddy werden gestartet, und mit dem tls-Profil wird eine echte Subdomain belegt. Vor der Ausführung sicherstellen, dass diese Nebenwirkungen akzeptabel sind; in den Belegen gibt es keine offiziellen Rollback-/Rückgängig-Befehle – nicht davon ausgehen, dass sich alles mit einem Klick zurücksetzen lässt.
  • Erfolgssignal: Nach Abschluss des Installationsskripts laufen lead, workers, agent-fs, MinIO und Caddy im Compose-Stack; der Systemzustand lässt sich über das Dashboard-UI nachvollziehen (die offizielle Demo verwendet agent-browser).
  • Wer zunächst nur die Tool-Oberfläche kennenlernen möchte, ohne zu deployen: Für einen leichteren offiziellen Weg gibt es keine Belege – keine alternativen Installationsmethoden erfinden.

Anwendungsfälle

  • Fall 1: Eine Aufgabe auslösen und verfolgen. Nach dem Deployment per MCP send-task aufrufen, um eine Aufgabe an den Swarm zu senden, dann mit poll-task den Fortschritt abfragen und mit store-progress den Fortschritt erfassen (der Terminal-Status 'skipped' wird unterstützt); bei Bedarf mit cancel-task abbrechen. Erwartbares Ergebnis: Der Lebenszyklus der Aufgabe von der Erstellung bis zum Endzustand ist in den Session-Logs nachvollziehbar.
  • Fall 2: Ein Tagesbudget festlegen, um außer Kontrolle geratene Ausgaben zu verhindern. Mit getBudget/getBudgets das aktuelle Budget einsehen und mit upsertBudget ein Tagesausgabenlimit setzen; laut offiziellen Belegen weist das System weitere Aufgaben zurück, sobald die Ausgaben das tägliche Gate erreichen – das ist der direkteste Weg zu beobachten, wie der Budget-Mechanismus greift. Löschen erfolgt mit deleteBudget.

Nutzungsgrenzen

  • Lese-/Schreibverhalten: Es gibt sowohl rein lesende Abfragen (getBudgets, poll-task, Session-Logs) als auch Schreib- und Abbruchoperationen (send-task, upsertBudget, cancel-task); vor jedem Schreibvorgang nach dem ersten Versuch zunächst im Dashboard den Zielzustand prüfen.
  • Lokale Daten: Die Datenschicht ist bun:sqlite und schreibt lokale Datenbankzustände auf den Host; das ist ein lokaler Schreibvorgang und wird durch die Existenz von Abfragetools nicht zu einem rein lesenden Zugriff.
  • Deployment-Nebenwirkungen: Einmalig wird ein Multi-Service-Stack gestartet und möglicherweise eine echte Domain belegt; ein Rollback-Pfad ist in den Belegen nicht angegeben.
  • Noch unbestätigt: Der Standardwert des täglichen Budget-Gates, Anforderungen an Zugangsdaten und Authentifizierung sowie die vollständigen Parametersignaturen jedes MCP-Tools (bestätigt sind nur die Tool-Namen und die Anzahl von 32+); vor der Nutzung das offizielle README bzw. die Dokumentation als maßgebliche Quelle heranziehen.