Omnigent: Ein Meta-Harness für Agent-CLIs

Was Omnigent ist

Omnigent ist ein Open-Source-Meta-Harness: eine Orchestrierungsebene, die die bereits installierten Kommandozeilenwerkzeuge (CLIs) für Agenten 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 innerhalb einer einzelnen Sitzung mit einem einheitlichen Regelsatz. Databricks hat das Repository im Juni 2026 unter der Apache-2.0-Lizenz veröffentlicht. PyPI führt das Paket weiterhin als Alpha-Version.

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

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 das Ergebnis zurück. Claude Code ist ein Harness. Codex ist ein Harness. Sie installieren es, melden sich an und es arbeitet selbststä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 ändern, weil der Client des Anbieters in Ihr Programm eingebunden ist.

Ein Meta-Harness steht 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 Rückgabewerte. Sie behalten die bereits installierte CLI und das vorhandene Abonnement oder den API-Schlüssel (application programming interface), mit dem Sie dafür 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, sie einzeln in Terminals zu bedienen.

Welches Problem löst eine Orchestrierungsebene?

• Der Wechsel des Anbieters erfordert nur eine Zeile. Die Agent-Definition enthält harness und model als Daten. Eine Rolle von einem Anbieter zu einem anderen zu verschieben, bedeutet daher eine Änderung an der YAML-Datei und keine Neuentwicklung.
• Reviews können anbieterübergreifend erfolgen. Ein von einem Modell erstellter Diff wird von einem Modell eines anderen Unternehmens gelesen. Zwei Modelle aus derselben Familie teilen meist dieselben blinden Flecken. Eine zweite Einschätzung desselben Anbieters ist daher weniger wertvoll.
• Die Richtlinie hat einen zentralen Ablageort. Budgetgrenzen und Genehmigungsabfragen werden in der Agent-Datei definiert. Sie gelten für jeden untergeordneten Sub-Agent.
• Die Sitzung ist nicht an ein einzelnes Tool gebunden. Ein Transkript deckt Arbeiten ab, die mit mehreren CLIs ausgeführt wurden. So können Sie nachvollziehen, was passiert ist, ohne vier Scrollback-Verläufe zusammenzuführen.

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

Wo ein Multi-Agent-Harness neben Tools für einzelne Agents einzuordnen ist

Wenn Sie noch keinen Agent auf einem Server ausgeführt haben, beginnen Sie stattdessen dort. Unser Leitfaden zum Ausführen eines Coding-Agents auf einem VPS behandelt den Einsatz eines einzelnen Agents vollständig. Omnigent setzt voraus, dass diese Einrichtung bereits vorhanden ist. Im größeren Bereich der Self-Hosted-AI-Agents wählen Sie die Agents selbst aus. Wenn die Begriffe hier neu für Sie sind, ist Wie Agents tatsächlich funktionieren der bessere Einstieg.

Omnigent arbeitet außerdem auf einer anderen Ebene als eine Connector-Schicht. Bei Themen wie Agents Zugriff auf Ihre eigenen Datenquellen geben geht es darum, welche Daten ein Agent erreichen kann. Bei Omnigent geht es darum, welcher Agent in welcher Reihenfolge und unter welchen Einschränkungen ausgeführt wird. Beides kann gleichzeitig erforderlich sein. Die Bereiche überschneiden sich nicht.

Was Sie vor der Installation benötigen

• Python 3.12 oder neuer. Das veröffentlichte Paket deklariert requires-python >= 3.12.
• tmux, da die Terminal-Harnesses darin ausgeführt werden.
• Mindestens eine Vendor-CLI, die bereits installiert und angemeldet ist.
• Node.js 22 oder neuer mit npm, da die Claude-, Codex- und Pi-Harnesses diese benötigen. Das Installationsprogramm prüft, ob Node 22.10 oder neuer vorhanden ist, und gibt andernfalls eine Warnung aus. Omnigent selbst benötigt Node nicht: Das Wheel auf PyPI enthält die kompilierten Web-Assets. Nur ein Build aus einem Git-Checkout macht Node zu einer zwingenden Abhängigkeit.

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 keine Dekoration. Ohne ihn interpretiert sh --version als eigene Option, und das Installationsprogramm wird überhaupt nicht ausgeführt. Wenn sh Bash ist, gibt es die eigene Version von Bash aus und wird erfolgreich beendet. Dadurch wird nichts installiert, und es erscheint keine Warnung. Mit -s -- liest sh das Skript aus der Pipe und übergibt --version 0.7.0 an das Installationsprogramm. Bei einem Repository, das alle paar Wochen inkompatible Änderungen veröffentlicht, macht das den Unterschied zwischen einem reproduzierbar eingerichteten System und einer Überraschung aus.

Release 0.7.0 ist am 29 October 2026 weiterhin auf PyPI veröffentlicht, aber das neueste Release ist jetzt 0.21.0 vom 5 November 2026. Das frühere Release 0.19.1 ist ein sicherheitsorientiertes Patch-Release ohne neue Funktionen. Es aktualisiert Abhängigkeiten nach der Kompromittierung der eMudhra-Zwischenzertifizierungsstelle, und das Projekt empfiehlt ein Upgrade. Entscheidend ist die festgelegte Version, nicht ihre Nummer: Legen Sie die von Ihnen getestete Version fest, und lesen Sie die inkompatiblen Änderungen in den Release Notes, bevor Sie sie ändern. Eine festgelegte Version ist jedoch kein Grund, ein Sicherheits-Release auszulassen. Aktualisieren Sie sie daher, sobald ein solches Release verfügbar ist.

Das Installationsprogramm verwendet uv, den Python-Paketmanager von Astral, und bietet die Installation von uv an, wenn es 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 wiederholt: --extra e2b --extra kubernetes beim Skript oder "omnigent[e2b,kubernetes]" mit uv. Das Skript fügt außerdem das Extra databricks hinzu, sofern Sie nicht --no-databricks übergeben. Die obige uv-Zeile installiert das Paket dagegen ohne dieses Extra. 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, was tatsächlich installiert wurde:

omni upgrade --check

Damit wird die installierte Version mit der neuesten veröffentlichten Version verglichen. Außerdem wird angegeben, ob ein Upgrade verfügbar ist, ohne es auszuführen. omni und omnigent sind dasselbe Programm unter zwei Namen.

Auf einen Model-Provider verweisen

omni setup

Der Assistent sucht nach bereits in Ihrer Umgebung vorhandenen Zugangsdaten und fordert Sie zur Eingabe der fehlenden Daten auf. Er unterstützt API-Keys, Anbieterabonnements, Gateways wie OpenRouter oder Ollama sowie Databricks-Workspaces. Wenn Sie auf demselben Rechner bereits einen lokalen Model-Server mit Ollama betreiben, verweisen Sie ein Gateway darauf. Der Netzwerkverkehr verlässt dann niemals den Rechner.

Ein minimaler Lauf mit mehreren Agents

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

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 die Arbeit mit mehreren Agents. Die Konfiguration definiert die Sub-Agents claude_code, codex, opencode, cursor, hermes und pi sowie eine Regel, die den gesamten Lauf sinnvoll macht: Die Prüfung erfolgt immer durch einen anderen Anbieter als die Implementierung. Polly schreibt selbst keinen Code. Es plant die Arbeit, teilt das Ziel in Arbeitselemente auf, delegiert diese einzeln 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 auf dem Rechner tatsächlich vorhanden sind. Wenn nur die CLI eines Anbieters installiert ist, kann das Diff niemandem übergeben werden. Installieren Sie daher mindestens zwei CLIs, 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 überhaupt eine Ausgabe zu erzeugen.

Sub-Agents werden als Tools deklariert

Die Agent-Datei ist YAML. executor benennt das Harness, das Modell und die 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 liegt allen zuvor genannten Komponenten zugrunde.

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 hauseigenen docs/AGENT_YAML_SPEC.md-Beispiel des Projekts und bezeichnen von Databricks gehostete Modelle. Ersetzen Sie harness und model durch die Werte, die omni setup auf Ihrem System konfiguriert. Weitere Harness-Werte in der Spezifikation sind antigravity, copilot, kimi und qwen. Die aktuelle Spezifikation unter main dokumentiert außerdem acp:<slug> für beliebige Agent Client Protocol-Server. Die Spezifikation v0.7.0 führt diesen Wert jedoch nicht auf. Prüfen Sie daher, ob er mit Ihrer festgelegten Version funktioniert, bevor Sie sich darauf verlassen. Die Spezifikation unterstützt für einen Sub-Agent außerdem pass_history: true. Damit wird ihm die übergeordnete Konversation übergeben. Das kostet bei jeder Delegierung Tokens. Deaktivieren Sie diese Option daher für Sub-Agents, die nur die aktuelle Aufgabe benötigen. Wenn die prompt eines Coders ihn anweist, die kleinste funktionierende Änderung vorzunehmen, übergibt er seinem Reviewer einen Diff, der kurz genug ist, um tatsächlich gelesen zu werden. Das ist hier wichtiger als das Modell, das Sie für eine der beiden Rollen auswählen.

Warum lang laufende Orchestrierung auf einen VPS gehört

Ein Multi-Agent-Lauf ist kein zweiminütiger Befehl. Sie planen, delegieren, warten auf parallele Git-Worktrees, prüfen und überarbeiten. Wenn Sie den Laptop zuklappen, endet der gesamte Ablauf. Ein VPS (virtueller privater Server) bleibt aktiv und behält seine Netzwerkverbindung. Dadurch läuft die Sitzung weiter, während Sie sie nicht überwachen.

omnigent server --background
omnigent server status

Der Server stellt eine Weboberfläche auf Port 6767 bereit. omnigent server status zeigt an, ob eine Sitzung läuft, und omnigent stop beendet sie. v0.7.0 entfernte omni server start zugunsten von omni server --background; v0.9.0 stellte es als veralteten Alias wieder her.

Veröffentlichen Sie 6767 nicht auf einer öffentlichen Adresse. Es gibt zwei sichere Varianten. 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. Oder terminieren Sie TLS (Transport Layer Security) davor und aktivieren Sie die Authentifizierung:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Der Firewall-Teil ist übliche Administrationsarbeit und 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 Bereitstellung als Container enthält das Verzeichnis deploy/docker/ des Repositorys eine Compose-Konfiguration: ./bootstrap.sh erzeugt Secrets in .env, anschließend startet docker compose up -d Omnigent und Postgres. Der Server läuft dabei auf Port 8000 statt auf 6767. OMNIGENT_PORT ändert diesen Host-Port. Compose berechnet DATABASE_URL automatisch für Sie. Bei anderen Bereitstellungszielen wählt dieselbe Variable Postgres oder SQLite aus. In den Containern ist OMNIGENT_AUTH_ENABLED standardmäßig auf 1 gesetzt. Das ist die richtige Standardeinstellung für alles, was von außen erreichbar ist.

Für die Dimensionierung geben die Bereitstellungshinweise den Leerlauf-Speicherverbrauch des Servers mit ungefähr 275 MB RSS an. Die Fly.io-Konfiguration reserviert eine Maschine mit 1 GB. Die Messung im Leerlauf gilt nur für den Supervisor. Die 1 GB bezeichnen den zugewiesenen Maschinenspeicher. Sub-Agents können das Arbeitsverzeichnis und die Umgebung des übergeordneten Prozesses gemeinsam nutzen, einschließlich seiner Sandbox über os_env: inherit. Separate Git-Worktrees sind eine Entscheidung der Orchestrierung. Dimensionieren Sie den Server daher für die Harnesses und Agents, die Sie gleichzeitig ausführen. 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.

Jeden Sub-Agent sandboxen, bevor Sie den Prozess beenden

Omnigent stellt eine Sandbox auf Betriebssystemebene namens Omnibox bereit. Unter Linux verwendet sie bubblewrap-Namespaces und seccomp, sodass der Kernel die Grenze erzwingt und nicht der Prompt des Agents. Ein durch einen manipulierten Prompt beeinflusster Agent kann eine Kernel-Regel nicht durch Überredung umgehen. Installieren Sie zuerst die Abhängigkeit:

sudo apt install bubblewrap

Die Konfiguration befindet sich unter os_env in der Agent-Datei:

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 fehlgeleiteter Agent kann dadurch nicht außerhalb des Workspace schreiben. Dotfiles auf der obersten Ebene des Arbeitsverzeichnisses und jede read_paths-Root bleiben verborgen, sofern sie nicht unter cwd_allow_hidden angegeben sind. Eine umfassende Lesefreigabe legt dadurch nicht stillschweigend die Verzeichnisse .ssh oder .aws auf oberster Ebene offen. Verschachtelte Dotfiles bleiben standardmäßig sichtbar. Setzen Sie cwd_hidden_scan_recursive: true, um sie im gesamten Verzeichnisbaum zu maskieren. Setzen Sie egress_rules, damit der gesamte HTTP- und HTTPS-Verkehr über einen standardmäßig sperrenden Proxy läuft. Jede Regel wird als "METHODS host/path-glob" geschrieben. credential_proxy geht noch einen Schritt weiter: Der Agent hält zu keinem Zeitpunkt das echte Secret, sondern nur einen Platzhalter. Der Proxy ersetzt ihn, wenn die Anfrage den Agenten verlässt. Dadurch enthält ein offengelegtes Transkript 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 der Netzwerkzugriff für einen Reviewer gesperrt 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 auch 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 eigener temporärer Rechner pro Agent das robustere Muster. Dieses Thema behandelt Coding-Agents in einer temporären VM ausführen. Der andere Teil der Aufgabe betrifft Zugangsdaten. Secrets außerhalb der Reichweite eines Agents halten wird schwieriger und nicht einfacher, wenn sechs Sub-Agents einen Host gemeinsam verwenden.

Ausgabenlimits sind Richtlinien, die in derselben Datei festgelegt werden:

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]

Die Richtlinie cost_budget fragt bei den weichen Schwellenwerten nach einer Bestätigung und blockiert standardmäßig alle Modelle bei max_cost_usd. Wenn Sie eine nicht leere Liste expensive_models festlegen, wird das Limit zu einer Umschaltfreigabe: Modelle außerhalb dieser Liste dürfen weiterhin Ausgaben verursachen. 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 die Schwellenwerte daher vor dem ersten unbeaufsichtigten Lauf fest und nicht erst nach der ersten Rechnung. Zu den integrierten Richtlinien gehören außerdem max_tool_calls_per_session und ask_on_os_tools. Diese fragen vor Datei- und Shell-Operationen nach einer Bestätigung. Unsere Hinweise zum Begrenzen der Kosten von AI-Agents auf einem VPS gelten hier direkt und sogar noch stärker, weil parallele Sub-Agents die Ausgaben 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 aus der eigenen Release-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. Die ersten beiden PyPI-Releases, 0.1.0 am 13. Juni 2026 und 0.1.1 am 16. Juni 2026, haben keinen Eintrag auf der GitHub-Releases-Seite und sind in der Grafik nicht enthalten. Die für v0.2.0 angezeigten drei Tage werden ab 0.1.1 gezählt.

Zwei dieser Releases änderten Befehle, 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, behielt memory jedoch als Kompatibilitätsalias bei, der bis einschließlich 0.10.0 weiterhin funktionierte. Ab 0.11.0, veröffentlicht am 25. August 2026, ist der Alias entfernt. Eine aus einem Beitrag vom Juni kopierte Installationszeile installiert den Hindsight-Client daher nicht mehr. Deshalb sollte Ihr Installationsbefehl --version enthalten und Ihr git clone einen Tag verwenden. Das ist keine Stilfrage.

Das Entwicklungstempo hat sich seit dieser Auswertung nicht verlangsamt. Am 29. Oktober 2026 führt PyPI 0.20.0, veröffentlicht am 28. Oktober, dreizehn Minor-Releases nach 0.7.0. In den Release Notes des Projekts werden in mehreren dieser Releases inkompatible Änderungen genannt. Zwei davon sind für Inhalte relevant, die von dieser Seite kopiert werden: v0.12.0 lässt einen einfachen Aufruf von omni den Hintergrund-Host statt des Polly-Agenten starten. omni run startet jetzt den Standard-Agenten. v0.13.0 erfordert für verwaltete Terminals tmux 3.3 oder neuer.

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

Am 27 October 2026 hat das Repository etwa 11k Stars, 1.8k Forks und rund 910 offene Issues. Der erste öffentliche Release liegt etwas mehr als vier Monate zurück. Stars messen das Interesse, nicht den Reifegrad. Das Projekt bezeichnet sich als Alpha. Die oben aufgeführte Release-Historie zeigt, dass dies auch tatsächlich Alpha bedeutet.

• Ich würde es nicht auf einem Host ausführen, auf dem sich Zugangsdaten für Produktionssysteme befinden, weil die Sandbox weder MCP-Server noch den Supervisor abdeckt.
• Ich würde einen Lauf ohne Überwachung nicht ohne eine cost_budget-Richtlinie starten, weil drei Anbieter parallel Kosten verursachen können. Bei einer nicht leeren expensive_models-Liste können weiterhin günstigere Modelle verwendet werden.
• Ich würde den Server nicht ohne gesetztes OMNIGENT_AUTH_ENABLED und vorgeschaltetes TLS auf einer öffentlichen IP-Adresse bereitstellen.
• Ich würde die Agent-YAML-Datei derzeit noch nicht als zwischen Minor-Versionen stabil betrachten. Pinnen 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 Telemetriedaten zur Nutzung hinzugefügt. Laut README werden diese standardmäßig erfasst. Das Projekt dokumentiert die Telemetrie einschließlich der Möglichkeit zum Opt-out auf einer eigenen Telemetrie-Seite. Lesen Sie diese Seite, und treffen Sie eine bewusste Entscheidung, wenn der Rechner für Kundenarbeit verwendet wird.

Wofür Omnigent heute tatsächlich gut geeignet ist, entspricht dem ursprünglichen Einsatzzweck. Sie haben drei oder vier Agent-CLIs, bezahlen bereits dafür und möchten, dass eine davon schreibt, während eine andere die Ergebnisse prüft. Das funktioniert bereits heute auf einem Rechner mit echter Sandbox unter 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 jeder davon Aufgaben zu und überwacht die Ergebnisse in einer Sitzung. Es bringt kein eigenes Modell mit. 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 nützlich ist?

Sie benötigen mindestens eine installierte und angemeldete Hersteller-CLI, weil Omnigent diese Programme steuert, statt 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?

Übergeben Sie --version mit sh -s -- an das Installationsskript, wie in sh -s -- --version 0.7.0. Ohne -s -- interpretiert sh --version als eigene Option, und das Installationsprogramm wird nie ausgeführt: Bash gibt beispielsweise seine eigene Version aus und wird beendet. Wenn uv bereits vorhanden ist, erfüllt uv tool install --force --python 3.12 "omnigent==0.7.0" denselben Zweck. Das Git-Tag ist v0.7.0, während die PyPI-Versionszeichenfolge 0.7.0 lautet.

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

Für den abgedeckten Bereich ist sie leistungsfähig und weist klar auf ihre Grenzen hin. Unter Linux verwendet sie bubblewrap zusammen mit seccomp. Dadurch erzwingt der Kernel die Datei- und Netzwerkbeschränkungen, und der Agent kann diese 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-Supervisor-Prozess. Ein MCP-Server läuft daher mit Ihren normalen Berechtigungen. Für unbeaufsichtigte Aufgaben bietet eine eigene, kurzlebige virtuelle Maschine pro Agent deshalb weiterhin die stärkere Isolation.

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

Die Deployment-Hinweise des Projekts nennen im Leerlauf ungefähr 275 MB RSS. Die Fly.io-Konfiguration weist einer Maschine 1 GB zu. Die Messung im Leerlauf betrifft nur den Server und nicht seine Sub-Agents. Sub-Agents können das Arbeitsverzeichnis und die Umgebung des übergeordneten Prozesses gemeinsam verwenden, einschließlich seiner Sandbox über os_env: inherit. Separate Arbeitskopien sind nicht garantiert. Läufe nach dem Polly-Muster verwenden parallele Git-Worktrees. Planen Sie RAM und Speicherplatz daher für die Anzahl der Agents, die Sie gleichzeitig ausführen möchten, und nicht nur für den Server.