Agent Design Patterns - список паттернов проектирования агентных систем на базе ИИ

Экосистема систем агентов на основе FM, аннотированных архитектурными шаблонами в серых полях Рис.1. Экосистема систем агентов на основе FM, аннотированных архитектурными шаблонами в серых полях

Описание паттернов будем вести от более простых к более сложным.

Пассивный Создатель Целей (Passive Goal Creator)

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

Когда пользователи обращаются к агентам для решения определенных проблем, они предоставляют соответствующий контекст и объясняют цели в своих промптах. В мультиагентных системах архитекторы могут применять Пассивного Создателя Целей или Проявляющего Инициативу Создателя Целей в зависимости от сценариев применения и требований к доступности.

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

  • Недоопределение (Underspecification). Пользователи могут не предоставить достаточную контекстную информацию и точно сформулировать цели для агентов.
  • Эффективность. Пользователи ожидают быстрых ответов от агентов.

Графическое представление Пассивного Создателя Целей. Агент на основе базовой модели предоставляет диалоговый интерфейс, где пользователи могут напрямую указывать контекст и проблемы, которые передаются Пассивному Создателю Целей для определения целей.

Рисунок 3 иллюстрирует простое графическое представление Пассивного Создателя Целей. Агент на основе базовой модели предоставляет диалоговый интерфейс, где пользователи могут напрямую указывать контекст и проблемы, которые передаются Пассивному Создателю Целей для определения целей.

Пассивный Создатель Целей также может извлекать связанную информацию из памяти, включая:

  • Репозиторий обрабатываемых артефактов
  • Соответствующие инструменты, использованные в недавних задачах
  • Истории диалогов
  • Примеры положительных и отрицательных результатов

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

Важно отметить, что в мультиагентных системах один агент может отправлять промпты, вызывая API другого агента для назначения конкретной задачи, в то время как последний анализирует полученную информацию и определяет цель. Пассивный Создатель Целей сначала обрабатывает входные данные пользователей и передает цели и соответствующую контекстную информацию Оптимизатору Промптов/Ответов для уточнения промпта.

Преимущества

  • Интерактивность. Пользователи или другие агенты могут взаимодействовать с агентом через диалоговый интерфейс или соответствующие API.
  • Поиск целей. Агент может анализировать предоставленный пользователем контекст и извлекать связанную информацию из памяти для определения целей и создания соответствующих стратегий.
  • Эффективность. Пользователи могут напрямую отправлять промпты агенту через диалоговый интерфейс, что интуитивно понятно и легко в использовании.

Недостатки

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

Известные применения

  • Liu et al. разработали агента, который может общаться с пользователями и помогать уточнять исследовательские вопросы через диалоговый интерфейс.
  • Kannan et al. предложили агента для пользователей, чтобы декомпозировать и распределять задачи между роботами через диалоговый интерфейс.
  • HuggingGPT может генерировать ответы для решения пользовательских запросов через чат-бота. Запросы пользователей, включая сложные намерения, могут интерпретироваться как их целевые интенты.
  • Этот паттерн является одним из основных, с которых начинаются почти все ассистенты на основе ИИ.

Связанные паттерны

  • Проявляющий Инициативу Создатель Целей (Proactive Goal Creator). Может рассматриваться как альтернатива Пассивному Создателю Целей, позволяющая внедрение мультимодального контекста.
  • Оптимизатор Промптов/Ответов (Prompt/Response Optimiser).
  • Пассивный Создатель Целей может сначала обрабатывать входные данные пользователей и передавать цели и соответствующую контекстную информацию Оптимизатору Промптов/Ответов для уточнения промпта.

Пример в общем домене (Система поддержки клиентов)

В мультиагентной системе обслуживания клиентов Пассивный Создатель Целей реализован как центральный компонент, принимающий запросы от пользователей. Когда клиент пишет: "Мне не пришел заказ №12345", система:

  1. Анализирует промпт через Пассивного Создателя Целей
  2. Извлекает из памяти историю взаимодействия с этим клиентом (предыдущие заказы, жалобы)
  3. Дополняет запрос данными из репозитория заказов (статус заказа №12345, дата размещения)
  4. Добавляет примеры успешного разрешения подобных ситуаций из базы знаний
  5. Формирует уточненную цель: "Проверить статус доставки заказа №12345, отправить уведомление клиенту с текущим местоположением посылки и предполагаемым временем доставки"

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

Пример в разработке AI агента для кодинга (Мультиагентная система разработки ПО)

В мультиагентной системе программирования, такой как гипотетический "CodeArchitect AI", Пассивный Создатель Целей может быть реализован следующим образом:

Когда разработчик отправляет запрос: "Оптимизируй этот код для обработки больших данных", система:

  1. Передает промпт Пассивному Создателю Целей
  2. Который дополнительно учитывает контекст текущего проекта (стек технологий, структуру проекта и др.)
  3. Анализирует текущий файл кода, на который ссылается разработчик
  4. Формирует уточненную цель, напримнр: "Оптимизировать функцию data_processing в файле analytics.py, заменив циклы на векторизованные операции с использованием NumPy, добавить кэширование промежуточных результатов, протестировать на датасете размером 10M записей"

Эта цель передается:

  • Агенту-анализатору кода для выявления узких мест
  • Агенту-оптимизатору для внесения изменений
  • Агенту-тестировщику для проверки производительности

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

Проактивный создатель целей

Проактивный создатель целей предвосхищает цели пользователей путем анализа человеческих взаимодействий и сбора контекстной информации с помощью соответствующих инструментов.

Пользователи формулируют цели, которых должен достичь агент, в текстовом запросе.

Проблема: Контекстная информация, собранная исключительно через диалоговый интерфейс, может быть недостаточной, что приводит к неточным ответам на запросы пользователей.

Силы, влияющие на паттерн:

  • Недоопределённость целей:
    • Пользователи часто не могут предоставить полный контекст или точно сформулировать цели для агентов.
    • Агенты ограничены в объёме информации, которую могут извлечь из памяти.
  • Доступность: Пользователи с определёнными ограниченными возможностями могут не иметь возможности напрямую взаимодействовать с агентом через пассивного создателя целей.

графическая схема работы проактивного создателя целей

На Рисунке 4 представлена графическая схема работы проактивного создателя целей. Помимо обработки текстовых запросов через диалоговый интерфейс и данных из памяти, паттерн предполагает:

  1. Отправку запросов на детекторы (специализированные инструменты), которые собирают мультимодальную контекстную информацию о пользователе и его окружении (например, распознавание жестов через камеру, анализ интерфейса приложения по скриншотам).
  2. Уведомление пользователя о сборе данных с низким уровнем ложных срабатываний, чтобы избежать излишних прерываний.
  3. Сохранение собранной информации в памяти агента для формирования моделей мира, что позволяет улучшать понимание реальных сценариев использования.

Преимущества:
• Интерактивность: Агент взаимодействует с пользователями или другими агентами, предвосхищая их решения на основе мультимодальных данных.
• Точность целей: Дополнительные данные (жесты, визуальный контекст) повышают точность определения целей и их выполнения.
• Доступность: Инструменты сбора данных (например, анализ мимики или движений) делают систему доступной для людей с ограниченными возможностями.

Недостатки:
• Накладные расходы:

  • Использование мультимодальных инструментов увеличивает стоимость системы.
  • Ограниченный контекст может повысить коммуникационную нагрузку между пользователем и агентом.

Известные примеры применения:
• GestureGPT: Расшифровывает описания жестов пользователя для определения его намерений.
• Инструмент анализа программных скринкастов: Извлекает шаги кодирования и сниппеты из видеозаписей экрана.
• ProAgent: Наблюдает за действиями других агентов в команде, определяет их цели и корректирует собственный план.

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

Пример реализации в мультиагентных системах Общая предметная область

Умный дом с проактивным контролем

  • Агенты системы умного дома используют данные с камер, микрофонов и датчиков движения для предвосхищения действий пользователя. Например:
    • При обнаружении жеста «показать на окно» (через камеру) агент автоматически открывает шторы.
    • Если пользователь произносит «холодно» (через микрофон), а датчики фиксируют падение температуры, агент повышает нагрев и отправляет уведомление: «Я увеличил температуру до 22°C. Подтвердите изменение?».
  • Архитектура:
    • Детекторы: Модуль распознавания жестов (на основе MediaPipe), аудиоанализатор (с использованием Whisper).
    • Память: Хранение моделей поведения (например, «пользователь всегда включает свет в 20:00»).
    • Уведомления: Подтверждение действий через голосовой интерфейс с таймаутом 5 секунд (низкий уровень ложных срабатываний).

Пример: Агент-помощник в IDE

  • Агент анализирует действия разработчика в реальном времени, чтобы предложить оптимизацию кода или обнаружить ошибки. Например:
    • При вводе цикла for с операцией if внутри агент замечает повторяющийся шаблон и предлагает вынести условие в отдельную функцию.
    • Если агент видит, что разработчик часто откатывает коммиты после запуска тестов, он предупреждает: «Обнаружено 3 отката после тестов. Проверить логи перед сохранением?».
  • Архитектура:
    • Детекторы:
    • Скриншот-анализатор (распознаёт структуру кода через OCR и AST-парсинг).
    • Трекер действий (фиксирует клики, время простоя, частоту использования горячих клавиш).
    • Память: База знаний с шаблонами рефакторинга (например, «цикл + условие → стратегия»).
    • Интеграция: Агент взаимодействует с другими агентами (например, тестовым runner’ом), чтобы прогнозировать последствия изменений.

Пример из практики:
В системе, подобной ProAgent, агент для разработки кода наблюдает за действиями коллег-агентов:

  • Агент A пишет функцию обработки данных, агент B запускает тесты.
  • Проактивный создатель целей замечает, что тесты агента B падают после изменений агента A, и предлагает: «Ваш код влияет на модуль X. Добавить обработку исключений?».
  • Для этого используются:
    • Детектор изменений в Git-истории.
    • Анализ зависимостей между модулями через статический анализатор.
    • Уведомление с предложением решения (ссылка на сниппет с try/except).

Ключевые рекомендации для реализации

  1. Минимизация ложных срабатываний: Используйте пороговые значения для уведомлений (например, активировать действие только при 90% уверенности в цели).
  2. Этика и прозрачность: Четко информируйте пользователя о сборе данных (например, иконка-индикатор работы камеры).
  3. Интеграция с памятью: Храните мультимодальные данные в структурированном виде (например, векторные базы для изображений + граф знаний для контекста).

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

Оптимизатор запросов/ответов

Оптимизатор запросов/ответов улучшает запросы и ответы в соответствии с желаемым содержанием и форматом входных или выходных данных.

Пользователи могут испытывать трудности при написании эффективных запросов, особенно учитывая необходимость включения подробного контекста. Аналогично, в некоторых случаях пользователям может быть сложно понять выводы агента.

Проблема: Как генерировать эффективные запросы и стандартизированные ответы, соответствующие целям или задачам пользователей?

  • Стандартизация. Запросы и ответы могут различаться по структуре, формату и содержанию, что приводит к путанице или несогласованному поведению агента.
  • Соответствие целям. Обеспечение соответствия запросов и ответов конечной цели позволяет агенту достигать желаемых результатов.
  • Интероперабельность. Сгенерированные запросы и ответы могут напрямую использоваться другими компонентами, внешними инструментами или агентами для выполнения задач.

графическое представление оптимизатора запросов/ответов

Рис. 5 иллюстрирует графическое представление оптимизатора запросов/ответов. Пользователь вводит исходный запрос, который может быть неэффективным из-за отсутствия контекста, избыточности или направленным на поиск уязвимостей (например, с инъекций). Оптимизатор формирует уточнённые запросы и ответы, соответствующие предопределённым ограничениям и спецификациям. Эти ограничения описывают желаемое содержание и формат, обеспечивая соответствие целям.

Шаблон запроса часто выступает в роли «фабрики» для создания конкретных экземпляров запросов/ответов. Он включает:

  • Инструкции для агента,
  • Примеры для few-shot обучения,
  • Целевой вопрос или задачу.

Пример структуры шаблона: 

Инструкция: -------  
Пример: ---------  
Вопрос: ---------

Преимущества:

  • Стандартизация. Генерация унифицированных запросов/ответов согласно шаблону.
  • Соответствие целям. Повышенная точность и релевантность результатов.
  • Интероперабельность. Упрощение взаимодействия с внешними инструментами.
  • Адаптивность. Возможность настройки под доменные требования через базу знаний.

Недостатки:

  • Недоопределённость. Сложность учёта всего контекста из-за неоднозначности ввода пользователя.
  • Затраты на поддержку. Модификация шаблонов при изменении требований требует времени и тестирование на ошибки.

Известные реализации:

  • LangChain. Предоставляет шаблоны запросов для создания агентов на основе foundation-моделей.
  • Amazon Bedrock. Позволяет настраивать шаблоны запросов для обработки ввода агентом.
  • Dialogflow. Использует генераторы для определения поведения агентов в реальном времени.

Связанные паттерны:

  • Пассивный/активный создатель целей передаёт контекст оптимизатору.
  • Паттерны рефлексии (Self-reflection, Cross-reflection) оценивают выводы оптимизатора.
  • Адаптер агента использует оптимизированные запросы для взаимодействия с внешними инструментами.

Общий домен: Система поддержки клиентов

Сценарий: Пользователь отправляет расплывчатый запрос: «У меня не работает интернет».

Как работает оптимизатор:

  • Шаг 1. Агент-оптимизатор анализирует историю взаимодействия (например, пользователь ранее жаловался на обрывы связи по вечерам).

  • Шаг 2. Формирует структурированный запрос для технического агента: 

    Инструкция: Диагностируй проблему с интернет-соединением, используя логи за последние 24 часа.  
Контекст: Пользователь сообщал о проблемах в 19:00–22:00. Текущий статус: пинг 300 мс, пакеты теряются.  
Вопрос: Какие действия предпринять для стабилизации соединения?

  • Шаг 3. Технический агент возвращает стандартизированный ответ в формате JSON: 

    {  
"рекомендации": ["перезагрузить роутер", "проверить кабель"],  
"приоритет": "высокий"  
}

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

Пример из разработки AI-агента для кодинга (Software Engineering)

Сценарий: Пользователь просит: «Исправь баг в функции sort_data».

Как работает оптимизатор:

  • Шаг 1. Собирает контекст из репозитория:
    • Код функции sort_data с ошибкой TypeError: 'NoneType' object is not iterable.
    • Логи тестов, где падает кейс с пустым списком.
  • Шаг 2. Генерирует детализированный запрос для кодирующего агента: 
    Инструкция: Исправь функцию sort_data, обработав случай пустого ввода.  
Пример:  
Ввод: [] → Ожидаемый вывод: []  
Ввод: [3, 1] → Ожидаемый вывод: [1, 3]  
Код функции:  
def sort_data(arr):  
    return sorted(arr)  # Ошибка при arr = None  
Вопрос: Как модифицировать функцию для обработки None и пустых списков?
  • Шаг 3. Кодирующий агент возвращает исправленный код с комментариями: 
    def sort_data(arr):  
  if arr is None:  
      return []  
  return sorted(arr)

Результат:

  • Устранена ошибка, связанная с None.
  • Ответ соответствует стандартам кода проекта (PEP8, типизация).
  • Шаблон интегрирован в CI/CD: перед коммитом оптимизатор проверяет запросы на полноту контекста.

Дополнительная реализация в мультиагентной системе:

  • Агент-ревьюер использует оптимизированный запрос для сравнения исправления с best practices.
  • Агент-документатор автоматически генерирует changelog на основе структурированного ответа.

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

  • Динамические шаблоны: В проектах с частыми изменениями (например, стартапы) шаблоны запросов хранятся в базе знаний с версионированием (аналогично Git).
  • Обратная связь от пользователей: Если ответ агента отклоняется, оптимизатор корректирует шаблон через механизм human-in-the-loop.
  • Интеграция с IDE: В VS Code расширение анализирует комментарии разработчика и автоматически дополняет запросы для GitHub Copilot контекстом из открытых файлов.

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

Расширенное генерирование с извлечением (Retrieval Augmented Generation, RAG)

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

Агенты, построенные на крупных базовых моделях, не обладают знаниями, специфичными для конкретных предметных областей — особенно если речь идёт о высококонфиденциальных или приватных локальных данных, — если только они не были дообучены (fine-tuned) с использованием данных этой области. Стандартные модели полагаются исключительно на знания, полученные во время предварительного обучения, что делает их непригодными для задач, требующих актуальной или защищённой информации.

Перед лицом конкретной задачи как может агент проводить рассуждения, используя данные или знания, которые не были усвоены базовой моделью в процессе её обучения?

Факторы

  • Недостаток знаний. Процесс рассуждения может быть ненадёжным, когда агенту требуется выполнить задачу в предметной области, в которой у него отсутствуют соответствующие знания.
  • Вычислительная нагрузка. Дообучение крупной базовой модели на локальных данных или обучение такой модели локально требует значительных вычислительных мощностей и ресурсов.
  • Конфиденциальность данных. Локальные данные являются конфиденциальными и не могут использоваться для обучения или дообучения моделей без риска утечки.

графическая схема паттерна RAG

На Рисунке 6 представлена графическая схема паттерна RAG. RAG — это техника, позволяющая повысить точность и достоверность выводов агента за счёт фактов, извлекаемых из внешних источников (локальных или онлайн-баз данных). Пробелы в знаниях, отсутствующих в памяти агента, заполняются за счёт параметризованных знаний, хранящихся в векторных базах данных.

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

Реализация RAG включает следующие шаги:

  1. Определение источников данных. Выбор внутренних или внешних источников: документы, базы знаний, кодовая база, API и т.д.
  2. Подготовка структуры данных. Индексация "сырых" данных (текст, изображения, видео, аудио) в виде эмбеддингов или графов знаний.
  3. Поиск по запросу. При поступлении запроса исполнитель задач (task executor) кодирует его и производит поиск в базе знаний (например, в векторном хранилище), чтобы извлечь наиболее релевантную информацию.
  4. Обработка результатов. Извлечённые данные проходят фильтрацию и переупорядочивание (reranking), чтобы сформировать более информированный и точный ответ.

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

Существует множество разновидностей RAG, ориентированных на различные аспекты улучшения, источники данных и приложения, такие как:

  • Federated RAG — для децентрализованных систем с распределёнными данными.
  • Graph RAG — использование графов знаний вместо векторных хранилищ для более сложных связей между фактами.
  • Retrieval Interleaved Generation — динамическое извлечение информации на протяжении всего процесса генерации ответа, а не единовременно.

Преимущества:

  • Извлечение знаний. Агенты могут находить и использовать знания, релевантные текущей задаче, что повышает надёжность рассуждений.
  • Возможность обновления. Знания в векторных хранилищах можно легко обновлять, что обеспечивает актуальность информации без изменения самой модели.
  • Конфиденциальность данных. Данные остаются локальными и не передаются в сторонние модели, что критично для корпоративных и регулируемых сред.
  • Экономическая эффективность. Отпадает необходимость в полном обучении новой модели; RAG позволяет использовать существующую базовую модель, дополняя её знаниями извне.

Недостатки:

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

Известные примеры использования:

  • LinkedIn. Использует RAG для построения конвейера агентов на основе базовых моделей, способных находить релевантные кейсы и отвечать пользователям.
  • Yan et al. [33]. Разработали механизм оценки извлечённых данных, который возвращает степень уверенности после анализа их качества, тем самым повышая устойчивость и производительность RAG.
  • Levonian et al. [34]. Применили RAG с GPT-3.5 для создания агента, способного извлекать содержимое качественного открытого учебника по математике и отвечать студентам.

Общий пример: Мультиагентная система поддержки клиентов

Сценарий:
Компания предоставляет техническую поддержку через AI-агентов. У неё есть база знаний с документацией, FAQ, журналами изменений и внутренними руководствами.

Реализация:

  • Агент-координатор принимает запрос пользователя: "Как обновить лицензию на продукт X?"
  • Перед генерацией ответа он вызывает инструмент retrieve_knowledge, передавая запрос в виде текста.
  • Инструмент преобразует запрос в эмбеддинг, выполняет поиск в векторной базе (например, ChromaDB или FAISS), возвращает 3 наиболее релевантных фрагмента документации.
  • Координатор передаёт эти фрагменты вместе с оригинальным запросом субагенту-ответчику (роль: техподдержка).
  • Субагент формирует точный, обоснованный ответ, ссылаясь на извлечённые данные, и возвращает его пользователю.

Пример в разработке ПО: AI-агент для кодинга (Software Engineering Agent)

Сценарий:
AI-агент помогает разработчику рефакторить устаревший модуль Python, используя внутреннюю документацию компании и историю коммитов.

Архитектура:

  • Основной агент (Planner): Получает задачу: "Обнови модуль auth.py, сделав его совместимым с новым API авторизации."
  • Он вызывает инструмент reflect, чтобы зафиксировать гипотезу: "Необходимо изучить спецификацию нового API и текущую реализацию."
  • Затем вызывается retrieve_knowledge с запросом: "API specification v2 auth endpoint" и "best practices for JWT handling in Python".
  • Извлечённые данные включают:
    • Фрагмент спецификации.
    • Руководство по безопасности от внутреннего DevSecOps.
    • Примеры кода из репозитория.
  • Основной агент создаёт субагента-программиста (Coder), передавая ему контекст и задачу.
  • Субагент анализирует код, применяет паттерны, генерирует исправленный auth.py, добавляет комментарии и ссылки на источники.

Дополнительно:
Можно реализовать Graph RAG, где связи между компонентами системы (например, микросервисами) представлены в виде графа. Это позволяет агенту понимать зависимости и предлагать безопасные изменения.

Интеграция с системой управления знаниями (аналог Dialogflow / Bedrock)

Сравнение с облачными решениями:

  • В Google Dialogflow используется концепция "generative data stores", которая по сути является реализацией RAG: агент извлекает данные из подключённых источников (BigQuery, CRM) и генерирует grounded-ответы.
  • В AWS Bedrock можно настраивать "advanced prompts" и включать/отключать этапы, такие как KNOWLEDGE_BASE_RESPONSE_GENERATION, что позволяет явно контролировать, когда и как происходит извлечение знаний.

Связанные паттерны:
RAG может дополнять все остальные паттерны, предоставляя дополнительный контекст из локального хранилища. Особенно эффективно сочетание с:

  • Субагентами — каждый субагент может иметь свой узкоспециализированный векторный индекс.
  • Рассуждением (ReAct) — извлечённые данные используются как "Thoughts" перед действием.
  • Хранением промежуточных размышлений — гипотезы и выводы на основе извлечённых данных фиксируются с помощью reflect.

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

Паттерн "Однократный запрос к модели" (One-Shot Model Querying)

Фундаментальная модель используется в одном экземпляре для генерации всех необходимых шагов плана.

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

Проблема: как агент может эффективно генерировать шаги плана?

Факторы • Эффективность. Для определенных срочных задач агент должен быть способен проводить планирование и отвечать в короткие сроки. • Накладные расходы. Пользователи должны платить за каждое взаимодействие с коммерческими фундаментальными моделями.

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

Рис. 7. Однократный запрос к модели.

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

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

Недостатки: • Упрощение. Для сложных задач однократный запрос к модели может не в состоянии полностью уловить все требования за один раз, поэтому упрощает задачи и не может вернуть правильный ответ. • Отсутствие объяснимости. Однократный запрос к модели может страдать отсутствием объяснимости, поскольку встроенная фундаментальная модель запрашивается только один раз, что может не обеспечить детальных шагов рассуждений для генерации плана. • Размер окна контекста. Качество ответа может быть ограничено с учетом текущих возможностей фундаментальных моделей обрабатывать длинные разговорные контексты и ограничений по токенам.

Однократный запрос к модели можно рассматривать как конфигурацию или использование по умолчанию, когда пользователь использует фундаментальную модель, в то время как Chain of Thought (CoT) и Zero-shot-CoT являются примерами этого паттерна.

Связанные паттерны: • Пошаговый запрос к модели (Incremental model querying). Пошаговый запрос к модели можно рассматривать как альтернативу однократному запросу к модели с итерациями. • Генератор плана с одним путем (Single-path plan generator). Однократный запрос к модели позволяет генерировать планы с одним путем, запрашивая фундаментальную модель только один раз. • Мультимодальные ограничения (Multimodal guardrails). Мультимодальные ограничения служат промежуточным слоем, управляющим входами и выходами запросов к модели.

Пример: cистема планирования путешествий

Представьте мультиагентную систему для планирования путешествий, где пользователь запрашивает "Спланируй 7-дневное путешествие в Париж с бюджетом 2000 евро".

Агент-планировщик использует паттерн однократного запроса к модели:

  • Формирует один запрос к LLM с полным описанием задачи
  • Запрашивает генерацию полного плана в структурированном формате (YAML/JSON)
  • Получает ответ с детализированным планом на 7 дней, включая отели, рестораны, достопримечательности и транспорт
  • Парсит ответ и представляет пользователю готовый план

Пример реализации на Python:

def plan_trip(user_query):
    prompt = f"""
    Сгенерируй детальный 7-дневный план путешествия в Париж с бюджетом 2000 евро.
    Верни результат в YAML формате со следующей структурой:

    plan:
      budget: [общий бюджет]
      daily_budget: [ежедневный бюджет]
      days:
        - day: 1
          morning: 
            activity: [название]
            cost: [стоимость]
            location: [местоположение]
          afternoon: {...}
          evening: {...}
        - day: 2
          ...

    Дополнительные примечания:
    - Убедись, что общий бюджет не превышает 2000 евро
    - Включи как минимум одну достопримечательность каждый день
    - Распределение бюджета должно быть сбалансированным
    """

    # Однократный запрос к модели
    response = llm.generate(prompt)

    # Парсинг YAML ответа с защитой от ошибок
    try:
        trip_plan = yaml.safe_load(response)
        return trip_plan
    except yaml.YAMLError:
        # Применение техник, подобных описанным в статье LinkedIn
        # для исправления типичных ошибок форматирования
        fixed_response = fix_yaml_errors(response)
        return yaml.safe_load(fixed_response)

Пример: система поддержки клиентов

В системе поддержки клиентов агент использует однократный запрос для генерации полного сценария ответа на запрос клиента "Как мне вернуть товар, купленный 2 недели назад?"

Агент формирует один запрос к модели, который включает:

  • Политику возврата компании
  • Текущий статус заказа клиента
  • Личные данные клиента (анонимизированные)
  • Требование сгенерировать ответ в структурированном формате

Пример реализации защиты от ошибок, как в случае с LinkedIn:

def generate_customer_response(query, order_data):
    prompt = f"""
    На основе следующей информации сгенерируй ответ клиенту о возврате товара:

    Политика возврата:
    - Возврат возможен в течение 30 дней с даты покупки
    - Товар должен быть в оригинальной упаковке
    - Необходимо предоставить чек

    Информация о заказе:
    {json.dumps(order_data, indent=2)}

    Верни ответ в следующем YAML формате:

    response:
      greeting: "Текст приветствия"
      policy_explanation: "Объяснение политики возврата применительно к этому случаю"
      steps:
        - "Шаг 1"
        - "Шаг 2"
        - "Шаг 3"
      closing: "Заключительный текст"
      estimated_time: "Ожидаемое время обработки"
    """

    response = llm.generate(prompt)

    # Реализация защитного парсера
    # Анализируем типичные ошибки и пытаемся их исправить
    if not is_valid_yaml(response):
        response = apply_yaml_fixes(response, expected_schema)

    return parse_yaml_safely(response)

Пример: агент для генерации функций

AI агент для программирования использует однократный запрос к модели для генерации полной функции на основе спецификации пользователя.

Пример запроса: "Напиши функцию на Python, которая преобразует дату из формата MM/DD/YYYY в YYYY-MM-DD, с проверкой корректности даты."

def generate_code_function(specification):
    prompt = f"""
    Ты - опытный разработчик Python. Напиши функцию, соответствующую следующей спецификации:

    {specification}

    Верни результат в следующем YAML формате:

    code:
      function_name: "Имя функции"
      imports: ["Список необходимых импортов"]
      code: |
        def {function_name}(date_str):
            # Реализация функции
            ...
      test_cases:
        - input: "Пример входного значения"
          expected_output: "Ожидаемый результат"
        - input: ...
          expected_output: ...
      explanation: "Краткое объяснение логики функции"

    Требования:
    - Функция должна включать проверку корректности даты
    - Добавь комментарии к сложным частям кода
    - Предоставь как минимум 3 тестовых случая
    """

    response = llm.generate(prompt)

    # Применение защитного YAML-парсера
    try:
        result = yaml.safe_load(response)
        # Дополнительная проверка структуры
        if not validate_code_schema(result):
            result = fix_code_schema(result, specification)
        return result
    except Exception as e:
        # Анализируем ошибки и применяем исправления
        fixed_response = linkedin_style_yaml_fixer(response)
        return yaml.safe_load(fixed_response)

Агент для рефакторинга кода

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

Пример использования:

def refactor_code(original_code, requirements):
    prompt = f"""
    Ты - senior Python разработчик. Проведи рефакторинг следующего кода:

    Исходный код:
    {original_code}

    Требования к рефакторингу:
    {requirements}

    Верни результат в YAML формате:

    refactored:
      code: |
        # Полный отрефакторенный код
      changes:
        - description: "Описание изменения 1"
          reason: "Причина изменения"
          before: "Фрагмент исходного кода"
          after: "Фрагмент измененного кода"
        - description: ...
      improvements:
        - "Улучшение 1 (производительность)"
        - "Улучшение 2 (читаемость)"
        - ...
      potential_issues: 
        - "Возможная проблема 1"
        - ...
      tests_needed:
        - "Тестовый случай, который нужно добавить"

    ВАЖНО:
    - Сохрани функциональность исходного кода
    - Улучши читаемость и поддерживаемость
    - Добавь комментарии там, где это необходимо
    - Не изменяй входные и выходные интерфейсы функции
    """

    response = llm.generate(prompt)

    # Реализация защиты от ошибок форматирования
    # Как описано в статье LinkedIn (сокращение ошибок с ~10% до ~0.01%)
    safe_response = defensive_yaml_parser(response)
    return yaml.safe_load(safe_response)

Паттерн «Инкрементальный запрос модели» (Incremental Model Querying)

Инкрементальный запрос модели предполагает взаимодействие с базовой моделью на каждом этапе процесса генерации плана.

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

Проблема: Базовая модель может не сформировать корректный ответ с первой попытки. Как агенту обеспечить точный процесс рассуждений?

Факторы

  • Ограничение размера контекстного окна. Контекстное окно базовой модели может быть ограничено, поэтому пользователи не могут предоставить полный и исчерпывающий промпт.
  • Упрощение процесса. Процесс рассуждений может быть чрезмерно упрощен, что приводит к неопределенностям при однократном запросе модели.
  • Отсутствие объяснимости. Сгенерированные базовыми моделями ответы требуют детального процесса рассуждений для обеспечения объяснимости и, как следствие, доверия.

взаимодействие между компонентом генерации плана и интегрированной базовой моделью с использованием инкрементального запроса модели

Рис. 8. Incremental Model Querying

На рисунке 8 показано взаимодействие между компонентом генерации плана и интегрированной базовой моделью с использованием инкрементального запроса модели. Агент может вести пошаговый процесс рассуждений для разработки плана достижения цели с помощью множественных запросов к базовой модели. При этом пользователь может в любой момент предоставить обратную связь как по процессу рассуждений, так и по сгенерированному плану, что позволяет вносить соответствующие корректировки в процессе запроса модели. Количество запросов может быть предопределено в конфигурации агента или указано в пользовательском промпте. Следует отметить, что инкрементальный запрос модели может опираться на повторно используемый шаблон, который направляет процесс через внедрение контекста или явную систему управления репозиторием рабочих процессов/планов. Этот паттерн применим, когда другие компоненты запрашивают интегрированную базовую модель.

Преимущества:

  • Дополнительный контекст. Инкрементальный запрос модели позволяет пользователям разбивать контекст на несколько промптов, решая проблему ограниченного контекстного окна.
  • Определенность рассуждений. Базовые модели будут итеративно уточнять шаги рассуждений через самопроверку или обратную связь от пользователей.
  • Объяснимость. Пользователи могут запросить у базовой модели предоставления детальных шагов рассуждений через инкрементальный запрос модели.

Недостатки:

  • Накладные расходы.
    • Инкрементальный запрос модели требует множественных взаимодействий с базовой моделью, что может увеличить время, необходимое для определения плана.
    • Большой объем пользовательских запросов может быть затратным при использовании коммерческих базовых моделей.

Известные применения:

  • HuggingGPT. Базовая модель HuggingGPT запрашивается несколько раз для декомпозиции запросов пользователей на мелкогранулярные задачи, а затем определения зависимостей и порядка выполнения задач.
  • EcoAssistant. EcoAssistant применяет исполнитель кода, взаимодействующий с базовой моделью для итеративного улучшения кода.
  • ReWOO. ReWOO запрашивает базовую модель для: i) генерации списка взаимозависимых планов; ii) объединения собранных инструментами доказательств с соответствующей задачей.

Связанные паттерны:

  • Однократный запрос модели. Инкрементальный запрос модели можно рассматривать как альтернативу однократному запросу модели с итерацией.
  • Генератор планов с несколькими путями. Агент может учитывать предпочтения пользователей на каждом шаге и генерировать планы с несколькими путями, итеративно запрашивая базовую модель.
  • Самоанализ. Самоанализ требует, чтобы агенты несколько раз запрашивали встроенную базовую модель для проверки и оценки ответов.
  • Анализ с участием человека. Анализ с участием человека реализуется через инкрементальный запрос модели для итеративного общения между пользователями/экспертами и агентом.
  • Мультимодальные защитные барьеры. Мультимодальные защитные барьеры служат промежуточным слоем, управляющим вводом и выводом запросов модели.

Пример в общем домене мультиагентных систем

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

  2. Адаптивная маршрутизация запросов: Центральный агент-роутер распределяет задачи между специализированными агентами, где каждый последующий запрос к модели уточняет детали на основе предыдущих результатов. Например, в системе анализа рынка первый запрос определяет основные тренды, второй — сегментирует аудиторию, третий — формирует рекомендации на основе собранных данных.

** Примеры в разработке AI агентов для кодинга (Software Engineering)

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

  2. Итеративное улучшение через исполнение кода: Как в EcoAssistant, система запрашивает базовую модель для генерации кода, затем выполняет его в изолированной среде, анализирует результаты и возвращает ошибки или узкие места обратно в модель для уточнения следующей итерации. Например, при генерации алгоритма сортировки модель сначала предоставляет базовую реализацию, система запускает ее на тестовых данных, обнаруживает переполнение стека при больших объемах данных и запрашивает у модели оптимизированную версию.

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

  4. Генерация и верификация тестов: Агент для тестирования ПО сначала запрашивает у модели генерацию тестовых сценариев, затем запускает их, анализирует покрытие кода и возвращает информацию о непокрытых участках для генерации дополнительных тестов в следующей итерации. Это особенно полезно в системах непрерывной интеграции, где требуется поддержание высокого качества кода при частых изменениях.

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

Паттерн: Генератор линейного плана

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

Агент воспринимается пользователями как «чёрный ящик», при этом им важно понимать процесс достижения их целей.

Проблема: как агент может эффективно формулировать стратегии для достижения целей пользователей?

  • Недоопределённость. Пользователи часто ставят задачи с высоким уровнем абстракции, что усложняет обработку неопределённости или двусмысленности в контексте.
  • Согласованность. Пользователи и взаимодействующие инструменты/агенты ожидают чётких и логически связанных шагов для достижения целей.
  • Эффективность. Неопределённые решения снижают производительность агента, уменьшая удовлетворённость пользователей.

Single-path plan generator.

Рис. 9. Single-path plan generator.

На рис. 9 показано графическое представление генератора линейного плана. После анализа цели пользователя он координирует создание плана для других агентов или инструментов, определяя последовательность шагов. Каждый шаг имеет только один последующий, формируя линейный путь (например, Chain-of-Thought, CoT). Для повышения надёжности используется самосогласованность: основная модель опрашивается несколько раз, и выбирается наиболее согласованный результат. Детализация плана зависит от сложности задачи — например, сложные сценарии могут включать комбинацию рабочих процессов и мелких шагов.

Преимущества:

  • Определённость рассуждений. Многошаговый план отражает логику решения, минимизируя неопределённость.
  • Согласованность. Все участники (пользователи, агенты, инструменты) следуют единому пути к цели.
  • Эффективность. Устранение лишних шагов повышает скорость выполнения задач.

Недостатки:

  • Ограниченная гибкость. Линейная структура не позволяет адаптироваться к изменяющимся предпочтениям пользователей.
  • Упрощение. Сложные задачи, требующие многовариантных подходов, могут быть недостаточно проработаны.

Известные применения:

  • LlamaIndex. Дообучает ReAct-агента для оптимизации линейного планирования через CoT.
  • ThinkGPT. Предоставляет инструментарий для реализации паттерна.
  • Чжан и др. Раскрывают механизмы применения CoT в планировании.

Связанные паттерны:

  • Однократный запрос к модели. Генерация плана за один запрос к базовой модели.
  • Генератор многоэтапного плана. Альтернатива для кастомизированных стратегий.
  • Саморефлексия. Дополняет CoT для повышения самосогласованности.

Пример: Организация международной конференции

Сценарий: Пользователь просит: «Организуй конференцию по ИИ в Амстердаме для 200 участников».
Как работает паттерн:

  • Генератор линейного плана (координирующий агент) создаёт последовательность:
    1. Агент локаций проверяет доступность конференц-залов и бронирует площадку.
    2. Агент логистики организует трансфер и размещение для спикеров.
    3. Агент контента согласовывает программу с докладчиками.
    4. Агент регистрации настраивает онлайн-регистрацию и высылает приглашения.
      Особенности:
  • Каждый шаг зависит от результата предыдущего (например, даты зависят от доступности площадки).
  • Плюсы: Чёткое разделение ответственности, минимизация конфликтов.
  • Минусы: При изменении даты конференции требуется перезапуск всего плана (низкая гибкость).

Пример разработка AI-агента для кодинга: Генерация Full-Stack приложения

Сценарий: Пользователь запрашивает: «Создай приложение для управления задачами с авторизацией и API».
Как работает паттерн:

  • Генератор линейного плана формирует:
    1. Агент-архитектор проектирует структуру БД и эндпоинты API.
    2. Агент бэкенда реализует логику на Python (FastAPI) с JWT-авторизацией.
    3. Агент фронтенда создаёт интерфейс на React с интеграцией API.
    4. Агент тестирования генерирует unit-тесты и проверяет покрытие кода.
      Особенности:
  • Выход каждого агента становится входом для следующего (например, спецификация API от архитектора используется бэкенд-агентом).
  • Плюсы: Ускорение разработки за счёт параллельной работы специализированных агентов в линейном потоке.
  • Минусы: При обнаружении ошибки в архитектуре (шаг 1) требуется откат к началу, что увеличивает время правок.

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

Multi-Path Plan Generator (Генератор многоходовых планов)

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

Агент