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

Program Agent Framework 1.13.0 zawiera drobne zmiany powodujące niezgodność w Python wykonywania przepływu pracy. Większość aplikacji nie wymaga zmian. Zmiany wpływają na aplikacje, które zależą od dokładnych liczb superkroku lub iteracji, ustawianych max_iterations na granicy zbieżności, inspekcji początkowego identyfikatora źródła komunikatów lub założeń dotyczących umieszczania i porządkowania punktów kontrolnych.

Kontekst

Przed 1.13.0 punkt kontrolny nie spełnił w pełni obietnicy przechwycenia stanu przepływu pracy potrzebnego do wznowienia wykonywania z żadnej zarejestrowanej granicy. Funkcja wykonawcza uruchamiania była uruchamiana przed pętlą superkroku i punktu kontrolnego, więc najwcześniejszy punkt kontrolny zawierał dane wyjściowe i zaktualizowany stan funkcji wykonawczej uruchamiania, ale nie oryginalne dane wejściowe przepływu pracy. Podobnie odpowiedzi na zdarzenia żądania zostały dostarczone i przetworzone bez uprzedniego zarejestrowania w punkcie kontrolnym. W rezultacie żaden punkt kontrolny nie może odtworzyć funkcji wykonawczej uruchamiania z oryginalnych danych wejściowych lub odtworzyć kontynuację pętli human-in-the-loop z dostarczonej odpowiedzi.

Zmiany zachowania

Wersja 1.13.0 zamyka te luki. Funkcja wykonawcza uruchamiania jest teraz uruchamiana w pierwszym superkroku, punkt kontrolny wejścia rejestruje początkowe dane wejściowe przed tym superkrokiem, a rekordy punktu kontrolnego wpisu odpowiedzi dostarczone odpowiedzi przed ich przetworzeniem. Razem te zmiany sprawiają, że przepływ pracy z punktem kontrolnym jest uruchamiany w pełni odtwarzalny z danych wejściowych, w tym kontynuacje pętli człowieka w pętli.

Ważna

Te zmiany nie mają wpływu na utworzone punkty kontrolne przed wersją 1.13.0. Istniejące punkty kontrolne pozostają obsługiwane i nadal można je przywrócić po uaktualnieniu.

Zmiany, które mogą wymagać akcji

Area	Przed 1.13.0	W wersji 1.13.0 lub nowszej	Wpływ na użytkownika
Uruchamianie funkcji wykonawczej	Funkcja wykonawcza uruchamiania została uruchomiona przed pętlą superstep.	Dane wejściowe są kolejkowane dla funkcji wykonawczej uruchamiania, która jest uruchamiana w pierwszym superkrokcie.	Każdy nowy przebieg emituje jeden dodatkowy superstep_started i superstep_completed zdarzenie.
Liczba iteracji	Iteracja 1 reprezentowała pierwszy superkrok po uruchomieniu funkcji wykonawczej uruchamiania.	Iteracja 1 uruchamia funkcję wykonawcza uruchamiania. Późniejsze zmiany pracy według jednej iteracji.	Przepływ pracy, który wcześniej wymagał iteracji $N$, musi teraz $N + 1$.
Źródło komunikatów wejściowych	Początkowy komunikat miał zakodowany na stałe identyfikator "Workflow"źródłowy .	Początkowy komunikat jest dostarczany za pośrednictwem wewnętrznej krawędzi funkcji wykonawczej uruchamiania i ma identyfikator INTERNAL_SOURCE_ID(start_executor.id)źródłowy .	Kod, który odczytuje lub filtruje początkowy identyfikator źródła komunikatów, musi używać nowej wartości.

Ulepszenia możliwości odtwarzania

Area	Przed 1.13.0	W wersji 1.13.0 lub nowszej	Poprawa
Początkowy punkt kontrolny	Punkt kontrolny iteracji-0 został utworzony po uruchomieniu funkcji wykonawczej uruchamiania. Przechwycił komunikaty wyjściowe funkcji wykonawczej i zaktualizowany stan, ale nie oryginalne dane wejściowe.	Punkt kontrolny wpisu jest tworzony przed wykonaniem superkroku 1. Rejestruje oryginalne dane wejściowe w kolejce dla funkcji wykonawczej uruchamiania.	Przywrócenie punktu kontrolnego wejścia odtwarza pełne uruchomienie, w tym funkcję wykonawcza uruchamiania.
Punkt kontrolny odpowiedzi	Odpowiedź na zdarzenie żądania została dostarczona bez uprzedniego zarejestrowania w punkcie kontrolnym.	Punkt kontrolny wpisu odpowiedzi jest tworzony po dostarczeniu odpowiedzi i przed uruchomieniem superkroku zużywanego.	Przywrócenie punktu kontrolnego typu response-entry odtwarza kontynuację, która zużywa odpowiedź.

Aktualizowanie obsługi zdarzeń superstep

Nowy przebieg przepływu pracy tworzy teraz jeszcze jedną parę zdarzeń superkrokiem, ponieważ funkcja wykonawcza uruchamiania jest uruchamiana w superkrok 1:

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

Kolejne zmiany wykonywane przez jeden superkrok. Aktualizowanie testów, telemetrii, wskaźników postępu lub innego kodu, który zakłada dokładną liczbę zdarzeń lub mapuje konkretną funkcję wykonawcza na stałą iterację.

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 superkrok, który uruchamia funkcję wykonawcza uruchamiania. 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 funkcja wykonawcza uruchamiania używa identyfikatora źródłowego początkowego komunikatu, zastąp wartość zakodowaną "Workflow" na stałe identyfikatorem źródłowym wewnętrznej krawędzi funkcji wykonawczej uruchamiania.

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żdy nowy przebieg tworzy teraz punkt kontrolny wpisu pod adresem iteration_count == 0. Ten punkt kontrolny zawiera oryginalne dane wejściowe jako komunikat w locie skierowany do funkcji wykonawczej uruchamiania. 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 przebiegu z $N$ superkroków należy oczekiwać $N + 1$ punktów kontrolnych: punkt kontrolny wejścia, po którym następuje jeden punkt kontrolny dla każdego ukończonego superkroku.

Przejrzyj kod, który zakłada, że punkt kontrolny iteracji-0 zawiera stan wygenerowany przez funkcję wykonawcą uruchamiania. Ten stan jest teraz wyświetlany w punkcie kontrolnym utworzonym po wykonaniu superkroku 1.

Punkty kontrolne odpowiedzi na żądanie

Po kontynuowaniu przepływu pracy workflow.run(responses=...)za pomocą programu platforma tworzy teraz punkt kontrolny typu response-entry po kolejce odpowiedzi i przed uruchomieniem superkroku, który z nich korzysta. 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 punkty do tego punktu kontrolnego oczekującego żądania.

Ważna

Nie ma gwarancji, że element iteration_count jest unikatowy w historii punktów kontrolnych w pętli człowieka. Postępuj zgodnie z łańcuchem, previous_checkpoint_id aby określić kolejność punktów kontrolnych. Jeśli potrzebujesz najnowszego punktu kontrolnego, użyj interfejsu API magazynu punktów kontrolnych zamiast wybierania największego iteration_count.

Lista kontrolna migracji

• Aktualizowanie asercji i odbiorców zdarzeń, które zależą od dokładnych liczb superkrokroków lub liczb iteracji.
• Zwiększ max_iterations o jeden tylko przepływy pracy, które osiągnęły poprzedni limit.
• Zastąp początkowe sprawdzanie identyfikatora źródła ciągiem "Workflow"INTERNAL_SOURCE_ID(start_executor.id).
• Traktuj punkt kontrolny iteracji-0 jako punkt kontrolny danych wejściowych przed wykonaniem.
• Kolejność punktów kontrolnych human-in-the-loop według pochodzenia zamiast zakładać iteration_count , że jest unikatowa.
• 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.