Комплект разработки агентов Google (ADK) — это фундаментальный сдвиг в том, как разработчики создают приложения на базе искусственного интеллекта. Вместо того, чтобы рассматривать большие языковые модели как простые системы запроса-ответа, ADK представляет управляемую событиями архитектуру времени выполнения, которая объединяет агентов, инструменты и постоянное состояние в связные приложения.
В этой статье рассматриваются основные архитектурные компоненты ADK и демонстрируется их совместная работа посредством практической реализации погодного агента.
Понимание архитектуры времени выполнения ADK
Код ниже определяет сквозной рабочий процесс в Python:
Среда выполнения ADK работает как сложный цикл событий, который является посредником между запросами пользователей, вызовами моделей ИИ и выполнением внешних инструментов. На самом высоком уровне поведение системы определяют три основных взаимодействия.
Сначала пользователь отправляет сообщение вместе с идентификатором сеанса. Этот идентификатор сеанса имеет решающее значение, поскольку он позволяет среде выполнения поддерживать диалоговый контекст между несколькими обменами. Во-вторых, внутренний цикл событий обрабатывает запрос, координируя работу логики выполнения и постоянных служб. В-третьих, система передает пользователю события, включая промежуточные вызовы инструментов и окончательный ответ.
На следующей архитектурной схеме показаны взаимосвязанные компоненты, которые позволяют это сделать.
Бегун как оркестратор
Runner находится в центре архитектуры ADK, служа основной точкой входа для всех взаимодействий с пользователем. Создавая экземпляр Runner, вы привязываете его к конкретному агенту и службе сеансов, создавая автономный контекст выполнения.
runner = Runner (агент=weather_agent, имя_приложения=APP_NAME, session_service=session_service) 12345 runner = Runner (агент=weather_agent, app_name=APP_NAME, session_service=session_service)
Runner содержит обработчик событий, который преобразует необработанные выходные данные модели в структурированные события. Каждое взаимодействие с агентом ADK осуществляется через метод run Runner, который выдает поток событий, а не возвращает один ответ. Такой потоковый подход обеспечивает обратную связь в реальном времени и позволяет приложениям реагировать на промежуточные этапы, такие как вызовы инструментов.
для события в runner.run(user_id=user_id, session_id=session_id, new_message=content): if event.is_final_response(): Final_response_text = event.content.parts[0].text 123 для события в runner.run(user_id=user_id, session_id=session_id, new_message=content): if event.is_final_response(): Final_response_text = event.content.parts[0].текст
Этот шаблон существенно отличается от традиционных вызовов API. Вместо ожидания полного ответа ваше приложение получает события по мере их возникновения, что позволяет использовать индикаторы прогресса, отладочные выходные данные и динамические обновления пользовательского интерфейса.
Как работает цикл событий
Цикл событий представляет собой основную инновацию ADK. Он работает как двунаправленный канал связи между исполнителем и уровнем логики выполнения, следуя шаблону «запрос-доходность».
Когда Runner получает сообщение пользователя, он просит логику выполнения обработать его. Логика выполнения может вызывать базовый LLM, вызывать инструмент или выполнять обратный вызов. Каждая из этих операций возвращает события Runner, который затем может пересылать их пользователю или запускать дополнительную обработку.
Эта архитектура естественным образом поддерживает многошаговые рассуждения. Рассмотрим, что происходит, когда пользователь запрашивает информацию о погоде. LLM сначала определяет, что ему необходимо вызвать инструмент get_weather. Логика выполнения вызывает этот инструмент и выдает событие, содержащее результат. Затем LLM обрабатывает выходные данные инструмента и генерирует удобочитаемый ответ. Каждый шаг порождает события, которые протекают через систему.
Логика выполнения и интеграция инструментов
Уровень логики выполнения обрабатывает фактическую работу запущенных агентов. Он управляет вызовами LLM, обратными вызовами инструментов и любой пользовательской логикой, которую вы определяете. Инструменты в ADK — это просто функции Python с подсказками типов, которые платформа автоматически предоставляет базовой модели.
def get_weather(city: str) ->gt; dict: city_normalized = city.lower().replace(» «, «») макет_weather_db = { «newyork»: {«status»: «success», «report»: «Погода в Нью-Йорке солнечная, температура 25°C.»}, «london»: {«status»: «success», «report»: «В Лондоне облачно, температура 15°C.»}, } Если city_normalized в макете_weather_db: верните макет_weather_db[city_normalized]
else: return {«status»: «error», «error_message»: f»К сожалению, у меня нет информации о погоде для ‘{city}’.»} 12345678910 def get_weather(city: str) -> dict: city_normalized = city.lower().replace(» «, «») макет_weather_db = { «newyork»: {«status»: «success», «report»: «Погода в Нью-Йорке солнечная, температура 25°C.»}, «london»: {«status»: «success», «report»: «В Лондоне облачно, температура 15°C.»}, } Если city_normalized в макете_weather_db: верните макет_weather_db[city_normalized] else: return {«status»: «error», «error_message»: f»К сожалению, у меня нет информации о погоде для ‘{city}’.»}
Конфигурация агента привязывает инструменты к конкретным моделям и предоставляет инструкции, определяющие поведение. Поле инструкций действует как системная подсказка, а параметр инструментов регистрирует доступные функции.
Weather_agent = Agent( name=»weather_agent_v1″, model=AGENT_MODEL,description=»Предоставляет информацию о погоде для определенных городов.», Instruction=»Вы полезный помощник по погоде. Когда пользователь спрашивает погоду…», Tools=[get_weather]) 1234567 Weather_agent = Agent( name=»weather_agent_v1″, model=AGENT_MODEL,description=»Предоставляет информацию о погоде для определенных городов.», Instruction=»Вы полезный помощник по погоде. Когда пользователь спрашивает погоду…», Tools=[get_weather],)
Когда LLM решает вызвать get_weather, ADK обрабатывает весь жизненный цикл вызова. Он анализирует вызов функции модели, выполняет вашу функцию Python и передает результат обратно в модель для интерпретации.
Уровень сервисов и управление состоянием
Уровень служб предоставляет возможности сохранения, которые преобразуют взаимодействия LLM без сохранения состояния в приложения с сохранением состояния. На этом уровне работают три основных сервиса.
Службы сеансов поддерживают диалоговое состояние на протяжении нескольких ходов. Служба InMemorySessionService, используемая в нашем примере, хранит все в памяти, подходящей для разработки и тестирования. В производственных развертываниях обычно используются постоянные серверные части, такие как Cloud Firestore или PostgreSQL.
session_service = InMemorySessionService() session = asyncio.run(session_service.create_session( app_name=APP_NAME, user_id=USER_ID, session_id=SESSION_ID)) 1234567 session_service = InMemorySessionService() session = asyncio.run(session_service.create_session( app_name=APP_NAME, user_id=USER_ID, session_id=SESSION_ID))
Службы артефактов обеспечивают хранение и извлечение файлов, позволяя агентам работать с документами, изображениями и другими двоичными данными. Службы памяти обеспечивают долговременное хранение информации, которая должна сохраняться между сеансами.
Уровень служб подключается к внешним системам хранения через четко определенные интерфейсы. Эта абстракция позволяет менять местами серверные хранилища без изменения логики агента. Ваш метеорологический агент может перейти из хранилища в памяти в распределенную базу данных, просто изменив реализацию службы сеансов.
Полный поток запросов
Отслеживание полного запроса через систему показывает, как взаимодействуют эти компоненты.
Пользователь отправляет сообщение «Какая погода в Лондоне?» с их идентификатором сеанса. Runner получает это сообщение, помещает его в объект Content и инициирует цикл обработки событий. Логика выполнения вызывает LLM с сообщением пользователя и определениями доступных инструментов.
Модель распознает это как запрос погоды и генерирует вызов инструмента get_weather с аргументом «Лондон». Логика выполнения перехватывает этот вызов, вызывает функцию Python и фиксирует возвращаемое значение. Событие, содержащее результат инструмента, проходит обратно через систему.
Модель получает выходные данные инструмента и генерирует ответ на естественном языке, суммирующий погодные условия. Это событие окончательного ответа передается пользователю через Runner.
На протяжении всего этого процесса служба сеансов поддерживает контекст. Когда пользователь задает вопрос «Как насчет Парижа?», история сеанса позволяет модели понять, что это относится к погоде, хотя это слово никогда не появляется во втором запросе.
Ключевые последствия ADK при проектировании
Архитектура ADK раскрывает несколько важных принципов проектирования приложений искусственного интеллекта.
Подход, управляемый событиями, обеспечивает возможность наблюдения и отладки, что было бы невозможно при использовании синхронных API. Вы можете регистрировать каждый вызов инструмента, отслеживать обоснование модели и строить сложную аналитику поведения агентов.
Разделение между логикой выполнения и логикой выполнения создает четкие границы для тестирования. Вы можете имитировать логику выполнения, чтобы протестировать поведение Runner, или внедрить тестовые двойники для внешних служб, чтобы проверить логику агента изолированно.
Абстракция уровня служб защищает ваше приложение от изменений инфраструктуры в будущем. Поскольку управляемые службы для памяти агентов и хранилища сеансов становятся доступными, миграция требует минимальных изменений кода.
Заключение
Комплект разработки агентов Google предоставляет готовую к использованию среду для создания приложений искусственного интеллекта, выходящих за рамки простых интерфейсов чата. Архитектура цикла событий в сочетании с надежным управлением сеансами и гибкой интеграцией инструментов позволяет разработчикам создавать агенты, которые поддерживают контекст, вызывают внешние возможности и масштабируются в распределенной инфраструктуре. Понимание этих архитектурных основ позволит вам создавать сложные системы искусственного интеллекта, отвечающие реальным требованиям.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джанакирам MSV — главный аналитик Janakiram & Associates и внештатный преподаватель Международного института информационных технологий. Он также является сертифицированным облачным разработчиком Google, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon,… Читать далее от Джанакирама MSV
