BRANCHENMELDUNGEN

Milan Jovanović erstellt PDF-Dokumente in ASP.NET .NET Core – und IronPDF ist seine bevorzugte Bibliothek.

Aktualisiert:

Microsoft hat das Agent Framework als direkten Nachfolger von Semantic Kernel und AutoGen veröffentlicht und konsolidiert damit die Agentenaufbauarbeiten, die sich über die AI-Werkzeuge des Unternehmens angesammelt haben. Für Teams, die .NET-Bibliotheken aufbauen, was wir bei Iron Software tun, ist diese Veröffentlichung einen genauen Blick wert. Agenten-Frameworks geben LLMs im Wesentlichen die Fähigkeit, Werkzeuge zu nutzen, und die Werkzeuge, die Agenten schließlich aufrufen, sind in der Praxis Bibliotheken.

Hier ist, was uns im Überblick aufgefallen ist und wie wir darüber aus der Perspektive eines Bibliotheksautoren denken.

Was das Agenten-Framework ist

Das Framework bietet zwei Hauptfähigkeiten. Agents sind individuelle LLM-gesteuerte Arbeiter, die Eingaben verarbeiten, Werkzeuge und MCP-Server aufrufen und Antworten generieren. Workflows sind graphbasierte Orchestrierungen, die mehrere Agenten und Funktionen mit typsicherer Routenführung, Checkpointing und menschlicher Unterstützung im Loop verbinden.

Um diese beiden Oberflächen herum bietet das Framework die Bausteine, die Teams von Unternehmens-AI-Werkzeugen erwarten: Modellclients über Azure OpenAI, OpenAI, Anthropic, Ollama und Microsoft Foundry; sitzungsbasierte Zustandsverwaltung; Kontextanbieter für Speicher; Middleware zur Abfangen von Agent-Aktionen; und MCP-Clients zur Werkzeugintegration.

Die Formulierung "Nachfolger von Semantic Kernel und AutoGen" ist wichtig. Microsoft konsolidiert, anstatt ein weiteres Framework hinzuzufügen. Für Teams, die darauf gewartet haben, sich auf einen .NET-Agenten-Stack festzulegen, bietet dies nun eine klarere Antwort.

Die meist unterschätzte Zeile in der Dokumentation

Versteckt im Abschnitt, wann man Agenten gegenüber Workflows verwenden sollte, gibt es einen Satz, der mehr leistet als der Rest der Seite:

Wenn Sie eine Funktion schreiben können, um die Aufgabe zu bearbeiten, tun Sie das anstatt einen AI-Agenten zu verwenden.

Dies ist die ehrliche technische Sichtweise und sollte der Ausgangspunkt für jedes Gespräch über die Übernahme von Agenten sein. Agents sind kein Zauber. Es sind LLMs mit der Fähigkeit, auszuwählen, welches Werkzeug sie verwenden und in welcher Reihenfolge. Wenn die Aufgabe deterministisch ist, ist eine Funktion schneller, billiger und zuverlässiger. Agents verdienen ihren Platz, wenn der Weg durch die Aufgabe wirklich offen ist.

Für Bibliotheksteams ist dies das grüne Licht. Unsere Bibliotheken sind die Funktionen, die Agenten aufrufen, wenn sie Arbeit delegieren. Das Framework ersetzt keinen Bibliothekscode; es hängt von ihm ab.

Wo .NET-Bibliotheken passen

Tools sind das verbindende Element zwischen einem Agenten und der Arbeit, die der Benutzer tatsächlich erledigt haben möchte. Wenn ein Agent entscheidet, dass "dieser Benutzer möchte, dass ein PDF aus den Daten generiert wird, die wir gerade zusammengefasst haben", generiert es das PDF nicht selbst. Es ruft ein Werkzeug auf, das dies tut.

Die nützlichsten Werkzeuge in einer Produktions-AI-Anwendung reduzieren sich auf Operationen an Dokumenten, Daten oder externen Systemen. Für .NET-Teams, die im Bereich der Dokumentenverarbeitung arbeiten, entspricht das direkt Bibliotheken wie IronPDF, IronOCR und IronXL. Ein konkretes Beispiel mit IronPDF, das als Funktion verpackt ist, die ein Agent aufrufen kann:

[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
$vbLabelText   $csharpLabel

Registrieren Sie diese Funktion als Werkzeug mit einem Agenten und der Agent kann nun gestaltete PDF-Berichte auf Abruf erstellen. Das gleiche Muster gilt für OCR (Extraktion von Text aus einem gescannten Dokument), Tabellenkalkulationsoperationen (Lesen oder Schreiben von XLSX-Daten) und Dokumentenkonvertierung. Jede Bibliothek bietet eine Fähigkeit und jede Fähigkeit wird zu einem Agenten-Werkzeug.

Workflows für Dokumenten-Pipelines

Die Workflow-Oberfläche verdient einen separaten Blick. Die Dokumentenverarbeitung in der Produktion ist selten ein einzelner Schritt. Eine typische reale Pipeline sieht aus wie: OCR der gescannten Rechnung, strukturierte Felder extrahieren, diese gegen Geschäftsregeln validieren, die validierten Daten in ein Excel-Hauptbuch schreiben und eine PDF-Quittung für den Kunden generieren.

Diese Abfolge passt sich sauber auf einen graphbasierten Workflow an, mit typsicherer Weiterleitung zwischen den Schritten. Jeder Knoten ist eine Funktion oder ein Agent; jeder Übergang hat definierte Eingabe- und Ausgabetypen und der Workflow unterstützt Checkpoints für langlaufende Operationen und menschenbasierte Überprüfung in jedem Schritt.

Für Teams, die diese Orchestrierung in benutzerdefiniertem Code handhaben, ist die Workflow-Oberfläche der Teil des Agent Framework, der die Aufmerksamkeit wert ist.

Für Teams, die PDF-, OCR-, Excel-, Word- oder Barcode-Fähigkeiten benötigen, um Werkzeu- oder Workflow-Knotenaufrufe zu unterstützen, bietet die Iron Suite produktionsgeprüfte Implementierungen aller fünf. Beginnen Sie eine kostenlose Testversion, keine Kreditkarte erforderlich.

Einschränkungen und Überlegungen

Einige Dinge, die es zu beachten gilt, bevor Sie sich engagieren:

  • Das Framework ist neu. Es konsolidiert ausgereifte Konzepte aus Semantic Kernel und AutoGen, aber die konsolidierte API-Oberfläche ist an sich neu. APIs werden sich weiterhin entwickeln.
  • Drittanbieter-Modell- und Werkzeugrisiko. Microsofts eigene Dokumentation ist explizit, dass alle Drittsysteme, die Sie integrieren (Nicht-Azure-Modelle, externe Agenten, Drittanbieter-Werkzeuge), weiterhin Ihre Verantwortung für die Datenverarbeitung, Kosten und Sicherheit bleiben. Dies ist die richtige Sichtweise und sollte sorgfältig gelesen werden.
  • Produktionsleitplanken sind weiterhin Ihre Verantwortung. Inhaltsfilter, verantwortungsvolle AI-Milderungsmaßnahmen, Telemetrie und Qualitätsprüfungen für Ihren spezifischen Anwendungsfall werden nicht vom Framework bereitgestellt. Es gibt Ihnen die Bausteine; das System um sie herum ist das Ihre zu bauen.

Zusammenfassung

Das Microsoft Agent Framework ist eine glaubwürdige Konsolidierung der AI-Agentenarbeit des Unternehmens und kommt zu einem Zeitpunkt, an dem .NET-Teams nach einer stabilen Grundlage für die Entwicklung von Produkt-AI-Anwendungen suchen. Sein wichtigstes Rahmensetting ist auch sein meist übersehenes: Agenten sind am nützlichsten, wenn sie um die Funktionen und Bibliotheken herum gebaut werden, die tatsächlich die Arbeit erledigen.

Für Bibliotheksteams ist das die Position, auf die wir gewartet haben.