Agenti di Polling negli Assistenti AI: 11 Pattern di Implementazione

Gli agenti di polling rappresentano una delle parti meno glamour dell’architettura degli assistenti AI, ma sono anche tra le più utili.

Un assistente chat normale attende che l’utente ponga una domanda. Un agente di polling continua a osservare. Controlla una fonte, nota i cambiamenti, decide se qualcosa è rilevante e poi agisce. Tale azione può essere una notifica, un riassunto, una bozza, una chiamata a uno strumento o un flusso di lavoro completo.

Questo è il modo in cui un assistente passa da “rispondi alla mia domanda” a “tieni d’occhio questo per me”. Invece di essere reattivo, diventa un processo in background che nota le cose per conto dell’utente e agisce quando le condizioni sono soddisfatte.

Il punto di progettazione importante è semplice: non rendere il modello linguistico responsabile del tempo, dello stato, dei tentativi ripetuti o del locking (blocco). Utilizza l’infrastruttura backend normale per quello. Utilizza il modello dove è prezioso: interpretando contesti complessi, prendendo decisioni semantiche e producendo linguaggio utile.

Cos’è un Agente di Polling?

Un agente di polling è un processo in background che controlla ripetutamente una fonte e attiva un’azione dell’assistente quando viene soddisfatta una condizione. Nel più ampio stack dei Sistemi AI — dove l’assistente combina un LLM, memoria, strumenti, routing e osservabilità — lo strato di polling è ciò che rende l’assistente proattivo piuttosto che puramente reattivo. Per la visione completa a cinque strati, vedi Architettura dell’Assistente AI: LLM, Memoria, Strumenti, Routing, Osservabilità.

Esempi:

• Controllare la casella di posta ogni mattina e riassumere i messaggi importanti.
• Monitorare un elenco di attività su Notion ed eseguire la prossima attività da fare.
• Monitorare un issue su GitHub fino a quando non cambia stato.
• Pollare un lavoro AI a lunga esecuzione fino a quando il risultato non è pronto.
• Controllare la disponibilità di un appuntamento fino a quando uno slot non diventa disponibile.
• Monitorare il portale di un fornitore fino a quando non appare un documento.
• Scansionare nuovi articoli di ricerca una volta alla settimana e riassumere quelli rilevanti.

Un agente di polling pratico ha cinque responsabilità:

1. Svegliarsi al momento giusto.
2. Leggere dalla fonte.
3. Ricordare cosa ha già visto.
4. Decidere se il nuovo stato è rilevante.
5. Agire una sola volta, in modo sicuro, senza ripetere se stesso.

Un flusso di produzione tipico appare così:

scheduler
  -> polling worker
  -> source system
  -> state store
  -> deterministic filters
  -> optional LLM evaluation
  -> assistant action

Questa struttura è noiosa nel miglior modo possibile. I sistemi noiosi sono più facili da debuggare alle 2 del mattino.

Lo Stato di cui Ogni Agente di Polling Ha Bisogno

Gli agenti di polling hanno bisogno di uno stato durevole. La cronologia della conversazione non è sufficiente. L’assistente può ricordare la conversazione, ma il sistema ha bisogno di un registro operativo affidabile.

Un buon record di stato di polling di solito contiene:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "prendi un'attività in stato Todo ed eseguila",
  "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"
}

Lo schema esatto dipende dalla fonte, ma la maggior parte dei sistemi ha bisogno di questi concetti.

Definizione del Poll

Questo descrive cosa l’agente sta monitorando e perché.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Ad esempio:

source_type: notion
source_ref: Database Attività
condition_text: Trova un'attività Todo, assegnatela, eseguila, contrassegnala come Completata.

Pianificazione (Schedule)

Questo descrive quando l’agente dovrebbe essere eseguito.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Per un agente Hermes che controlla Notion ogni 10 minuti:

interval_seconds: 600
timezone: Australia/Melbourne

Cursore o Snapshot

Questo aiuta l’agente a evitare di ri-elaborare gli stessi dati.

A seconda della fonte, questo può essere:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Per una coda di attività su Notion, il cursore può essere meno importante rispetto allo stato dell’attività e ai campi di assegnazione. Per Gmail, GitHub o un’API di sincronizzazione, il cursore è di solito critico.

Assegnazione (Claim) o Lease

Questo impedisce a due worker di prendere lo stesso lavoro.

claimed_by
claimed_at
claim_expires_at
run_id

Ad esempio, un’attività su Notion può essere cambiata da:

Stato: Todo

a:

Stato: InProgress
AssegnatoDa: hermes
AssegnatoA: 2026-06-19T01:00:00Z
ScadenzaAssegnazione: 2026-06-19T01:30:00Z
RunId: run_789

Questa è la differenza tra “spero che solo un worker lo prenda” e “il sistema ha un protocollo di assegnazione”.

Record di Esecuzione

Questo registra cosa è successo durante un’esecuzione.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Il record di esecuzione dovrebbe risiedere nel backend dell’assistente, non solo su Notion o in un altro strumento esterno. Notion è buono per la visibilità umana. Non è ideale come unico registro di esecuzione.

Record di Deduplicazione

Questo previene notifiche duplicate o azioni ripetute.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Ad esempio:

user_456:poll_123:notion_page_999:execute:v1

Se la stessa azione viene tentata di nuovo, il sistema può sopprimerla.

Metodo 1: Worker di Polling Programmato

Questo è il pattern più semplice e affidabile.

Un pianificatore (scheduler) si sveglia a intervalli fissi e chiama un worker. Il worker legge la fonte, aggiorna lo stato e attiva un’azione dell’assistente se necessario.

scheduler
  -> worker
  -> source API
  -> database
  -> assistant action

Come Funziona

Il pianificatore è responsabile del tempo. Potrebbe essere cron, un pianificatore cloud, un CronJob Kubernetes o un piccolo pianificatore interno.

A ogni intervallo, avvia un’esecuzione del worker. Il worker carica la sua configurazione, interroga la fonte target, confronta il risultato con lo stato memorizzato e agisce se necessario.

Per un assistente semplice, questo è spesso sufficiente. Un singolo pianificatore e un processo worker leggero possono gestire decine di controlli giornalieri senza richiedere code, lease o coordinamento distribuito.

Modello di Stato

Il pianificatore memorizza molto poco. Di solito sa solo quando attivare un lavoro.

Il database dell’applicazione memorizza lo stato importante:

definizione del poll
pianificazione
cursore o snapshot
ultima ora di esecuzione
conteggio errori
stato

Il worker dovrebbe essere stateless (senza stato). Può contenere dati temporanei mentre è in esecuzione, ma la verità durevole appartiene al database.

Esempio di Flusso

Ogni 10 minuti:
  attiva il worker di polling di Hermes

Worker:
  carica la configurazione del poll attivo
  interroga la fonte
  confronta con lo stato precedente
  esegue controlli deterministici
  chiama l'LLM solo se necessario
  aggiorna lo stato
  emette evento dell'assistente

Migliore Utilizzo

Utilizza i worker di polling programmati per:

• Riassunti giornalieri.
• Controlli orari.
• Piccole automazioni interne.
• Compiti semplici di tipo “monitora questo”.
• Lavori dell’assistente a volume basso o medio.

Debolezze

Il polling programmato è facile da capire, ma può diventare fragile su larga scala. Se molti poll vengono eseguiti contemporaneamente, potresti sovraccaricare i tuoi worker o raggiungere i limiti di frequenza del provider. I tentativi ripetuti possono anche diventare caotici se il pianificatore avvia direttamente il lavoro.

Metodo 2: Worker di Polling Basati su Code

Il polling basato su code è di solito la scelta predefinita migliore per gli assistenti AI in produzione.

Il pianificatore non esegue il poll direttamente. Mette un lavoro su una coda. I processi worker consumano i lavori dalla coda.

scheduler
  -> queue
  -> worker pool
  -> source API
  -> state store
  -> assistant action

Come Funziona

Un pianificatore cerca i poll scaduti e accoda i lavori. I worker prelevano i lavori quando hanno capacità.

Questo ti dà backpressure (contropressione). Se il sistema è occupato, i lavori aspettano nella coda invece di sommergere l’API della fonte o il provider LLM.

Modello di Stato

Il database memorizza lo stato del poll:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Il messaggio della coda dovrebbe rimanere piccolo:

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

Il worker carica lo stato completo dal database quando inizia.

Esempio di Flusso

Ogni minuto:
  il pianificatore trova poll dove next_run_at <= ora
  il pianificatore accoda i lavori

Worker:
  prelevano lavori dalla coda
  bloccano o assegnano il poll
  interrogano la fonte
  aggiornano lo stato
  emettono azione dell'assistente se necessario
  impostano next_run_at

Migliore Utilizzo

Utilizza il polling basato su code per:

• Assistenti AI multi-utente.
• Molti poll simultanei.
• Integrazioni con limiti di frequenza.
• Lavoro in background ripetibile.
• Lavori che possono richiedere tempi diversi.
• Prodotti SaaS dove l’affidabilità è importante.

Debolezze

Le code aggiungono infrastruttura. Hai bisogno di gestione delle code di lettera morta (dead letter), idempotenza, timeout di visibilità e politiche di ripetizione. Vale la pena per i sistemi di produzione, ma probabilmente eccessivo per un piccolo prototipo.

Metodo 3: Strumento Esterno come Coda di Attività

Questo è il pattern nell’esempio di Notion più Hermes.

Lo strumento esterno non è solo una fonte di dati. Diventa la coda di attività visibile all’utente. L’agente controlla periodicamente lo strumento, assegna un’attività, la esegue e aggiorna lo stato dell’attività.

scheduler
  -> Hermes worker
  -> Notion database
  -> assegna un'attività
  -> esegui attività
  -> aggiorna stato Notion

Come Funziona

Ogni 10 minuti, Hermes interroga il database di Notion per un’attività in stato Todo. Sceglie la prossima attività, di solito per priorità e tempo di creazione. Poi assegna l’attività impostandola su InProgress.

Dopo di che, Hermes esegue l’attività. Se l’esecuzione ha successo, marca l’attività come Complete. Se l’esecuzione fallisce, marca l’attività come Failed o la restituisce a Todo con un conteggio di ripetizioni.

Modello di Stato

Notion memorizza lo stato dell’attività visibile all’utente:

Titolo
Descrizione
Stato: Todo | InProgress | Complete | Failed
Priorità
CreatoA
AssegnatoDa
AssegnatoA
ScadenzaAssegnazione
RunId
ConteggioRipetizioni
UltimoErrore
CompletatoA

Il backend di Hermes memorizza lo stato operativo di esecuzione:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Questa separazione è importante. Notion è eccellente per la visibilità e la modifica manuale. Il backend di Hermes è migliore per log, ripetizioni, deduplicazione e storia di audit.

Esempio di Flusso

Ogni 10 minuti:
  Hermes si sveglia

Hermes:
  interroga Notion per un'attività dove Stato = Todo
  ordina per Priorità, CreatoA
  aggiorna l'attività selezionata a InProgress
  imposta AssegnatoDa, AssegnatoA, ScadenzaAssegnazione, RunId
  esegue l'attività
  scrive il log di esecuzione
  imposta l'attività su Complete o Failed

Migliore Utilizzo

Utilizza questo pattern quando:

• Gli umani gestiscono già il lavoro su Notion, Jira, Linear, Trello o un altro strumento.
• Vuoi che l’assistente elabori attività visibili.
• La bacheca delle attività è l’interfaccia utente.
• Hai bisogno di un modello di automazione semplice con intervento umano.

Debolezze

Gli strumenti esterni raramente sono code perfette. Le assegnazioni atomiche possono essere limitate. La coerenza delle query può ritardare. Possono applicarsi limiti di frequenza. Se l’agente può essere eseguito in più istanze, hai bisogno di una strategia di assegnazione o lease accurata.

Il consiglio pratico è utilizzare Notion come cassetto delle attività visibile all’utente mantenendo tutti i log di esecuzione, i record di ripetizione, le tracce e le chiavi di idempotenza su Hermes. Notion dà agli utenti visibilità; Hermes mantiene il sistema affidabile. Per la dispatcher e la meccanica di concorrenza che si trovano dietro questo pattern su Hermes, vedi Kanban in Hermes Agent per Flussi di Lavoro LLM Self-Hosted.

Metodo 4: Ciclo di Worker a Lunga Esecuzione

Un ciclo a lunga esecuzione è l’implementazione più semplice.

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

Questo pattern combina pianificazione ed esecuzione in un unico servizio, il che lo rende il punto di partenza più semplice possibile per il lavoro dell’agente in background.

Come Funziona

Il processo worker funziona continuamente. Ogni pochi secondi o minuti, controlla il database per i poll scaduti e li esegue. È facile da costruire, facile da ragionare su e veloce da iterare durante lo sviluppo.

Modello di Stato

Il database memorizza comunque uno stato durevole:

configurazione del poll
next_run_at
cursor
ultimo risultato
conteggio errori
stato

La memoria del processo dovrebbe contenere solo stato temporaneo:

batch corrente
cache a breve termine
esecuzione in corso

Non memorizzare mai progressi importanti solo in memoria. Se il processo crasha, qualsiasi stato che non è stato scritto su storage durevole è perso, e la prossima esecuzione non avrà modo di sapere dove si era fermato.

Migliore Utilizzo

Utilizza i cicli a lunga esecuzione per:

• Prototipi.
• Sviluppo locale.
• Strumenti interni.
• Sistemi single-tenant.
• Agenti a basso volume.

Debolezze

Questo pattern diventa rischioso con più repliche. Senza lease, due worker possono eseguire lo stesso poll. Manca anche delle funzionalità operative di una vera coda o motore di flusso di lavoro.

Un ciclo a lunga esecuzione non è sbagliato come punto di partenza, ma non è un pianificatore distribuito e non dovrebbe essere trattato come tale. Non appena hai bisogno di più repliche o garanzie di affidabilità più forti, dovrai passare a uno dei pattern più strutturati sopra.

Metodo 5: Webhook-First con Fallback a Polling

Se la fonte supporta webhook, usali. Il polling dovrebbe spesso essere il backup, non il meccanismo principale.

external system
  -> webhook endpoint
  -> event store
  -> assistant action

reconciliation poll
  -> source API
  -> compare with event store
  -> repair missed events

Come Funziona

Il sistema esterno invia eventi al tuo endpoint webhook quando qualcosa cambia. Il tuo sistema memorizza l’evento e lo elabora asincronamente.

Un poll di riconciliazione più lento viene eseguito ogni poche ore o una volta al giorno. Controlla se sono stati persi degli eventi.

Modello di Stato

Lo store degli eventi registra i webhook in arrivo:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Il poll di riconciliazione memorizza:

last_reconciliation_at
last_seen_cursor
last_seen_version

La tabella degli oggetti della fonte memorizza l’ultimo stato noto:

external_id
current_status
external_updated_at
last_processed_event_id

Migliore Utilizzo

Utilizza l’architettura webhook-first per:

• Eventi GitHub.
• Eventi Stripe.
• Eventi Slack.
• Aggiornamenti CRM.
• Notifiche di deployment.
• Sistemi di ticketing.

Debolezze

I webhook richiedono un endpoint pubblico, convalida delle firme, protezione dal replay e deduplicazione degli eventi. Alcuni provider inviano anche eventi incompleti, quindi potresti ancora dover recuperare l’oggetto completo.

Tuttavia, se esistono buoni webhook, pollare ogni minuto è di solito uno spreco.

Metodo 6: Polling di Lavori in Background del Provider

A volte la cosa che viene pollata è il lavoro AI stesso.

L’applicazione avvia un lavoro a lunga esecuzione del provider, memorizza l’ID del lavoro e controlla in seguito se è stato completato.

app
  -> start AI background job
  -> store provider job id
  -> poll status
  -> fetch result
  -> notify user

Come Funziona

L’assistente avvia un lavoro con il provider. Il provider restituisce un ID. Il tuo backend memorizza quell’ID e ne controlla lo stato finché il lavoro non ha successo, fallisce, scade o va in timeout.

Modello di Stato

Il tuo backend memorizza:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Il provider memorizza lo stato temporaneo del lavoro e l’output.

Se l’output è importante, copialo nel tuo storage durevole non appena il lavoro si completa. Lo storage dei risultati lato provider ha finestre di ritenzione brevi e non è un sostituto di un archivio appropriato nel tuo sistema.

Migliore Utilizzo

Utilizza il polling di lavori in background lato provider per:

• Attività di ricerca AI a lunga esecuzione.
• Elaborazione di grandi documenti.
• Analisi del codice.
• Generazione di report.
• Lavori di estrazione dati.
• Attività che superano i timeout normali delle richieste HTTP.

Debolezze

Questo pattern risolve un problema: aspettare un lavoro lungo del provider. Non sostituisce il tuo motore di flusso di lavoro, pianificatore, coda o store di stato aziendale.

Metodo 7: Motore di Flusso di Lavoro Durevole

Un motore di flusso di lavoro durevole gestisce l’esecuzione a lunga durata, timer, ripetizioni e recupero. Temporal è la scelta più comune per backend assistente basati su Go e Python; per una guida di implementazione completa vedi Implementazione di Applicazioni di Flusso di Lavoro con Temporal in Go.

Invece di cablare manualmente ogni attesa e ripetizione, modella il processo come un flusso di lavoro.

workflow engine
  -> activity: check source
  -> timer: wait
  -> activity: evaluate result
  -> activity: notify user

Come Funziona

Il flusso di lavoro inizia una volta e poi controlla le proprie attese. Può dormire per minuti, giorni o settimane. Se il processo worker crasha, il motore di flusso di lavoro può riprendere dallo stato registrato.

Modello di Stato

Il motore di flusso di lavoro memorizza:

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

Il database della tua applicazione memorizza:

user-facing poll definition
authorization references
business records
notification records

Il motore di flusso di lavoro possiede lo stato del processo — cronologia di esecuzione, timer, ripetizioni e tentativi di attività. Il tuo database possiede lo stato aziendale — configurazioni utente, record di autorizzazione, notifiche e log di audit. Mantenere questi separati impedisce che ogni strato diventi un ibrido confuso di entrambi.

Migliore Utilizzo

Utilizza flussi di lavoro durevoli per:

• Processi aziendali multi-step.
• Automazioni a lunga esecuzione.
• Flussi di approvazione umana.
• Ripetizioni affidabili.
• Lavoro in background auditabile.
• Processi che devono riprendere dopo un fallimento.

Debolezze

I motori di flusso di lavoro aggiungono concetti e infrastruttura. Sono eccellenti quando il processo è importante, ma pesanti per semplici controlli orari.

Metodo 8: Runtime dell’Agente Persistente

Alcuni framework per agenti possono persistere lo stato dell’agente, fare checkpoint dell’esecuzione e riprendere in seguito.

Questo è utile quando l’agente stesso ha un processo di ragionamento multi-step.

scheduler or workflow
  -> agent runtime
  -> load checkpoint
  -> call tools
  -> save checkpoint
  -> resume later

Come Funziona

Un pianificatore esterno o un flusso di lavoro avvia l’agente. Il runtime dell’agente carica lo stato precedente, esegue il prossimo step, chiama strumenti se necessario e scrive un checkpoint.

Il runtime dell’agente non dovrebbe essere il tuo unico pianificatore. È meglio considerato come lo strato di ragionamento all’interno di un’architettura backend più ampia.

Modello di Stato

Lo storage dei checkpoint dell’agente contiene:

current node
messages
tool outputs
intermediate reasoning state
pending action

La memoria a lungo termine contiene:

stable user preferences
facts
project context
source references

Lo stato operativo appartiene comunque altrove:

poll schedule
cursor
status
retry count
dedupe records

Una regola utile: la memoria non è un cursore, e un checkpoint non è una coda. La memoria dell’agente memorizza quello che il modello sa; lo stato operativo traccia dove si trova il processo e cosa ha fatto. Confluenza dei due porta a bug sottili che appaiono solo sotto concorrenza o dopo un riavvio. Lo spazio di progettazione completo per la memoria di lavoro, lo stato durevole e gli strati di recupero è coperto in Sistemi di Memoria negli Assistenti AI.

Migliore Utilizzo

Utilizza il runtime persistente dell’agente per:

• Ricerca multi-step.
• Agenti che pausano e riprendono.
• Lavoro con intervento umano.
• Ragionamento pesante su strumenti.
• Attività in cui il contesto si accumula nel tempo.

Debolezze

La persistenza dell’agente non è la stessa cosa dell’affidabilità operativa. Hai ancora bisogno di pianificazione, locking, ripetizioni, limiti di frequenza e log di audit.

Metodo 9: Sincronizzazione Database Più Valutazione dei Cambiamenti

In questo pattern, il polling è usato per sincronizzare dati esterni nel tuo database. L’assistente reagisce poi ai cambiamenti del database locale invece di interrogare le API esterne direttamente in ogni ciclo di valutazione.

sync poller
  -> external API
  -> local database
  -> change evaluator
  -> assistant action

Questo separa la sincronizzazione dei dati dall’intelligenza dell’assistente. Il worker di sincronizzazione è responsabile di mantenere i record locali aggiornati; il valutatore è responsabile di decidere cosa fare riguardo ai cambiamenti. Ogni strato può essere testato, monitorato e scalato indipendentemente.

Come Funziona

Il worker di sincronizzazione recupera periodicamente i cambiamenti esterni e scrive record normalizzati nel tuo database. Un secondo worker o flusso di cambiamenti rileva le righe aggiornate e decide se l’assistente dovrebbe agire.

Modello di Stato

La tabella di sincronizzazione memorizza:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Lo stato di sincronizzazione memorizza:

source_cursor
last_sync_at
rate_limit_status
failure_count

La tabella di valutazione dell’assistente memorizza:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Migliore Utilizzo

Utilizza questo pattern per:

• Sincronizzazione CRM.
• Sistemi di ticketing.
• Documenti contabili.
• Inventario prodotti.
• Revisione conformità.
• Indicizzazione di ricerca.
• Dashboard interne.

Debolezze

Sincronizzare tutto può essere costoso e inutile. Può anche creare obblighi di privacy e ritenzione. Utilizza questo pattern quando i dati locali hanno valore oltre a un’unica azione dell’assistente.

Metodo 10: Polling Adattivo

Il polling adattivo cambia la frequenza in base allo stato, all’urgenza o all’attività recente.

active object: poll every 1 minute
waiting object: poll every 1 hour
stale object: poll once per day
completed object: stop polling

Come Funziona

Dopo ogni esecuzione, il worker decide quando dovrebbe avvenire la prossima esecuzione.

Se l’oggetto è cambiato recentemente, polla prima. Se nulla è cambiato da molto tempo, rallenta. Se il compito è completo, fermati.

Modello di Stato

Lo stato del poll include:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Lo snapshot della fonte include:

status
updated_at
activity_level
expected_next_change

Migliore Utilizzo

Utilizza il polling adattivo per:

• Stato di deployment.
• Tracciamento spedizioni.
• Disponibilità slot calendario.
• Monitoraggio prezzi.
• Lavori di build.
• Attività a lunga esecuzione del provider.
• Qualsiasi fonte con aggiornamenti a raffica.

Debolezze

Il polling adattivo può essere più difficile da ragionare su. Se un compito deve essere eseguito a un tempo rigoroso, mantienilo rigoroso. Non rendere intelligenti i lavori di conformità.

Metodo 11: Polling Semantico con Valutatore LLM

Il polling semantico è usato quando la condizione è sfumata.

Il codice può rispondere:

Lo stato è uguale a Completato?
Il prezzo è sotto 100?
C'è un nuovo messaggio?

Un LLM può aiutare a rispondere:

Questa email sembra urgente?
Questo cliente è probabilmente insoddisfatto?
Questo articolo di ricerca è rilevante?
Questo cambiamento richiede la mia attenzione?

Come Funziona

Il worker applica prima filtri deterministici economici. Solo gli elementi candidati vanno all’LLM.

new item?
matches source filters?
not already processed?
not obviously irrelevant?

Poi l’LLM valuta il set di candidati più piccolo e restituisce output strutturato.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Il cliente segnala un'interruzione di produzione."
}

Modello di Stato

La definizione del poll memorizza:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Il log di valutazione memorizza:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Lo stato del poll memorizza:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Migliore Utilizzo

Utilizza il polling semantico per:

• Rilevamento di email importanti.
• Monitoraggio del sentiment del cliente.
• Avvisi di ricerca.
• Rilevamento di opportunità di vendita.
• Triage di sicurezza.
• Briefing esecutivi.

Debolezze

Le chiamate LLM costano denaro e aggiungono latenza. Possono anche essere incoerenti se prompt e schemi sono laschi. Usa filtri deterministici prima. Chiedi al modello solo quando il giudizio è realmente necessario.

Tabella Decisionale: Scegliere un Metodo per l’Agente di Polling

Architettura Predefinita Raccomandata

Per la maggior parte degli assistenti AI di produzione, inizia con questo:

polls table
  -> scheduler
  -> queue
  -> stateless workers
  -> deterministic filters
  -> optional LLM evaluator
  -> notification or assistant action

Uno schema minimale:

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)
);

Questo ti dà una separazione pulita:

scheduler owns time
queue owns buffering
worker owns execution
database owns state
LLM owns semantic judgment
assistant owns user interaction

Quella separazione è il cuore di un agente di polling affidabile.

Esempio: Agente Hermes che Elabora Attività Notion

Ora applichiamo l’architettura a un caso concreto.

Supponiamo che un database Notion contenga attività. Hermes dovrebbe essere eseguito ogni 10 minuti, prendere un’attività in stato Todo, impostarla su InProgress, eseguirla e poi contrassegnarla come Complete.

Questo è meglio descritto come:

external tool as task queue
+
scheduled polling worker
+
claim or lease based execution

Per una versione di produzione, diventa:

queue-based polling with Notion as the human-facing task inbox

Proprietà delle Attività Notion

Il database Notion dovrebbe contenere campi come:

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

I campi importanti sono ClaimedAt, ClaimExpiresAt e RunId. Rendono l’assegnazione dell’attività visibile e recuperabile.

Stato di Esecuzione di Hermes

Hermes dovrebbe anche mantenere il proprio record di esecuzione:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Questo ti protegge se Notion viene modificato manualmente, se una chiamata API fallisce o se hai bisogno di auditare cosa ha fatto realmente Hermes.

Flusso di Esecuzione

Every 10 minutes:
  Hermes scheduler creates a run

Hermes worker:
  finds one Notion task where Status = Todo
  sorts by Priority and CreatedAt
  claims the task by setting Status = InProgress
  writes ClaimedBy, ClaimedAt, ClaimExpiresAt, and RunId
  executes the task
  writes execution logs to Hermes backend
  sets Notion Status = Complete on success
  sets Notion Status = Failed on failure

Se Hermes crasha dopo aver assegnato un’attività, il lease può scadere:

Status = InProgress
ClaimExpiresAt < now

Una futura esecuzione può poi recuperare l’attività o contrassegnarla come fallita.

Gestione degli Errori

Su successo:

Status = Complete
CompletedAt = now
LastError = empty

Su errore recuperabile:

Status = Todo
RetryCount = RetryCount + 1
LastError = short error message

Su errore non recuperabile:

Status = Failed
LastError = clear explanation

Per sicurezza, Hermes dovrebbe anche usare una chiave di idempotenza:

notion_page_id + task_version + action_type

Questo impedisce che la stessa attività venga eseguita due volte se una ripetizione avviene al momento sbagliato.

Perché Questo Non è Solo Polling

La parte di polling è solo il meccanismo di risveglio. La vera architettura è l’assegnazione delle attività e l’esecuzione affidabile.

Un’implementazione ingenua dice:

Every 10 minutes, find a Todo task and do it.

Un’implementazione affidabile dice:

Every 10 minutes, claim exactly one eligible task, record the run, execute idempotently, and move the task to a terminal state.

Questa è la differenza tra una demo e un agente di cui puoi fidarti.

Errori Comuni degli Agenti di Polling

Errore 1: Nessun Protocollo di Assegnazione

Se due worker possono vedere la stessa attività, possono entrambi eseguirla.

Usa:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Anche se attualmente esegui un worker, progetta come se un secondo worker potesse apparire in seguito.

Errore 2: Nessuna Chiave di Deduplicazione

Ogni azione esterna dovrebbe avere una chiave di deduplicazione.

user_id + poll_id + source_object_id + action_type + condition_version

Questo previene notifiche ripetute, email ripetute, esecuzione attività ripetuta e chiamate a strumenti ripetute. I principi più ampi dietro lo scoping, lo storage e il testing di queste chiavi si applicano allo stesso modo qui — vedi Idempotenza nei Sistemi Distribuiti che Funziona Davvero.

Errore 3: Chiamare l’LLM Tropo Presto

Non chiedere al modello di fare il filtraggio del database.

Male:

Send all tasks to the LLM and ask which one is Todo.

Meglio:

Use the Notion API filter to fetch Todo tasks.
Then use the LLM only if task interpretation is needed.

Errore 4: Trattare Notion come l’Unico Backend

Notion è un’interfaccia utente buona. Non è un backend di esecuzione completo.

Mantieni i log di esecuzione, le ripetizioni, le tracce e i record di idempotenza su Hermes.

Errore 5: Polling Infinito

Ogni poll dovrebbe avere una condizione di stop.

Esempi:

stop after success
stop after date
stop after max retries
stop when user disables it
stop after repeated authorization failure

Un agente di polling senza una condizione di stop è una perdita di costi silenziosa.

Errore 6: Nessuna Osservabilità

Dovresti essere in grado di rispondere:

What did the agent run?
Why did it run?
What did it read?
What did it change?
Why did it fail?
Did it notify the user?
Did it run twice?

Se non puoi rispondere a quelle domande, il sistema non è pronto per un lavoro importante.

Checklist di Osservabilità

Traccia metriche come:

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

Log di campi come:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Costruisci una vista admin per:

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

Gli agenti di polling girano in background, dove i fallimenti sono silenziosi e i problemi possono accumularsi prima che qualcuno si accorga. I sistemi in background hanno bisogno di visibilità costruita fin dall’inizio, non aggiunta come un dopo-pensiero quando qualcosa va storto. Per lo stack completo di osservabilità per sistemi AI e LLM — metriche, tracce, log strutturati e SLO — vedi Osservabilità per Sistemi LLM: Metriche, Tracce, Log e Testing in Produzione.

Raccomandazione Finale

Per un assistente AI serio, inizia con worker di polling basati su code e uno store di stato durevole. Aggiungi webhook dove i provider li supportano. Usa il polling adattivo quando i limiti di frequenza sono importanti. Usa un motore di flusso di lavoro durevole quando il processo è a lunga esecuzione e multi-step. Usa il runtime persistente dell’agente quando l’agente ha bisogno di ragionare nel tempo.

Per l’esempio di Hermes e Notion, l’architettura giusta è:

Notion as the human-facing task inbox
Hermes scheduler every 10 minutes
Hermes worker with claim or lease logic
Hermes backend for execution logs and idempotency
Notion status updates for visibility

L’intervallo di polling non è la parte difficile. La parte difficile è assicurarsi che l’agente assegni un’attività, la esegua una volta, registri cosa è successo e lasci il sistema in uno stato che gli umani possono comprendere.

Questo è ciò che trasforma uno script di polling in un assistente AI affidabile — non l’intervallo, non il modello, ma la disciplina nell’assegnare il lavoro, registrarlo e lasciare il sistema in uno stato che sia comprensibile per gli umani e per le esecuzioni future.