Upgrade kontrolních bodů pracovního postupu Python na verzi 1.13.0

Agent Framework 1.13.0 obsahuje menší zásadní změny Python provádění pracovního postupu. Většina aplikací nevyžaduje změny. Změny ovlivňují aplikace, které závisí na přesných počtech superkroků nebo iteračních číslech, nastavených max_iterations na hranici konvergence, kontrole počátečního ID zdroje zprávy nebo vytvoření předpokladů o umístění a řazení kontrolních bodů.

Background

Před verzí 1.13.0 kontrolní bod plně nesplní svůj slib zachycení stavu pracovního postupu potřebného k obnovení provádění z jakékoli zaznamenané hranice. Spouštěcí exekutor běžel před smyčkou superkroku a kontrolního bodu, takže nejstarší kontrolní bod obsahoval výstup a aktualizovaný stav spouštěcího exekutoru, ale ne původní vstup pracovního postupu. Podobně byly odpovědi na události žádosti doručeny a zpracovány, aniž byly nejprve zaznamenány v kontrolním bodě. V důsledku toho žádný checkpoint nemohl z původního vstupu znovu spustit počáteční executor ani z poskytnuté odpovědi zopakovat pokračování human-in-the-loop.

Změny chování

Verze 1.13.0 tyto mezery zavře. Spouštěcí executor se nyní spouští v prvním superkroku, vstupní checkpoint zaznamenává počáteční vstup před tímto superkrokem a checkpoint pro vstup odpovědi zaznamenává doručené odpovědi před jejich zpracováním. Tyto změny společně umožňují, aby byl běh workflow s checkpointy plně znovu přehratelný z jeho vstupu, včetně pokračování se zapojením člověka.

Important

Tyto změny nemají vliv na kontrolní body vytvořené před verzí 1.13.0. Stávající kontrolní body zůstanou podporovány a po upgradu je možné je obnovit.

Změny, které můžou vyžadovat akci

Area	Před 1.13.0	Ve verzi 1.13.0 a novějších verzích	Dopad na uživatele
Spuštění exekutoru	Spouštěcí modul se spustil před smyčkou superkroků.	Vstup je zařazen do fronty pro startovací executor, který běží v prvním superkroku.	Každé nové spuštění generuje jednu další superstep_started událost a superstep_completed událost.
Počet iterací	Iterace 1 představovala první superkrok po spuštění spouštěcího executoru.	Iterace 1 spustí executor Start. Pozdější pracovní směny se posunou o jednu iteraci.	Pracovní postup, který dříve potřeboval iterace $N$, teď potřebuje $N + 1$.
Zdroj vstupní zprávy	Počáteční zpráva měla pevně zakódované zdrojové ID "Workflow".	Úvodní zpráva je doručena prostřednictvím interní hrany spouštěcího vykonavatele a má ID zdroje INTERNAL_SOURCE_ID(start_executor.id).	Kód, který čte nebo filtruje POČÁTEČNÍ ID zdroje zprávy, musí použít novou hodnotu.

Vylepšení možností přehrání

Area	Před 1.13.0	Ve verzi 1.13.0 a novějších verzích	Zlepšení
Počáteční kontrolní bod	Kontrolní bod iterace-0 byl vytvořen po spuštění spouštěcího exekutoru. Zachytil výstupní zprávy exekutoru a aktualizovaný stav, ale ne původní vstup.	Vstupní kontrolní bod se vytvoří před superkrokem 1. Zaznamenává původní vstup zařazený do fronty pro spouštěcí modul.	Obnovením kontrolního bodu vstupu se znovu přehraje celý běh, včetně spouštěcího modulu.
Kontrolní bod odpovědi	Odpověď na událost requestu byla doručena, aniž byla nejprve zaznamenána v kontrolním bodě.	Kontrolní bod pro zadání odpovědi se vytvoří po doručení odpovědi a před spuštěním superkroku.	Obnovením kontrolního bodu zadání odpovědi se znovu přehraje pokračování, které zpracovává odpověď.

Aktualizace zpracování událostí superkroku

Nové spuštění pracovního postupu teď vytvoří ještě jednu dvojici událostí superkroku, protože spouštěcí exekutor běží v superkroku 1:

• superstep_started s iteration == 1
• superstep_completed s iteration == 1

Následná práce executoru se posune o jeden superkrok. Aktualizace testů, telemetrie, indikátorů průběhu nebo jiného kódu, který předpokládá přesný počet událostí nebo mapuje konkrétní exekutor na pevnou iteraci.

Kód, který reaguje na typy událostí, aniž by se spoléhal na jejich počet nebo iteraci, se nemusí měnit.

Kontrola maximálního limitu iterace

Limit max_iterations teď zahrnuje superkrok, který spouští spouštěcí exekutor. Pokud pracovní postup dříve použil úplný limit, zvyšte nakonfigurovanou hodnotu o jednu:

from agent_framework import WorkflowBuilder

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

Pokud už pracovní postup konverguje před dosažením nakonfigurovaného limitu, není potřeba žádná změna.

Aktualizace kontrol zdroje počáteční zprávy

Pokud spouštěcí exekutor využívá ID zdroje počáteční zprávy, nahraďte pevně zakódovanou "Workflow" hodnotu id zdroje pro interní hraniční zařízení spouštěcího exekutoru.

Před 1.13.0:

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

Ve verzi 1.13.0 a novější:

from agent_framework import INTERNAL_SOURCE_ID

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

INTERNAL_SOURCE_ID(executor_id) v současné době vrací "internal:<executor_id>". Místo sestavování tohoto řetězce použijte pomocnou funkci, aby váš kód dodržoval formát ID zdroje daný rámcem.

Aktualizace zpracování kontrolních bodů

Počáteční vstupní kontrolní body

Když je vytváření kontrolních bodů povolené, každé nové spuštění teď vytvoří vstupní kontrolní bod na iteration_count == 0adrese . Tento kontrolní bod obsahuje původní vstup jako zprávu v letu adresovanou spouštěcímu exekutoru. Obnovením znovu spustíte spouštěcí exekutor a reprodukuje se spuštění celého pracovního postupu.

Po každém dokončeném superkroku rámec nadále vytváří kontrolní bod. Při běhu s $N$ superkroky lze očekávat $N + 1$ kontrolních bodů: jeden vstupní kontrolní bod a poté jeden kontrolní bod za každý dokončený superkrok.

Zkontrolujte kód, který předpokládá, že kontrolní bod iterace-0 obsahuje stav vytvořený spouštěcím exekutorem. Tento stav se teď zobrazí v kontrolním bodu vytvořeném po superkroku 1.

Kontrolní body žádosti a odpovědi

Když v pracovním postupu pokračujete pomocí workflow.run(responses=...), framework nyní vytvoří kontrolní bod zadání odpovědi po zařazení odpovědí do fronty a před spuštěním superkroku, který je zpracovává. Obnovením tohoto kontrolního bodu se znovu doručí zaznamenané odpovědi a přehraje zbytek pracovního postupu.

Kontrolní bod pro zadání odpovědi má stejný iteration_count jako předchozí kontrolní bod, který obsahuje čekající požadavek. Jde o samostatný kontrolní bod, jehož previous_checkpoint_id ukazuje na kontrolní bod nevyřízeného požadavku.

Important

iteration_count nemusí být v historii kontrolních bodů se zapojením člověka jedinečný. previous_checkpoint_id Podle řetězce určete pořadí kontrolních bodů. Pokud potřebujete nejnovější kontrolní bod, použijte rozhraní API úložiště kontrolních bodů namísto výběru největšího iteration_count.

Kontrolní seznam pro migraci

• Aktualizujte aserce a odběratele událostí, které závisí na přesných počtech superkroků nebo číslech iterací.
• Zvýšení max_iterations o jeden pouze u pracovních postupů, které dosáhly předchozího limitu.
• Nahraďte počáteční kontroly ID zdroje u "Workflow" za INTERNAL_SOURCE_ID(start_executor.id).
• Považujte kontrolní bod iterace 0 za vstupní kontrolní bod před spuštěním.
• Řaďte kontrolní body se zapojením člověka podle linie, namísto předpokladu, že iteration_count je jedinečné.
• Ověřte, že přehrání vstupního kontrolního bodu a kontrolního bodu pro zadání odpovědi vytvoří očekávaný výstup a vedlejší účinky.

Podrobnosti o implementaci naleznete v části Povolit úplné opětovné přehrání kontrolního bodu workflow.