На данный момент я прохожу 5-дневный интенсив по AI-агентам от Google и параллельно веду собственный конспект. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В некоторых местах я немного упростила формулировки или обобщила идеи.
Оригинал материала можно найти тут Introduction to Agents.

---

AI-агенты — это следующий шаг в развитии искусственного интеллекта. В отличие от моделей, которые просто генерируют текст, агенты — это автономные исполнители.

Они сочетают способность думать с умением действовать, чтобы самостоятельно решать сложные многоэтапные задачи.

Содержание документа:

Базовая анатомия: Разбор агента на три ключевых компонента: Модель (Model) для рассуждений, Инструменты (Tools) для действий и управляющий Слой оркестрации (Orchestration Layer).

Классификация возможностей агентов (A Taxonomy of Capabilities) : от простых исполнителей до сложных мультиагентных систем.

Проектирование архитектуры: Погружение в практические аспекты разработки каждого компонента — от выбора модели до реализации инструментов.

Подготовка к эксплуатации: Внедрение подхода Agent Ops, необходимого для оценки, отладки, защиты и масштабирования агентных систем — от одного экземпляра до целого парка агентов( по аналогии с таксопарком) под корпоративным управлением.

Введение, что такое AI-агент?

AI-агент можно определить как комбинацию моделей, инструментов, слоя оркестрации и сервисов рантайма, которая использует LM в цикле для достижения цели. Эти четыре элемента формируют основную архитектуру любой автономной системы.

Модель («Мозг»): Ядро — языковая (LM) или фундаментальная модель, которая служит центральным механизмом рассуждений агента для обработки информации, оценки вариантов и принятия решений. Тип модели (общего назначения, дообученная или мультимодальная) определяет когнитивные способности агента. Агентная система является главным куратором входного контекстного окна для LM.

Инструменты («Руки»): Механизмы, которые связывают рассуждения агента с внешним миром, позволяя выполнять действия, выходящие за рамки генерации текста. К ним относятся расширения API, функции кода и хранилища данных (например, базы данных или векторные хранилища) для доступа к фактической информации в реальном времени. Агентная система позволяет LM планировать, какие инструменты использовать, выполняет их и помещает результаты в контекстное окно для следующего вызова LM.

Слой оркестрации («Нервная система»): Управляющий процесс, который руководит операционным циклом агента. Он отвечает за планирование, память (состояние) и выполнение стратегии рассуждений. Этот слой использует фреймворки для промптинга и техники рассуждений (такие как Chain-of-Thought или ReAct), чтобы разбивать сложные цели на шаги и решать, когда думать, а когда использовать инструмент. Этот слой также наделяет агентов памятью, чтобы они могли «помнить».

Развёртывание («Тело и ноги»): Хотя создание агента на ноутбуке эффективно для прототипирования, именно развёртывание в продакшене делает его надёжным и доступным сервисом. Это включает хостинг агента на безопасном, масштабируемом сервере и его интеграцию с основными сервисами для мониторинга, логирования и управления. После развёртывания агент становится доступен пользователям через графический интерфейс или программно для других агентов через Agent-to-Agent (A2A) API.

В конечном счёте, создание генеративного AI-агента — это новый подход к разработке решений для выполнения задач. Традиционный разработчик действует как «каменщик», точно определяя каждый логический шаг. Разработчик агентов, напротив, больше похож на режиссёра. Вместо написания явного кода для каждого действия вы создаёте сцену (задаёте инструкции и промпты), выбираете актёров (инструменты и API) и предоставляете необходимый контекст (данные). Основной задачей становится направление этого автономного «актёра» для достижения желаемого результата.

Вы быстро обнаружите, что величайшая сила LM — её невероятная гибкость — является и вашей главной головной болью. Способность большой языковой модели делать что угодно усложняет задачу заставить её делать что-то одно, надёжно и идеально. То, что мы раньше называли “prompt engineering”, а теперь — “context engineering”, направляет LM к генерации нужного вывода. При каждом вызове LM мы передаём инструкции, факты, доступные инструменты, примеры, историю сессии, профиль пользователя и т.д., заполняя контекстное окно именно той информацией, которая нужна для получения требуемых результатов. Агенты — это программное обеспечение, управляющее входными данными для LM с целью выполнения работы.

Отладка становится необходимой при возникновении проблем. "Agent Ops" по сути переосмысливает знакомый цикл измерения, анализа и оптимизации системы. С помощью трейсов и логов вы можете отслеживать «мыслительный процесс» агента, чтобы выявить отклонения от намеченного пути выполнения.

Крайне важно помнить, что всесторонняя оценка и тестирование часто оказывают большее влияние на результат, чем первоначальный промпт.

По сути, агент — это система, посвящённая искусству курирования контекстного окна. Это непрерывный цикл: сборка контекста, вызов модели с промптом, наблюдение за результатом и повторная сборка контекста для следующего шага. Контекст может включать системные инструкции, ввод пользователя, историю сессии, долговременную память, базовые знания из авторитетных источников, доступные инструменты и результаты их предыдущих вызовов. Это сложное управление вниманием модели позволяет её способностям к рассуждению решать новые задачи и достигать целей.

В своей основе агент работает в рамках непрерывного циклического процесса для достижения своих целей. Хотя этот цикл может быть очень сложным, его можно разбить на пять фундаментальных шагов, как подробно описано в книге Agentic System Design:

1. Получить задачу (Get the Mission): Процесс начинается с конкретной, высокоуровневой цели. Эта задача ставится пользователем (например, «Организуй поездку моей команды на предстоящую конференцию») или автоматическим триггером (например, «Поступил новый высокоприоритетный тикет от клиента»).

2. Оценить обстановку (Scan the Scene): Агент анализирует окружение для сбора контекста. Для этого слой оркестрации обращается к доступным ресурсам: «Что говорится в запросе пользователя?», «Какая информация есть в моей памяти? Пытался ли я уже выполнить эту задачу? Давал ли мне пользователь указания на прошлой неделе?», «К чему я могу получить доступ через свои инструменты, такие как календари, базы данных или API?»

3. Продумать план (Think It Through): Это основной цикл «мышления» агента, управляемый моделью для рассуждений (reasoning model). Агент анализирует Задачу (Шаг 1) в контексте Обстановки (Шаг 2) и разрабатывает план. Это не одна мысль, а часто — цепочка рассуждений: «Чтобы забронировать поездку, мне сначала нужно узнать состав команды. Я использую инструмент get_team_roster. Затем мне нужно будет проверить их доступность через calendar_api».

4. Предпринять действие (Take Action): Слой оркестрации выполняет первый конкретный шаг плана. Он выбирает и вызывает подходящий инструмент — обращаясь к API, запуская функцию кода или запрашивая базу данных. Так агент воздействует на мир за пределами своих внутренних рассуждений.

5. Наблюдать и повторять (Observe and Iterate): Агент наблюдает за результатом своего действия. Инструмент get_team_roster возвращает список из пяти имён. Эта новая информация добавляется в контекст или «память» агента. Затем цикл повторяется, возвращаясь к Шагу 3: «Теперь, когда у меня есть состав команды, мой следующий шаг — проверить календарь для этих пяти человек. Я использую calendar_api».

Этот цикл «Думай, Действуй, Наблюдай» продолжается под управлением Слоя Оркестрации, с рассуждениями от Модели и исполнением через Инструменты, пока внутренний план агента не будет завершён и исходная задача не будет достигнута.

Рассмотрим на реальном примере, как агент службы поддержки будет действовать в рамках этого 5-ступенчатого цикла.

Представьте, что пользователь спрашивает: «Где мой заказ №12345?»

Вместо того чтобы немедленно действовать, агент сначала переходит на этап «Обдумывание» для разработки полной стратегии. Он рассуждает:

«Пользователь хочет узнать статус доставки. Чтобы дать полный ответ, мне нужен многошаговый план:

1. Найти заказ: Сначала я должен найти заказ в нашей внутренней базе данных, чтобы подтвердить, что он существует, и получить его детали.

2. Отследить доставку: Из деталей заказа я извлеку трекинг-номер транспортной компании. Затем я обращусь к внешнему API этой компании, чтобы узнать актуальный статус посылки.

3. Сообщить результат: Наконец, я должен объединить всю собранную информацию и сформулировать ясный и полезный ответ для пользователя».

Имея в виду этот план, агент приступает к выполнению.

На первом этапе «Действие» он выполняет первый шаг своего плана, вызывая инструмент find_order("12345"). Он наблюдает результат — полную запись о заказе, включая трекинг-номер «ZYX987».

Слой оркестрации агента распознаёт, что первая часть плана завершена, и немедленно переходит ко второй. Он действует, вызывая инструмент get_shipping_status("ZYX987"). Он наблюдает новый результат: «Передан в доставку».

Наконец, успешно завершив этапы сбора данных, агент переходит к шагу «Сообщить». Он понимает, что у него есть все необходимые компоненты, планирует финальное сообщение и действует, генерируя ответ: «Ваш заказ №12345 имеет статус „Передан в доставку“!»

Классификация агентных систем

Понимание 5-ступенчатого операционного цикла — это первая часть головоломки. Вторая заключается в осознании того, что этот цикл можно масштабировать по сложности для создания различных классов агентов. Для IT-архитектора или руководителя продукта ключевым начальным решением является определение типа создаваемого агента. Мы можем классифицировать агентные системы на несколько общих уровней, где каждый следующий развивает возможности предыдущего.

Уровень 0: Ядро для рассуждений (The Core Reasoning System)

Прежде чем у нас появится агент, мы должны начать с «Мозга» в его простейшей форме — самого механизма рассуждений. В этой конфигурации языковая модель (LM) работает изолированно, отвечая исключительно на основе своих огромных, предварительно обученных знаний, без каких-либо инструментов, памяти или взаимодействия с реальным миром.

Её сила — в этом обширном обучении, что позволяет ей с большой глубиной объяснять устоявшиеся концепции и планировать подходы к решению проблем. Обратной стороной является полное отсутствие знаний о текущих событиях; она функционально «слепа» ко всему, что произошло после сбора её обучающих данных.

Например, она может объяснить правила профессионального бейсбола и полную историю команды New York Yankees. Но если вы спросите: «Какой был итоговый счёт в игре Yankees вчера вечером?», она не сможет ответить. Эта игра — событие реального мира, которое произошло после того, как её знания были сформированы.

Уровень 1: Подключённый исполнитель задач (The Connected Problem-Solver)

На этом уровне механизм рассуждений становится полноценным агентом, подключаясь к внешним инструментам — компоненту «Руки» из нашей архитектуры. Теперь его способность решать задачи не ограничена статичными, предварительно обученными знаниями.

Используя 5-ступенчатый цикл, агент может ответить на наш предыдущий вопрос. Получив задачу «Какой был итоговый счёт в игре Yankees вчера вечером?», на шаге «Обдумывание» он понимает, что для ответа нужны данные в реальном времени. На шаге «Действие» он вызывает инструмент, например, Google Search API, с правильной датой и поисковым запросом. Он «Наблюдает» результат поиска (например, «Yankees выиграли 5-3») и на его основе формирует окончательный ответ.

Эта фундаментальная способность взаимодействовать с миром — будь то использование поисковика для счёта в игре, финансового API для получения цены акций или базы данных через Retrieval-Augmented Generation (RAG) — является ключевой особенностью агента Уровня 1.

Уровень 2: Стратегический исполнитель задач (The Strategic Problem-Solver)

Уровень 2 знаменует собой значительное расширение возможностей: переход от выполнения простых команд к стратегическому планированию сложных, многоэтапных целей. Ключевым навыком здесь становится context engineering (инженерия контекста): способность агента активно выбирать, упаковывать и управлять самой важной информацией на каждом шаге своего плана.

Точность агента зависит от качества и релевантности контекста.  Context engineering помогает модели не перегружаться информацией и работать эффективно.

Например, рассмотрим задачу: «Найди хорошую кофейню на полпути между моим офисом по адресу 1600 Amphitheatre Parkway, Mountain View, и офисом моего клиента по адресу 1 Market St, San Francisco».

Агент Уровня 2 начнёт создавать план:

1. Думать: «Сначала я должен найти середину пути».

   • Действовать: Вызвать инструмент Maps с обоими адресами.

   • Наблюдать: «Середина пути — это Millbrae, CA».

2. Думать: «Теперь я должен найти кофейни в Millbrae. Пользователь попросил „хорошие“, поэтому я буду искать заведения с рейтингом 4 звезды или выше».

   • Действовать: Вызвать инструмент google_places с запросом query="coffee shop in Millbrae, CA", min_rating=4.0. (Это и есть context engineering — он автоматически создал новый, сфокусированный поисковый запрос из вывода предыдущего шага).

   • Наблюдать: «Поиск вернул „Millbrae Coffee“ и „The Daily Grind“».

3. Думать: «Я объединю эти результаты и представлю их пользователю».

Такое стратегическое планирование также позволяет оказывать проактивную помощь — например, агент может прочитать длинное письмо с подтверждением авиабилета, выделить ключевую информацию (номер рейса, дата) и добавить это событие в ваш календарь.

Уровень 3: Совместная мультиагентная система (The Collaborative Multi-Agent System)

На этом, самом высоком уровне, парадигма полностью меняется. Мы отходим от создания одного всемогущего «суперагента» в сторону «команды специалистов», работающих согласованно — модели, которая напрямую отражает человеческую организацию. Коллективная сила системы заключается в разделении труда.

Здесь агенты рассматривают других агентов, как инструменты. Представьте агента-«менеджера проектов», получающего задачу: «Запустить в продажу наши новые наушники „Solaris“».

Агент-«менеджер проектов» не выполняет всю работу сам. Он действует, создавая новые задачи для своей команды специализированных агентов, почти как в реальной жизни:

1. Делегирует MarketResearchAgent: «Проанализируй цены конкурентов на наушники с шумоподавлением. Предоставь сводный документ к завтрашнему дню».

2. Делегирует MarketingAgent: «Подготовь три версии пресс-релиза, используя спецификацию продукта „Solaris“ в качестве контекста».

3. Делегирует WebDevAgent: «Сгенерируй HTML для новой страницы продукта на основе приложенных дизайн-макетов».

Эта совместная модель, хотя в настоящее время и ограничена возможностями рассуждения современных LM, представляет собой передний край автоматизации целых бизнес-процессов от начала до конца.

Уровень 4: Саморазвивающаяся система (The Self-Evolving System)

Уровень 4 представляет собой огромный скачок от делегирования к автономному созданию и адаптации. На этом уровне агентная система может выявлять пробелы в собственных возможностях и динамически создавать новые инструменты или даже новых агентов для их заполнения. Она переходит от использования фиксированного набора ресурсов к их активному расширению.

Продолжая наш пример, агент-«менеджер проектов», которому поручен запуск «Solaris», может осознать, что ему необходимо отслеживать настроения в социальных сетях, но такого инструмента или агента в его команде нет.

1. Думать (Мета-рассуждение): «Я должен отслеживать ажиотаж вокруг „Solaris“ в социальных сетях, но у меня нет такой возможности».

2. Действовать (Автономное создание): Вместо того чтобы потерпеть неудачу, он вызывает высокоуровневый инструмент AgentCreator с новой задачей: «Создай нового агента, который отслеживает социальные сети по ключевым словам „Solaris headphones“, выполняет анализ тональности и предоставляет ежедневный отчёт».

3. Наблюдать: Новый, специализированный SentimentAnalysisAgent создаётся, тестируется и добавляется в команду «на лету», готовый внести свой вклад в первоначальную миссию.

Этот уровень автономии, когда система может динамически расширять свои собственные возможности, превращает команду агентов в по-настоящему обучающуюся и развивающуюся организацию.

*На данный момент мы находимся на 2 уровне и пытаемся перейти на 3.

---

Основная архитектура агента: Модель, Инструменты и Оркестрация

Модель: «Мозг» вашего AI-агента

Языковая модель (LM) — это мыслительный центр вашего агента. Её выбор — ключевое архитектурное решение, которое определяет интеллектуальные способности, стоимость и скорость работы агента.

Распространённая ошибка — просто выбрать модель с лучшими результатами в стандартных тестах (бенчмарках). В реальных рабочих условиях успех агента редко зависит от этих общих показателей. Для успеха нужна модель, которая превосходно справляется с основами агентного подхода: способностью логически мыслить для решения сложных, многоэтапных задач и надёжно использовать инструменты для взаимодействия с миром⁷.

Чтобы сделать правильный выбор, начните с определения бизнес-задачи, а затем тестируйте модели по метрикам, которые напрямую измеряют её решение. Если ваш агент должен писать код, проверяйте его на вашем собственном коде. Если он обрабатывает страховые претензии — оцените, как он извлекает информацию из ваших форматов документов. Результаты этого анализа нужно сопоставить с практическими факторами: стоимостью и скоростью ответа (задержкой, latency). «Лучшая» модель — это та, которая предлагает идеальный баланс качества, скорости и цены именно для вашей задачи⁸.

Вы можете использовать не одну модель, а целую «команду специалистов». Как говорится, не стоит забивать гвозди микроскопом. Надёжная архитектура агента может использовать передовую модель, вроде Gemini 2.5 Pro, для самой сложной аналитической работы — например, для первоначального планирования. А более простые и массовые задачи, такие как классификация намерений пользователя или суммирование текста, разумно перенаправлять на гораздо более быструю и дешёвую модель, например Gemini 2.5 Flash. Такая маршрутизация моделей — ключевая стратегия для оптимизации и производительности, и затрат⁹.

Тот же принцип применим и к обработке разных типов данных. Модель, изначально созданная для работы с разными форматами (как multimodal model Gemini)¹⁰, предлагает простой способ обработки изображений и аудио. Альтернативный подход — использовать специализированные инструменты, такие как Cloud Vision API¹¹ или Speech-to-Text API¹². В этом случае данные из реального мира сначала преобразуются в текст, который затем передаётся для анализа языковой модели. Это добавляет гибкости и позволяет использовать лучшие в своём классе компоненты, но в то же время значительно усложняет систему.

Наконец, сфера AI находится в состоянии постоянного и стремительного развития. Модель, которую вы выберете сегодня, устареет уже через полгода. Подход «настроил и забыл» здесь не работает. Чтобы соответствовать этой реальности, нужно инвестировать в гибкую операционную среду — практику Agent Ops. Наличие надёжного CI/CD pipeline, который постоянно оценивает новые модели по вашим ключевым бизнес-метрикам, позволит снизить риски и ускорить обновления. Так вы гарантируете, что ваш агент всегда будет работать на лучшем из доступных «мозгов» без необходимости полной перестройки всей архитектуры.

---

Инструменты: «Руки» вашего AI-агента

Если модель — это мозг агента, то инструменты — это его руки, связывающие логику с реальностью. Они позволяют агенту выйти за рамки своих статичных знаний, чтобы получать информацию в реальном времени и действовать в мире. Надёжная работа с инструментами строится на трёхэтапном цикле: определить возможности инструмента, вызвать его и проанализировать результат.

Получение информации: опора на реальность

Самый базовый инструмент — это способность получать актуальную информацию. Технология Retrieval-Augmented Generation (RAG) даёт агенту своего рода «читательский билет» для доступа к внешним знаниям, которые могут храниться в векторных базах данных (Vector Databases), графах знаний (Knowledge Graphs), внутренних документах компании или в интернете через Google Search. Для работы со структурированными данными инструменты Natural Language to SQL (NL2SQL) позволяют агенту делать запросы к базам данных для ответа на аналитические вопросы, например: «Какие продукты у нас продавались лучше всего в прошлом квартале?». Проверяя факты перед ответом — будь то в документе или базе данных — агент опирается на реальные данные, что резко снижает вероятность «галлюцинаций».

Выполнение действий: меняя мир

Настоящая сила агентов раскрывается, когда они переходят от простого чтения информации к активным действиям. Обернув существующие API и функции кода в инструменты, агент может отправить email, запланировать встречу или обновить запись о клиенте в ServiceNow. Для более сложных задач агент может писать и выполнять код «на лету». В безопасной изолированной среде (sandbox) он может сгенерировать SQL-запрос или Python-скрипт для решения комплексной проблемы или выполнения расчетов, превращаясь из просто осведомлённого помощника в автономного исполнителя¹⁴.

Это также включает инструменты для взаимодействия с человеком. Агент может использовать инструмент с участием человека (Human in the Loop, HITL), чтобы приостановить процесс и запросить подтверждение (например, ask_for_confirmation()) или уточнить информацию через пользовательский интерфейс (например, ask_for_date_input()), обеспечивая участие человека в принятии критических решений. HITL может быть реализован через SMS и запись задачи в базе данных.

---

Слой оркестрации

Если модель — это мозг агента, а инструменты — его руки, то слой оркестрации — это центральная нервная система, которая их связывает. Это движок, который управляет циклом «Думай, Действуй, Наблюдай», и место, где воплощается в жизнь вся логика, заложенная разработчиком. Этот слой — не просто «связующее звено»; это дирижёр всего агентного оркестра, который решает, когда модели следует думать, какой инструмент применить, и как результат действия должен повлиять на следующий шаг.

Ключевые проектные решения

Первое архитектурное решение — определить степень автономности агента. Это целый спектр вариантов. На одном его конце — полностью предсказуемые процессы, где языковая модель вызывается как инструмент для конкретной задачи, то есть лишь «вкрапления» AI для улучшения существующего процесса. На другом конце — языковая модель «за рулём», которая динамически адаптируется, планирует и выполняет задачи для достижения цели.

Параллельный выбор — это метод реализации. No-code конструкторы предлагают скорость и доступность, позволяя пользователям быстро автоматизировать задачи. Для более сложных и критически важных систем code-first фреймворки, такие как Agent Development Kit (ADK) от Google, обеспечивают глубокий контроль, гибкость и возможности интеграции, необходимые инженерам.

Независимо от подхода, необходим фреймворк промышленного уровня (production-grade). Он должен быть открытым, чтобы вы могли подключить любую модель или инструмент, избегая зависимости от одного поставщика (vendor lock-in). Он должен обеспечивать точный контроль, позволяя сочетать непредсказуемые рассуждения модели с жёстко закодированными бизнес-правилами. И самое главное, фреймворк должен быть спроектирован с учётом наблюдаемости (observability). Когда агент ведёт себя неожиданно, вы не можете просто поставить точку останова (breakpoint) на «мысли» модели. Надёжный фреймворк генерирует подробные отчёты (traces) и логи, раскрывая всю траекторию его рассуждений: внутренний монолог модели, выбранный инструмент, переданные параметры и полученный результат.

Инструкции: экспертные знания и «персона»

В рамках этого фреймворка самый мощный рычаг в руках разработчика — это задать агенту экспертные знания и определённую «персону» (роль). Это делается с помощью системного промпта или набора базовых инструкций. Это не просто команда, а своего рода «конституция» агента.

Именно здесь вы указываете: Ты — полезный агент поддержки клиентов компании Acme Corp..., а также задаёте ограничения, желаемый формат ответа, правила поведения, тон общения и чёткие указания, когда и какие инструменты использовать. Несколько наглядных примеров в инструкциях обычно работают очень эффективно.

Расширение с помощью контекста

Краткосрочная память — это активный «черновик» агента, где хранится история текущего диалога. Она отслеживает последовательность пар «Действие — Результат», предоставляя модели контекст, необходимый для принятия следующего решения.

Долгосрочная память обеспечивает постоянство данных между сессиями. Архитектурно она почти всегда реализуется как ещё один специализированный инструмент — система RAG, подключённая к векторной базе данных или поисковой системе. Оркестратор даёт агенту возможность заранее подгружать и активно запрашивать собственную историю, позволяя ему «помнить» предпочтения пользователя или результат похожей задачи, выполненной несколько недель назад, для по-настоящему персонализированного опыта¹⁹.

Мультиагентные системы и паттерны проектирования

По мере усложнения задач создание одного всемогущего «суперагента» становится неэффективным. Более удачное решение — подход «команды специалистов», который отражает структуру человеческой организации. В этом и заключается суть мультиагентной системы: сложный процесс разбивается на отдельные подзадачи, и каждая поручается выделенному, специализированному AI-агенту. Такое разделение труда позволяет каждому агенту быть проще, сфокусированнее, а также его легче создавать, тестировать и поддерживать.

 IT-архитектор или руководитель продукта могут опираться на проверенные паттерны проектирования, хотя возможности агентов, а значит и паттерны, быстро развиваются. Для динамичных или нелинейных задач незаменим паттерн «Координатор». Он вводит агента-«менеджера», который анализирует сложный запрос, разбивает его на части и разумно направляет каждую подзадачу нужному специалисту (например, исследователю, копирайтеру или программисту). Затем координатор собирает ответы от всех специалистов и формирует итоговый, комплексный ответ.

Для более линейных рабочих процессов лучше подходит Последовательный паттерн (Sequential), который работает как цифровой конвейер: результат работы одного агента становится входными данными для следующего. Другие ключевые паттерны сосредоточены на качестве и безопасности. Паттерн Итеративного Улучшения (Iterative Refinement) создает цикл обратной связи, в котором агент-«генератор» создает контент, а агент-«критик» оценивает его на соответствие стандартам качества. Для критически важных задач ключевую роль играет паттерн с участием человека (Human-in-the-Loop, HITL). Он создает намеренную паузу в процессе, чтобы получить одобрение от человека, прежде чем агент выполнит важное действие.

Развертывание агентов и сопутствующие сервисы

После создания локального агента вы захотите развернуть его на сервере, чтобы он работал постоянно и был доступен для других людей и агентов. Продолжая нашу аналогию, развертывание и сервисы — это «тело и ноги» нашего агента. Для эффективной работы ему необходим ряд сервисов, таких как история сессий, сохранение памяти (persistence) и другие. Как разработчик агентов, вы также будете отвечать за логирование, а также за меры безопасности для обеспечения конфиденциальности, локализации данных (data residency) и соответствия нормативным требованиям. Все эти аспекты необходимо учитывать при развертывании агентов в рабочей среде (продакшене).

К счастью, разработчики агентов могут опереться на инфраструктуру для хостинга приложений, которая развивалась десятилетиями. В конце концов, агенты — это новая форма ПО, и к ним применимы многие из тех же принципов. Разработчики могут использовать специализированные платформы для развертывания агентов, такие как Vertex AI Agent Engine, которые предоставляют среду выполнения (runtime) и все необходимое в рамках единой платформы. Разработчики, которым нужен больший контроль над своим стеком приложений или которые хотят развернуть агентов в рамках своей существующей DevOps-инфраструктуры, могут упаковать любого агента и большинство сопутствующих сервисов в docker-контейнер и развернуть его в стандартных для отрасли средах выполнения, таких как Cloud Run или GKE

Если вы не являетесь разработчиком ПО и DevOps-экспертом, процесс развертывания вашего первого агента может показаться сложным. Многие фреймворки для агентов упрощают эту задачу с помощью одной команды deploy или специальной платформы. Их стоит использовать на начальных этапах для изучения и освоения технологии. Однако создание безопасной и готовой к эксплуатации (production-ready) среды обычно требует больших временных затрат и применения лучших практик, включая CI/CD и автоматизированное тестирование для ваших агентов²³.

---

Agent Ops: Структурированный подход к непредсказуемому

Создавая своих первых агентов, вы будете снова и снова тестировать их поведение вручную. Добавили новую функцию — работает ли она? Исправили ошибку — не сломали ли что-то другое? Тестирование — это нормальная часть разработки, но с генеративным AI всё интереснее.

Переход от традиционного, детерминированного ПО(например традиционное по детерминированное, его можно затестить, просто сравнив полученный результат с единственно правильным ожидаемым результатом) к стохастическим (ии агент стохастический,его нельзя затестить, сравнив ответ с одним единственным верным, тут нужно оценивать качество ответа: соответствует ли он задаче, логичен ли он, выдержан ли тон и тд) агентным системам требует нового подхода к эксплуатации. Обычные юнит-тесты могли просто проверять условие результат == ожидаемое_значение, но это не работает, когда ответ агента по своей сути вероятностен. Кроме того, из-за сложности языка для оценки «качества» ответа часто требуется другая языковая модель — чтобы проверить, что агент сделал всё, что требовалось, не сделал ничего лишнего и выдержал правильный тон.

Agent Ops — это структурированный подход для работы в этих новых условиях. Это закономерное развитие DevOps и MLOps, адаптированное под специфические задачи создания, развёртывания и управления AI-агентами.

Этот подход превращает непредсказуемость из недостатка в управляемую, измеримую и надёжную особенность системы.

Измеряйте главное: подход к оценке успеха по принципу A/B-теста

Прежде чем улучшать агента, нужно определить, что для вашего бизнеса значит «лучше». Постройте свою стратегию наблюдаемости (observability) по принципу A/B-теста и задайте себе вопрос: какие ключевые показатели эффективности (KPI) доказывают, что агент приносит пользу? Эти метрики должны выходить за рамки технической корректности и измерять реальное влияние на бизнес: процент выполнения задач, оценки удовлетворенности пользователей, задержка (latency) при выполнении задач, операционные затраты на взаимодействие и, что самое важное, влияние на бизнес-цели, такие как доход, конверсия или удержание клиентов. Такой подход «сверху вниз» будет направлять всё ваше тестирование, поставит вас на путь разработки на основе метрик (metrics-driven development) и позволит рассчитать окупаемость инвестиций (ROI).

Качество вместо «прошёл/не прошёл»: используем LM в роли судьи

Бизнес-метрики не показывают, корректно ли ведёт себя агент. Поскольку простая оценка «прошёл/не прошёл» невозможна, мы переходим к оценке качества, используя другую языковую модель в роли «судьи» (LM as Judge). Этот метод заключается в использовании мощной модели для проверки ответа агента по заранее определённым критериям: Дал ли он правильный ответ? Был ли ответ основан на фактах? Следовал ли он инструкциям? Эта автоматизированная оценка, запускаемая на «золотом» наборе данных (golden dataset), обеспечивает последовательное измерение качества.

Создание таких наборов для оценки, включающих идеальные («золотые») вопросы и правильные ответы, может быть утомительным процессом. Для их формирования следует отбирать сценарии из реальных взаимодействий с агентом. Набор данных должен охватывать весь спектр ожидаемых сценариев использования, а также несколько непредвиденных. Хотя вложения в систему оценки быстро окупаются, её результаты всегда должны проверяться экспертом в предметной области, прежде чем будут признаны действительными. Всё чаще подготовка и поддержка этих оценок становятся ключевой обязанностью руководителей продуктов (Product Managers) при поддержке доменных экспертов.

Разработка на основе метрик: ваш критерий для развёртывания

Как только вы автоматизируете десятки сценариев оценки и получите надёжные показатели качества, вы сможете уверенно тестировать изменения в вашем агенте. Процесс прост: запустите новую версию на всём наборе данных для оценки и напрямую сравните её показатели с текущей рабочей версией. Эта система устраняет неопределённость и придаёт уверенности при каждом развёртывании. Хотя автоматизированные оценки критически важны, не забывайте и о других факторах, таких как задержка (latency), стоимость и процент успешного выполнения задач. Для максимальной безопасности используйте A/B-развёртывания, чтобы постепенно выкатывать новые версии и сравнивать реальные рабочие метрики с результатами ваших симуляций.

Отладка с помощью трейсов OpenTelemetry: в поисках ответа на вопрос «почему?»

Когда ваши метрики падают или пользователь сообщает об ошибке, вам нужно понять «почему». Трейс OpenTelemetry — это детальная, пошаговая запись всего пути выполнения агента (траектории), позволяющая отлаживать его действия²⁵. С помощью трейсов вы можете увидеть точный промпт, отправленный модели, её внутренние рассуждения (если доступны), конкретный инструмент, который она вызвала, точные параметры, которые она для него сгенерировала, и сырые данные, полученные в результате. Трейсы могут показаться сложными на первый взгляд, но они предоставляют все детали, необходимые для диагностики и устранения первопричины любой проблемы. Важные данные из трейсов можно превратить в метрики, но их анализ в первую очередь предназначен для отладки, а не для общего обзора производительности.

Цените обратную связь от людей: она направляет вашу автоматизацию

Обратная связь от человека — это не досадная помеха, а самый ценный источник данных для улучшения вашего агента. Когда пользователь сообщает об ошибке или нажимает «палец вниз», он делает вам подарок: новый, реальный пограничный случай (edge case), который ваши автоматические тесты упустили. Сбор и анализ этих данных критически важен. Эффективный процесс Agent Ops «замыкает цикл обратной связи»: он фиксирует этот отзыв, воспроизводит проблему и превращает этот сценарий в новый постоянный тест в вашем наборе для оценки. Это гарантирует, что вы не только исправите ошибку, но и «привьёте» систему от повторения целого класса подобных сбоев.

Взаимодействие агентов (Agent Interoperability)

Создав качественных агентов, вы захотите, чтобы они могли взаимодействовать с пользователями и другими агентами. В нашей аналогии с частями тела это было бы «лицо» агента. Важно понимать, что агенты — это не инструменты²⁶. Есть разница между подключением к агентам и подключением агентов к данным и API. Давайте предположим, что инструменты у вас уже есть, и рассмотрим, как интегрировать ваших агентов в более широкую экосистему.

Агенты и люди

Самая распространённая форма взаимодействия — через пользовательский интерфейс. В простейшем случае это чат-бот. Более продвинутые агенты могут предоставлять структурированные данные, например, в формате JSON, для создания насыщенных, динамичных интерфейсов.

Взаимодействие с участием человека (HITL) может включать уточнение намерений, подтверждение действий или запросы на дополнительную информацию. Продвинутые агенты также могут управлять интерфейсом от имени пользователя: переходить на страницы, нажимать кнопки или заполнять формы²⁷.

Современные агенты выходят за рамки текста, переходя к мультимодальному общению в реальном времени (live mode). Технологии вроде Gemini Live API³¹ позволяют пользователю говорить с агентом и прерывать его, как в обычном разговоре. Это открывает массу новых возможностей: от помощи технику в ремонте оборудования до советов по стилю в реальном времени.

Агенты и агенты

Агенты должны взаимодействовать не только с людьми, но и друг с другом. По мере масштабирования AI в компании разные команды будут создавать специализированных агентов. Без общего стандарта их соединение превратилось бы в запутанную паутину хрупких, кастомных API-интеграций.

Протокол Agent2Agent (A2A) — это открытый стандарт, созданный для решения этой проблемы. Он действует как универсальное «рукопожатие». A2A позволяет любому агенту опубликовать свою цифровую «визитную карточку» (Agent Card) — простой JSON-файл с описанием своих возможностей и данных для подключения. После обнаружения агенты общаются с помощью асинхронных «задач», что позволяет решать сложные проблемы в рамках длительных соединений. A2A превращает набор изолированных агентов в единую, совместимую экосистему.

Агенты и деньги

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

Протокол Agent Payments Protocol (AP2) вводит криптографически подписанные цифровые «мандаты», которые служат неопровержимым доказательством намерений пользователя. Его дополняет протокол x402, который использует стандартный код HTTP 402 "Payment Required" для бесшовных межмашинных микроплатежей. Вместе они закладывают основу доверия для коммерческих взаимодействий в агентном вебе.

Безопасность одного агента: компромисс между пользой и риском

Создавая AI-агента, вы сталкиваетесь с компромиссом: чтобы агент был полезен, ему нужно дать полномочия (отправлять письма, работать с базами данных), но каждое полномочие несёт в себе риск. Основные угрозы — это несанкционированные действия и раскрытие конфиденциальных данных. Нужно дать агенту поводок, достаточно длинный для работы, но достаточно короткий, чтобы он не наделал бед³².

Для управления этим риском нельзя полагаться только на суждения AI-модели, так как ею можно манипулировать (например, через prompt injection³³). Лучшая практика — это эшелонированная защита (defense-in-depth)³⁴.

1. Первый слой — традиционные, жёстко закодированные правила (guardrails), которые действуют как точка контроля безопасности вне логики модели. Например, политика, блокирующая любую покупку свыше $100.

2. Второй слой — защита на основе AI. Это включает обучение модели быть более устойчивой к атакам и использование специализированных «моделей-стражей», которые анализируют план агента до его выполнения и помечают рискованные шаги.

Идентичность агента: новый класс субъектов доступа

В традиционной модели безопасности есть пользователи-люди (OAuth, SSO) и сервисы (IAM, сервисные аккаунты). Агенты — это третья категория. Агент — не просто код, а автономный актор, новый тип субъекта доступа (principal), которому нужна собственная проверяемая идентичность, своего рода «цифровой паспорт».

Наличие у каждого агента проверяемой идентичности (например, по стандарту SPIFFE³⁵) — основа безопасности. Это позволяет выдавать ему гранулярные разрешения по принципу наименьших привилегий: SalesAgent может работать с CRM, а HROnboardingAgent — нет. Такой контроль критически важен для ограничения потенциального ущерба, если один из агентов будет скомпрометирован.

Политика для ограничения доступа

Ограничение доступа с помощью правил

В безопасности важно различать два понятия:

• Аутентификация (AuthN): Проверка личности. Отвечает на вопрос: «Кто вы?»

• Авторизация (AuthZ): Проверка прав. Отвечает на вопрос: «Что вам разрешено делать?»

Именно за авторизацию и отвечают правила доступа. Как правило, эти правила ограничивают возможности пользователя или системы. Например: «Сотрудники из отдела маркетинга могут обращаться только к этим 27 адресам API и не могут выполнять команды на удаление (DELETE)».

При разработке агентов нам необходимо применять такие же правила разрешений к самим агентам, их инструментам, а также к данным, которыми они могут обмениваться. Подумайте об этом так: если вы даёте системе доступ ко всем возможным ресурсам, вы должны чётко ограничить каждого агента лишь тем набором возможностей, который необходим ему для выполнения своей работы. Это и есть принцип наименьших привилегий — давать минимум прав, достаточный для решения задачи.

Защита агента, созданного с помощью ADK

Когда базовые принципы идентичности и правила доступа определены, защита агента, созданного с помощью Agent Development Kit (ADK), становится практической задачей по применению этих концепций через код и конфигурацию³⁷.

Как было описано выше, процесс требует чёткого разделения идентичностей: учётная запись пользователя (например, через OAuth), сервисный аккаунт (для запуска кода) и идентичность агента (для использования делегированных полномочий).

После того как аутентификация настроена, следующий уровень защиты — это создание правил доступа к сервисам. Часто это делается на уровне управления API (API governance), наряду с управлением, поддерживающим сервисы MCP и A2A.

Следующий уровень — встраивание защитных механизмов (guardrails) непосредственно в ваши инструменты, модели и подагенты для принудительного выполнения правил. Это гарантирует, что, какие бы выводы ни сделала языковая модель и что бы ни предлагал вредоносный промпт, собственная логика инструмента откажется выполнять небезопасное или нарушающее правила действие. Такой подход обеспечивает предсказуемую и проверяемую основу безопасности, превращая абстрактные правила доступа в конкретный, надёжный код³⁸.

Для более динамической защиты, которая может адаптироваться к поведению агента во время выполнения, ADK предоставляет коллбэки (Callbacks) и плагины (Plugins). Коллбэк before_tool_callback позволяет проверить параметры вызова инструмента до его запуска, сверяя их с текущим состоянием агента. Для создания более универсальных правил можно использовать плагины. Распространённый паттерн — «Gemini в роли судьи»³⁹, который использует быструю и недорогую модель (например, Gemini Flash-Lite или вашу собственную дообученную модель Gemma) для проверки в реальном времени пользовательского ввода и ответов агента на предмет prompt injection или вредоносного контента.

Для организаций, которым требуется полностью управляемое решение корпоративного уровня для таких динамических проверок, в качестве опционального сервиса можно интегрировать Model Armor. Model Armor действует как специализированный слой безопасности, который проверяет промпты и ответы на широкий спект-р угроз, включая prompt injection, попытки обхода ограничений (jailbreak), утечку конфиденциальных данных (PII) и вредоносные URL⁴⁰. Передавая эти сложные задачи безопасности выделенному сервису, разработчики могут обеспечить постоянную и надёжную защиту, не создавая и не поддерживая эти механизмы самостоятельно.

Именно такой гибридный подход в ADK — сочетание сильной идентичности, детерминированной логики в инструментах, динамических защитных механизмов на базе AI и опциональных управляемых сервисов вроде Model Armor — позволяет создать агента, который будет одновременно мощным и надёжным.

https://saif.google/focus-on-agents подробнее тут

Масштабирование: от одного агента до корпоративного парка агентов

Успешное внедрение одного AI-агента в рабочую среду — это большое достижение. Масштабирование до сотен — это уже архитектурная задача. Если вы создаёте одного-двух агентов, ваши основные заботы связаны с безопасностью. Если же вы строите множество агентов, вам придётся проектировать системы, способные справиться с гораздо большими вызовами. Подобно API sprawl (хаотичному разрастанию API), когда агенты и инструменты бесконтрольно распространяются по организации, возникают новые сложности.

Безопасность и конфиденциальность: укрепление рубежей

Платформа корпоративного уровня должна решать уникальные проблемы безопасности и конфиденциальности, присущие генеративному AI, даже если на ней работает всего один агент. Сам агент становится новым вектором атаки. Злоумышленники могут использовать prompt injection для перехвата инструкций агента или data poisoning (отравление данных) для искажения информации, которую он использует для обучения или в RAG. Кроме того, агент без должных ограничений может случайно допустить утечку конфиденциальных данных клиентов или служебной информации.

Надёжная платформа обеспечивает эшелонированную защиту (defense-in-depth) для снижения этих рисков. Она начинается с данных, гарантируя, что частная информация компании никогда не используется для обучения базовых моделей и защищена такими средствами, как VPC Service Controls. Платформа требует фильтрации ввода и вывода, которая работает как файрвол для промптов и ответов. Наконец, она должна предлагать контрактную защиту, например, гарантию возмещения убытков в связи с нарушением прав интеллектуальной собственности, что даёт компаниям юридическую и техническую уверенность для развёртывания агентов.

Управление агентами: плоскость управления вместо хаоса

Когда агенты и их инструменты распространяются по организации, они создают сложную сеть взаимодействий и потенциальных уязвимостей — проблему, которую часто называют «хаотичным разрастанием агентов» (agent sprawl). Для управления этим необходимо перейти от защиты отдельных агентов к реализации централизованного архитектурного подхода: единого шлюза, который служит плоскостью управления (control plane) для всей активности агентов.

Представьте оживлённый мегаполис с тысячами автономных машин — пользователей, агентов, инструментов. Без светофоров, номерных знаков и центральной системы управления царил бы хаос. Подход со шлюзом и создаёт такую систему, устанавливая обязательную точку входа для всего агентного трафика. Через него проходят и запросы пользователей, и вызовы инструментов (MCP), и взаимодействие между агентами (A2A), и прямые запросы к языковым моделям. Находясь на этом критическом перекрёстке, организация может проверять, маршрутизировать, отслеживать и управлять каждым взаимодействием.

Эта плоскость управления выполняет две взаимосвязанные функции:

1. Применение правил во время выполнения: Шлюз действует как архитектурная точка контроля для обеспечения безопасности. Он отвечает за аутентификацию («Кто этот актор?») и авторизацию («Есть ли у него права на это действие?»). Централизация обеспечивает «единое окно» (single pane of glass) для наблюдаемости, создавая общие логи, метрики и трейсы для всех операций. Это превращает «спагетти» из разрозненных агентов в прозрачную и аудируемую систему.

2. Централизованное управление: Для эффективного применения правил шлюзу нужен источник истины. Им служит центральный реестр — своего рода корпоративный «магазин приложений» для агентов и инструментов. Этот реестр позволяет разработчикам находить и повторно использовать существующие компоненты, а администраторам — видеть полный их перечень. Что ещё важнее, он обеспечивает формальный жизненный цикл для агентов и инструментов, включая проверку безопасности перед публикацией, версионирование и создание детальных правил доступа.

Сочетая шлюз с центральным реестром, организация превращает риск хаотичного разрастания в управляемую, безопасную и эффективную экосистему.

Стоимость и надёжность: инфраструктурная основа

В конечном итоге, агенты корпоративного уровня должны быть надёжными и экономически эффективными. Агент, который часто сбоит или медленно работает, имеет отрицательный ROI. И наоборот, непомерно дорогой агент не сможет масштабироваться. Базовая инфраструктура должна быть спроектирована так, чтобы управлять этим компромиссом, обеспечивая безопасность и соблюдение нормативных требований.

В некоторых случаях вам нужна функция scale-to-zero (масштабирование до нуля) для агентов с нерегулярным трафиком. Для критически важных, чувствительных к задержкам (latency) нагрузок платформа должна предлагать выделенные, гарантированные мощности, такие как Provisioned Throughput⁴¹ для сервисов LM или SLA на уровне 99.9% для сред выполнения вроде Cloud Run⁴². Это обеспечивает предсказуемую производительность и гарантирует, что ваши самые важные агенты всегда будут отзывчивы.

Как агенты развиваются и обучаются

Агенты работают в динамичных средах, где правила, технологии и форматы данных постоянно меняются. Без способности к адаптации производительность агента со временем будет снижаться — этот процесс часто называют «старением». Ручное обновление большого парка агентов — медленно и неэкономично. Более масштабируемое решение — проектировать агентов, которые могут учиться и развиваться автономно, улучшая своё качество в процессе работы с минимальными инженерными усилиями⁴³.

Как агенты учатся и самосовершенствуются

Подобно людям, агенты учатся на опыте и внешних сигналах. Этот процесс подпитывается из нескольких источников:

• Опыт во время работы: Агенты учатся на логах сессий, трейсах и данных из памяти, которые фиксируют успехи, неудачи и траектории принятия решений. Сюда же относится обратная связь от человека (HITL), которая даёт авторитетные исправления.

• Внешние сигналы: Обучение также стимулируется новыми документами, такими как обновлённые корпоративные правила, нормативные акты или критика со стороны других агентов.

Эта информация используется для оптимизации будущего поведения. Наиболее успешные методы адаптации делятся на две категории:

• Улучшенная инженерия контекста (Context Engineering): Система постоянно совершенствует свои промпты, few-shot примеры и информацию, извлекаемую из памяти.

• Оптимизация и создание инструментов: Агент может выявлять пробелы в своих возможностях и действовать, чтобы их заполнить: получить доступ к новому инструменту, создать новый «на лету» (например, Python-скрипт) или изменить существующий.

Активными областями исследований являются и другие методы, такие как динамическая реконфигурация мультиагентных систем или Reinforcement Learning from Human Feedback (RLHF).

Пример: изучение новых нормативных требований

Рассмотрим агента, работающего в строго регулируемой отрасли, например, в финансах. Его задача — генерировать отчёты, соответствующие нормативным требованиям (например, GDPR).

Это можно реализовать с помощью мультиагентного процесса:

1. Агент-запросчик извлекает сырые данные.

2. Агент-отчётчик создаёт на их основе черновик отчёта.

3. Агент-критик, вооружённый знаниями о нормативных требованиях, проверяет отчёт. В случае сомнений он эскалирует задачу на человека-эксперта.

4. Агент-ученик наблюдает за всем процессом и обобщает обратную связь от эксперта в новое, переиспользуемое правило для будущих задач.

Например, если эксперт-человек отмечает, что определённая статистика по домохозяйствам должна быть анонимизирована, Агент-ученик фиксирует это исправление. В следующий раз при генерации аналогичного отчёта Агент-критик автоматически применит это новое правило, сокращая потребность в участии человека. Этот цикл критики, обратной связи от человека и обобщения позволяет системе автономно адаптироваться к изменяющимся нормативным требованиям.

Симуляция и Agent Gym — новый рубеж

Паттерн проектирования, который мы представили, можно отнести к категории in-line learning (обучение в процессе работы), где агенты обучаются, используя только те ресурсы и паттерны, с которыми они были изначально спроектированы. Сейчас исследуются более продвинутые подходы, предполагающие наличие специализированной платформы, созданной для оптимизации мультиагентной системы в оффлайн-режиме с помощью продвинутых инструментов и возможностей, которые не являются частью рабочей среды выполнения агентов.

Ключевые особенности такой платформы Agent Gym(тренировочной среды для агентов):

1. Она не является частью рабочего процесса. Это автономная, отдельная от продакшена платформа, которая может использовать любые модели, оффлайн-инструменты, облачные приложения и многое другое.

2. Она предлагает среду для симуляции, где агент может «тренироваться» на новых данных и учиться. Эта среда отлично подходит для метода проб и ошибок со множеством путей для оптимизации.

3. Она может вызывать продвинутые генераторы синтетических данных, которые делают симуляцию максимально реалистичной и позволяют проводить стресс-тестирование агента (это может включать такие техники, как red-teaming, динамическую оценку и использование целого семейства агентов-критиков).

4. Арсенал инструментов для оптимизации не является фиксированным, и платформа может добавлять новые инструменты (либо через открытые протоколы, такие как MCP или A2A), либо — в более продвинутом варианте — изучать новые концепции и создавать под них собственные инструменты.

5. Наконец, даже такие системы, как Agent Gym, могут быть не в состоянии справиться с определёнными нестандартными сценариями (edge cases) из-за хорошо известной проблемы «неформальных знаний» (tribal knowledge) — опыта и практик, которые существуют в компании, но нигде не задокументированы. В таких случаях Agent Gym может связываться с сообществом экспертов в предметной области и консультироваться с ними, чтобы определить правильные результаты, которые станут основой для следующего этапа оптимизации.

Примеры продвинутых агентов

Google Co-Scientist

Co-Scientist — это продвинутый AI-агент, разработанный для работы в качестве виртуального научного сотрудника. Он ускоряет научные открытия, систематически исследуя сложные научные области.

Исследователи могут поставить перед ним цель, обеспечить доступ к необходимым публичным и частным (proprietary) источникам знаний, после чего агент начинает генерировать и оценивать множество новых гипотез.

Для достижения этой цели Co-Scientist создаёт целую экосистему агентов, которые сотрудничают друг с другом.

Представьте эту систему в роли руководителя научного проекта. Сначала AI берёт общую исследовательскую цель и создаёт на её основе детальный план. Затем агент-«Супервизор» (Supervisor) выступает в роли менеджера: он делегирует задачи команде специализированных агентов и распределяет ресурсы, такие как вычислительные мощности (computing power).

Такая структура обеспечивает лёгкое масштабирование проекта и совершенствование методов работы команды по мере продвижения к конечной цели.

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

Агент AlphaEvolve

Другим примером продвинутой агентной системы является AlphaEvolve — AI-агент, который находит и оптимизирует алгоритмы для решения сложных задач в математике и информатике.

AlphaEvolve работает, сочетая возможности языковых моделей Gemini по генерации кода с автоматизированной системой оценки. Он использует эволюционный процесс: AI генерирует возможные решения, специальный оценщик присваивает им баллы, а самые перспективные идеи ложатся в основу следующего поколения кода.

Этот подход уже привёл к значительным прорывам, в том числе:

• Повышение эффективности дата-центров Google, проектирования чипов и обучения AI.

• Обнаружение более быстрых алгоритмов умножения матриц.

• Нахождение новых решений для открытых математических проблем.

AlphaEvolve особенно эффективен для задач, в которых проверить качество готового решения гораздо проще, чем найти это решение с нуля.

AlphaEvolve создан для тесного и итеративного сотрудничества между человеком и AI. Это сотрудничество строится на двух ключевых принципах:

• Прозрачные решения: AI генерирует решения в виде человекочитаемого кода. Эта прозрачность позволяет пользователям понимать логику, делать новые выводы, доверять результатам и напрямую изменять код под свои нужды.

• Экспертное руководство: Опыт эксперта играет ключевую роль в постановке задачи. Пользователи направляют AI, уточняя метрики оценки и задавая направление для поиска решений, что не позволяет системе использовать непреднамеренные лазейки в определении задачи. Такой цикл взаимодействия гарантирует, что итоговые решения будут одновременно мощными и практичными.

Результатом работы агента становится код, который непрерывно совершенствуется, улучшая заданные человеком метрики.

---

Первый день интенсива по AI-агентам позади, и это было интересно! Я решила делиться здесь конспектами. Сам курс открытый, и все материалы есть в свободном доступе, так что вы можете проходить его вместе со мной. Но чтобы вам не пришлось тратить время на поиски, я могу собрать все практические задания с разбором как делать за сегодня и полезные ссылки в одном месте. Дайте знать в комментариях, если такая подборка будет вам полезна, и я с радостью её подготовлю! А пока, иду на второй день интесива :)