Как сделать ИИ-агента для ресерча и мониторинга конкурентов

Что получится в результате

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

Первая рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. список конкурентов хранится в `competitors`;
3. исследовательские вопросы хранятся в `monitoring_questions`;
4. разрешенные источники хранятся в `source_registry`;
5. поисковые запросы хранятся в `search_queries`;
6. задания на обход страниц хранятся в `crawl_jobs`;
7. снимки страниц пишутся в `page_snapshots`;
8. результаты поиска пишутся в `serp_results`;
9. найденные факты пишутся в `observations`;
10. проверка фактов пишется в `fact_checks`;
11. изменения по страницам пишутся в `change_log`;
12. сигналы рынка пишутся в `market_signals`;
13. выводы и гипотезы пишутся в `insight_queue`;
14. задачи командам пишутся в `task_queue`;
15. спорные выводы уходят в `approval_queue`;
16. одобренные выводы попадают в `execution_queue`;
17. еженедельный отчет пишется в `weekly_digest`;
18. история версий пишется в `version_log`;
19. все решения пишутся в `audit_log`;
20. ошибки API и данных пишутся в `error_log`.

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

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• Firecrawl API, Tavily API, Apify API, DataForSEO API или другой легальный источник веб-данных.
• Список конкурентов и страниц для мониторинга.
• Список поисковых запросов.
• Правила доступа: что можно собирать, что нельзя, как учитывать robots.txt и ToS.
• Канал approval: Telegram, Slack, Teams, email или задача.
• Канал отчетов: Slack, Teams, email, Telegram или Google Docs.
• API-ключ LLM-провайдера.
• Ответственный маркетолог, продуктовый менеджер или аналитик, который проверяет выводы.

Шаг 1. Выберите один сценарий мониторинга

Не начинайте с формулировки “следить за конкурентами”.

Для MVP выберите один сценарий:

1. мониторинг страниц тарифов конкурентов;
2. мониторинг changelog и новых функций;
3. мониторинг блогов и контентных тем;
4. мониторинг документации по интеграциям;
5. мониторинг SERP по ключевым запросам;
6. мониторинг отзывов и публичных жалоб;
7. еженедельный дайджест изменений рынка.

Самый безопасный старт: `раз в неделю проверить страницы тарифов и changelog 5 конкурентов, выделить факты и собрать дайджест`.

Проверка: сценарий можно вручную проверить на 10 URL.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

• обходить логины и paywall;
• игнорировать robots.txt и условия сайта;
• создавать аккаунты на сайтах конкурентов;
• отправлять формы на чужих сайтах;
• сканировать сайт с высокой частотой;
• собирать персональные данные;
• копировать закрытые материалы;
• публиковать выводы наружу;
• отправлять обвинения или сравнения без проверки;
• менять цены или позиционирование компании;
• запускать рекламные кампании по выводам агента;
• писать конкуренту от имени компании.

Разрешите агенту:

• читать разрешенные публичные страницы;
• сохранять URL, дату и фрагмент доказательства;
• сравнивать снимки страниц;
• выделять факты;
• оценивать confidence;
• готовить дайджест;
• создавать задачи на проверку;
• отправлять review;
• вести audit log.

Проверка: в `source_registry` у каждого источника есть `access_mode` и `allowed = true`.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу:

Competitor research agent

Добавьте листы:

settings
competitors
monitoring_questions
source_registry
search_queries
crawl_jobs
page_snapshots
serp_results
observations
fact_checks
change_log
market_signals
insight_queue
approval_queue
execution_queue
task_queue
weekly_digest
version_log
audit_log
error_log

Проверка: n8n может читать и писать во все листы.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

approval_required | true | выводы и внешние действия только через review
auto_execute | false | автоприменение выключено
respect_robots_txt | true | учитывать правила обхода
max_pages_per_competitor | 20 | лимит страниц за запуск
min_confidence_for_digest | medium | минимум уверенности для дайджеста
snapshot_retention_days | 180 | хранение снимков
digest_day | friday | день еженедельного отчета
source_timeout_seconds | 30 | таймаут запроса

Проверка: лимиты обхода и review включены.

Шаг 5. Заполните competitors

В `competitors` добавьте колонки:

competitor_id
name
website_url
category
market_segment
priority
owner
status
updated_at

Пример:

COMP-001 | Acme AI | https://example.com | AI support | SMB | high | product@example.ru | active | 2026-05-23

Проверка: у каждого конкурента есть сайт, сегмент и приоритет.

Шаг 6. Заполните monitoring_questions

В `monitoring_questions` добавьте колонки:

question_id
competitor_id
topic
question_text
expected_evidence
priority
owner
status
updated_at

Примеры:

Q-001 | COMP-001 | pricing | Изменились ли тарифы за неделю? | price table, plan names, URL | high | product | active | 2026-05-23
Q-002 | COMP-001 | product | Появились ли новые функции AI-агента? | changelog, docs, release note | high | product | active | 2026-05-23

Проверка: агент отвечает на конкретные вопросы, а не собирает все подряд.

Шаг 7. Заполните source_registry

В `source_registry` добавьте колонки:

source_id
competitor_id
source_type
url
access_mode
robots_allowed
check_frequency
importance
last_checked_at
status
updated_at

`source_type`:

pricing
changelog
blog
docs
landing
integrations
reviews
serp
social
news

`access_mode`:

public
manual_only
blocked
api
rss

Проверка: источники `blocked` не попадают в `crawl_jobs`.

Шаг 8. Заполните search_queries

В `search_queries` добавьте колонки:

query_id
topic
query_text
target_region
language
frequency
owner
status
updated_at

Примеры:

SQ-001 | pricing | Acme AI pricing | RU | ru | weekly | marketing | active | 2026-05-23
SQ-002 | alternatives | лучшие AI support agents | RU | ru | weekly | seo | active | 2026-05-23

Проверка: поисковые запросы привязаны к теме и региону.

Шаг 9. Создайте crawl_jobs

В `crawl_jobs` добавьте колонки:

job_id
run_id
source_id
competitor_id
url
tool
status
scheduled_at
started_at
finished_at
error_message

`tool`:

firecrawl
apify
manual
rss
http_request

Статусы:

queued
running
completed
failed
skipped
blocked

Проверка: за один запуск создается не больше `max_pages_per_competitor`.

Шаг 10. Подключите источники в n8n

Создайте workflow:

Competitor Research Agent - weekly monitor

Добавьте узлы:

1. `Schedule Trigger`;
2. `Read competitors`;
3. `Read monitoring_questions`;
4. `Read source_registry`;
5. `Read search_queries`;
6. `Create crawl_jobs`;
7. `Fetch pages`;
8. `Fetch SERP`;
9. `Write page_snapshots`;
10. `Extract observations`;
11. `Detect changes`;
12. `Check facts`;
13. `LLM research analysis`;
14. `Write digest and tasks`;
15. `Send approval`;
16. `Write audit_log`;
17. `Write error_log`.

Проверка: workflow вручную обрабатывает один конкурентный сайт и один поисковый запрос.

Шаг 11. Подключите Firecrawl, Tavily или Apify

Для Firecrawl:

POST /v2/scrape
url = {{$json.url}}
formats = markdown, html

Для Tavily:

POST /search
query = {{$json.query_text}}
search_depth = basic
include_answer = false

Для Apify:

POST /v2/acts/{actorId}/runs
GET /v2/datasets/{datasetId}/items

Проверка: tool возвращает URL, title, текст, дату запроса и статус.

Шаг 12. Сохраняйте page_snapshots

В `page_snapshots` добавьте колонки:

snapshot_id
run_id
source_id
competitor_id
url
title
content_hash
content_text
captured_at
tool
status
created_at

Статусы:

ok
empty
blocked
error
manual_needed

Проверка: повторный снимок той же страницы имеет новый `content_hash`, если контент изменился.

Шаг 13. Сохраняйте serp_results

В `serp_results` добавьте колонки:

serp_id
run_id
query_id
query_text
position
title
url
snippet
domain
captured_at
status

Проверка: по одному query сохраняются позиции и URL, а не только текстовый summary.

Шаг 14. Создайте observations

В `observations` добавьте колонки:

observation_id
run_id
competitor_id
source_id
topic
fact_text
evidence_quote
evidence_url
observed_at
confidence
status
created_at

`topic`:

pricing
feature
positioning
integration
content
review
traffic
partnership
customer_segment

`confidence`:

high
medium
low
needs_review

Проверка: каждое наблюдение имеет `evidence_url` и короткий фрагмент доказательства.

Шаг 15. Создайте fact_checks

В `fact_checks` добавьте колонки:

fact_check_id
observation_id
check_type
result
supporting_urls
conflicting_urls
notes
checked_at

`check_type`:

official_source
second_source
previous_snapshot
manual_review

`result`:

confirmed
partially_confirmed
unconfirmed
conflicting
needs_manual_review

Проверка: вывод high confidence невозможен без official source или второго подтверждения.

Шаг 16. Создайте change_log

В `change_log` добавьте колонки:

change_id
run_id
competitor_id
source_id
url
change_type
old_value
new_value
evidence_json
risk_level
status
created_at

`change_type`:

price_change
plan_change
new_feature
removed_feature
new_integration
new_case
positioning_change
content_change
docs_change

Проверка: изменение тарифной страницы попадает в `price_change` или `plan_change`, а не в общий текст.

Шаг 17. Создайте market_signals

В `market_signals` добавьте колонки:

signal_id
run_id
topic
signal_text
competitor_ids
evidence_urls
confidence
impact
owner
status
created_at

`impact`:

low
medium
high
critical

Проверка: сигнал рынка опирается минимум на одно наблюдение или SERP-результат.

Шаг 18. Создайте insight_queue

В `insight_queue` добавьте колонки:

insight_id
run_id
topic
insight_text
evidence_json
confidence
recommended_action
owner_team
approval_required
status
created_at

Статусы:

draft
needs_review
approved
rejected
included_in_digest

Проверка: гипотеза с confidence `low` всегда получает `needs_review`.

Шаг 19. Настройте prompt для LLM research analysis

В n8n добавьте узел `LLM research analysis`.

System prompt:

Ты research analyst. Работай только с переданными источниками.
Не придумывай факты, цены, даты, клиентов и выводы без evidence.
Разделяй fact, change, signal и hypothesis.
Если доказательств мало, ставь confidence = needs_review.
Не публикуй выводы наружу и не предлагай агрессивные действия.
Ответ возвращай только JSON.

User prompt:

Проанализируй данные мониторинга.

competitors:
{{$json.competitors}}

questions:
{{$json.monitoring_questions}}

snapshots:
{{$json.page_snapshots}}

serp:
{{$json.serp_results}}

previous_changes:
{{$json.change_log}}

Верни JSON:
{
  "run_id": "...",
  "observations": [
    {
      "competitor_id": "...",
      "topic": "...",
      "fact_text": "...",
      "evidence_quote": "...",
      "evidence_url": "...",
      "confidence": "high | medium | low | needs_review"
    }
  ],
  "changes": [
    {
      "competitor_id": "...",
      "change_type": "...",
      "old_value": "...",
      "new_value": "...",
      "confidence": "high | medium | low | needs_review"
    }
  ],
  "insights": [
    {
      "topic": "...",
      "insight_text": "...",
      "recommended_action": "...",
      "owner_team": "product | marketing | sales | leadership",
      "approval_required": true
    }
  ]
}

Проверка: JSON валидный, а каждое observation содержит URL.

Шаг 20. Создайте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
run_id
action_type
action_text
payload_json
risk_level
requested_by
approver
status
requested_at
approved_at
decision_comment

Статусы:

pending
approved
rejected
needs_changes
expired

В approval отправляйте:

1. выводы low confidence;
2. сравнения с конкурентами;
3. публичные формулировки;
4. задачи на изменение цены;
5. задачи на изменение позиционирования;
6. упоминание конкурента в маркетинге;
7. выводы из спорного источника;
8. любые внешние действия.

Проверка: без `approved` вывод не попадает в финальный дайджест как рекомендация.

Шаг 21. Сделайте Telegram approval

В n8n добавьте узел `Telegram`.

Сообщение:

Research insight: pricing

Наблюдение: COMP-001 добавил тариф Business.
Evidence: https://example.com/pricing
Confidence: medium
Действие: проверить нашу страницу тарифов и сравнение пакетов.

Approve: /approve RES-770
Edit: /edit RES-770
Reject: /reject RES-770

После `/approve RES-770` workflow должен:

1. найти `approval_id`;
2. проверить статус `pending`;
3. записать `approved`;
4. заполнить `approved_at`;
5. передать действие в `execution_queue`;
6. записать событие в `audit_log`.

Проверка: `/reject` не включает вывод в финальный отчет.

Шаг 22. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
run_id
action_type
target_system
payload_json
status
executed_at
result_json
error_message

Статусы:

queued
manual_only
executed
failed
skipped

Для MVP используйте `manual_only`: агент создает задачу, а человек проверяет вывод и принимает решение.

Проверка: стратегические действия не выполняются автоматически.

Шаг 23. Создайте task_queue

В `task_queue` добавьте колонки:

task_id
source
source_id
run_id
task_type
title
description
owner_team
assignee
priority
status
created_at
due_at
closed_at

`task_type`:

fact_check
pricing_review
content_gap_review
product_review
sales_enablement
seo_review
legal_review
data_fix

Пример:

TASK-8801 | insight_queue | INS-1001 | RUN-20260523 | pricing_review | Проверить тариф Business у COMP-001 | Конкурент добавил новый пакет, confidence medium, нужна ручная проверка | product | product@example.ru | high | open | 2026-05-23 | 2026-05-27 | -

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

Шаг 24. Соберите weekly_digest

В `weekly_digest` добавьте колонки:

digest_id
run_id
period_start
period_end
topics
summary
top_changes_json
top_insights_json
recommended_actions_json
approval_status
created_at

Правила дайджеста:

1. сначала факты;
2. потом изменения;
3. потом выводы;
4. потом задачи;
5. каждый пункт содержит ссылку;
6. low confidence идет в отдельный блок review.

Проверка: дайджест можно отправить команде без ручного копания в 50 страницах.

Шаг 25. Настройте version_log

В `version_log` добавьте колонки:

version_id
entity_type
entity_id
old_hash
new_hash
change_summary
created_at

Проверка: для изменившейся страницы сохраняется история content hash.

Шаг 26. Настройте audit_log

В `audit_log` добавьте колонки:

event_id
run_id
event_type
competitor_id
source_id
actor
input_hash
output_hash
summary
created_at

Пишите события:

run_started
sources_loaded
crawl_job_created
page_captured
serp_captured
observation_created
fact_checked
change_detected
insight_created
approval_requested
digest_created
task_created
run_finished

Проверка: по `run_id` можно восстановить путь от URL до вывода.

Шаг 27. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
step
source_id
competitor_id
url
error_type
error_message
payload_sample
status
created_at
resolved_at

`error_type`:

api_error
blocked_source
timeout
empty_page
robots_disallow
invalid_json
missing_evidence
duplicate_observation

Проверка: если robots disallow, агент пишет `robots_disallow` и пропускает источник.

Шаг 28. Протестируйте на одном конкуренте

Создайте тестовые данные:

competitors:
COMP-TEST-001 | Acme AI | https://example.com | AI support | SMB | high | product@example.ru | active | 2026-05-23

monitoring_questions:
Q-TEST-001 | COMP-TEST-001 | pricing | Изменились ли тарифы за неделю? | price table, plan names, URL | high | product | active | 2026-05-23

source_registry:
SRC-TEST-001 | COMP-TEST-001 | pricing | https://example.com/pricing | public | true | weekly | high | - | active | 2026-05-23

Запустите workflow вручную.

Ожидаемый результат:

1. в `crawl_jobs` появилась задача;
2. в `page_snapshots` появился снимок страницы;
3. в `observations` появился факт с URL;
4. в `fact_checks` появилась проверка;
5. в `change_log` появилась запись, если hash изменился;
6. в `insight_queue` появился вывод или `needs_review`;
7. в `weekly_digest` появился черновик;
8. в `audit_log` есть шаги запуска;
9. в `error_log` нет ошибки.

Проверка: ни один вывод без evidence не попал в digest.

Шаг 29. Проверьте негативные сценарии

Сделайте 5 тестов:

1. поставьте `robots_allowed = false`;
2. удалите `evidence_url`;
3. верните пустую страницу;
4. создайте дубль observation;
5. верните от LLM невалидный JSON.

Ожидаемый результат:

1. запрещенный источник - `robots_disallow`;
2. нет evidence - `missing_evidence`;
3. пустая страница - `empty_page`;
4. дубль - `duplicate_observation`;
5. невалидный JSON - `invalid_json`;
6. low confidence не попадает в финальные рекомендации без review;
7. внешние действия не запускаются.

Проверка: агент не превращает мусор в уверенный отчет.

Минимальная проверка результата

Прототип работает, если выполняются условия:

1. `competitors` содержит минимум 3 конкурента;
2. `monitoring_questions` содержит конкретные вопросы;
3. `source_registry` содержит разрешенные URL;
4. `crawl_jobs` создает ограниченные задания;
5. `page_snapshots` хранит текст и hash;
6. `serp_results` хранит позиции выдачи;
7. `observations` содержит факты с URL;
8. `fact_checks` отделяет confirmed от needs_review;
9. `change_log` ловит изменения;
10. `insight_queue` не смешивает факты и гипотезы;
11. `approval_queue` блокирует спорные выводы;
12. без `approved` нет записи в `execution_queue`;
13. `task_queue` назначает владельца;
14. `weekly_digest` содержит ссылки;
15. `version_log` хранит hash изменений;
16. `audit_log` объясняет действия;
17. `error_log` показывает плохие данные.

Что нельзя автоматизировать в первой версии

• обход логинов и paywall;
• игнорирование robots.txt;
• сбор персональных данных;
• отправку форм на сайтах конкурентов;
• высокочастотный scraping;
• публикацию конкурентных сравнений без review;
• изменение цен и позиционирования компании;
• запуск рекламы по выводам агента;
• отправку сообщений конкурентам;
• копирование закрытых материалов;
• вывод high confidence без доказательств;
• любые внешние действия без approval.

Частые вопросы

Можно ли агенту парсить любые сайты конкурентов?

Нет. Начинайте только с публичных и разрешенных страниц, учитывайте robots.txt, условия использования и нагрузку. Спорные источники помечайте `manual_only`.

Чем ресерч-агент отличается от обычного поиска?

Поиск возвращает ссылки. Ресерч-агент ведет процесс: знает вопросы, источники, сохраняет снимки, выделяет факты, проверяет confidence и готовит отчет с задачами.

Какие источники подключать первыми?

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

Как не получить поток мусора?

Ограничьте вопросы, источники, частоту, лимит страниц, темы и минимум confidence. Каждый факт должен иметь URL и evidence quote.

Какой минимальный результат считать успешным?

Успешный MVP: агент проверяет 3 конкурента, сохраняет снимки страниц, находит изменения, пишет факты с URL, собирает weekly digest и создает задачи на ручную проверку спорных выводов.