Google Opal показал предприятиям новый способ строить AI-агентов. И это меняет всё
Год назад вся корпоративная AI-сцена спорила об одном: сколько свободы давать AI-агентам? Мало — и получаешь дорогую автоматизацию, которая едва ли заслуживает звание «агента». Много — и вот уже системы удаляют данные, как случилось с ранними пользователями инструментов типа OpenClaw. На этой неделе Google Labs выпустил обновление Opal — своего no-code конструктора агентов — и тихо предложил ответ на этот вопрос. Причём ответ, который стоит внимательно изучить каждому IT-лидеру, планирующему стратегию с агентами.
Обновление добавляет то, что Google называет «agent step» — это превращает статичные, перетаскиваемые workflow-ы в динамичные, интерактивные системы. Вместо того чтобы вручную указывать, какую модель вызвать и в каком порядке, разработчик теперь просто задаёт цель — и агент сам решает, как её достичь. Выбирает инструменты, запускает модели типа Gemini 3 Flash или Veo для видеогенерации, даже начинает беседу с пользователем, если нужна дополнительная информация.
На первый взгляд — скромное обновление. Но это не так. Google поставил на поток рабочую архитектуру для трёх возможностей, которые определят корпоративные агенты в 2026 году:
- Адаптивная маршрутизация
- Постоянная память
- Человеческий контроль в цепочке оркестрации
И всё это работает благодаря стремительному прогрессу в reasoning-способностях моделей типа Gemini 3.
Почему лучшие модели ломают всё, что вы знали об агентах
Чтобы понять важность апдейта Opal, нужно разобраться в сдвиге, который назревал в экосистеме месяцами.
Первая волна корпоративных фреймворков — ранние версии CrewAI, ранние релизы LangGraph — всё строилась на натяжении между автономностью и контролем. Старые модели просто не могли надёжно принимать самостоятельные решения. Результат: «агенты на рельсах» — жёстко ограниченные workflow-ы, где каждое решение, каждый вызов инструмента, каждое ветвление прописывалось разработчиком вручную.
Работало, но было ограниченно. Нужно было предусмотреть всё, что может произойти — это комбинаторный кошмар для чего угодно, кроме простых линейных задач. Плюс такие агенты не могли адаптироваться к новым ситуациям, а именно это делает агентивный AI ценным.
Gemini 3, Claude Opus 4.6 и Sonnet 4.6 пересекли порог: модели стали достаточно хороши в планировании, рассуждениях и саморефлексии, чтобы рельсы начали сниматься. Opal как раз это признание. Новый agent step не требует от разработчика предопределять каждый путь через workflow. Вместо этого он доверяет модели оценить цель пользователя, оценить доступные инструменты и динамически найти оптимальную последовательность действий.
Это же, кстати, сделало жизнеспособным Claude Code и его агентивные workflow-ы: модели хороши в том, чтобы решить, что делать дальше, и часто даже сами исправляют ошибки без ручной переподсказки. Разница в том, что Google упаковывает это в потребительский, no-code продукт — сильный сигнал, что технология вышла из экспериментальной фазы.
Для корпоративных команд вывод прямой: если вы ещё проектируете архитектуры, требующие предопределённых путей на все случаи жизни, вы, вероятно, переусложняете. Новое поколение моделей поддерживает паттерн, где вы задаёте цели и ограничения, предоставляете инструменты — и модель сама решает маршрут. Переход от программирования агентов к управлению ими.
Память между сессиями: разница между демо и production-агентами
Второе крупное добавление в Opal — постоянная память. Теперь агенты помнят информацию между сессиями: предпочтения пользователей, прошлые взаимодействия, накопленный контекст. Агенты становятся лучше с использованием, а не начинают с нуля каждый раз.
Google не раскрыла технические детали реализации. Но сам паттерн хорошо известен сообществу. OpenClaw работает с памятью через markdown и JSON-файлы — просто, работает для одного пользователя. Но корпоративные deployment-ы — это жёсткая задача: память у множества пользователей, разные сессии, разные границы безопасности, и при этом данные одного юзера не должны просочиться к другому.
Это разделение (один пользователь против многих) — одна из самых недообсуждённых проблем в корпоративном развёртывании агентов. Персональный помощник кодирования, помнящий структуру проекта — это совсем не то же самое, что обращённый к клиентам агент, который должен держать отдельные состояния памяти для тысяч одновременных пользователей и соответствовать политикам хранения данных.
Что сигнализирует apдейт Opal: Google видит память как core-фичу архитектуры агента, не как опциональное добавление. Для IT-решейкеров, выбирающих платформу, это должно стать критерием отбора. Фреймворк без ясной стратегии памяти создаст впечатляющие демо, но упадёт в production, где ценность агента растёт с повторными взаимодействиями с теми же пользователями.
Человеческий контроль — не подушка безопасности, а принцип дизайна
Третий столп апдейта — то, что Google зовёт «interactive chat»: агент может остановиться, задать пользователю уточняющий вопрос, собрать недостающую информацию или предложить варианты перед продолжением. В терминах архитектуры это human-in-the-loop orchestration, и его присутствие в потребительском продукте — очень показательно.
Самые эффективные production-агенты на самом деле не полностью автономны. Это системы, которые понимают границы собственной уверенности и могут плавно передать контроль человеку. Именно это разделяет надёжные корпоративные агенты от runaway-систем, которые наносили репутационный урон по всей индустрии.
В LangGraph human-in-the-loop традиционно реализовалась как явный узел в графе — зашитая checkpoints, где выполнение паузируется на проверку. Opal гибче: сам агент решает, когда ему нужна помощь, основываясь на качестве и полноте информации. Это естественнее взаимодействует и лучше масштабируется — не нужно заранее предугадывать, где именно потребуется вмешательство.
Для enterprise-архитекторов урок: human-in-the-loop не просто подстраховка, приклеенная после постройки агента. Это first-class capability самого фреймворка — то, что модель может вызвать динамически, оценив собственную неуверенность.
Динамическая маршрутизация: модель выбирает путь
Последняя важная фичка — динамическая маршрутизация: разработчик определяет несколько путей через workflow, и агент выбирает подходящий на основе пользовательских критериев. Google приводит пример: агент для брифинга руководителя ходит по разным путям в зависимости, новый это клиент или уже знакомый. Для новых ищет информацию в веб, для уже знакомых смотрит внутренние заметки встреч.
Концептуально похоже на conditional branching в LangGraph. Но реализация Opal резко упрощает процесс: вместо кода можно описать критерии маршрутизации на естественном языке. Модель интерпретирует и принимает решение, а не требует разработчику писать логику.
Корпоративный смысл огромен. Динамическая маршрутизация на естественном языке значит, что бизнес-аналитики и эксперты в предметной области — не только разработчики — могут определять сложное поведение агентов. Агент-разработка переходит от чисто инженерной дисциплины к области, где знание предмета становится главным узким местом. Это может резко ускорить внедрение нетехнических подразделений.
Что реально строит Google: слой агентного интеллекта
Если отойти от отдельных фич, общий паттерн апдейта — Google строит слой интеллекта между намерением пользователя и исполнением сложных многошаговых задач. Опираясь на опыт внутреннего SDK под названием Breadboard, agent step — это не просто ещё один узел в workflow. Это слой оркестрации, который может привлекать модели, вызывать инструменты, управлять памятью, маршрутизировать динамически и взаимодействовать с людьми — всё, движимое растущими reasoning-способностями базовых Gemini-моделей.
Такой же архитектурный паттерн появляется по всей индустрии. Claude Code, способный автономно управлять задачами кодирования всю ночь, опирается на близкие принципы: мощная модель, доступ к инструментам, постоянный контекст и feedback-циклы для саморефлексии.
Для корпоративных команд вывод: архитектура агентов сходится на общем наборе примитивов: целенаправленное планирование, использование инструментов, постоянная память, динамическая маршрутизация и human-in-the-loop оркестрация. Дифференциатор — не в том, какие примитивы вы реализуете, а в том, как хорошо вы их интегрируете и как эффективно используете растущие способности frontier-моделей, чтобы снизить объём ручной конфигурации.
Практический плейбук для корпоративных агент-строителей
То, что Google выпустил эти возможности в бесплатный, потребительский продукт, отправляет ясный сигнал: фундаментальные паттерны для построения эффективных AI-агентов — это уже не передовые исследования. Это productized. Корпоративные команды, ждавшие зрелости технологии, теперь имеют рабочий пример, который могут изучить, протестировать и с которого могут учиться — бесплатно.
Практические шаги простые. Первое: оцените, не переусложнены ли ваши текущие архитектуры. Если каждая точка решения требует зашитой логики — вы, вероятно, не используете полностью возможности текущих frontier-моделей. Второе: сделайте память core-компонентом архитектуры, не afterthought. Третье: спроектируйте human-in-the-loop как динамическую способность, которую агент может вызвать, а не как фиксированный checkpoint в workflow. Четвёртое: экспериментируйте с natural language routing как способом привлечь экспертов в предметной области к дизайну агента.
Сам Opal, вероятно, не станет платформой, которую выберут предприятия. Но паттерны дизайна, которые он воплощает — адаптивные, с памятью, понимающие людей агенты, powered frontier-моделями — это паттерны, которые определят следующее поколение корпоративного AI. Google раскрыл карты. Вопрос для IT-лидеров: вы обратили внимание?
Если тема зашла — самое время держаться ближе к обновлениям (там часто всплывают детали, которые решают все).🔔 Чтобы читать больше про нейросети, AI-сервисы и практические кейсы, подписывайся на канал в Telegram!