Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article aborde les concepts clés de l’architecture de l’Infrastructure de l’agent, notamment les principes fondamentaux, les objectifs de conception et les objectifs stratégiques.
Objectifs
Le Agent Framework a été élaboré avec les principales priorités suivantes à l’esprit :
- L’infrastructure de l’agent de noyau sémantique sert de base pour l’implémentation des fonctionnalités de l’agent.
- Plusieurs agents de différents types peuvent collaborer au sein d’une conversation unique, chacun contribuant à ses fonctionnalités uniques, tout en intégrant l’entrée humaine.
- Un agent peut participer et gérer plusieurs conversations simultanées simultanément.
Agent
La classe Agent abstraite sert d’abstraction principale pour tous les types d’agents, fournissant une structure fondamentale qui peut être étendue pour créer des agents plus spécialisés. Cette classe de base constitue la base des implémentations d’agents plus spécifiques, qui tirent parti des fonctionnalités du noyau pour exécuter leurs fonctions respectives. Consultez tous les types d’agents disponibles dans la section Types d’agents .
L’abstraction de noyau Agent sémantique sous-jacente est disponible ici.
L’abstraction de noyau Agent sémantique sous-jacente est disponible ici.
Les agents peuvent être appelés directement pour effectuer des tâches ou être orchestrés par différents modèles. Cette structure flexible permet aux agents de s’adapter à différents scénarios conversationnels ou pilotés par des tâches, fournissant aux développeurs des outils robustes pour créer des systèmes intelligents et multi-agents.
Types d’agent dans le noyau sémantique
Thread d’agent
La classe AgentThread abstraite sert d’abstraction principale pour les threads ou l’état de conversation. Il masque les différentes façons dont l’état de conversation peut être géré pour les différents agents.
Les services d’agent avec état stockent souvent l’état de conversation dans le service et vous pouvez interagir avec lui via un ID. D’autres agents peuvent exiger que l’intégralité de l’historique des conversations soit transmise à l’agent sur chaque appel, auquel cas l’état de conversation est géré localement dans l’application.
Les agents avec état fonctionnent généralement uniquement avec une implémentation de AgentThread correspondante, tandis que d’autres types d’agents peuvent fonctionner avec plusieurs types de AgentThread. Par exemple, AzureAIAgent nécessite une AzureAIAgentThreadcorrespondante. Cela est dû au fait que le service Azure AI Agent stocke les conversations dans le service et nécessite des appels de service spécifiques pour créer un thread et le mettre à jour. Si un autre type de thread d’agent est utilisé avec AzureAIAgent, nous détectons rapidement une erreur due à un type de thread inattendu et déclenchons une exception pour alerter l’appelant.
Orchestration de l’agent
Important
Les fonctionnalités d’orchestration d’agent dans l’infrastructure d’agent sont à l’étape expérimentale. Ils sont en cours de développement actif et peuvent changer considérablement avant de passer à la phase de version préliminaire ou de candidat à la version finale.
Remarque
Si vous utilisez le AgentGroupChat modèle d’orchestration, notez qu’il n’est plus conservé. Nous recommandons aux développeurs d’utiliser le nouveau GroupChatOrchestration modèle. Un guide de migration est fourni ici.
L’infrastructure d’orchestration de l’agent dans le noyau sémantique permet la coordination de plusieurs agents pour résoudre des tâches complexes en collaboration. Il fournit une structure flexible pour définir la façon dont les agents interagissent, partagent des informations et délèguent des responsabilités. Les principaux composants et concepts sont les suivants :
- Modèles d’orchestration : Les modèles prédéfini tels que Concurrent, Séquentiel, Handoff, Group Chat et Magentic permettent aux développeurs de choisir le modèle de collaboration le plus approprié pour leur scénario. Chaque modèle définit une façon différente pour les agents de communiquer et de traiter les tâches (consultez le tableau des modèles d’orchestration pour plus d’informations).
- Logique de transformation de données : Les transformations d’entrée et de sortie permettent aux flux d’orchestration d’adapter les données entre les agents et les systèmes externes, prenant en charge les types de données simples et complexes.
- Human-in-the-loop : Certains modèles prennent en charge human-in-the-loop, ce qui permet aux agents humains de participer au processus d’orchestration. Cela est particulièrement utile pour les scénarios où le jugement humain ou l’expertise est nécessaire.
Cette architecture permet aux développeurs de créer des systèmes intelligents et multi-agents capables de résoudre des problèmes réels par le biais de la collaboration, de la spécialisation et de la coordination dynamique.
Alignement de l’agent avec les fonctionnalités du noyau sémantique
Le Agent Framework est bâti sur les concepts fondamentaux et les fonctionnalités que de nombreux développeurs ont appris à connaître dans l’écosystème du Noyau Sémantique. Ces principes fondamentaux servent d'éléments constitutifs pour la conception du Cadre de l'agent. En tirant parti de la structure et des fonctionnalités familières du noyau sémantique, Agent Framework étend ses fonctionnalités pour permettre des comportements d’agent plus avancés et autonomes, tout en conservant la cohérence avec l’architecture de noyau sémantique plus large. Cela garantit une transition fluide pour les développeurs, ce qui leur permet d’appliquer leurs connaissances existantes pour créer des agents intelligents et adaptables au sein de l’infrastructure.
Plug-ins et appel de fonction
Les plug-ins constituent un aspect fondamental du noyau sémantique, ce qui permet aux développeurs d’intégrer des fonctionnalités personnalisées et d’étendre les fonctionnalités d’une application IA. Ces plug-ins offrent un moyen flexible d’incorporer des fonctionnalités spécialisées ou une logique propre à l’entreprise dans les flux de travail IA de base. En outre, les capacités des agents au sein de l’infrastructure peuvent être considérablement améliorées grâce à l'utilisation des plug-ins et de l'appel de fonction. Cela permet aux agents d’interagir dynamiquement avec des services externes ou d’exécuter des tâches complexes, en développant davantage l’étendue et la polyvalence du système IA au sein de diverses applications.
Découvrez comment configurer des agents pour utiliser des plug-ins ici.
Messages de l’agent
La messagerie de l’agent, y compris les entrées et les réponses, repose sur les principaux types de contenu du noyau sémantique, fournissant une structure unifiée pour la communication. Ce choix de conception simplifie le processus de transition des modèles d’achèvement de conversation traditionnels aux modèles pilotés par les agents plus avancés dans le développement de votre application. En tirant parti des types de contenu de noyau sémantique familiers, les développeurs peuvent intégrer en toute transparence les fonctionnalités de l’agent dans leurs applications sans avoir à réviser les systèmes existants. Cette rationalisation garantit que, à mesure que vous évoluez de l’IA conversationnelle de base vers des agents plus autonomes et orientés tâches, le framework sous-jacent reste cohérent, ce qui rend le développement plus rapide et plus efficace.
Conseil / Astuce
Informations de référence sur l’API :
Conseil / Astuce
Informations de référence sur l’API :
Conseil / Astuce
Informations de référence sur l’API :
Création de modèles
Le rôle d’un agent est principalement mis en forme par les instructions qu’il reçoit, ce qui détermine son comportement et ses actions. À l'instar de l'appel d'un Kernelprompt, les instructions d'un agent peuvent inclure des paramètres de modèle (à la fois des valeurs et des fonctions) qui sont substitués dynamiquement pendant l'exécution. Cela permet des réponses flexibles et contextuelles, ce qui permet à l’agent d’ajuster sa sortie en fonction de l’entrée en temps réel.
En outre, un agent peut être configuré directement à l’aide d’une configuration de modèle d’invite, fournissant aux développeurs un moyen structuré et réutilisable de définir son comportement. Cette approche offre un outil puissant pour la normalisation et la personnalisation des instructions de l’agent, garantissant ainsi la cohérence entre différents cas d’usage tout en conservant l’adaptabilité dynamique.
En savoir plus sur la création d’un agent avec le modèle de noyau sémantique ici.
Spécification déclarative
La documentation sur l’utilisation de spécifications déclaratives sera bientôt disponible.
Important
Cette fonctionnalité est à l’étape expérimentale. Les fonctionnalités à ce stade sont en cours de développement et soumises à des modifications avant de passer à la phase de préversion ou de version candidate.
Inscription de types d’agents personnalisés
Pour utiliser un agent personnalisé avec le système de spécification YAML déclaratif, vous devez d’abord inscrire votre classe d’agent auprès du registre de l’agent. Cela est nécessaire pour que l’agent AgentRegistry puisse reconnaître et construire votre agent lors de l’analyse du type: champ dans la spécification YAML.
Pour inscrire un type d’agent personnalisé, utilisez le décorateur @register_agent_type.
from semantic_kernel.agents import register_agent_type, Agent, DeclarativeSpecMixin
@register_agent_type("custom_agent")
class CustomAgent(DeclarativeSpecMixin, Agent):
...
La chaîne fournie au décorateur (par exemple) "custom_agent"doit correspondre au type : champ dans votre spécification YAML.
Une fois inscrit, votre agent personnalisé peut être instancié à l’aide du modèle déclaratif, par exemple via AgentRegistry.create_from_yaml(...).
La DeclarativeSpecMixin ajoute le support de méthodes telles que from_yaml, from_dict, et resolve_placeholders, qui permettent à votre agent d’être construit à partir d’une spécification YAML ou d’un dictionnaire.
@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
Conseil / Astuce
Tout agent personnalisé doit hériter de DeclarativeSpecMixin pour activer la construction basée sur YAML et doit être inscrit auprès du registre à l'aide de @register_agent_type.
Cette fonctionnalité n’est pas disponible.