Porque é que os agentes de IA domésticos se esquecem das ações concluídas depois de reiniciar um serviço?
Os agentes de IA domésticos esquecem as ações concluídas após um reinício quando o respetivo plano, os resultados das ferramentas e os marcadores de conclusão existem apenas na memória volátil do processo.
Um agente pode atualizar um ficheiro, criar um evento, reiniciar um contentor ou concluir parte de um lote e, ainda assim, perder essa informação quando o serviço é reimplementado ou falha. O efeito externo pode persistir, enquanto a conversa com o modelo, o contador do ciclo, o plano pendente e o objeto com o resultado da ferramenta desaparecem. Após o arranque, o agente pode repetir o trabalho ou presumir que nada aconteceu. Uma recuperação duradoura exige guardar o estado de execução em limites que liguem a intenção, a chamada da ferramenta, o resultado observável e o passo seguinte por concluir.
O histórico da conversa não é um estado de fluxo de trabalho duradouro
Uma transcrição de chat pode conter o pedido do utilizador e a narração do agente, mas pode não registar quais efeitos secundários foram confirmados, quais registos foram ignorados ou qual ramo deve ser retomado.
O guia da Augment Code sobre o estado persistente do fluxo de trabalho separa a execução prolongada de um único processo ou pedido síncrono.
O agente precisa de um estado estruturado, como o ID da tarefa, o passo atual, as operações concluídas, os hashes dos resultados das ferramentas, as aprovações pendentes e o número de novas tentativas. Regenerar esse estado a partir de um chat em linguagem natural após um reinício é ambíguo.
As chamadas de ferramentas concluídas precisam de um limite de confirmação duradouro
Uma ferramenta pode ter êxito externamente antes de o agente escrever o seu marcador de conclusão local. Um reinício nesse intervalo deixa a ação efetivamente realizada, mas o agente não tem conhecimento dela.
A Zylos descreve limites de execução duradoura que preservam o trabalho concluído antes de a recuperação prosseguir.
Um limite fiável regista o ID da operação e o resultado num armazenamento duradouro, ou utiliza um único serviço transacional que possa confirmar simultaneamente o efeito secundário e o registo de conclusão.
Quando a confirmação atómica é impossível, a ferramenta deve disponibilizar uma consulta de estado para que o agente reiniciado possa reconciliar resultados incertos.
Um instantâneo, por si só, pode não reconstruir uma execução segura
Guardar as mensagens do modelo ou um estado serializado do grafo regista aquilo em que o agente acreditava num determinado momento. Isso não garante automaticamente que as chamadas externas não sejam duplicadas durante a repetição.
A Diagrid distingue os pontos de controlo da aplicação dos ambientes de execução que gerem as novas tentativas, o histórico de eventos e a conclusão dos efeitos secundários.
O desenho da recuperação tem de definir que código é determinístico, que chamadas de ferramentas podem ser repetidas e que resultados são lidos do histórico em vez de serem executados novamente.
Caso contrário, um ponto de controlo correto pode ainda retomar a execução com uma mensagem duplicada, uma movimentação de ficheiro repetida ou um segundo comando para um dispositivo.
Identidades estáveis de execução e de passo evitam iniciar acidentalmente uma tarefa nova
Após um reinício, um novo ID de conversa ou de execução pode fazer com que o mesmo objetivo do utilizador pareça uma tarefa nova. Nesse caso, o agente não tem uma chave para encontrar o estado antigo.
A Inference.sh explica como a identidade duradoura da execução permite a um agente retomar a partir do ponto de controlo concluído mais recente.
Guarde o ID do fluxo de trabalho fora do contentor e associe-o ao utilizador, à tarefa, ao âmbito dos dados e à autorização. A descoberta de serviços e o balanceamento de carga não devem criar uma nova execução lógica apenas porque outro trabalhador recebe o pedido.
Os passos concluídos devem ser reutilizados em vez de novamente analisados
Voltar a executar chamadas anteriores do modelo pode produzir um plano diferente, argumentos de ferramentas diferentes ou uma interpretação diferente sobre o trabalho concluído.
O artigo da Pydantic sobre o ambiente de execução afirma que os pontos de controlo concluídos permanecem concluídos, enquanto a recuperação repete apenas o limite que falhou.
Isto reduz o custo de tokens e impede que um agente reiniciado invente uma segunda rota através de sistemas domésticos já modificados.
Os resultados armazenados devem incluir provas suficientes para validar que a saída da ferramenta ainda corresponde ao estado atual do alvo.
A idempotência e a reconciliação protegem a recuperação contra efeitos duplicados
O estado duradouro pode ainda estar um passo atrás do sistema externo. IDs de operações, chaves de idempotência, verificações de estado e ações compensatórias ajudam a lidar com essa incerteza.
O guia da Restate sobre ciclos de agentes resilientes mantém o estado da iteração entre reinícios e permite uma continuação controlada.
O artigo da ZimaSpace sobre automação segura de repetir mostra por que motivo um estado final pretendido é mais seguro do que repetir cegamente comandos aditivos.
Quando não é possível tornar a ação idempotente, o agente reiniciado deve reconciliar o estado atual ou interromper a execução para revisão, em vez de presumir que um registo local em falta significa uma falha.
Os testes de reinício devem incluir todas as janelas de falha
Termine o serviço antes de uma chamada de ferramenta, durante a chamada, após o efeito externo, depois do ponto de controlo local e enquanto aguarda aprovação. Cada reinício deve produzir uma continuação previsível.
A DBOS descreve a execução resistente a falhas para fluxos de trabalho que incluem APIs e interação humana.
Audite se as ações concluídas são reutilizadas, se as ações incertas são reconciliadas, se as ações pendentes permanecem pendentes e se nenhuma autorização é regenerada silenciosamente.
O agente só se lembra do trabalho concluído quando o progresso é armazenado como prova operacional duradoura — não apenas como texto que o processo antigo mantinha por acaso.
Perguntas frequentes
Guardar a transcrição do chat é suficiente?
Não. A transcrição pode omitir IDs de operações, efeitos secundários confirmados, estado das novas tentativas, aprovações e o limite preciso a partir do qual a execução deve ser retomada.
O agente deve repetir todas as chamadas de ferramentas após um reinício?
Não. As chamadas concluídas devem ser reutilizadas a partir do histórico duradouro, enquanto as chamadas incertas exigem idempotência ou reconciliação antes de qualquer nova tentativa.
Um ponto de controlo numa base de dados pode impedir todas as ações duplicadas?
Não. Tem de ser coordenado com o efeito secundário externo. Uma falha entre o efeito e o ponto de controlo continua a criar um resultado incerto.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Que funcionalidades permitem criar um limite de confiança de IA doméstico em torno de ficheiros sensíveis?
Uma fronteira de confiança para IA doméstica combina encriptação em repouso, permissões de privilégio mínimo, sandboxing em tempo de execução e recuperação com âmbito...
O que faz com que os resultados de pesquisa privada favoreçam ficheiros editados com frequência?
Os ficheiros editados frequentemente obtêm vantagens no posicionamento quando cada atualização acrescenta sinais de atualidade, fragmentos, versões ou interação, sem normalização por fonte.
O que faz com que os modelos de presença de casas inteligentes confundam visitantes com residentes?
Os visitantes podem parecer residentes quando o sistema observa padrões de atividade doméstica, mas não dispõe de um sinal de identidade estável da pessoa...
