За пределами вайб-кодингаМасштабирование ИИ-агентов через инфраструктуру извлечения

Почти любой разработчик может заставить ИИ-агента собрать данные с одной страницы при помощи удачно сформулированного промпта. Попросите Claude взять цену с этого URL, вставьте ссылку, и обычно вы получите пригодный результат за один ход.

Такой подход быстро ломается, стоит выйти за пределы прототипа: в момент перехода от одной страницы к десяти тысячам вы перестаёте бороться с промптами и начинаете бороться с инфраструктурой. При тестировании извлечения данных в больших объёмах раз за разом всплывают одни и те же сбои:

• Агенты принимают страницы CAPTCHA за настоящий контент.
• Полезная нагрузка HTML на 200 KB взрывает расход токенов.
• Повторные попытки умножают стоимость инференса.
• Редизайн фронтенда молча ломает логику извлечения.
• Одни и те же URL краулятся снова и снова.

Большинство сбоев ИИ-агентов, это инфраструктурные сбои, переодетые в проблему промптинга. Это руководство не про то, как писать промпты лучше. Оно про то, как построить слой между живым вебом и вашей моделью: нормализованное извлечение в Markdown через Crawlbase Web MCP Server, предохранители, которые отсекают отравленные ответы до инференса, и Cloud Storage в роли долговременной памяти агента. У каждого примера ниже есть работающий аналог в сопутствующем репозитории.

Почему ИИ-агенты ломаются на масштабе

ИИ-агенты не выдерживают масштаба, потому что публичный веб шумный, нестабильный и дорогой для прямой обработки языковой моделью. Современная веб-страница, это не только контент. Это бандлы JavaScript, полезная нагрузка гидратации, скрипты аналитики, продублированные деревья DOM, баннеры о cookie и состояние фреймворка. Страница с ценами, которая выглядит простой, до всякой нормализации способна вернуть заметно больше 200 KB сырого HTML, и почти всё это не имеет отношения к тому, что на самом деле нужно агенту.

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

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

На практике это даёт сбои, которые по отдельности выглядят почти комично, а в сумме обходятся дорого. Агенты вытаскивают цены из каруселей рекомендаций, пересказывают баннер о cookie как содержимое страницы, принимают JSON гидратации за данные о товаре или считают промежуточную страницу CAPTCHA нормальным ответом.

Почему Markdown выигрывает у сырого HTML

Markdown снижает расход токенов и повышает надёжность извлечения, потому что убирает фронтенд-шум, сохраняя семантическую структуру. Сырой HTML тащит с собой полезную нагрузку JavaScript, классы CSS, навигационную разметку, трекинговые скрипты и артефакты фреймворков, которые модели не нужны. Markdown оставляет то, от чего рассуждение действительно зависит: заголовки, абзацы, списки, таблицы и ссылки.

Точная величина сокращения зависит от сайта, но направление всегда одно: на порядок меньше нагрузки при том же объёме информации. Это выражается в меньшей стоимости токенов, более быстром инференсе, более чистом извлечении и более стабильном рассуждении, и всё это только за счёт улучшения соотношения сигнала и шума внутри контекстного окна.

Именно поэтому Web MCP Server отдаёт нормализованное извлечение через crawl_markdown, тот же механизм, что стоит за format=md в Crawling API. Когда нормализация уже сделана выше по потоку, промпт может быть коротким и конкретным:

Use crawl_markdown on https://example.com/pricing and return only:
plan names, monthly prices, and currency.
Do not paste raw HTML.
If the crawl fails, report the tool error.

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

Что такое плоскость данных агента

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

Без этого слоя агенты работают напрямую с нестабильными живыми веб-страницами. На демо выглядит красиво, деградирует быстро.

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

Предохранители: валидация до инференса

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

Сопутствующий модуль circuit_breaker.py реализует валидацию с отказом по умолчанию перед слоем рассуждений:

def evaluate(
    result: CrawlResult,
    *,
    max_body_chars: int = DEFAULT_MAX_BODY_CHARS,
    expect_markdown: bool = True,
) -> CircuitDecision:

    if result.http_status != 200:
        return CircuitDecision(False, f"HTTP status {result.http_status}")

    if result.cb_status and result.cb_status != "200":
        return CircuitDecision(
            False,
            f"Crawlbase cb_status={result.cb_status}"
        )

    if not result.body.strip():
        return CircuitDecision(False, "empty body")

    if expect_markdown and not result.content_type.startswith("text/markdown"):
        return CircuitDecision(
            False,
            f"expected markdown, got {result.content_type}"
        )

    if len(result.body) > max_body_chars:
        return CircuitDecision(
            False,
            f"body exceeds {max_body_chars} chars"
        )

    return CircuitDecision(True, "ok")

Эта функция, это межсетевой экран между публичным вебом и контекстным окном. Вместо того чтобы доверять каждому ответу, она проверяет транспортный статус, cb_status от Crawlbase, пустое тело, тип содержимого и размер полезной нагрузки до того, как что-либо дойдёт до модели. Учтите, что cb_status, это текущее имя заголовка статуса Crawlbase; в старом коде и руководствах он может по-прежнему называться pc_status.

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

Без предохранителя цепочка сбоев в продакшене предсказуема:

1. Целевой сайт возвращает страницу CAPTCHA.
2. Агент принимает этот HTML за настоящий контент.
3. Конвейеры извлечения сохраняют отравленные данные.
4. Системы мониторинга сообщают об изменениях, которых не было.
5. Циклы повторов умножают и расход токенов, и стоимость краулинга.

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

Почему хранилище выигрывает у повторного краулинга

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

Здесь Crawlbase Cloud Storage и оправдывает своё место в архитектуре. Конвейер загрузки сохраняет нормализованные снимки в Markdown с параметром store=true вместо того, чтобы заново обрабатывать живые страницы на каждом запуске:

params = {
    "token": token,
    "url": url,
    "format": "md",
    "md_readability": "true",
    "store": "true",
}

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

Есть и вторая выгода, которую легко упустить: детерминизм. Живой интернет недетерминирован из-за редизайнов фронтенда, сплит-тестов, персонализации и обычной текучки DOM. Снимки в хранилище дают фиксированный вход для рассуждения, а это разница между конвейером, который можно отлаживать, и конвейером, за которым можно только наблюдать.

Полный процесс лежит в сопутствующем скрипте загрузки с приоритетом хранилища.

Обнаружение изменений без повторной обработки всего

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

prev_hash = hashlib.sha256(previous.encode("utf-8")).hexdigest()
curr_hash = hashlib.sha256(current.encode("utf-8")).hexdigest()

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

Сопутствующий репозиторий плоскости данных

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

• circuit_breaker.py для валидации извлечения с отказом по умолчанию.
• ingest.py для загрузки Markdown с приоритетом хранилища.
• change_detection.py для сравнения снимков и процессов мониторинга.

Важны не сами скрипты. Важна форма: на вход приходит пакет URL, предохранитель отбраковывает то, что никогда не должно дойти до модели, уцелевшее нормализуется в Markdown и сохраняется, а агент потом читает небольшие фрагменты по ссылке вместо повторного краулинга. Агенты должны рассуждать над проверенным, нормализованным и сохранённым извлечением, а не над произвольными ответами из интернета.

Подключите Web MCP Server к Claude

Web MCP Server подключается напрямую к Claude Desktop или Claude Code. Документация по ИИ и MCP и руководство по интеграции с Claude подробнее описывают настройку, сценарии работы с Cloud Storage и инструменты извлечения. Конфигурация для Claude Desktop короткая:

{
  "mcpServers": {
    "crawlbase": {
      "type": "stdio",
      "command": "npx",
      "args": ["@crawlbase/mcp@latest"],
      "env": {
        "CRAWLBASE_TOKEN": "YOUR_TOKEN",
        "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN"
      }
    }
  }
}

После перезапуска Claude инструменты извлечения становятся доступны в окружении модели: crawl_markdown для нормализованных запросов плюс storage_get, storage_list и storage_bulk_get для чтения того, что уже собрано. Дальше те же инфраструктурные паттерны работают интерактивно внутри Claude или эксплуатационно через конвейеры на Python, и ради этого их и выносят в плоскость данных, а не в промпт.

Продакшен-паттерны, которые масштабируются

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

По умолчанию используйте Markdown

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

Блокируйте при сбое

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

Сначала спрашивайте память

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

Соблюдайте бюджеты контекста

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

Отделяйте извлечение от рассуждения

Валидации и нормализации место выше модели по потоку. Разбиение конвейера на этапы retrieval, validation, normalization, persistence и reasoning даёт чистую изоляцию сбоев, более стабильные результаты и систему, которую действительно можно отлаживать на масштабе.

Что действительно масштабируется

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

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

Если вы строите систему в этом направлении, наши разборы про рабочие процессы ИИ-агентов с Web MCP Server и создание исследовательского набора данных для ИИ показывают ту же плоскость данных на конкретных задачах. Следующее поколение ИИ-систем будет определяться не только более удачными промптами. Оно будет определяться более качественной инфраструктурой извлечения.

Часто задаваемые вопросы

Почему ИИ-агенты не справляются со скрейпингом большого числа страниц?

Небольшие демо работают, потому что модель незаметно компенсирует шумное извлечение. На больших объёмах краулинга агенты начинают потреблять раздутую полезную нагрузку HTML, страницы CAPTCHA, продублированную фронтенд-разметку и нестабильные живые ответы, а это даёт коллапс контекста, раздутую стоимость токенов и несогласованное извлечение. Сбой находится в плоскости данных, а не в промпте.

Почему Markdown лучше HTML для ИИ-агентов?

Markdown сохраняет семантическую структуру и убирает большую часть фронтенд-шума, что снижает расход токенов, загрязнение контекста, задержку инференса и нестабильность извлечения. Та же страница, которая в виде сырого HTML стоит 50K+ токенов, в виде Markdown обычно умещается в несколько тысяч токенов, с лучшим соотношением сигнала и шума внутри контекстного окна.

Что такое предохранитель в инфраструктуре ИИ?

Это шлюз валидации, который срабатывает до того, как содержимое дойдёт до LLM. Он отбраковывает ошибки HTTP, значения cb_status, отличные от 200, пустые тела, неожиданные типы содержимого и слишком большие полезные нагрузки, поэтому отравленное извлечение никогда не становится входом для рассуждения. Политика такова: отказ по умолчанию, и если ответ выглядит неправильно, его отбрасывают, а не пересказывают.

Почему агентам стоит использовать хранилище вместо повторного краулинга страниц?

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

Что такое плоскость данных агента?

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

NZ

Neil Zamora

Старший архитектор · Crawlbase

Старший архитектор в Crawlbase, сосредоточен на системах, стоящих за краулингом в больших масштабах: ротация прокси, устойчивость к anti-bot и API, скрывающие эту сложность.

IK

Ian Kalvin

Инженер технической поддержки · Crawlbase

Инженер технической поддержки в Crawlbase, пишет с переднего края того, что на самом деле ломается в продакшене при скрейпинге и в прокси-конфигурациях.