Databricks Omnigent: зачем компаниям мета-харнесс для AI-агентов

По состоянию на 24 июня 2026 года Databricks Omnigent — это open-source meta-harness для AI-агентов: слой над Claude Code, Codex, Cursor, Pi и кастомными агентами, который нужен не для ещё одного чата, а для управления сессиями, политиками, sandbox, расходами и совместной работой.

Databricks пытается решить проблему, которую компании уже начинают чувствовать: агентные инструменты размножаются быстрее, чем появляются правила их эксплуатации. Разработчик держит Claude Code, Codex и Cursor в разных окнах. Команда data science строит своих агентов. Security хочет понять, куда они ходят, что читают и сколько тратят. Omnigent предлагает общий слой над этим пёстрым набором инструментов.

Инфоповод пришёл из выпуска Latent Space от 24 июня 2026 года с Матеем Захарией и Рейнольдом Синем из Databricks. В нём Omnigent обсуждают шире, чем обычный релиз на GitHub: как часть будущей инфраструктуры для agent clouds, где важны не только модели, но и контекст, права доступа, история сессий, контроль стоимости и переносимость между средами запуска.

Что такое Databricks Omnigent

Omnigent — открытый фреймворк и meta-harness для AI-агентов. Databricks описывает его как слой поверх существующих harnesses: Claude Code, Codex, Pi, agent SDKs и кастомных агентов. Репозиторий Omnigent дополнительно называет Cursor. Идея в том, чтобы не переписывать рабочий процесс под каждый агентный инструмент, а дать им общий интерфейс: сообщения и файлы на входе, потоки текста, tool calls и артефакты на выходе.

В официальном анонсе Databricks выделяет три функции: composition, control и collaboration. Composition позволяет сочетать разные модели, harnesses и агентные техники без переписывания кода. Control добавляет политики на уровне meta-harness: бюджеты, permissions и guardrails, которые отслеживают состояние сессии. Collaboration превращает live agent session в рабочее место, куда можно пригласить коллег, вместе смотреть файлы и направлять агента.

Отсюда отличие от обычного «агента для кода». Omnigent не заменяет Claude Code или Codex, а ставит над ними диспетчерский слой, где сессии можно переносить, шарить, ограничивать, аудировать и запускать в sandbox. В этом месте Omnigent пересекается с тем, что мы уже разбирали в статье про AWS Context и Continuum как слой контроля AI-агентов: рынок постепенно смещается от «какая модель умнее» к «какая инфраструктура удержит агента в рабочих рамках».

Почему компаниям мало одного Claude Code или Codex

Один агентный инструмент удобен, пока пользователь один, задача локальная, а цена ошибки терпимая. В enterprise всё ломается на соседних требованиях. Нужно дать агенту доступ к репозиториям и внутренним данным, но не ко всем. Нужно запускать код, но в изолированной среде. Нужно разрешить тратить токены, но не бесконечно. Нужно сохранить историю работы, потому что результат должны проверить коллеги.

Databricks формулирует это из собственного опыта: компания пишет, что рано внедрила coding agents в инженерной команде из 5 000+ человек и строила тысячи агентов для клиентов. Это вендорская формулировка, но она хорошо объясняет, почему Omnigent выглядит не как игрушечная оболочка, а как инфраструктурный слой. Когда агентами пользуется не один энтузиаст, а десятки команд, появляются операционные вопросы.

Таблица не доказывает, что Omnigent закрывает всё. Она показывает, где теперь проходит граница зрелости. Агентный инструмент без общего слоя быстро превращается в личную автоматизацию. Инструмент с политиками, историей, sandbox и бюджетами уже можно обсуждать с security, platform engineering и finance.

Как устроен Omnigent

В архитектуре Omnigent есть runner, server и несколько интерфейсов. Runner оборачивает агента в sandboxed session с uniform API. Server отвечает за policies, sharing, catalog, MCPs, skills и артефакты. Пользователь может работать через terminal UI, web UI, native app, mobile UI или REST API.

На уровне функций Databricks перечисляет real-time collaboration, доступ к одной сессии с разных устройств, cloud execution, contextual security policies, cost policies, OS sandbox и multi-harness authoring. Самая сильная часть здесь — не список интерфейсов, а возможность задавать политики по состоянию сессии. В анонсе приведён пример: после установки нового npm-пакета агенту можно потребовать human approval перед git push.

Ещё один пример связан с секретами. Databricks пишет, что sandbox может перехватывать и менять сетевые запросы: агент не видит GitHub security token напрямую, но approved request получает нужный секрет через egress proxy. Для корпоративной среды это не декоративная функция. Агент без доступа бесполезен, агент с прямым доступом опасен.

Тема расходов не менее приземлённая. Databricks говорит о policy, которая может остановить агента и запросить продолжение после каждых $100 затрат в сессии. Это не решает весь FinOps для LLM, но даёт точку контроля там, где агент уже может часами читать логи, перезапускать тесты и делать tool calls. Мы отдельно разбирали, почему стоимость токенов в enterprise AI растёт не только из-за цены модели: агентные циклы легко превращают мелкую задачу в дорогой процесс.

Managed Omnigent на Databricks: где начинается governance

Open-source Omnigent — только половина истории. В документации Databricks уже есть managed Omnigent on Databricks. Он включает Databricks-operated server, интеграцию с identity provider рабочего пространства, доступ к моделям через Foundation Model APIs и AI Gateway, а также Databricks Sandboxes для совместной агентной разработки и knowledge work.

Доступность пока ограничена. Документация Databricks указывает, что для Omnigent нужен включённый preview в workspace и регион, где поддерживается Databricks Unity AI Gateway. Databricks Sandbox доступен в select regions on AWS. Практический вывод простой: это ещё не функция, которую любой клиент Databricks завтра включит во всех регионах.

Связка с Unity AI Gateway объясняет enterprise-угол. На странице Gateway Databricks описывает centralized governance, tracing, guardrails, operational controls, бюджеты, rate limits, audit logs и policy decisions across AI interactions. Там же Omnigent вынесен как один из use cases: запускать, supervising и sharing agents above any harness, при этом runtime policies идут через Unity AI Gateway, а сессии трассируются в MLflow.

Здесь легко спутать продукты. Omnigent — слой работы с агентами и harnesses. Unity AI Gateway — runtime/governance layer для AI estate: моделей, агентов, MCP servers, tools и endpoint traffic. В одной статье их можно связать, но нельзя сводить друг к другу. Иначе получится общий текст про AI governance, а не материал про Databricks Omnigent.

Почему Databricks делает это открытым

В выпуске Latent Space Захария объясняет open-source ставку через сетевой эффект. Если слой должен соединять много harnesses, моделей, sandbox providers и инструментов, ему нужны внешние интеграции. Databricks приводит Spark как историческую аналогию: открытый слой выигрывает, когда вокруг него можно писать библиотеки и коннекторы.

На GitHub Omnigent опубликован под Apache 2.0 и помечен как alpha. README описывает его как open-source AI agent framework and meta-harness для orchestration Claude Code, Codex, Cursor, Pi и custom agents. То есть стратегия похожа на классическую Databricks-схему: базовый слой открыт, а управляемый enterprise-вариант с identity, AI Gateway, sandboxes и platform controls живёт внутри Databricks.

Для рынка это выглядит как ставка на переносимость. Если компании не хотят полностью зависеть от одного agent harness, им нужен общий слой, который переживёт смену модели, IDE, SDK или облачного sandbox-провайдера. Это близко к старой проблеме data stack: данные, форматы и политики должны жить дольше, чем конкретный инструмент.

Что это значит для команд

Для разработчиков Omnigent может стать оболочкой, где несколько агентов работают в одной сессии, а результаты не теряются между терминалом, браузером и телефоном. Это не отменяет привычные tools, но снижает цену переключения между ними. Особенно если в команде уже есть разные предпочтения: один пишет с Claude Code, другой проверяет через Codex, третий держит часть workflow в Cursor.

Для platform engineering и security ценность в другом. Omnigent делает агентные сессии видимыми. Можно говорить не абстрактно «агент что-то сделал», а смотреть файлы, commands, tool calls, sandbox, policies, budget и history. Рядом появляется нормальный разговор про approvals, audit и ответственность. В статье про безопасность агентских систем мы уже писали, что память, доступы и журналирование — это базовый слой, а не украшение. Omnigent идёт в ту же сторону.

Для руководителей главный вывод проще. Если компания уже покупает несколько AI-инструментов для разработки, данных и операций, следующий риск — не отсутствие ещё одного агента. Риск в том, что у каждого агента своя история, свои права, свои расходы и свой непонятный путь к production. Omnigent предлагает ранний вариант слоя, где эти вопросы хотя бы можно собрать в одном месте.

Что пока не доказано

Первое ограничение — зрелость. Open-source Omnigent находится в alpha, а managed Omnigent on Databricks требует preview и региональной поддержки Unity AI Gateway. Это ранняя инфраструктура, а не стандарт де-факто для всех агентных команд.

Второе — переносимость на практике. Общий API звучит убедительно, но разные harnesses по-разному работают с контекстом, разрешениями, shell, файлами, tool calls и interrupt. Чем глубже workflow использует особенности конкретного инструмента, тем сложнее обещать честную заменяемость одной строкой.

Третье — governance не появляется из продукта сам. Cost policies, sandbox и audit полезны только там, где компания уже решила, кто имеет право запускать агента, какие данные ему доступны, какие действия требуют approval и что считается инцидентом. Без этих правил Omnigent рискует стать просто красивым способом запускать больше агентов одновременно.

Omnigent нельзя превращать в общий ответ на enterprise AI governance. Databricks строит большой контур вокруг AI Gateway, MLflow, Unity Catalog, Foundation Model APIs и Sandboxes. Omnigent закрывает слой агентных сессий и harnesses. Это важная часть, но не вся система управления AI.

Главное

Databricks Omnigent стоит читать как сигнал: рынок AI-агентов взрослеет до инфраструктурного слоя. Компаниям уже мало отдельных harnesses. Им нужны общие сессии, политики, sandbox, бюджеты, audit и совместная работа поверх разных инструментов.

Сильная идея Omnigent — meta-harness над агентами, а не очередной агент. Слабое место — ранняя зрелость: open-source проект в alpha, managed-версия в preview-контуре Databricks. Поэтому разумная позиция такая: смотреть, тестировать на внутренних сценариях, но не обещать бизнесу, что один новый слой решит все вопросы безопасности и контроля.

FAQ

Что такое Omnigent?

Omnigent — open-source meta-harness Databricks для AI-агентов. Он даёт общий слой над Claude Code, Codex, Cursor, Pi и кастомными агентами: сессии, файлы, политики, sandbox, history, collaboration и интерфейсы вроде web UI, terminal UI, mobile UI и REST API.

Чем Omnigent отличается от Claude Code, Codex и Cursor?

Claude Code, Codex и Cursor — отдельные агентные или coding-инструменты. Omnigent стоит над ними и помогает объединять несколько harnesses, переносить сессии, применять политики, запускать агентов в sandbox и совместно ревьюить результат. Он не заменяет эти инструменты, а пытается связать их в один управляемый контур.

Почему Omnigent связан с enterprise AI governance?

Потому что корпоративным агентам нужны не только модели. Им нужны права доступа, лимиты бюджета, журнал действий, sandbox, approvals, identity-aware controls и понятная история сессий. Omnigent закрывает часть этого слоя на уровне harnesses, а managed-вариант Databricks связывает его с Foundation Model APIs, AI Gateway и Sandboxes.

Можно ли уже использовать Omnigent в production?

С осторожностью. Open-source проект помечен как alpha. Managed Omnigent on Databricks требует preview в workspace и поддерживаемый регион Unity AI Gateway. Для production-сценариев нужны отдельная оценка рисков, политики доступа, тесты sandbox, аудит и human approval для чувствительных действий.

Читайте также

• AWS Context и Continuum: зачем AI agents слой контроля
• Стоимость токенов в enterprise AI: почему счёт за LLM растёт
• Безопасность агентских систем: атаки, GPU-часы и MEMO

Источники и проверка фактов

Факты в материале проверены 24 июня 2026 года по официальным материалам Databricks, документации Omnigent, GitHub-репозиторию проекта и выпуску Latent Space. Статусы alpha, preview и региональная доступность могут измениться после этой даты.

• Latent Space: Why the Frontier Ecosystem must be Open — Matei Zaharia and Reynold Xin, Databricks, опубликовано 24 июня 2026 года, использовано для контекста Agent Clouds, роли Omnigent, security, spend controls и тезиса про Databricks как data/AI operating system.
• Databricks Blog: Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents, опубликовано 13 июня 2026 года, использовано для определения Omnigent, composition/control/collaboration, architecture, policies, sandbox и Apache 2.0.
• Databricks Docs: Omnigent on Databricks, использовано для managed Omnigent, identity provider, Foundation Model APIs, AI Gateway, Sandboxes, preview и региональных ограничений.
• GitHub: omnigent-ai/omnigent, использовано для статуса open-source, Apache 2.0, alpha, Python 3.12+, поддерживаемых harnesses и описания проекта.
• Databricks: Unity AI Gateway, использовано для governance-контекста: policies, budgets, rate limits, audit logs, tracing, cost controls и связи с Omnigent on Databricks.
• Databricks Blog: What is an AI agent harness?, использовано для определения harness, роли tools, memory, workspace, guardrails и enterprise governance для агентных систем.