Dynamiczne przepływy pracy w umiejętnościach hostowanych w Azure Functions

Dynamiczne przepływy pracy są cechą umiejętności hostowanych w Azure Functions. Pozwalają hostowanej umiejętności rozpocząć długotrwały, wieloetapowy przepływ pracy obejmujący wywołania narzędzi i oczekiwania, bez konieczności pisania kodu orkiestracji w Durable Functions.

Aby uzyskać najnowszą i pełną dokumentację środowiska uruchomieniowego, zobacz Dynamiczne przepływy pracy w środowisku Azure Functions Agents Runtime.

Zamiast wywoływać narzędzia pojedynczo przez pętlę rozmowy, dynamiczne przepływy pracy pozwalają modelowi AI generować uporządkowany plan wywołań narzędzi. Środowisko uruchomieniowe realizuje plan jako orkiestrację Durable Functions, która może się rozgałęziać, czekać, przetrwać ponowne uruchomienia i zachowywać możliwość monitorowania, przy czym tylko wynik końcowy trafia do kontekstu hostowanej umiejętności.

Dlaczego dynamiczne przepływy pracy

Istnieją cztery podstawowe ograniczenia narzędzi wywołujących umiejętności hostowanych bezpośrednio w pętli modelu:

• Koszt symboliczny. Każdy wynik narzędzia pośredniego jest dodawany do kontekstu modelu. Plan wieloetapowy może wydać tokeny na surowe dane, które model musi jedynie podsumować.
• Opóźnienie. Każde bezpośrednie wywołanie narzędzia to kolejna komunikacja z modelem. Długie lub rozgałęzione zadania są wykonywane sekwencyjnie w pętli modelu, zamiast uruchamiać niezależne zadania równolegle.
• Trwałość. Praca wykonywana inline może zostać utracona, jeśli worker zostanie uruchomiony ponownie, a nie ma wbudowanego sposobu na wstrzymanie wykonania do czasu upłynięcia timera ani na oczekiwanie na długotrwały sygnał zewnętrzny.
• Możliwość obserwowania. Operatorzy nie mogą łatwo wypisać, sprawdzić lub odwołać prace podczas lotu bez przejścia przez sesję czatu.

Dynamiczne przepływy pracy eliminują te ograniczenia, przenosząc wykonywanie planu do niezawodnej orkiestracji. Umiejętność hostowana rozpoczyna przepływ pracy, otrzymuje identyfikator przepływu pracy i może zakończyć swoją kolej. Orchestrator uruchamia narzędzia bezpieczne dla przepływu pracy oraz trwałe timery. Interfejs czatu i powierzchnie operacyjne mogą niezależnie śledzić przepływ pracy, a hostowana umiejętność wznawia działanie po zakończeniu przepływu pracy.

Jak dynamiczne przepływy pracy odnoszą się do programowego wywoływania narzędzi

Dynamiczne przepływy pracy mają strukturę podobną do stosowanego przez Anthropic programistycznego wzorca wywoływania narzędzi. W tym wzorcu model tworzy ustrukturyzowany plan użycia narzędzi, a środowisko wykonawcze realizuje go poza standardową pętlą czatu z sekwencyjnym wywoływaniem narzędzi. Takie podejście może zmniejszyć zużycie tokenów i opóźnienia, ponieważ wyniki pośrednie pozostają poza kontekstem modelu, a jeden plan stworzony przez model może reprezentować wiele wywołań narzędzi.

Dynamiczne przepływy pracy wykorzystują ten wzorzec w usłudze Azure Functions i dodają warstwę trwałości i operacyjną:

Kiedy stosować dynamiczne przepływy pracy

Stosuj dynamiczne przepływy pracy, gdy hostowana umiejętność musi wykonać zadania większe niż jedna tura czatu czy bezpośrednie wywołanie narzędzi. Dobre dopasowania obejmują:

• Wzorce fan-out/fan-in, które równolegle zbierają dane z kilku niezależnych źródeł, takich jak logi, metryki i historia wdrożeń.
• Równoległe uruchamianie izolowanych hostowanych umiejętności specjalistycznych i łączenie ich odpowiedzi.
• Prowadzenie planu wieloetapowego, gdzie kolejne etapy zależą od wcześniejszych wyników narzędzi.
• Czekanie na trwały timer bez zajęcia pracownika.
• Utrzymywanie dużych wyników pośrednich poza kontekstem rozmowy hostowanej funkcji do momentu uzyskania ostatecznego wyniku lub podsumowania.
• Śledzenie i kontrola długotrwałej pracy spoza pętli modelu.

Jak działa workflow

Poniższy diagram przedstawia główne elementy architektury dynamicznego przepływu pracy:

Dynamiczny przepływ pracy przebiega przez tę sekwencję:

1. Wydarzenie uruchamia hostowaną umiejętność lub użytkownik wysyła żądanie przez interfejs czatu.
2. Hostowana umiejętność wywołuje start_workflow z planem przepływu pracy wygenerowanym przez model AI.
3. Środowisko uruchomieniowe rozpoczyna plan jako orkiestrację Durable Functions i natychmiast zwraca identyfikator przepływu pracy.
4. Orkiestrator uruchamia równolegle gotowe działania narzędzi i tworzy trwałe timery dla kroków wait. Może także delegować pracę do umiejętności hostowanych przez subagenta, z których każda działa w izolowanej, bezstanowej sesji.
5. Gdy przepływ pracy osiąga stan końcowy, środowisko uruchomieniowe powiadamia hostowaną umiejętność, która wywołuje get_workflow_status i podsumowuje wynik końcowy.

Gdy hostowana umiejętność korzysta z wbudowanego interfejsu czatu, interfejs również sprawdza status workflow i pokazuje kartę postępu.

Wyniki pośrednie pozostają w magazynie workflow. Hostowana funkcja widzi identyfikator przepływu pracy tylko w momencie uruchomienia oraz końcowy status, gdy pobiera wynik. Hostowana umiejętność nie pyta podczas działania workflow.

Narzędzia do zarządzania przepływem pracy

Gdy włączasz workflow, runtime dodaje te narzędzia do hostowanej umiejętności:

Hostowana umiejętność wywołuje te narzędzia. Użytkownicy nie wywołują ich bezpośrednio w kodzie aplikacji.

Podagenci przepływu pracy

Hostowana umiejętność obsługująca przepływ pracy może przyznawać dostęp do specjalistycznych hostowanych umiejętności w swojej konfiguracji workflows.subagents. Każdy specjalista to kolejny .agent.md plik w tej samej hostowanej aplikacji do umiejętności.

Poniższe materiały wstępne pozwalają koordynatorowi korzystać z dwóch specjalistów:

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

Wartość agent to identyfikator nazwy pliku specjalisty. Na przykład odnosi pr_status_analyst się do pr_status_analyst.agent.md. Wartość opcjonalna when pomaga modelowi zdecydować, kiedy użyć specjalisty. Runtime weryfikuje każdego specjalistę pod kątem tego konkretnego grantu przed zaplanowaniem workflow.

Model może wygenerować zadanie przepływu pracy sub_agent z id, agent oraz samodzielnym task. Zadanie podrzędnego agenta może również korzystać z depends_on, when oraz for_each.

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

Każde wywołanie subagenta jest bezstanowe i izolowane:

• Specjalista korzysta z własnego modelu, instrukcji, narzędzi, serwerów MCP, umiejętności oraz limitu czasu.
• Specjalista nie otrzymuje historii konwersacji koordynatora, sandboxa, narzędzi do zarządzania przepływem prac ani narzędzi do delegowania czatu.
• Awaria specjalisty lub przerwa czasowa powoduje awarię w procesie nadrzędnym.
• Specjalistyczne narzędzia powinny być odporne na ponowne uruchomienie, ponieważ awaria procesu roboczego może sprawić, że podagent zostanie uruchomiony więcej niż raz.

Kompletny przykład, który równolegle wykonuje zadania analizy PR i łączy ich podsumowania w raport, znajdziesz w przykładzie podagentów przepływu pracy.

Zaplecze magazynu

Dynamiczne przepływy pracy wewnętrznie korzystają z Durable Functions i obsługują te same backendy pamięci masowej. Domyślnie workflow korzysta z konta Azure Storage, które Twoja aplikacja funkcjonalna już posiada. W przypadku obciążeń produkcyjnych możesz przejść na Durable Task Scheduler (DTS), który zapewnia dashboard z każdym stanem zadania, historią powtórek i kontrolami dla pracy w locie. Poradnik obejmujący obie opcje.

Zagadnienia do rozważenia

Miej na uwadze obecne ograniczenia przy korzystaniu z dynamicznych przepływów pracy:

• Programy obsługi narzędzi bezpieczne dla przepływu pracy muszą być synchroniczne i zwracać wartości serializowalne do formatu JSON.
• Model AI generuje plan przepływu pracy w czasie działania. Nie da się zdefiniować statycznych szablonów workflow w YAML ani Markdown.
• Nie da się skonfigurować polityk powtórek i limitu czasu dla poszczególnych zadań.
• Obsługa dużych wyjść i integracja z zadaniami MCP nie są dostępne.

Następne kroki

Konfiguruj narzędzia bezpieczne dla przepływu pracy i uruchamiaj swój workflow lokalnie:

Treści powiązane

• Dynamiczne przepływy pracy w środowisku uruchomieniowym Azure Functions Agents Runtime
• Umiejętności hostowane w usłudze Azure Functions
• Stwórz aplikację AI opartą na zdarzeniach z umiejętnościami hostowanymi w Azure Functions
• Przykład przepływu pracy klasyfikacji incydentów
• Próbka podagentów workflow
• Omówienie rozszerzenia Durable Functions