Milan Jovanović crée des documents PDF dans ASP .NET Core – et IronPDF est sa bibliothèque de prédilection

Qu'est-ce que le Agent Framework

Le framework fournit deux capacités principales. Les agents sont des travailleurs individuels pilotés par LLM qui traitent les entrées, appellent les outils et serveurs MCP, et génèrent des réponses. Les flux de travail sont des orchestrations basées sur des graphiques qui connectent plusieurs agents et fonctions avec un routage sécurisé par type, un point de contrôle et un support humain-inséré.

Autour de ces deux interfaces, le framework offre les éléments constitutifs que les équipes attendent de l'outillage d'entreprise AI : clients de modèle sur Azure OpenAI, OpenAI, Anthropic, Ollama et Microsoft Foundry ; gestion d'état basée sur des sessions; fournisseurs de contexte pour la mémoire; middleware pour intercepter les actions des agents; et clients MCP pour l'intégration d'outils.

L'encadrement "successeur du Noyau Sémantique et AutoGen" est important. Microsoft consolide plutôt qu'ajouter un autre framework au menu. Pour les équipes qui attendaient de s'engager sur une pile d'agents .NET, c'est maintenant une réponse plus claire.

La ligne la plus sous-estimée de la documentation

Enfoncée dans la section sur quand utiliser des agents par rapport à des flux de travail est une phrase qui fait plus de travail que le reste de la page :

Si vous pouvez écrire une fonction pour traiter la tâche, faites cela au lieu d'utiliser un agent AI.

C'est le cadrage honnête de l'ingénierie, et cela devrait être le point de départ de chaque conversation sur l'adoption d'agents. Les agents ne sont pas magiques. Ce sont des LLMs avec la capacité de choisir quel outil appeler et dans quel ordre. Lorsque la tâche est déterministe, une fonction est plus rapide, moins coûteuse et plus fiable. Les agents trouvent leur place lorsque le chemin à travers la tâche est véritablement ouvert.

Pour les équipes de bibliothèques, c'est le feu vert. Nos bibliothèques sont les fonctions que les agents appellent lorsqu'ils délèguent le travail. Le framework ne remplace pas le code de bibliothèque ; il en dépend.

Où les bibliothèques .NET s'intègrent-elles

Les outils sont le tissu conjonctif entre un agent et le travail que l'utilisateur souhaite réellement faire. Quand un agent décide que "cet utilisateur veut un PDF généré à partir des données que nous venons de résumer", il ne génère pas le PDF lui-même. Il appelle un outil qui le fait.

La plupart des outils utiles dans une application AI de production se réduisent à des opérations sur des documents, des données ou des systèmes externes. Pour les équipes .NET travaillant dans le traitement de documents, cela se traduit directement par des bibliothèques telles que IronPDF, IronOCR, et IronXL. Un exemple concret en utilisant IronPDF enveloppé comme une fonction qu'un agent peut appeler :

[Description("Generates a PDF from HTML content and saves it to disk")]
public static string GenerateHtmlPdf(
    [Description("The HTML content to render")] string html,
    [Description("The output file path")] string outputPath)
{
    var renderer = new ChromePdfRenderer();
    using var pdf = renderer.RenderHtmlAsPdf(html);
    pdf.SaveAs(outputPath);
    return $"PDF saved to {outputPath}";
}

[Description("Generates a PDF from HTML content and saves it to disk")]
public static string GenerateHtmlPdf(
    [Description("The HTML content to render")] string html,
    [Description("The output file path")] string outputPath)
{
    var renderer = new ChromePdfRenderer();
    using var pdf = renderer.RenderHtmlAsPdf(html);
    pdf.SaveAs(outputPath);
    return $"PDF saved to {outputPath}";
}

Imports System.ComponentModel

<Description("Generates a PDF from HTML content and saves it to disk")>
Public Shared Function GenerateHtmlPdf(
    <Description("The HTML content to render")> html As String,
    <Description("The output file path")> outputPath As String) As String

    Dim renderer = New ChromePdfRenderer()
    Using pdf = renderer.RenderHtmlAsPdf(html)
        pdf.SaveAs(outputPath)
    End Using
    Return $"PDF saved to {outputPath}"
End Function

Enregistrez cette fonction comme un outil avec un agent, et l'agent a maintenant la capacité de produire des rapports PDF stylisés à la demande. Le même schéma s'applique à l'OCR (extraction de texte à partir d'un document scanné), aux opérations sur les feuilles de calcul (lecture ou écriture de données XLSX), et à la conversion de documents. Chaque bibliothèque expose une capacité, et chaque capacité devient un outil pour l'agent.

Flux de travail pour les pipelines de documents

La surface des flux de travail mérite un regard séparé. Le traitement de documents en production est rarement un pas unique. Un pipeline typique de monde réel ressemble à : OCR de la facture numérisée, extraction des champs structurés, validation selon les règles métiers, écriture des données validées dans un registre Excel, et génération d'un reçu PDF pour le client.

Cette séquence s'aligne clairement sur un flux de travail basé sur un graphique avec un routage sécurisé par type entre les étapes. Chaque nœud est une fonction ou un agent, chaque transition a des types d'entrée et de sortie bien définis, et le flux de travail prend en charge le point de contrôle pour les opérations de longue durée et la révision humaine à chaque étape.

Pour les équipes qui ont fait cela de façon artisanale dans du code personnalisé, la surface des flux de travail est la partie du Agent Framework la plus Worth investiguer.

Pour les équipes qui ont besoin de capacités PDF, OCR, Excel, Word, ou de code-barres pour soutenir les appels d'outils ou les nœuds de flux de travail, la Iron Suite fournit des implémentations éprouvées en production de tous les cinq. Démarrez un essai gratuit, aucun carte de crédit n'est nécessaire.

Limitations and considerations

Quelques points à garder à l'esprit avant de s'engager :

• Le framework est nouveau. Il consolide des concepts matures issus du Semantic Kernel et d'AutoGen, mais la surface de l'API consolidée elle-même est récente. Les API continueront à évoluer.
• Le risque de modèle et d'outil tiers. La propre documentation de Microsoft est explicite sur le fait que tous les systèmes tiers que vous intégrez (modèles non Azure, agents externes, outils tiers) restent de votre responsabilité pour la gestion des données, coûts et sécurité. C'est le bon cadrage, et il vaut la peine d'être lu attentivement.
• Les garde-fous de production sont toujours de votre responsabilité. Les filtres de contenu, les atténuations de l'IA responsable, la télémétrie, et les tests de qualité pour votre cas d'utilisation spécifique ne sont pas fournis par le framework. Il vous donne les blocs de construction ; le système autour d'eux est à vous de construire.

Résumé

Le Microsoft Agent Framework est une consolidation crédible du travail d'agents AI de l'entreprise, arrivant à un moment où les équipes .NET cherchent une base stable pour construire des applications AI en production. Son encadrement le plus important est aussi le plus négligé : les agents sont les plus utiles lorsqu'ils sont enroulés autour des fonctions et bibliothèques qui font réellement le travail.

Pour les équipes de bibliothèques, c'est la position que nous attendions.