Flux de travail dynamiques dans les compétences hébergées dans Azure Functions

Les flux de travail dynamiques sont une fonctionnalité des compétences hébergées sur Azure Functions. Ils permettent à une compétence hébergée de lancer un flux de travail durable et en plusieurs étapes d’appels d’outils et d’attentes sans que vous ayez à écrire du code d’orchestration Durable Functions.

Pour obtenir la documentation du runtime la plus récente et la plus complète, consultez Workflows dynamiques dans le runtime des agents Azure Functions.

Important

Azure Functions Hosted Skills est actuellement en aperçu. Les fonctionnalités, les noms de configuration et les connecteurs pris en charge peuvent changer avant la disponibilité générale.

Au lieu d’appeler les outils un par un via la boucle de conversation, les flux de travail dynamiques permettent au modèle IA de générer un plan structuré d’appels d’outils. Le runtime exécute le plan en tant qu’orchestration Durable Functions, qui peut se ramifier, attendre, survivre aux redémarrages et rester observable, tandis que seul le résultat final intègre le contexte de la compétence hébergée.

Pourquoi les flux de travail dynamiques

Il existe quatre limitations fondamentales au fait que des compétences hébergées appellent directement des outils dans la boucle du modèle :

  • Le coût des jetons. Chaque résultat intermédiaire de l’outil est ajouté au contexte du modèle. Un plan multiétape peut consommer des jetons pour traiter des données brutes dont le modèle n’a besoin que d’un résumé.
  • Latence. Chaque appel direct à l’outil constitue un nouveau cycle d’échange avec le modèle. Les traitements longs ou à embranchements multiples s’exécutent de façon séquentielle dans la boucle du modèle, au lieu d’exécuter les tâches indépendantes en parallèle.
  • Durabilité. Le travail en ligne peut être perdu si l’ouvrier redémarre, et il n’y a pas de moyen de mettre en veille sur un minuteur ou d’attendre un signal externe de longue durée.
  • Observabilité. Les opérateurs ne peuvent pas facilement lister, inspecter ou annuler le travail en vol sans passer par la session de chat.

Les flux de travail dynamiques répondent à ces limites en faisant passer l’exécution du plan à une orchestration durable. La compétence hébergée lance le workflow, reçoit un identifiant du workflow et peut terminer son tour. L’orchestrateur exécute des outils compatibles avec le flux de travail et des temporisateurs persistants. L’interface de chat et les interfaces opérationnelles peuvent chacune suivre le flux de travail de manière autonome, et la compétence hébergée reprend le relais une fois le flux de travail terminé.

Comment les flux de travail dynamiques se rapportent à l’appel d’outils programmatiques

Les flux de travail dynamiques sont similaires dans leur forme au patron d'appel d'outils programmatiques d'Anthropic. Dans ce schéma, le modèle crée un plan d’outil structuré et l’exécution l’exécute en dehors de la boucle de discussion normale outil par outil. Cette approche peut réduire l’utilisation et la latence des jetons car les résultats intermédiaires restent en dehors du contexte du modèle, et un plan rédigé par le modèle peut représenter plusieurs appels d’outils.

Les flux de travail dynamiques appliquent ce schéma à Azure Functions et ajoutent une couche de durabilité et d’opérations :

Capacité Modèle programmatique d’appel d’outils Flux de travail dynamiques
Appels d’outils en forme de plan Yes Yes
Consommation de tokens et latence réduites pour l’utilisation de plusieurs outils Yes Yes
Exécution durable à travers les redémarrages des workers Non Oui, en utilisant Durable Functions
Attentes et temporisateurs persistants Non Yes
Liste hors boucle, inspection, annulation et terminaison Non Yes
Visibilité de l’opérateur dans Durable Task Scheduler Non Oui, une fois configuré

Quand utiliser des flux de travail dynamiques

Utilisez des flux de travail dynamiques lorsqu’une compétence hébergée doit exécuter un travail plus important qu’un simple chat ou un appel direct. Les bons ajustements sont les suivants :

  • Des schémas fan-out/fan-in qui rassemblent en parallèle des éléments probants provenant de plusieurs sources indépendantes, telles que les journaux, les métriques et l’historique des déploiements.
  • Gérer en parallèle des compétences hébergées par des spécialistes isolés et combiner leurs réponses.
  • Exécuter un plan en plusieurs étapes où les étapes suivantes dépendent des résultats antérieurs de l’outil.
  • Attendre un retardateur durable sans occuper un worker.
  • Garder les gros résultats intermédiaires hors du contexte de conversation de la compétence hébergée jusqu’à ce qu’un résultat final ou un résumé soit disponible.
  • Suivre et contrôler des tâches de longue durée en dehors de la boucle du modèle.

Tip

Si le travail peut se terminer en un seul appel d’outil ou nécessite une réponse immédiate de l’utilisateur à chaque étape, utilisez un appel direct d’outil plutôt qu’un flux de travail dynamique.

Comment fonctionne un flux de travail

Le schéma suivant montre les principaux composants de l’architecture de flux de travail dynamique :

Diagramme montrant une compétence hébergée lançant un flux de travail dynamique qui exécute des activités d’outils, des minuteurs et des sous-agents via un orchestrateur durable.

Un flux de travail dynamique suit cette séquence :

  1. Un événement déclenche la compétence hébergée, ou un utilisateur envoie une requête via l’interface du chat.
  2. La compétence hébergée s’appelle start_workflow avec un plan de workflow généré par le modèle IA.
  3. L’exécution démarre le plan sous forme d’orchestration Durable Functions et renvoie immédiatement un ID de workflow.
  4. L’orchestrateur exécute en parallèle les activités d’outil prêtes et crée des temporisateurs persistants pour les étapes wait. Il peut également déléguer des tâches à des compétences hébergées par des sous-agents, chacune s’exécutant dans une session isolée et sans état.
  5. Lorsque le flux de travail atteint un état terminal, l’exécution notifie la compétence hébergée, qui appelle get_workflow_status et résume la sortie finale.

Lorsque la compétence hébergée utilise l’interface de chat intégrée, l’interface interroge également le statut du workflow et affiche une fiche de progression.

Les résultats intermédiaires restent dans le stockage du flux de travail. La compétence hébergée ne voit que l’ID du workflow au début et le statut final lorsqu’elle récupère le résultat. La compétence hébergée ne sonde pas pendant que le workflow s’exécute.

Outils de gestion des flux de travail

Lorsque vous activez les flux de travail, l’exécution ajoute ces outils à la compétence hébergée :

Tool Purpose
start_workflow Lance un plan de workflow validé et renvoie immédiatement un ID de workflow.
get_workflow_status Obtient le statut actuel et la sortie finale d’un flux de travail.
list_workflows Liste les flux de travail appartenant à la session en cours.
cancel_workflow Demande une annulation coordonnée.
terminate_workflow Termine brusquement l’instance de workflow.

La compétence hébergée appelle ces outils. Les utilisateurs ne les appellent pas directement dans le code de l’application.

Sous-agents de flux de travail

Une compétence hébergée activée par un workflow peut donner accès à des compétences hébergées spécialisées dans sa workflows.subagents configuration. Chaque spécialiste correspond à un autre fichier .agent.md de la même application hébergée de compétences.

Le sujet de première ligne suivant permet au coordinateur d’utiliser deux spécialistes :

---
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
---

La valeur agent est le slug du nom de fichier du spécialiste. Par exemple, pr_status_analyst fait référence à pr_status_analyst.agent.md. La valeur optionnelle when aide le modèle à décider quand utiliser le spécialiste. L’environnement d’exécution vérifie chaque spécialiste au regard de cette autorisation explicite avant de planifier le workflow.

Le modèle peut générer une tâche de workflow sub_agent avec id, agent et un task autonome. Une tâche sous-agent peut aussi utiliser depends_on, when, et for_each.

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

Chaque invocation de sous-agent est sans état et isolée :

  • Le spécialiste utilise son propre modèle, instructions, outils, serveurs MCP, compétences et délais d’attente.
  • Le spécialiste ne reçoit pas l’historique des conversations du coordinateur, le bac à sable, les outils de gestion des flux de travail ou les outils de délégation du temps de chat.
  • Une défaillance ou un délai d’attente spécialisé fait échouer le flux de travail parent.
  • Les outils spécialisés devraient tolérer la réexécution car une défaillance de travailleur peut faire fonctionner un sous-agent plus d’une fois.

Pour un exemple de bout en bout qui exécute en parallèle des tâches d’analyse de PR et combine leurs résumés dans un rapport, voir l’exemple de sous-agents de flux de travail.

Back-end de stockage

Les flux de travail dynamiques utilisent Durable Functions en interne et prennent en charge les mêmes backends de stockage. Par défaut, les workflows utilisent le compte stockage Azure que votre application de fonctions possède déjà. Pour les charges de travail, vous pouvez passer au Durable Task Scheduler (DTS), qui fournit un tableau de bord avec l’état de tâche par instance, l’historique des essais et les contrôles pour le travail en vol. Le guide pratique couvre les deux options.

Considerations

Gardez à l’esprit ces limitations actuelles lorsque vous utilisez des flux de travail dynamiques :

  • Les gestionnaires d’outils sûrs en flux de travail doivent être synchrones et retourner des valeurs sérialisables en JSON.
  • Le modèle d’IA génère le plan de flux de travail à l’exécution. On ne peut pas définir de modèles de workflow statiques dans YAML ou Markdown.
  • Vous ne pouvez pas configurer des politiques de réessayage et de délai par tâche.
  • La gestion des sorties volumineuses et l’intégration à MCP Tasks ne sont pas disponibles.

Étapes suivantes

Configurez des outils sûrs pour les flux de travail et exécutez votre flux de travail localement :

Créer et exécuter des flux de travail dynamiques

Contenu connexe

  • Dernière mise à jour :