Agentów odpytujących w asystentach AI: 11 wzorców implementacji

Agenci pollingowi to jedna z najmniej glamour części architektury asystentów AI, ale jednocześnie jedna z najbardziej przydatnych.

Zwykły asystent czatowy czeka, aż użytkownik zadaje pytanie. Agent pollingowy nieustannie obserwuje. Sprawdza źródło, dostrzega zmiany, decyduje, czy mają one znaczenie, a następnie działa. Ta akcja może być powiadomieniem, podsumowaniem, szkicem, wywołaniem narzędzia lub pełnym przepływem pracy.

Dzięki temu asystant przechodzi od modelu „odpowiedz na moje pytanie” do „trzymaj rękę na pulsie za mnie”. Zamiast być reaktywny, staje się procesem działającym w tle, który zauważa rzeczy w imieniu użytkownika i działa, gdy spełnione są określone warunki.

Kluczowa zasada projektowania jest prosta: nie obciążaj modelu językowego odpowiedzialnością za czas, stan, ponowe próby (retries) czy blokady (locking). Wykorzystaj do tego zwykłą infrastrukturę backendową. Używaj tam, gdzie model jest wartościowy: interpretując nieporządkowany kontekst, podejmując semantyczne decyzje i generując przydatne teksty.

Czym jest agent pollingowy?

Agent pollingowy to proces działający w tle, który powtarzająco sprawdza źródło i uruchamia akcję asystenta, gdy spełniony jest określony warunek. W szerszym stosie Systemów AI — gdzie asystent łączy LLM, pamięć, narzędzia, routing i obserwowalność — warstwa pollingowa sprawia, że asystant staje się proaktywny, a nie tylko reaktywny. Pełny obraz pięciowarstwowej architektury znajdziesz w artykule Architektura asystenta AI: LLM, pamięć, narzędzia, routing, obserwowalność.

Przykłady:

• Sprawdzanie skrzynki odbiorczej każdego ranka i podsumowywanie ważnych wiadomości.
• Monitorowanie listy zadań w Notion i wykonywanie kolejnego elementu „todo”.
• Obserwowanie zgłoszenia w GitHubie do momentu zmiany jego statusu.
• Polling długotrwałego zadania AI do momentu gotowości wyniku.
• Sprawdzanie dostępności terminu rezerwacji, aż pojawi się wolny slot.
• Monitorowanie portalu dostawcy do momentu pojawienia się dokumentu.
• Tygodniowe skanowanie nowych artykułów badawczych i podsumowywanie tych istotnych.

Praktyczny agent pollingowy ma pięć odpowiedzialności:

1. Budzić się w odpowiednim czasie.
2. Czytać ze źródła.
3. Pamiętać, co już widział.
4. Decydować, czy nowy stan ma znaczenie.
5. Działać raz, bezpiecznie, bez powielania działań.

Typowy przepływ produkcyjny wygląda następująco:

kalendarz (scheduler)
  -> pracownik pollingowy (polling worker)
  -> system źródłowy
  -> magazyn stanów (state store)
  -> deterministyczne filtry
  -> opcjonalna ocena LLM
  -> akcja asystenta

Ta struktura jest nudna w możliwy do osiągnięcia najlepszy sposób. Nudzące systemy są łatwiejsze do debugowania o 2 rano.

Stan potrzebny każdemu agentowi pollingowemu

Agenci pollingowi wymagają trwałego stanu. Historia rozmowy nie wystarczy. Asystent może pamiętać rozmowę, ale system potrzebuje niezawodnego rekordu operacyjnego.

Dobry rekord stanu pollingowego zwykle zawiera:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "weź jedno zadanie w stanie Todo i wykonaj je",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "kursor_lub_tymestempel",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "aktywny"
}

Dokładny schemat zależy od źródła, ale większość systemów potrzebuje tych koncepcji.

Definicja pollingowa

Opisuje, co agent obserwuje i dlaczego.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Na przykład:

source_type: notion
source_ref: Baza danych zadań
condition_text: Znajdź zadanie Todo, przejmij je, wykonaj, oznacz jako Zakończone.

Harmonogram

Opisuje, kiedy agent powinien działać.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Dla agenta Hermes sprawdzającego Notion co 10 minut:

interval_seconds: 600
timezone: Australia/Melbourne

Kursor lub snapshot

Pomaga agentowi uniknąć ponownego przetwarzania tych samych danych.

W zależności od źródła może to być:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Dla kolejki zadań w Notion kursor może być mniej ważny niż status zadania i pola rezerwacji (claim). Dla Gmaila, GitHuba lub API synchronizacji kursor jest zwykle krytyczny.

Rezerwacja (Claim) lub najem (Lease)

Zapobiega przejęciu tego samego zadania przez dwóch pracowników (workers).

claimed_by
claimed_at
claim_expires_at
run_id

Na przykład zadanie w Notion może zostać zmienione z:

Status: Todo

na:

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

To jest różnica między „mam nadzieję, że tylko jeden pracownik to wybierze” a „system ma protokół rezerwacji”.

Rekord wykonania

Rejestruje, co się stało podczas uruchomienia.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Rekord wykonania powinien istnieć w backendzie asystenta, a nie tylko w Notionie lub innym zewnętrznym narzędziu. Notion jest dobry dla widoczności przez człowieka. Nie jest idealny jako jedyny dziennik wykonania.

Rekord deduplikacji

Zapobiega powielaniu powiadomień lub akcji.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Na przykład:

user_456:poll_123:notion_page_999:execute:v1

Jeśli ta sama akcja zostanie próbna ponownie, system może ją zablokować.

Metoda 1: Zaplanowany pracownik pollingowy

To najprostszy niezawodny wzorzec.

Kalendarz (scheduler) budzi się co określony interwał i wywołuje pracownika (workera). Pracownik czyta ze źródła, aktualizuje stan i uruchamia akcję asystenta, jeśli jest to wymagane.

kalendarz
  -> pracownik
  -> API źródła
  -> baza danych
  -> akcja asystenta

Jak to działa

Kalendarz jest odpowiedzialny za czas. Może to być cron, kalendarz chmurowy, CronJob w Kubernetes lub mały wewnętrzny kalendarz.

Co interwał, uruchamia on uruchomienie pracownika. Pracownik ładuje konfigurację, zapytuje docelowe źródło, porównuje wynik ze zmagazynowanym stanem i działa, jeśli jest to potrzebne.

Dla prostego asystenta często jest to wystarczające. Pojedynczy kalendarz i lekki proces pracownika mogą obsłużyć dziesiątki dziennych sprawdzeń bez konieczności używania kolejek, najemów lub dystrybuowanej koordynacji.

Model stanu

Kalendarz przechowuje bardzo mało danych. Zwykle wie tylko, kiedy uruchomić zadanie.

Baza danych aplikacji przechowuje ważny stan:

definicja pollingowa
harmonogram
kursor lub snapshot
czas ostatniego uruchomienia
licznik awarii
status

Pracownik powinien być bezstanowy (stateless). Może trzymać tymczasowe dane podczas działania, ale trwała prawda należy do bazy danych.

Przykładowy przepływ

Co 10 minut:
  uruchom pracownika pollingowego Hermes

Pracownik:
  ładuje aktywną konfigurację pollingową
  zapytuje źródło
  porównuje ze poprzednim stanem
  uruchamia deterministyczne sprawdzenia
  wywołuje LLM tylko jeśli potrzebne
  aktualizuje stan
  emituje zdarzenie asystenta

Najlepsze zastosowanie

Używaj zaplanowanych pracowników pollingowych do:

• Dziennych podsumowań.
• Godzinnych sprawdzeń.
• Małych wewnętrznych automatyzacji.
• Prostych zadań typu „obserwuj to”.
• Zadań asystenta o niskim do średnim natężeniu.

Wady

Polling zaplanowany jest łatwy do zrozumienia, ale może stać się kruchy przy skalowaniu. Jeśli wiele pollingów uruchamia się jednocześnie, możesz przeciążyć pracowników lub uderzyć w limity współczynników dostawcy (rate limits). Ponowe próby mogą też stać się chaotyczne, jeśli kalendarz bezpośrednio zaczyna pracę.

Metoda 2: Pracownicy pollingowi oparte na kolejkach

Polling oparty na kolejkach jest zwykle najlepszym domyślnym wyborem dla produkcyjnych asystentów AI.

Kalendarz nie wykonuje pollinga bezpośrednio. Umieszcza zadanie w kolejce. Procesy pracowników pobierają zadania z kolejki.

kalendarz
  -> kolejka
  -> pulę pracowników
  -> API źródła
  -> magazyn stanów
  -> akcja asystenta

Jak to działa

Kalendarz skanuje pollingi należne ienqueue-uje zadania. Pracownicy pobierają zadania, gdy mają pojemność.

Daje to Ci backpressure (ciśnienie zwrotne). Jeśli system jest zajęty, zadania czekają w kolejce zamiast przytłaczać API źródła lub dostawcę LLM.

Model stanu

Baza danych przechowuje stan pollingowy:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Wiadomość kolejki powinna być mała:

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

Pracownik ładuje pełny stan z bazy danych przy starcie.

Przykładowy przepływ

Co minutę:
  kalendarz znajduje pollingi gdzie next_run_at <= teraz
  kalendarz enqueue-uje zadania

Pracownicy:
  pobierają zadania z kolejki
  blokują lub najemują polling
  zapytują źródło
  aktualizują stan
  emitują akcję asystenta jeśli potrzebna
  ustawiają next_run_at

Najlepsze zastosowanie

Używaj pollinga opartego na kolejkach do:

• Wieloużytkowych asystentów AI.
• Wielu równoczesnych pollingów.
• Integracji z limitami współczynników.
• Ponownych prób pracy w tle.
• Zadań, które mogą trwać różny czas.
• Produktów SaaS, gdzie niezawodność ma znaczenie.

Wady

Kolejki dodają infrastrukturę. Potrzebujesz obsługi kolejki martwych listów (dead letter), idempotentności, timeoutów widoczności i polityk ponownych prób. Opłaca się to dla systemów produkcyjnych, ale prawdopodobnie jest to przesada dla małego prototypu.

Metoda 3: Zewnętrzne narzędzie jako kolejka zadań

To wzorzec z przykładu Notion plus Hermes.

Zewnętrzne narzędzie nie jest tylko źródłem danych. Staje się kolejką zadań skierowaną do człowieka. Agent okresowo sprawdza narzędzie, przejmuje jedno zadanie, wykonuje je i aktualizuje status zadania.

kalendarz
  -> pracownik Hermes
  -> baza danych Notion
  -> przejmij jedno zadanie
  -> wykonaj zadanie
  -> zaktualizuj status Notion

Jak to działa

Co 10 minut Hermes zapytuje bazę danych Notion o jedno zadanie w stanie Todo. Wybiera kolejne zadanie, zwykle według priorytetu i czasu utworzenia. Następnie przejmuje zadanie, ustawiając je na InProgress.

Po tym Hermes wykonuje zadanie. Jeśli wykonanie się powiedzie, oznacza zadanie jako Complete. Jeśli wykonanie się nie powiedzie, oznacza zadanie jako Failed lub zwraca je do Todo z licznikiem ponownych prób.

Model stanu

Notion przechowuje stan zadań skierowanych do człowieka:

Tytuł
Opis
Status: Todo | InProgress | Complete | Failed
Priorytet
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Backend Hermes przechowuje operacyjny stan wykonania:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
szczegóły błędu
idempotency_key

To rozdzielenie ma znaczenie. Notion jest doskonały do widoczności i edycji ręcznej. Backend Hermes jest lepszy do logów, ponownych prób, deduplikacji i historii audytowej.

Przykładowy przepływ

Co 10 minut:
  Hermes się budzi

Hermes:
  zapytuje Notion o jedno zadanie gdzie Status = Todo
  sortuje według Priorytetu, CreatedAt
  aktualizuje wybrane zadanie na InProgress
  ustawia ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  wykonuje zadanie
  zapisuje log wykonania
  ustawia zadanie na Complete lub Failed

Najlepsze zastosowanie

Używaj tego wzorca gdy:

• Ludzie już zarządzają pracą w Notion, Jira, Linear, Trello lub innym narzędziu.
• Chcesz, aby asystent przetwarzał widoczne zadania.
• Tablica zadań jest interfejsem użytkownika.
• Potrzebujesz prostego modelu automatyzacji z człowiekiem w pętli (human-in-the-loop).

Wady

Zewnętrzne narzędzie rzadko jest idealną kolejką. Atomowe rezerwacje mogą być ograniczone. Spójność zapytań może opóźniać. Mogą obowiązywać limity współczynników. Jeśli agent może działać w wielu instancjach, potrzebujesz ostrożnej strategii rezerwacji lub najmu.

Praktyczną rekomendacją jest używanie Notion jako skrzynki odbiorczej zadań skierowanej do człowieka, trzymając przy tym wszystkie logi wykonania, rekordy ponownych prób, ślady i klucze idempotentności w Hermesie. Notion daje użytkownikom widoczność; Hermes utrzymuje system niezawodnym. Dla mechanik dyspozytora i współbieżności, które leżą za tym wzorcem w Hermesie, zobacz Kanban w agencie Hermes dla samodzielnie hostowanych przepływów pracy LLM.

Metoda 4: Pętla długotrwałego pracownika

Długotrwała pętla jest najprostszą implementacją.

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

Ten wzorzec łączy harmonogramowanie i wykonanie w jednej usłudze, co czyni go najprostszym możliwym punktem startu dla pracy agenta w tle.

Jak to działa

Proces pracownika działa ciągle. Co kilka sekund lub minut sprawdza bazę danych pod kątem należnych pollingów i wykonuje je. Jest łatwy do zbudowania, łatwy do rozumowania i szybki do iteracji podczas rozwoju.

Model stanu

Baza danych nadal przechowuje trwały stan:

konfiguracja pollingowa
next_run_at
cursor
ostatni wynik
licznik awarii
status

Pamięć procesu powinna zawierać tylko stan tymczasowy:

bieżąca partia
krótkotrwała pamięć podręczna
bieżące uruchomienie

Nigdy nie przechowuj ważnego postępu tylko w pamięci. Jeśli proces się zawali, cały stan, który nie został zapisany w trwałym magazynie, ginie, a kolejne uruchomienie nie będzie miał możliwości poznania, w którym miejscu zostały rzeczy.

Najlepsze zastosowanie

Używaj długotrwałych pętli do:

• Prototypów.
• Rozwoju lokalnego.
• Wewnętrznych narzędzi.
• Systemów jedno-najemcy (single-tenant).
• Agentów o niskim natężeniu.

Wady

Ten wzorzec staje się ryzykowny z wieloma replikami. Bez najemów (leases) dwa pracownicy mogą uruchomić ten sam polling. Brakuje mu również funkcji operacyjnych prawdziwej kolejki lub silnika przepływów pracy.

Długotrwała pętla nie jest błędem jako punkt startowy, ale nie jest dystrybuowanym kalendarzem i nie powinna być traktowana jako taka. Gdy tylko będziesz potrzebować wielu replik lub silniejszych gwarancji niezawodności, będziesz musiał przejść do jednego z bardziej strukturalnych wzorców powyżej.

Metoda 5: Najpierw Webhook z fallbackiem do pollinga

Jeśli źródło obsługuje webhoki, użyj ich. Polling powinien często być kopią zapasową, a nie głównym mechanizmem. To samo rozdzielenie pojawia się w projektowaniu protokołów agentów: powiadomienia push A2A budzą handler klienta, który następnie sprawdza GetTask w celu uzyskania pełnego stanu, jak opisano w Strumieniowanie A2A i zadania asynchroniczne dla długotrwałych przepływów pracy agentów.

system zewnętrzny
  -> endpoint webhook
  -> magazyn zdarzeń
  -> akcja asystenta

polling harmonizacyjny
  -> API źródła
  -> porównaj z magazynem zdarzeń
  -> napraw przegapięte zdarzenia

Jak to działa

System zewnętrzny wysyła zdarzenia do Twojego endpointu webhook, gdy coś się zmienia. Twój system przechowuje zdarzenie i przetwarza je asynchronicznie.

Powolny polling harmonizacyjny (reconciliation) uruchamia się co kilka godzin lub raz dziennie. Sprawdza, czy jakieś zdarzenia zostały przegapięte.

Model stanu

Magazyn zdarzeń rejestruje przychodzące webhoki:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Polling harmonizacyjny przechowuje:

last_reconciliation_at
last_seen_cursor
last_seen_version

Tabela obiektów źródłowych przechowuje najnowszy znany stan:

external_id
current_status
external_updated_at
last_processed_event_id

Najlepsze zastosowanie

Używaj architektury „najpierw webhook” do:

• Zdarzeń GitHub.
• Zdarzeń Stripe.
• Zdarzeń Slack.
• Aktualizacji CRM.
• Powiadomień o wdrożeniach.
• Systemów ticketingowych.

Wady

Webhoki wymagają publicznego endpointu, walidacji podpisu, ochrony przed odtworzeniem (replay protection) i deduplikacji zdarzeń. Niektórzy dostawcy wysyłają również niekompletne zdarzenia, więc nadal możesz potrzebować pobrania pełnego obiektu.

Nawet tak, jeśli istnieją dobre webhoki, polling co minutę jest zwykle marnotrawstwem.

Metoda 6: Polling zadań w tle po stronie dostawcy

Czasami rzecz, która jest pollingowana, to samo zadanie AI.

Aplikacja uruchamia długotrwałe zadanie dostawcy, przechowuje ID zadania i sprawdza później, czy zostało ukończone.

aplikacja
  -> uruchom zadanie AI w tle
  -> przechowuj ID zadania dostawcy
  -> sprawdź status
  -> pobierz wynik
  -> powiadom użytkownika

Jak to działa

Asystent uruchamia zadanie z dostawcą. Dostawca zwraca ID. Twój backend przechowuje to ID i sprawdza jego status, dopóki zadanie się nie powiedzie, nie zawali, nie wygaśnie lub nie przekroczy limitu czasu.

Model stanu

Twój backend przechowuje:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Dostawca przechowuje tymczasowy stan zadania i wyjście.

Jeśli wyjście ma znaczenie, skopiuj je do własnego trwałego magazynu tak szybko, jak zadanie się zakończy. Przechowywanie wyników po stronie dostawcy ma krótkie okna retencji i nie jest zastępstwem dla odpowiedniego archiwum we własnym systemie.

Najlepsze zastosowanie

Używaj pollinga zadań w tle po stronie dostawcy do:

• Długich zadań badawczych AI.
• Przetwarzania dużych dokumentów.
• Analizy kodu.
• Generowania raportów.
• Zadań ekstrakcji danych.
• Zadań przekraczających normalne limity czasu żądań HTTP.

Wady

Ten wzorzec rozwiązuje jeden problem: oczekiwanie na długie zadanie dostawcy. Nie zastępuje on Twojego silnika przepływów pracy, kalendarza, kolejki ani magazynu stanu biznesowego.

Metoda 7: Trwały silnik przepływów pracy

Trwały silnik przepływów pracy zarządza długotrwałym wykonaniem, timerami, ponownymi próbami i odzyskiwaniem. Temporal jest najczęstszym wyborem dla backendów asystentów opartych na Go i Python; pełny przewodnik implementacyjny znajdziesz w Implementacja aplikacji przepływów pracy z Temporal w Go.

Zamiast ręcznego łączenia każdego oczekiwania i ponownej próby, modelujesz proces jako przepływ pracy.

silnik przepływów pracy
  -> aktywność: sprawdź źródło
  -> timer: czekaj
  -> aktywność: oceń wynik
  -> aktywność: powiadom użytkownika

Jak to działa

Przepływ pracy zaczyna się raz i następnie kontroluje własne oczekiwanie. Może spać przez minuty, dni lub tygodnie. Jeśli proces pracownika się zawali, silnik przepływów pracy może wznowić działanie od zapisanego stanu.

Model stanu

Silnik przepływów pracy przechowuje:

workflow_id
historia wykonania
stan timera
ponowne próby aktywności
polityka ponownych prób
bieżący stan przepływu pracy

Twoja baza danych aplikacji przechowuje:

definicja pollingowa skierowana do użytkownika
referencje autoryzacyjne
rekordy biznesowe
rekordy powiadomień

Silnik przepływów pracy posiada stan procesu — historię wykonania, timery, ponowne próby i próby aktywności. Twoja baza danych posiada stan biznesowy — konfiguracje użytkownika, rekordy autoryzacji, powiadomienia i logi audytowe. Utrzymywanie tych warstw osobno zapobiega temu, aby każda warstwa stała się zdezorientowanym hybrydą obu.

Najlepsze zastosowanie

Używaj trwałych przepływów pracy do:

• Wieloetapowych procesów biznesowych.
• Długotrwałych automatyzacji.
• Przepływów zatwierdzania przez człowieka.
• Niezawodnych ponownych prób.
• Pracy w tle podlegającej audytowi.
• Procesów, które muszą zostać wznowione po awarii.

Wady

Silniki przepływów pracy dodają koncepcje i infrastrukturę. Są doskonałe, gdy proces jest ważny, ale ciężkie dla prostych godzinnych sprawdzeń.

Metoda 8: Trwały runtime agenta

Niektóre frameworki agentów mogą utrzymywać stan agenta, tworzyć punkty kontrolne (checkpoint) i wznawiać działanie później.

Jest to przydatne, gdy sam agent ma wieloetapowy proces rozumowania.

kalendarz lub przepływ pracy
  -> runtime agenta
  -> załaduj punkt kontrolny
  -> wywołaj narzędzia
  -> zapisz punkt kontrolny
  -> wznów później

Jak to działa

Zewnętrzny kalendarz lub przepływ pracy uruchamia agenta. Runtime agenta ładuje poprzedni stan, uruchamia kolejny krok, wywołuje narzędzia, jeśli jest to potrzebne, i zapisuje punkt kontrolny.

Runtime agenta nie powinien być Twoim jedynym kalendarzem. Lepiej traktować go jako warstwę rozumowania wewnątrz większej architektury backendowej.

Model stanu

Magazyn punktów kontrolnych agenta zawiera:

bieżący węzeł
wiadomości
wyjścia narzędzi
pośredni stan rozumowania
oczekująca akcja

Pamięć długoterminowa zawiera:

trwałe preferencje użytkownika
fakty
kontekst projektu
referencje źródłowe

Stan operacyjny nadal należy do innego miejsca:

harmonogram pollingowy
kursor
status
licznik ponownych prób
rekordy deduplikacji

Przydatna zasada: pamięć nie jest kursorem, a punkt kontrolny nie jest kolejką. Pamięć agenta przechowuje to, co model wie; stan operacyjny śledzi, gdzie jest proces i co już zrobił. Połączenie obu prowadzi do subtelnych błędów, które pojawiają się tylko przy współbieżności lub po restarcie. Pełna przestrzeń projektowa dla pracy pamięci, trwałego stanu i warstw odzyskiwania jest omówiona w Systemach pamięci w asystentach AI.

Najlepsze zastosowanie

Używaj trwałego runtime agenta do:

• Wieloetapowych badań.
• Agentów, które pauzują i wznawiają.
• Pracy z człowiekiem w pętli.
• Rozumowania opartego na narzędziach.
• Zadań, gdzie kontekst narasta z czasem.

Wady

Utrwalanie stanu agenta nie jest tym samym, co niezawodność operacyjna. Nadal potrzebujesz harmonogramowania, blokowania, ponownych prób, limitów współczynników i logów audytowych.

Metoda 9: Synchronizacja bazy danych plus ocena zmian

W tym wzorcu polling jest używany do synchronizacji danych zewnętrznych do własnej bazy danych. Asystent reaguje następnie na lokalne zmiany bazy danych, zamiast zapytywać zewnętrzne API bezpośrednio w każdym cyklu oceny.

poller synchronizacji
  -> API zewnętrzne
  -> lokalna baza danych
  -> oceniaacz zmian
  -> akcja asystenta

To oddziela synchronizację danych od inteligencji asystenta. Pracownik synchronizacji jest odpowiedzialny za utrzymywanie aktualnych lokalnych rekordów; oceniaacz jest odpowiedzialny za decyzję, co zrobić ze zmianami. Każda warstwa może być testowana, monitorowana i skalowana niezależnie.

Jak to działa

Pracownik synchronizacji okresowo pobiera zewnętrzne zmiany i zapisuje znormalizowane rekordy do bazy danych. Drugi pracownik lub strumień zmian wykrywa zaktualizowane wiersze i decyduje, czy asystent powinien działać.

Model stanu

Tabela synchronizacji przechowuje:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Stan synchronizacji przechowuje:

source_cursor
last_sync_at
rate_limit_status
failure_count

Tabela oceny asystenta przechowuje:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Najlepsze zastosowanie

Używaj tego wzorca do:

• Synchronizacji CRM.
• Systemów ticketingowych.
• Dokumentów księgowych.
• Inwentarza produktów.
• Przeglądu zgodności.
• Indeksowania wyszukiwania.
• Wewnętrznych dashboardów.

Wady

Synchronizacja wszystkiego może być droga i niepotrzebna. Może również tworzyć zobowiązania prywatności i retencji. Używaj tego wzorca, gdy lokalne dane mają wartość poza pojedynczą akcją asystenta.

Metoda 10: Polling adaptacyjny

Polling adaptacyjny zmienia częstotliwość w zależności od stanu, pilności lub ostatniej aktywności.

aktywny obiekt: polling co 1 minutę
oczekujący obiekt: polling co 1 godzinę
przestarzały obiekt: polling raz dziennie
ukończony obiekt: zatrzymaj polling

Jak to działa

Po każdym uruchomieniu pracownik decyduje, kiedy powinno nastąpić kolejne uruchomienie.

Jeśli obiekt zmienił się ostatnio, polluj szybciej. Jeśli nic się nie zmieniło przez długi czas, zwolnij. Jeśli zadanie jest ukończone, zatrzymaj.

Model stanu

Stan pollingowy zawiera:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Snapshot źródła zawiera:

status
updated_at
activity_level
expected_next_change

Najlepsze zastosowanie

Używaj pollinga adaptacyjnego do:

• Statusu wdrożenia.
• Śledzenia dostaw.
• Dostępności slotów kalendarzowych.
• Monitorowania cen.
• Zadań budowania.
• Długotrwałych zadań dostawcy.
• Dowolnych źródeł z nieregularnymi aktualizacjami.

Wady

Polling adaptacyjny może być trudniejszy do rozumowania. Jeśli zadanie musi uruchomić się o ściśle określonej porze, utrzymaj tę ścisłość. Nie rób zadań zgodnościowych „mądrymi”.

Metoda 11: Polling semantyczny z oceniaaczem LLM

Polling semantyczny jest używany, gdy warunek jest nieostry (fuzzy).

Kod może odpowiedzieć:

Czy status jest równy Complete?
Czy cena jest poniżej 100?
Czy jest nowa wiadomość?

LLM może pomóc odpowiedzieć:

Czy ten e-mail brzmi pilnie?
Czy ten klient jest prawdopodobnie niezadowolony?
Czy ten artykuł badawczy jest istotny?
Czy ta zmiana wymaga mojej uwagi?

Jak to działa

Pracownik najpierw stosuje tanie deterministyczne filtry. Tylko kandydujące elementy trafiają do LLM.

nowy element?
zgodny z filtrami źródłowymi?
nie przetwarzany już?
nie oczywicie nieistotny?

Następnie LLM ocenia mniejszy zbiór kandydatów i zwraca strukturalne wyjście.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Klient zgłasza awarię w produkcji."
}

Model stanu

Definicja pollingowa przechowuje:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Log oceny przechowuje:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Stan pollingowy przechowuje:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Najlepsze zastosowanie

Używaj pollinga semantycznego do:

• Wykrywania ważnych e-maili.
• Monitorowania nastroju klientów.
• Alertów badawczych.
• Wykrywania możliwości sprzedaży.
• Triady bezpieczeństwa.
• Skryptów dla kadry kierowniczej.

Wady

Wywołania LLM kosztują pieniądze i dodają opóźnienia. Mogą również być niespójne, jeśli prompty i schematy są luźne. Używaj deterministycznych filtrów najpierw. Pytaj model tylko wtedy, gdy osąd jest naprawdę potrzebny.

Tabela decyzyjna: Wybór metody agenta pollingowego

Rekomendowana domyślna architektura

Dla większości produkcyjnych asystentów AI zacznij od tego:

tabela pollingów
  -> kalendarz
  -> kolejka
  -> pracownicy bezstanowi
  -> deterministyczne filtry
  -> opcjonalny oceniaacz LLM
  -> powiadomienie lub akcja asystenta

Minimalny schemat:

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

To daje Ci czyste rozdzielenie:

kalendarz posiada czas
kolejka posiada buforowanie
pracownik posiada wykonanie
baza danych posiada stan
LLM posiada osąd semantyczny
asystent posiada interakcję z użytkownikiem

To rozdzielenie jest sercem niezawodnego agenta pollingowego.

Przykład: Agent Hermes przetwarzający zadania w Notion

Teraz zastosujmy architekturę do konkretnego przypadku.

Załóżmy, że baza danych Notion zawiera zadania. Hermes powinien uruchamiać się co 10 minut, wziąć jedno zadanie w stanie Todo, ustawić je na InProgress, wykonać je, a następnie oznaczyć jako Complete.

Najlepiej opisać to jako:

zewnętrzne narzędzie jako kolejka zadań
+
zaplanowany pracownik pollingowy
+
wykonanie oparte na rezerwacji lub najmie

Dla wersji produkcyjnej staje się:

polling oparty na kolejkach z Notionem jako skrzynką odbiorczą zadań skierowaną do człowieka

Właściwości zadań w Notion

Baza danych Notion powinna zawierać pola takie jak:

Nazwa
Status: Todo | InProgress | Complete | Failed
Priorytet
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Ważne pola to ClaimedAt, ClaimExpiresAt i RunId. Sprawiają one, że rezerwacja zadania jest widoczna i odzyskiwalna.

Stan wykonania Hermes

Hermes powinien również utrzymywać własny rekord wykonania:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

To chroni Cię, jeśli Notion zostanie edytowany ręcznie, jeśli wywołanie API zawali, lub jeśli potrzebujesz audytować, co Hermes faktycznie zrobił.

Przepływ wykonania

Co 10 minut:
  kalendarz Hermes tworzy uruchomienie

Pracownik Hermes:
  znajduje jedno zadanie Notion gdzie Status = Todo
  sortuje według Priorytetu i CreatedAt
  przejmuje zadanie ustawiając Status = InProgress
  zapisuje ClaimedBy, ClaimedAt, ClaimExpiresAt i RunId
  wykonuje zadanie
  zapisuje logi wykonania do backendu Hermes
  ustawia Status Notion = Complete przy sukcesie
  ustawia Status Notion = Failed przy porażce

Jeśli Hermes zawali po przejęciu zadania, najem może wygasnąć:

Status = InProgress
ClaimExpiresAt < teraz

Przyszłe uruchomienie może następnie odzyskać zadanie lub oznaczyć je jako nieudane.

Obsługa błędów

Przy sukcesie:

Status = Complete
CompletedAt = teraz
LastError = puste

Przy odzyskiwalnej awarii:

Status = Todo
RetryCount = RetryCount + 1
LastError = krótka wiadomość błędu

Przy nieodzyskiwalnej awarii:

Status = Failed
LastError = jasne wyjaśnienie

Dla bezpieczeństwa Hermes powinien również używać klucza idempotentności:

notion_page_id + task_version + action_type

To zapobiega dwukrotnemu wykonaniu tego samego zadania, jeśli ponowna próba nastąpi w niewłaściwym czasie.

Dlaczego to nie jest tylko polling

Część pollingowa to tylko mechanizm budzenia. Prawdziwa architektura to rezerwacja zadań i niezawodne wykonanie.

Naïwna implementacja mówi:

Co 10 minut, znajdź zadanie Todo i zrób to.

Niezwodna implementacja mówi:

Co 10 minut, przejmij dokładnie jedno kwalifikujące się zadanie, zapisz uruchomienie, wykonaj idempotentnie i przenieś zadanie do stanu końcowego.

To jest różnica między demo a agentem, któremu możesz ufać.

Częste błędy agentów pollingowych

Błąd 1: Brak protokołu rezerwacji

Jeśli dwóch pracowników może zobaczyć to samo zadanie, mogą je obaj wykonać.

Używaj:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Nawet jeśli obecnie uruchamiasz jednego pracownika, projektuj tak, jakby drugi pracownik mógł pojawić się później.

Błąd 2: Brak klucza deduplikacji

Każda zewnętrzna akcja powinna mieć klucz deduplikacji.

user_id + poll_id + source_object_id + action_type + condition_version

To zapobiega powielaniu powiadomień, powielaniu e-maili, powielaniu wykonania zadań i powielaniu wywołań narzędzi. Szersze zasady dotyczące zakresu, przechowywania i testowania tych kluczy stosują się tutaj również — zobacz Idempotentność w systemach dystrybuowanych, która naprawdę działa.

Błąd 3: Za wczesne wywoływanie LLM

Nie pytaj modelu o filtrowanie bazy danych.

Źle:

Wyślij wszystkie zadania do LLM i zapytaj, które jest Todo.

Lepiej:

Użyj filtra API Notion, aby pobrać zadania Todo.
Następnie użyj LLM tylko jeśli interpretacja zadania jest potrzebna.

Błąd 4: Traktowanie Notion jako jedynego backendu

Notion jest dobrym interfejsem dla człowieka. Nie jest kompletnym backendem wykonawczym.

Utrzymuj logi wykonania, ponowne próby, ślady i rekordy idempotentności w Hermesie.

Błąd 5: Nieskończony polling

Każdy polling powinien mieć warunek zatrzymania.

Przykłady:

zatrzymaj po sukcesie
zatrzymaj po dacie
zatrzymaj po maksymalnej liczbie ponownych prób
zatrzymaj gdy użytkownik to wyłączy
zatrzymaj po powtarzającej się awarii autoryzacji

Agent pollingowy bez warunku zatrzymania to cicha wyciek kosztów.

Błąd 6: Brak obserwowalności

Powinieneś być w stanie odpowiedzieć:

Co uruchomił agent?
Dlaczego to uruchomił?
Co przeczytał?
Co zmienił?
Dlaczego zawalił?
Czy powiadomił użytkownika?
Czy uruchomił to dwukrotnie?

Jeśli nie możesz odpowiedzieć na te pytania, system nie jest gotowy na ważną pracę.

Checklista obserwowalności

Śledź metryki takie jak:

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

Loguj pola takie jak:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Zbuduj widok administracyjny dla:

aktywne pollingi
zaczepione zadania InProgress
ostatnie awarie
zadania z wysoką liczbą ponownych prób
zadania z kolejki martwych listów
drogie oceny LLM
wyłączone integracje

Agenci pollingowi działają w tle, gdzie awarie są ciche i problemy mogą się kumulować, zanim ktoś to zauważy. Systemy tła potrzebują widoczności wbudowanej od początku, a nie dodanej jako afterthought, gdy coś pójdzie nie tak. Pełny stos obserwowalności dla systemów AI i LLM — metryki, ślady, strukturalne logi i SLO — znajdziesz w Obserwowalność dla systemów LLM: Metryki, ślady, logi i testy w produkcji.

Ostateczna rekomendacja

Wzorce pollingowe obsługują warstwę proaktywnego harmonogramowania pod wieloagentowym systemem. Gdy masz już wielu agentów, którzy potrzebują koordynacji ze sobą — nie tylko niezależnego pollinga — kolejną decyzją projektową jest to, jak się koordynują: hub-and-spoke, pipeline, fan-out lub swarm. Wzorce orkiestracji wieloagentowej omawia te topologie koordynacyjne z trybami awarii i ramami decyzyjnymi.

Dla poważnego asystenta AI zacznij od pracowników pollingowych opartych na kolejkach i trwałego magazynu stanu. Dodaj webhoki tam, gdzie dostawcy je obsługują. Używaj pollinga adaptacyjnego, gdy limity współczynników mają znaczenie. Używaj trwałego silnika przepływów pracy, gdy proces jest długotrwały i wieloetapowy. Używaj trwałego runtime agenta, gdy agent potrzebuje rozumowania z czasem.

Dla przykładu Hermes i Notion, odpowiednia architektura to:

Notion jako skrzynka odbiorcza zadań skierowana do człowieka
kalendarz Hermes co 10 minut
pracownik Hermes z logiką rezerwacji lub najmu
backend Hermes dla logów wykonania i idempotentności
aktualizacje statusu Notion dla widoczności

Interwał pollingowy nie jest trudną częścią. Trudną częścią jest upewnienie się, że agent przejmuje jedno zadanie, wykonuje je raz, zapisuje, co się stało, i pozostawia system w stanie, który ludzie mogą zrozumieć.

To jest to, co przekształca skrypt pollingowy w niezawodnego asystenta AI — nie interwał, nie model, ale dyscyplina wokół przejmowania pracy, jej rejestracji i pozostawiania systemu w stanie, który mogą zrozumieć zarówno ludzie, jak i przyszłe uruchomienia.