Dynamische Workflows in in Azure Functions gehosteten Fertigkeiten

Dynamische Workflows sind eine Funktion von in Azure Functions gehosteten Skills. Sie ermöglichen es einem gehosteten Skill, einen dauerhaften, mehrstufigen Workflow aus Tool-Aufrufen und Wartezeiten zu starten, ohne dass man Durable Functions-Orchestrierungscode schreiben muss.

Die aktuellste und umfassendste Runtimedokumentation finden Sie unter Dynamic workflows in Azure Functions Agents Runtime.

Anstatt die Werkzeuge einzeln über die Konversationsschleife aufzurufen, ermöglichen dynamische Workflows dem KI-Modell die Erstellung eines strukturierten Plans von Tool-Aufrufen. Die Laufzeit führt den Plan als Durable Functions-Orchestrierung aus, die sich ausbreiten, warten, Neustarts überstehen und beobachtbar bleiben kann, während nur das Endergebnis in den Kontext der gehosteten Skill eintritt.

Warum dynamische Workflows

Es gibt vier grundlegende Einschränkungen dafür, dass gehostete Skills Werkzeuge direkt in der Modellschleife aufrufen:

• Kosten für Token Jedes Zwischenwerkzeugergebnis wird dem Kontext des Modells hinzugefügt. Ein Mehrstufeplan kann Tokens für Rohdaten ausgeben, die das Modell nur zusammenfassen muss.
• Latenz. Jeder direkte Tool-Aufruf ist ein weiterer Modell-Roundtrip. Lange oder stark verzweigte Aufgaben werden in der Modellschleife seriell abgearbeitet, statt unabhängige Aufgaben parallel auszuführen.
• Haltbarkeit. Inline-Arbeit kann verloren gehen, wenn der Mitarbeiter neu startet, und es gibt keine erstklassige Möglichkeit, auf einem Timer zu schlafen oder auf ein langanhaltendes externes Signal zu warten.
• Observability. Betreiber können Inflight-Arbeiten nicht einfach auflisten, inspizieren oder stornieren, ohne die Chat-Session durchzulaufen.

Dynamische Workflows beheben diese Einschränkungen, indem sie die Planausführung in eine dauerhafte Orchestrierung verwandeln. Der gehostete Skill startet den Workflow, erhält eine Workflow-ID und kann seinen Zug beenden. Der Orchestrator verwendet workflow-sichere Tools und langlebige Timer. Die Chat-Benutzeroberfläche und die Vorgangsoberflächen können den Workflow unabhängig verfolgen, und die gehostete Skill wird wieder aufgenommen, wenn der Workflow abgeschlossen ist.

Wie dynamische Workflows mit programmatischen Werkzeugaufrufen zusammenhängen

Dynamische Workflows ähneln in ihrer Form dem programmatischen Werkzeugaufrufmuster von Anthropic. In diesem Schema erstellt das Modell einen strukturierten Tool-Plan, und die Laufzeit führt ihn außerhalb der normalen Chat-Schleife aus, in der Tools einzeln aufgerufen werden. Dieser Ansatz kann den Tokenverbrauch und die Latenz reduzieren, da Zwischenergebnisse außerhalb des Modellkontexts bleiben und ein vom Modell verfasster Plan mehrere Werkzeugaufrufe darstellen kann.

Dynamische Workflows wenden dieses Muster auf Azure Functions an und fügen eine Dauerhaftigkeits- und Betriebsschicht hinzu:

Wann dynamische Workflows verwendet werden sollten

Nutze dynamische Workflows, wenn eine gehostete Fähigkeit Arbeit ausführen muss, die größer ist als ein einzelner Chat-Turn oder ein direkter Tool-Call. Geeignete Optionen sind:

• Fan-out/fan-in-Muster, die parallel Erkenntnisse aus mehreren unabhängigen Quellen sammeln, beispielsweise aus Protokollen, Metriken und dem Bereitstellungsverlauf.
• Isolierte, von Spezialisten gehostete Skills parallel ausführen und ihre Antworten kombinieren.
• Einen mehrstufigen Plan durchzuführen, bei dem spätere Schritte von früheren Werkzeugergebnissen abhängen.
• Warten auf einen dauerhaften Timer, ohne einen Arbeiter zu beschäftigen.
• Große Zwischenergebnisse bis zum Vorliegen eines endgültigen Ergebnisses oder einer Zusammenfassung aus dem Konversationskontext des gehosteten Skills heraushalten.
• Nachverfolgen und Steuern lang laufender Aufgaben außerhalb der Modellschleife.

Wie ein Workflow funktioniert

Das folgende Diagramm zeigt die Hauptkomponenten der dynamischen Workflow-Architektur:

Ein dynamischer Workflow läuft durch diese Sequenz:

1. Ein Ereignis löst die gehostete Fähigkeit aus oder ein Nutzer sendet eine Anfrage über die Chat-UI.
2. Die gehostete Fähigkeit ruft start_workflow mit einem vom KI-Modell generierten Workflowplan auf.
3. Die Laufzeit startet den Plan als Durable Functions-Orchestrierung und gibt sofort eine Workflow-ID zurück.
4. Der Orchestrator führt einsatzbereite Toolaktivitäten parallel aus und erstellt dauerhafte Timer für wait-Schritte. Es kann auch Aufgaben an von Subagenten gehostete Skills delegieren, die jeweils in einer isolierten, zustandslosen Sitzung ausgeführt werden.
5. Wenn der Workflow einen Endzustand erreicht, benachrichtigt die Laufzeit den gehosteten Skill, der get_workflow_status aufruft und die endgültige Ausgabe zusammenfasst.

Wenn die gehostete Fähigkeit die integrierte Chat-UI verwendet, fragt die Benutzeroberfläche auch den Workflow-Status ab und zeigt eine Fortschrittskarte an.

Zwischenergebnisse bleiben im Workflow-Speicher. Die gehostete Fähigkeit sieht nur die Workflow-ID beim Start und den finalen Status, wenn sie das Ergebnis abruft. Der gehostete Skill wird nicht regelmäßig abgefragt, während der Workflow läuft.

Tools zur Workflow-Verwaltung

Wenn du Workflows aktivierst, fügt die Laufzeit folgende Tools zum gehosteten Skill hinzu:

Die gehostete Fähigkeit ruft diese Tools auf. Benutzer rufen sie im Anwendungscode nicht direkt auf.

Workflow-Unteragenten

Eine Workflow-fähige gehostete Skill kann in ihrer workflows.subagents-Konfiguration den Zugriff auf spezialisierte gehostete Skills ermöglichen. Jeder Spezialist ist eine weitere .agent.mdDatei in derselben gehosteten Skills-App.

Die folgende Frontangelegenheit ermöglicht es dem Koordinator, zwei Spezialisten einzusetzen:

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

Der Wert agent ist der Dateinamen-Slug des Spezialisten. Zum Beispiel bezieht sich pr_status_analyst auf pr_status_analyst.agent.md. Der optionale when Wert hilft dem Modell zu entscheiden, wann der Spezialist eingesetzt wird. Die Laufzeit validiert jeden Spezialisten anhand dieser expliziten Gewährung, bevor der Workflow geplant wird.

Das Modell kann eine sub_agent Workflowaufgabe mit id, agent und einem eigenständigen task generieren. Eine Unteragenten-Aufgabe kann auch when, for_each und depends_on verwenden.

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

Jeder Subagentenaufruf ist zustandslos und isoliert:

• Der Spezialist verwendet sein eigenes Modell, Befehle, Werkzeuge, MCP-Server, Fähigkeiten und Timeout.
• Der Spezialist erhält weder die Gesprächshistorie, Sandbox, Workflow-Management-Tools noch die Chat-Zeit-Delegationstools des Koordinators.
• Das Fehlschlagen eines Spezialisten oder ein Timeout lässt den übergeordneten Workflow fehlschlagen.
• Spezialisierte Werkzeuge sollten eine erneute Ausführung tolerieren, da ein Worker-Fehler dazu führen kann, dass ein Subagent mehr als einmal ausgeführt wird.

Ein End-to-End-Beispiel, das parallele PR-Analysten-Aufgaben ausführt und deren Zusammenfassungen zu einem Bericht zusammenfasst, siehe das Beispiel der Workflow-Unteragenten.

Speicher-Back-End

Dynamische Workflows verwenden intern Durable Functions und unterstützen dieselben Speicher-Backends. Standardmäßig verwenden Workflows das Azure Storage-Konto, das deine Funktions-App bereits hat. Für Produktionsworkloads können Sie auf den Durable Task Scheduler (DTS) umsteigen, der ein Dashboard mit dem Aufgabenstatus pro Instanz, der Wiederholungshistorie und Steuerungen für Arbeiten während des Fluges bereitstellt. Der Anleitungsleitfaden behandelt beide Optionen.

Considerations

Behalte diese aktuellen Einschränkungen im Hinterkopf, wenn du dynamische Workflows nutzt:

• Workflow-sichere Tool-Handler müssen synchron sein und JSON-serialisierbare Werte zurückgeben.
• Das KI-Modell generiert den Workflowplan zur Laufzeit. Man kann keine statischen Workflow-Vorlagen in YAML oder Markdown definieren.
• Du kannst keine Pro-Task-Wiederholungs- und Timeout-Richtlinien konfigurieren.
• Big-Output-Handling und MCP-Aufgaben-Integration sind nicht verfügbar.

Nächste Schritte

Konfigurieren Sie workflow-sichere Tools und führen Sie Ihren Workflow lokal aus:

Verwandte Inhalte

• Dynamische Workflows in Azure Functions Agents Runtime
• In Azure Functions gehostete Skills
• Baue eine ereignisgesteuerte KI-App mit Azure Functions-gehosteten Fähigkeiten
• Beispiel für die Workflow-Vorfall-Triage
• Muster von Workflow-Subagenten
• Übersicht über dauerhafte Funktionen