Агенты опроса в ИИ-ассистентах: 11 шаблонов реализации

Агенты с опросом (polling agents) — одна из наименее гламурных частей архитектуры AI-ассистентов, но одновременно и одна из самых полезных.

Обычный чат-ассистент ждет, пока пользователь задаст вопрос. Агент с опросом постоянно наблюдает. Он проверяет источник, замечает изменения, решает, имеют ли они значение, и затем предпринимает действие. Это действие может быть уведомлением, сводкой, черновиком, вызовом инструмента или полным рабочим процессом.

Так ассистент переходит от режима «ответь на мой вопрос» к режиму «следи за этим за меня». Вместо реактивного поведения он становится фоновым процессом, который замечает события от имени пользователя и действует при выполнении определенных условий.

Ключевой момент в дизайне прост: не возлагайте на языковую модель ответственность за время, состояние, повторные попытки или блокировку. Для этого используйте стандартную бэкенд-инфраструктуру. Используйте модель там, где она действительно ценна: для интерпретации запутанного контекста, принятия семантических решений и генерации полезного текста.

Что такое агент с опросом?

Агент с опросом — это фоновый процесс, который регулярно проверяет источник и запускает действие ассистента при выполнении определенного условия. В более широкой архитектуре AI-систем — где ассистент объединяет LLM, память, инструменты, маршрутизацию и наблюдаемость — слой опроса делает ассистента проактивным, а не просто реактивным. Для понимания полной картины из пяти слоев см. Архитектура AI-ассистента: LLM, Память, Инструменты, Маршрутизация, Наблюдаемость.

Примеры:

• Проверять входящую почту каждое утро и сводить важные сообщения.
• Следить за списком задач в Notion и выполнять следующее действие.
• Мониторить проблему в GitHub до изменения ее статуса.
• Опрашивать долгоиграющую AI-задачу до готовности результата.
• Проверять доступность слота для бронирования, пока он не освободится.
• Следить за порталом поставщика до появления документа.
• Сканировать новые научные статьи раз в неделю и сводить релевантные.

Практический агент с опросом имеет пять обязанностей:

1. Пробуждаться в правильное время.
2. Читать данные из источника.
3. Запоминать уже увиденное.
4. Решать, имеет ли новое состояние значение.
5. Действовать один раз, безопасно, без повторений.

Типичный производственный поток выглядит так:

планировщик
  -> рабочий процесс опроса
  -> источник данных
  -> хранилище состояния
  -> детерминированные фильтры
  -> опциональная оценка LLM
  -> действие ассистента

Эта структура скучна в самом лучшем смысле этого слова. Скучные системы легче отлаживать в 2 часа ночи.

Состояние, необходимое каждому агенту с опросом

Агентам с опросом требуется устойчивое состояние. Истории диалога недостаточно. Ассистент может помнить разговор, но системе нужен надежный операционный журнал.

Запись хорошего состояния опроса обычно содержит:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "взять одну задачу в состоянии Todo и выполнить ее",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "курсор_или_временная_метка",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

Точная схема зависит от источника, но большинству систем нужны эти концепции.

Определение опроса

Это описывает, что отслеживает агент и почему.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Например:

source_type: notion
source_ref: База данных задач
condition_text: Найти одну задачу Todo, захватить ее, выполнить, отметить как Completed.

Расписание

Это описывает, когда должен запускаться агент.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Для агента Hermes, который проверяет Notion каждые 10 минут:

interval_seconds: 600
timezone: Australia/Melbourne

Курсор или снимок

Это помогает агенту избежать повторной обработки одних и тех же данных.

В зависимости от источника, это может быть:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Для очереди задач в Notion курсор может быть менее важен, чем статус задачи и поля захвата. Для Gmail, GitHub или синхронизационного API курсор обычно критичен.

Захват или аренда (Claim or Lease)

Это предотвращает выполнение одной и той же работы двумя рабочими процессами.

claimed_by
claimed_at
claim_expires_at
run_id

Например, задача в Notion может быть изменена с:

Status: Todo

на:

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

Это разница между «я надеюсь, что только один работник возьмет это» и «у системы есть протокол захвата».

Журнал выполнения

Это фиксирует то, что произошло во время запуска.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Журнал выполнения должен храниться в бэкенде ассистента, а не только в Notion или другом внешнем инструменте. Notion хорош для видимости человеком. Он не идеален в качестве единственного журнала выполнения.

Журнал дедупликации

Это предотвращает дублирование уведомлений или повторных действий.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Например:

user_456:poll_123:notion_page_999:execute:v1

Если то же действие будет attempted снова, система может его подавить.

Метод 1: Планируемый рабочий процесс опроса

Это самый простой надежный паттерн.

Планировщик просыпается через фиксированные интервалы и вызывает рабочий процесс. Рабочий процесс считывает источник, обновляет состояние и запускает действие ассистента при необходимости.

планировщик
  -> рабочий процесс
  -> источник API
  -> база данных
  -> действие ассистента

Как это работает

Планировщик отвечает за время. Это может быть cron, облачный планировщик, CronJob Kubernetes или небольшой внутренний планировщик.

Каждый интервал он запускает рабочий процесс. Рабочий процесс загружает конфигурацию, запрашивает целевой источник, сравнивает результат с сохраненным состоянием и действует при необходимости.

Для простого ассистента этого часто достаточно. Один планировщик и легкий рабочий процесс могут обрабатывать десятки ежедневных проверок без необходимости очередей, аренд или распределенной координации.

Модель состояния

Планировщик хранит очень мало. Обычно он знает только, когда запускать задачу.

База данных приложения хранит важное состояние:

определение опроса
расписание
курсор или снимок
время последнего запуска
количество сбоев
статус

Рабочий процесс должен быть безсостоятельным. Он может удерживать временные данные во время выполнения, но устойчивая истина должна быть в базе данных.

Пример потока

Каждые 10 минут:
  запустить рабочий процесс опроса Hermes

Рабочий процесс:
  загрузить активную конфигурацию опроса
  запросить источник
  сравнить с предыдущим состоянием
  выполнить детерминированные проверки
  вызвать LLM только если нужно
  обновить состояние
  выпустить событие ассистента

Лучшее применение

Используйте планируемые рабочие процессы опроса для:

• Ежедневных сводок.
• Ежечасовых проверок.
• Небольших внутренних автоматизаций.
• Простых задач «следить за этим».
• Задач ассистента с низким и средним объемом.

Слабые стороны

Планируемый опрос легко понять, но он может стать хрупким при масштабировании. Если много опросов запускаются одновременно, вы можете перегрузить рабочих процессов или достичь лимитов скорости поставщика. Повторные попытки также могут стать запутанными, если планировщик напрямую запускает работу.

Метод 2: Рабочие процессы опроса на основе очередей

Опрос на основе очередей обычно является лучшим вариантом по умолчанию для производственных AI-ассистентов.

Планировщик не выполняет опрос напрямую. Он помещает задачу в очередь. Рабочие процессы потребляют задачи из очереди.

планировщик
  -> очередь
  -> пул рабочих процессов
  -> источник API
  -> хранилище состояния
  -> действие ассистента

Как это работает

Планировщик сканирует просроченные опросы и ставит задачи в очередь. Рабочие процессы берут задачи, когда у них есть мощность.

Это дает вам обратное давление. Если система занята, задачи ждут в очереди, вместо того чтобы перегружать источник API или провайдера LLM.

Модель состояния

База данных хранит состояние опроса:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Сообщение в очереди должно оставаться небольшим:

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

Рабочий процесс загружает полное состояние из базы данных при запуске.

Пример потока

Каждую минуту:
  планировщик находит опросы, где next_run_at <= now
  планировщик ставит задачи в очередь

Рабочие процессы:
  берут задачи из очереди
  блокируют или арендуют опрос
  запрашивают источник
  обновляют состояние
  выпускают действие ассистента при необходимости
  устанавливают next_run_at

Лучшее применение

Используйте опрос на основе очередей для:

• AI-ассистентов с множеством пользователей.
• Множества одновременных опросов.
• Интеграций с лимитами скорости.
• Повторяемой фоновой работы.
• Задач, которые могут занимать разное количество времени.
• SaaS-продуктов, где важна надежность.

Слабые стороны

Очереди добавляют инфраструктуру. Вам нужна обработка мертвых писем, идемпотентность, тайм-ауты видимости и политики повторных попыток. Это стоит того для производственных систем, но, вероятно, избыточно для небольшого прототипа.

Метод 3: Внешний инструмент как очередь задач

Это паттерн в примере Notion плюс Hermes.

Внешний инструмент — это не просто источник данных. Он становится ориентированным на человека интерфейсом очереди задач. Агент периодически проверяет инструмент, захватывает одну задачу, выполняет ее и обновляет статус задачи.

планировщик
  -> рабочий процесс Hermes
  -> база данных Notion
  -> захватить одну задачу
  -> выполнить задачу
  -> обновить статус Notion

Как это работает

Каждые 10 минут Hermes запрашивает базу данных Notion на наличие одной задачи в состоянии Todo. Он выбирает следующую задачу, обычно по приоритету и времени создания. Затем он захватывает задачу, установив ее в InProgress.

После этого Hermes выполняет задачу. Если выполнение успешно, он отмечает задачу как Complete. Если выполнение не удалось, он отмечает задачу как Failed или возвращает ее в Todo с счетчиком повторных попыток.

Модель состояния

Notion хранит состояние задачи, ориентированное на человека:

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

Бэкенд Hermes хранит операционное состояние выполнения:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Это разделение важно. Notion отлично подходит для видимости и ручного редактирования. Бэкенд Hermes лучше подходит для журналов, повторных попыток, дедупликации и истории аудита.

Пример потока

Каждые 10 минут:
  Hermes просыпается

Hermes:
  запрашивает Notion на наличие одной задачи, где Status = Todo
  сортирует по Priority, CreatedAt
  обновляет выбранную задачу до InProgress
  устанавливает ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  выполняет задачу
  пишет журнал выполнения
  устанавливает статус задачи в Complete или Failed

Лучшее применение

Используйте этот паттерн, когда:

• Люди уже управляют работой в Notion, Jira, Linear, Trello или другом инструменте.
• Вы хотите, чтобы ассистент обрабатывал видимые задачи.
• Доска задач является пользовательским интерфейсом.
• Вам нужна простая модель автоматизации с участием человека.

Слабые стороны

Внешние инструменты редко являются идеальными очередями. Атомарные захваты могут быть ограничены. Согласованность запросов может отставать. Могут применяться лимиты скорости. Если агент может запускаться в нескольких экземплярах, вам нужна тщательная стратегия захвата или аренды.

Практическая рекомендация — использовать Notion как ориентированный на человека почтовый ящик задач, сохраняя все журналы выполнения, записи повторных попыток, трассировки и ключи идемпотентности в Hermes. Notion дает пользователям видимость; Hermes сохраняет надежность системы. Для диспетчера и механики конкурентности, которые лежат в основе этого паттерна в Hermes, см. Kanban в агенте Hermes для автономных LLM-пайплайнов.

Метод 4: Длительный цикл рабочего процесса

Длительный цикл — самое простое выполнение.

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

Этот паттерн объединяет планирование и выполнение в одном сервисе, что делает его самым простым началом для фоновой работы агента.

Как это работает

Процесс рабочего запускается непрерывно. Каждые несколько секунд или минут он проверяет базу данных на наличие просроченных опросов и выполняет их. Это легко построить, легко рассуждать об этом и быстро итерировать во время разработки.

Модель состояния

База данных по-прежнему хранит устойчивое состояние:

конфигурация опроса
next_run_at
курсор
последний результат
количество сбоев
статус

Память процесса должна содержать только временное состояние:

текущая партия
кратковременный кэш
выполнение в полете

Никогда не храните важный прогресс только в памяти. Если процесс падает, любое состояние, которое не было записано в устойчивое хранилище, исчезает, и следующий запуск не будет знать, на чем остановиться.

Лучшее применение

Используйте длительные циклы для:

• Прототипов.
• Локальной разработки.
• Внутренних инструментов.
• Систем с одним арендатором.
• Агентов с низким объемом.

Слабые стороны

Этот паттерн становится рискованным с несколькими репликами. Без аренд два рабочих процесса могут выполнить один и тот же опрос. Он также lacks операционных функций реальной очереди или движка рабочих процессов.

Длительный цикл — не ошибка как начальная точка, но это не распределенный планировщик, и к нему не следует относиться как к таковому. Как только вам понадобятся несколько реплик или более сильные гарантии надежности, вам придется перейти к одним из более структурированных паттернов выше.

Метод 5: Вебхуки первыми с опросом как резервным вариантом

Если источник поддерживает вебхуки, используйте их. Опрос часто должен быть резервным механизмом, а не основным. То же разделение появляется в дизайне протокола агента: push-уведомления A2A будят обработчик клиента, который затем опрашивает GetTask для полного состояния, как описано в A2A потоки и асинхронные задачи для длительных рабочих процессов агента.

внешняя система
  -> конечная точка вебхука
  -> хранилище событий
  -> действие ассистента

опрос согласования
  -> источник API
  -> сравнить с хранилищем событий
  -> исправить пропущенные события

Как это работает

Внешняя система отправляет события в вашу конечную точку вебхука, когда что-то меняется. Ваша система сохраняет событие и обрабатывает его асинхронно.

Более медленный опрос согласования запускается каждые несколько часов или раз в день. Он проверяет, не были ли пропущены какие-либо события.

Модель состояния

Хранилище событий фиксирует входящие вебхуки:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Опрос согласования хранит:

last_reconciliation_at
last_seen_cursor
last_seen_version

Таблица объектов источника хранит последнее известное состояние:

external_id
current_status
external_updated_at
last_processed_event_id

Лучшее применение

Используйте архитектуру вебхуков первыми для:

• Событий GitHub.
• Событий Stripe.
• Событий Slack.
• Обновлений CRM.
• Уведомлений о развертывании.
• Систем тикетирования.

Слабые стороны

Вебхуки требуют публичной конечной точки, проверки подписи, защиты от воспроизведения и дедупликации событий. Некоторые поставщики также отправляют неполные события, поэтому вам может все еще понадобиться получить полный объект.

Тем не менее, если существуют хорошие вебхуки, опрос каждую минуту обычно является расточительным.

Метод 6: Опрос фоновых задач на стороне поставщика

Иногда то, что опрашивается, — это сама AI-задача.

Приложение запускает длительную задачу поставщика, сохраняет ID задачи и проверяет позже, завершена ли она.

приложение
  -> запустить фоновую AI-задаку
  -> сохранить ID задачи поставщика
  -> опросить статус
  -> получить результат
  -> уведомить пользователя

Как это работает

Ассистент запускает задачу у поставщика. Поставщик возвращает ID. Ваш бэкенд сохраняет этот ID и проверяет его статус, пока задача не завершится успешно, не провалится, не истечет срок или не выйдет тайм-аут.

Модель состояния

Ваш бэкенд хранит:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Поставщик хранит временное состояние задачи и вывод.

Если вывод имеет значение, скопируйте его в собственное устойчивое хранилище сразу после завершения задачи. Хранилище результатов на стороне поставщика имеет короткие окна удержания и не является заменой правильного архива в вашей собственной системе.

Лучшее применение

Используйте опрос фоновых задач на стороне поставщика для:

• Длительных исследовательских AI-задач.
• Обработки больших документов.
• Анализа кодовой базы.
• Генерации отчетов.
• Задач извлечения данных.
• Задач, превышающих нормальные тайм-ауты HTTP-запросов.

Слабые стороны

Этот паттерн решает одну проблему: ожидание длительной задачи поставщика. Он не заменяет ваш движок рабочих процессов, планировщик, очередь или хранилище бизнес-состояния.

Метод 7: Устойчивый движок рабочих процессов

Устойчивый движок рабочих процессов управляет длительным выполнением, таймерами, повторными попытками и восстановлением. Temporal — самый распространенный выбор для бэкендов ассистентов на Go и Python; для полного руководства по реализации см. Реализация приложений рабочих процессов с Temporal на Go.

Вместо ручной настройки каждого ожидания и повторной попытки, вы моделируете процесс как рабочий процесс.

движок рабочих процессов
  -> активность: проверить источник
  -> таймер: ждать
  -> активность: оценить результат
  -> активность: уведомить пользователя

Как это работает

Рабочий процесс запускается один раз и затем контролирует собственное ожидание. Он может спать минуты, дни или недели. Если процесс рабочего падает, движок рабочих процессов может возобновить работу из записанного состояния.

Модель состояния

Движок рабочих процессов хранит:

workflow_id
история выполнения
состояние таймера
попытки активности
политика повторных попыток
текущее состояние рабочего процесса

Ваша база данных приложения хранит:

определение опроса, ориентированное на пользователя
ссылки авторизации
бизнес-записи
записи уведомлений

Движок рабочих процессов владеет процессным состоянием — историей выполнения, таймерами, повторными попытками и попытками активности. Ваша база данных владеет бизнес-состоянием — конфигурациями пользователя, записями авторизации, уведомлениями и журналами аудита. Сохранение этого разделения предотвращает превращение каждого слоя в запутанный гибрид обоих.

Лучшее применение

Используйте устойчивые рабочие процессы для:

• Многошаговых бизнес-процессов.
• Длительных автоматизаций.
• Потоков одобрения человеком.
• Надежных повторных попыток.
• Фоновой работы, подлежащей аудиту.
• Процессов, которые должны возобновляться после сбоя.

Слабые стороны

Движки рабочих процессов добавляют концепции и инфраструктуру. Они excellent, когда процесс важен, но тяжелы для простых часовых проверок.

Метод 8: Постоянный runtime агента

Некоторые фреймворки агентов могут сохранять состояние агента, чекпоинтировать выполнение и возобновлять позже.

Это полезно, когда сам агент имеет многошаговый процесс рассуждения.

планировщик или рабочий процесс
  -> runtime агента
  -> загрузить чекпоинт
  -> вызвать инструменты
  -> сохранить чекпоинт
  -> возобновить позже

Как это работает

Внешний планировщик или рабочий процесс запускает агента. Runtime агента загружает предыдущее состояние, выполняет следующий шаг, вызывает инструменты при необходимости и записывает чекпоинт.

Runtime агента не должен быть вашим единственным планировщиком. Его лучше рассматривать как слой рассуждений внутри более крупной архитектуры бэкенда.

Модель состояния

Хранилище чекпоинтов агента содержит:

текущий узел
сообщения
выводы инструментов
промежуточное состояние рассуждений
отложенное действие

Долгосрочная память содержит:

устойчивые предпочтения пользователя
факты
контекст проекта
ссылки на источники

Операционное состояние по-прежнему принадлежит где-то еще:

расписание опроса
курсор
статус
количество повторных попыток
записи дедупликации

Полезное правило: память — это не курсор, и чекпоинт — это не очередь. Память агента хранит то, что знает модель; операционное состояние отслеживает, где находится процесс и что он сделал. Смешение двух приводит к тонким ошибкам, которые проявляются только при конкурентности или после перезапуска. Полное пространство дизайна для рабочей памяти, устойчивого состояния и слоев извлечения описано в Системы памяти в AI-ассистентах.

Лучшее применение

Используйте постоянный runtime агента для:

• Многошаговых исследований.
• Агентов, которые приостанавливаются и возобновляются.
• Работы с участием человека.
• Рассуждений, насыщенных инструментами.
• Задач, где контекст накапливается со временем.

Слабые стороны

Постоянство агента — это не то же самое, что операционная надежность. Вам все еще нужны планирование, блокировка, повторные попытки, лимиты скорости и журналы аудита.

Метод 9: Синхронизация базы данных плюс оценка изменений

В этом паттерне опрос используется для синхронизации внешних данных в вашу собственную базу данных. Ассистент затем реагирует на изменения локальной базы данных, а не запрашивает внешние API напрямую в каждом цикле оценки.

синхронизатор опроса
  -> внешний API
  -> локальная база данных
  -> оценщик изменений
  -> действие ассистента

Это разделяет синхронизацию данных и интеллектуальность ассистента. Рабочий процесс синхронизации отвечает за поддержание актуальности локальных записей; оценщик отвечает за решение, что делать с изменениями. Каждый слой может быть протестирован, мониторен и масштабирован независимо.

Как это работает

Рабочий процесс синхронизации периодически получает внешние изменения и записывает нормализованные записи в вашу базу данных. Второй рабочий процесс или поток изменений обнаруживает обновленные строки и решает, должен ли ассистент действовать.

Модель состояния

Таблица синхронизации хранит:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Состояние синхронизации хранит:

source_cursor
last_sync_at
rate_limit_status
failure_count

Таблица оценки ассистента хранит:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Лучшее применение

Используйте этот паттерн для:

• Синхронизации CRM.
• Систем тикетирования.
• Бухгалтерских документов.
• Инвентаря продуктов.
• Обзора соответствия.
• Индексации поиска.
• Внутренних дашбордов.

Слабые стороны

Синхронизация всего может быть дорогой и ненужной. Это также может создать обязательства по конфиденциальности и удержанию. Используйте этот паттерн, когда локальные данные имеют ценность за пределами одного действия ассистента.

Метод 10: Адаптивный опрос

Адаптивный опрос изменяет частоту на основе состояния, срочности или недавней активности.

активный объект: опрашивать каждые 1 минуту
ожидание объекта: опрашивать каждые 1 час
устаревший объект: опрашивать раз в день
завершенный объект: остановить опрос

Как это работает

После каждого запуска рабочий процесс решает, когда должен произойти следующий запуск.

Если объект изменился недавно, опрашивать раньше. Если ничего не изменилось долгое время, замедлить. Если задача завершена, остановить.

Модель состояния

Состояние опроса включает:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Снимок источника включает:

status
updated_at
activity_level
expected_next_change

Лучшее применение

Используйте адаптивный опрос для:

• Статуса развертывания.
• Отслеживания доставки.
• Доступности слотов календаря.
• Мониторинга цен.
• Задач сборки.
• Длительных задач поставщика.
• Любого источника с всплесками обновлений.

Слабые стороны

Адаптивный опрос может быть сложнее для рассуждений. Если задача должна выполняться в строго определенное время, держите его строгим. Не делайте задачи соответствия «умными».

Метод 11: Семантический опрос с оценщиком LLM

Семантический опрос используется, когда условие размыто.

Код может ответить:

Равен ли статус Complete?
Цена ниже 100?
Есть ли новое сообщение?

LLM может помочь ответить:

Звучит ли это письмо срочным?
Вероятно ли, что этот клиент недоволен?
Релевантна ли эта научная статья?
Требует ли это изменения моего внимания?

Как это работает

Рабочий процесс сначала применяет дешевые детерминированные фильтры. Только кандидаты идут к LLM.

новый элемент?
соответствует фильтрам источника?
не уже обработан?
не очевидно нерелевантен?

Затем LLM оценивает меньший набор кандидатов и возвращает структурированный вывод.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Клиент сообщает о сбое в производстве."
}

Модель состояния

Определение опроса хранит:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Журнал оценки хранит:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Состояние опроса хранит:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Лучшее применение

Используйте семантический опрос для:

• Обнаружения важных писем.
• Мониторинга настроения клиентов.
• Исследовательских оповещений.
• Обнаружения возможностей продаж.
• Триажи безопасности.
• Исполнительных брифингов.

Слабые стороны

Вызовы LLM стоят денег и добавляют задержку. Они также могут быть несовместными, если промпты и схемы свободны. Используйте детерминированные фильтры первыми. Спрашивайте модель только тогда, когда действительно нужно суждение.

Таблица решений: Выбор метода агента с опросом

Рекомендуемая архитектура по умолчанию

Для большинства производственных AI-ассистентов начните с этого:

таблица опросов
  -> планировщик
  -> очередь
  -> безсостоятельные рабочие процессы
  -> детерминированные фильтры
  -> опциональный оценщик LLM
  -> уведомление или действие ассистента

Минимальная схема:

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

Это дает вам чистое разделение:

планировщик владеет временем
очередь владеет буферизацией
рабочий процесс владеет выполнением
база данных владеет состоянием
LLM владеет семантическим суждением
ассистент владеет взаимодействием с пользователем

Это разделение — сердце надежного агента с опросом.

Пример: Агент Hermes обрабатывает задачи Notion

Теперь применим архитектуру к конкретному случаю.

Предположим, база данных Notion содержит задачи. Hermes должен запускаться каждые 10 минут, брать одну задачу в состоянии Todo, устанавливать ее в InProgress, выполнять и затем отмечать как Complete.

Это лучше всего описывается как:

внешний инструмент как очередь задач
+
планируемый рабочий процесс опроса
+
выполнение на основе захвата или аренды

Для производственной версии это становится:

опрос на основе очередей с Notion как ориентированным на человека почтовым ящиком задач

Свойства задачи Notion

База данных Notion должна содержать поля, такие как:

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

Важные поля — ClaimedAt, ClaimExpiresAt и RunId. Они делают захват задачи видимым и восстанавливаемым.

Состояние выполнения Hermes

Hermes также должен сохранять собственную запись выполнения:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Это защищает вас, если Notion редактируется вручную, если вызов API падает, или если вам нужно аудировать, что именно сделал Hermes.

Поток выполнения

Каждые 10 минут:
  планировщик Hermes создает запуск

Рабочий процесс Hermes:
  находит одну задачу Notion, где Status = Todo
  сортирует по Priority и CreatedAt
  захватывает задачу, устанавливая Status = InProgress
  пишет ClaimedBy, ClaimedAt, ClaimExpiresAt и RunId
  выполняет задачу
  пишет журналы выполнения в бэкенд Hermes
  устанавливает Status Notion = Complete при успехе
  устанавливает Status Notion = Failed при ошибке

Если Hermes падает после захвата задачи, аренда может истечь:

Status = InProgress
ClaimExpiresAt < now

Будущий запуск может затем восстановить задачу или отметить ее как сбой.

Обработка ошибок

При успехе:

Status = Complete
CompletedAt = now
LastError = пусто

При восстанавливаемом сбое:

Status = Todo
RetryCount = RetryCount + 1
LastError = короткое сообщение об ошибке

При невозвратном сбое:

Status = Failed
LastError = четкое объяснение

Для безопасности Hermes также должен использовать ключ идемпотентности:

notion_page_id + task_version + action_type

Это предотвращает выполнение одной и той же задачи дважды, если повторная попытка происходит в неправильное время.

Почему это не просто опрос

Часть опроса — это только механизм пробуждения. Реальная архитектура — это захват задач и надежное выполнение.

Наивная реализация говорит:

Каждые 10 минут найти задачу Todo и сделать ее.

Надежная реализация говорит:

Каждые 10 минут захватить ровно одну подходящую задачу, записать запуск, выполнить идемпотентно и переместить задачу в конечное состояние.

В этом разница между демо и агентом, которому можно доверять.

Общие ошибки агентов с опросом

Ошибка 1: Нет протокола захвата

Если два рабочих процесса могут видеть одну и ту же задачу, они могут выполнить ее оба.

Используйте:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Даже если вы сейчас запускаете один рабочий процесс, проектируйте так, как если бы второй рабочий процесс мог появиться позже.

Ошибка 2: Нет ключа дедупликации

Каждое внешнее действие должно иметь ключ дедупликации.

user_id + poll_id + source_object_id + action_type + condition_version

Это предотвращает повторяющиеся уведомления, повторяющиеся письма, повторяющееся выполнение задач и повторяющиеся вызовы инструментов. Более широкие принципы, стоящие за охватом, хранением и тестированием этих ключей, применяются здесь так же — см. Идемпотентность в распределенных системах, которая действительно работает.

Ошибка 3: Вызов LLM слишком рано

Не просите модель делать фильтрацию базы данных.

Плохо:

Отправить все задачи LLM и спросить, какая из них Todo.

Лучше:

Использовать фильтр API Notion для получения задач Todo.
Затем использовать LLM только если нужна интерпретация задачи.

Ошибка 4: Отношение к Notion как к единственному бэкенду

Notion — хороший человеческий интерфейс. Это не полный бэкенд выполнения.

Храните журналы выполнения, повторные попытки, трассировки и записи идемпотентности в Hermes.

Ошибка 5: Бесконечный опрос

Каждый опрос должен иметь условие остановки.

Примеры:

остановить после успеха
остановить после даты
остановить после максимального количества повторных попыток
остановить, когда пользователь отключит его
остановить после повторяющейся ошибки авторизации

Агент с опросом без условия остановки — это тихая утечка затрат.

Ошибка 6: Нет наблюдаемости

Вы должны быть able ответить:

Что выполнил агент?
Почему он выполнил?
Что он прочитал?
Что он изменил?
Почему он упал?
Уведомил ли он пользователя?
Выполнился ли он дважды?

Если вы не можете ответить на эти вопросы, система не готова к важной работе.

Чек-лист наблюдаемости

Отслеживайте метрики, такие как:

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

Поля журнала, такие как:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Постройте административный вид для:

активные опросы
застылые задачи InProgress
недавние сбои
задачи с высокими повторными попытками
задачи мертвых писем
дорогие оценки LLM
отключенные интеграции

Агенты с опросом работают в фоновом режиме, где сбои тихи, и проблемы могут накапливаться, прежде чем кто-либо заметит. Фоновые системы нуждаются в видимости, встроенной с самого начала, а не добавленной постфактум, когда что-то идет не так. Для полного стека наблюдаемости для AI и систем на базе LLM — метрик, трассировок, структурированных журналов и SLO — см. Наблюдаемость для систем LLM: метрики, трассировки, журналы и тестирование в производстве.

Итоговая рекомендация

Паттерны опроса обрабатывают проактивный слой планирования под многоагентной системой. Как только у вас есть несколько агентов, которым нужно координировать друг с другом — а не просто опрашивать независимо — следующее дизайнерское решение — как они координируют: hub-and-spoke, конвейер, fan-out или swarm. Паттерны оркестрации многоагентных систем охватывает эти топологии координации с режимами сбоев и фреймворком принятия решений.

Для серьезного AI-ассистента начните с рабочих процессов опроса на основе очередей и устойчивого хранилища состояния. Добавьте вебхуки там, где поставщики их поддерживают. Используйте адаптивный опрос, когда важны лимиты скорости. Используйте устойчивый движок рабочих процессов, когда процесс длительный и многошаговый. Используйте постоянный runtime агента, когда агенту нужно рассуждать со временем.

Для примера Hermes и Notion правильная архитектура:

Notion как ориентированный на человека почтовый ящик задач
Планировщик Hermes каждые 10 минут
Рабочий процесс Hermes с логикой захвата или аренды
Бэкенд Hermes для журналов выполнения и идемпотентности
Обновления статуса Notion для видимости

Интервал опроса — не сложная часть. Сложная часть — убедиться, что агент захватывает одну задачу, выполняет ее один раз, записывает, что произошло, и оставляет систему в состоянии, которое люди могут понять.

Это то, что превращает скрипт опроса в надежного AI-ассистента — не интервал, не модель, а дисциплина вокруг захвата работы, записи ее и оставления системы в состоянии, которое могут понять как люди, так и будущие запуски.