Agentes de Polling em Assistentes de IA: 11 Padrões de Implementação

Agentes de sondagem (polling agents) são uma das partes menos glamourosas da arquitetura de assistentes de IA, mas também são uma das mais úteis.

Um assistente de chat normal espera que o usuário faça uma pergunta. Um agente de sondagem continua observando. Ele verifica uma fonte, percebe mudanças, decide se algo é relevante e, em seguida, age. Essa ação pode ser uma notificação, um resumo, um rascunho, uma chamada de ferramenta ou um fluxo de trabalho completo.

É assim que um assistente passa de “responder à minha pergunta” para “ficar de olho nisso para mim”. Em vez de ser reativo, ele se torna um processo em segundo plano que percebe coisas em nome do usuário e age quando as condições são atendidas.

O ponto de design importante é simples: não torne o modelo de linguagem responsável pelo tempo, estado, tentativas ou bloqueios. Use a infraestrutura de backend normal para isso. Use o modelo onde ele é valioso: interpretando contextos confusos, fazendo julgamentos semânticos e produzindo linguagem útil.

O que é um Agente de Sondagem?

Um agente de sondagem é um processo em segundo plano que verifica repetidamente uma fonte e aciona uma ação do assistente quando uma condição é atendida. No contexto mais amplo de Sistemas de IA — onde o assistente combina um LLM, memória, ferramentas, roteamento e observabilidade —, a camada de sondagem é o que torna o assistente proativo em vez de puramente reativo. Para ver o panorama completo das cinco camadas, consulte Arquitetura de Assistente de IA: LLM, Memória, Ferramentas, Roteamento, Observabilidade.

Exemplos:

• Verificar uma caixa de entrada todas as manhãs e resumir mensagens importantes.
• Monitorar uma lista de tarefas do Notion e executar o próximo item a fazer.
• Monitorar um issue do GitHub até que ele mude de status.
• Sondar um trabalho de IA de longa execução até que o resultado esteja pronto.
• Verificar um horário de reserva até que um se torne disponível.
• Monitorar um portal de fornecedores até que um documento apareça.
• Escanear novos artigos de pesquisa uma vez por semana e resumir os relevantes.

Um agente de sondagem prático tem cinco responsabilidades:

1. Acordar no momento certo.
2. Ler da fonte.
3. Lembrar do que já viu.
4. Decidir se o novo estado é relevante.
5. Agir uma vez, com segurança, sem se repetir.

Um fluxo de produção típico parece com isso:

agendador (scheduler)
  -> trabalhador de sondagem (polling worker)
  -> sistema de fonte
  -> armazenamento de estado
  -> filtros determinísticos
  -> avaliação de LLM opcional
  -> ação do assistente

Esta estrutura é chata da melhor maneira possível. Sistemas chatos são mais fáceis de depurar às 2 da manhã.

O Estado que Todo Agente de Sondagem Precisa

Agentes de sondagem precisam de estado durável. O histórico da conversa não é suficiente. O assistente pode lembrar da conversa, mas o sistema precisa de um registro operacional confiável.

Um bom registro de estado de sondagem geralmente contém:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "pegar uma tarefa em estado Todo e executá-la",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "cursor_or_timestamp",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

O esquema exato depende da fonte, mas a maioria dos sistemas precisa desses conceitos.

Definição de Sondagem

Isso descreve o que o agente está observando e por quê.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Por exemplo:

source_type: notion
source_ref: database_tasks
condition_text: Encontrar uma tarefa Todo, reivindicá-la, executá-la e marcá-la como Complete.

Agendamento

Isso descreve quando o agente deve executar.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Para um agente Hermes que verifica o Notion a cada 10 minutos:

interval_seconds: 600
timezone: Australia/Melbourne

Cursor ou Snapshot (Instantâneo)

Isso ajuda o agente a evitar o processamento repetido dos mesmos dados.

Dependendo da fonte, isso pode ser:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Para uma fila de tarefas do Notion, o cursor pode ser menos importante do que o status da tarefa e os campos de reivindicação. Para Gmail, GitHub ou uma API de sincronização, o cursor geralmente é crítico.

Reivindicação ou Arrendamento (Claim or Lease)

Isso impede que dois trabalhadores peguem o mesmo trabalho.

claimed_by
claimed_at
claim_expires_at
run_id

Por exemplo, uma tarefa do Notion pode ser alterada de:

Status: Todo

para:

Status: InProgress
ClaimedBy: hermes
ClaimedAt: 2026-06-19T01:00:00Z
ClaimExpiresAt: 2026-06-19T01:30:00Z
RunId: run_789

Esta é a diferença entre “esperar que apenas um trabalhador a pegue” e “o sistema tem um protocolo de reivindicação”.

Registro de Execução

Isso registra o que aconteceu durante uma execução.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

O registro de execução deve ficar no backend do assistente, não apenas no Notion ou em outra ferramenta externa. O Notion é bom para visibilidade humana. Não é ideal como seu único registro de execução.

Registro de Deduplicação

Isso impede notificações duplicadas ou ações repetidas.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Por exemplo:

user_456:poll_123:notion_page_999:execute:v1

Se a mesma ação for tentada novamente, o sistema pode suprimi-la.

Método 1: Trabalhador de Sondagem Agendada

Este é o padrão mais simples e confiável.

Um agendador acorda em intervalos fixos e chama um trabalhador. O trabalhador lê a fonte, atualiza o estado e aciona uma ação do assistente, se necessário.

agendador
  -> trabalhador
  -> API de fonte
  -> banco de dados
  -> ação do assistente

Como Funciona

O agendador é responsável pelo tempo. Pode ser cron, um agendador em nuvem, um CronJob do Kubernetes ou um pequeno agendador interno.

A cada intervalo, ele inicia uma execução do trabalhador. O trabalhador carrega sua configuração, consulta a fonte alvo, compara o resultado com o estado armazenado e age, se necessário.

Para um assistente simples, isso geralmente é suficiente. Um único agendador e um processo de trabalhador leve podem lidar com dezenas de verificações diárias sem exigir filas, arrendamentos ou coordenação distribuída.

Modelo de Estado

O agendador armazena muito pouco. Geralmente, ele só sabe quando acionar um trabalho.

O banco de dados da aplicação armazena o estado importante:

definição da sondagem
agendamento
cursor ou instantâneo
último tempo de execução
contagem de falhas
status

O trabalhador deve ser sem estado. Ele pode conter dados temporários enquanto estiver em execução, mas a verdade durável pertence ao banco de dados.

Fluxo de Exemplo

A cada 10 minutos:
  acionar trabalhador de sondagem do Hermes

Trabalhador:
  carregar configuração de sondagem ativa
  consultar fonte
  comparar com estado anterior
  executar verificações determinísticas
  chamar LLM apenas se necessário
  atualizar estado
  emitir evento do assistente

Melhor Aplicação

Use trabalhadores de sondagem agendados para:

• Resumos diários.
• Verificações horárias.
• Automações internas pequenas.
• Tarefas simples de “observar isso”.
• Trabalhos de assistente de volume baixo a médio.

Fraquezas

A sondagem agendada é fácil de entender, mas pode se tornar frágil em escala. Se muitas sondagens forem executadas ao mesmo tempo, você pode sobrecarregar seus trabalhadores ou atingir os limites de taxa do provedor. As tentativas também podem se tornar confusas se o agendador iniciar o trabalho diretamente.

Método 2: Trabalhadores de Sondagem Baseados em Fila

A sondagem baseada em fila geralmente é a melhor opção padrão para assistentes de IA em produção.

O agendador não executa a sondagem diretamente. Ele coloca um trabalho em uma fila. Os processos dos trabalhadores consomem trabalhos da fila.

agendador
  -> fila
  -> pool de trabalhadores
  -> API de fonte
  -> armazenamento de estado
  -> ação do assistente

Como Funciona

Um agendador procura por sondagens vencidas e enfileira trabalhos. Os trabalhadores puxam trabalhos quando têm capacidade.

Isso lhe dá contrapressão. Se o sistema estiver ocupado, os trabalhos aguardam na fila em vez de sobrecarregar a API da fonte ou o provedor do LLM.

Modelo de Estado

O banco de dados armazena o estado da sondagem:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

A mensagem da fila deve permanecer pequena:

{
  "poll_id": "poll_123",
  "scheduled_for": "2026-06-19T01:10:00Z",
  "attempt": 1
}

O trabalhador carrega o estado completo do banco de dados quando inicia.

Fluxo de Exemplo

A cada minuto:
  agendador encontra sondagens onde next_run_at <= agora
  agendador enfileira trabalhos

Trabalhadores:
  puxam trabalhos da fila
  bloqueiam ou arrendam a sondagem
  consultam a fonte
  atualizam o estado
  emitem ação do assistente se necessário
  definem next_run_at

Melhor Aplicação

Use sondagem baseada em fila para:

• Assistentes de IA multi-usuário.
• Muitas sondagens simultâneas.
• Integrações com limites de taxa.
• Trabalho em segundo plano com possibilidade de nova tentativa.
• Trabalhos que podem levar diferentes quantidades de tempo.
• Produtos SaaS onde a confiabilidade é importante.

Fraquezas

As filas adicionam infraestrutura. Você precisa de tratamento de caixas de correio mortas (dead letter), idempotência, tempos de visibilidade e políticas de nova tentativa. Isso vale a pena para sistemas de produção, mas provavelmente é excessivo para um pequeno protótipo.

Método 3: Ferramenta Externa como Fila de Tarefas

Este é o padrão do exemplo Notion mais Hermes.

A ferramenta externa não é apenas uma fonte de dados. Ela se torna a fila de tarefas voltada para o humano. O agente verifica a ferramenta periodicamente, reivindica uma tarefa, executa-a e atualiza o status da tarefa.

agendador
  -> trabalhador Hermes
  -> banco de dados Notion
  -> reivindicar uma tarefa
  -> executar tarefa
  -> atualizar status do Notion

Como Funciona

A cada 10 minutos, o Hermes consulta o banco de dados do Notion para uma tarefa em estado Todo. Ele escolhe a próxima tarefa, geralmente por prioridade e tempo de criação. Em seguida, ele reivindica a tarefa definindo-a como InProgress.

Depois disso, o Hermes executa a tarefa. Se a execução for bem-sucedida, ele marca a tarefa como Complete. Se a execução falhar, ele marca a tarefa como Failed ou a retorna para Todo com uma contagem de nova tentativa.

Modelo de Estado

O Notion armazena o estado da tarefa voltado para o humano:

Title
Description
Status: Todo | InProgress | Complete | Failed
Priority
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

O backend do Hermes armazena o estado de execução operacional:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Esta divisão é importante. O Notion é excelente para visibilidade e edição manual. O backend do Hermes é melhor para registros, novas tentativas, deduplicação e histórico de auditoria.

Fluxo de Exemplo

A cada 10 minutos:
  Hermes acorda

Hermes:
  consultar Notion para uma tarefa onde Status = Todo
  ordenar por Priority, CreatedAt
  atualizar tarefa selecionada para InProgress
  definir ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  executar a tarefa
  escrever registro de execução
  definir tarefa como Complete ou Failed

Melhor Aplicação

Use este padrão quando:

• Humanos já gerenciarem trabalho no Notion, Jira, Linear, Trello ou outra ferramenta.
• Você quiser que o assistente processe tarefas visíveis.
• O quadro de tarefas seja a interface do usuário.
• Você precisar de um modelo de automação simples com humano no loop (human-in-the-loop).

Fraquezas

As ferramentas externas raramente são filas perfeitas. As reivindicações atômicas podem ser limitadas. A consistência da consulta pode atrasar. Limites de taxa podem se aplicar. Se o agente puder ser executado em múltiplas instâncias, você precisará de uma estratégia de reivindicação ou arrendamento cuidadosa.

A recomendação prática é usar o Notion como a caixa de entrada de tarefas voltada para o humano, mantendo todos os registros de execução, registros de nova tentativa, rastreamentos e chaves de idempotência no Hermes. O Notion dá visibilidade aos usuários; o Hermes mantém o sistema confiável. Para ver a mecânica do despachante e da concorrência que ficam por trás deste padrão no Hermes, consulte Kanban no Agente Hermes para Fluxos de Trabalho de LLM Auto-hospedados.

Método 4: Loop de Trabalhador de Longa Duração

Um loop de longa duração é a implementação mais simples.

while True:
    due_polls = db.find_due_polls()
    for poll in due_polls:
        run_poll(poll)
    sleep(30)

Este padrão combina agendamento e execução em um único serviço, o que o torna o ponto de partida mais simples possível para trabalho de agente em segundo plano.

Como Funciona

O processo do trabalhador é executado continuamente. A cada poucos segundos ou minutos, ele verifica o banco de dados em busca de sondagens vencidas e as executa. É fácil de construir, fácil de raciocinar e rápido para iterar durante o desenvolvimento.

Modelo de Estado

O banco de dados ainda armazena estado durável:

configuração da sondagem
next_run_at
cursor
último resultado
contagem de falhas
status

A memória do processo deve conter apenas estado temporário:

lote atual
cache de curta duração
execução em voo

Nunca armazene progresso importante apenas na memória. Se o processo falhar, qualquer estado que não tenha sido escrito no armazenamento durável desaparece, e a próxima execução não terá como saber onde as coisas pararam.

Melhor Aplicação

Use loops de longa duração para:

• Protótipos.
• Desenvolvimento local.
• Ferramentas internas.
• Sistemas de inquilino único.
• Agentes de baixo volume.

Fraquezas

Este padrão se torna arriscado com múltiplas réplicas. Sem arrendamentos, dois trabalhadores podem executar a mesma sondagem. Ele também carece dos recursos operacionais de uma fila ou motor de fluxo de trabalho real.

Um loop de longa duração não está errado como ponto de partida, mas não é um agendador distribuído e não deve ser tratado como tal. Assim que você precisar de múltiplas réplicas ou garantias de confiabilidade mais fortes, precisará migrar para um dos padrões mais estruturados acima.

Método 5: Webhook em Primeiro Lugar com Sondagem como Fallback

Se a fonte suportar webhooks, use-os. A sondagem deve frequentemente ser o backup, não o mecanismo principal.

sistema externo
  -> endpoint de webhook
  -> armazenamento de eventos
  -> ação do assistente

sondagem de reconciliação
  -> API de fonte
  -> comparar com armazenamento de eventos
  -> reparar eventos perdidos

Como Funciona

O sistema externo envia eventos para seu endpoint de webhook quando algo muda. Seu sistema armazena o evento e o processa assincronamente.

Uma sondagem de reconciliação mais lenta é executada a cada poucas horas ou uma vez por dia. Ela verifica se algum evento foi perdido.

Modelo de Estado

O armazenamento de eventos registra webhooks recebidos:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

A sondagem de reconciliação armazena:

last_reconciliation_at
last_seen_cursor
last_seen_version

A tabela de objetos da fonte armazena o último estado conhecido:

external_id
current_status
external_updated_at
last_processed_event_id

Melhor Aplicação

Use arquitetura com webhook em primeiro lugar para:

• Eventos do GitHub.
• Eventos do Stripe.
• Eventos do Slack.
• Atualizações de CRM.
• Notificações de implantação.
• Sistemas de ticketing.

Fraquezas

Webhooks exigem um endpoint público, validação de assinatura, proteção contra reprodução e deduplicação de eventos. Alguns provedores também enviam eventos incompletos, então você ainda pode precisar buscar o objeto completo.

Mesmo assim, se bons webhooks existirem, sondar a cada minuto geralmente é um desperdício.

Método 6: Sondagem de Trabalho em Segundo Lado do Provedor

Às vezes, a coisa sendo sondada é o trabalho de IA em si.

A aplicação inicia um trabalho de provedor de longa duração, armazena o ID do trabalho e verifica mais tarde se ele foi concluído.

app
  -> iniciar trabalho em segundo plano do provedor de IA
  -> armazenar ID do trabalho do provedor
  -> sondar status
  -> buscar resultado
  -> notificar usuário

Como Funciona

O assistente inicia um trabalho com o provedor. O provedor retorna um ID. Seu backend armazena esse ID e verifica seu status até que o trabalho tenha sucesso, falhe, expire ou tenha tempo limite.

Modelo de Estado

Seu backend armazena:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

O provedor armazena o estado e a saída temporários do trabalho.

Se a saída for importante, copie-a para seu próprio armazenamento durável assim que o trabalho for concluído. O armazenamento de resultados do lado do provedor tem janelas de retenção curtas e não substitui um arquivo adequado em seu próprio sistema.

Melhor Aplicação

Use sondagem de trabalho em segundo plano do lado do provedor para:

• Tarefas de pesquisa de IA de longa duração.
• Processamento de grandes documentos.
• Análise de base de código.
• Geração de relatórios.
• Trabalhos de extração de dados.
• Tarefas que excedem os tempos limite normais de solicitações HTTP.

Fraquezas

Este padrão resolve um problema: esperar por um trabalho de provedor longo. Ele não substitui seu motor de fluxo de trabalho, agendador, fila ou armazenamento de estado de negócios.

Método 7: Motor de Fluxo de Trabalho Durável

Um motor de fluxo de trabalho durável gerencia execução de longa duração, temporizadores, novas tentativas e recuperação. O Temporal é a escolha mais comum para backends de assistentes baseados em Go e Python; para um guia de implementação completo, consulte Implementando Aplicações de Fluxo de Trabalho com Temporal em Go.

Em vez de conectar manualmente cada espera e nova tentativa, você modela o processo como um fluxo de trabalho.

motor de fluxo de trabalho
  -> atividade: verificar fonte
  -> temporizador: esperar
  -> atividade: avaliar resultado
  -> atividade: notificar usuário

Como Funciona

O fluxo de trabalho inicia uma vez e então controla sua própria espera. Ele pode dormir por minutos, dias ou semanas. Se o processo do trabalhador falhar, o motor de fluxo de trabalho pode retomar a partir do estado gravado.

Modelo de Estado

O motor de fluxo de trabalho armazena:

workflow_id
execution history
timer state
activity attempts
retry policy
current workflow state

Seu banco de dados da aplicação armazena:

definição de sondagem voltada para o usuário
referências de autorização
registros de negócios
registros de notificação

O motor de fluxo de trabalho possui o estado do processo — histórico de execução, temporizadores, novas tentativas e tentativas de atividade. Seu banco de dados possui o estado de negócios — configurações do usuário, registros de autorização, notificações e logs de auditoria. Manter esses separados impede que cada camada se torne um híbrido confuso de ambos.

Melhor Aplicação

Use fluxos de trabalho duráveis para:

• Processos de negócios com múltiplos passos.
• Automações de longa duração.
• Fluxos de aprovação humana.
• Novas tentativas confiáveis.
• Trabalho em segundo plano auditável.
• Processos que devem retomar após falha.

Fraquezas

Os motores de fluxo de trabalho adicionam conceitos e infraestrutura. Eles são excelentes quando o processo é importante, mas pesados para verificações horárias simples.

Método 8: Tempo de Execução Persistente do Agente

Algumas estruturas de agente podem persistir o estado do agente, criar pontos de verificação de execução e retomar mais tarde.

Isso é útil quando o agente em si tem um processo de raciocínio em múltiplos passos.

agendador ou fluxo de trabalho
  -> tempo de execução do agente
  -> carregar ponto de verificação
  -> chamar ferramentas
  -> salvar ponto de verificação
  -> retomar mais tarde

Como Funciona

Um agendador externo ou fluxo de trabalho inicia o agente. O tempo de execução do agente carrega o estado anterior, executa o próximo passo, chama ferramentas se necessário e grava um ponto de verificação.

O tempo de execução do agente não deve ser seu único agendador. É melhor tratado como a camada de raciocínio dentro de uma arquitetura de backend maior.

Modelo de Estado

O armazenamento de ponto de verificação do agente contém:

current node
messages
tool outputs
intermediate reasoning state
pending action

A memória de longo prazo contém:

stable user preferences
facts
project context
source references

O estado operacional ainda pertence a outro lugar:

poll schedule
cursor
status
retry count
dedupe records

Uma regra útil: memória não é cursor, e um ponto de verificação não é uma fila. A memória do agente armazena o que o modelo sabe; o estado operacional rastreia onde o processo está e o que ele fez. Conflitar os dois leva a bugs sutis que só aparecem sob concorrência ou após uma reinicialização. O espaço de design completo para memória de trabalho, estado durável e camadas de recuperação é coberto em Sistemas de Memória em Assistentes de IA.

Melhor Aplicação

Use tempo de execução persistente do agente para:

• Pesquisa em múltiplos passos.
• Agentes que pausam e retomam.
• Trabalho com humano no loop.
• Raciocínio pesado em ferramentas.
• Tarefas onde o contexto se acumula ao longo do tempo.

Fraquezas

A persistência do agente não é a mesma coisa que confiabilidade operacional. Você ainda precisa de agendamento, bloqueio, novas tentativas, limites de taxa e logs de auditoria.

Método 9: Sincronização de Banco de Dados Mais Avaliação de Mudança

Neste padrão, a sondagem é usada para sincronizar dados externos para seu próprio banco de dados. O assistente então reage a mudanças no banco de dados local em vez de consultar APIs externas diretamente em cada ciclo de avaliação.

sondador de sincronização
  -> API externa
  -> banco de dados local
  -> avaliador de mudança
  -> ação do assistente

Isso separa a sincronização de dados da inteligência do assistente. O trabalhador de sincronização é responsável por manter os registros locais atualizados; o avaliador é responsável por decidir o que fazer com as mudanças. Cada camada pode ser testada, monitorada e escalada independentemente.

Como Funciona

O trabalhador de sincronização busca periodicamente mudanças externas e grava registros normalizados em seu banco de dados. Um segundo trabalhador ou fluxo de mudança detecta linhas atualizadas e decide se o assistente deve agir.

Modelo de Estado

A tabela de sincronização armazena:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

O estado de sincronização armazena:

source_cursor
last_sync_at
rate_limit_status
failure_count

A tabela de avaliação do assistente armazena:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Melhor Aplicação

Use este padrão para:

• Sincronização de CRM.
• Sistemas de ticketing.
• Documentos contábeis.
• Inventário de produtos.
• Revisão de conformidade.
• Indexação de pesquisa.
• Painéis internos.

Fraquezas

Sincronizar tudo pode ser caro e desnecessário. Também pode criar obrigações de privacidade e retenção. Use este padrão quando os dados locais tiverem valor além de uma única ação do assistente.

Método 10: Sondagem Adaptativa

A sondagem adaptativa muda a frequência com base no estado, urgência ou atividade recente.

objeto ativo: sondar a cada 1 minuto
objeto esperando: sondar a cada 1 hora
objeto obsoleto: sondar uma vez por dia
objeto concluído: parar de sondar

Como Funciona

Após cada execução, o trabalhador decide quando a próxima execução deve acontecer.

Se o objeto mudou recentemente, sondar mais cedo. Se nada mudou por um longo tempo, desacelerar. Se a tarefa estiver completa, parar.

Modelo de Estado

O estado da sondagem inclui:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

O instantâneo da fonte inclui:

status
updated_at
activity_level
expected_next_change

Melhor Aplicação

Use sondagem adaptativa para:

• Status de implantação.
• Rastreamento de entrega.
• Disponibilidade de horário no calendário.
• Monitoramento de preços.
• Trabalhos de compilação.
• Tarefas de provedor de longa duração.
• Qualquer fonte com atualizações em rajadas.

Fraquezas

A sondagem adaptativa pode ser mais difícil de raciocinar. Se uma tarefa deve ser executada em um horário estrito, mantenha-a estrita. Não torne trabalhos de conformidade inteligentes.

Método 11: Sondagem Semântica com Avaliador de LLM

A sondagem semântica é usada quando a condição é vaga.

O código pode responder:

O status é igual a Complete?
O preço está abaixo de 100?
Há uma nova mensagem?

Um LLM pode ajudar a responder:

Este e-mail soa urgente?
Este cliente provavelmente está insatisfeito?
Este artigo de pesquisa é relevante?
Esta mudança exige minha atenção?

Como Funciona

O trabalhador primeiro aplica filtros determinísticos baratos. Apenas itens candidatos vão para o LLM.

item novo?
corresponde aos filtros da fonte?
não já processado?
não obviamente irrelevante?

Então o LLM avalia o conjunto candidato menor e retorna saída estruturada.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "O cliente relata uma interrupção em produção."
}

Modelo de Estado

A definição da sondagem armazena:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

O log de avaliação armazena:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

O estado da sondagem armazena:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Melhor Aplicação

Use sondagem semântica para:

• Detecção de e-mails importantes.
• Monitoramento de sentimento do cliente.
• Alertas de pesquisa.
• Detecção de oportunidades de vendas.
• Triagem de segurança.
• Resumos executivos.

Fraquezas

As chamadas de LLM custam dinheiro e adicionam latência. Elas também podem ser inconsistentes se os prompts e esquemas forem soltos. Use filtros determinísticos primeiro. Pergunte ao modelo apenas quando o julgamento for realmente necessário.

Tabela de Decisão: Escolhendo um Método de Agente de Sondagem

Arquitetura Padrão Recomendada

Para a maioria dos assistentes de IA em produção, comece com isso:

tabela de sondagens
  -> agendador
  -> fila
  -> trabalhadores sem estado
  -> filtros determinísticos
  -> avaliador de LLM opcional
  -> notificação ou ação do assistente

Um esquema mínimo:

CREATE TABLE polls (
    id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    source_type TEXT NOT NULL,
    source_ref TEXT NOT NULL,
    condition_text TEXT NOT NULL,
    schedule_type TEXT NOT NULL,
    interval_seconds INTEGER,
    timezone TEXT,
    next_run_at TIMESTAMP NOT NULL,
    last_run_at TIMESTAMP,
    cursor_value TEXT,
    last_hash TEXT,
    status TEXT NOT NULL,
    failure_count INTEGER NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE poll_runs (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    started_at TIMESTAMP NOT NULL,
    finished_at TIMESTAMP,
    status TEXT NOT NULL,
    items_checked INTEGER,
    items_matched INTEGER,
    decision_summary TEXT,
    error TEXT
);

CREATE TABLE notifications (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    user_id TEXT NOT NULL,
    dedupe_key TEXT NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    delivered_at TIMESTAMP,
    UNIQUE (dedupe_key)
);

Isso lhe dá uma separação limpa:

agendador possui o tempo
fila possui o amortecimento
trabalhador possui a execução
banco de dados possui o estado
LLM possui o julgamento semântico
assistente possui a interação com o usuário

Essa separação é o coração de um agente de sondagem confiável.

Exemplo: Agente Hermes Processando Tarefas do Notion

Agora vamos aplicar a arquitetura a um caso concreto.

Suponha que um banco de dados do Notion contenha tarefas. O Hermes deve rodar a cada 10 minutos, pegar uma tarefa em estado Todo, defini-la como InProgress, executá-la e, em seguida, marcá-la como Complete.

Isso é melhor descrito como:

ferramenta externa como fila de tarefas
+
trabalhador de sondagem agendada
+
execução baseada em reivindicação ou arrendamento

Para uma versão de produção, torna-se:

sondagem baseada em fila com Notion como a caixa de entrada de tarefas voltada para o humano

Propriedades da Tarefa do Notion

O banco de dados do Notion deve conter campos como:

Name
Status: Todo | InProgress | Complete | Failed
Priority
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Os campos importantes são ClaimedAt, ClaimExpiresAt e RunId. Eles tornam a reivindicação da tarefa visível e recuperável.

Estado de Execução do Hermes

O Hermes também deve manter seu próprio registro de execução:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Isso o protege se o Notion for editado manualmente, se uma chamada de API falhar ou se você precisar auditar o que o Hermes realmente fez.

Fluxo de Execução

A cada 10 minutos:
  agendador do Hermes cria uma execução

Trabalhador do Hermes:
  encontra uma tarefa do Notion onde Status = Todo
  ordena por Priority e CreatedAt
  reivindica a tarefa definindo Status = InProgress
  escreve ClaimedBy, ClaimedAt, ClaimExpiresAt e RunId
  executa a tarefa
  escreve logs de execução no backend do Hermes
  define Status do Notion = Complete em caso de sucesso
  define Status do Notion = Failed em caso de falha

Se o Hermes falhar após reivindicar uma tarefa, o arrendamento pode expirar:

Status = InProgress
ClaimExpiresAt < agora

Uma execução futura pode então recuperar a tarefa ou marcá-la como falha.

Tratamento de Falhas

Em caso de sucesso:

Status = Complete
CompletedAt = agora
LastError = vazio

Em caso de falha recuperável:

Status = Todo
RetryCount = RetryCount + 1
LastError = mensagem de erro curta

Em caso de falha não recuperável:

Status = Failed
LastError = explicação clara

Para segurança, o Hermes também deve usar uma chave de idempotência:

notion_page_id + task_version + action_type

Isso impede que a mesma tarefa seja executada duas vezes se uma nova tentativa acontecer no momento errado.

Por Que Isso Não é Apenas Sondagem

A parte de sondagem é apenas o mecanismo de despertar. A arquitetura real é a reivindicação de tarefas e execução confiável.

Uma implementação ingênua diz:

A cada 10 minutos, encontrar uma tarefa Todo e fazê-la.

Uma implementação confiável diz:

A cada 10 minutos, reivindicar exatamente uma tarefa elegível, registrar a execução, executar de forma idempotente e mover a tarefa para um estado terminal.

Essa é a diferença entre uma demonstração e um agente em que você pode confiar.

Erros Comuns de Agentes de Sondagem

Erro 1: Sem Protocolo de Reivindicação

Se dois trabalhadores puderem ver a mesma tarefa, eles podem executá-la.

Use:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Mesmo que você atualmente execute um trabalhador, projete como se um segundo trabalhador pudesse aparecer mais tarde.

Erro 2: Sem Chave de Deduplicação

Cada ação externa deve ter uma chave de deduplicação.

user_id + poll_id + source_object_id + action_type + condition_version

Isso impede notificações repetidas, e-mails repetidos, execução de tarefas repetidas e chamadas de ferramentas repetidas. Os princípios mais amplos por trás do escopo, armazenamento e teste dessas chaves se aplicam igualmente aqui — consulte Idempotência em Sistemas Distribuídos que Realmente Funciona.

Erro 3: Chamando o LLM Muito Cedo

Não peça ao modelo para fazer filtragem de banco de dados.

Ruim:

Enviar todas as tarefas para o LLM e perguntar qual é Todo.

Melhor:

Usar o filtro da API do Notion para buscar tarefas Todo.
Então usar o LLM apenas se a interpretação da tarefa for necessária.

Erro 4: Tratando o Notion como o Único Backend

O Notion é uma boa interface humana. Não é um backend de execução completo.

Mantenha logs de execução, novas tentativas, rastreamentos e registros de idempotência no Hermes.

Erro 5: Sondagem Infinita

Cada sondagem deve ter uma condição de parada.

Exemplos:

parar após sucesso
parar após data
parar após novas tentativas máximas
parar quando o usuário desativar
parar após falha de autorização repetida

Um agente de sondagem sem condição de parada é um vazamento de custo silencioso.

Erro 6: Sem Observabilidade

Você deve ser capaz de responder:

O que o agente executou?
Por que ele executou?
O que ele leu?
O que ele mudou?
Por que ele falhou?
Ele notificou o usuário?
Ele executou duas vezes?

Se você não puder responder a essas perguntas, o sistema não está pronto para trabalho importante.

Lista de Verificação de Observabilidade

Acompanhe métricas como:

polls_due
polls_started
polls_succeeded
polls_failed
tasks_claimed
tasks_completed
tasks_failed
claim_expired_count
duplicate_suppressed_count
llm_calls
llm_cost
rate_limit_count
average_run_duration

Campos de log como:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Construa uma visão administrativa para:

active polls
stuck InProgress tasks
recent failures
high retry tasks
dead letter jobs
expensive LLM evaluations
disabled integrations

Agentes de sondagem rodam em segundo plano, onde falhas são silenciosas e problemas podem se acumular antes que alguém perceba. Sistemas em segundo plano precisam de visibilidade construída desde o início, não adicionada como uma reflexão tardia quando algo dá errado. Para a pilha de observabilidade completa para sistemas de IA e LLM — métricas, rastreamentos, logs estruturados e SLOs — consulte Observabilidade para Sistemas de LLM: Métricas, Rastreamentos, Logs e Testes em Produção.

Recomendação Final

Para um assistente de IA sério, comece com trabalhadores de sondagem baseados em fila e um armazenamento de estado durável. Adicione webhooks onde os provedores os suportarem. Use sondagem adaptativa quando os limites de taxa forem importantes. Use um motor de fluxo de trabalho durável quando o processo for de longa duração e com múltiplos passos. Use tempo de execução persistente do agente quando o agente precisar raciocinar ao longo do tempo.

Para o exemplo Hermes e Notion, a arquitetura correta é:

Notion como a caixa de entrada de tarefas voltada para o humano
Agendador do Hermes a cada 10 minutos
Trabalhador do Hermes com lógica de reivindicação ou arrendamento
Backend do Hermes para logs de execução e idempotência
Atualizações de status do Notion para visibilidade

O intervalo de sondagem não é a parte difícil. A parte difícil é garantir que o agente reivindique uma tarefa, execute-a uma vez, registre o que aconteceu e deixe o sistema em um estado que humanos possam entender.

É isso que transforma um script de sondagem em um assistente de IA confiável — não o intervalo, não o modelo, mas a disciplina ao redor de reivindicar trabalho, registrá-lo e deixar o sistema em um estado que humanos e futuras execuções possam entender.