Agenter för polling i AI-assistenter: 11 implementeringsmönster

Pollningagenter är en av de minst glamourösa delarna av arkitekturen för AI-assistenter, men de är också en av de mest användbara.

En vanlig chattassistent väntar på att användaren ska fråga något. En pollningagent fortsätter att övervaka. Den kontrollerar en källa, noterar förändringar, avgör om något har betydelse och agerar därefter. Denna åtgärd kan vara en avisering, en sammanfattning, ett utkast, ett verktygsanrop eller ett helt arbetsflöde.

Så här flyttar en assistent från “svara på min fråga” till “håll utkik efter detta åt mig”. Istället för att vara reaktiv blir den en bakgrundsprocess som noterar saker på användarens vägnar och agerar när villkor uppfylls.

Den viktiga designpunkten är enkel: gör inte språkmodellen ansvarig för tid, tillstånd, omförsök eller låsning. Använd vanlig backendinfrastruktur för detta. Använd modellen där den är värdefull: att tolka rörigt sammanhang, fatta semantiska bedömningar och producera användbart språk.

Vad är en pollningagent?

En pollningagent är en bakgrundsprocess som upprekat kontrollerar en källa och utlöser en assistentåtgärd när ett villkor uppfylls. I den bredare AI-systemstacken — där assistenten kombinerar en LLM, minne, verktyg, routing och observabilitet — är pollningslagret det som gör assistenten proaktiv snarare än rent reaktiv. För den fullständiga femlagsöversikten, se Arkitektur för AI-assistenter: LLM, minne, verktyg, routing, observabilitet.

Exempel:

• Kontrollera en inbox varje morgon och sammanfatta viktiga meddelanden.
• Övervaka en uppgiftslista i Notion och utför nästa todo-objekt.
• Övervaka ett GitHub-problem tills det ändrar status.
• Polla ett långvarigt AI-jobb tills resultatet är klart.
• Kontrollera en bokningslapp tills en blir tillgänglig.
• Övervaka en leverantörsportal tills ett dokument dyker upp.
• Skanna nya forskningsartiklar en gång i veckan och sammanfatta relevanta.

En praktisk pollningagent har fem ansvarsområden:

1. Vakna vid rätt tidpunkt.
2. Läsa från källan.
3. Komma ihåg vad den redan har sett.
4. Avgöra om det nya tillståndet har betydelse.
5. Agera en gång, säkert, utan att upprepa sig.

En typisk produktionsflöde ser ut så här:

schemaläggare
  -> pollningsarbetare
  -> källsystem
  -> tillståndsregister
  -> deterministiska filter
  -> valfri LLM-utvärdering
  -> assistentåtgärd

Denna struktur är tråkig på bästa möjliga sätt. Tråkiga system är lättare att felsöka klockan 2 på natten.

Tillståndet varje pollningagent behöver

Pollningagenter behöver uthålligt tillstånd. Konversationshistorik räcker inte. Assistenten kan komma ihåg konversationen, men systemet behöver en pålitlig driftspost.

En bra pollningstillståndspost innehåller vanligtvis:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "ta en uppgift i Todo-tillstånd och utför den",
  "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"
}

Det exakta schemat beror på källan, men de flesta system behöver dessa koncept.

Pollningdefinition

Detta beskriver vad agenten övervakar och varför.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Till exempel:

source_type: notion
source_ref: Uppgiftsdatabas
condition_text: Hitta en Todo-uppgift, anspråk den, utför den, markera den som Avslutad.

Schema

Detta beskriver när agenten ska köras.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

För en Hermes-agent som kontrollerar Notion var 10:e minut:

interval_seconds: 600
timezone: Australia/Melbourne

Markör eller ögonblicksbild

Detta hjälper agenten att undvika att bearbeta samma data igen.

Beroende på källan kan detta vara:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

För en uppgiftskö i Notion kan markören vara mindre viktig än uppgiftens status och anspråk. För Gmail, GitHub eller en synkroniserings-API är markören vanligtvis kritisk.

Anspråk eller leasing

Detta förhindrar att två arbetare tar samma jobb.

claimed_by
claimed_at
claim_expires_at
run_id

Till exempel kan en Notion-uppgift ändras från:

Status: Todo

till:

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

Detta är skillnaden mellan “jag hoppas att bara en arbetare tar den” och “systemet har ett anspråksprotokoll”.

Exekveringspost

Detta registrerar vad som hände under en körning.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Exekveringsposten bör finnas i assistentens backend, inte bara i Notion eller ett annat externt verktyg. Notion är bra för mänsklig synlighet. Det är inte idealiskt som din enda exekveringslogg.

Avdubleringspost

Detta förhindrar dubbla aviseringar eller upprepade åtgärder.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Till exempel:

user_456:poll_123:notion_page_999:execute:v1

Om samma åtgärd försöker igen kan systemet undertrycka den.

Metod 1: Schema-baserad pollningsarbetare

Detta är det enklaste tillförlitliga mönstret.

En schemaläggare vaknar varje fast intervall och kallar en arbetare. Arbetaren läser källan, uppdaterar tillståndet och utlöser en assistentåtgärd om det krävs.

schemaläggare
  -> arbetare
  -> käll-API
  -> databas
  -> assistentåtgärd

Hur det körs

Schemaläggaren är ansvarig för tiden. Det kan vara cron, en molnschemaläggare, en Kubernetes CronJob eller en liten intern schemaläggare.

Varje intervall startar den en arbetarkörning. Arbetaren laddar sin konfiguration, frågar målkällan, jämför resultatet med det sparade tillståndet och agerar vid behov.

För en enkel assistent räcker detta ofta. En enda schemaläggare och en lättvikts arbetarprocess kan hantera dussintals dagliga kontroller utan att kräva köer, leasing eller distribuerad samordning.

Tillståndsmodell

Schemaläggaren sparar mycket lite. Vanligtvis vet den bara när den ska utlösa ett jobb.

Applikationsdatabasen sparar det viktiga tillståndet:

pollningdefinition
schema
markör eller ögonblicksbild
senaste körningstid
felräknare
status

Arbetaren bör vara tillståndslos. Den kan hålla tillfällig data medan den körs, men den uthålliga sanningen tillhör databasen.

Exempelflöde

Var 10:e minut:
  utlös Hermes pollningsarbetare

Arbetare:
  ladda aktiv pollningskonfiguration
  fråga källa
  jämför med tidigare tillstånd
  kör deterministiska kontroller
  kalla LLM endast om det behövs
  uppdatera tillstånd
  skicka ut assistenthändelse

Bäst passning

Använd schema-baserade pollningsarbetare för:

• Dagliga sammanfattningar.
• Timvisa kontroller.
• Små interna automatiseringar.
• Enkla “övervaka detta”-uppgifter.
• Låg till medelvolym assistentjobb.

Svagheter

Schema-baserad pollning är lätt att förstå, men den kan bli skör i stor skala. Om många pollningar körs samtidigt kan du överbelasta dina arbetare eller träffa leverantörens hastighetsbegränsningar. Omförsök kan också bli rörigt om schemaläggaren direkt startar arbetet.

Metod 2: Kö-baserade pollningsarbetare

Kö-baserad pollning är vanligtvis det bästa förvalet för produktionsberedda AI-assistenter.

Schemaläggaren utför inte pollningen direkt. Den lägger ett jobb i en kö. Arbetarprocesser konsumerar jobb från kön.

schemaläggare
  -> kö
  -> arbetarpool
  -> käll-API
  -> tillståndsregister
  -> assistentåtgärd

Hur det körs

En schemaläggare skannar efter förfallna pollningar och lagrar jobb i kön. Arbetare hämtar jobb när de har kapacitet.

Detta ger dig backpressure. Om systemet är upptaget väntar jobb i kön istället för att överväldiga käll-API:t eller LLM-leverantören.

Tillståndsmodell

Databasen sparar pollningstillståndet:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Kömeddelandet bör hållas litet:

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

Arbetaren laddar hela tillståndet från databasen när den startar.

Exempelflöde

Var minut:
  schemaläggaren hittar pollningar där next_run_at <= nu
  schemaläggaren lagrar jobb i kön

Arbetare:
  hämta jobb från kö
  lås eller leasa pollningen
  fråga källan
  uppdatera tillstånd
  skicka ut assistentåtgärd vid behov
  sätt next_run_at

Bäst passning

Använd kö-baserad pollning för:

• AI-assistenter med flera användare.
• Många simultana pollningar.
• Integrationer med hastighetsbegränsningar.
• Bakgrundsarbeten som kan omförsökas.
• Jobb som kan ta olika lång tid.
• SaaS-produkter där tillförlitlighet är viktig.

Svagheter

Köer lägger till infrastruktur. Du behöver hantering av dead letter, idempotens, synlighetstider och omförsökpolicyer. Detta är värt det för produktionsystem, men troligen överdrivet för en liten prototyp.

Metod 3: Externt verktyg som uppgiftskö

Detta är mönstret i Notion plus Hermes-exemplet.

Det externa verktyget är inte bara en datakälla. Det blir den mänskliga uppgiftskön. Agenten kontrollerar periodiskt verktyget, anspråkar en uppgift, utför den och uppdaterar uppgiftens status.

schemaläggare
  -> Hermes arbetare
  -> Notion-databas
  -> anspråk en uppgift
  -> utför uppgift
  -> uppdatera Notion-status

Hur det körs

Var 10:e minut frågar Hermes Notion-databasen efter en uppgift i Todo-tillstånd. Den väljer nästa uppgift, vanligtvis baserat på prioritet och skapande tid. Sedan anspråkar den uppgiften genom att sätta den till InProgress.

Därefter utför Hermes uppgiften. Om exekveringen lyckas markerar den uppgiften som Complete. Om exekveringen misslyckas markerar den uppgiften som Failed eller returnerar den till Todo med en omförsöksräknare.

Tillståndsmodell

Notion sparar det mänskliga uppgiftstillståndet:

Titel
Beskrivning
Status: Todo | InProgress | Complete | Failed
Prioritet
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Hermes backend sparar det operativa exekveringstillståndet:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Denna uppdelning är viktig. Notion är utmärkt för synlighet och manuell redigering. Hermes backend är bättre för loggar, omförsök, avdubling och revisionshistorik.

Exempelflöde

Var 10:e minut:
  Hermes vaknar

Hermes:
  fråga Notion efter en uppgift där Status = Todo
  sortera efter Prioritet, CreatedAt
  uppdatera vald uppgift till InProgress
  sätt ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  utför uppgiften
  skriv exekveringslogg
  sätt uppgift till Complete eller Failed

Bäst passning

Använd detta mönster när:

• Människor redan hanterar arbete i Notion, Jira, Linear, Trello eller ett annat verktyg.
• Du vill att assistenten ska bearbeta synliga uppgifter.
• Uppgiftsbrädan är användargränssnittet.
• Du behöver en enkel human-in-the-loop-automatiseringsmodell.

Svagheter

Externa verktyg är sällan perfekta köer. Atomiska anspråk kan vara begränsade. Frågekonsistens kan hinka efter. Hastighetsbegränsningar kan gälla. Om agenten kan köras i flera instanser behöver du en noggrann anspråks- eller leasingstrategi.

Den praktiska rekommendationen är att använda Notion som den mänskliga uppgiftsinboxen medan man behåller alla exekveringsloggar, omförsöksposter, spår och idempotensnycklar i Hermes. Notion ger användare synlighet; Hermes håller systemet tillförligt. För dispatcher- och konkurrensmechanik som ligger bakom detta mönster i Hermes, se Kanban i Hermes Agent för självhostade LLM-arbetsflöden.

Metod 4: Långvarig arbetarloop

En långvarig loop är den enklaste implementationen.

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

Detta mönster kombinerar schemaläggning och exekvering i en tjänst, vilket gör det till den enklaste möjliga startpunkten för bakgrundsentagentarbete.

Hur det körs

Arbetarprocessen körs kontinuerligt. Varje få sekunder eller minuter kontrollerar den databasen för förfallna pollningar och utför dem. Det är enkelt att bygga, enkelt att resonera kring och snabbt att iterera på under utveckling.

Tillståndsmodell

Databasen sparar fortfarande uthålligt tillstånd:

pollningkonfiguration
next_run_at
cursor
last result
failure count
status

Procesminnet bör endast innehålla tillfälligt tillstånd:

current batch
short-lived cache
in-flight run

Spara aldrig viktig framsteg endast i minnet. Om processen kraschar är allt tillstånd som inte skrivits till uthållig lagring borta, och nästa körning får ingen möjlighet att veta var saken lämnades.

Bäst passning

Använd långvariga looper för:

• Prototyper.
• Lokal utveckling.
• Interna verktyg.
• Single-tenant-system.
• Lågvolymagenter.

Svagheter

Detta mönster blir riskabelt med flera repliker. Utan leasing kan två arbetare köra samma pollning. Det saknar också de operativa funktionerna hos en riktig kö eller arbetsflödesmotor.

En långvarig loop är inte fel som startpunkt, men det är inte en distribuerad schemaläggare och bör inte behandlas som sådan. Så fort du behöver flera repliker eller starkare tillförlitlighetsgarantier, måste du övergå till ett av de mer strukturerade mönstren ovan.

Metod 5: Webhook-först med pollning som fallback

Om källan stöder webhooks, använd dem. Pollning bör ofta vara backup, inte den primära mekanismen. Samma uppdelning syns i agentprotokolldesign: A2A-pushaviseringar väcker en klienthanterare, som sedan pollar GetTask för fullständigt tillstånd, som beskrivs i A2A Streaming och Async Tasks för långvariga agentarbetsflöden.

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

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

Hur det körs

Det externa systemet skickar händelser till din webhook-endpunkt när något ändras. Ditt system sparar händelsen och bearbetar den asynkront.

En långsammare återställningspollning körs varje få timmar eller en gång om dagen. Den kontrollerar om några händelser har missats.

Tillståndsmodell

Händelselagret registrerar inkommande webhooks:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Återställningspollningen sparar:

last_reconciliation_at
last_seen_cursor
last_seen_version

Källobjektstabellen sparar det senaste kända tillståndet:

external_id
current_status
external_updated_at
last_processed_event_id

Bäst passning

Använd webhook-först-arkitektur för:

• GitHub-händelser.
• Stripe-händelser.
• Slack-händelser.
• CRM-uppdateringar.
• Deployningsaviseringar.
• Ticketing-system.

Svagheter

Webhooks kräver en offentlig endpoint, signaturvalidering, uppspelningsbeskydd och händelseavdubling. Vissa leverantörer skickar också ofullständiga händelser, så du kan fortfarande behöva hämta hela objektet.

Ändå, om bra webhooks finns, är pollning var minut vanligtvis slöseri.

Metod 6: Leverantörs-sida bakgrundjobb pollning

Ibland är det som pollas AI-jobbet självt.

Applikationen startar ett långvarigt leverantörsjobb, sparar jobb-ID:t och kontrollerar senare om det är klart.

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

Hur det körs

Assistenten startar ett jobb med leverantören. Leverantören returnerar ett ID. Din backend sparar det ID:t och kontrollerar dess status tills jobbet lyckas, misslyckas, upphör eller timeout.

Tillståndsmodell

Din backend sparar:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Leverantören sparar det tillfälliga jobbtillståndet och utdata.

Om utdata är viktig, kopiera den till din egen uthålliga lagring så snart jobbet är klart. Leverantörs-sida resultatlager har korta retentionstider och är inte en ersättning för ett ordentligt arkiv i ditt eget system.

Bäst passning

Använd leverantörs-sida bakgrundjobb pollning för:

• Långvariga AI-forskninguppgifter.
• Stor dokumentbearbetning.
• Kodbasanalys.
• Rapportgenerering.
• Dataextraheringsjobb.
• Uppgifter som överstiger normala HTTP-förfråganstimeouts.

Svagheter

Detta mönster löser ett problem: att vänta på ett långvarigt leverantörsjobb. Det ersätter inte din arbetsflödesmotor, schemaläggare, kö eller affärstillståndsregister.

Metod 7: Uthållig arbetsflödesmotor

En uthållig arbetsflödesmotor hanterar långvarig exekvering, timrar, omförsök och återhämtning. Temporal är det vanligaste valet för Go- och Python-baserade assistentbackends; för en full implementeringsguide se Implementering av arbetsflödesapplikationer med Temporal i Go.

Istället för att manuellt koppla varje väntan och omförsök, modellerar du processen som ett arbetsflöde.

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

Hur det körs

Arbetsflödet startar en gång och kontrollerar sedan sin egen väntan. Det kan sova i minuter, dagar eller veckor. Om arbetarprocessen kraschar kan arbetsflödesmotorn återuppta från det registrerade tillståndet.

Tillståndsmodell

Arbetsflödesmotorn sparar:

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

Din applikationsdatabas sparar:

user-facing poll definition
authorization references
business records
notification records

Arbetsflödesmotorn äger procestillstånd — exekveringshistorik, timrar, omförsök och aktivitetsförsök. Din databas äger affärstillstånd — användarkonfigurationer, auktoriseringsposter, aviseringar och revisionsloggar. Att hålla dessa separerade förhindrar att varje lager blir en förvirrad hybrid av båda.

Bäst passning

Använd uthålliga arbetsflöden för:

• Flerstegs affärsprocesser.
• Långvariga automatiseringar.
• Mänskliga godkännandeflöden.
• Tillförlitliga omförsök.
• Reviderbar bakgrundsarbeten.
• Processer som måste återupptas efter misslyckande.

Svagheter

Arbetsflödesmotorer lägger till koncept och infrastruktur. De är utmärkta när processen är viktig, men tunga för enkla timvisa kontroller.

Metod 8: Persistent agentruntime

Vissa agentramverk kan persista agenttillstånd, checkpointa exekvering och återuppta senare.

Detta är användbart när agenten självt har en flersteps resonemangsprocess.

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

Hur det körs

En extern schemaläggare eller arbetsflöde startar agenten. Agentruntimet laddar tidigare tillstånd, kör nästa steg, kallar verktyg vid behov och skriver en checkpoint.

Agentruntimet bör inte vara din enda schemaläggare. Det är bättre att behandla den som resonemangslaget i en större backendarkitektur.

Tillståndsmodell

Agentcheckpoint-lagret innehåller:

current node
messages
tool outputs
intermediate reasoning state
pending action

Långtidsminne innehåller:

stable user preferences
facts
project context
source references

Operativt tillstånd tillhör fortfarande någon annars:

poll schedule
cursor
status
retry count
dedupe records

En användbar regel: minne är inte en markör, och en checkpoint är inte en kö. Agentminnet sparar vad modellen vet; operativt tillstånd spår var processen är och vad den har gjort. Att sammanfläta de två leder till subtila fel som bara dyker upp under konkurrens eller efter en omstart. Den fullständiga designytan för arbetsminne, uthålligt tillstånd och hämtningslager täcks i Minnesystem i AI-assistenter.

Bäst passning

Använd persistent agentruntime för:

• Flerstegs forskning.
• Agenter som pausar och återupptar.
• Human-in-the-loop-arbeten.
• Verktygsintensivt resonemang.
• Uppgifter där sammanhang ackumuleras över tid.

Svagheter

Agentpersistens är inte detsamma som operativ tillförlitlighet. Du behöver fortfarande schemaläggning, låsning, omförsök, hastighetsbegränsningar och revisionsloggar.

Metod 9: Databassynk plus förändringsutvärdering

I detta mönster används pollning för att synka extern data till din egen databas. Assistenten reagerar sedan på lokala databasförändringar snarare än att fråga externa API:er direkt vid varje utvärderingscykel.

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

Detta separerar data synkronisering från assistentintelligens. Synkarbetaren är ansvarig för att hålla lokala poster aktuella; utvärderaren är ansvarig för att avgöra vad som ska göras med förändringar. Varje lager kan testas, övervakas och skalas oberoende.

Hur det körs

Synkarbetaren hämtar periodiskt externa förändringar och skriver normaliserade poster i din databas. En annan arbetare eller förändringsström upptäcker uppdaterade rader och avgör om assistenten ska agera.

Tillståndsmodell

Synk-tabellen sparar:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Synktillståndet sparar:

source_cursor
last_sync_at
rate_limit_status
failure_count

Assistentutvärderingstabellen sparar:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Bäst passning

Använd detta mönster för:

• CRM-synk.
• Ticketing-system.
• Redovisningsdokument.
• Produktinventarier.
• Efterlevnadsgenomgång.
• Sökindecering.
• Interna dashboards.

Svagheter

Att synka allt kan vara dyrt och onödigt. Det kan också skapa integritets- och retentionsskyldigheter. Använd detta mönster när lokal data har värde bortom en enda assistentåtgärd.

Metod 10: Adaptiv pollning

Adaptiv pollning ändrar frekvens baserat på tillstånd, brådskande eller nyligen aktivitet.

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

Hur det körs

Efter varje körning avgör arbetaren när nästa körning ska ske.

Om objektet ändrades nyligen, polla tidigare. Om inget har ändrats på lång tid, saktar ner. Om uppgiften är klar, stoppa.

Tillståndsmodell

Pollningstillståndet inkluderar:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Källögonblicksbilden inkluderar:

status
updated_at
activity_level
expected_next_change

Bäst passning

Använd adaptiv pollning för:

• Deployningsstatus.
• Leveransspårning.
• Kalendertillgänglighet.
• Prissövervakning.
• Byggjobb.
• Långvariga leverantörsuppgifter.
• Alla källor med burstiga uppdateringar.

Svagheter

Adaptiv pollning kan vara svårare att resonera kring. Om en uppgift måste köras vid en strikt tid, håll den strikt. Gör inte efterlevnadsjobb smarta.

Metod 11: Semantisk pollning med LLM-utvärderare

Semantisk pollning används när villkoret är suddigt.

Kod kan svara:

Is status equal to Complete?
Is price below 100?
Is there a new message?

En LLM kan hjälpa till att svara:

Does this email sound urgent?
Is this customer likely unhappy?
Is this research paper relevant?
Does this change require my attention?

Hur det körs

Arbetaren applicerar först billiga deterministiska filter. Endast kandidatobjekt går till LLM.

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

Därefter utvärderar LLM den mindre kandidatuppsättningen och returnerar strukturerad utdata.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "The customer reports a production outage."
}

Tillståndsmodell

Pollningdefinitionen sparar:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Utvärderingsloggen sparar:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Pollningstillståndet sparar:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Bäst passning

Använd semantisk pollning för:

• Detektion av viktiga e-postmeddelanden.
• Kundkänslövervakning.
• Forskningslarm.
• Detektion av försäljningsmöjligheter.
• Säkerhetstriage.
• Exekutiva sammanfattningar.

Svagheter

LLM-anrop kostar pengar och lägger till latens. De kan också vara inkonsekventa om prompts och scheman är lösa. Använd deterministiska filter först. Be modellen endast när domslut faktiskt behövs.

Beskedstabell: Välj en pollningagentmetod

Rekommenderad standardarkitektur

För de flesta produktionsberedda AI-assistenter, börja med detta:

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

Ett minimalt schema:

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

Detta ger dig en ren separation:

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

Den separationen är hjärtat i en tillförlig pollningagent.

Exempel: Hermes-agent bearbetar Notion-uppgifter

Låt oss nu tillämpa arkitekturen på ett konkret fall.

Anta att en Notion-databas innehåller uppgifter. Hermes bör köra var 10:e minut, ta en uppgift i Todo-tillstånd, sätta den till InProgress, utföra den och sedan markera den Complete.

Detta är bäst beskrivet som:

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

För en produktionsversion blir det:

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

Notion-uppgiftsegenskaper

Notion-databasen bör innehålla fält som:

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

De viktiga fälten är ClaimedAt, ClaimExpiresAt och RunId. De gör uppgiftsanspråket synligt och återvinningsbart.

Hermes exekveringstillstånd

Hermes bör också behålla sin egen exekveringspost:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Detta skyddar dig om Notion redigeras manuellt, om ett API-anrop misslyckas, eller om du behöver revidera vad Hermes faktiskt gjorde.

Exekveringsflöde

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

Om Hermes kraschar efter att ha anspråkat en uppgift, kan leasingen upphöra:

Status = InProgress
ClaimExpiresAt < now

En framtida körning kan då återställa uppgiften eller markera den som misslyckad.

Felhantering

Vid framgång:

Status = Complete
CompletedAt = now
LastError = empty

Vid återställbart fel:

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

Vid icke-återställbart fel:

Status = Failed
LastError = clear explanation

För säkerhetens skull bör Hermes också använda en idempotensnyckel:

notion_page_id + task_version + action_type

Detta förhindrar att samma uppgift exekveras två gånger om ett omförsök händer vid fel tidpunkt.

Varför detta inte bara är pollning

Pollningsdelen är bara väcknemekanismen. Den verkliga arkitekturen är uppgiftsanspråk och tillförlig exekvering.

En naiv implementation säger:

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

En tillförlig implementation säger:

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

Det är skillnaden mellan en demo och en agent du kan lita på.

Vanliga pollningagentfel

Fel 1: Inget anspråksprotokoll

Om två arbetare kan se samma uppgift, kan de båda utföra den.

Använd:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Även om du för närvarande kör en arbetare, designa som om en annan arbetare kan dyka upp senare.

Fel 2: Ingen avdublingsnyckel

Varje extern åtgärd bör ha en avdublingsnyckel.

user_id + poll_id + source_object_id + action_type + condition_version

Detta förhindrar upprepade aviseringar, upprepade e-postmeddelanden, upprepade uppgiftsexekveringar och upprepade verktygsanrop. De bredare principerna bakom scope, lagring och testning av dessa nycklar gäller lika här — se Idempotens i distribuerade system som faktiskt fungerar.

Fel 3: Kalla LLM för tidigt

Be inte modellen att göra databasfiltrering.

Dåligt:

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

Bättre:

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

Fel 4: Behandla Notion som den enda backenden

Notion är ett bra mänskligt gränssnitt. Det är inte en komplett exekveringsbackend.

Behåll exekveringsloggar, omförsök, spår och idempotensposter i Hermes.

Fel 5: Oändlig pollning

Varje pollning bör ha en stoppvillkor.

Exempel:

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

En pollningagent utan stoppvillkor är en tyst kostnadsläcka.

Fel 6: Ingen observabilitet

Du bör kunna svara:

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?

Om du inte kan svara på dessa frågor, är systemet inte redo för viktigt arbete.

Observabilitetschecklista

Spåra metrik som:

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

Loggfält som:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Bygg en adminvy för:

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

Pollningagenter körs i bakgrunden, där fel är tysta och problem kan ackumuleras innan någon noterar. Bakgrundssystem behöver synlighet inbyggd från start, inte tillagd i efterhand när något går fel. För den fullständiga observabilitetsstacken för AI- och LLM-baserade system — metrik, spår, strukturerade loggar och SLO:er — se Observabilitet för LLM-system: Metrik, spår, loggar och testning i produktion.

Slutlig rekommendation

Pollningsmönster hanterar det proaktiva schemalägningslagret under ett multi-agent-system. När du har flera agenter som behöver samordna med varandra — inte bara polla oberoende — är nästa designbeslut hur de samordnas: hub-and-spoke, pipeline, fan-out eller swarm. Multi-Agent Orkestreringmönster täcker dessa samordningstopologier med felmoder och ett beslutsramverk.

För en seriös AI-assistent, börja med kö-baserade pollningsarbetare och ett uthålligt tillståndsregister. Lägg till webhooks där leverantörer stöder dem. Använd adaptiv pollning när hastighetsbegränsningar är viktiga. Använd en uthållig arbetsflödesmotor när processen är långvarig och flerstegs. Använd persistent agentruntime när agenten behöver resonera över tid.

För Hermes- och Notion-exemplet är rätt arkitektur:

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

Pollningsintervallet är inte den svåra delen. Den svåra delen är att se till att agenten anspråkar en uppgift, kör den en gång, registrerar vad som hände och lämnar systemet i ett tillstånd som människor kan förstå.

Det är det som förvandlar ett pollningscript till en tillförlig AI-assistent — inte intervallet, inte modellen, men disciplinen kring att anspråka arbete, registrera det och lämna systemet i ett tillstånd som både människor och framtida körningar kan förstå.