Omnigent: единый harness для CLI-агентов

Что такое Omnigent

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

Практическое утверждение здесь узкое, и его стоит сформулировать прямо. Вы один раз описываете агента в YAML и указываете harness, который его запускает. Измените эту одну строку — и тот же агент будет работать через CLI другого поставщика. В остальной конфигурации ничего менять не нужно, потому что Omnigent управляет циклом над агентами, а не циклом внутри них.

Что такое мета-hарнесс и чем он отличается от фреймворка?

Харнесс — это программа, которая запускает модель в цикле. Она читает ваш запрос, вызывает инструменты, редактирует файлы и сообщает результат. Claude Code — это харнесс. Codex — это харнесс. Вы устанавливаете его, входите в систему, и он работает самостоятельно.

Фреймворк — это библиотека, на основе которой вы пишете код. Вы импортируете её, определяете шаги в Python, и ваша программа становится агентом. При смене поставщика приходится редактировать код, поскольку клиент поставщика встроен в вашу программу.

Мета-харнесс находится уровнем выше обоих вариантов. Это супервизор, который запускает харнессы как дочерние процессы. Omnigent запускает CLI поставщика, передаёт ему задачу и считывает результат. Вы продолжаете использовать уже установленный CLI и имеющуюся подписку или API-ключ, с помощью которого он оплачивается. В этом и состоит главное отличие. Оно определяет целевую аудиторию инструмента: пользователей, у которых уже работают несколько CLI агентов и которым надоело запускать их по одному в каждом терминале.

Какую проблему решает один оркестрационный слой?

• Смена поставщика требует изменить одну строку. В определении агента harness и model хранятся как данные, поэтому перенос роли от одного поставщика к другому требует изменить YAML-файл, а не переписывать конфигурацию.
• Проверка может выполняться между поставщиками. Diff, созданный одной моделью, проверяет модель другой компании. Две модели из одного семейства обычно имеют одинаковые слабые места, поэтому второе мнение от того же поставщика менее ценно.
• Политика хранится в одном месте. Ограничения расходов и запросы на подтверждение объявляются в файле агента и применяются ко всем подчинённым агентам.
• Сеанс не зависит от отдельного инструмента. Одна расшифровка содержит результаты работы нескольких 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 keys, подписки поставщиков, шлюзы, такие как OpenRouter или Ollama, а также рабочие пространства Databricks. Если на том же компьютере уже запущен локальный сервер моделей с Ollama, укажите шлюзу его адрес, и network traffic не выйдет за пределы компьютера.

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

Примеры агентов находятся в репозитории, поэтому клонируйте тот же тег, который вы установили, а не 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 (model context protocol), функции 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> — для компонентов, работающих по общему протоколу. В спецификации для субагента также можно указать pass_history: true. Этот параметр передаёт ему родительский диалог. При каждой делегации это расходует дополнительные токены, поэтому не включайте его для субагентов, которым нужна только текущая задача.

Почему длительные orchestration-задачи нужно запускать на VPS

Запуск с несколькими агентами — это не команда на две минуты. Нужно составить план, делегировать задачи, дождаться параллельной работы в git worktree, проверить результат и внести изменения. Если закрыть крышку ноутбука, вся работа остановится. VPS (virtual private server) продолжает работать и сохраняет сетевое подключение, поэтому сессия продолжается, пока вы за ней не наблюдаете.

omnigent server --background
omnigent server status

Сервер предоставляет web-интерфейс на порту 6767. Команда omnigent server status показывает, запущен ли он, а omnigent stop останавливает его. В релизах до v0.7.0 использовалась команда omni server start. Её удалили, поэтому старые инструкции и снимки экрана могут не соответствовать тому, что отображается в вашем терминале.

Не публикуйте порт 6767 на публичном адресе. Безопасны два варианта. Оставьте порт закрытым в firewall и пробросьте его через SSH с помощью ssh -N -L 6767:localhost:6767 you@your-server, а затем откройте web-интерфейс по адресу 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. Каждый sub-agent является отдельным процессом со своей рабочей копией и собственным клиентом модели, поэтому размер VPS нужно выбирать с учётом количества агентов. После запуска сервера команды omnigent login https://your-host и omnigent host https://your-host регистрируют на нём ваш ноутбук, а omnigent attach <session_id> позволяет продолжить запущенную сессию с другого устройства.

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

Omnigent выпускает изолированную среду на уровне операционной системы под названием Omnibox. В Linux она использует пространства имён bubblewrap и seccomp, поэтому границу безопасности обеспечивает ядро, а не промпт агента. Агент с внедрённой инструкцией не может обойти правило ядра с помощью текста. Сначала установите зависимость:

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. Поэтому неправильно работающий агент не сможет записать данные за пределами рабочего пространства. Скрытые файлы остаются недоступными, пока вы явно не укажете их в cwd_allow_hidden. Это не позволяет широкому разрешению на чтение незаметно открыть доступ к .ssh или .aws. Укажите egress_rules, и весь HTTP- и HTTPS-трафик будет проходить через прокси с запретом по умолчанию. Каждое правило записывается в виде "METHODS host/path-glob". credential_proxy обеспечивает дополнительную защиту: агент получает только placeholder, а прокси подставляет настоящий секрет при отправке запроса. Поэтому утечка журнала работы не раскрывает пригодный для использования секрет. В конфигурации с несколькими harness каждый субагент получает собственный блок sandbox в отдельном файле конфигурации в agents/. Так ревьюеру можно запретить доступ к сети, сохранив его для разработчика.

Ограничение указано в документации, и его важно учитывать. Sandbox операционной системы применяется к вызовам инструментов sys_os_* и к терминалам. Она не распространяется на MCP-серверы и не охватывает сам процесс supervisor Omnigent. Запущенный вами MCP-сервер работает вне sandbox с вашими разрешениями. Поэтому более надёжный вариант — выделять каждому агенту отдельную временную машину. Этому посвящён материал запуск агентов для программирования во временной виртуальной машине. Вторая часть задачи — учётные данные. При размещении шести субагентов на одном хосте становится сложнее, а не проще не допускать агентов к секретам.

Лимиты расходов задаются политиками в том же файле:

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]

Если один поставщик используется для планирования, второй — для реализации, а третий — для ревью, расходы возникают сразу в трёх местах. Поэтому задайте ограничение до первого запуска без контроля, а не после получения первого счёта. Встроенные политики также включают max_tool_calls_per_session и ask_on_os_tools. Они запрашивают подтверждение перед операциями с файлами и shell. Наши рекомендации по контролю расходов AI-агентов на 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 августа 2026 года. В период между 2026-06-19 и 2026-07-27 вышло 7 релизов с тегами, а самый длинный интервал между двумя релизами составил 11 дней. Версия v0.5.1 вышла в тот же день, что и предыдущий релиз. Первый релиз, 0.1.1 от 16 июня 2026 года, не показан на графике, поскольку для него нет предыдущего тега, относительно которого можно измерить интервал.

Два из этих релизов изменили команды, которые уже были приведены в руководствах. В v0.7.0 команда omni server start была удалена в пользу omni server --background. В v0.6.0 дополнительный компонент omnigent[memory] был переименован в omnigent[hindsight], поэтому строка установки, скопированная из материала за июнь, завершается ошибкой при сборке за июль. Поэтому в команде установки следует указывать --version, а в git clone — тег. Это требование обеспечивает воспроизводимость, а не является вопросом стиля.

Для чего я пока не стал бы ему доверять

По состоянию на August 2026 репозиторий получил около 8.1k stars, 1.2k forks и примерно 350 открытых issues. Первый публичный релиз вышел семь недель назад. Stars показывают интерес, а интерес не означает зрелость. Проект прямо называет себя alpha, и приведённая выше история релизов подтверждает, что это действительно alpha.

• Я не стал бы запускать его на хосте с production credentials, потому что sandbox не изолирует MCP servers и supervisor.
• Я не стал бы оставлять запуск без контроля без политики cost_budget, потому что три vendors могут одновременно выставить счёт, а больше ничто их не остановит.
• Я не стал бы открывать server на public IP address без настроенного OMNIGENT_AUTH_ENABLED и TLS перед ним.
• Я пока не считал бы agent YAML стабильным между minor versions, поэтому зафиксируйте version и прочитайте release notes перед обновлением.

Есть ещё один момент, о котором нужно знать заранее. В v0.6.0 добавили anonymised usage telemetry, а описание этой функции опубликовано на отдельной странице telemetry. Прочитайте эту страницу и осознанно примите решение, если машина обрабатывает работу клиентов.

Сегодня Omnigent действительно хорошо справляется с задачей, для которой его создали. У вас есть три или четыре agent CLI, вы уже платите за них и хотите, чтобы один из них выполнял запись, а другой проводил проверку. Сейчас это работает на одной машине с полноценной sandboxing в Linux. Всё остальное пока следует считать перспективным, но незавершённым.

FAQ

Omnigent — это агент или система, которая запускает агентов?

Он запускает агентов. Omnigent — это мета-обвязка: она запускает уже установленные CLI поставщиков, например Claude Code, Codex или OpenCode, назначает каждому задачи и контролирует результаты в рамках одной сессии. Собственной модели у Omnigent нет. Поэтому Omnigent отличается от framework: в framework вы пишете код на 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 tag имеет значение v0.7.0, а строка версии в PyPI — 0.7.0.

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

Для поддерживаемых функций sandbox обеспечивает надёжную изоляцию и явно определяет свои ограничения. В Linux она использует bubblewrap и seccomp, поэтому ядро ограничивает доступ к файлам и сети, а агент не может отключить эти ограничения. В документации указано, что sandbox применяется к вызовам инструментов и терминалам sys_os_*, но не распространяется на MCP servers и процесс supervisor Omnigent. Поэтому MCP server запускается с обычными разрешениями пользователя. Для автономной работы отдельная одноразовая виртуальная машина для каждого агента по-прежнему обеспечивает более сильную изоляцию.

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

В заметках проекта по развёртыванию для сервера указана рабочая область объёмом примерно от 512 MB до 1 GB, а в конфигурации Fly.io задано 1 GB. Этого достаточно для supervisor и web-интерфейса, доступного только на порту 6767. Каждый sub-agent — отдельный процесс со своей рабочей копией и клиентом модели. Запуски в стиле Polly используют параллельные git worktree, поэтому объём RAM и диска нужно рассчитывать по числу агентов, которые вы планируете запускать одновременно, а не только по параметрам сервера.