Omnigent: Ein Harness für viele Agent-CLIs

Was Omnigent ist

Omnigent ist ein Open-Source-Meta-Harness: eine Orchestrierungsschicht, die die bereits installierten Kommandozeilenwerkzeuge (CLIs) für Agents steuert. Es ersetzt Claude Code, Codex, Cursor, OpenCode, Hermes oder Pi nicht. Omnigent startet diese Werkzeuge, weist jedem eine Aufgabe zu und überwacht das Ergebnis in einer einzigen Sitzung mit einem einheitlichen Regelsatz. Databricks hat das Repository im Juni 2026 unter der Apache-2.0-Lizenz veröffentlicht, und auf der Startseite steht weiterhin Status: alpha.

Die praktische Aussage ist begrenzt und sollte klar formuliert werden. Sie beschreiben einen Agent einmal in YAML und geben das Harness an, das ihn ausführt. Wenn Sie diese eine Zeile ändern, läuft derselbe Agent über die CLI eines anderen Anbieters. An Ihrer übrigen Konfiguration ändert sich nichts, weil Omnigent die Schleife über den Agents steuert und nicht die Schleife innerhalb der Agents.

Was ist ein Meta-Harness, und wie unterscheidet es sich von einem Framework?

Ein Harness ist das Programm, das ein Modell in einer Schleife ausführt. Es liest Ihren Prompt, ruft Tools auf, bearbeitet Dateien und gibt Ergebnisse zurück. Claude Code ist ein Harness. Codex ist ein Harness. Sie installieren es, melden sich an, und es arbeitet eigenständig.

Ein Framework ist eine Bibliothek, gegen die Sie Code schreiben. Sie importieren sie, definieren die Schritte in Python, und Ihr Programm wird zum Agenten. Wenn Sie dort den Anbieter wechseln, müssen Sie Ihren Code bearbeiten, weil der Client des Anbieters über Ihr Programm eingebunden ist.

Ein Meta-Harness befindet sich eine Ebene über beiden. Es ist ein Supervisor, der Harnesses als untergeordnete Prozesse ausführt. Omnigent startet die CLI des Anbieters, übergibt ihr Aufgaben und liest die Ergebnisse ein. Sie behalten die bereits installierte CLI sowie das Abonnement oder den API-Schlüssel (application programming interface), mit dem Sie sie bereits bezahlen. Das ist der gesamte Unterschied. Er bestimmt, für wen das Tool gedacht ist: für Personen, bei denen bereits mehrere Agent-CLIs funktionieren und die es leid sind, diese jeweils einzeln in einem Terminal zu bedienen.

Welches Problem löst eine Orchestrierungsebene?

• Der Wechsel des Anbieters erfordert eine Zeile. Die Agent-Definition enthält harness und model als Daten. Daher ändern Sie beim Übertragen einer Rolle von einem Anbieter zu einem anderen die YAML-Datei, statt sie neu zu schreiben.
• Reviews können anbieterübergreifend erfolgen. Ein von einem Modell erstellter Diff wird von einem Modell eines anderen Unternehmens gelesen. Zwei Modelle derselben Familie haben tendenziell dieselben blinden Flecken. Daher ist eine zweite Meinung desselben Anbieters weniger wert.
• Die Richtlinie hat einen zentralen Ort. Ausgabenlimits und Genehmigungsabfragen werden in der Agent-Datei festgelegt. Sie gelten für jeden untergeordneten Agent.
• Die Sitzung ist unabhängig von einzelnen Tools. Ein Transkript umfasst die Arbeit mehrerer CLIs. Dadurch können Sie nachvollziehen, was passiert ist, ohne vier Ausgabenverläufe zusammenzuführen.

Der Nachteil ist die Ebene selbst. Jeder Fehler in Omnigent befindet sich nun zwischen Ihnen und einem Agent, der zuvor eigenständig funktioniert hat. Im Alpha-Stadium ist das ein realer und kein theoretischer Aufwand.

Wo sich ein Multi-Agent-Harness neben Einzelagenten-Tools einordnet

Wenn Sie noch keinen Agenten auf einem Server ausgeführt haben, beginnen Sie stattdessen dort. Unser Leitfaden zum Ausführen eines Coding-Agenten auf einem VPS behandelt den Fall mit einem einzelnen Agenten vollständig. Omnigent setzt voraus, dass diese Umgebung bereits vorhanden ist. Im größeren Bereich der Self-Hosted-KI-Agenten wählen Sie die Agenten selbst aus. Wie Agenten tatsächlich funktionieren ist der bessere Einstieg, wenn Ihnen die hier verwendeten Begriffe noch nicht vertraut sind.

Omnigent verfolgt außerdem eine andere Zielrichtung als eine Connector-Schicht. Bei Themen wie Agenten Zugriff auf Ihre eigenen Datenquellen geben geht es darum, welche Ressourcen ein Agent erreichen kann. Bei Omnigent geht es darum, welcher Agent in welcher Reihenfolge und unter welchen Einschränkungen ausgeführt wird. Sie können beides gleichzeitig benötigen. Die Bereiche überschneiden sich nicht.

Voraussetzungen für die Installation

• Python 3.12 oder neuer. Das veröffentlichte Paket deklariert requires-python >= 3.12.
• tmux, weil die Terminal-Harnesses darin ausgeführt werden.
• Mindestens eine Anbieter-CLI, die bereits installiert ist und bei der Sie bereits angemeldet sind.
• Node.js 22 nur, wenn Sie aus einem Git-Checkout bauen. Das Wheel auf PyPI enthält die kompilierten Web-Assets, daher benötigt die normale Installation überhaupt kein Node.

Eine festgelegte Version installieren, nicht main

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

Der Teil sh -s -- ist nicht optional. Ohne ihn interpretiert sh --version als eigene Option. Das Installationsprogramm erhält das Flag dann nicht, und Sie installieren die Version, die an diesem Tag aktuell ist. Bei einem Repository, das alle paar Wochen inkompatible Änderungen veröffentlicht, entscheidet das darüber, ob das System reproduzierbar bleibt oder unerwartet abweicht.

Das Installationsprogramm verwendet uv, den Python-Paketmanager von Astral, und bietet die Installation von uv an, wenn uv noch fehlt. Wenn uv bereits installiert ist, überspringen Sie das Skript:

uv tool install --force --python 3.12 "omnigent==0.7.0"

Extras folgen demselben Muster, und das Flag wird erneut angegeben: --extra e2b --extra kubernetes im Skript oder "omnigent[e2b,kubernetes]" mit uv. Beachten Sie, dass das git-Tag v0.7.0 lautet, während die Paketversion auf PyPI 0.7.0 ist.

uv legt die Binärdatei in dem Verzeichnis ab, das uv tool dir --bin ausgibt, normalerweise ~/.local/bin. Das Installationsprogramm bietet an, dieses Verzeichnis an Ihr Shell-Profil anzuhängen. Wenn der Befehl direkt nach einer sauberen Installation nicht gefunden wird, ist das der Grund. Prüfen Sie die installierte Version:

omni upgrade --check

Damit vergleichen Sie die installierte Version mit der zuletzt veröffentlichten Version und erfahren, ob ein Upgrade verfügbar ist, ohne es auszuführen. omni und omnigent sind dasselbe Programm unter zwei Namen.

Mit einem Modellanbieter verbinden

omni setup

Der Assistent sucht nach bereits in Ihrer Umgebung vorhandenen Zugangsdaten und fordert die fehlenden Daten an. Er unterstützt API-Schlüssel, Anbieterabonnements, Gateways wie OpenRouter oder Ollama sowie Databricks-Arbeitsbereiche. Wenn Sie bereits einen lokalen Modellserver mit Ollama auf demselben Rechner betreiben, richten Sie ein Gateway darauf aus. Der Netzwerkverkehr verlässt dann niemals diesen Rechner.

Ein minimaler Multi-Agent-Lauf

Die Beispiel-Agenten befinden sich im Repository. Klonen Sie daher denselben Tag, den Sie installiert haben, statt main zu verwenden.

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly ist der im Repository enthaltene Orchestrator für Multi-Agent-Coding. Die Konfiguration definiert die Sub-Agenten claude_code, codex, opencode, cursor, hermes und pi sowie eine Regel, die den gesamten Ablauf sinnvoll macht: Das Review wird immer von einem anderen Anbieter als die Implementierung durchgeführt. Polly schreibt selbst keinen Code. Polly plant, teilt das Ziel in Arbeitseinheiten auf, delegiert diese und leitet jedes Diff an einen Reviewer eines anderen Anbieters weiter.

Bevor Polly Aufgaben delegiert, führt es eine Vorabprüfung durch. Dabei wird ermittelt, welche Sub-Agent-CLIs tatsächlich auf dem System vorhanden sind. Wenn nur die CLI eines Anbieters installiert ist, kann niemand das Diff übernehmen. Installieren Sie daher mindestens zwei Anbieter, bevor Sie die Ausgabe bewerten. Debby, das andere enthaltene Beispiel, ist ein Debate-Agent mit zwei Köpfen: einem von Claude und einem von GPT:

omni debby

Damit lässt sich kurz bestätigen, dass zwei Provider konfiguriert sind. Debby benötigt beide, um eine Ausgabe zu erzeugen.

Sub-Agents werden als Tools deklariert

Die Agent-Datei liegt im YAML-Format vor. executor bezeichnet Harness, Modell und Authentifizierung. tools enthält MCP-Server (Model Context Protocol), Python-Funktionen und Sub-Agents. Ein Sub-Agent ist ein Tool mit type: agent und einem eigenen Executor. Dieser Mechanismus bildet die Grundlage für alle darüberliegenden Funktionen.

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

Diese Modell-IDs stammen aus dem eigenen docs/AGENT_YAML_SPEC.md-Beispiel des Projekts und bezeichnen von Databricks gehostete Modelle. Ersetzen Sie harness und model durch die Werte, die auf Ihrem System für omni setup konfiguriert sind. Weitere Harness-Werte in der Spezifikation sind antigravity, copilot, kimi, qwen und acp:<slug> für alles, was das generische Protokoll verwendet. Die Spezifikation unterstützt für einen Sub-Agent außerdem pass_history: true. Damit wird ihm die übergeordnete Unterhaltung übergeben. Das verbraucht bei jeder Delegierung zusätzliche Tokens. Lassen Sie diese Option bei Sub-Agents deaktiviert, die nur die aktuelle Aufgabe benötigen.

Warum lang laufende Orchestrierung auf einen VPS gehört

Ein Multi-Agent-Lauf ist kein zweiminütiger Befehl. Planen, delegieren, auf parallele Git-Worktrees warten, prüfen und überarbeiten. Wenn Sie den Deckel eines Laptops schließen, endet der gesamte Vorgang. Ein VPS (Virtual Private Server) bleibt aktiv und hält seine Netzwerkverbindung aufrecht. Dadurch läuft die Sitzung weiter, auch wenn Sie sie nicht beobachten.

omnigent server --background
omnigent server status

Der Server stellt eine Weboberfläche auf Port 6767 bereit. omnigent server status meldet, ob eine Sitzung läuft, und omnigent stop beendet sie. In Releases vor v0.7.0 war dies omni server start. Dieser Befehl wurde entfernt. Ältere Anleitungen und Screenshots stimmen daher nicht mit dem überein, was Ihr Terminal anzeigt.

Veröffentlichen Sie 6767 nicht auf einer öffentlichen Adresse. Zwei Varianten sind sicher. Lassen Sie den Port in der Firewall geschlossen und leiten Sie ihn mit ssh -N -L 6767:localhost:6767 you@your-server über SSH weiter. Öffnen Sie die Weboberfläche anschließend unter http://localhost:6767 auf Ihrem eigenen Rechner. Alternativ können Sie TLS (Transport Layer Security) davor terminieren und die Authentifizierung aktivieren:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Der Firewall-Teil ist eine gewöhnliche Konfigurationsaufgabe. Er wird in den Grundlagen der ufw-Firewall für einen VPS behandelt. Wenn auf dem Server bereits Container hinter Traefik vor mehreren Docker-Compose-Anwendungen laufen, ist Omnigent ein weiterer Dienst nach demselben Muster.

Für eine Container-Bereitstellung enthält das Verzeichnis deploy/ des Repositorys eine Compose-Konfiguration. ./bootstrap.sh erzeugt Geheimnisse in .env. Anschließend startet docker compose up -d Omnigent und Postgres auf Port 6767. DATABASE_URL wählt zwischen Postgres und SQLite. Innerhalb der Container verwendet OMNIGENT_AUTH_ENABLED standardmäßig 1. Das ist die richtige Voreinstellung für alles, was von außen erreichbar ist.

Bei der Dimensionierung wird in den Bereitstellungshinweisen für die Arbeitsmenge des Servers ungefähr 512 MB bis 1 GB angegeben. Die Fly.io-Konfiguration legt 1 GB fest. Dieser Wert gilt nur für den Supervisor. Jeder Sub-Agent ist ein eigener Prozess mit einem eigenen Checkout und einem eigenen Model-Client. Dimensionieren Sie den Server daher nach der Anzahl der Agents. Sobald der Server läuft, registriert omnigent login https://your-host gefolgt von omnigent host https://your-host Ihren Laptop bei ihm. Mit omnigent attach <session_id> können Sie eine laufende Sitzung von einem anderen Gerät aus wieder aufnehmen.

Sichern Sie jeden Sub-Agenten, bevor Sie ihn unbeaufsichtigt lassen

Omnigent veröffentlicht eine Sandbox auf Betriebssystemebene namens Omnibox. Unter Linux verwendet sie bubblewrap-Namespaces und seccomp. Dadurch erzwingt der Kernel die Grenze und nicht der Prompt des Agenten. Ein durch Prompt-Injection manipulierter Agent kann eine Kernel-Regel nicht durch weitere Anweisungen umgehen. Installieren Sie zunächst die Abhängigkeit:

sudo apt install bubblewrap

Die Konfiguration liegt unter os_env in der Agentendatei:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

Das Arbeitsverzeichnis ist schreibgeschützt, bis Sie es unter write_paths aufführen. Ein fehlerhaft arbeitender Agent kann daher nicht außerhalb des Workspace schreiben. Dotfiles bleiben verborgen, sofern sie nicht unter cwd_allow_hidden angegeben werden. Eine weit gefasste Leseberechtigung legt dadurch nicht unbemerkt .ssh oder .aws offen. Setzen Sie egress_rules. Dann läuft der gesamte HTTP- und HTTPS-Verkehr über einen standardmäßig ablehnenden Proxy. Jede Regel wird als "METHODS host/path-glob" eingetragen. credential_proxy geht noch einen Schritt weiter: Der Agent besitzt zu keinem Zeitpunkt das echte Secret, sondern nur einen Platzhalter. Der Proxy ersetzt ihn erst beim Verlassen der Anfrage durch das echte Secret. Ein offengelegtes Transkript enthält dadurch kein nutzbares Secret. In einer Umgebung mit mehreren Harnesses verfügt jeder Sub-Agent in seiner eigenen Konfigurationsdatei unter agents/ über einen eigenen Sandbox-Block. So kann einem Reviewer der Netzwerkzugriff verweigert werden, während der Implementierer ihn behält.

Die Dokumentation nennt diese Einschränkung ausdrücklich, und sie ist wichtig. Die Sandbox auf Betriebssystemebene gilt für sys_os_*-Tool-Aufrufe und für Terminals. Sie gilt nicht für MCP-Server und nicht für den Omnigent-Supervisor-Prozess selbst. Ein von Ihnen gestarteter MCP-Server läuft außerhalb der Sandbox mit Ihren Berechtigungen. Deshalb bleibt ein separates Wegwerf-System pro Agent das sicherere Vorgehen. Dieses Thema behandelt Coding-Agenten in einer Wegwerf-VM ausführen. Der andere Teil der Aufgabe betrifft Zugangsdaten. Secrets außerhalb der Reichweite eines Agenten halten wird schwieriger und nicht einfacher, wenn sechs Sub-Agenten denselben Host gemeinsam verwenden.

Ausgabenlimits sind Richtlinien und werden in derselben Datei festgelegt:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

Ein Lauf, der mit einem Anbieter plant, mit einem zweiten implementiert und mit einem dritten prüft, verursacht gleichzeitig an drei Stellen Kosten. Legen Sie das Limit daher vor dem ersten unbeaufsichtigten Lauf fest und nicht erst nach der ersten Rechnung. Zu den integrierten Funktionen gehören außerdem max_tool_calls_per_session und ask_on_os_tools. Damit wird vor Datei- und Shell-Operationen eine Genehmigung angefordert. Unsere Hinweise zum Kontrollieren der Kosten von KI-Agenten auf einem VPS gelten hier direkt. Das gilt umso mehr, weil parallele Sub-Agenten die Verbrauchsrate vervielfachen.

Wie schnell entwickelt sich dieses Repository?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

Das sind die veröffentlichten Release-Daten von der eigenen Releases-Seite des Projekts, abgerufen am 3. August 2026. 7 getaggte Releases wurden zwischen 2026-06-19 und 2026-07-27 veröffentlicht. Die längste Lücke zwischen zwei Releases betrug 11 Tage. v0.5.1 wurde am selben Tag wie das vorherige Release veröffentlicht. Das erste Release, 0.1.1 vom 16. Juni 2026, ist in der Grafik nicht enthalten, weil es kein vorheriges Tag gibt, von dem aus gemessen werden kann.

Zwei dieser Releases haben Befehle entfernt oder geändert, die in Anleitungen bereits dokumentiert waren. v0.7.0 entfernte omni server start zugunsten von omni server --background. v0.6.0 benannte das Extra omnigent[memory] in omnigent[hindsight] um. Deshalb schlägt eine aus einem Artikel vom Juni kopierte Installationszeile bei einem Build vom Juli fehl. Das spricht dafür, --version in Ihrem Installationsbefehl und ein Tag in Ihrem git clone zu verwenden. Das ist keine Stilfrage.

Wofür ich es derzeit noch nicht einsetzen würde

Stand August 2026 hat das Repository etwa 8.1k Sterne, 1.2k Forks und ungefähr 350 offene Issues. Die erste öffentliche Veröffentlichung liegt sieben Wochen zurück. Sterne messen das Interesse, nicht den Reifegrad. Das Projekt bezeichnet sich als Alpha, und die oben aufgeführte Release-Historie bestätigt das.

• Ich würde es nicht auf einem Host ausführen, der produktive Zugangsdaten enthält, weil die Sandbox weder MCP-Server noch den Supervisor abdeckt.
• Ich würde einen Lauf ohne cost_budget-Richtlinie nicht unbeaufsichtigt lassen, weil drei Anbieter parallel Kosten berechnen können und nichts anderes sie daran hindert.
• Ich würde den Server nicht ohne gesetztes OMNIGENT_AUTH_ENABLED und vorgeschaltetes TLS an einer öffentlichen IP-Adresse bereitstellen.
• Ich würde die Agent-YAML-Datei noch nicht als stabil zwischen Minor-Versionen behandeln. Fixieren Sie daher die Version und lesen Sie vor einem Upgrade die Release Notes.

Noch etwas sollten Sie wissen, bevor es Sie überrascht: v0.6.0 hat anonymisierte Nutzungs-Telemetrie hinzugefügt. Das Projekt dokumentiert sie auf einer eigenen Telemetrie-Seite. Lesen Sie diese Seite und entscheiden Sie bewusst, wenn die Maschine für Kundenaufträge eingesetzt wird.

Wofür Omnigent heute tatsächlich gut geeignet ist, entspricht seinem vorgesehenen Zweck. Sie haben drei oder vier Agent-CLIs, bezahlen bereits dafür und möchten, dass eines davon schreibt, während ein anderes die Ergebnisse prüft. Das funktioniert bereits jetzt auf einer Maschine mit echter Sandbox auf Linux. Alles darüber hinaus sollten Sie als vielversprechend, aber noch nicht fertig betrachten.

FAQ

Ist Omnigent ein Agent oder etwas, das Agents ausführt?

Omnigent führt Agents aus. Omnigent ist ein Meta-Harness: Es startet die bereits installierten Hersteller-CLIs wie Claude Code, Codex oder OpenCode, weist ihnen Aufgaben zu und überwacht die Ergebnisse in einer Sitzung. Es enthält kein eigenes Modell. Darin unterscheidet es sich von einem Framework, bei dem Sie Python gegen eine Bibliothek schreiben und Ihr eigenes Programm zum Agent wird.

Muss ich Claude Code und Codex installieren, bevor Omnigent sinnvoll nutzbar ist?

Sie benötigen mindestens eine installierte und angemeldete Hersteller-CLI, weil Omnigent diese Programme steuert, anstatt sie zu ersetzen. Für das mitgelieferte Polly-Beispiel benötigen Sie zwei oder mehr CLIs verschiedener Hersteller. Polly verlangt, dass die Überprüfung immer von einem anderen Hersteller als die Implementierung durchgeführt wird. Wenn nur eine CLI vorhanden ist, gibt es daher keinen zweiten Hersteller, an den der Diff gesendet werden kann.

Wie installiere ich eine bestimmte Omnigent-Version statt der neuesten Version?

Übergeben Sie --version mit sh -s -- an das Installationsskript, wie in sh -s -- --version 0.7.0. Ohne -s -- wird das Flag von sh selbst verarbeitet, und das Skript installiert das neueste Release. Wenn uv bereits vorhanden ist, übernimmt uv tool install --force --python 3.12 "omnigent==0.7.0" dieselbe Aufgabe. Der Git-Tag lautet v0.7.0, während der PyPI-Versionsstring 0.7.0 lautet.

Reicht die Omnibox-Sandbox aus, um Agents unbeaufsichtigt auszuführen?

Für die abgedeckten Bereiche bietet sie eine starke Isolation und macht ihre Grenzen klar. Unter Linux verwendet sie bubblewrap zusammen mit seccomp. Dadurch erzwingt der Kernel die Datei- und Netzwerkbeschränkungen, und der Agent kann sie nicht umgehen. Die Dokumentation gibt an, dass sie für sys_os_*-Toolaufrufe und Terminals gilt, nicht jedoch für MCP-Server oder den Omnigent-Supervisorprozess. Ein MCP-Server läuft daher mit Ihren normalen Berechtigungen. Für unbeaufsichtigte Aufgaben bleibt deshalb eine separate, kurzlebige virtuelle Maschine pro Agent die stärkere Isolation.

Wie viel Arbeitsspeicher benötigt ein Omnigent-Server auf einem VPS?

Die Deploy-Hinweise des Projekts veranschlagen für den Server eine Arbeitssatzgröße von etwa 512 MB bis 1 GB. Die Fly.io-Konfiguration reserviert 1 GB. Das deckt den Supervisor und die Weboberfläche ausschließlich auf Port 6767 ab. Jeder Sub-Agent ist ein separater Prozess mit einer eigenen Arbeitskopie und einem eigenen Modell-Client. Läufe im Polly-Stil verwenden außerdem parallele Git-Worktrees. Planen Sie RAM und Speicherplatz daher anhand der Anzahl der Agents, die Sie gleichzeitig ausführen möchten, nicht anhand des Servers.