Uaktualnianie punktów kontrolnych przepływu pracy Python do wersji 1.13.0

Agent Framework 1.13.0 zawiera niewielkie niekompatybilne zmiany w wykonywaniu przepływów pracy w języku Python. Większość aplikacji nie wymaga zmian. Zmiany wpływają na aplikacje, które zależą od dokładnej liczby superkroków lub iteracji, ustawiają max_iterations na granicy zbieżności, sprawdzają identyfikator źródła komunikatu początkowego lub zakładają określone rozmieszczenie i kolejność punktów kontrolnych.

Kontekst

Przed wersją 1.13.0 mechanizm punktów kontrolnych nie w pełni realizował swoją obietnicę uchwycenia stanu przepływu pracy potrzebnego do wznowienia wykonywania od dowolnego zapisanego punktu. Egzekutor startowy został uruchomiony przed pętlą superkroków i punktów kontrolnych, więc najwcześniejszy punkt kontrolny zawierał dane wyjściowe egzekutora startowego oraz zaktualizowany stan, ale nie oryginalne dane wejściowe przepływu pracy. Podobnie, odpowiedzi na zdarzenia żądań były dostarczane i przetwarzane bez uprzedniego zapisania ich w punkcie kontrolnym. W rezultacie żaden punkt kontrolny nie mógł odtworzyć egzekutora startowego na podstawie oryginalnych danych wejściowych ani odtworzyć kontynuacji z udziałem człowieka na podstawie dostarczonej odpowiedzi.

Zmiany zachowania

Wersja 1.13.0 zamyka te luki. Egzekutor startowy jest teraz uruchamiany w pierwszym superkroku, wejściowy punkt kontrolny rejestruje początkowe dane wejściowe przed tym superkrokiem, a punkt kontrolny wejścia odpowiedzi rejestruje dostarczone odpowiedzi przed ich przetworzeniem. Łącznie zmiany te sprawiają, że przepływ pracy z punktami kontrolnymi można w pełni odtworzyć na podstawie danych wejściowych, w tym także kontynuacje z udziałem człowieka.

Zmiany, które mogą wymagać akcji

Ulepszenia możliwości odtwarzania

Aktualizowanie obsługi zdarzeń superstep

Nowe uruchomienie przepływu pracy powoduje wygenerowanie jeszcze jednej pary zdarzeń superkroku, ponieważ egzekutor startowy działa w superkroku 1:

• superstep_started Z iteration == 1
• superstep_completed Z iteration == 1

Kolejne operacje wykonywane przez wykonawcę są przesunięte o jeden superkrok. Zaktualizuj testy, telemetrię, wskaźniki postępu lub inne fragmenty kodu, które zakładają dokładną liczbę zdarzeń albo przypisują konkretnego egzekutora do stałej iteracji.

Kod, który odpowiada na typy zdarzeń bez polegania na ich liczbie lub iteracji, nie musi się zmieniać.

Przejrzyj maksymalny limit iteracji

Limit max_iterations obejmuje teraz także superkrok uruchamiający egzekutor startowy. Jeśli przepływ pracy wcześniej używał pełnego limitu, zwiększ skonfigurowaną wartość o jedną:

from agent_framework import WorkflowBuilder

workflow = WorkflowBuilder(
    start_executor=start_executor,
    max_iterations=previous_max_iterations + 1,
).build()

Nie jest wymagana żadna zmiana, jeśli przepływ pracy jest już zbieżny przed osiągnięciem skonfigurowanego limitu.

Aktualizowanie początkowych testów źródła komunikatów

Jeśli egzekutor startowy wykorzystuje źródłowy identyfikator komunikatu początkowego, zastąp zakodowaną na stałe wartość "Workflow" źródłowym identyfikatorem wewnętrznej krawędzi egzekutora startowego.

Przed 1.13.0:

is_workflow_input = ctx.source_executor_ids != ["Workflow"]

W wersji 1.13.0 lub nowszej:

from agent_framework import INTERNAL_SOURCE_ID

is_workflow_input = ctx.source_executor_ids != [INTERNAL_SOURCE_ID(self.id)]

INTERNAL_SOURCE_ID(executor_id) obecnie zwraca wartość "internal:<executor_id>". Użyj pomocnika zamiast konstruowania tego ciągu, aby kod był zgodny z formatem identyfikatora źródłowego platformy.

Aktualizowanie obsługi punktów kontrolnych

Początkowe punkty kontrolne danych wejściowych

Po włączeniu tworzenia punktów kontrolnych każde nowe uruchomienie tworzy teraz początkowy punkt kontrolny w lokalizacji iteration_count == 0. Ten punkt kontrolny zawiera oryginalne dane wejściowe jako wiadomość w trakcie przetwarzania skierowaną do egzekutora startowego. Przywrócenie go ponownie uruchamia funkcję wykonawczej uruchamiania i odtwarza pełny przebieg przepływu pracy.

Po wykonaniu każdego ukończonego superkroku struktura nadal tworzy punkt kontrolny. W przypadku uruchomienia obejmującego $N$ superkroków należy się spodziewać $N + 1$ punktów kontrolnych: początkowego punktu kontrolnego oraz po jednym punkcie kontrolnym dla każdego ukończonego superkroku.

Przejrzyj kod, który zakłada, że punkt kontrolny iteracji 0 zawiera stan utworzony przez egzekutor startowy. Ten stan jest teraz wyświetlany w punkcie kontrolnym utworzonym po wykonaniu superkroku 1.

Punkty kontrolne odpowiedzi na żądanie

Gdy kontynuujesz przepływ pracy za pomocą workflow.run(responses=...), framework tworzy teraz punkt kontrolny typu response-entry po umieszczeniu odpowiedzi w kolejce i przed uruchomieniem superkroku, który je przetwarza. Przywrócenie tego punktu kontrolnego ponownie dostarcza zarejestrowane odpowiedzi i odtwarza resztę przepływu pracy.

Punkt kontrolny typu response-entry ma taki sam iteration_count jak poprzedni punkt kontrolny zawierający oczekujące żądanie. Jest to oddzielny punkt kontrolny, którego previous_checkpoint_id wskazuje na punkt kontrolny oczekującego żądania.

Lista kontrolna migracji

• Zaktualizuj asercje i konsumentów zdarzeń, które zależą od dokładnej liczby superkroków lub iteracji.
• Zwiększ max_iterations o 1 tylko dla przepływów pracy, które osiągnęły poprzedni limit.
• Zastąp początkowe sprawdzanie identyfikatora źródła dla "Workflow" elementem INTERNAL_SOURCE_ID(start_executor.id).
• Traktuj punkt kontrolny iteracji 0 jako punkt kontrolny danych wejściowych przed wykonaniem.
• Sortuj punkty kontrolne z udziałem człowieka według pochodzenia, zamiast zakładać, że element iteration_count jest unikatowy.
• Sprawdź, czy ponowne utworzenie punktu kontrolnego wejścia i punktu kontrolnego odpowiedzi powoduje wygenerowanie oczekiwanych danych wyjściowych i skutków ubocznych.

Aby uzyskać szczegółowe informacje o implementacji, zobacz Zezwalaj na pełne odtwarzanie punktu kontrolnego przepływu pracy.