Atualizar Python pontos de verificação de fluxo de trabalho para 1.13.0

O Agent Framework 1.13.0 contém pequenas alterações significativas no Python execução do fluxo de trabalho. A maioria dos aplicativos não exige alterações. As alterações afetam aplicativos que dependem de contagens exatas de superstep ou números de iteração, definidos max_iterations no limite de convergência, inspecionam a ID de origem da mensagem inicial ou fazem suposições sobre o posicionamento e a ordenação do ponto de verificação.

Tela de fundo

Antes da 1.13.0, o ponto de verificação não cumpria totalmente sua promessa de capturar o estado de fluxo de trabalho necessário para retomar a execução de qualquer limite registrado. O executor inicial foi executado antes do loop de superstep e do ponto de verificação, de modo que o ponto de verificação mais antigo continha a saída do executor inicial e o estado atualizado, mas não a entrada de fluxo de trabalho original. Da mesma forma, as respostas aos eventos de solicitação foram entregues e processadas sem primeiro serem registradas em um ponto de verificação. Como resultado, nenhum ponto de verificação pode reproduzir o executor inicial da entrada original ou reproduzir uma continuação humana no loop da resposta entregue.

Alterações de comportamento

A versão 1.13.0 fecha essas lacunas. O executor inicial agora é executado no primeiro superstep, um ponto de verificação de entrada registra a entrada inicial antes desse superstep e um ponto de verificação de entrada de resposta registra as respostas entregues antes de serem processadas. Juntas, essas alterações tornam um fluxo de trabalho com ponto de verificação totalmente reproduzido de sua entrada, incluindo continuações humanas no loop.

Alterações que podem exigir ação

Melhorias na reprodução

Atualizar o tratamento de eventos superstep

Uma nova execução de fluxo de trabalho agora produz mais um par de eventos de superstep porque o executor inicial é executado no superstep 1:

• superstep_started com iteration == 1
• superstep_completed com iteration == 1

Turnos de trabalho do executor subsequentes por um superespasto. Atualizar testes, telemetria, indicadores de progresso ou outro código que pressupõe uma contagem exata de eventos ou mapeia um executor específico para uma iteração fixa.

O código que responde a tipos de eventos sem depender de sua contagem ou iteração não precisa ser alterado.

Examinar o limite máximo de iteração

O max_iterations limite agora inclui o superstep que executa o executor inicial. Se um fluxo de trabalho usou anteriormente seu limite completo, aumente o valor configurado em um:

from agent_framework import WorkflowBuilder

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

Nenhuma alteração será necessária se o fluxo de trabalho já convergir antes de atingir o limite configurado.

Atualizar verificações iniciais de origem da mensagem

Se um executor inicial consumir a ID de origem da mensagem inicial, substitua o valor codificado "Workflow" pela ID de origem da borda interna do executor inicial.

Antes da 1.13.0:

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

Na versão 1.13.0 e posterior:

from agent_framework import INTERNAL_SOURCE_ID

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

INTERNAL_SOURCE_ID(executor_id) atualmente retorna "internal:<executor_id>". Use o auxiliar em vez de construir essa cadeia de caracteres para que o código siga o formato de ID de origem da estrutura.

Atualizar tratamento de ponto de verificação

Pontos de verificação de entrada iniciais

Quando o ponto de verificação está habilitado, cada nova execução agora cria um ponto de verificação de entrada em iteration_count == 0. Esse ponto de verificação contém a entrada original como uma mensagem de pré-lançamento endereçada ao executor inicial. Restaurá-lo executa novamente o executor inicial e reproduz a execução completa do fluxo de trabalho.

Após cada superstep concluído, a estrutura continua a criar um ponto de verificação. Para uma execução com $N$ supersteps, espere $N + 1$ pontos de verificação: o ponto de verificação de entrada seguido por um ponto de verificação para cada superespasta concluída.

Examine o código que pressupõe que o ponto de verificação de iteração 0 contém o estado produzido pelo executor inicial. Esse estado agora aparece no ponto de verificação criado após a superespasp 1.

Pontos de verificação de solicitação-resposta

Quando você continua um fluxo de trabalho com workflow.run(responses=...), a estrutura agora cria um ponto de verificação de entrada de resposta depois de enfileirar as respostas e antes de executar o superstep que as consome. Restaurar esse ponto de verificação entrega novamente as respostas gravadas e reproduza o restante do fluxo de trabalho.

O ponto de verificação de entrada de resposta tem o mesmo iteration_count ponto de verificação anterior que contém a solicitação pendente. É um ponto de verificação separado cujos previous_checkpoint_id pontos para esse ponto de verificação de solicitação pendente.

Lista de verificação de migração

• Atualize as declarações e os consumidores de eventos que dependem de contagens exatas ou números de iteração.
• Aumente max_iterations em um apenas para fluxos de trabalho que atingiram o limite anterior.
• Substitua as verificações iniciais de ID de origem por "Workflow"INTERNAL_SOURCE_ID(start_executor.id).
• Trate o ponto de verificação de iteração 0 como o ponto de verificação de entrada de pré-execução.
• Ordene pontos de verificação humanos no loop por linhagem em vez de supondo que iteration_count seja exclusivo.
• Verifique se a reprodução de um ponto de verificação de entrada e um ponto de verificação de entrada de resposta produz os efeitos colaterais e de saída esperados.

Para obter detalhes sobre a implementação, consulte Permitir a reprodução completa do ponto de verificação de fluxo de trabalho.