MICROSOFT AGENT FRAMEWORK · 0.16.0-rc.1
Code, workflow et agent
Décider où une règle suffit et où une interprétation devient utile, avec Demo010.
Objectifs
- Justifier le choix entre règle, procédure et agent.
- Expliquer les quatre couches et la responsabilité de l’hôte.
- Observer une limite du classement déterministe et de la réponse du modèle.
Choisir avant d’appeler un modèle
Un écran reçoit une demande de support. Faut-il exécuter une règle, suivre une procédure ou demander une interprétation ? La présence de langage naturel ne tranche pas cette question. Le choix dépend du résultat attendu et de la part d’incertitude que l’application peut accepter.
EP002 pose ce problème d’architecture avant de présenter une API. Nous conservons cette progression : caractériser le besoin, choisir une frontière de responsabilité, puis observer le programme. Les introductions du cours J1 apportent un second repère : une réponse de modèle appartient à un système logiciel qui gère configuration, état, outils et effets.
Trois besoins, trois choix à justifier
| Besoin | Choix initial | Preuve et limite |
|---|---|---|
| Calculer une remise fixe | Fonction C# | Vérifier la formule et les cas limites. Un modèle ajoute une réponse variable à une règle déjà connue. |
| Qualifier puis router un incident | Procédure explicite ou workflow | Vérifier transitions, refus et traces. Plusieurs étapes ne suffisent pas à justifier un agent. |
| Clarifier une panne ambiguë | Agent dans une branche contrôlée | Évaluer la pertinence des questions. Une formulation convaincante ne prouve pas la résolution. |
Un workflow décrit des étapes et des transitions connues. Il peut inclure un appel de modèle sans céder à celui-ci le contrôle des autorisations. Un agent devient intéressant quand une interprétation ou un dialogue apporte une valeur mesurable. Ce sont des composants qui peuvent coexister dans la même application.
- Décrire le résultat et ses critères d’acceptation.
- Si la règle est calculable, l’exprimer directement en code.
- Si les transitions sont connues, rendre la procédure explicite.
- Si une interprétation reste nécessaire, borner l’appel du modèle et contrôler sa sortie.
Le routeur d’architecture d’EP002 illustrait ce jugement. Dans Demo010 actuel, il n’existe pas de routeur général à trois branches : le code contient un calcul, un branchement sur Login et une option --agent. Le choix architectural reste la responsabilité du concepteur ; ce programme ne sait pas choisir une architecture pour une demande arbitraire.
Lire Demo010 ligne par ligne
Console.WriteLine("Deterministic C#: a fixed discount rule returns " + (100m * 0.9m));
var request = "Login fails for a known account";
var component = request.Contains("Login", StringComparison.OrdinalIgnoreCase) ? "Auth" : "Other";
Console.WriteLine($"Explicit C# orchestration: classify -> route -> display. Component: {component}. This is not a MAF workflow graph.");
if (!args.Contains("--agent")) return;
Code source · Demo010 · Dossier
Le calcul 100m × 0.9m applique une remise fixe de dix pour cent et conserve un résultat décimal. Le montant, le taux et l’absence de règle d’arrondi constituent les hypothèses de cet exemple. Le scénario filmé parlait d’une commande de 1 200 euros et d’un client Gold ; ce n’est plus le comportement du fichier actuel.
Contains recherche Login sans tenir compte de la casse. Une occurrence donne Auth ; toute autre chaîne donne Other. Il s’agit d’un classement par sous-chaîne, pas d’une compréhension de l’incident. Une phrase contenant Login dans une négation reçoit elle aussi Auth ; une panne d’authentification formulée sans ce mot reçoit Other.
Le message classify → route → display décrit une orchestration C# ordinaire. Aucun graphe MAF, arrêt durable, reprise ni validation humaine n’est créé ici. Demo230 sera le point de comparaison avec un workflow typé ; sa fiche n’est pas encore rédigée dans cet aperçu.
L’instruction return arrête le programme avant le chargement de DemoSettings si --agent est absent. Avec ce drapeau, DemoConnection construit le client, AsAIAgent fournit le runtime et RunAsync reçoit une demande de deux questions de clarification. Aucun outil métier ni accès en écriture n’est exposé à cet agent.
- Application hôte : arguments, délai de deux minutes et annulation.
- Runtime MAF : instructions de l’agent et exécution RunAsync.
- Abstraction IChatClient de Microsoft.Extensions.AI : échange avec le client.
- Fournisseur configuré par DemoConnection : inférence locale ou distante selon le profil.
Manipuler puis expliquer ce qui est observé
Ouvrir une distribution complète de BaseTechnique : le dossier de la démo seul ne suffit pas. Depuis sa racine, employer le SDK fixé dans global.json. Après la compilation Release, lancer la commande sans modèle de la fiche. Vérifier les deux messages et la fin du processus avant toute variante optionnelle.
Exercice de décision : classer une remise contractuelle fixe, une procédure de support connue et une demande de diagnostic incomplète. Pour chaque cas, écrire le résultat vérifiable, la responsabilité de l’hôte et la raison éventuelle d’un appel de modèle. Réponse attendue : calcul direct pour la remise ; transitions explicites pour la procédure ; questions proposées puis évaluées pour le diagnostic.
Dans une copie de travail du code, remplacer la demande par « Authentication fails » puis par « Login is not the problem ». Prévoir Other puis Auth avant l’exécution. Le classement reste cohérent avec Contains, mais peut être inadapté au besoin métier. Ce contre-exemple sépare un test du programme d’une qualification de son utilité.
Coût, contrôle et limites de la comparaison
Un modèle local évite éventuellement une facturation par requête ; il consomme toujours calcul, mémoire et temps. Sa latence et sa qualité dépendent du poste et du modèle. L’ancien « coût nul » et la fiabilité générale de granite4:3b ne sont donc pas retenus comme garanties. La configuration par défaut n’est pas une qualification indépendante.
Une même application peut garder ses calculs en C#, orchestrer une procédure connue et appeler un agent à un endroit précis. Définir alors délais, annulation, traces et contrôles de sortie. Demo010 montre une frontière minimale avec un délai global et sans outil ; il ne démontre ni persistance, ni idempotence, ni autorisation de production.
Avant de retenir un agent, définir un jeu de cas représentatifs, les erreurs acceptables et une comparaison avec la solution explicite. Observer coût, latence et utilité des réponses. Les tests de fabrication du site n’exécutent pas le modèle et ne fournissent aucune mesure de ces qualités.
Révision des sources et suite du parcours
Adaptation d’EP002 : introduction et trois besoins (body:4–11), cas déterministe et procédure (body:12–21), agent contrôlé et décision (body:22–34). Les appels au spectateur, RUN 1–3, minutages et menu de tournage ont été retirés. Les introductions J1 (body:18–32) sont corrigées pour distinguer application, runtime, client et fournisseur. Le détail des correspondances reste dans le registre éditorial privé.
Lire la fiche Demo010 pour les commandes et les résultats observables, puis poursuivre avec Connexion et capacités. L’exercice Actionability compare une analyse valide à une action encore bloquée.
Le démarrage de Demo020 ci-dessous charge les réglages, enregistre les services et construit le host sans appeler le modèle. Sa fiche décrit séparément console, embeddings et backend.
var builder = Host.CreateApplicationBuilder();
builder.Configuration.AddDemoConfiguration(args);
var settings = ConnectionOptions.FromConfiguration(builder.Configuration);
builder.Services.AddDemoConnection(settings);
using var host = builder.Build();
Prérequis
Pour poursuivre
Précédent
Suivant