Flujos de trabajo dinámicos en habilidades alojadas por Azure Functions

Los flujos de trabajo dinámicos son una característica de las habilidades alojadas en Azure Functions. Permiten que una habilidad alojada inicie un flujo de trabajo duradero y de varios pasos de llamadas a herramientas y esperas sin que escribas código de orquestación de Durable Functions.

Para consultar la documentación más actualizada y completa sobre el runtime, consulta Flujos de trabajo dinámicos en Agents Runtime de Azure Functions.

Importante

Las habilidades hospedadas de Azure Functions se encuentran actualmente en versión preliminar. Las características, los nombres de configuración y los conectores admitidos pueden cambiar antes de la disponibilidad general.

En lugar de llamar a las herramientas una a una a través del bucle de conversación, los flujos de trabajo dinámicos permiten que el modelo de IA genere un plan estructurado de llamadas a herramientas. El entorno de ejecución ejecuta el plan como una orquestación de Durable Functions que puede ramificarse, esperar, sobrevivir a los reinicios y seguir siendo observable, mientras que solo el resultado final entra en el contexto de la habilidad hospedada.

Por qué flujos de trabajo dinámicos

Hay cuatro limitaciones básicas para que las habilidades alojadas llamen directamente a herramientas dentro del bucle del modelo:

Coste de tokens. Cada resultado intermedio de la herramienta se añade al contexto del modelo. Un plan de varios pasos puede consumir tokens con datos sin procesar que el modelo solo tiene que resumir.
Latencia. Cada llamada directa a la herramienta supone otra ida y vuelta al modelo. El trabajo largo o ramificado se ejecuta en serie a través del bucle del modelo en lugar de ejecutar trabajo independiente en paralelo.
Durabilidad. El trabajo en línea puede perderse si el trabajador se reinicia, y no existe una forma óptima de suspender la ejecución mediante un temporizador o esperar una señal externa de larga duración.
Observabilidad. Los operadores no pueden listar, inspeccionar o cancelar fácilmente trabajos en vuelo sin pasar por la sesión de chat.

Los flujos de trabajo dinámicos abordan estas limitaciones trasladando la ejecución del plan a una orquestación duradera. La habilidad alojada inicia el flujo de trabajo, recibe un ID de flujo de trabajo y puede terminar su turno. El orquestador ejecuta herramientas seguras para el flujo de trabajo y temporizadores duraderos. La interfaz de usuario del chat y las superficies de operaciones pueden realizar un seguimiento del flujo de trabajo de forma independiente, y la habilidad hospedada se reanuda cuando el flujo de trabajo finaliza.

Cómo se relacionan los flujos de trabajo dinámicos con la llamada a herramientas programáticas

Los flujos de trabajo dinámicos son similares en forma al patrón de llamada de herramientas programáticas de Anthropic. En ese patrón, el modelo crea un plan estructurado de herramientas y el tiempo de ejecución lo ejecuta fuera del bucle normal de chat herramienta por herramienta. Este enfoque puede reducir el uso y la latencia de tokens porque los resultados intermedios permanecen fuera del contexto del modelo, y un plan creado por el modelo puede representar múltiples llamadas a herramientas.

Los flujos de trabajo dinámicos aplican ese patrón a Azure Functions y añaden una capa de durabilidad y operaciones:

Capacidad	Patrón de llamada a herramienta programática	Flujos de trabajo dinámicos
Llamadas a herramientas en forma de plan	Yes	Yes
Menor uso de tokens y menor latencia para trabajos con varias herramientas	Yes	Yes
Ejecución duradera tras los reinicios del trabajador	No	Sí, usando Durable Functions
Esperas y temporizadores persistentes	No	Yes
Lista, inspección, cancelación y finalización fuera del bucle	No	Yes
Visibilidad del operador en Durable Task Scheduler	No	Sí, cuando está configurado

Cuándo usar flujos de trabajo dinámicos

Utiliza flujos de trabajo dinámicos cuando una habilidad alojada necesite realizar trabajo mayor que un solo turno de chat o una llamada directa a una herramienta. Entre las opciones adecuadas se incluyen:

Patrones de fan-out/fan-in que recopilan evidencias de varias fuentes independientes en paralelo, como registros, métricas e historial de implementaciones.
Ejecutar en paralelo habilidades especializadas alojadas de forma aislada y combinar sus respuestas.
Ejecutar un plan de varios pasos donde los pasos posteriores dependen de los resultados de herramientas anteriores.
Esperar un temporizador duradero sin mantener ocupado al trabajador.
Mantener los grandes resultados intermedios fuera del contexto de conversación de la habilidad alojada hasta que haya disponible un resultado final o resumen.
Seguimiento y control de procesos de ejecución prolongada desde fuera del bucle del modelo.

Tip

Si el trabajo puede terminar en una sola llamada a la herramienta o necesita una respuesta inmediata del usuario en cada paso, utiliza la llamada directa a la herramienta en lugar de un flujo de trabajo dinámico.

Cómo funciona un flujo de trabajo

El siguiente diagrama muestra los componentes principales de la arquitectura dinámica del flujo de trabajo:

Un flujo de trabajo dinámico recorre esta secuencia:

Un evento activa la habilidad alojada, o un usuario envía una solicitud a través de la interfaz del chat.
La función alojada invoca a start_workflow con un plan del flujo de trabajo generado por el modelo de IA.
El entorno de ejecución inicia el plan como una orquestación de Durable Functions y devuelve de inmediato un identificador de flujo de trabajo.
El orquestador ejecuta en paralelo las actividades de las herramientas listas y crea temporizadores duraderos para los pasos wait. También puede delegar tareas en habilidades alojadas en subagentes, cada una de las cuales se ejecuta en una sesión aislada y sin estado.
Cuando el flujo de trabajo alcanza un estado terminal, el entorno de ejecución notifica a la habilidad alojada, que llama a get_workflow_status y sintetiza el resultado final.

Cuando la habilidad alojada utiliza la interfaz de chat integrada, la interfaz también consulta el estado del flujo de trabajo y muestra una tarjeta de progreso.

Los resultados intermedios permanecen en el almacén de flujo de trabajo. La habilidad alojada solo ve el ID del flujo de trabajo al inicio y el estado final cuando recupera el resultado. La habilidad alojada no realiza sondeos mientras se ejecuta el flujo de trabajo.

Herramientas de gestión de flujos de trabajo

Cuando activas flujos de trabajo, el tiempo de ejecución añade estas herramientas a la habilidad alojada:

Tool	Purpose
`start_workflow`	Inicia un plan de flujo de trabajo validado y devuelve un ID de flujo de trabajo inmediatamente.
`get_workflow_status`	Obtiene el estado actual y la salida final de un flujo de trabajo.
`list_workflows`	Lista los flujos de trabajo que pertenecen a la sesión actual.
`cancel_workflow`	Solicita cancelación cooperativa.
`terminate_workflow`	Termina la instancia del flujo de trabajo de forma abrupta.

La habilidad hospedada llama a estas herramientas. Los usuarios no los invocan directamente desde el código de la aplicación.

Subagentes de flujo de trabajo

Una habilidad hospedada habilitada para flujos de trabajo puede conceder acceso a habilidades hospedadas especializadas en su configuración workflows.subagents. Cada especialista es otro .agent.md archivo en la misma aplicación de habilidades alojada.

El siguiente punto inicial permite al coordinador utilizar a dos especialistas:

---
name: PR Status Portfolio Coordinator
description: Reviews pull requests and produces an actionable report.
workflows:
  enabled: true
  subagents:
    - agent: pr_status_analyst
      when: Review one pull request and summarize its current status
    - agent: actionable_report_writer
      when: Combine pull-request summaries into an actionable portfolio report
---

El valor de agent es el slug del nombre de archivo correspondiente al especialista. Por ejemplo, pr_status_analyst se refiere a pr_status_analyst.agent.md. El valor opcional when ayuda al modelo a decidir cuándo utilizar al especialista. El tiempo de ejecución valida a cada especialista respecto a esta concesión explícita antes de programar el flujo de trabajo.

El modelo puede generar una tarea de flujo de trabajo sub_agent con id, agent y un task autónomo. Una tarea de subagente también puede usar depends_on, when, y for_each.

{
  "id": "analyze_pr",
  "type": "sub_agent",
  "agent": "pr_status_analyst",
  "task": "Review the supplied pull request and summarize its current status."
}

Cada invocación de subagente es sin estado y está aislada:

El especialista utiliza su propio modelo, instrucciones, herramientas, servidores MCP, habilidades y tiempos de espera.
El especialista no recibe el historial de conversaciones del coordinador, el sandbox, las herramientas de gestión de flujos de trabajo ni las herramientas de delegación en el chat.
Un fallo o un tiempo de espera de un especialista hace que falle el flujo de trabajo padre.
Las herramientas especializadas deberían tolerar la reejecución porque un fallo de un trabajador puede hacer que un subagente se ejecute más de una vez.

Para un ejemplo de extremo a extremo que ejecute tareas paralelas de analistas de relaciones públicas y combine sus resúmenes en un informe, véase el ejemplo de subagentes de flujo de trabajo.

Backend de almacenamiento

Los flujos de trabajo dinámicos utilizan Durable Functions internamente y soportan los mismos backends de almacenamiento. Por defecto, los flujos de trabajo usan la cuenta de Azure Storage que ya tiene tu app de funciones. Para cargas de trabajo en producción, puedes cambiar a Durable Task Scheduler (DTS), que proporciona un panel con el estado de la tarea por instancia, el historial de reintentos y los controles para el trabajo en vuelo. La guía de instrucciones cubre ambas opciones.

Considerations

Ten en cuenta estas limitaciones actuales cuando utilices flujos de trabajo dinámicos:

Los manejadores de herramientas seguros para flujos de trabajo deben ser síncronos y devolver valores serializables en JSON.
El modelo de IA genera el plan de flujo de trabajo en tiempo de ejecución. No puedes definir plantillas de flujo de trabajo estáticas en YAML o Markdown.
No puedes configurar políticas de reintento y tiempo de espera por tarea.
La gestión de salidas de gran tamaño y la integración con tareas MCP no están disponibles.

Pasos siguientes

Configura herramientas seguras para flujos de trabajo y ejecuta tu flujo de trabajo localmente:

Crear y ejecutar flujos de trabajo dinámicos

Comentarios

¿Le ha resultado útil esta página?

Se actualizó por última vez el 2026-09-03