Omnigent bereitstellen: von Ein-Klick-Plattformen bis zum eigenen Server
Omnigent ist ein Open-Source-KI-Agenten-Framework und Meta-Harness: Orchestrieren Sie Claude Code, Codex, Cursor, Pi und benutzerdefinierte Agenten, tauschen Sie Harnesses ohne Umschreiben aus, erzwingen Sie Richtlinien und Sandboxing und arbeiten Sie in Echtzeit von jedem Gerät aus zusammen.
Auf einen Blick
- Was ist das?
- Die Omnigent-README ist ein Bereitstellungsmenü: Sie behandelt Ein-Klick-Bereitstellungen auf Render und Railway, Docker Compose, Fly.io, Modal, Cloudflare und mehr, zusammen mit der Datenbankwahl Postgres/SQLite, dem Ausführungsmodell Server/Runner und den drei Authentifizierungsmodi.
- Für wen ist es gedacht?
- Geeignet ist omnigent für Teams, deren konkreter Bedarf zum README von omnigent-ai/omnigent passt. Nicht geeignet ist es als Beleg für Fähigkeiten, die dort nicht dokumentiert sind.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was die Bereitstellungs-README abdeckt bei omnigent
Die Bereitstellungs-README des Repositorys ist ein Menü zum Ausführen des Omnigent-Servers auf verschiedenen Plattformen. Sie beginnt mit Ein-Klick-Bereitstellungen auf Render und Railway, die keine lokale Werkzeugkette benötigen, automatisch eine verwaltete Postgres-Datenbank bereitstellen und standardmäßig den integrierten accounts-Authentifizierungsanbieter verwenden. Beim ersten Start wird ein Administratorkonto erstellt, dessen Passwort in den Dienstprotokollen erscheint. Darüber hinaus dokumentiert die README Fly.io, Hugging Face Spaces, Modal, Cloudflare Containers mit D1 und R2, einen Cloudflare-Quick-Tunnel zum Freigeben eines lokalen Servers, Tailscale für privaten Zugriff, Databricks Apps und ein gemeinsames Docker-Image für jeden Docker-fähigen Host. Die README weist auch darauf hin, welche Einträge Sandbox-Anbieter-Anleitungen und keine Server-Bereitstellungsziele sind.
Für omnigent-ai/omnigent ist dieser Punkt an konkrete Artefakte gebunden. Die README nennt dafür den Einstieg npm install && npm test. Bei einem Test sollten Eingabe, Ausgabe, Exit-Code und Fehlermeldung getrennt festgehalten werden. Das zeigt, ob genau der dokumentierte Pfad funktioniert; es belegt keine Eigenschaften, die die Quelle nicht nennt.
Postgres und SQLite als Datenbank-Backends bei omnigent
Der Server unterstützt zwei Datenbank-Backends, beide als erstklassig mit gleichem Schema und gleichen Migrationen beschrieben, ausgewählt über DATABASE_URL. Postgres ist die Standard- und Produktionslösung, die für mehr als eine Serverinstanz erforderlich ist, und wird auf Render und Railway automatisch bereitgestellt. Auf anderen Plattformen bringen Sie Ihre eigene mit; die README schlägt Neon vor und stellt fest, dass jede postgres://- oder postgresql://-URL funktioniert, die vom Einstiegspunkt automatisch auf den psycopg3-Dialekt normalisiert wird. SQLite ist eine Zero-Dependency-Lite-Stufe für Demos und Einzelinstanz-Bereitstellungen, wobei die .db-Datei auf dem persistenten Datenträger der Plattform liegt. Die README warnt vor ihren Grenzen: Hugging Face kostenlose Spaces haben einen ephemeren Datenträger, sodass SQLite bei einem Neustart zurückgesetzt wird, und die Volume-Semantik von Modal eignet sich nicht für eine Live-.db-Datei. Sie stellt auch fest, dass der erste Start gegen ein entferntes Postgres Migrationen über das Netzwerk ausführt, etwa eine Minute auf Neon, und dass der Arbeitssatz des Servers ungefähr 512 MB bis 1 GB beträgt.
omnigent sollte anhand seiner eigenen Konfiguration und der im README genannten Dateien beurteilt werden. Versionen, Betriebssystem, Rechte und externe Dienste gehören zur Umgebung und dürfen nicht aus dem Projektnamen abgeleitet werden. Wenn die Dokumentation einen Wert offen lässt, bleibt er eine offene Betriebsfrage.
Die HTTP/2-Proxy-Anforderung bei omnigent
Ein markanter Teil der README erklärt, warum die Auslieferung der Web-UI über HTTP/1.1 ein scheinbares Einfrieren verursacht. Jede offene Sitzung hält eine langlebige Streaming-HTTP-Antwort, und HTTP/1.1-Browser begrenzen gleichzeitige Verbindungen auf etwa sechs pro Ursprung. Wenn mehrere Fenster geöffnet sind, füllt sich der Pool mit gehaltenen Streams, und jede andere Anfrage reiht sich hinter der Begrenzung ein, sodass die UI eingefroren erscheint, während der Server im Leerlauf ist. Die Lösung besteht darin, über HTTP/2 auszuliefern, das alle Streams über eine Verbindung multiplexiert. Das gebündelte Caddy-Overlay in docker-compose.https.yaml bietet dies, und die Ein-Klick-Plattformen sowie verwaltetes Databricks terminieren TLS mit HTTP/2 an ihrem Edge. Die Lücke besteht nur, wenn der rohe :8000-HTTP/1.1-Port direkt an Browser weitergegeben wird, was die README für ein einzelnes Fenster als in Ordnung bezeichnet.
Die Lizenz Apache-2.0 ist für omnigent-ai/omnigent praktisch relevant: Sie bestimmt, unter welchen Bedingungen der Code weitergegeben oder in ein eigenes Produkt eingebunden werden darf. Der Lizenztext ersetzt keine Prüfung der Abhängigkeiten und ist keine Zusage für Support, Sicherheit oder bestimmte Leistungswerte.
Das Ausführungsmodell Server und Runner bei omnigent
Omnigent läuft in zwei Teilen, die über einen WebSocket-Tunnel verbunden sind. Der Server ist die bereitgestellte FastAPI-App; er behandelt HTTP- und SSE-Routen, Terminal-Attach-WebSockets, Persistenz und die Web-UI. Der Runner, Host genannt, ist ein Python-Subprozess auf dem Rechner des Benutzers, der über WS /v1/runner/tunnel einwählt, die LLM-Schleife und Tools lokal ausführt und Ereignisse zurückschickt. Die Bereitstellungsoptionen decken nur den Server ab; Runner werden von jedem Benutzer mit Befehlen wie omnigent run ... --server <url> oder omnigent claude --server <url> gestartet. Aufgrund dieser Trennung ist das Server-Image klein, ohne tmux, ohne Harness-SDKs, ohne LLM-API-Schlüssel, und es läuft kein Agentencode darin.
Eine sinnvolle Erstprüfung bleibt bei omnigent klein. npm install && npm test sollte mit dem im README beschriebenen Beispiel oder einer minimalen projekttypischen Eingabe laufen. Zu beobachten sind bei diesem Projekt die dort genannten Dateien, Statuswerte, Logs oder generierten Daten. Erst ein passender Befund rechtfertigt eine weitergehende Integration.
Laptop verbinden oder Hosts in Cloud-Sandboxen ausführen bei omnigent
Sobald der Server läuft, meldet sich ein Benutzer mit omnigent login https://your-host an, das den Authentifizierungsmodus des Servers automatisch erkennt, einschließlich integrierter Konten, OIDC, Header-Authentifizierungs-Proxys und Databricks-gehosteter Server. Dann registriert omnigent host https://your-host den Rechner als Host, oder omnigent run path/to/agent.yaml --server https://your-host richtet einen einmaligen Lauf an den Server. Für Cloud-Hosts statt eines Laptops behandelt die README CLI-gestartete Sandboxen auf Modal, Daytona, Islo und E2B sowie serververwaltete Hosts, bei denen das Erstellen einer Sitzung mit host_type managed den Server veranlasst, eine Sandbox bereitzustellen, einen Host zu starten und die Sitzung dort auszuführen. Sandboxen booten von einem vorgebackenen Host-Image, das die Harness-CLIs claude, codex, pi und kiro-cli enthält, und die README dokumentiert, wie man ein benutzerdefiniertes Host-Image erstellt und verwendet.
Die Materialbasis beschreibt den vorgesehenen Umfang von omnigent, aber nicht jede Kombination aus Versionen, Datenmenge und Infrastruktur. Deshalb sollte ein Team die konkrete omnigent-ai/omnigent-Revision, die verwendeten Abhängigkeiten und die erzeugten Artefakte mit dem eigenen Einsatzfall vergleichen. Nicht dokumentierte Erwartungen bleiben unbestätigt.
Authentifizierungsmodi und die Warnungen der README bei omnigent
Die Authentifizierung wird durch einen einzigen Schalter OMNIGENT_AUTH_ENABLED gesteuert. Die Framework-Standardeinstellung für einen bloßen lokalen Server lässt ihn aus, im Einzelbenutzer-Header-Modus, während die containerisierten Bereitstellungen ihn auf 1 setzen, da eine netzwerkexponierte Instanz authentifiziert sein sollte. Bei eingeschaltetem Schalter wählt die Angabe von OMNIGENT_OIDC_*-Variablen OIDC aus, andernfalls wird der integrierte accounts-Ablauf verwendet, und OMNIGENT_AUTH_PROVIDER kann den Modus explizit festlegen. Der accounts-Modus ist die Bereitstellungsstandard mit Bootstrap als erster Benutzer-Administrator und UI-Einladungen. OIDC ist für Teams mit einem vorhandenen Identitätsanbieter gedacht und erfordert HTTPS. Der Header-Modus liest standardmäßig X-Forwarded-Email von einem vertrauenswürdigen SSO-Proxy; die README warnt eindringlich, dass wenn der Proxy vom Client gelieferte Kopien des Identitätsheaders nicht entfernt, jeder jeden impersonieren kann, und empfiehlt für fast alle accounts oder OIDC.
Redaktionelles Fazit
Geeignet ist omnigent für Teams, deren konkreter Bedarf zum README von omnigent-ai/omnigent passt. Nicht geeignet ist es als Beleg für Fähigkeiten, die dort nicht dokumentiert sind. Vor dem Einsatz sollte npm install && npm test mit einer kleinen, projekttypischen Eingabe ausgeführt werden; zu prüfen sind die konkrete Ausgabe, die Abhängigkeiten, die Rechte und die Lizenz Apache-2.0.
Community-Notizen