Uppgradera Python arbetsflödeskontrollpunkter till 1.13.0

Agent Framework 1.13.0 innehåller mindre brytande ändringar i körningen av arbetsflöden i Python. De flesta program kräver inte ändringar. Ändringarna påverkar applikationer som är beroende av exakta superstegsantal eller iterationsnummer, som anger max_iterations vid konvergensgränsen, inspekterar käll-ID:t för det första meddelandet eller gör antaganden om placering och ordningsföljd för kontrollpunkter.

Background

Före 1.13.0 uppfyllde kontrollpunkterna inte helt sitt löfte om att samla in arbetsflödestillståndet som krävs för att återuppta körningen från någon inspelad gräns. Startexekveraren kördes före superstep- och checkpointslingan, så den tidigaste kontrollpunkten innehöll startexekverarens utdata och uppdaterade tillstånd, men inte arbetsflödets ursprungliga indata. På samma sätt levererades och bearbetades svar på begärandehändelser utan att först registreras i en kontrollpunkt. Därför kunde ingen checkpoint köra om startexekveraren från den ursprungliga indatan eller återskapa en fortsättning med mänsklig inblandning utifrån det levererade svaret.

Beteendeförändringar

Version 1.13.0 stänger dessa luckor. Startköraren körs nu under det första supersteget, en ingångskontrollpunkt registrerar de ursprungliga indata före det supersteget, och en svarsingångskontrollpunkt registrerar levererade svar innan de bearbetas. Tillsammans gör dessa ändringar att ett arbetsflöde med kontrollpunkter kan köras om fullt ut utifrån sina indata, inklusive fortsättningar med mänsklig medverkan.

Ändringar som kan kräva åtgärd

Förbättringar av omspelsbarhet

Uppdatera händelsehantering med supersteg

En ny körning av arbetsflödet ger nu ytterligare ett par superstegshändelser eftersom startexekveraren körs i supersteg 1:

• superstep_started med iteration == 1
• superstep_completed med iteration == 1

Efterföljande executor-arbetsskift med ett supersteg. Uppdatera tester, telemetri, förloppsindikatorer eller annan kod som förutsätter ett exakt händelseantal eller mappar en viss köre till en fast iteration.

Kod som svarar på händelsetyper utan att förlita sig på deras antal eller iteration behöver inte ändras.

Granska den maximala iterationsgränsen

Gränsen max_iterations omfattar nu supersteget som kör start-exekveraren. Om ett arbetsflöde tidigare använde sin fullständiga gräns ökar du det konfigurerade värdet med en:

from agent_framework import WorkflowBuilder

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

Ingen ändring krävs om arbetsflödet redan konvergerar innan det når den konfigurerade gränsen.

Uppdatera de första källkontrollerna för meddelanden

Om en start-exekverare förbrukar käll-ID:t för det inledande meddelandet, ersätter du det hårdkodade värdet "Workflow" med käll-ID:t för start-exekverarens interna kant.

Före 1.13.0:

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

I 1.13.0 och senare:

from agent_framework import INTERNAL_SOURCE_ID

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

INTERNAL_SOURCE_ID(executor_id) returnerar för närvarande "internal:<executor_id>". Använd hjälpen i stället för att skapa den här strängen så att koden följer ramverkets käll-ID-format.

Uppdatera kontrollpunktshantering

Inledande kontrollpunkter för indata

När checkpoints är aktiverade skapar varje ny körning nu en ingångskontrollpunkt vid iteration_count == 0. Den här kontrollpunkten innehåller den ursprungliga inmatningen som ett pågående meddelande adresserat till startexekveraren. När du återställer den körs startexekveraren igen och hela arbetsflödeskörningen återskapas.

När varje slutfört supersteg fortsätter ramverket att skapa en kontrollpunkt. För en körning med $N$ supersteg kan du förvänta dig $N + 1$ kontrollpunkter: den inledande kontrollpunkten följd av en kontrollpunkt för varje slutfört supersteg.

Granska kod som förutsätter att kontrollpunkten för iteration 0 innehåller tillstånd som producerats av startexekveraren. Det tillståndet visas nu i kontrollpunkten som skapades efter supersteg 1.

Kontrollpunkter för begärandesvar

När du fortsätter ett arbetsflöde med workflow.run(responses=...) skapar ramverket nu en kontrollpunkt för svarsinmatning efter att ha lagt svaren i kö och innan supersteget som förbrukar dem körs. Om du återställer den här kontrollpunkten får du de inspelade svaren igen och resten av arbetsflödet spelas upp igen.

Kontrollpunkten för svarsinmatning har samma iteration_count som föregående kontrollpunkt som innehåller den väntande begäran. Det är en separat checkpunkt vars previous_checkpoint_id pekar på checkpunkten för den väntande begäran.

Checklista för migrering

• Uppdatera asserteringar och händelsekonsumenter som är beroende av det exakta antalet superstep eller iterationsnummer.
• Öka max_iterations endast med en för arbetsflöden som nådde den tidigare gränsen.
• Ersätt inledande käll-ID-kontroller för "Workflow" med INTERNAL_SOURCE_ID(start_executor.id).
• Behandla iteration-0-kontrollpunkten som kontrollpunkt för indata före körning.
• Beställ kontrollpunkter för människor i loopen efter ursprung i stället för att anta iteration_count att det är unikt.
• Kontrollera att uppspelning av en inmatningskontrollpunkt och en svarsinmatningskontrollpunkt ger förväntade utdata och biverkningar.

Mer information om implementering finns i Tillåt fullständig omspelning av kontrollpunkter för arbetsflöden.