Milan Jovanović 在 ASP .NET Core 中建立 PDF 文件 - 而 IronPDF 是他的首選程式庫

Agent Framework是什麼

這個框架提供了兩個主要的能力。 代理是單個由LLM驅動的工作者，處理輸入、呼叫工具和MCP伺服器，以及生成響應。 工作流程是基於圖形的編排，連接多個代理和功能，具有型別安全的路由、檢查點和人為介入支持。

在這兩個介面周圍，框架提供了企業AI工具所期望的構建塊：跨Azure OpenAI、OpenAI、Anthropic、Ollama和Microsoft Foundry的模型客戶端； 基於會話的狀態管理； 記憶的上下文提供者； 攔截代理操作的中介軟體； 以及用於工具整合的MCP客戶端。

作為Semantic Kernel和AutoGen的繼任者的框架設定很重要。 Microsoft正在整合，而不是再增加另一個框架。 對於一直在等待承諾使用.NET代理堆疊的團隊，這現在是一個更清晰的答案。

文件中最被低估的一句話

藏在何時使用代理與工作流程的章節中，有一句話比整頁的內容更有效：

如果您能寫一個函式來處理這項任務，那麼就這樣做，不要使用AI代理。

這是誠實的工程框架，應該是每一次有關採用代理的對話的起點。 代理不是魔法。 它們是具有選擇呼叫工具順序能力的LLM。 當任務是確定性的時候，函式更快、更便宜、更可靠。 當任務的執行路徑真的很開放時，代理才是有價值的。

對於程式庫團隊來說，這是綠燈。 我們的程式庫是代理在委派工作時呼叫的函式。 框架不會取代程式庫的程式碼； 它依賴於程式碼。

.NET程式庫的適用位置

工具是代理與使用者真正想要完成的工作之間的連接綱。 當代理決定"使用者希望從我們剛剛總結的資料生成PDF"時，它不會自己生成PDF。 它呼叫一個工具來完成。

在生產AI應用程式中，大多數有用的工具都歸結為對文件、資料或外部系統的操作。 對於在文件處理領域工作的.NET團隊來說，這直接映射到像 IronPDF、 IronOCR 和 IronXL 這樣的程式庫。 一個用IronPDF包裝為函式的具體範例，代理可以呼叫它：

[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

將此函式註冊為代理的工具，現在代理具有隨需生產風格化PDF報告的能力。 相同的模式適用於OCR（從掃描的文件中提取文字）、電子表格操作（讀取或寫入XLSX資料）和文件轉換。 每個程式庫提供一種能力，每種能力都成為代理工具。

文件管道的工作流程

工作流程介面值得單獨一看。 生產中的文件處理很少是單一步驟。典型的真實管道看起來像這樣：OCR掃描的發票，提取結構化字段，根據業務規則驗證它們，將驗證的資料寫入Excel分類帳，並為客戶生成PDF收據。

該序列乾淨地映射到基於圖形的流程上，步驟之間具有型別安全的路由。 每個節點是一個函式或代理，每個過渡都有明確定義的輸入和輸出型別，並且工作流程支持長期運行操作的檢查點及人為檢查的任意步驟。

對於一直在自定義程式碼中手工編寫這種編排的團隊來說，工作流程介面是Agent Framework最值得調查的部分。

對於需要PDF、OCR、Excel、Word或條碼功能來支持工具呼叫或工作流程節點的團隊，Iron Suite 提供全五種的生產測試實現。開始免費試用, 無需信用卡。

限制和考量

在承諾之前值得記住幾件事情：

• 此框架是新的。 它整合了來自Semantic Kernel和AutoGen的成熟概念，但整合的API介面本身是新的。 API將繼續發展。
• 第三方模型和工具風險。 Microsoft自己的文件明確指出，您整合的任何第三方系統（非Azure模型、外部代理、第三方工具）的資料處理、成本和安全性仍然是您的責任。 這是正確的框架，值得仔細閱讀。
• 生產護欄仍然是您的責任。 內容過濾器、負責任的AI緩解措施、遙測和針對您具體用例的質量測試都未由框架提供。 它給您構建塊； 周圍的系統是您需要構建的。

摘要

Microsoft Agent Framework 是公司AI代理工作的一個可信整合，恰逢.NET團隊正在尋找一個穩定環境來構建生產AI應用程式的時刻。 其最重要的框架也是最被忽視的：代理在圍繞真正完成工作的功能和程式庫時最有用。

對於程式庫團隊來說，這是我們一直在等待的位置。