Observabilidade do agente para a fome de fila: Idade de execução da pista

A observabilidade do agente não deve chamar de insalubre uma fila apenas porque é longa. Deve se perguntar quanto tempo a tarefa mais antiga runnable tem esperado, se qualquer trabalhador é acessível, se um espaço está livre e se os resultados verificados ainda estão chegando. Esses fatos distinguem uma dependência legítima da capacidade insuficiente, de um trabalhador morto, de uma tarefa envenenada ou de um despachador que deixou de atribuir trabalho. O padrão prático é gravar o eligibleAt para cada tarefa e alertar quando o now eligibleAt exceder o objetivo inicial dessa classe de tarefas. Não inicie o relógio enquanto a dependência declarada ou o atraso de retomada ainda estiver válido. A profundidade da fila continua a ser um contexto útil, mas a idade correta é o sinal de decisão. A profundidade da fila é o contexto, não um diagnóstico. Uma contagem comprime diferente dos estados. Dez tarefas podem estar aguardando aprovação humana, prontas para começar, já alugadas a trabalhadores, atrasadas por backkoff, ou falhando repetidamente. Tratar todos os dez como um atraso faz com que uma fila ocupada pareça quebrada e pode esconder uma tarefa antiga atrás de uma pequena contagem. Os próprios serviços de fila expõem a limitação. A Amazon SQS publica tanto o ApproximateNumberOfMessagesVisible quanto o ApproximateAgeOfOldestMessage , e etiqueta muitos valores aproximados devido à sua arquitetura distribuída. O Google Pub/Sub é mais explícito em seu Orientações de acompanhamento: o número absoluto de mensagens não reconhecidas não é necessariamente significativo, enquanto um pequeno atraso constante com uma idade de mensagens mais velhas em constante crescimento pode indicar mensagens presas. Para o trabalho de agente, a idade da mensagem crua ainda é demasiado grosseira. Uma tarefa colocada em fila às 09:00 horas, mas bloqueada em aprovação até às 10:00 horas, não deve gastar uma hora do seu orçamento inicial antes de ser elegível. Definição: Deixar ausente o eligibleAt enquanto uma dependência limitada estiver aberta. Registre separadamente o tipo de dependência, o proprietário e o prazo. Se não existir nenhuma evidência de elegibilidade nem uma dependência válida, devolver o uncertain ; não converter os dados faltantes em um zero saudável. Construir um livro de contabilidade de elegibilidade Um disco mínimo pode ficar livre de conteúdo: Campo Questão operacional taskId Qual identidade de tarefa segura e opaca é afetada? eligibleAt Quando é que um trabalhador pode começar legitimamente? dependency Quem ou o quê é o dono da espera, e até quando? deliveryAttempts A tarefa acabou com a sua política limitada de retomadas? workerHeartbeatAt É acessível pelo menos um trabalhador compatível? slots e active A capacidade está ocupada ou disponível? lastVerifiedProgressAt Os resultados completos ainda estão em andamento? Isto é deliberadamente menor que um vestígio. O Documentação de rastreamento do SDK OpenAI Agents descreve gerações, chamadas de função, guardrails, entregas e eventos personalizados. Esses registros ajudam a explicar a execução, mas não dizem quando uma tarefa em fila se tornou elegível ou se o resultado pretendido foi observado. Junte traços detalhados ao livro de contato com um identificador de execução segura; não faça com que a atividade de rastreamento interfira no progresso da fila. Usar uma ordem de decisão que preserve a causa: 1. A prova de elegibilidade e de dependência faltante é a uncertain . 2. Não há tarefas executáveis mais um contrato de locação de dependência válido é waiting . 3. A idade corrida dentro do objetivo de partida é healthy . 4. Uma tarefa mais antiga além do seu orçamento de entrega é a poisoned head . 5. Trabalho antigo, mais batimentos cardíacos de trabalhadores obsoletos, é worker unreachable . 6. Trabalho antigo, todos os espaços ocupados e o progresso verificado é capacity bound . 7. Trabalho antigo, mais um trabalhador novo e um espaço livre é dispatcher stuck . A ordem é importante. Se uma tarefa já tiver esgotado o seu orçamento de tentativa, a adição de trabalhadores não é a primeira reparação. Se nenhum trabalhador for acessível, o envio de culpas é prematuro. Se todos os slots estiverem ocupados e os resultados ainda estiverem chegando, o sistema é lento em relação ao seu objetivo, mas não está imóvel. Reproduzir sete estados de fila O artefato que acompanha congela o tempo de observação no 2026 07 26T04:50:00Z , define uma janela de 120 segundos de frescura do trabalhador e um objetivo de início de 300 segundos, e depois avalia sete filas sintéticas. A corrida produzida: O caso decisivo é o dispatcher gap . A sua tarefa mais antiga foi executada por 900 segundos, o batimento cardíaco do trabalhador é de apenas 20 segundos, e ambos os slots são livres. A maior capacidade não ajudaria; devem ser verificadas as provas de atribuição ou de encaminhamento. Em contraste, o all slots busy tem uma idade de execução de 840 segundos, sem slot livre e um resultado verificado há 80 segundos. É limitada em termos de capacidade no âmbito do objectivo desta fixação. O bounded dependency foi encontrado antes de qualquer um dos casos, mas é o waiting : a aprovação tem um proprietário nomeado e um prazo futuro, por isso não há relógio executável para violar. O silent worker mantém o antigo trabalho pronto separado da falha de acessibilidade. O poisoned oldest impede que uma quinta entrega falhada desapareça dentro de uma fila de aparência normal. O missing eligibility permanece incerto. O experimento demonstra a regra da decisão, não a prevalência. Um caso sintético por estado não pode estabelecer limiares de produção, e não modela inversão de prioridade, filas divididas, desvio do relógio ou restrições de afinidade de tarefa. Idade em par com o movimento de capacidade e resultado A idade correta só se torna accionable ao lado da capacidade e do progresso. Uma tarefa antiga com cada espaço compatível ocupado sugere uma decisão de escala ou de formação da carga de trabalho. A mesma idade com um espaço aberto em despacho, roteamento, afinidade de tarefa, ou um contrato de arrendamento perdido. Evite três atalhos tentadores: Não proporcione a fome. Um atraso médio inicial baixo pode coexistir com uma tarefa que nunca é executada. Rastrear a idade mais velha e um percentil por classe de tarefas. Não misture trabalhos bloqueados com trabalhos executáveis. Mantenha visível a idade da dependência, mas exclui a do objetivo inicial até que a dependência se resolva ou o seu contrato de locação expire. Não deduzir progresso a partir de contratos de arrendamento ou de chamadas de ferramentas. A capacidade só está realmente em movimento quando um artefato específico da tarefa, verificação de aceitação ou recibo de destino mudam. Escolha o objetivo inicial da promessa do trabalho. Uma tarefa de codificação interativa, um relatório programado e uma reconciliação noturna não devem compartilhar 300 segundos porque o dispositivo faz. Medir o tempo normal de iniciação da elegibilidade, definir um objetivo revisível com um buffer e versioná lo. Partição por grupo de trabalhadores ou classe de tarefas compatíveis para que uma fila não relacionada não possa disfarçar a fome. Quando um prazo de dependência ultrapassar, não o prorrogue em silêncio. Calcule a elegibilidade com base nas provas que tem e avise o proprietário nomeado. Quando o batimento cardíaco de um trabalhador estiver obsoleto, verifique a conectividade antes de tentar novamente trabalhos que ainda podem estar em funcionamento noutro lugar. Quando uma tarefa envenenada atinge o seu orçamento de entrega, a quarentena ou a solicitação de revisão, em vez de lhe permitir monopolizar o chefe da fila. Mantenha o diagnóstico separado da intervenção A idade corrente diz lhe que uma promessa operacional está atrasada; os fatos combinados sugerem o porquê. Não autorizam uma reparação automática. Um veredicto da dispatcher stuck pode preparar uma verificação de expedição limitada. A capacity bound pode abrir uma revisão da capacidade. A worker unreachable pode solicitar uma verificação da acessibilidade. Nenhum desses estados sozinho permite reiniciar um hospedeiro, duplicar um efeito colateral, mudar credenciais ou gastar além de um limite de reaprovação. Após qualquer ação aprovada, exigir novas provas: a tarefa recebeu um contrato de arrendamento, a impressão digital do progresso foi alterada ou o resultado esperado foi verificado de forma independente. Um comando que devolveu zero é atividade, não recuperação. Há limites importantes. As métricas de idade do fornecedor podem ser aproximadas. A distorção do relógio pode criar idades negativas impossíveis, por isso compare o tempo de coletor e o tempo de produtor antes de usar o resultado. As filas de prioridade podem legitimamente deixar o trabalho de baixa prioridade envelhecer; expõem a política em vez de chamá la de saudável por acidente. Uma tarefa também pode manter um espaço de aparência livre através de um contrato de locação não observado, por isso, a falta de dados de locação deve diminuir a confiança. A regra resolvida é estreita: iniciar o relógio quando o trabalho é realmente executável, alertar sobre a tarefa executável mais antiga contra um objetivo específico da tarefa, em seguida, usar frescor do trabalhador, slots livres, orçamento de retoma e movimento de resultado verificado para classificar a causa. A Sidewisp está atualmente em prévia privada. Seu site público e biblioteca de artigos estão ao vivo, mas a coleção de agentes de produção saúde, adaptadores de tempo de execução e recuperação geralmente não são enviados. O Sidewisp é concebido para funcionar ao lado dos horários de execução existentes, não para substituí los ou para atuar como fixador autónomo. Se a evidência de idade correta facilitasse o julgamento das operações dos seus agentes, pode juntar se ao acesso precoce enquanto trata o produto como uma pré visualização em vez de monitoramento implantado.