Loop de agente do AI SDK: prove por que parou

UmAI SDKo loop do agente não está íntegro apenas porque retornou. Um retorno prova que um caminho de fluxo de controle terminou: o modelo terminou sem outra chamada de ferramenta, uma ferramenta não pôde ser executada, foi necessária aprovação ou uma condição de parada configurada foi acionada. Nenhum desses fatos comprova que a fatura foi gerada, o ticket foi atualizado ou o relatório chegou ao destino. O padrão prático é manter o loop limitado do SDK, registrar uma causa de parada explícita e verificar o resultado externo pretendido separadamente. Trate uma solicitação de aprovação como uma espera, uma etapa ou limite de orçamento como uma parada limitada e um término natural sem recebimento de resultado como uma conclusão falsa. Este guia fixa o comportamento ao liberado [email protected] pacote eNode.js22.23.1. A reprodução sem conteúdo que acompanha exerceu as funções reais de condição de parada exportadas em onze casos operacionais. Todas as onze classificações e quatro asserções diretas do SDK foram aprovadas. O SDK pode parar por vários motivos legítimos OGuia de controle de loop do AI SDKnomeia quatro rotas de terminação: 1. o modelo retorna um motivo de término diferente de tool calls ; 2. uma ferramenta chamada não tem execute função; 3. uma chamada de ferramenta precisa de aprovação; 4. uma condição de parada configurada retorna verdadeira. Essas rotas não devem colapsar numa só completed: true campo. Eles implicam diferentes ações do operador. Um acabamento natural sem ferramenta pode ser perfeitamente válido para uma resposta de pesquisa, mas incompleto para um fluxo de trabalho cujo contrato exige um arquivo no armazenamento de objetos. Uma ferramenta sem execute pode agir deliberadamente como uma estrutura done sinal, mas o sinal contém o que o modelo afirmava – não uma evidência independente de que um efeito colateral teve sucesso. Uma solicitação de aprovação é uma pausa intencional. Um limite de etapa significa que o limite de segurança funcionou, não que a tarefa falhou ou foi bem sucedida. A documentação atual diz ToolLoopAgent o padrão é isStepCount(20) . Substituindo o por isLoopFinished() remove essa condição de parada de contagem de passos. Isso pode ser razoável para um experimento local rigidamente controlado, mas também elimina um simples limite nas chamadas de modelo e no custo. Se a aplicação não puder explicar o seu prazo independente, orçamento e controlos de cancelamento, manter o limite padrão é a decisão mais segura. Três pequenos detalhes de implementação mudam o diagnóstico A versão fixadafonte de condição de paradaé curto o suficiente para auditar diretamente: isStepCount(n) é verdade quando steps.length === n , não quando a contagem é maior ou igual a n . hasToolCall(name) inspeciona chamadas de ferramenta na etapa concluída mais recentemente. isLoopFinished() sempre retorna falso como condição de parada, deixando o encerramento natural, uma ferramenta não executada ou aprovação para encerrar o loop. Essa semântica é importante ao reconstruir um incidente. Suponha que um aplicativo persista apenas o texto final e a contagem total de etapas. Uma corrida de três etapas que chamou done na sua segunda etapa não pode mais tarde provar que hasToolCall("done") causou o encerramento, porque a condição relevante verifica a última etapa. Da mesma forma, uma observação de 21 etapas não mostra que isStepCount(20) despedido; é uma evidência de que a política configurada, a contagem registrada ou o limite de execução diferem da suposição. Mantenha as entradas de condição e a versão da política selecionada com a execução. Não os infira a partir de um painel após o fato. Crie um recibo de parada antes de escolher um estado de saúde Um recibo útil é pequeno. Ele não precisa de prompts, respostas de modelo ou cargas brutas de ferramentas: O stopCause deve vir da fronteira de integração, e não de uma suposição baseada na prosa final. Registre se a execução atingiu um término sem ferramenta, correspondeu a uma condição de parada nomeada, emitiu uma solicitação de aprovação, invocou uma ferramenta de conclusão não executada, foi abortada, atingiu o tempo limite ou falhou na execução da ferramenta. Em seguida, aplique uma regra de precedência: Evidência Estado Decisão do operador Falha na execução da ferramenta FAILED Diagnosticar o limite da ferramenta; não tente novamente um efeito colateral incerto cegamente. A aprovação está pendente com proprietário, prazo e token de currículo WAITING Encaminhe a decisão e preserve a retomada. A aprovação está pendente sem dados de roteamento WAITING UNROUTED Adicione um proprietário e um caminho de escalonamento antes que a espera se torne invisível. O tempo limite expirou sem progresso útil STUCK Inspecione o último progresso durável e escolha uma recuperação limitada. Etapa, token ou limite de anulação do usuário disparado BOUNDED STOP Preservar trabalho parcial; decidir se uma nova corrida limitada é justificada. Acabamento natural ou explícito done mais recibo de resultado VERIFIED COMPLETE Feche a corrida. Acabamento natural ou explícito done sem recebimento de resultado FALSE COMPLETE Verifique o destino ou reabra a tarefa. Os sinais discordam ou a causa não foi registrada UNCERTAIN Pergunte antes de agir. A ordem é importante. Um tempo limite na quarta etapa ainda será um tempo limite, mesmo que a contagem de etapas seja igual a quatro. Uma solicitação de aprovação deve permanecer aguardando, em vez de ser levada a um estado genérico incompleto. Um acabamento natural sem entrega deve permanecer falso completo mesmo quando seu texto parece confiante. Repetir a política sem chamar um modelo A auditoria importou o liberado isStepCount , hasToolCall , e isLoopFinished funções. Ele passou matrizes sem conteúdo de registros de etapas concluídas e juntou sua saída ao classificador de recebimento. Nenhuma chamada de modelo, prompt, segredo ou efeito de ferramenta externa foi necessária. Quatro afirmações estabeleceram os limites do SDK: O acessório de onze caixas cobriu o acabamento natural com e sem resultado, done com e sem resultado, limite de etapa, orçamento de token, aprovação roteada e não roteada, erro de ferramenta, tempo limite e anulação do usuário. Os pares reveladores não foram fracassos exóticos. Ambos os equipamentos de acabamento natural tiveram causas de fluxo de controle idênticas; apenas aquele que carregava um recibo de destino tornou se VERIFIED COMPLETE . A mesma divisão apareceu para o done ferramenta. Esse é o principal resultado falsificável: se a terminação do loop por si só provou ser uma conclusão útil, esses equipamentos emparelhados deveriam ter recebido o mesmo veredicto saudável. Eles não fizeram isso. Verifique o destino após a interrupção do fluxo de controle OReferência do ToolLoopAgentexpõe as etapas concluídas no resultado gerado e aceita abortSignal e controles de tempo limite. Esses campos são evidências úteis, mas a aplicação ainda possui a definição de sucesso. Escolha a verificação determinística mais barata que responda à solicitação real do usuário: para um arquivo, verifique o caminho esperado ou a chave do objeto, o tipo de conteúdo, o tamanho mínimo e um hash ou esquema específico da tarefa; para uma mutação de banco de dados, leia o registro de destino e compare os campos pretendidos; para uma mensagem, guarde o recebimento do provedor e a identidade de destino; para uma implantação, verifique a versão imutável, a resposta de saúde pública e a rota voltada para o usuário; para uma análise, valide as seções necessárias, a cobertura da fonte e a saída legível por máquina antes de aceitar a prosa. Não faça do recebimento do resultado uma segunda cópia da afirmação do modelo. {"status":"done"} emitido pelo mesmo loop não é uma verificação independente. O recibo deve vir do destino, de um validador determinístico ou de uma decisão humana quando o resultado não puder ser verificado com segurança por código. A aprovação também precisa de um limite separado. A documentação do SDK mostra que uma solicitação de aprovação pode ser coletada, anexada à conversa como uma resposta de aprovação e passada para uma chamada subsequente. Operacionalmente, isso significa que a espera deve reter contexto suficiente para retomar a mesma decisão. Um proprietário sem token de currículo cria um trabalho de reconstrução manual; um token sem proprietário cria uma fila invisível. O que esta repetição não prova O experimento não invocou um modelo de provedor, transmitiu saída parcial ou executou uma ferramenta externa. Portanto, ele não estabelece comportamento de motivo de término específico do provedor, tempo de cancelamento de rede ou idempotência de efeito colateral. Eles pertencem a testes de integração em torno do modelo, ferramentas e destino reais. Também não recomenda uma etapa universal ou limite de token. Uma pesquisa em quatro etapas e uma migração em quarenta etapas possuem envelopes diferentes. O requisito operacional é que os limites selecionados sejam explícitos, registrados e vinculados a uma ação segura quando alcançados. A regra é mais restrita e durável: preserve o motivo da parada do loop, mantenha as esperas legítimas distintas das falhas e exija evidências de destino antes de declarar uma conclusão útil. Sidewispé uma plataforma de saúde do agente de IA destinada a facilitar a inspeção de evidências, estados de espera, recuperação limitada e verificação de resultados em tempos de execução existentes. Agente de produção coleta sanitária eAI SDKmonitoramento geralmente não são enviados hoje. A Sidewisp está atualmente em prévia privada. Se esse recibo de rescisão corresponder a um modo de falha em seus próprios agentes, a lista de espera de visualização privada será o local apropriado para compartilhar o tempo de execução e o limite de evidências necessários.