Agent polling w asystantach AI: 11 wzorców wdrożenia

Agentów sondujących (polling agents) należy uznać za jedną z najmniej glamour, ale zarazem najbardziej użytecznych części architektury asystentów AI.

Zwykły asystant czatowy czeka, aż użytkownik zada pytanie. Agent sondujący nieustannie obserwuje. Sprawdza źródło, zauważa zmiany, decyduje, czy mają one znaczenie, a następnie podejmuje działanie. To działanie 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 modelu „trzymaj oko na tym dla mnie”. Zamiast być reaktywny, staje się procesem w tle, który zauważa rzeczy w imieniu użytkownika i działa, gdy są spełnione określone warunki.

Kluczowa zasada projektowa jest prosta: nie obciążaj modelu językowego odpowiedzialnością za czas, stan, ponowne próby (retries) ani blokadę (locking). Do tego użyj zwykłej infrastruktury backendowej. Użyj modelu tam, gdzie jest wartościowy: do interpretacji chaotycznego kontekstu, wydawania ocen semantycznych i generowania użytecznej treści językowej.

Czym jest agent sondujący?

Agent sondujący to proces w tle, który wielokrotnie sprawdza źródło i inicjuje działanie asystenta, gdy zostanie spełniony określony warunek. W szerszym stosie Systemów AI – gdzie asystent łączy LLM, pamięć, narzędzia, routing i obserwowalność – warstwa sondowania sprawia, że asystant staje się proaktywny, a nie czysto reaktywny. Pełny obraz pięciowarstwowy 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.
• Obserwowanie listy zadań w Notion i wykonywanie kolejnego elementu „do zrobienia”.
• Monitorowanie zgłoszenia w GitHubie do momentu zmiany jego statusu.
• Sondowanie długotrwałego zadania AI do momentu gotowości wyniku.
• Sprawdzanie dostępności terminu rezerwacji, aż do momentu jego otwarcia.
• Obserwowanie portalu dostawcy do momentu pojawienia się dokumentu.
• Skanowanie nowych artykułów badawczych raz w tygodniu i podsumowywanie tych istotnych.

Praktyczny agent sondujący 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 powtarzania swoich działań.

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

kalendarz (scheduler)
  -> pracownik sondujący (polling worker)
  -> system źródłowy
  -> magazyn stanu (state store)
  -> deterministyczne filtry
  -> opcjonalna ewaluacja LLM
  -> działanie asystenta

Ta struktura jest nudna w najlepszym możliwym sensie. Nudne systemy są łatwiejsze do debugowania o 2:00 w nocy.

Stan wymagany przez każdego agenta sondującego

Agenty sondujące wymagają trwałości stanu (durable state). Historia rozmowy nie wystarczy. Asystent może pamiętać rozmowę, ale system potrzebuje niezawodnego rekordu operacyjnego.

Dobry rekord stanu sondowania zazwyczaj 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_tymiecz",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

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

Definicja sondy (Poll Definition)

Opisuje to, 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ź jedno zadanie Todo, przejmij je, wykonaj, oznacz jako Zakończone.

Harmonogram (Schedule)

Opisuje, kiedy agent powinien działać.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Dla agenta Hermes, który sprawdza Notion co 10 minut:

interval_seconds: 600
timezone: Australia/Melbourne

Kursor lub migawka (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 przejęcia (claim). Dla Gmaila, GitHuba lub API synchronizacji kursor jest zazwyczaj krytyczny.

Przejęcie (Claim) lub dzierżawa (Lease)

Zapobiega to sytuacji, w której dwa pracownicy (workers) podejmą to samo zadanie.

claimed_by
claimed_at
claim_expires_at
run_id

Na przykład zadanie w Notion można zmienić 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 podejmie” a „system ma protokół przejęcia”.

Rekord wykonania (Execution Record)

Rejestruje to, 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 znajdować się w backendzie asystenta, a nie tylko w Notionie czy innym zewnętrznym narzędziu. Notion jest dobry dla widoczności dla człowieka. Nie jest idealny jako jedyny dziennik wykonania.

Rekord eliminacji duplikatów (Dedupe Record)

Zapobiega powielonym powiadomieniom lub powtarzającym się działaniom.

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 to samo działanie zostanie ponownie próbne, system może je zablokować.

Metoda 1: Zaplanowany pracownik sondujący

To najprostszy niezawodny wzorzec.

Kalendarz (scheduler) budzi się co stały interwał i wywołuje pracownika (worker). Pracownik czyta ze źródła, aktualizuje stan i inicjuje działanie asystenta, jeśli jest to wymagane.

kalendarz
  -> pracownik
  -> API źródła
  -> baza danych
  -> działanie 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 bieg pracownika. Pracownik ładuje swoją konfigurację, zapytuje docelowe źródło, porównuje wynik ze przechowywanym stanem i działa, jeśli jest to potrzebne.

Dla prostego asystenta często wystarczy to. Pojedynczy kalendarz i lekki proces pracownika mogą obsługiwać dziesiątki dziennych sprawdzeń bez wymagania kolejek, dzierżaw lub koordynacji rozproszonej.

Model stanu

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

Baza danych aplikacji przechowuje ważny stan:

definicja sondy
harmonogram
kursor lub migawka
ostatni czas 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 sondującego Hermes

Pracownik:
  załaduj aktywną konfigurację sondy
  zapytaj źródło
  porównaj z poprzednim stanem
  uruchom deterministyczne sprawdzenia
  wywołaj LLM tylko jeśli potrzebne
  zaktualizuj stan
  wyemituj zdarzenie asystenta

Najlepsze zastosowanie

Użyj zaplanowanych pracowników sondujących do:

• Dziennych podsumowań.
• Godzinnych sprawdzeń.
• Małych wewnętrznych automatyzacji.
• Prosty zadań typu „obserwuj to”.
• Zadań asystenta o niskim i średnim wolumenie.

Wady

Sondowanie zaplanowane jest łatwe do zrozumienia, ale może stać się kruche w skali. Jeśli wiele sond działa jednocześnie, możesz przeciążyć swoich pracowników lub uderzyć w limity stawiane przez dostawcę. Ponowne próby mogą również stać się chaotyczne, jeśli kalendarz bezpośrednio uruchamia pracę.

Metoda 2: Pracownicy sondujący oparte na kolejkach

Sondowanie oparte na kolejkach jest zazwyczaj najlepszym domyślnym wyborem dla produkcyjnych asystentów AI.

Kalendarz nie wykonuje sondy bezpośrednio. Umieszcza zadanie w kolejce. Procesy pracujące pobierają zadania z kolejki.

kalendarz
  -> kolejka
  -> pulę pracowników (worker pool)
  -> API źródła
  -> magazyn stanu
  -> działanie asystenta

Jak to działa

Kalendarz skanuje sondy do wykonania i umieszcza zadania w kolejce. Pracownicy pobierają zadania, gdy mają pojemność.

Daje to Ci zwrotne ciśnienie (backpressure). 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 sondy:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Wiadomość w kolejce 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, gdy się uruchamia.

Przykładowy przepływ

Co minutę:
  kalendarz znajduje sondy gdzie next_run_at <= teraz
  kalendarz umieszcza zadania w kolejce

Pracownicy:
  pobierają zadania z kolejki
  blokują lub dzierżawią sondę
  zapytują źródło
  aktualizują stan
  emitują działanie asystenta jeśli potrzebne
  ustawiają next_run_at

Najlepsze zastosowanie

Użyj sondowania opartego na kolejkach do:

• Wieloużytkowych asystentów AI.
• Wielu jednoczesnych sond.
• Integracji z limitami stawianymi przez dostawców (rate limits).
• Ponownych prób pracy w tle.
• Zadań, które mogą trwać różną ilość czasu.
• Produktów SaaS, gdzie niezawodność ma znaczenie.

Wady

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

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

To jest 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 w Notion

Jak to działa

Co 10 minut Hermes zapytuje bazę danych Notion o jedno zadanie w stanie Todo. Wybiera kolejne zadanie, zazwyczaj 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ń skierowany 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
error details
idempotency_key

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

Przykładowy przepływ

Co 10 minut:
  Hermes się budzi

Hermes:
  zapytaj Notion o jedno zadanie gdzie Status = Todo
  posortuj według Priorytetu, CreatedAt
  zaktualizuj wybrane zadanie do InProgress
  ustaw ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  wykonaj zadanie
  zapisz dziennik wykonania
  ustaw zadanie na Complete lub Failed

Najlepsze zastosowanie

Użyj 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 przejęcia mogą być ograniczone. Spójność zapytań może opóźniać się. Mogą obowiązywać limity stawiane przez dostawcę (rate limits). Jeśli agent może działać w wielu instancjach, potrzebujesz ostrożnej strategii przejęcia lub dzierżawy.

Praktyczną rekomendacją jest użycie Notion jako skrzynki odbiorczej zadań skierowanej do człowieka, podczas gdy wszystkie dzienniki wykonania, rekordy ponownych prób, ślady i klucze idempotencji powinny znajdować się w Hermesie. Notion daje użytkownikom widoczność; Hermes utrzymuje system niezawodny. Dla mechanik dystrybutora i współbieżności stojących za tym wzorcem w Hermesie, zobacz Kanban w Agencie Hermes dla przepływów pracy LLM hostowanych samodzielnie.

Metoda 4: Długotrwała pętla 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 kalendarzowanie i wykonanie w jednej usłudze, co czyni go najprostszym możliwym punktem wyjścia dla pracy agenta w tle.

Jak to działa

Proces pracownika działa nieprzerwanie. Co kilka sekund lub minut sprawdza bazę danych pod kątem wymaganych sond i je wykonuje. Jest łatwy do zbudowania, łatwy do zrozumienia i szybki do iteracji podczas rozwoju.

Model stanu

Baza danych nadal przechowuje trwały stan:

konfiguracja sondy
next_run_at
cursor
ostatni wynik
licznik awarii
status

Pamięć procesu powinna zawierać tylko tymczasowy stan:

aktualna 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 do trwałej pamięci, znika, a następne uruchomienie nie będzie wiedział, gdzie skończył.

Najlepsze zastosowanie

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

• Prototypów.
• Rozwoju lokalnego.
• Narzędzi wewnętrznych.
• Systemów jednodomenowych (single-tenant).
• Agentów o niskim wolumenie.

Wady

Ten wzorzec staje się ryzykowny z wieloma replikami. Bez dzierżaw dwa pracownicy mogą uruchomić tę samą sondę. 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 wyjścia, ale nie jest rozproszonym kalendarzem i nie należy jej traktować jako takiej. W momencie, gdy potrzebujesz wielu replik lub silniejszych gwarancji niezawodności, będziesz musiał przejść do jednego z bardziej ustrukturyzowanych wzorców powyżej.

Metoda 5: Webhook-first z fallbackiem do sondowania

Jeśli źródło obsługuje webhooki, użyj ich. Sondowanie powinno często być backupem, a nie głównym mechanizmem.

system zewnętrzny
  -> punkt końcowy webhooka
  -> magazyn zdarzeń
  -> działanie asystenta

sonda rekonsyliacyjna
  -> 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 punktu końcowego webhooka, gdy coś się zmienia. Twój system przechowuje zdarzenie i przetwarza je asynchronicznie.

Powolniejsza sonda rekonsyliacyjna działa co kilka godzin lub raz dziennie. Sprawdza, czy któreś zdarzenia zostały przegapięte.

Model stanu

Magazyn zdarzeń rejestruje nadchodzące webhooki:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Sonda rekonsyliacyjna 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żyj architektury webhook-first do:

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

Wady

Webhooki wymagają publicznego punktu końcowego, walidacji podpisu, ochrony przed odtworzeniem i eliminacji duplikatów zdarzeń. Niektórzy dostawcy również wysyłają niekompletne zdarzenia, więc możesz nadal potrzebować pobrania pełnego obiektu.

Nawet tak, jeśli istnieją dobre webhooki, sondowanie co minutę jest zazwyczaj marnotrawstwem.

Metoda 6: Sondowanie długotrwałych zadań po stronie dostawcy

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

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

aplikacja
  -> uruchom długotrwałe zadanie AI
  -> przechowuj ID zadania dostawcy
  -> sonduj 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 zawiedzie, 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łasnej trwałej pamięci tak szybko, jak zadanie się zakończy. Przechowywanie wyników po stronie dostawcy ma krótkie okna retencji i nie jest substytutem odpowiedniego archiwum w Twoim własnym systemie.

Najlepsze zastosowanie

Użyj sondowania długotrwałych zadań po stronie dostawcy do:

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

Wady

Ten wzorzec rozwiązuje jeden problem: czekanie na długie zadanie dostawcy. Nie zastępuje 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ęstszy wyborem dla backendów asystentów opartych na Go i Python; pełny przewodnik implementacyjny znajdziesz w Implementowanie aplikacji przepływów pracy z Temporal w Go.

Zamiast ręcznie łączyć każde oczekiwanie i ponowną próbę, 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 uruchamia się raz i następnie kontroluje własne oczekiwanie. Może spać przez minuty, dni lub tygodnie. Jeśli proces pracownika zawali, silnik przepływów pracy może wznowić działanie od zarejestrowanego stanu.

Model stanu

Silnik przepływów pracy przechowuje:

workflow_id
historia wykonania
stan timerów
prób aktywności
polityka ponownych prób
aktualny stan przepływu pracy

Baza danych aplikacji przechowuje:

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

Silnik przepływów pracy jest właścicielem stanu procesu — historii wykonania, timerów, ponownych prób i prób aktywności. Twoja baza danych jest właścicielem stanu biznesowego — konfiguracji użytkownika, rekordów autoryzacyjnych, powiadomień i dzienników audytowych. Trzymanie tych warstw osobno zapobiega temu, aby każda warstwa stała się zdezorientowanym hybrydą obu.

Najlepsze zastosowanie

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

• Wieloetapowych procesów biznesowych.
• Długotrwałych automatyzacji.
• Przepływów zatwierdzeń ludzkich.
• Niezawodnych ponownych prób.
• Audytowalnej pracy w tle.
• Procesów, które muszą wznowić 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ła runtime agenta

Niektóre frameworki agentów mogą utrzymywać stan agenta, tworzyć punkty kontrolne wykonania i wznawiać go później.

To jest 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 szerszej architektury backendowej.

Model stanu

Przechowywanie punktów kontrolnych agenta zawiera:

aktualny węzeł
wiadomości
wyjścia narzędzi
pośredni stan rozumowania
oczekujące działanie

Długoterminowa pamięć zawiera:

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

Operacyjny stan nadal należy gdzie indziej:

harmonogram sondy
kursor
status
licznik ponownych prób
rekordy eliminacji duplikatów

Pożyteczna zasada: pamięć nie jest kursorzem, a punkt kontrolny nie jest kolejką. Pamięć agenta przechowuje to, co model zna; operacyjny stan śledzi, gdzie jest proces i co zrobił. Mieszanie 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 pamięci roboczej, trwałego stanu i warstw odzyskiwania jest omówiona w Systemy pamięci w asystentach AI.

Najlepsze zastosowanie

Użyj trwałej runtime agenta do:

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

Wady

Utrwalanie agenta nie jest tym samym co niezawodność operacyjna. Nadal potrzebujesz kalendarzowania, blokowania, ponownych prób, limitów stawianych przez dostawcę i dzienników audytowych.

Metoda 9: Synchronizacja bazy danych plus ewaluacja zmian

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

sondowanie synchronizacyjne
  -> API zewnętrzne
  -> lokalna baza danych
  -> ewaluator zmian
  -> działanie asystenta

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

Jak to działa

Pracownik synchronizacyjny okresowo pobiera zewnętrzne zmiany i zapisuje znormalizowane rekordy do Twojej 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 ewaluacji asystenta przechowuje:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Najlepsze zastosowanie

Użyj tego wzorca do:

• Synchronizacji CRM.
• Systemów biletowych.
• 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żyj tego wzorca, gdy lokalne dane mają wartość poza pojedynczym działaniem asystenta.

Metoda 10: Sondowanie adaptacyjne

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

aktywny obiekt: sonduj co 1 minutę
oczekujący obiekt: sonduj co 1 godzinę
przestarzały obiekt: sonduj raz dziennie
zakończony obiekt: przestań sondować

Jak to działa

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

Jeśli obiekt zmienił się niedawno, sonduj szybciej. Jeśli nic się nie zmieniło przez długi czas, zwolnij. Jeśli zadanie jest zakończone, przestań.

Model stanu

Stan sondy zawiera:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Migawka źródła zawiera:

status
updated_at
activity_level
expected_next_change

Najlepsze zastosowanie

Użyj sondowania adaptacyjnego do:

• Statusu wdrożeń.
• Śledzenia dostaw.
• Dostępności terminów kalendarzowych.
• Monitorowania cen.
• Zadań budowania.
• Długotrwałych zadań dostawcy.
• Dowolnego źródła z burzliwymi aktualizacjami.

Wady

Sondowanie adaptacyjne może być trudniejsze do zrozumienia. Jeśli zadanie musi uruchomić się w ścisłym czasie, trzymaj się go. Nie rób zadań zgodności sprytnymi.

Metoda 11: Sondowanie semantyczne z ewaluatorem LLM

Sondowanie semantyczne jest używane, gdy warunek jest rozmyty.

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?
pasuje do filtrów źródła?
nie został już przetworzony?
nie jest oczywiście nieistotny?

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

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

Model stanu

Definicja sondy przechowuje:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Dziennik ewaluacji przechowuje:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Stan sondy przechowuje:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Najlepsze zastosowanie

Użyj sondowania semantycznego do:

• Wykrywania ważnych e-maili.
• Monitorowania sentymentu klientów.
• Alertów badawczych.
• Wykrywania szans sprzedażowych.
• Tryjazu bezpieczeństwa.
• Briefingów wykonawczych.

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żyj deterministycznych filtrów najpierw. Pytaj model tylko wtedy, gdy naprawdę potrzebna jest ocena.

Tabela decyzyjna: Wybór metody agenta sondującego

Rekomendowana architektura domyślna

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

tabela sond
  -> kalendarz
  -> kolejka
  -> pracownicy bezstanowi
  -> deterministyczne filtry
  -> opcjonalny ewaluator LLM
  -> powiadomienie lub działanie 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 oddzielenie:

kalendarz posiada czas
kolejka posiada buforowanie
pracownik posiada wykonanie
baza danych posiada stan
LLM posiada ocenę semantyczną
asystent posiada interakcję z użytkownikiem

To oddzielenie jest sercem niezawodnego agenta sondującego.

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

Teraz zastosujmy tę 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.

To jest najlepiej opisane jako:

zewnętrzne narzędzie jako kolejka zadań
+
zaplanowany pracownik sondujący
+
wykonanie oparte na przejęciu lub dzierżawie

Dla wersji produkcyjnej, staje się:

sondowanie oparte 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żnymi polami są ClaimedAt, ClaimExpiresAt i RunId. Sprawiają one, że przejęcie zadania jest widoczne i odzyskiwalne.

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 zawiedzie 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 dzienniki wykonania do backendu Hermes
  ustawia Status Notion = Complete w przypadku sukcesu
  ustawia Status Notion = Failed w przypadku porażki

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

Status = InProgress
ClaimExpiresAt < teraz

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

Obsługa awarii

W przypadku sukcesu:

Status = Complete
CompletedAt = teraz
LastError = puste

W przypadku awarii odzyskiwalnej:

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

W przypadku awarii nieodzyskiwalnej:

Status = Failed
LastError = jasne wyjaśnienie

Dla bezpieczeństwa, Hermes powinien również używać klucza idempotencji:

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 sondowanie

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

Naiwna implementacja mówi:

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

Niezawodna implementacja mówi:

Co 10 minut, przejmij dokładnie jedno kwalifikujące się zadanie, zapisz uruchomienie, wykonaj idempotentnie i przesunij 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 sondujących

Błąd 1: Brak protokołu przejęcia

Jeśli dwa pracownicy mogą zobaczyć to samo zadanie, mogą je oba wykonać.

Użyj:

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 eliminacji duplikatów

Każde zewnętrzne działanie powinno mieć klucz eliminacji duplikatów.

user_id + poll_id + source_object_id + action_type + condition_version

To zapobiega powielonym powiadomieniom, powielonym e-mailom, powielonemu wykonaniu zadań i powielonym wywołaniom narzędzi. Szersze zasady dotyczące zakresu, przechowywania i testowania tych kluczy stosują się tutaj również — zobacz Idempotencja w systemach rozproszonych, która naprawdę działa.

Błąd 3: Zbyt wcześnie wywoływanie LLM

Nie pytaj modelu o filtrowanie bazy danych.

Złe:

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

Lepsze:

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

Utrzymuj dzienniki wykonania, ponowne próby, ślady i rekordy idempotencji w Hermesie.

Błąd 5: Nieskończone sondowanie

Każda sonda powinna 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 sondujący bez warunku zatrzymania to cicha wyciek kosztów.

Błąd 6: Brak obserwowalności

Powinieneś być w stanie odpowiedzieć:

Co uruchomił agent?
Dlaczego się uruchomił?
Co przeczytał?
Co zmienił?
Dlaczego zawiedzie?
Czy powiadomił użytkownika?
Czy uruchomił się dwukrotnie?

Jeśli nie możesz odpowiedzieć na te pytania, system nie jest gotowy do ważnej pracy.

Lista kontrolna 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

Pola dziennika 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 sondy
zablokowane zadania InProgress
ostatnie awarie
zadania z wysoką liczbą ponownych prób
zadania w kolejce martwych listów
kosztowne ewaluacje LLM
wyłączone integracje

Agenty sondujące działają w tle, gdzie awarie są ciche i problemy mogą się namnażać, zanim ktokolwiek je zauważy. Systemy w tle potrzebują widoczności wbudowanej od początku, a nie dodanej jako dodatek, gdy coś pójdzie nie tak. Pełny stos obserwowalności dla systemów AI i LLM — metryki, ślady, ustrukturyzowane dzienniki i SLO — znajdziesz w Obserwowalność dla systemów LLM: metryki, ślady, dzienniki i testowanie w produkcji.

Ostateczna rekomendacja

Dla poważnego asystenta AI, zacznij od pracowników sondujących opartych na kolejkach i trwałym magazynie stanu. Dodaj webhooki, gdzie dostawcy ich obsługują. Użyj sondowania adaptacyjnego, gdy limity stawiane przez dostawcę mają znaczenie. Użyj trwałego silnika przepływów pracy, gdy proces jest długotrwały i wieloetapowy. Użyj trwałej runtime agenta, gdy agent potrzebuje rozumowania w czasie.

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ą przejęcia lub dzierżawy
Backend Hermes dla dzienników wykonania i idempotencji
Aktualizacje statusu Notion dla widoczności

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

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