Dynamische workflows in door Azure Functions gehoste vaardigheden

Dynamische workflows zijn een kenmerk van Azure Functions gehoste vaardigheden. Ze laten een gehoste vaardigheid een duurzame, meerstapsworkflow van tooloproepen en wachttijden starten zonder dat jij Durable Functions orchestratiecode hoeft te schrijven.

Voor de meest actuele en uitgebreide runtime-documentatie raadpleegt u Dynamische workflows in Azure Functions Agents Runtime.

Important

Azure Functions-gehoste vaardigheden zijn momenteel beschikbaar als preview. Functies, configuratienamen en ondersteunde connectors kunnen vóór algemene beschikbaarheid veranderen.

In plaats van tools één voor één via de gespreksloop aan te roepen, laten dynamische workflows het AI-model een gestructureerd plan van toolcalls genereren. De runtime voert het plan uit als een Durable Functions-orkestratie die kan vertakken, wachten, herstarts kan overleven en observeerbaar blijft, terwijl alleen het eindresultaat terechtkomt in de context van de gehoste vaardigheid.

Waarom dynamische workflows

Er zijn vier fundamentele beperkingen aan het feit dat gehoste skills tools rechtstreeks binnen de modelloop aanroepen:

Tokenkosten. Elk tussentijds toolresultaat wordt toegevoegd aan de context van het model. Een meerstapsplan kan tokens besteden aan ruwe data die het model alleen hoeft samen te vatten.
Latency. Elke directe aanroep van een tool is nog een extra heen-en-weergang naar het model. Langdurig of sterk vertakt werk loopt serieel via de modellus in plaats van onafhankelijk werk parallel uit te voeren.
Duurzaamheid. Inline werk kan verloren gaan als de werknemer opnieuw opstart, en er is geen eersteklas manier om op een timer te slapen of te wachten op een langlopend extern signaal.
Waarneembaarheid. Operators kunnen niet gemakkelijk werk aan boord vermelden, inspecteren of annuleren zonder de chatsessie te doorlopen.

Dynamische workflows pakken deze beperkingen aan door de planuitvoering te veranderen in een duurzame orkestratie. De gehoste skill start de workflow, ontvangt een workflow-ID en kan de beurt beëindigen. De orchestrator draait workflow-veilige tools en duurzame timers. De chatinterface en bewerkingsoppervlakken kunnen de workflow zelfstandig bijhouden, en de gehoste vaardigheid hervat zodra de workflow is voltooid.

Hoe dynamische workflows zich verhouden tot programmatic tool calling

Dynamische workflows lijken qua vorm op het programmatic tool-aanroeppatroon van Anthropic. In dat patroon maakt het model een gestructureerd toolplan en voert de runtime dit uit buiten de normale tool-voor-tool chatlus. Deze aanpak kan het gebruik en de latentie van tokens verminderen omdat tussenresultaten buiten de modelcontext blijven, en één door het model geschreven plan meerdere toolcalls kan weergeven.

Dynamische workflows passen dat patroon toe op Azure Functions en voegen een duurzaamheids- en operatielaag toe:

Vermogen	Patroon voor het programmatisch aanroepen van hulpprogramma's	Dynamische werkstromen
Plangevormde toolaanroepen	Ja	Ja
Lagere tokengebruik en latentie voor multitoolwerk	Ja	Ja
Duurzame uitvoering bij herstarts van werknemers	No	Ja, door gebruik te maken van Durable Functions
Duurzame wachttijden en timers	No	Ja
Buiten de lus lijsten, inspecteren, annuleren en beëindigen	No	Ja
Zichtbaarheid voor operators in Durable Task Scheduler	No	Ja, wanneer geconfigureerd

Wanneer dynamische workflows te gebruiken

Gebruik dynamische workflows wanneer een hosted skill werk moet uitvoeren dat groter is dan een enkele chatbeurt of direct toolcall. Goede pasvormen zijn onder andere:

Fan-out/fan-in-patronen die parallel bewijsmateriaal verzamelen van verschillende onafhankelijke bronnen, zoals logs, meetgegevens en uitrolgeschiedenis.
Geïsoleerde specialistische gehoste vaardigheden parallel uitvoeren en de antwoorden combineren.
Een meerstappenplan uitvoeren waarbij latere stappen afhangen van eerdere resultaten van het gereedschap.
Wachten op een duurzame timer zonder een werknemer bezig te houden.
Grote tussenresultaten buiten de gesprekscontext van de gehoste vaardigheid houden totdat een definitief resultaat of een samenvatting beschikbaar is.
Het volgen en controleren van langlopend werk van buiten de modelloop.

Tip

Als het werk in één toolcall kan worden afgerond of bij elke stap direct een gebruikersreactie vereist, gebruik dan direct tool calling in plaats van een dynamische workflow.

Hoe een workflow werkt

Het volgende diagram toont de belangrijkste componenten in de dynamische workflowarchitectuur:

Een dynamische workflow loopt door deze volgorde:

Een gebeurtenis activeert de gehoste vaardigheid, of een gebruiker stuurt een verzoek via de chatinterface.
De gehoste vaardigheid roept start_workflow aan met een werkstroomplan dat door het AI-model is gegenereerd.
De runtime start het plan als een Durable Functions-orkestratie en geeft direct een workflow-ID terug.
De orchestrator voert gereedstaande toolactiviteiten parallel uit en maakt duurzame timers aan voor wait stappen. Het kan ook werk delegeren aan subagent-gehoste vaardigheden, die elk in een geïsoleerde, stateloze sessie draaien.
Wanneer de workflow een eindtoestand bereikt, stelt de runtime de gehoste vaardigheid op de hoogte, die get_workflow_status aanroept en het eindresultaat samenvat.

Wanneer de gehoste vaardigheid de ingebouwde chatinterface gebruikt, peilt de UI ook de status van de workflow en toont een voortgangskaart.

Tussenresultaten blijven in de workflow-opslag. De gehoste vaardigheid ziet alleen de workflow-ID bij het starten en de eindstatus wanneer het resultaat wordt opgehaald. De gehoste vaardigheid pollt niet terwijl de workflow loopt.

Workflowbeheertools

Wanneer je workflows inschakelt, voegt de runtime deze tools toe aan de gehoste vaardigheid:

Tool	Purpose
`start_workflow`	Start een gevalideerd workflowplan en geeft direct een workflow-ID terug.
`get_workflow_status`	Krijgt de huidige status en de uiteindelijke output van een workflow.
`list_workflows`	Geeft een lijst van workflows die eigendom zijn van de huidige sessie.
`cancel_workflow`	Verzoek om coöperatieve annulering.
`terminate_workflow`	Beëindigt de workflow-instantie abrupt.

De gehoste vaardigheid roept deze tools aan. Gebruikers roepen deze niet rechtstreeks aan in de applicatiecode.

Workflow-subagenten

Een workflowgestuurde gehoste vaardigheid kan toegang verlenen tot gespecialiseerde gehoste vaardigheden in de workflows.subagents-configuratie. Elke specialist is een ander .agent.md bestand in dezelfde gehoste vaardighedenapp.

De volgende frontzaak stelt de coördinator in staat twee specialisten te gebruiken:

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

De waarde agent is de bestandsnaamslug van de specialist. Bijvoorbeeld, pr_status_analyst verwijst naar pr_status_analyst.agent.md. De optionele when waarde helpt het model te beslissen wanneer de specialist wordt ingezet. De runtime controleert elke specialist tegen deze expliciete machtiging voordat de workflow wordt ingepland.

Het model kan een sub_agent workflowtaak genereren met id, agent, en een zelfstandige task. Een subagenttaak kan ook gebruikmaken van depends_on, when, en for_each.

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

Elke subagent-aanroep is stateloos en geïsoleerd:

De specialist gebruikt zijn eigen model, instructies, tools, MCP-servers, vaardigheden en timeout.
De specialist ontvangt niet de gespreksgeschiedenis, de sandbox, hulpmiddelen voor workflowbeheer of hulpmiddelen voor delegatie tijdens chats van de coördinator.
Het falen of een time-out van een specialist zorgt ervoor dat de bovenliggende workflow mislukt.
Gespecialiseerde tools moeten bestand zijn tegen herhaalde uitvoering, omdat een storing van een worker ertoe kan leiden dat een subagent meer dan één keer wordt uitgevoerd.

Voor een end-to-end voorbeeld dat parallelle taken van PR-analisten uitvoert en hun samenvattingen combineert tot een rapport, zie het voorbeeld van workflow-subagenten.

Back-end voor opslag

Dynamische workflows gebruiken intern Durable Functions en ondersteunen dezelfde opslagbackends. Standaard gebruiken workflows het Azure Storage-account dat je functie-app al heeft. Voor productieworkloads kun je overschakelen naar Durable Task Scheduler (DTS), die een dashboard biedt met de taakstatus per instantie, herkansingsgeschiedenis en controles voor werk tijdens de vlucht. De handleiding behandelt beide opties.

Overwegingen

Houd deze huidige beperkingen in gedachten wanneer je dynamische workflows gebruikt:

Workflow-veilige toolhandlers moeten synchroon zijn en JSON-serialiseerbare waarden teruggeven.
Het AI-model genereert het workflowplan tijdens runtime. Je kunt geen statische workflowtemplates definiëren in YAML of Markdown.
Je kunt geen per-taak-herkansings- en timeout-beleid configureren.
Verwerking van grote uitvoer en integratie van MCP Tasks zijn niet beschikbaar.

Volgende stappen

Configureer workflow-veilige tools en voer je workflow lokaal uit:

Maak en voer dynamische workflows uit

Feedback

Is deze pagina nuttig?

Laatst bijgewerkt om 2026-09-03