AI Agente Painel: Seis sinais que revelam saúde operacional

O AI O painel do agente deve responder a uma pergunta operacional antes de desenhar um gráfico de tokens: Esta corrida precisa de atenção agora? A linha mais pequena e útil combina seis sinais: frescura do coletor, pontualidade do cronograma, atividade cardíaca, progresso útil, dependência explícita de espera e verificação de resultados. Aplique os em ordem fixa para que uma espera silenciosa de aprovação não seja confundida com uma barraca e um ciclo de retomada ocupado não seja confundido com um trabalho saudável. Mantenha a latência, chamadas de modelo, chamadas de ferramentas, tokens, custo e rastreamento. São valiosas provas de diagnóstico. Não provam, por si só, que uma corrida programada tenha começado, que um relatório tenha mudado, que uma aprovação esteja pendente ou que o produto prometido exista. Comece com uma linha de estado, não uma parede de gráficos O padrão razoável para um painel de aplicação LLM é a telemetria de serviço. O painel oficial AI Agents da Sentry, por exemplo, inclui corridas de agentes, chamadas LLM, duração, uso do modelo, tokens, chamadas de ferramentas, erros e detalhes de rastreamento. Esses painéis ajudam a responder o que aconteceu dentro desta execução? e que dependência se tornou lenta ou cara? Um operador que enfrenta vinte circuitos autônomos ou programados tem uma decisão anterior: qual devo abrir? Uma linha compacta de estado pode responder: Campo Exemplo Decisão que apoia Agente e fluxo de trabalho researcher / weekly brief Qual trabalho é afetado? Estado waiting:human approval Precisa de intervenção, roteamento ou paciência? Idade da prova collector 14s ago O veredicto baseia se em dados recentes? Último progresso útil 3 sources added, 4m ago O resultado está a mover se, não apenas o processo? Próximo evento esperado approval by owner O que deve acontecer a seguir? Verificação de resultados brief.md schema: pending O que deve ser verdadeiro antes que o completo seja credível? O estado é um veredicto derivado de evidências, não uma cópia da última cadeia de status do runtime. Coloque as provas decisivas ao lado. Stuck sem uma janela de progresso é uma opinião; Não há alteração de configuração de fonte durante 13 minutos enquanto os batimentos cardíacos permanecem frescos é inspecionável. Esta separação tem um precedente útil em sistemas de agentes externos. Kubernetes não desintegra a inicialização, a vitalidade e a prontidão em uma sonda porque a resposta correta é diferente: esperar a inicialização, reiniciar após uma falha de vitalidade genuína ou parar o tráfego de roteamento quando uma carga de trabalho não está pronta. A sua documentação também adverte que uma sonda de vida mal projetada pode criar falhas em cascata. Um painel de controle de agentes tem o mesmo problema de controlo: um rótulo só é seguro quando implica a ação seguinte certa. Recolher seis sinais com frescura explícita Os seis sinais abaixo formam um contrato de saúde compacto. Podem ser armazenados como campos num registo de execução ou calculados a partir de eventos de tempo de execução. Cada um precisa de um tempo, fonte e estado indisponível. 1. Frescosidade do colecionador Registrar quando o painel de controle chegou ao tempo de execução ou recebeu um evento de confiança. Se o coletor estiver obsoleto, classifique a corrida como unreachable ou uncertain antes de interpretar os batimentos cardíacos e o progresso mais velhos. Caso contrário, um anfitrião desconectado pode parecer pacíficamente ocioso. Use um limiar ligado à cadência de coleta. Um limite de frescura de 120 segundos é razoável para um pesquisador de um minuto num exemplo; é absurdo para um trabalho que sincroniza a cada hora. Indicar a idade observada e o limite configurado. 2. Terminação do horário Armazenar o início esperado, início real, fuso horário, janela de graça e política de agendamento. "Não haver corrida" significa pouco sem esses campos. Um cronógrafo pode ser interrompido, uma política de sobreposição pode deliberadamente ignorar um início ou uma janela de acompanhamento pode adiar o trabalho perdido. A documentação Temporal's Schedule torna estas distinções concretas: os cronogramas podem ser pausados; as políticas de sobreposição podem pular, amortecer, cancelar, encerrar ou permitir execuções simultâneas; as janelas de retorno decidem quais ações perdidas são executadas após uma interrupção. Outros tempos de execução usam nomes diferentes, mas o painel ainda precisa preservar a política que explica a lacuna. 3. Actividade cardíaca Um batimento cardíaco prova a recente atividade de contato ou execução. É útil para separar um tempo de execução inacessível de um processo ao vivo. Não deve avançar o relógio de progresso. Tornar o evento estreito: heartbeat at , source , e talvez uma sequência monotonicamente crescente. Não chame a corrida saudável apenas porque essa sequência continua a mudar. 4. Progresso útil Defina um delta específico da tarefa. Um agente codificador pode alterar a digestão do parche ou aumentar o número de testes de aprovação. Um agente de pesquisa pode adicionar uma fonte primária acessível ou mover um breve de esquema inválido para esquema válido. Um agente de apoio pode criar o bilhete prometido. O registo de progresso requer o last progress at , uma pequena descrição do delta e uma versão verificadora. Evite os contadores vagos, como pasos completados, a menos que cada passo trace o resultado. 5. A dependência de espera Representar a espera legítima explicitamente: human approval , credential , rate limit , external job , ou outra dependência nomeada. Adicione um proprietário, ação solicitada e prazo quando conhecido. Este campo altera a ação. Uma corrida à espera de aprovação precisa ser encaminhada para a pessoa autorizada, não uma reinicialização. Uma espera limitada pode exigir paciência. Uma credencial faltante precisa de um ser humano que possa fornecê la sem expor o segredo ao painel. 6. Verificação dos resultados Escreva a predicada de conclusão antes do início da corrida. Exemplos incluem: report exists, parses, and contains two reachable primary sources ; pull request exists and named checks pass ; ticket ID was returned and can be fetched ; scheduled export contains the expected date partition . Armazenar o declared complete separadamente do outcome verified . O segundo deve ser true , false ou unavailable , com o verificador e o tempo de verificação. Um comando bem sucedido é a atividade. O artefato pretendido é o resultado. Aplicar uma ordem de prioridade O painel de instrumentos não deve colocar todos os possíveis avisos na mesma fila. Avalie primeiro o estado mais seguro e mais explicativo: 1. colector estável → unreachable ; 2. O início esperado para além da sua janela de graça → missed schedule ; 3. dependência denominada → waiting:<dependency ; 4. declarado completo sem resultado verificado → false success ; 5. Batimento cardíaco fresco mais obsoleto, progresso zero → stuck ; 6. Resultado verificado → complete ; 7. Delta de progresso positivo → working ; 8. Evidências insuficientes ou conflitantes → uncertain . Essa encomenda é uma decisão de produto, não uma lei da natureza. Ainda é melhor do que permitir que três alertas independentes afirmem que a mesma corrida desconectada está simultaneamente presa, atrasada e perdendo seu resultado. Preservar os sinais subjacentes para investigação, mas dar ao operador um estado primário e uma ação seguinte. O equipamento de acompanhamento testa seis casos contra limites de exemplo explícitos: frescura do coletor de 120 segundos, graça do cronograma de 300 segundos, frescura do batimento cardíaco de 60 segundos e um tempo de progresso de 600 segundos. Execute com Node.js 20 ou mais recente: A saída exacta é: O par mais importante é approval wait versus retry loop . Ambos têm batimentos cardíacos frescos, nenhum delta de progresso, e velhos progressos. A dependência nomeada torna a primeira espera legítima; a ausência de uma dependência torna a segunda candidata presa após o seu tempo de espera. O caso false success tem progressos recentes e uma alegação de conclusão, mas o verificador de resultados é falso, de modo que a alegação de conclusão não ganha confiança. Coloque o diagnóstico atrás do veredicto . Uma vez que a linha de estado identifica uma corrida que vale a pena abrir, a visão de detalhes pode explicar o porquê. Organize o em torno da transição que falhou em vez de em torno da fonte de telemetria que é mais fácil de mapear. Para o missed schedule , indique a expressão do cronograma, o fuso horário, o estado habilitado, os arranques esperados e reais, a política de sobreposição e o histórico de execução recente. Para o waiting , indique a dependência, o proprietário, a autoridade solicitada, a idade e uma ação de lembrete limitada. Para o stuck , exibir a cadência cardíaca, juntamente com evidências de progresso e assinaturas repetidas de ferramentas. Para o false success , indique a alegação de conclusão ao lado do predicado falhado. Depois, adicione o rastreamento, a latência, o token, o custo, o modelo e os painéis de ferramentas. Um ponto simbólico ligado a uma corrida bloqueada é acionável; o mesmo ponto ligado a um resultado verificado pode ser um item de revisão de custos em vez de um incidente. A repetição de chamada de ferramenta pode explicar um impasse, mas chamadas idênticas não são prova de um ciclo até que a evidência de progresso da tarefa também pare de mudar. Usar uma linha do tempo para a causalidade: Este ponto de vista torna compreensíveis os períodos de silêncio. Também dá a cada alerta uma idade de provas. Se um adaptador parar de relatar após 12:03, o painel deve mudar para unreachable ou uncertain em vez de manter um estado verde para sempre. Tratar os limiares e a recolha de dados como limites dos produtos A fixação é um conjunto de contra exemplos, não um índice de referência de produção. Dez minutos sem mudança de arquivo podem ser normais para análise profunda e desastrosos para um trabalhador de uma fila de um minuto. Calibra as janelas por fluxo de trabalho, depois grava a configuração ao lado do veredicto. O progresso é o sinal mais difícil. Preferir evidências deterministas como um digest, contagem de filas, código de status, resultado do teste ou verificação de esquema. Quando o resultado é qualitativo, um avaliador com versão pode contribuir com evidências, mas a sua pontuação é incerta. Mantenha o unavailable como um estado real; não converta evidências faltantes em saudáveis. Recolher o mínimo necessário para estabelecer a saúde. Uma linha de estado geralmente não precisa de pedidos, respostas, segredos, cargas úteis de ferramentas brutas ou caminhos locais absolutos. Um identificador de execução opaco, timestamps, pequenos contadores, resultados de verificação e classes de dependência editadas podem impulsionar a primeira decisão. Os vestígios mais ricos podem ter regras separadas de retenção e de acesso. Por último, não conecte o estado primário diretamente à automação irreversível. O aviso de vida de Kubernetes é relevante aqui: um excesso de confiança no teste de saúde pode piorar a recuperação. Um painel pode recomendar uma tentativa limitada, pausa ou lembrete, mas a ação deve respeitar a autoridade, a tentativa, o tempo e os limites de custose o problema deve ser resolvido apenas após o progresso útil ou o resultado esperado ser observado. Onde se encaixa o Sidewisp A direção do produto da Sidewisp é uma visão de saúde em torno dos agentes que as pessoas já executam: acessibilidade, progresso útil, acesso à memória e ferramentas, evidência de resultados, sinais de custo e recuperação controlada com limites de aprovação explícitos. Não é destinado a substituir o sistema de rastreamento de tempo de execução, o cronógrafo, o modelo de gateway ou o sistema de rastreamento bruto. Essa descrição é a direção do produto e não uma alegação de monitorização geralmente disponível. A Sidewisp está atualmente em prévia privada. O site público, a demonstração interativa e o sistema de artigos estão ao vivo; coleção de agentes de produção saúde, adaptadores de tempo de execução, recuperação automática, gerenciamento de cron e análise de custos de token geralmente não são enviados. Junte se à prévia privada se este contrato de painel de seis sinais coincidir com o problema operacional que precisa resolver. Fontes primárias Centinela AI Agentes Painéis de Controle campos oficiais para corridas, chamadas LLM, duração, modelos, tokens, ferramentas, erros e vestígios. Capacidade de vida, prontidão e sondas de arranque de Kubernetes separação oficial dos controlos de saúde, reacções, limiares e avisos de falha. Horários temporais cronograma oficial, pausa, sobreposição, acompanhamento e semântica da política de falhas.