Обзор архитектуры агента

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

Цели

Agent Framework был разработан с учетом следующих ключевых приоритетов:

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

Агент

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

Здесь Agent базовую абстракцию семантического ядра.

Здесь Agent базовую абстракцию семантического ядра.

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

Типы агентов в семантическом ядре

• ChatCompletionAgent
• OpenAIAssistantAgent
• AzureAIAgent
• OpenAIResponsesAgent
• CopilotStudioAgent

Нить агента

Абстрактный AgentThread класс служит основной абстракцией для потоков или состояния беседы. Он упрощает различные способы управления состоянием разговора для разных агентов.

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

Состояние-следящие агенты обычно работают исключительно с соответствующей реализацией AgentThread, в то время как другие типы агентов могут работать с несколькими типами AgentThread одновременно. Например, для AzureAIAgent требуется соответствующий AzureAIAgentThread. Это связано с тем, что служба агента ИИ Azure хранит беседы в службе и требует определенных вызовов сервисных функций для создания потока и его обновления. Если используется другой тип потока агента с AzureAIAgent, мы быстро завершаем выполнение из-за непредвиденного типа потока и создаём исключение, чтобы уведомить вызывающий объект.

Управление агентами

Это важно

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

Замечание

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

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

• Шаблоны оркестрации: Предварительно созданные шаблоны, такие как Параллельные, Последовательные, Handoff, Group Chat и Magentic, позволяют разработчикам выбирать наиболее подходящую модель совместной работы для своего сценария. Каждый шаблон определяет другой способ взаимодействия агентов и обработки задач (см. таблицу шаблонов оркестрации для получения подробных сведений ).
• Логика преобразования данных: Преобразования входных и выходных данных позволяют потокам оркестрации адаптировать данные между агентами и внешними системами, поддерживая как простые, так и сложные типы данных.
• Human-in-the-loop: Некоторые шаблоны поддерживают принцип "человек в цикле", позволяя сотрудникам участвовать в процессе оркестрации. Это особенно полезно для сценариев, когда требуется человеческое решение или опыт.

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

Совмещение агента с функциями семантического ядра

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

Подключаемые модули и вызовы функций

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

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

Сообщения агента

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

Подсказка

Справочник по API:

• ChatHistory
• ChatMessageContent
• KernelContent
• StreamingKernelContent
• FileReferenceContent
• AnnotationContent

Подсказка

Справочник по API:

• chat_history
• chat_message_content
• kernel_content
• streaming_chat_message_content
• file_reference_content
• annotation_content

Подсказка

Справочник по API:

• ChatHistory
• ChatMessageContent
• KernelContent
• StreamingKernelContent

Шаблонирование

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

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

Дополнительные сведения о создании агента с помощью шаблона семантического ядра см. здесь.

Декларативная спецификация

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

Это важно

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

Регистрация типов пользовательских агентов

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

Чтобы зарегистрировать пользовательский тип агента, используйте @register_agent_type декоратор:

from semantic_kernel.agents import register_agent_type, Agent, DeclarativeSpecMixin

@register_agent_type("custom_agent")
class CustomAgent(DeclarativeSpecMixin, Agent):
    ...

Строка, предоставленная декоратору (например, "custom_agent") должна соответствовать типу: поле в спецификации YAML.

После регистрации настраиваемого агента можно инстанцировать с помощью декларативного шаблона, например через AgentRegistry.create_from_yaml(...).

Добавляет DeclarativeSpecMixin поддержку таких методов, как from_yaml, from_dictи resolve_placeholders, что позволяет агенту создаваться из спецификации YAML или словаря:

@classmethod
async def from_yaml(cls, yaml_str: str, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, extras=None, **kwargs):
    # Resolves placeholders and loads YAML, then delegates to from_dict.
    ...

@classmethod
async def from_dict(cls, data: dict, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, **kwargs):
    # Normalizes and passes spec fields to _from_dict.
    ...

@classmethod
@abstractmethod
async def _from_dict(cls, data: dict, *, kernel, prompt_template_config=None, **kwargs):
    # Subclasses implement this to create the agent from a dict.
    ...

@classmethod
def resolve_placeholders(cls, yaml_str: str, settings=None, extras=None) -> str:
    # Optional: override this to customize how environment or runtime placeholders are resolved in YAML.
    return yaml_str

Подсказка

Любой пользовательский агент должен наследовать от DeclarativeSpecMixin, чтобы обеспечить возможность построения на основе YAML, и должен быть зарегистрирован в реестре с помощью @register_agent_type.

Эта функция недоступна.

Дальнейшие шаги

Изучение API вызова общего агента