NOTICIAS DEL SECTOR

Milan Jovanović crea documentos PDF en ASP .NET Core - Y IronPDF es su biblioteca de elección

Actualizado:

Microsoft ha lanzado el Agent Framework como el sucesor directo de Semantic Kernel y AutoGen, consolidando el trabajo de construcción de agentes que se ha acumulado en las herramientas de IA de la compañía. Para los equipos que construyen bibliotecas de .NET, que es lo que hacemos en Iron Software, este lanzamiento merece un vistazo detenidamente. Los frameworks de agentes tratan fundamentalmente sobre darle a los LLMs la capacidad de usar herramientas, y las herramientas que los agentes terminan llamando son, en la práctica, bibliotecas.

Aquí está lo que nos llamó la atención en el resumen, y cómo lo estamos pensando desde la perspectiva de un autor de bibliotecas.

Qué es el Agent Framework

El framework proporciona dos capacidades principales. Agentes son trabajadores individuales impulsados por LLM que procesan entradas, llaman herramientas y servidores MCP, y generan respuestas. Flujos de trabajo son orquestaciones basadas en gráficos que conectan múltiples agentes y funciones con enrutamiento seguro por tipo, puntos de control y soporte humano en el bucle.

Alrededor de esas dos superficies, el framework ofrece los bloques de construcción que los equipos esperan de las herramientas de IA empresarial: clientes de modelo a través de Azure OpenAI, OpenAI, Anthropic, Ollama y Microsoft Foundry; gestión de estado basada en sesiones; proveedores de contexto para memoria; middleware para interceptar acciones del agente; y clientes MCP para integración de herramientas.

El encuadre de "sucesor de Semantic Kernel y AutoGen" importa. Microsoft está consolidando en lugar de agregar otro framework al menú. Para los equipos que han estado esperando para comprometerse con un stack de agentes de .NET, esta es ahora una respuesta más clara.

La línea más subestimada en la documentación

Oculta en la sección sobre cuándo usar agentes frente a flujos de trabajo hay una oración que hace más trabajo que el resto de la página:

Si puedes escribir una función para manejar la tarea, haz eso en lugar de usar un agente de IA.

Este es el encuadre de ingeniería honesta, y debería ser el punto de partida para cada conversación sobre la adopción de agentes. Los agentes no son magia. Son LLMs con la capacidad de elegir qué herramienta llamar y en qué orden. Cuando la tarea es determinista, una función es más rápida, más barata y más confiable. Los agentes ganan su lugar cuando el camino a través de la tarea es genuinamente abierto.

Para los equipos de bibliotecas, esta es la luz verde. Nuestras bibliotecas son las funciones que los agentes llaman cuando delegan trabajo. El framework no reemplaza el código de biblioteca; depende de ello.

Dónde encajan las bibliotecas .NET

Las herramientas son el tejido conectivo entre un agente y el trabajo que el usuario realmente quiere hacer. Cuando un agente decide que "este usuario quiere un PDF generado a partir de los datos que acabamos de resumir", no genera el PDF en sí. Llama a una herramienta que sí lo hace.

La mayoría de las herramientas útiles en una aplicación de IA en producción se reducen a operaciones sobre documentos, datos o sistemas externos. Para equipos .NET que trabajan en el espacio de procesamiento de documentos, eso se mapea directamente a bibliotecas como IronPDF, IronOCR, y IronXL. Un ejemplo concreto que usa IronPDF envuelto como una función que un agente puede llamar:

[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

Registra esta función como una herramienta con un agente, y el agente ahora tiene la capacidad de producir informes PDF con estilo bajo demanda. El mismo patrón se aplica a OCR (extracción de texto de un documento escaneado), operaciones en hojas de cálculo (lectura o escritura de datos XLSX), y conversión de documentos. Cada biblioteca expone una capacidad, y cada capacidad se convierte en una herramienta de agente.

Flujos de trabajo para pipelines de documentos

La superficie de los flujos de trabajo merece una mirada separada. El procesamiento de documentos en producción rara vez es un solo paso. Un pipeline típico del mundo real se ve así: OCR la factura escaneada, extraer campos estructurados, validarlos contra reglas de negocio, escribir los datos validados en un libro de Excel, y generar un recibo PDF para el cliente.

Esa secuencia se mapea limpiamente en un flujo de trabajo basado en gráficos con enrutamiento seguro por tipo entre pasos. Cada nodo es una función o agente, cada transición tiene tipos de entrada y salida bien definidos, y el flujo de trabajo admite puntos de control para operaciones prolongadas y revisión humana en cualquier paso.

Para los equipos que han estado orquestando esto de manera personalizada, la superficie de los flujos de trabajo es la parte del Agent Framework que más vale la pena investigar.

Para equipos que necesitan capacidades de PDF, OCR, Excel, Word o códigos de barras para respaldar llamadas a herramientas o nodos de flujo de trabajo, el Iron Suite proporciona implementaciones probadas en producción de los cinco. Comienza una prueba gratuita, no se requiere tarjeta de crédito.

Limitations and considerations

Algunas cosas que vale la pena tener en cuenta antes de comprometerse:

  • El framework es nuevo. Consolida conceptos maduros de Semantic Kernel y AutoGen, pero la superficie de API consolidada es en sí reciente. Las API seguirán evolucionando.
  • Riesgo de modelos y herramientas de terceros. La propia documentación de Microsoft es explícita en que cualquier sistema de terceros que integres (modelos no Azure, agentes externos, herramientas de terceros) sigue siendo tu responsabilidad para el manejo de datos, costo y seguridad. Este es el encuadre correcto, y vale la pena leerlo cuidadosamente.
  • Las salvaguardias de producción siguen siendo tu responsabilidad. Los filtros de contenido, las mitigaciones de IA responsable, la telemetría y las pruebas de calidad para tu caso de uso específico no son proporcionados por el framework. Te da los bloques de construcción; el sistema en torno a ellos es tuyo para construir.

Resumen

El Microsoft Agent Framework es una consolidación creíble del trabajo de agentes de IA de la compañía, llegando en un momento en que los equipos de .NET están buscando una base estable para construir aplicaciones de IA en producción. Su encuadre más importante es también el más pasado por alto: los agentes son más útiles cuando se envuelven en torno a las funciones y bibliotecas que realmente hacen el trabajo.

Para los equipos de bibliotecas, esa es la posición que hemos estado esperando.