Actuellement, l’un des principaux obstacles à la réalisation du plein potentiel des
agents d’IA réside dans leur incapacité à communiquer et à collaborer efficacement entre eux.
L’intégration des différents outils et plateformes au sein de l’écosystème de l’IA reste un processus précaire, complexe et souvent artisanal, caractérisé par un manque de standardisation et d’automatisation
Orchestration et coordination
À mesure que les systèmes d'IA prennent de l'ampleur, ils intègrent souvent de nombreux agents dotés de capacités diverses. Il devient de plus en plus difficile de gérer ces interactions et de s'assurer qu'elles fonctionnent harmonieusement.
Les cadres d'agents offrent un environnement structuré qui permet d'orchestrer les activités des agents, de définir leurs rôles et responsabilités et d'améliorer la communication.
Modularité et réutilisation
Les cadres d'agents favorisent une approche modulaire du développement de l'IA, où les agents sont conçus et mis en œuvre comme des composants indépendants. Cette modularité permet une meilleure organisation du code et la réutilisation des modules d'agents dans différents projet
Design patterns
Gateway
MCP
un researcher (web search) et un coder (code interpreter),
agrège leurs outputs, et décide de poursuivre ou terminer.
L’agent dispose alors d’une URL REST publique (avec
authentification), metrics Azure Monitor (latence, erreurs,
tokens), logs Application Insights, et auto-scaling basé sur la
charge.
Guardrails et Responsible AI
Microsoft annonce des fonctionnalités de Responsible AI en
intégration : task adherence (vérifier que l’agent reste dans
son rôle), prompt shields (détecter les injections), PII detec-
tion (masquer données sensibles). Ces guardrails s’appli-
quent via IntelligenceOptions ou policies Azure AI Foundry.
Memory et State Management
Les agents peuvent maintenir une mémoire conversationnelle
via les threads persistants. En Python, agent.get_new_thread() crée
un contexte isolé. À l’inverse, la réutilisation d’un thread exis-
tant facilite le traitement des questions de suivi (follow-up
questions). Azure AI agents stockent ces threads côté cloud,
tandis que Semantic Kernel s’appuyait sur des threads locaux.
Avec Agent Framework, le comportement est désormais uni-
formisé : les threads locaux sont utilisés par défaut, avec une
option de stockage cloud disponible via AzureAIAgentThread.
Observabilité avec OpenTelemetry
Agent Framework se base sur des traces OpenTelemetry à
chaque appel d’agent, tool call et workflow step. Les dévelop-
peurs connectent Azure Monitor ou Grafana pour visualiser
latence, tokens consommés, erreurs. Exemple minimal :
await foreach (WorkflowEvent evt in run.WatchStreamAsync())
{
if (evt is AgentRunUpdateEvent e)
Console.WriteLine($”{e.Update.AuthorName}: {e.Update.Text}”);
}
Déploiement sur Azure AI Foundry
Le workflow typique : développer localement avec OpenAI/Azure
OpenAI, tester avec uv run python my_agent.py, puis déployer sur
Azure AI Foundry. Les agents deviennent des ressources
cloud avec endpoints REST, gestion des versions, scaling
automatique. Les samples AzureAIFoundry/Step01_Basics démon-
trent la création d’agents cloud via PersistentAgentsClient.
Le support OpenAPI permet d’enregistrer des API tierces
comme outils : spécification OpenAPI génération automa-
tique de fonctions typées appel transparent par l’agent. Le
sample openai_assistant/02_code_interpreter montre l’intégration de
code interpreter hosted (exécution Python cloud-side).
Pour déployer un agent local vers Azure :
var azureClient = AzureAIAgent.CreateAgentsClient(
azureEndpoint,
new AzureCliCredential()
);
PersistentAgent definition = await azureClient.Administration.CreateAgentAsync(
deploymentName: “gpt-4o”,
name: “CustomerSupport”,
instructions: “Vous êtes un assistant de support client”,
tools: toolDefinitions
);
AzureAIAgent cloudAgent = new(definition, azureClient);
80
Bonnes pratiques et patterns de développement
L’expérience cumulée de Semantic Kernel et AutoGen a cris-
tallisé des patterns reproductibles. Microsoft documente ces
best practices dans le guide utilisateur.
Principe de responsabilité unique : un agent = une tâche.
Éviter les agents “couteau suisse” avec 20 outils. Préférer
composer des workflows d’agents spécialisés. Exemple :
séparer SentimentAnalyzer, ContentModerator, ResponseGenerator plutôt
qu’un SocialMediaAgent monolithique.
Instructions claires et testables : les instructions sont le
contrat de l’agent. Spécifier format, contraintes, ton.
Exemple : “Vous êtes un assistant juridique. Répondez uni-
quement aux questions sur le droit français. Si autre pays,
répondez ‘Je ne traite que le droit français’. Max 200 mots.
Citez toujours l’article de loi.”
Gestion d’erreurs explicite : les tool calls peuvent échouer.
Envelopper les outils dans try/catch avec messages structurés :
@ai_function(name=”check_stock”, description=”Vérifier disponibilité produit”)
async def check_stock(product_id: str) -> str:
try:
result = await inventory_api.get(product_id)
return f”Stock disponible: {result.quantity} unités”
except APITimeout:
return “Service indisponible, réessayez dans 30 secondes”
except ProductNotFound:
return f”Produit {product_id} introuvable”
Observabilité dès le début : intégrer OpenTelemetry traces
dès le développement local avec custom spans pour les
étapes critiques.
Testing multi-niveaux : unit tests pour outils (mocks des API),
integration tests pour agents, end-to-end tests pour workflows
validant handoffs et événements.
Versioning des agents : Azure AI Foundry supporte le versio-
ning. Créer CustomerSupport_v2, tester en parallèle de v1, basculer
progressivement (canary deployment).
Sécurité et conformité : appliquer le principe du moindre pri-
vilège, utiliser Managed Identity Azure, chiffrer secrets avec
Key Vault. Les guardrails PII detection (preview) masquent
automatiquement emails/numéros de carte dans les logs.
Ces patterns, hérités de 3 ans de Semantic Kernel en produc-
tion et 2 ans d’AutoGen en recherche, donnent à Agent
Framework une maturité opérationnelle.
Cas d’usage et adoption :
de la théorie à la pratique
Les exemples d’Arafat Tehsin illustrent la polyvalence du fra-
mework. Invoice status checking : un agent répond à
“Where is my invoice #12345?” en appelant une
fonction check_invoice_status(invoice_id) et retournant le
statut. Payment approval workflow : un workflow séquentiel
avec agent validator approver notifier, chacun avec outils
dédiés (database query, email send).
No comments:
Post a Comment