Omnigent: jak zarządzać wieloma agentami CLI

Czym jest Omnigent

Omnigent to otwartoźródłowy meta-harness: jedna warstwa orkiestracji sterująca narzędziami wiersza poleceń (CLI) dla agentów, które są już zainstalowane w systemie. Nie zastępuje on narzędzi takich jak Claude Code, Codex, Cursor, OpenCode, Hermes czy Pi. Omnigent uruchamia je, przydziela każdemu zadanie i nadzoruje wynik w ramach jednej sesji z jednolitym zestawem zasad. Firma Databricks opublikowała repozytorium w czerwcu 2026 roku na licencji Apache 2.0, a strona główna nadal zawiera tekst Status: alpha.

Praktyczne założenie jest ograniczone i warto je jasno przedstawić. Agent opisywany jest jednokrotnie w formacie YAML, z podaniem nazwy harnessa, który go uruchamia. Zmiana tej jednej linii powoduje, że ten sam agent działa w oparciu o CLI innego dostawcy. Żaden inny element konfiguracji nie ulega zmianie, ponieważ Omnigent zarządza pętlą operacyjną ponad agentami, a nie pętlą wewnątrz nich.

Czym jest meta-harness i czym różni się od frameworka?

Harness to program, który otacza model pętlą operacyjną. Odczytuje on prompt, wywołuje narzędzia, edytuje pliki i raportuje wyniki. Claude Code jest harness-em. Codex jest harness-em. Instaluje się go, loguje i narzędzie działa samodzielnie.

Framework to biblioteka, w oparciu o którą pisze się kod. Importuje się ją, definiuje kroki w Python, a program staje się agentem. Zmiana dostawcy w tym przypadku oznacza edycję kodu, ponieważ klient dostawcy jest wbudowany w program.

Meta-harness znajduje się o poziom wyżej od obu tych rozwiązań. Jest to nadzorca, który uruchamia harness-y jako procesy potomne. Omnigent uruchamia CLI dostawcy, przekazuje mu zadania i odczytuje odpowiedzi. Użytkownik zachowuje zainstalowane już CLI oraz wszelkie subskrypcje lub klucze API (application programming interface), które już za nie płacą. Na tym polega cała różnica i to ona decyduje, dla kogo przeznaczone jest to narzędzie: dla osób, które mają już uruchomionych kilka agentów CLI i są zmęczone obsługiwaniem ich w osobnych oknach terminala.

Jaki problem rozwiązuje warstwa orkiestracji?

• Koszty zmiany dostawcy to jedna linijka. Definicja agenta przechowuje harness oraz model jako dane, więc przeniesienie roli między dostawcami wymaga edycji pliku YAML, a nie przepisywania kodu.
• Weryfikacja może obejmować różnych dostawców. Różnice (diff) wygenerowane przez jeden model są analizowane przez model innej firmy. Dwa modele z tej samej rodziny często wykazują te same luki, dlatego druga opinia od tego samego dostawcy ma mniejszą wartość.
• Polityka ma jedno miejsce przechowywania. Limity wydatków i monity o zatwierdzenie są deklarowane w pliku agenta i dotyczą wszystkich podrzędnych agentów.
• Sesja trwa dłużej niż jakiekolwiek pojedyncze narzędzie. Jeden zapis transkrypcji obejmuje pracę wykonaną przez kilka interfejsów CLI, co pozwala na prześledzenie przebiegu działań bez konieczności łączenia czterech osobnych historii przewijania.

Koszt stanowi sama warstwa orkiestracji. Każdy błąd w Omnigent staje się teraz błędem znajdującym się między użytkownikiem a agentem, który wcześniej działał samodzielnie. W fazie alpha jest to koszt realny, a nie teoretyczny.

Miejsce dla środowiska wieloagentowego obok narzędzi jednoagentowych

Jeśli na serwerze nie uruchomiono jeszcze żadnego agenta, należy zacząć od tego kroku. Przewodnik dotyczący uruchamiania agenta programistycznego na VPS wyczerpująco opisuje przypadek pojedynczego agenta, a taka konfiguracja jest wymagana przez Omnigent. Szersza dziedzina samodzielnie hostowanych agentów AI pozwala na wybór konkretnych agentów, natomiast zrozumienie sposobu działania agentów jest lepszym punktem wyjścia, jeśli używana tutaj terminologia jest nowa.

Omnigent stanowi również inną kategorię niż warstwa łączników. Prace takie jak zapewnienie agentom dostępu do własnych źródeł danych dotyczą zakresu dostępności zasobów dla agenta. Omnigent natomiast zarządza tym, który agent jest uruchamiany, w jakiej kolejności oraz z jakimi ograniczeniami. Można korzystać z obu tych rozwiązań jednocześnie, ponieważ nie nakładają się one na siebie.

Wymagania wstępne instalacji

• Python 3.12 lub nowszy. Opublikowany pakiet deklaruje requires-python >= 3.12.
• tmux, ponieważ środowiska terminalowe są w nim uruchamiane.
• Co najmniej jeden interfejs CLI dostawcy, zainstalowany i skonfigurowany z aktywną sesją użytkownika.
• Node.js 22 tylko w przypadku budowania aplikacji z repozytorium git. Pakiet wheel dostępny w PyPI zawiera już zbudowane zasoby webowe, więc standardowa instalacja nie wymaga obecności Node.js.

Instalacja przypiętego wydania, a nie wersji main

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

Część sh -s -- nie jest dekoracją. Bez niej sh odczytuje --version jako własną opcję, a instalator nigdy nie otrzymuje flagi, co skutkuje pobraniem najnowszej dostępnej wersji. W przypadku repozytorium, które co kilka tygodni publikuje wydania wprowadzające zmiany łamiące kompatybilność, stanowi to różnicę między powtarzalnym środowiskiem a nieprzewidzianą awarią.

Instalator korzysta z uv, menedżera pakietów Python stworzonego przez Astral, i oferuje instalację uv, jeśli narzędzie nie jest obecne. Jeśli uv jest już zainstalowane, można pominąć skrypt:

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

Dodatki podlegają temu samemu schematowi, a flaga jest powtarzana: --extra e2b --extra kubernetes w skrypcie lub "omnigent[e2b,kubernetes]" w przypadku uv. Należy zwrócić uwagę, że tag git to v0.7.0, podczas gdy wersja pakietu w PyPI to 0.7.0.

uv umieszcza plik binarny w katalogu wskazywanym przez uv tool dir --bin, zazwyczaj ~/.local/bin, a instalator oferuje dodanie tej ścieżki do profilu powłoki. Jeśli polecenie nie jest rozpoznawane bezpośrednio po czystej instalacji, jest to przyczyna. Należy sprawdzić zainstalowaną wersję:

omni upgrade --check

Polecenie to porównuje zainstalowaną wersję z najnowszą opublikowaną i informuje o dostępności aktualizacji, nie przeprowadzając jej. omni oraz omnigent to ten sam program pod dwiema nazwami.

Wskazanie dostawcy modelu

omni setup

Kreator wyszukuje poświadczenia już obecne w środowisku i prosi o podanie brakujących. Obsługuje klucze API, subskrypcje dostawców, bramy takie jak OpenRouter lub Ollama oraz obszary robocze Databricks. Jeśli na tej samej maszynie uruchomiono już lokalny serwer modelu z Ollama, należy wskazać go jako bramę, dzięki czemu ruch sieciowy nie opuści urządzenia.

Minimalne uruchomienie wielu agentów

Przykładowe agenty znajdują się w repozytorium, dlatego należy sklonować ten sam tag, który został zainstalowany, zamiast main.

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

Polly to orkiestrator kodowania dla wielu agentów, który jest dostarczany wraz z repozytorium. Jego konfiguracja deklaruje podagenty o nazwach claude_code, codex, opencode, cursor, hermes oraz pi, a także jedną regułę, która uzasadnia przeprowadzenie całego procesu: przegląd kodu zawsze wykonuje inny dostawca niż ten, który go zaimplementował. Polly nie pisze samodzielnie żadnego kodu. Planuje zadania, dzieli cel na elementy pracy, deleguje każdy z nich i kieruje każdy diff do recenzenta od innego dostawcy.

Przed delegowaniem jakiegokolwiek zadania, Polly wykonuje kontrolę wstępną, aby sprawdzić, które interfejsy CLI podagentów faktycznie istnieją w systemie. Przy zainstalowanym tylko jednym CLI dostawcy nie ma komu przekazać diffa, dlatego przed oceną wyników należy zainstalować co najmniej dwa. Debby, drugi dostarczony przykład, to agent debaty z dwiema głowami: jedną Claude i jedną GPT:

omni debby

Jest to szybki sposób na potwierdzenie, że skonfigurowano dwóch dostawców, ponieważ agent wymaga odpowiedzi od obu, aby wygenerować jakikolwiek komunikat.

Podagenci są deklarowani jako narzędzia

Plik agenta ma format YAML. executor określa środowisko uruchomieniowe (harness), model oraz uwierzytelnianie. tools zawiera serwery MCP (model context protocol), funkcje w języku Python oraz podagentów. Podagent jest narzędziem z własnym type: agent oraz własnym mechanizmem wykonawczym, co stanowi podstawę działania wszystkich powyższych elementów.

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

Identyfikatory modeli pochodzą z przykładowego pliku docs/AGENT_YAML_SPEC.md projektu i są nazwami hostowanymi w Databricks. Należy zastąpić harness oraz model wartościami omni setup skonfigurowanymi w danym środowisku. Inne wartości środowiska uruchomieniowego w specyfikacji obejmują antigravity, copilot, kimi, qwen oraz acp:<slug> dla każdego komponentu obsługującego ogólny protokół. Specyfikacja wspiera również pass_history: true dla podagenta, co przekazuje mu konwersację nadrzędną. Wiąże się to z kosztem tokenów przy każdym delegowaniu, dlatego należy wyłączyć tę opcję dla podagentów, które wymagają jedynie otrzymania bieżącego zadania. Programista, którego prompt nakazuje wprowadzenie najmniejszej działającej zmiany, dostarcza recenzentowi diff na tyle krótki, aby był czytelny, co w tym przypadku jest ważniejsze niż wybór modelu dla którejkolwiek z ról.

Dlaczego długotrwała orkiestracja powinna działać na VPS

Uruchomienie wielu agentów nie jest zadaniem na dwie minuty. Planowanie, delegowanie, oczekiwanie na równoległe operacje w drzewach roboczych git, przegląd i korekta zajmują czas. Zamknięcie pokrywy laptopa przerywa cały proces. Serwer VPS (virtual private server) pozostaje uruchomiony i utrzymuje połączenie sieciowe, dzięki czemu sesja trwa, nawet gdy nie monitorujesz jej aktywnie.

omnigent server --background
omnigent server status

Serwer udostępnia interfejs użytkownika przez przeglądarkę na porcie 6767. omnigent server status informuje, czy usługa działa, a omnigent stop ją zatrzymuje. W wydaniach starszych niż v0.7.0 służyło do tego omni server start, które zostało usunięte, dlatego starsze poradniki i zrzuty ekranu mogą nie odpowiadać obecnemu działaniu terminala.

Nie należy wystawiać portu 6767 na publiczny adres IP. Bezpieczne są dwa rozwiązania. Pierwszym jest zablokowanie portu na firewallu i przekierowanie go przez SSH za pomocą ssh -N -L 6767:localhost:6767 you@your-server, a następnie otwarcie interfejsu pod adresem http://localhost:6767 na własnym komputerze. Drugim jest zakończenie połączenia TLS (transport layer security) przed usługą i włączenie uwierzytelniania:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Konfiguracja firewalla to standardowe zadanie, opisane w podstawach obsługi ufw na VPS. Jeśli serwer obsługuje już kontenery za pomocą Traefik przed kilkoma aplikacjami Docker Compose, Omnigent można dodać jako kolejną usługę w tym samym schemacie.

W przypadku wdrożenia kontenerowego, katalog deploy/ w repozytorium zawiera konfigurację Compose: ./bootstrap.sh generuje sekrety do .env, a następnie docker compose up -d uruchamia Omnigent i Postgres na porcie 6767. DATABASE_URL pozwala wybrać między Postgres a SQLite, natomiast OMNIGENT_AUTH_ENABLED domyślnie ustawia 1 wewnątrz kontenerów, co jest właściwym ustawieniem dla każdej usługi dostępnej z zewnątrz.

Jeśli chodzi o wymagania sprzętowe, notatki wdrożeniowe określają zapotrzebowanie serwera na pamięć w zakresie od 512 MB do 1 GB, a konfiguracja Fly.io rezerwuje 1 GB. Ta wartość dotyczy wyłącznie nadzorcy. Każdy pod-agent jest osobnym procesem, który utrzymuje własną kopię repozytorium i własnego klienta modelu, dlatego należy dobrać zasoby serwera odpowiednio do liczby agentów. Gdy serwer jest gotowy, omnigent login https://your-host oraz omnigent host https://your-host rejestrują laptopa w systemie, a omnigent attach <session_id> pozwala wznowić działającą sesję z innego urządzenia.

Izoluj każdego podagenta w piaskownicy przed zakończeniem pracy

Omnigent dostarcza piaskownicę na poziomie systemu operacyjnego o nazwie Omnibox. W systemie Linux wykorzystuje ona przestrzenie nazw bubblewrap oraz seccomp, dzięki czemu to jądro systemu, a nie monit agenta, wymusza granice bezpieczeństwa. Agent, w którym doszło do wstrzyknięcia poleceń (prompt injection), nie jest w stanie obejść reguł jądra. Najpierw należy zainstalować zależność:

sudo apt install bubblewrap

Konfiguracja znajduje się w pliku agenta pod kluczem os_env:

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: []

Katalog roboczy jest dostępny tylko do odczytu, dopóki nie zostanie wymieniony w write_paths, dzięki czemu błędnie działający agent nie może zapisać danych poza obszarem roboczym. Pliki ukryte (dotfiles) pozostają niedostępne, chyba że zostaną wskazane w cwd_allow_hidden. Oznacza to, że szerokie uprawnienia do odczytu nie ujawnią automatycznie zawartości .ssh ani .aws. Ustawienie egress_rules sprawia, że cały ruch HTTP i HTTPS przechodzi przez domyślnie blokujący serwer proxy, gdzie każda reguła jest zapisana jako "METHODS host/path-glob". credential_proxy idzie o krok dalej: agent przechowuje jedynie symbol zastępczy, a proxy podmienia go na rzeczywisty sekret w momencie opuszczania żądania przez system, więc wyciek transkrypcji nie ujawnia niczego użytecznego. W konfiguracji wielozadaniowej każdy podagent posiada własny blok piaskownicy we własnym pliku konfiguracyjnym w agents/, dzięki czemu można odebrać dostęp do sieci recenzentowi, zachowując go dla implementatora.

Ograniczenia są opisane w dokumentacji i mają istotne znaczenie. Piaskownica systemowa dotyczy wywołań narzędzi sys_os_* oraz terminali. Nie obejmuje ona serwerów MCP ani samego procesu nadzorczego Omnigent. Uruchomiony serwer MCP działa poza piaskownicą, z uprawnieniami użytkownika. Ta luka sprawia, że silniejszym wzorcem pozostaje użycie jednej, jednorazowej maszyny na agenta, co jest tematem uruchamiania agentów programistycznych w maszynie wirtualnej typu disposable. Drugą częścią zadania jest zarządzanie poświadczeniami, a utrzymywanie sekretów poza zasięgiem agenta staje się trudniejsze, a nie łatwiejsze, gdy sześciu podagentów współdzieli jeden host.

Limity wydatków to polityki deklarowane w tym samym pliku:

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]

Uruchomienie, które planuje z jednym dostawcą, implementuje z drugim, a recenzuje z trzecim, generuje koszty w trzech miejscach jednocześnie. Dlatego limit należy ustawić przed pierwszym uruchomieniem bez nadzoru, a nie po otrzymaniu pierwszej faktury. Wbudowane funkcje obejmują również max_tool_calls_per_session oraz ask_on_os_tools, które wymagają zatwierdzenia przed wykonaniem operacji na plikach i w powłoce. Nasze uwagi dotyczące kontrolowania kosztów agentów AI na serwerze VPS mają tutaj bezpośrednie zastosowanie, a ich znaczenie jest większe, ponieważ równolegle działający podagenci zwielokrotniają tempo zużycia środków.

Jak szybko rozwija się to repozytorium?

[
  {
    "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
  }
]

Powyższe daty pochodzą z oficjalnej strony wydań projektu, stan na dzień 3 sierpnia 2026. W okresie między 2026-06-19 a 2026-07-27 opublikowano 7 wersji, a najdłuższa przerwa między nimi wyniosła 11 dni. Wersja v0.5.1 została wydana tego samego dnia, co poprzednia. Pierwsze wydanie, 0.1.1 z 16 czerwca 2026, pominięto na wykresie, ponieważ brak wcześniejszego tagu uniemożliwia obliczenie odstępu czasu.

Dwa z tych wydań wprowadziły zmiany powodujące błędy w poleceniach opisanych w poradnikach. Wersja v0.7.0 usunęła omni server start na rzecz omni server --background. Wersja v0.6.0 zmieniła nazwę dodatku omnigent[memory] na omnigent[hindsight], przez co polecenie instalacji skopiowane z czerwcowego artykułu kończy się niepowodzeniem w lipcowej kompilacji. Jest to argument za stosowaniem --version w poleceniu instalacji oraz konkretnego tagu w git clone, a nie kwestia preferencji stylistycznych.

Do czego jeszcze nie należy go używać

Według stanu na sierpień 2026 r. repozytorium posiada około 8,1 tys. gwiazdek, 1,2 tys. forków i mniej więcej 350 otwartych zgłoszeń, a od pierwszego publicznego wydania minęło siedem tygodni. Gwiazdki świadczą o zainteresowaniu, a zainteresowanie nie oznacza dojrzałości oprogramowania. Projekt jest oznaczony jako alpha i historia wydań potwierdza, że jest to status wczesny.

• Nie należy uruchamiać go na hoście przechowującym dane uwierzytelniające środowiska produkcyjnego, ponieważ piaskownica nie obejmuje serwerów MCP ani nadzorcy.
• Nie należy pozostawiać uruchomionego procesu bez polityki cost_budget, ponieważ trzech dostawców może naliczać opłaty równolegle i nic innego ich nie powstrzyma.
• Nie należy wystawiać serwera na publicznym adresie IP bez ustawionego OMNIGENT_AUTH_ENABLED oraz warstwy TLS przed nim.
• Nie należy traktować plików YAML agenta jako stabilnych w obrębie wersji minor, dlatego należy przypiąć wersję i zapoznać się z informacjami o wydaniu przed aktualizacją.

Warto wiedzieć jeszcze jedną rzecz, aby uniknąć niespodzianek: wersja v0.6.0 wprowadziła anonimową telemetrię użycia, a projekt dokumentuje to na dedykowanej stronie. Należy przeczytać tę stronę i podjąć świadomą decyzję, jeśli maszyna obsługuje zadania klienckie.

Tym, w czym Omnigent sprawdza się obecnie naprawdę dobrze, jest cel, do którego został stworzony. Jeśli posiadasz trzy lub cztery interfejsy CLI agentów, za które już płacisz, i chcesz, aby jeden z nich pisał, podczas gdy inny dokonuje przeglądu, to rozwiązanie działa już teraz, na jednej maszynie, z rzeczywistą piaskownicą w systemie Linux. Wszystko poza tym należy traktować jako obiecujące, lecz niedokończone.

FAQ

Czy Omnigent jest agentem, czy narzędziem uruchamiającym agentów?

Uruchamia agentów. Omnigent to meta-środowisko: uruchamia zainstalowane już interfejsy CLI dostawców, takie jak Claude Code, Codex czy OpenCode, przydziela każdemu z nich zadania i nadzoruje wyniki w jednej sesji. Nie posiada własnego modelu. Tym różni się od frameworka, w którym pisze się kod w Pythonie z użyciem biblioteki, a własny program staje się agentem.

Czy muszę mieć zainstalowane Claude Code i Codex, aby Omnigent był użyteczny?

Wymagane jest zainstalowanie i zalogowanie się do co najmniej jednego CLI dostawcy, ponieważ Omnigent steruje tymi programami, a nie zastępuje je. W przypadku dostarczonego przykładu Polly wymagane są dwa lub więcej narzędzia od różnych dostawców. Zasada Polly stanowi, że przegląd kodu zawsze wykonuje inny dostawca niż ten, który go zaimplementował, więc przy obecności tylko jednego CLI nie ma drugiego dostawcy, do którego można wysłać diff.

Jak zainstalować konkretną wersję Omnigent zamiast najnowszej?

Należy przekazać --version przez skrypt instalacyjny za pomocą sh -s --, tak jak w sh -s -- --version 0.7.0. Bez -s -- flaga jest przetwarzana przez samo sh, a skrypt instaluje najnowsze wydanie. Jeśli narzędzie uv jest już obecne, uv tool install --force --python 3.12 "omnigent==0.7.0" wykonuje to samo zadanie. Tag git to v0.7.0, natomiast ciąg wersji PyPI to 0.7.0.

Czy piaskownica Omnibox wystarcza do uruchamiania agentów bez nadzoru?

Jest skuteczna w swoim zakresie i jasno określa swoje ograniczenia. W systemie Linux wykorzystuje bubblewrap oraz seccomp, dzięki czemu jądro wymusza limity plików i sieci, których agent nie może pominąć. Dokumentacja wskazuje, że dotyczy to wywołań narzędzi sys_os_* oraz terminali, i nie obejmuje serwerów MCP ani procesu nadzorcy Omnigent. Serwer MCP działa zatem z normalnymi uprawnieniami użytkownika, dlatego jednorazowa maszyna wirtualna dla każdego agenta pozostaje bezpieczniejszą izolacją w przypadku pracy bez nadzoru.

Ile pamięci RAM potrzebuje serwer Omnigent na VPS?

Notatki wdrożeniowe projektu określają zapotrzebowanie serwera na poziomie około 512 MB do 1 GB, a konfiguracja Fly.io rezerwuje 1 GB. Dotyczy to wyłącznie nadzorcy i interfejsu webowego na porcie 6767. Każdy pod-agent jest osobnym procesem z własną kopią roboczą i klientem modelu, a uruchomienia w stylu Polly wykorzystują równoległe drzewa robocze git, dlatego zasoby RAM i dysku należy planować pod kątem liczby agentów uruchamianych jednocześnie, a nie samego serwera.