Agentes temporários AI: Execução duradoura separada da Agente Saúde

Temporal é uma resposta sólida a um problema de agente duro: Como você mantém uma execução de longa duração recuperável quando os trabalhadores caem, processos reiniciam ou uma dependência externa falha? Não é, por si só, uma resposta a uma pergunta diferente: É o agente saudável e produziu o resultado solicitado pelo usuário? O padrão seguro é usar o estado do fluxo de trabalho temporário como evidência de execução, e depois adicionar quatro recibos de inscrição antes de atribuir um veredicto de saúde: 1. Um recibo de progresso que indique um marco significativo ou um delta de saída; 2. Um recibo wait com o nome do proprietário, prazo e condição de prossecução; 3. Um recibo de effect resolvendo se ocorreu uma ação do lado da ferramenta; 4. Um recibo de entrega que comprova o artefato ou estado solicitado. Essa distinção é importante porque o próprio Fluxo de trabalho Documentação de execução da Temporal define o Running como capaz de progredir enquanto progride ativamente o ou espera por algo o . Um fluxo de trabalho aberto e verde não pode, portanto, distinguir trabalho produtivo, uma espera legítima de aprovação ou um estádio silencioso. Da mesma forma, um fluxo de trabalho Completed fechado prova que o seu código atingiu um caminho de conclusão; não prova automaticamente que uma fatura foi enviada uma vez, que um pedido de retirada contém as alterações previstas ou que existe um relatório no destino prometido. O que o Temporal prova e o que não O modelo de execução duradoura do Temporal dá a um agente AI valiosas garantias mecânicas. O estado do fluxo de trabalho persiste em qualquer falha. Reproduzir verificações gerou comandos contra História de Eventos. As atividades isolam chamadas propensas a falhas, como solicitações LLM, uso de ferramentas e API externas do código de orquestração determinista. A explicação oficial do Agentes dinâmicos AI em Temporal torna esta fronteira explícita: a orquestração do fluxo de trabalho deve ser determinista, enquanto as decisões e os resultados das ferramentas do LLM podem permanecer não deterministas dentro das atividades. Estas propriedades respondem a várias questões operacionais: O estado de orquestração gravado pode sobreviver a uma reinicialização dos trabalhadores? O fluxo de trabalho pode retomar a partir do seu histórico gravado em vez de recomputar todas as decisões anteriores do LLM? Uma Atividade ainda está a tentar novamente, terminada, fracassada ou concluída? O Fluxo de Trabalho está aberto, interrompido, cancelado, concluído, falhado, encerrado ou terminado? Não respondem a quatro perguntas específicas do agente: O plano avançou mais perto do objetivo do usuário, ou o ciclo é apenas ativo? Uma pausa é esperada, propriedade e retomável? Houve algum efeito colateral externo, especialmente após um intervalo ou acidente de trabalho? Existe o resultado final e satisfaz uma verificação de aceitação determinista? Isto não é uma crítica ao Temporal. É um limite de responsabilidade. O Implementação do agente da comunidade temporária AI demonstra um loop de agente, chamadas de ferramentas, confirmação humana, sinais, gerenciamento de estado e testes dentro de um fluxo de trabalho. Suas próprias anotações também chamam a longo histórico de conversação, a visibilidade e as considerações de armazenamento de produção. A semântica da aplicação ainda pertence à aplicação. Coloque quatro recibos acima do status do fluxo de trabalho Um recibo compacto pode ser muito menor do que uma transcrição. Ele deve expor evidências, frescura e identidade sem carregar pedidos, ferramentas úteis ou segredos. O recibo do progresso deve descrever um marco da candidatura, não apenas um tempo de batimento cardíaco. Documentos temporários Atividade Batimentos cardíacos como uma forma de um Trabalhador relatar o seu estado de saúde e progresso, preservar os detalhes do progresso para uma nova tentativa e receber cancelamento. Esse transporte é útil, mas a carga útil tem de transportar um delta significativo: contagem de registos processados, conjunto de fontes verificado, IDs de ramo completados, digestão de artefatos ou outra invariante específica da tarefa. Um agente pode emitir uma nova marca de tempo para sempre enquanto repete a mesma chamada falhada. O recibo de espera impede que o erro opostopague uma pausa humana saudável no circuito como um impasse. Exigir três campos: owner : a pessoa ou sistema capaz de resolver a dependência; deadline : quando a espera for atrasada; resumeToken : o sinal, atualização, identificação de aprovação ou outra identidade que retoma o mesmo trabalho. Não ter nenhum dos três faz com que a espera seja operacionalmente incompleta. A espera de aprovação sem um proprietário é um trabalho abandonado. Um proprietário sem prazo pode desaparecer indefinidamente. Um prazo sem identidade de currículo convida a uma continuação duplicada ou desviada. O recebimento do efeito é necessário porque as atividades podem ser retomadas. O Orientação para manipulação de erros em Python da Temporal descreve as atividades como pelo menos uma vez e recomenda a idempotencia: um trabalhador pode completar uma ação externa e acidente antes da conclusão dos registos de serviço. Para um agente, os estados críticos são none , attempted , verified e unknown . O Unknown não é autorizado a tentar novamente. Reconciliar primeiro a identificação de operação estável com o destino. O recibo de entrega fecha a lacuna na outra extremidade. Deve ligar o fluxo de trabalho e executar a identidade para uma verificação determinista: digest de arquivo, versão de banco de dados, ID de recurso HTTP, compromisso combinado, resultado de teste ou um veredicto de aceitação estruturado. Uma mensagem em linguagem natural done é prova de uma alegação, não prova do resultado. Uma experiência de seis casos A fixação inspecionável utilizada para este artigo avalia seis corridas com uma regra determinista: Somente o estado do fluxo de trabalho derrubaria os quatro primeiros casos em RUNNING e os dois últimos em COMPLETED . Os recibos alteram a decisão do operador: Caso Evidências decisivas Ação segura Trabalhar Recentemente , o marco mudou . Deixa o em paz. Esperando Proprietário, prazo, token de retorno rota ou esperar até o prazo Enfiado . Não há delta recente e não há espera válida Investigar, depois preparar uma recuperação limitada Efeito incerto A identificação de operação estável não tem veredicto de destino reconciliar; não tentar novamente Falso sucesso Fluxo de trabalho concluído, mas faltam entregas reabrir o incidente Completos saudáveis Conclusão, efeito e entregable acordo fechar com provas A regra é intencionalmente conservadora. Não utiliza um juiz LLM quando existe uma verificação determinista. Preserva o uncertain quando as evidências discordam. Evitar também "fixar" cada pausa: uma espera válida continua a ser uma espera, não um fracasso. Repetições operacionais e longas histórias sem falso verde O Temporal lida com a mecânica de retestamento, mas o aplicativo ainda possui o orçamento de retestamento e o limite de efeitos. Para cada Atividade externa, carregar um ID de operação estável em todas as tentativas. Regista o veredicto de impotência do destino quando disponível. Separar a falha transitória do transporte da falha permanente da entrada e parar quando o prazo de execução restante não puder acomodar outra tentativa mais reconciliação e verificação de entrega. Para atividades longas, combinar três sinais diferentes: Atividade batimento cardíaco fresco: o Trabalhador se comunicou recentemente? Freshness of milestone: mudou o estado de aplicação útil? O orçamento da tentativa e do prazo: a retomada da tentativa actual ainda está autorizada e capaz de ser concluída? Um batimento cardíaco fresco com um marco inalterado pode ser um ciclo. Um batimento cardíaco obsoleto com um recibo de destino recente pode ser uma falha de comunicação incerta. Uma espera exponencial de retorno pode ser saudável se o seu tempo de espera e orçamento forem explícitos. Nenhuma marca de tempo merece um veredicto verde. O crescimento da história é outro limite. O documento Fluxo de trabalho Limites de execução de História de Eventos limite de 51.200 eventos ou 50 MB, com advertências em 10.240 eventos ou 10 MB. Não converta esses valores datados em constantes universais; verifique a documentação atual e a sua implementação. O padrão duradouro é manter dados de conversação volumosos fora do histórico de fluxo de trabalho quando apropriado, reter identidades e invariantes minimizadas pelo conteúdo e usar Continuar como novo antes que a pressão do histórico se torne uma interrupção. Isso cria uma divisão prática do trabalho: Temporal preserva e retoma o estado de orquestração. A aplicação de agente define marcos, espera propriedade, efeito reconciliação e verificações de aceitação. Uma camada de saúde para o operador une ambos os conjuntos de evidências e mostra incerteza em vez de inventar um veredicto. Mantém a saúde separada da orquestração Para um agente Temporal AI, a execução duradoura é a base, não a pontuação final de saúde. A repetição pode restaurar as decisões gravadas após um acidente. As tentativas de atividade podem recuperar falhas transitórias. Sinais e Atualizações podem levar decisões humanas. Nenhuma dessas mecânicas deve ser estendida para uma alegação de que o agente está progredindo, que um efeito colateral aconteceu exatamente uma vez, ou que o resultado do usuário está presente. Começa com os quatro recibos. Torná los pequenos, frescos e ligados a workflowId , runId e identidades operacionais estáveis. Teste os seis estados desconfortáveis antes da produção. Se o seu painel não pode mostrar waiting , stuck , uncertain e false success separadamente, está escondendo as decisões que um operador realmente precisa tomar. A limitação é semântica: cada fluxo de trabalho deve definir o seu próprio marco significativo e o seu próprio controlo de entregabilidade. Um agente de verificação da fonte e um agente de pagamento não podem compartilhar o mesmo pré digo de aceitação. Quando não exista verificação determinista dos resultados, marque o julgamento e sua confiança; não o converta silenciosamente em fato. A Sidewisp está atualmente em prévia privada. Sua direção de produto é uma camada de saúde de agente AI, mas um adaptador temporário de produção e coleção de agente vivo de saúde não são apresentados aqui como capacidades enviadas. A mudança útil a curto prazo é independente de qualquer produto: manter a prova de durabilidade do Temporal, adicionar os quatro recibos de candidatura e exigir que eles concordam antes de chamar um agente saudável.