Polling-agenter i AI-assistenter: 11 implementeringsmönster

Pollningsagenter ä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 ställa en fråga. En pollningsagent fortsätter att övervaka. Den kontrollerar en källa, upptäcker förändringar, bedömer om något har betydelse och agerar därefter. Denna åtgärd kan vara en avisering, en sammanfattning, ett utkast, ett verktygsanrop eller en hel arbetsflödesprocess.

Så här flyttar en assistent från att “svara på min fråga” till att “hålla utkik åt mig”. Istället för att vara reaktiv blir den en bakgrundsprocess som uppmärksammar saker på användarens vägnar och agerar när förutsättningarna är uppfyllda.

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

Vad är en pollningsagent?

En pollningsagent är en bakgrundsprocess som upprepade gånger kontrollerar en källa och utlöser en assistentåtgärd när en villkor är uppfyllt. I den bredare stacken för AI-system — 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 bilden av de fem lagren, se AI-assistentarkitektur: LLM, minne, verktyg, routing, observabilitet.

Exempel:

• Kontrollera en inkorg varje morgon och sammanfatta viktiga meddelanden.
• Övervaka en Notion-uppgiftslista och utför nästa todo-uppgift.
• Övervaka ett GitHub-ärende tills dess status ändras.
• Polla en långvarig AI-jobb tills resultatet är klart.
• Kontrollera en bokningstid tills en blir tillgänglig.
• Övervaka en leverantörsportal tills ett dokument dyker upp.
• Skanna nya forskningsartiklar en gång i veckan och sammanfatta de relevanta.

En praktisk pollningsagent har fem ansvarsområden:

1. Vakna vid rätt tidpunkt.
2. Läs från källan.
3. Kom ihåg vad den redan har sett.
4. Bestäm 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
  -> pollningsarbetsprocess
  -> källsystem
  -> tillståndsbutik
  -> deterministiska filter
  -> valfri LLM-utvärdering
  -> assistentåtgärd

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

Det tillstånd varje pollningsagent behöver

Pollningsagenter behöver uthålligt tillstånd (durable state). Konversationshistorik räcker inte. Assistensen kan komma ihåg konversationen, men systemet behöver en pålitlig operativ post.

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.

Polldefinition

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: Tasks database
condition_text: Hitta en Todo-uppgift, anspråk den, utför den, markera den som Complete.

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

Cursor eller Snapshot

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 Notion-uppgiftskö kan cursorn vara mindre viktig än uppgiftsstatus och anspråk-fält. För Gmail, GitHub eller en synkroniserings-API är cursorn vanligtvis kritisk.

Anspråk eller Läs

Detta förhindrar att två arbetsprocesser 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 arbetsprocess 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 assistentbackenden, 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.

Deduperingspost

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öks igen kan systemet undertrycka den.

Metod 1: Schema-baserad pollningsarbetsprocess

Detta är det enklaste pålitliga mönstret.

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

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

Hur det körs

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

Varje intervall startar den en arbetsprocesskörning. Arbetsprocessen 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ättviktig arbetsprocess kan hantera dussintals dagliga kontroller utan att kräva köer, läs 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:

polldefinition
schema
cursor eller snapshot
senaste körningstid
antalsfel
status

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

Exempel på flöde

Var 10:e minut:
  utlös Hermes pollningsarbetsprocess

Arbetsprocess:
  ladda aktiv pollningskonfiguration
  fråga källan
  jämför med tidigare tillstånd
  kör deterministiska kontroller
  kalla LLM endast om nödvändigt
  uppdatera tillstånd
  emitiera händelse för assistenten

Bäst passform

Använd schema-baserade pollningsarbetsprocesser för:

• Dagliga sammanfattningar.
• Timvisa kontroller.
• Små interna automationer.
• Enkla “övervaka detta”-uppgifter.
• Assistenterjobb med låg till medelstor volym.

Svagheter

Schema-baserad pollning är lätt att förstå, men den kan bli ömbar vid skalning. Om många pollningar körs samtidigt kan du överbelasta dina arbetsprocesser eller träffas av leverantörens hastighetsbegränsningar. Återförsök kan också bli röriga om schemaläggaren direkt startar arbetet.

Metod 2: Köbaserade pollningsarbetsprocesser

Köbaserad pollning är vanligtvis det bästa standardvalet för produktions-AI-assistenter.

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

schemaläggare
  -> kö
  -> arbetsprocesspool
  -> käll-API
  -> tillståndsbutik
  -> assistentåtgärd

Hur det körs

En schemaläggare skannar efter pollningar som är förfallna och köar jobb. Arbetsprocesser hämtar jobb när de har kapacitet.

Detta ger dig backpressure (mottryck). Om systemet är upptaget väntar jobben i kön istället för att överbelasta 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
}

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

Exempel på flöde

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

Arbetsprocesser:
  hämtar jobb från kön
  låser eller läser pollningen
  frågar källan
  uppdaterar tillstånd
  emitierar assistentåtgärd om nödvändigt
  ställer in next_run_at

Bäst passform

Använd köbaserad pollning för:

• AI-assistenter med flera användare.
• Många samtidiga pollningar.
• Integrationer med hastighetsbegränsningar.
• Återförsökbart bakgrundarbeta.
• Jobb som kan ta olika lång tid.
• SaaS-produkter där pålitlighet är viktig.

Svagheter

Köer lägger till infrastruktur. Du behöver hantering av dead letter (meddelanden som inte kan bearbetas), idempotens, synlighetstidsgränser och återförsökpolicyer. Det är värt det för produktionssystem, men troligen överdrivet för en liten prototyp.

Metod 3: Externt verktyg som uppgiftskö

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

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 uppgiftsstatusen.

schemaläggare
  -> Hermes-arbetsprocess
  -> Notion-databas
  -> anspråka 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 efter prioritet och skapningstid. Därefter anspråkar den uppgiften genom att ställa den till InProgress.

Efter det 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 ett återförsöksantal.

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, återförsök, deduplikering och revisionshistorik.

Exempel på flöde

Var 10:e minut:
  Hermes vaknar

Hermes:
  frågar Notion efter en uppgift där Status = Todo
  sorterar efter Prioritet, CreatedAt
  uppdaterar vald uppgift till InProgress
  ställer in ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  utför uppgiften
  skriver exekveringslogg
  ställer uppgift till Complete eller Failed

Bäst passform

Använd detta mönster när:

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

Svagheter

Externa verktyg är sällan perfekta köer. Atomära 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 strategi för anspråk eller läs.

Den praktiska rekommendationen är att använda Notion som den mänskliga uppgiftsinkorgen medan man håller alla exekveringsloggar, återförsöksposter, spår och idempotensnycklar i Hermes. Notion ger användare synlighet; Hermes håller systemet pålitligt. För dispatchern och konkurrensmechanikerna som ligger bakom detta mönster i Hermes, se Kanban i Hermes Agent för självhostade LLM-arbetsflöden.

Metod 4: Långvarig arbetsprocessloop

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 bakgrundsagentarbete.

Hur det körs

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

Tillståndsmodell

Databasen sparar fortfarande uthålligt tillstånd:

pollkonfiguration
next_run_at
cursor
senaste resultat
antalsfel
status

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

aktuell batch
kortlivad cache
pågående körning

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 inget sätt att veta var sakerna lämnades.

Bäst passform

Använd långvariga looper för:

• Prototyper.
• Lokal utveckling.
• Interna verktyg.
• System med en hyresgäst (single-tenant).
• Agenter med låg volym.

Svagheter

Detta mönster blir riskabelt med flera repliker. Utan läser kan två arbetsprocesser 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 den är inte en distribuerad schemaläggare och bör inte behandlas som sådan. Så fort du behöver flera repliker eller starkare pålitlighetsgarantier måste du flytta 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.

extert system
  -> webhook-slutpunkt
  -> händelsetillstånd
  -> assistentåtgärd

sammanförande pollning
  -> käll-API
  -> jämför med händelsetillstånd
  -> repara missade händelser

Hur det körs

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

En långsammare sammanförande pollning körs varje några timmar eller en gång per dag. Den kontrollerar om några händelser har missats.

Tillståndsmodell

Händelsetillståndet registrerar inkommande webhooks:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Sammanförande pollningen 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 passform

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 slutpunkt, signaturvalidering, återlägningsskydd och händelsededuplikering. 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 varje minut vanligtvis slöseri.

Metod 6: Pollning av bakgrundsjobb på leverantörsidan

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

Applikationen startar ett långvarigt leverantörsjobb, sparar jobbidet och kontrollerar senare om det är klart.

app
  -> starta AI-bakgrundsjobb
  -> spara leverantörsjobbid
  -> polla status
  -> hämta resultat
  -> avisera användare

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, löper ut eller tidsgränsen nås.

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 har betydelse, kopiera den till din egen uthålliga lagring så snart jobbet är klart. Resultatlager på leverantörsidan har korta behållningsfönster och är inget substitut för ett ordentligt arkiv i ditt eget system.

Bäst passform

Använd pollning av bakgrundsjobb på leverantörsidan för:

• Långvariga AI-forskninguppgifter.
• Stor dokumentbearbetning.
• Kodanalys.
• Rapportgenerering.
• Dataextraktionsjobb.
• Uppgifter som överstiger normala HTTP-förfråganstidsgränser.

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åndsbutik.

Metod 7: Uthållig arbetsflödesmotor

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

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

arbetsflödesmotor
  -> aktivitet: kontrollera källa
  -> timer: vänta
  -> aktivitet: utvärdera resultat
  -> aktivitet: avisera användare

Hur det körs

Arbetsflödet startar en gång och kontrollerar därefter sin egen väntan. Det kan sova i minuter, dagar eller veckor. Om arbetsprocessen 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 processtillstånd — exekveringshistorik, timrar, återförsök och aktivitetsförsök. Din databas äger affärstillstånd — användarkonfigurationer, behörighetsposter, aviseringar och revisionsloggar. Att hålla dessa separata förhindrar att varje lager blir en förvirrad hybrid av båda.

Bäst passform

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

• Flerstegs affärsprocesser.
• Långvariga automationer.
• Flöden för mänsklig godkännande.
• Pålitliga återförsök.
• Revisionsbar bakgrundarbete.
• 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 behålla agenttillstånd, checkpunkta exekvering och återuppta senare.

Detta är användbart när agenten självt har en flertrådig resonemangsprocess.

schemaläggare eller arbetsflöde
  -> agentruntime
  -> ladda checkpunkt
  -> kalla verktyg
  -> spara checkpunkt
  -> återuppta senare

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 checkpunkt.

Agentruntimet bör inte vara din enda schemaläggare. Den är bättre att behandla som resonemangslaget i en större backend-arkitektur.

Tillståndsmodell

Agentcheckpunktslagring 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 annanstans:

poll schedule
cursor
status
retry count
dedupe records

En användbar regel: minne är inte en cursor, och en checkpunkt ä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 vid konkurrens eller efter en omstart. Den fullständiga designsfären för arbetsminne, uthålligt tillstånd och hämtningslager täcks i Minnesystem i AI-assistenter.

Bäst passform

Använd persistent agentruntime för:

• Flerstegs forskning.
• Agenter som pausar och återupptar.
• Human-in-the-loop-arbete.
• Resonemang med många verktyg.
• Uppgifter där sammanhang ackumuleras över tid.

Svagheter

Agentpersistens är inte samma sak som operativ pålitlighet. Du behöver fortfarande schemaläggning, låsning, återförsök, hastighetsbegränsningar och revisionsloggar.

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

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

synkpoler
  -> externt API
  -> lokal databas
  -> förändringsutvärderare
  -> assistentåtgärd

Detta separerar datasynkronisering från assistentintelligens. Synk-arbetsprocessen ä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

Synk-arbetsprocessen hämtar periodiskt externa förändringar och skriver normaliserade poster i din databas. En andra arbetsprocess eller förändringsström upptäcker uppdaterade rader och bestämmer 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

Synk-tillstå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 passform

Använd detta mönster för:

• CRM-synk.
• Ticketing-system.
• Redovisningsdokument.
• Produktinventering.
• Efterlevnadsgranskning.
• Sökindecering.
• Interna instrumentpaneler.

Svagheter

Att synkronisera allt kan vara dyrt och onödigt. Det kan också skapa integritets- och behållningsförpliktelser. Använd detta mönster när lokal data har värde bortom en ensam 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 bestämmer arbetsprocessen när nästa körning ska ske.

Om objektet ändrades nyligen, polla tidigare. Om ingenting 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ällsnapshoten inkluderar:

status
updated_at
activity_level
expected_next_change

Bäst passform

Använd adaptiv pollning för:

• Deployningsstatus.
• Leveransspårning.
• Tillgänglighet av kalendertid.
• Priss övervakning.
• Byggjobb.
• Långvariga leverantörsuppgifter.
• Alla källor med burst-aktiga 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 en LLM-utvärderare

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

Kod kan svara:

Är status lika med Complete?
Är priset under 100?
Finns det ett nytt meddelande?

En LLM kan hjälpa till att svara:

Ljudar detta e-postmeddelande brådskande?
Är denna kund troligen missnöjd?
Är denna forskningsartikel relevant?
Kräver denna förändring min uppmärksamhet?

Hur det körs

Arbetsprocessen tillämpar först billiga deterministiska filter. Endast kandidatobjekt går till LLM.

nytt objekt?
matchar källfilter?
inte redan bearbetat?
inte uppenbarbart irrelevant?

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

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Kunden rapporterar ett produktionsavbrott."
}

Tillståndsmodell

Polldefinitionen 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 passform

Använd semantisk pollning för:

• Detektering av viktiga e-postmeddelanden.
• Övervakning av kundstämning.
• Forskningslarm.
• Detektering 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 bedömning faktiskt behövs.

Beslutstabell: Välj en pollningsagentmetod

Rekommenderad standardarkitektur

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

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

En minimal 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:

schemaläggaren äger tiden
kön äger buffring
arbetsprocessen äger exekvering
databasen äger tillstånd
LLM äger semantisk bedömning
assistenten äger användarinteraktion

Den separationen är kärnan i en pålitlig pollningsagent.

Exempel: Hermes-agent som 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, ställa den till InProgress, utföra den och därefter markera den som 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 återställningsbart.

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 granska 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 läset löpa ut:

Status = InProgress
ClaimExpiresAt < nu

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

Felhantering

Vid framgång:

Status = Complete
CompletedAt = nu
LastError = tom

Vid återställningsbart fel:

Status = Todo
RetryCount = RetryCount + 1
LastError = kort felmeddelande

Vid icke-återställbart fel:

Status = Failed
LastError = tydlig förklaring

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 utförs två gånger om ett återförsök händer vid fel tid.

Varför detta inte bara är pollning

Pollningsdelen är bara väckmekanismen. Den riktiga arkitekturen är uppgiftsanspråk och pålitlig exekvering.

En naiv implementation säger:

Var 10:e minut, hitta en Todo-uppgift och gör den.

En pålitlig implementation säger:

Var 10:e minut, anspråka exakt en kvalificerad uppgift, registrera körningen, utför idempotent och flytta uppgiften till ett terminaltillstånd.

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

Vanliga pollningsagentfel

Fel 1: Inget anspråksprotokoll

Om två arbetsprocesser 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 arbetsprocess, designa som om en andra arbetsprocess kan dyka upp senare.

Fel 2: Ingen deduplikeringssnyckel

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

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 omfång, lagring och testning av dessa nycklar gäller lika här — se Idempotens i distribuerade system som faktiskt fungerar.

Fel 3: Att kalla LLM för tidigt

Be inte modellen att göra databasfiltrering.

Dåligt:

Skicka alla uppgifter till LLM och fråga vilken som är Todo.

Bättre:

Använd Notion-API-filtret för att hämta Todo-uppgifter.
Använd sedan LLM endast om uppgiftstolkning behövs.

Fel 4: Att behandla Notion som den enda backenden

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

Håll exekveringsloggar, återförsök, spår och idempotensposter i Hermes.

Fel 5: Oändlig pollning

Varje pollning bör ha en stoppvillkor.

Exempel:

stoppa efter framgång
stoppa efter datum
stoppa efter max antal återförsök
stoppa när användaren inaktiverar den
stoppa efter upprepade behörighetsfel

En pollningsagent utan stoppvillkor är en tyst kostnadsutsläpp.

Fel 6: Ingen observabilitet

Du bör kunna svara på:

Vad körde agenten?
Varför körde den?
Vad läste den?
Vad ändrade den?
Varför misslyckades den?
Aviserade den användaren?
Körde den två gånger?

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

Observabilitetschecklista

Spåra mått så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 så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

Pollningsagenter körs i bakgrunden, där fel är tysta och problem kan ackumuleras innan någon märker det. Bakgrundssystem behöver synlighet inbyggd från start, inte tillagd som ett eftertanke när något går fel. För den fullständiga observabilitetsstacken för AI- och LLM-baserade system — mått, spår, strukturerade loggar och SLO:er — se Observabilitet för LLM-system: Mått, spår, loggar och testning i produktion.

Slutlig rekommendation

För en seriös AI-assistent, börja med köbaserade pollningsarbetsprocesser och en uthållig tillståndsbutik. 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 flertrådig. Använd persistent agentruntime när agenten behöver resonera över tid.

För Hermes- och Notion-exemplet är den rätta arkitekturen:

Notion som den mänskliga uppgiftsinkorgen
Hermes schemaläggare var 10:e minut
Hermes arbetsprocess med anspråks- eller läslógica
Hermes backend för exekveringsloggar och idempotens
Notion statusuppdateringar för synlighet

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 pollningsscript till en pålitlig 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å.