Omnigent: один harness для багатьох agent CLI

Що таке Omnigent

Omnigent — це open source meta-harness: один рівень оркестрації, який керує вже встановленими інструментами командного рядка для агентів (CLI). Він не замінює Claude Code, Codex, Cursor, OpenCode, Hermes або Pi. Omnigent запускає їх, призначає кожному завдання та контролює результат в одному сеансі за єдиним набором політик. Databricks опублікувала репозиторій у June 2026 за ліцензією Apache 2.0, а на головній сторінці досі зазначено Status: alpha.

Практичне твердження є вузьким, і його варто сформулювати прямо. Ви один раз описуєте агента в YAML і вказуєте harness, який його запускає. Змініть цей один рядок — і той самий агент працюватиме через CLI іншого постачальника. Більше нічого у вашій конфігурації не змінюється, оскільки Omnigent керує циклом над агентами, а не циклом усередині них.

Що таке meta-harness і чим він відрізняється від framework?

Harness — це програма, яка запускає модель у циклі. Вона читає ваш prompt, викликає tools, редагує файли та повертає результат. Claude Code — це harness. Codex — це harness. Ви встановлюєте його, входите в систему, і він працює самостійно.

Framework — це бібліотека, для якої ви пишете код. Ви імпортуєте її, визначаєте кроки в Python, і ваша програма стає агентом. Щоб змінити vendor, потрібно редагувати код, оскільки client vendor інтегрований у вашу програму.

Meta-harness розташований на рівень вище за обидва ці компоненти. Це супервізор, який запускає harness як дочірні процеси. Omnigent запускає CLI vendor, передає йому завдання та читає отриману відповідь. Ви продовжуєте використовувати вже встановлений CLI і наявну subscription або API (application programming interface) key, за яку вже сплачується доступ. У цьому полягає вся відмінність. Саме вона визначає цільову аудиторію інструмента: людей, у яких уже працює кілька agent CLI і які втомилися запускати їх по одному в кожному терміналі.

Яку проблему розв’язує один шар оркестрації?

• Зміна постачальника потребує одного рядка. Визначення агента зберігає harness і model як дані, тому перенесення ролі від одного постачальника до іншого потребує редагування YAML-файлу, а не переписування конфігурації.
• Перевірку можна виконувати між різними постачальниками. Diff, створений однією моделлю, перевіряє модель іншої компанії. Дві моделі з одного сімейства зазвичай мають однакові слабкі місця, тому друга думка від того самого постачальника має меншу цінність.
• Політика має єдине місце визначення. Ліміти витрат і запити на підтвердження оголошуються у файлі агента та застосовуються до кожного підлеглого субагента.
• Сесія не залежить від окремого інструмента. Один transcript охоплює роботу кількох CLI, тому можна переглянути перебіг роботи, не зводячи докупи чотири окремі журнали прокручування.

Ціна — сам цей шар. Тепер кожна помилка в Omnigent стає помилкою між вами та агентом, який раніше працював самостійно. На етапі alpha це реальна ціна, а не теоретична.

Де multi-agent harness вписується поруч з інструментами для одного агента

Якщо ви ще не запускали одного агента на сервері, почніть із цього. Наш посібник із запуску coding agent на VPS охоплює сценарій з одним агентом від початку до кінця, і Omnigent передбачає, що це налаштування у вас уже є. Ширше поле self-hosted AI agents — це місце, де ви обираєте самих агентів, а як насправді працюють агенти буде кращою відправною точкою, якщо наведена тут термінологія вам незнайома.

Omnigent також належить до іншої площини, ніж connector layer. Такі завдання, як надання агентам доступу до власних джерел даних, стосуються того, до чого агент може отримати доступ. Omnigent визначає, який агент запускається, у якому порядку та з якими обмеженнями. Ви можете використовувати обидва підходи одночасно, оскільки вони не дублюють один одного.

Що потрібно до встановлення

• Python 3.12 або новішої версії. Опублікований пакет оголошує requires-python >= 3.12.
• tmux, оскільки в ньому запускаються оболонки терміналу.
• Щонайменше один CLI-інструмент постачальника, уже встановлений і з виконаним входом.
• Node.js 22 потрібен лише під час складання з git checkout. Wheel-пакет на PyPI містить уже зібрані вебресурси, тому для звичайного встановлення Node не потрібен.

Встановлюйте зафіксований реліз, а не main

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

Частина sh -s -- не є декоративною. Без неї sh сприймає --version як окрему опцію, а інсталятор не бачить цей прапорець. У результаті встановлюється версія, яка є найновішою на цей день. У репозиторії, де кожні кілька тижнів з’являються несумісні зміни, це визначає, чи буде сервер відтворюваним, чи призведе до несподіванок.

Інсталятор використовує uv — менеджер пакетів Python від Astral — і пропонує спочатку встановити uv, якщо його ще немає. Якщо uv уже встановлено, пропустіть цей скрипт:

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

Додаткові компоненти встановлюються так само, і прапорець повторюється: --extra e2b --extra kubernetes у скрипті або "omnigent[e2b,kubernetes]" з uv. Зверніть увагу: тег git має значення v0.7.0, а версія пакета на PyPI — 0.7.0.

uv розміщує бінарний файл у каталозі, який повертає uv tool dir --bin. Зазвичай це ~/.local/bin. Інсталятор пропонує додати цей каталог до профілю оболонки. Якщо одразу після чистого встановлення команда не знайдена, причина саме в цьому. Перевірте, що встановлено:

omni upgrade --check

Команда порівнює встановлену версію з останньою опублікованою версією та повідомляє, чи доступне оновлення, не виконуючи його. omni і omnigent — це та сама програма під двома назвами.

Спрямуйте його до постачальника моделей

omni setup

Майстер шукає облікові дані, які вже доступні у вашому середовищі, і запитує ті, яких бракує. Він працює з API-ключами, підписками постачальників, шлюзами на кшталт OpenRouter або Ollama, а також робочими просторами Databricks. Якщо на цій самій машині ви вже запускаєте локальний сервер моделей за допомогою Ollama, спрямуйте шлюз до нього, і трафік не залишатиме хост.

Мінімальний запуск із кількома агентами

Приклади агентів зберігаються в репозиторії, тому клонуйте той самий тег, який ви встановили, а не main.

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

Polly — це оркестратор для написання коду кількома агентами, який постачається разом із репозиторієм. Його конфігурація оголошує субагентів із назвами claude_code, codex, opencode, cursor, hermes і pi, а також одне правило, заради якого варто запускати весь приклад: перевірку завжди виконує інший постачальник, ніж реалізацію. Polly не пише код самостійно. Він планує роботу, розподіляє мету на робочі елементи, делегує кожен із них і передає кожен diff на перевірку рецензенту від іншого постачальника.

Перш ніж щось делегувати, Polly виконує попередню перевірку, щоб визначити, які CLI субагентів фактично доступні на машині. Якщо встановлено CLI лише одного постачальника, передати diff нікому, тому встановіть щонайменше два CLI, перш ніж оцінювати результат. Debby, інший приклад, що постачається разом із репозиторієм, — це агент для дебатів із двома головами: однією Claude і однією GPT:

omni debby

Це швидкий спосіб перевірити, що налаштовано два провайдери, оскільки для роботи Debby потрібні обидва.

Субагенти оголошуються як інструменти

Файл агента має формат YAML. executor визначає harness, модель і автентифікацію. tools містить MCP (протокол контексту моделі) сервери, функції Python і субагентів. Субагент — це інструмент із type: agent і власним виконавцем. Саме цей механізм лежить в основі всього описаного вище.

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

Ці ідентифікатори моделей наведено у власному прикладі docs/AGENT_YAML_SPEC.md проєкту. Це назви моделей, розміщених у Databricks. Замініть harness і model на значення, які omni setup налаштовано у вашій системі. Інші значення harness у специфікації включають antigravity, copilot, kimi, qwen і acp:<slug> для всього, що працює за generic protocol. Специфікація також підтримує pass_history: true для субагента. Цей параметр передає йому батьківську розмову. За кожного делегування це витрачає токени, тому не вмикайте його для субагентів, яким потрібне лише поточне завдання. Якщо prompt кодера вказує йому вносити найменшу працездатну зміну, він передає рецензенту достатньо короткий diff, який можна прочитати. У цьому випадку це важливіше, ніж вибір моделі для будь-якої з ролей.

Чому тривалі оркестровані процеси слід запускати на VPS

Запуск кількох агентів — це не команда на дві хвилини. Потрібно планувати, делегувати завдання, чекати на паралельну роботу в git worktree, перевіряти результат і вносити зміни. Якщо закрити кришку ноутбука, цей процес припиниться. VPS (virtual private server) продовжує працювати й зберігає мережеве підключення, тому сесія триває, навіть коли ви за нею не стежите.

omnigent server --background
omnigent server status

Сервер надає вебінтерфейс на порту 6767. omnigent server status показує, чи запущено сесію, а omnigent stop завершує її. У версіях до v0.7.0 це була команда omni server start. Її видалили, тому старі інструкції та знімки екрана можуть не відповідати тому, що виконується у вашому терміналі.

Не публікуйте порт 6767 на публічній адресі. Безпечні два варіанти. Залиште порт закритим у firewall і перенаправляйте його через SSH за допомогою ssh -N -L 6767:localhost:6767 you@your-server, після чого відкривайте вебінтерфейс за адресою http://localhost:6767 на власному комп’ютері. Або налаштуйте TLS (transport layer security) перед ним і ввімкніть автентифікацію:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Налаштування firewall описано в основах firewall ufw для VPS. Якщо на сервері вже працюють контейнери за Traefik перед кількома застосунками Docker Compose, Omnigent буде ще одним сервісом у цій самій схемі.

Для розгортання в контейнері каталог deploy/ у репозиторії містить конфігурацію Compose: ./bootstrap.sh створює секрети у .env, а docker compose up -d запускає Omnigent і Postgres на порту 6767. DATABASE_URL вибирає Postgres або SQLite, а OMNIGENT_AUTH_ENABLED за замовчуванням використовує 1 усередині контейнерів. Це правильне значення за замовчуванням для всього, що доступне ззовні.

Щодо ресурсів: в інструкціях із розгортання для робочого набору сервера вказано приблизно від 512 MB до 1 GB, а конфігурація Fly.io фіксує значення 1 GB. Це значення стосується лише supervisor. Кожен субагент є окремим процесом із власною робочою копією та власним клієнтом моделі, тому ресурси сервера потрібно розраховувати з урахуванням агентів. Після запуску сервера команда omnigent login https://your-host, а потім omnigent host https://your-host реєструє ваш ноутбук на ньому, а omnigent attach <session_id> відновлює запущену сесію з іншого пристрою.

Ізолюйте кожного субагента перед завершенням роботи

Omnigent постачає sandbox на рівні операційної системи під назвою Omnibox. У Linux він використовує простори імен bubblewrap і seccomp, тому межу контролює ядро, а не prompt агента. Агент із prompt injection не може обійти правило ядра за допомогою текстових інструкцій. Спочатку встановіть залежність:

sudo apt install bubblewrap

Конфігурація зберігається в 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: []

Робочий каталог доступний лише для читання, доки ви не додасте його до write_paths. Тому агент у разі помилки не зможе записувати дані за межами робочого простору. Dotfiles залишаються прихованими, доки їх явно не вказано в cwd_allow_hidden. Широкий дозвіл на читання при цьому не відкриває непомітно .ssh або .aws. Установіть egress_rules, і весь HTTP- та HTTPS-трафік проходитиме через проксі з політикою заборони за замовчуванням, а кожне правило матиме формат "METHODS host/path-glob". credential_proxy забезпечує додатковий рівень захисту: агент працює лише із заповнювачем, а проксі підставляє справжній секрет під час вихідного запиту. Тому витік transcript не розкриває придатних для використання даних. У конфігурації з кількома harness кожен субагент має власний блок sandbox у власному конфігураційному файлі в agents/. Так reviewer можна заборонити доступ до мережі, тоді як implementer збереже його.

Обмеження описане в документації, і воно важливе. Sandbox операційної системи застосовується до викликів інструментів sys_os_* і до терміналів. Він не охоплює MCP servers і не охоплює сам процес supervisor Omnigent. Запущений вами MCP server працює поза sandbox із вашими дозволами. Саме через цю прогалину надійнішим підходом залишається окрема одноразова машина для кожного агента. Цю тему розглянуто в запуску coding agents в одноразовій VM. Інша частина завдання — облікові дані. У матеріалі як не допустити доступу агента до секретів пояснюється, що за шістьох субагентів на одному хості захист секретів стає складнішим, а не простішим.

Ліміти витрат — це політики, оголошені в тому самому файлі:

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]

Запуск, який планує роботу з одним vendor, реалізує її з другим, а перевіряє з третім, одночасно витрачає кошти в трьох місцях. Тому встановіть ліміт до першого запуску без нагляду, а не після першого рахунку. Вбудовані параметри також містять max_tool_calls_per_session і ask_on_os_tools. Вони запитують підтвердження перед операціями з файлами та shell. Наші рекомендації в матеріалі як контролювати витрати AI agent на VPS безпосередньо застосовні й тут. Це особливо важливо, оскільки паралельні субагенти збільшують швидкість витрат.

Наскільки швидко розвивається цей репозиторій?

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

Це дати опублікованих релізів зі сторінки релізів самого проєкту, зафіксовані 3 August 2026. У період між 2026-06-19 і 2026-07-27 вийшло 7 релізів із тегами, а найдовший інтервал між будь-якими двома релізами становив 11 днів. Версію v0.5.1 випущено того самого дня, що й попередню версію. Перший реліз, 0.1.1 від 16 June 2026, не показано на графіку, оскільки немає попереднього тегу, від якого можна було б виміряти інтервал.

Два з цих релізів порушили сумісність команд, які вже були описані в інструкціях. У v0.7.0 omni server start замінено на omni server --background. У v0.6.0 додатковий компонент omnigent[memory] перейменовано на omnigent[hindsight], тому команда встановлення, скопійована з матеріалу за June, не працює у збірці за July. Саме тому в команді встановлення потрібен --version, а у вашому git clone — тег. Це вимога відтворюваності, а не питання стилю.

Що я поки не став би йому довіряти

Станом на серпень 2026 року репозиторій має близько 8.1k зірок, 1.2k fork і приблизно 350 відкритих issues, а перший публічний реліз вийшов лише сім тижнів тому. Зірки показують зацікавленість, а не зрілість. Проєкт називає себе alpha, і наведена вище історія релізів це підтверджує.

• Я не запускав би його на хості, де зберігаються production credentials, оскільки sandbox не охоплює MCP servers або supervisor.
• Я не залишав би запуск без нагляду без політики cost_budget, оскільки три vendors можуть паралельно списувати кошти, а ніщо інше їх не зупиняє.
• Я не відкривав би сервер на публічній IP-адресі без налаштованого OMNIGENT_AUTH_ENABLED і TLS перед ним.
• Я поки не вважав би agent YAML стабільним між minor versions, тому зафіксуйте версію та прочитайте release notes перед оновленням.

Є ще один момент, про який варто знати, щоб він не став несподіванкою: v0.6.0 додав anonymised usage telemetry, а проєкт описує її на окремій сторінці telemetry. Прочитайте цю сторінку та свідомо ухваліть рішення, якщо машина обробляє робочі дані клієнтів.

Сьогодні Omnigent справді добре виконує завдання, для якого його створили. У вас є три або чотири agent CLI, ви вже платите за них і хочете, щоб один із них писав код, а інший його перевіряв. Це вже працює на одній машині з повноцінним sandboxing у Linux. Усе, що виходить за ці межі, поки що слід вважати перспективним, але незавершеним.

FAQ

Omnigent — це агент чи система, що запускає агентів?

Вона запускає агентів. Omnigent — це метаоболонка: вона запускає вже встановлені вами CLI постачальників, зокрема Claude Code, Codex або OpenCode, призначає кожному завдання та контролює результати в межах одного сеансу. Власної моделі вона не має. Саме тому Omnigent відрізняється від фреймворку, у якому ви пишете код Python на основі бібліотеки, а ваша програма стає агентом.

Чи потрібно встановити Claude Code і Codex до того, як Omnigent стане корисним?

Потрібно встановити та виконати вхід принаймні в один CLI постачальника, оскільки Omnigent керує цими програмами, а не замінює їх. Для прикладу Polly, що постачається разом із системою, бажано мати два або більше CLI від різних постачальників. Правило Polly полягає в тому, що перевірку завжди виконує інший постачальник, ніж той, хто реалізує зміни. Тому за наявності лише одного CLI немає другого постачальника, якому можна передати diff.

Як встановити певну версію Omnigent, а не останню?

Передайте --version через скрипт встановлення за допомогою sh -s --, як показано в sh -s -- --version 0.7.0. Без -s -- цей прапорець обробляє сам sh, а скрипт встановлює найновіший реліз. Якщо uv уже встановлено, uv tool install --force --python 3.12 "omnigent==0.7.0" виконує те саме завдання. Тег git має значення v0.7.0, а рядок версії PyPI — 0.7.0.

Чи достатньо sandbox Omnibox для автономного запуску агентів?

Для того, що він охоплює, захист достатній, і документація чітко визначає його обмеження. У Linux він використовує bubblewrap разом із seccomp, тому ядро примусово застосовує обмеження для файлів і мережі, а агент не може їх обійти. У документації зазначено, що це поширюється на виклики інструментів і термінали sys_os_*, але не поширюється на MCP-сервери або процес-супервізор Omnigent. Тому MCP-сервер працює зі звичайними правами вашого користувача. Саме тому для автономної роботи сильнішу ізоляцію забезпечує окрема одноразова віртуальна машина для кожного агента.

Скільки пам’яті потрібно серверу Omnigent на VPS?

В інструкціях проєкту з розгортання для сервера вказано робочий набір приблизно від 512 MB до 1 GB, а в конфігурації Fly.io зарезервовано 1 GB. Цього достатньо лише для супервізора та вебінтерфейсу на порту 6767. Кожен субагент є окремим процесом із власною робочою копією та клієнтом моделі. Запуски в стилі Polly використовують паралельні git worktree, тому обсяг RAM і дискового простору слід визначати за кількістю агентів, які планується запускати одночасно, а не за вимогами самого сервера.