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

Рис.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) с использованием данных этой области. Стандартные модели полагаются исключительно на знания, полученные во время предварительного обучения, что делает их непригодными для задач, требующих актуальной или защищённой информации.

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

Факторы

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

На Рисунке 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. Генерация и верификация тестов: Агент для тестирования ПО сначала запрашивает у модели генерацию тестовых сценариев, затем запускает их, анализирует покрытие кода и возвращает информацию о непокрытых участках для генерации дополнительных тестов в следующей итерации. Это особенно полезно в системах непрерывной интеграции, где требуется поддержание высокого качества кода при частых изменениях.

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

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

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

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

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

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

Рис. 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 (Генератор многоходовых планов)

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

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

Как агент может генерировать высококачественное, согласованное и эффективное решение, учитывая комплексность и разнообразие, когда ему поставлена сложная задача или проблема?

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

Рис. 10. Генератор многоходовых планов.

Рисунок 10 иллюстрирует графическое представление высокого уровня генератора многоходовых планов. Основываясь на генераторе одноходовых планов, генератор многоходовых планов может создавать несколько вариантов выбора на каждом шаге к достижению целей, что требует от базовой модели выделить приемлемые и выполнимые действия для каждого выбора на предыдущем шаге. В частности, предпочтения пользователей могут влиять на последующие промежуточные шаги, что приводит к различным конечным планам. Задействованные агенты и инструменты будут корректироваться соответствующим образом. Tree-of-Thoughts является примером этого шаблона проектирования.

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

Недостатки: • Накладные расходы. Декомпозиция задачи и генерация множества планов могут увеличить коммуникационные накладные расходы между пользователем и агентом.

Известные применения: • AutoGPT. AutoGPT может принимать обоснованные решения, включая Tree-of-Thoughts в качестве генератора многоходовых планов. • Gemini. Для задачи Gemini может генерировать несколько вариантов для выбора пользователями. Получив ответы пользователей, Gemini предоставит несколько вариантов для следующего шага. • Open AI. GPT-4 был использован для реализации генератора многоходовых планов на основе Tree-of-Thoughts.

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

Финансовый консультационный агент

Рассмотрим систему, где мультиагентная система помогает пользователю анализировать финансовую отчетность компании Uber за разные кварталы 2022 года. В этом случае генератор многоходовых планов может предложить следующие варианты на каждом этапе:

1. Шаг 1: Определение целей анализа

   • Вариант A: Анализ роста выручки за кварталы
   • Вариант B: Оценка факторов, негативно влияющих на бизнес
   • Вариант C: Сравнение методов признания выручки в разных кварталах

2. Шаг 2: Выбор источников данных (после выбора Варианта B)

   • Вариант A: Анализ отчета за март 2022
   • Вариант B: Анализ отчета за июнь 2022
   • Вариант C: Сравнение всех трех отчетов (март, июнь, сентябрь)

3. Шаг 3: Глубина анализа (после выбора Варианта C)

   • Вариант A: Поверхностный анализ основных факторов
   • Вариант B: Подробный анализ с выявлением взаимосвязей между факторами
   • Вариант C: Прогнозирование влияния выявленных факторов на будущие кварталы

В системе на основе LlamaIndex, как описано в примере fine-tuning ReAct агента, агент может генерировать несколько путей анализа финансовых отчетов. Например, при запросе "Какие факторы негативно повлияли на бизнес Uber в 2022 году?" агент может предложить:

• Анализ рисков, связанных с пандемией COVID-19
• Анализ рисков, связанных с использованием искусственного интеллекта и потенциальных предубеждений
• Анализ климатических рисков и влияния экстремальных погодных условий
• Анализ рисков, связанных с безопасностью и защитой данных

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

Система рефакторинга кода с несколькими вариантами оптимизации

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

1. Шаг 1: Определение направления оптимизации

   • Вариант A: Оптимизация по скорости выполнения
   • Вариант B: Оптимизация по использованию памяти
   • Вариант C: Оптимизация по читаемости кода

2. Шаг 2: Выбор конкретной техники (после выбора Варианта A)

   • Вариант A: Изменение алгоритма на более эффективный (например, переход от линейного поиска к бинарному)
   • Вариант B: Кэширование промежуточных результатов
   • Вариант C: Параллелизация вычислений

3. Шаг 3: Реализация выбранной техники (после выбора Варианта A)

   • Вариант A: Реализация с минимальными изменениями в существующем коде
   • Вариант B: Полная переработка алгоритма с сохранением интерфейса
   • Вариант C: Интеграция с существующими библиотеками для поиска

Пример реализации на основе ThinkGPT:

from thinkgpt.llm import ThinkGPT
import json

llm = ThinkGPT(model_name="gpt-4")

def generate_multi_path_plan(task_description):
    """Генерирует многоходовой план для задачи оптимизации кода"""

    # Генерация нескольких вариантов на первом уровне
    planning_prompt = f"""
    Задача: {task_description}

    Предложи 3 различных направления для оптимизации этого кода.
    Для каждого направления опиши:
    1. Основную идею оптимизации
    2. Ожидаемые преимущества
    3. Возможные риски или ограничения

    Представь результат в формате JSON:
    {{
        "paths": [
            {{
                "id": "path_1",
                "title": "Название первого пути",
                "idea": "Основная идея",
                "benefits": ["преимущество 1", "преимущество 2"],
                "risks": ["риск 1", "риск 2"]
            }},
            {{
                "id": "path_2",
                "title": "Название второго пути",
                "idea": "Основная идея",
                "benefits": ["преимущество 1", "преимущество 2"],
                "risks": ["риск 1", "риск 2"]
            }},
            {{
                "id": "path_3",
                "title": "Название третьего пути",
                "idea": "Основная идея",
                "benefits": ["преимущество 1", "преимущество 2"],
                "risks": ["риск 1", "риск 2"]
            }}
        ]
    }}
    """

    response = llm.predict(planning_prompt)

    try:
        return json.loads(response)
    except:
        # В случае ошибки парсинга, попробуем извлечь JSON из текста
        import re
        json_match = re.search(r'\{[\s\S]*\}', response)
        if json_match:
            return json.loads(json_match.group(0))
        return {"error": "Не удалось распарсить ответ"}

def generate_detailed_plan(selected_path, task_description):
    """Генерирует детальный план для выбранного направления"""

    detailed_prompt = f"""
    Задача: {task_description}
    Выбранное направление: {selected_path['title']}

    Предложи 3 различных способа реализации этой оптимизации.
    Для каждого способа опиши:
    1. Подробное описание подхода
    2. Пример кода до и после оптимизации
    3. Оценка сложности реализации (низкая/средняя/высокая)

    Представь результат в формате JSON:
    {{
        "implementation_options": [
            {{
                "id": "option_1",
                "approach": "Описание подхода",
                "before_code": "Пример кода до",
                "after_code": "Пример кода после",
                "complexity": "низкая/средняя/высокая"
            }},
            ...
        ]
    }}
    """

    response = llm.predict(detailed_prompt)

    try:
        return json.loads(response)
    except:
        import re
        json_match = re.search(r'\{[\s\S]*\}', response)
        if json_match:
            return json.loads(json_match.group(0))
        return {"error": "Не удалось распарсить ответ"}

# Пример использования
task = "Оптимизируй алгоритм поиска в большом массиве данных (1 млн элементов)"
multi_path_plan = generate_multi_path_plan(task)

print("Доступные направления оптимизации:")
for path in multi_path_plan["paths"]:
    print(f"- {path['id']}: {path['title']}")
    print(f"  Идея: {path['idea']}")
    print(f"  Преимущества: {', '.join(path['benefits'])}")
    print(f"  Риски: {', '.join(path['risks'])}")
    print()

# Предположим, пользователь выбрал первый путь
selected_path = multi_path_plan["paths"][0]
detailed_plan = generate_detailed_plan(selected_path, task)

print(f"Детали для {selected_path['title']}:")
for option in detailed_plan["implementation_options"]:
    print(f"- Вариант {option['id']}:")
    print(f"  Подход: {option['approach']}")
    print(f"  Сложность: {option['complexity']}")
    print("  Пример кода:")
    print(f"    До: {option['before_code']}")
    print(f"    После: {option['after_code']}")
    print()

Этот пример демонстрирует, как в системе разработки ПО может быть реализован паттерн Multi-Path Plan Generator. Агент генерирует несколько вариантов реализации задачи и позволяет пользователю выбрать наиболее подходящий план, а затем управляет выполнением выбранного плана с помощью агента-исполнителя и набора специализированных инструментов.

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

Паттерн Саморефлексия (Self-Reflection) в проектировании AI Агентов

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

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

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

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

Рис. 11. Генератор многоходовых планов.

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

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

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

Недостатки:

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

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

• Reflexion Reflexion использует модель саморефлексии, которая может генерировать нюансированную и конкретную обратную связь на основе статуса успеха, текущей траектории и постоянной памяти.
• Bidder agent Модуль перепланирования в этом агенте использует саморефлексию для создания новых текстовых планов на основе статуса аукциона и новой контекстной информации.
• Generative agents Агенты выполняют рефлексию два или три раза в день, сначала определяя цель рефлексии в соответствии с недавней деятельностью, затем генерируя рефлексию, которая будет сохранена в потоке памяти.

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

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

Пример. Tree of Thoughts (ToT) от Princeton NLP

Одним из наиболее ярких примеров реализации паттерна саморефлексии является метод "Дерево мыслей" (Tree of Thoughts), разработанный Princeton NLP. Этот подход позволяет языковым моделям более сознательно решать сложные задачи через итеративный процесс рефлексии и выбора оптимальных путей рассуждений.

В отличие от традиционного Chain of Thought (цепочки рассуждений), где модель генерирует линейную последовательность мыслей, ToT создает "дерево" возможных рассуждений, где каждая ветвь представляет собой альтернативный путь решения. Ключевой компонент этой архитектуры — механизм саморефлексии, который позволяет модели оценивать качество своих промежуточных рассуждений и выбирать наиболее перспективные направления.

Например, в задаче "игра в 24" (где нужно использовать четыре числа и арифметические операции для получения результата 24), агент ToT:

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

Как видно из примера кода в документации:

import argparse
from tot.methods.bfs import solve
from tot.tasks.game24 import Game24Task
args = argparse.Namespace(backend='gpt-4', temperature=0.7, task='game24', naive_run=False, 
                         prompt_sample=None, method_generate='propose', method_evaluate='value', 
                         method_select='greedy', n_generate_sample=1, n_evaluate_sample=3, n_select_sample=5)
task = Game24Task()
ys, infos = solve(args, task, 900)
print(ys[0])

Этот код реализует алгоритм поиска в ширину (BFS) с саморефлексией, где method_evaluate='value' указывает на использование механизма оценки промежуточных состояний, а n_evaluate_sample=3 определяет, сколько раз модель будет запрашиваться для оценки каждого состояния. Это позволяет агенту критически оценивать свои собственные рассуждения и корректировать дальнейшие действия.

Генеративные агенты с периодической рефлексией

Система генеративных агентов (Generative Agents) реализует саморефлексию через запланированные сеансы рефлексии. Агенты в этой системе проводят саморефлексию 2-3 раза в день, следуя следующему процессу:

1. Определение цели рефлексии на основе недавней активности
2. Генерация глубоких размышлений о произошедших событиях
3. Сохранение этих размышлений в памяти для будущего использования

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

Агент с саморефлексией для генерации и оптимизации кода

AI агент для программирования может использовать саморефлексию следующим образом при реализации алгоритма:

def generate_sorting_algorithm(data):
    # Генерация первоначального кода
    initial_code = llm_generate("""
    Реализуй функцию сортировки для данного массива данных. 
    Вход: список чисел
    Выход: отсортированный список

    Пример:
    Вход: [3, 1, 4, 1, 5, 9]
    Выход: [1, 1, 3, 4, 5, 9]

    Реализация:
    """)

    # Саморефлексия: оценка качества сгенерированного кода
    reflection = llm_reflect(f"""
    Проанализируй следующий код сортировки на наличие ошибок, неэффективности и возможностей улучшения:

    {initial_code}

    Учти:
    1. Корректность алгоритма
    2. Обработка крайних случаев (пустой массив, один элемент)
    3. Сложность алгоритма
    4. Соответствие best practices
    5. Читаемость кода

    Предложи конкретные улучшения.
    """)

    # Генерация улучшенного кода на основе рефлексии
    improved_code = llm_generate(f"""
    Улучши следующий код сортировки, учитывая замечания из рефлексии:

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

    Рефлексия:
    {reflection}

    Улучшенный код:
    """)

    # Дополнительная проверка через саморефлексию
    final_reflection = llm_reflect(f"""
    Проверь улучшенный код на соответствие требованиям и отсутствие ошибок:

    {improved_code}

    Выполни мысленный тест на следующих примерах:
    1. Пустой массив []
    2. Массив с одним элементом [5]
    3. Уже отсортированный массив [1, 2, 3, 4]
    4. Обратно отсортированный массив [4, 3, 2, 1]

    Если есть проблемы, предложи окончательные исправления.
    """)

    # Генерация финального кода
    final_code = llm_generate(f"""
    Создай окончательную версию кода, учитывая последние замечания:

    Текущий код:
    {improved_code}

    Замечания:
    {final_reflection}

    Окончательный код:
    """)

    return final_code

В этом примере агент проходит через несколько этапов саморефлексии:

1. После генерации первоначального кода он критически оценивает его качество
2. На основе этой оценки генерирует улучшенную версию
3. Проводит дополнительную проверку через мысленный тест на различных сценариях
4. Создает окончательную версию с учетом всех замечаний

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

Интеграция Tree of Thoughts в агент для решения программистских задач

Можно адаптировать метод Tree of Thoughts для решения задач программирования. Например, при реализации алгоритма поиска кратчайшего пути в графе:

1. Генерация начальных мыслей: Агент генерирует несколько возможных подходов (Dijkstra, A*, BFS)
2. Оценка через саморефлексию: Для каждого подхода агент оценивает:
   • Сложность реализации
   • Эффективность алгоритма
   • Подходящие структуры данных
   • Возможные крайние случаи
3. Выбор наиболее перспективного пути: На основе оценки выбирается оптимальный алгоритм
4. Детализация с итеративной рефлексией: При реализации каждого компонента алгоритма агент проводит дополнительные сессии саморефлексии для проверки корректности и оптимальности

Пример реализации с использованием ToT для программистской задачи:

from tot.methods.bfs import solve
from tot.tasks.code_task import CodeTask

# Настройка задачи поиска кратчайшего пути
args = argparse.Namespace(
    backend='gpt-4', 
    temperature=0.7, 
    task='shortest_path', 
    naive_run=False,
    method_generate='propose',
    method_evaluate='value',
    method_select='greedy',
    n_generate_sample=3,      # Генерировать 3 различных подхода
    n_evaluate_sample=5,      # Оценивать каждый подход 5 раз для надежности
    n_select_sample=2         # Выбирать 2 лучших подхода для дальнейшей детализации
)

task = CodeTask(
    problem="Реализуй алгоритм поиска кратчайшего пути в невзвешенном графе",
    constraints="Граф представлен как список смежности, узлы пронумерованы от 0 до N-1"
)

# Решение с использованием Tree of Thoughts и саморефлексии
solutions, trace = solve(args, task, max_steps=10)

# Вывод лучшего решения
print("Лучшее решение:")
print(solutions[0])

# Вывод процесса рефлексии
print("\nПроцесс саморефлексии:")
for step, info in enumerate(trace):
    print(f"\nШаг {step+1}:")
    print(f"Сгенерированные мысли: {info['thoughts']}")
    print(f"Оценки: {info['values']}")
    print(f"Выбранные пути: {info['selected']}")

Этот код демонстрирует, как агент может использовать саморефлексию для выбора между различными алгоритмами (BFS, DFS и т.д.) и последующей оптимизации выбранного подхода. Механизм оценки (method_evaluate='value') позволяет агенту критически оценивать свои собственные предложения и выбирать наиболее перспективные для дальнейшей разработки.

Агент с саморефлексией для рецензирования кода

Еще один пример — агент, который проводит рецензирование собственного кода через саморефлексию:

def self_review_code(generated_code, requirements):
    # Первичная саморефлексия: соответствие требованиям
    requirement_reflection = llm_query(f"""
    Проверь, соответствует ли следующий код требованиям:

    Требования: {requirements}

    Код:
    {generated_code}

    Укажи:
    1. Какие требования выполнены
    2. Какие требования не выполнены
    3. Конкретные места в коде, где есть проблемы
    """)

    # Саморефлексия: поиск ошибок и уязвимостей
    error_reflection = llm_query(f"""
    Проанализируй следующий код на наличие:
    - Логических ошибок
    - Потенциальных исключений
    - Проблем с безопасностью
    - Неэффективных операций

    Код:
    {generated_code}

    Предложи конкретные исправления для каждой найденной проблемы.
    """)

    # Саморефлексия: оптимизация производительности
    performance_reflection = llm_query(f"""
    Оцени производительность следующего кода:

    {generated_code}

    Укажи:
    1. Операции с высокой временной/пространственной сложностью
    2. Возможные оптимизации
    3. Альтернативные подходы с лучшей производительностью
    """)

    # Объединение всех рефлексий и генерация исправленного кода
    fixed_code = llm_query(f"""
    На основе следующих рефлексий создай исправленную и оптимизированную версию кода:

    Анализ требований:
    {requirement_reflection}

    Анализ ошибок:
    {error_reflection}

    Анализ производительности:
    {performance_reflection}

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

    Исправленный код:
    """)

    return fixed_code, {
        "requirement_reflection": requirement_reflection,
        "error_reflection": error_reflection,
        "performance_reflection": performance_reflection
    }

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

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

Взаимное рефлексирование (Cross-Reflection)**

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

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

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

Это приводит к следующим рискам:

• Низкая точность решений.

• Отсутствие прозрачности в процессе принятия решений.

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

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

• Отсутствие объяснимости. Пользователь не видит, как был сформирован план, что затрудняет понимание и контроль за процессом.

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

Паттерн Взаимное рефлексирование предлагает использовать отдельного агента — агент-рефлексии (reflective agent), чья специализация заключается в анализе и оценке планов, гипотез и рассуждений других агентов. Процесс выглядит следующим образом:

1. Основной агент (например, планировщик или программист) формирует предварительный план решения задачи.
2. Этот план, вместе с цепочкой рассуждений (reasoning trace), передаётся одному или нескольким агентам-рефлексии.
3. Агент-рефлексия анализирует:
   • Логическую согласованность шагов.
   • Наличие пропущенных этапов.
   • Корректность использованных инструментов.
   • Возможные риски и альтернативы.
4. На основе анализа агент-рефлексии возвращает рекомендации по улучшению: замена шагов, добавление проверок, перестройка приоритетов и т.д.
5. Основной агент корректирует свой план и может повторно отправить его на рефлексию — процесс становится итеративным до достижения согласованности.

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

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

• Определённость рассуждений. Выходные данные и методология основного агента проверяются и уточняются другими агентами, что повышает достоверность и точность.
• Объяснимость. Несколько агентов могут предоставить разносторонние объяснения, почему тот или иной шаг считается корректным или ошибочным, что делает процесс более прозрачным.
• Инклюзивность. При участии нескольких агентов-рефлексии можно получить разнообразные точки зрения, что позволяет формировать более всесторонние и сбалансированные рекомендации.
• Масштабируемость. Система легко масштабируется: новых агентов-рефлексии можно добавлять без изменения архитектуры основного агента. Например, можно внедрить специализированного агента для проверки безопасности кода или соответствия требованиям GDPR.

Недостатки

• Зависимость от качества агентов-рефлексии. Общее качество системы напрямую зависит от компетентности и надёжности агентов, выполняющих рефлексию. Если они ошибаются, ошибки могут быть усугублены.
• Сохранение справедливости. При использовании нескольких агентов возникает вопрос: как взвешивать их мнения? Как избежать доминирования одной точки зрения? Это особенно важно при конфликте рекомендаций.
• Сложность установления ответственности. Если ошибка в плане привела к серьёзному сбою, трудно определить, кто виноват — основной агент, агент-рефлексия или система агрегации.
• Накладные расходы:
  • i) Коммуникационные издержки. Каждый вызов агента-рефлексии требует передачи данных, управления контекстом и ожидания ответа.
  • ii) Экономические издержки. Использование дополнительных агентов, особенно облачных LLM, увеличивает стоимость выполнения задачи.

Общий пример: мультиагентная система для автоматизации бизнес-задач

Сценарий: Автоматизация процесса подготовки отчётности.

• Основной агент (Planner): Получает задачу: «Подготовь ежемесячный финансовый отчёт за октябрь 2025 года».

• Формирует план:

  1. Извлечь данные из бухгалтерской системы.
  2. Преобразовать данные в формат CSV.
  3. Построить графики в Matplotlib.
  4. Сгенерировать PDF-отчёт.
  5. Отправить по email.

• Агент-рефлексии (Reviewer): Получает этот план и анализирует:

  • «Шаг 1: Указано "извлечь данные", но не указан источник. Требуется уточнение: API, база данных, файл?»
  • «Шаг 5: Отправка email требует проверки получателей и темы письма. Добавить шаг проверки конфиденциальности.»
  • «Не учтены возможные ошибки соединения с базой. Рекомендуется добавить механизм повторных попыток.»

• Основной агент обновляет план с учётом замечаний, используя инструмент update_plan:

  update_plan(
    steps=[
        "Уточнить источник данных у пользователя",
        "Подключиться к PostgreSQL с retry-логикой",
        "Экспортировать данные в CSV",
        "Построить графики",
        "Сгенерировать PDF с шаблоном",
        "Проверить список получателей",
        "Отправить email через SMTP"
    ],
    reason="Добавлены уточнения источника, обработка ошибок и проверка безопасности"
  )

Пример в разработке AI-агента для программирования (SWE Agent)

Сценарий: Написание Python-функции для парсинга JSON с валидацией.

• Агент-программист (Coder): Генерирует код:

  def parse_user_data(json_str):
    import json
    data = json.loads(json_str)
    return {
        'name': data['name'],
        'age': int(data['age'])
    }

• Агент-рефлексии (например Code Reviewer): Анализирует код и отправляет замечания:

  • «Отсутствует обработка исключений: json.JSONDecodeError, KeyError, ValueError.»
  • «Нет валидации возраста: должно быть в диапазоне 0–120.»
  • «Импорт внутри функции — плохая практика. Перенести наверх.»
  • «Рекомендуется добавить типизацию и docstring.»

• Агент-программист исправляет код:

  import json
  from typing import Dict, Optional
  
  def parse_user_data(json_str: str) -> Optional[Dict[str, any]]:
    """
    Парсит JSON со строкой данных пользователя.
    Возвращает словарь с полями name и age или None при ошибке.
    """
    try:
        data = json.loads(json_str)
        name = data.get('name')
        age = data.get('age')
  
        if not name or not isinstance(name, str):
            return None
        if not isinstance(age, (int, float)) or not (0 <= age <= 120):
            return None
  
        return {'name': name, 'age': int(age)}
    except (json.JSONDecodeError, TypeError):
        return None

• Затем может быть задействован агент-тестировщик (Tester), который генерирует тесты:

  def test_parse_user_data():
    assert parse_user_data('{"name": "Alice", "age": 25}') == {"name": "Alice", "age": 25}
    assert parse_user_data('{"name": "Bob", "age": 150}') is None
    assert parse_user_data('invalid json') is None

Архитектура взаимодействия:

• Основной агент (координатор) создаёт субагентов: Programmer, Reviewer, Tester.
• Каждый работает в своём контексте, возвращает краткий отчёт.
• Координатор интегрирует результаты, сохраняя общий контекст лёгким.
• Все действия сопровождаются аргументом reason для прослеживаемости.

Реализация инструмента reflect в Python

Для поддержки паттерна Cross-Reflection можно реализовать специальный инструмент reflect, который явно фиксирует внутренние размышления:

from typing import Callable, Awaitable

async def reflect(content: str, source_agent: str, target_agent: str) -> str:
    """
    Инструмент для записи внутренних размышлений или отзывов между агентами.
    Используется в мультиагентной системе для кросс-рефлексии.
    """
    # Сохраняем в общий журнал или передаём целевому агенту
    note = f"[REFLECT] From: {source_agent} | To: {target_agent}\n{content}"
    # Здесь может быть запись в файл, очередь или передача в другого агента
    print(note)
    return "Reflection logged."

Пример вызова:

await reflect(
    content="Функция parse_user_data требует обработки исключений и валидации входных данных.",
    source_agent="Reviewer",
    target_agent="Programmer"
)
# Вывод: [REFLECT] From: Reviewer | To: Programmer\nФункция parse_user_data требует...

Известные применения (Known Uses)

• XAgent: Агент-исполнитель (tool agent) отправляет обратную связь агенту-планировщику (plan agent), указывая, завершена ли задача или требуется доработка.
• Yao et al.: Агент-мыслитель (thinker) даёт рекомендации агенту-исполнителю (actor), помогая ему принимать более обоснованные решения.
• Qian et al.: Виртуальная компания по разработке ПО, где агенты-тестировщики находят баги и сообщают программистам.
• Talebirad и Nadiri: Исследование межагентной обратной связи, включающей критику, что помогает агентам адаптировать свои стратегии.

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

• Оптимизатор запросов/ответов (Prompt/Response Optimiser): Cross-Reflection может предоставлять обратную связь для улучшения промптов и структуры ответов.
• Сотрудничество на основе голосования, ролей или дебатов (Voting-based, Role-based, Debate-based Cooperation): Агенты-рефлексии могут работать в рамках этих схем, оценивая выводы основного агента.
• Реестр инструментов/агентов (Tool/Agent Registry): Основной агент может находить подходящих агентов-рефлексии через централизованный реестр, выбирая их по специализации (например, «security_reviewer», «code_style_checker»).

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

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

Паттерн "Рефлексия с участием человека" (Human Reflection)

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

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

Как обеспечить полное и правильное отражение предпочтений человека и их интеграцию в процесс рассуждений и сгенерированные планы?

Факторы

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

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

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

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

Недостатки

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

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

• Внутренний монолог. Внутренний монолог реализован в роботизированной системе, которая может разбивать инструкции пользователей на выполнимые шаги и использовать обратную связь от человека для распознавания объектов.
• Ma et al. исследуют процесс обсуждения между пользователями и агентами при принятии решений. Пользователи и агенты должны предоставлять соответствующие доказательства и аргументы в поддержку своих противоречащих друг другу мнений.
• Wang et al. интегрируют обратную связь от человека для агентов, чтобы отслеживать динамическую эволюцию интересов пользователей и, следовательно, предоставлять более точные рекомендации.

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

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

Пример: Система рекомендаций ресторанов в XAgent

В системе XAgent реализован инструмент AskForHumanHelp, который активно использует паттерн "Рефлексия с участием человека". Когда пользователь запросил рекомендации ресторанов для дружеской встречи, но не предоставил конкретных деталей, XAgent распознал недостаточность предоставленной информации. Агент автоматически активировал процесс рефлексии, запросив у пользователя следующие уточнения:

• Предпочтительное местоположение
• Бюджетные ограничения
• Кухня по предпочтению
• Диетические ограничения

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

Пример: Система поддержки принятия решений

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

1. Агент представляет план в виде интерактивной визуализации с пошаговым обоснованием
2. Бизнес-аналитик (человек) может отметить спорные моменты, запросить дополнительные данные или предложить альтернативные подходы
3. Агент-аналитик пересчитывает влияние предложенных изменений и представляет обновленный план
4. Процесс продолжается до тех пор, пока план не будет одобрен

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

Пример: XAgent для анализа данных Iris

https://github.com/OpenBMB/XAgent

В XAgent реализован пример использования паттерна "Рефлексия с участием человека" при анализе данных набора Iris. Когда пользователь предоставил файл iris.zip и запросил помощь в анализе данных, XAgent разбил задачу на подзадачи, включая проверку окружения Python на наличие необходимых библиотек для анализа данных.

Однако, при обнаружении, что пользователь не указал конкретные требования к визуализации, XAgent активировал процесс рефлексии:

1. Агент предложил несколько вариантов визуализации (гистограммы, scatter-plot матрица, box-plot)
2. Запросил у пользователя предпочтения по типу визуализации и детализации
3. Получив обратную связь, скорректировал план анализа
4. После выполнения анализа представил промежуточные результаты для проверки перед генерацией окончательного отчета

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

Пример: Мультиагентная система разработки ПО

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

1. Агент-аналитик преобразует исходное требование пользователя в техническое задание
2. Техническое задание представляется пользователю через интерфейс с возможностью комментирования каждого пункта
3. Пользователь может:
   • Указать недостающие функции
   • Уточнить приоритеты
   • Запросить изменения в интерфейсе
   • Указать потенциальные проблемы безопасности
4. Агент-архитектор на основе уточнений формирует архитектурный план и представляет его пользователю
5. При обнаружении пользователем несоответствия ожиданиям, процесс повторяется с корректировкой

Пример: Обучение модели BERT для анализа отзывов

В сценарии, где XAgent использовался для анализа отзывов о фильмах, паттерн "Рефлексия с участием человека" был реализован следующим образом:

1. XAgent инициировал процесс обучения модели BERT на наборе данных IMDB
2. Перед началом обучения агент запросил у пользователя уточнение:
   • Требуемая точность модели
   • Доступное время на обучение
   • Предпочтительный баланс между точностью и скоростью инференса
3. После первоначального обучения модель была протестирована на небольшом наборе данных
4. Результаты тестирования были представлены пользователю с рекомендациями по дообучению
5. Пользователь указал, что для его задачи важнее полнота (recall), чем точность (precision)
6. XAgent скорректировал параметры обучения и повторил процесс

Голосование как основа сотрудничества (Voting-based Cooperation)

Агенты могут свободно высказывать свои мнения и достигать консенсуса через сотрудничество на основе голосования.

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

Проблема: Как правильно окончательно принять решения агентов, чтобы обеспечить справедливость между разными агентами?

Факторы:

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

Рис. 12. Voting-based cooperation.

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

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

• Справедливость. Голосование может проводиться разными способами для обеспечения справедливости. Например, подсчет голосов для обеспечения равных прав агентов или распределение весов с учетом ролей агентов и т.д.
• Подотчетность. Общая процедура и окончательные результаты фиксируются в соответствующей системе голосования. Заинтересованные стороны могут отследить и определить агентов, ответственных за выбор определенных вариантов.
• Коллективный интеллект. Окончательные решения после голосования могут использовать сильные стороны нескольких агентов (например, комплексную базу знаний), поэтому они считаются более точными и надежными, чем те, которые генерируются одним агентом.

Недостатки:

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

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

• Hamilton использует девять агентов для моделирования суда, где агенты голосуют по поступающим делам. Каждое дело определяется преобладающим результатом голосования.
• ChatEval. Агенты могут достигать консенсуса по запросам пользователей через голосование, при этом результаты голосования могут суммироваться путем расчета большинства голосов или средней оценки.
• Yang et al. исследуют согласованность голосующих агентов на основе GPT-4 и LLaMA-2 и голосующих людей по 24 городским проектам. Результаты показывают, что агенты-голосующие склонны к единообразному выбору, в то время как люди имеют разнообразные предпочтения.
• Li et al. постепенно запрашивают основную модель для генерации N образцов и используют несколько агентов для выбора окончательного ответа через большинство голосов.

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

• Взаимная рефлексия (Cross-reflection). Агент может запросить у нескольких агентов обратную связь, которая может быть определена через сотрудничество на основе голосования между рефлексирующими агентами.
• Ролевое и дебатное сотрудничество (Role-based and debate-based cooperation). Сотрудничество на основе голосования можно рассматривать как альтернативу другим паттернам сотрудничества путем проведения голосования между агентами, хотя они могут применяться вместе для взаимного дополнения.
• Реестр инструментов/агентов (Tool/agent registry). Агенты, участвующие в процессе голосования, могут быть задействованы через реестр инструментов/агентов.

Пример: Система управления городскими проектами:

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

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

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

Генерация оптимального кода через коллективное принятие решений: При решении сложной задачи программирования (например, реализация алгоритма сортировки) несколько агентов генерируют различные варианты кода. Дополнительные агенты-эксперты оценивают каждый вариант по критериям эффективности, читаемости и соответствия стандартам, затем голосуют за лучшее решение. Процесс реализован через фреймворк LangChain с использованием Voting-Based Council Pattern, где результаты голосования суммируются как большинство голосов или средняя оценка. Такой подход позволяет использовать коллективный интеллект для создания более надежного кода, чем при использовании одного агента, и особенно полезен в сложных сценариях, где требуется баланс между различными качествами кода.

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

Паттерн Role-based Cooperation (Ролевое взаимодействие)

Агентам назначаются различные роли, а решения окончательно формируются в соответствии с их ролями.

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

Как агенты могут сотрудничать над определенными задачами с учетом их специализаций?

Факторы

• Разнообразие. Используемые агенты могут иметь различные мнения о том, как построить план или как выполнить задачу.
• Разделение труда. Поскольку агенты могут быть обучены на разных корпусах данных для различных целей, при выполнении задач следует учитывать их сильные стороны и экспертизу.
• Устойчивость к сбоям. Агенты могут быть недоступны во время сотрудничества, что повлияет на конечный результат задачи.

Рис. 13. Role-based cooperation.

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

Последствия

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

• Разделение труда. Агенты могут имитировать разделение труда в реальном мире в соответствии со своими ролями, что позволяет наблюдать социальные явления.
• Устойчивость к сбоям. Поскольку используются несколько агентов, система может продолжать работу, заменяя неактивных агентов другими агентами той же роли.
• Масштабируемость. В любое время могут быть задействованы или созданы агенты новых ролей для уточнения рабочего процесса задачи и расширения возможностей всей системы.
• Подотчетность. Подотчетность облегчается, поскольку обязанности агентов четко определены в отношении их ожидаемых ролей.

Недостатки:

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

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

• XAgent. XAgent состоит из трех основных частей: агент-планировщик для генерации задач, агент-диспетчер для назначения задач и агент-инструмент для выполнения задач.
• MetaGPT [58]. MetaGPT использует различные агенты, выступающие в разных ролях (например, архитектор, менеджер проекта, инженер) в стандартизированных операционных процедурах.
• MedAgents [59]. Агентам назначаются роли различных предметных экспертов (например, кардиология, хирургия, гастроэнтерология) для предоставления специализированного анализа и совместной работы над вопросами здравоохранения.
• Wang et al. [60] предлагают Mixture-of-Agents, где агенты-предложители предоставляют полезные эталонные ответы агентам-агрегаторам, а агенты-агрегаторы составлены в слои для синтеза и уточнения ответов.

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

• Перекрестная рефлексия. Агент может запросить несколько агентов для предоставления обратной связи, которая может быть определена через ролевое взаимодействие между рефлексивными агентами.
• Сотрудничество на основе голосования и дебатов. Ролевое взаимодействие может рассматриваться как альтернатива другим паттернам сотрудничества путем четкого назначения ролей агентам, которые затем будут работать и сотрудничать в соответствии с заданными ролями. В то же время эти паттерны могут применяться вместе, дополняя друг друга.
• Реестр инструментов/агентов. Агенты с разными ролями могут быть найдены и задействованы через реестр инструментов/агентов.

Примеры реализации

Примеры в общем домене

Медицинская диагностика с использованием MedAgents В системе MedAgents для комплексной диагностики пациента создаются агенты с ролями различных медицинских специалистов. Например:

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

Агент-координатор (agent-as-an-assigner) распределяет симптомы пациента между специализированными агентами, собирает их выводы и формирует комплексное заключение. Если выявляется редкое заболевание, для которого нет специализированного агента, агент-создатель генерирует нового агента с соответствующей экспертизой на основе медицинских баз знаний.

Управление городской инфраструктурой В умном городе агенты с ролями:

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

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

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

MetaGPT для разработки веб-приложения В системе MetaGPT при создании веб-приложения задействованы агенты с четкими ролями:

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

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

Система для автоматизации CI/CD процессов В современных мультиагентных системах программной инженерии можно выделить следующие роли:

• Агент-планировщик (agent-as-a-planner) анализирует требования и создает план развертывания
• Агент-сборщик (agent-as-a-worker) собирает проект и запускает тесты
• Агент-мониторинга отслеживает производительность после деплоя
• Агент-документатор автоматически обновляет техническую документацию

Эта система демонстрирует явное разделение ответственности, что соответствует принципам Role-Based Cooperation и позволяет легко масштабировать процесс разработки.

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