WebFetch

13 сентября 2026 · ~12 мин чтения

WebFetch

WebFetch — инструмент ИИ-агента (в том числе Claude), который делает HTTP-запрос к указанному URL, получает содержимое страницы и передаёт его модели как текст для анализа — без запуска браузера, без выполнения JavaScript, без рендеринга.

История

WebFetch как отдельная сущность — не стандарт с датой рождения и автором, а название конкретного инструмента (tool) в наборе возможностей LLM-агентов, появившееся вместе с волной «agentic AI» 2024–2025 годов, когда языковые модели стали получать доступ к внешним действиям через протокол вызова инструментов (tool use / function calling).

Механизм, который стоит за WebFetch, — HTTP GET-запрос — гораздо старше: он часть протокола HTTP, описанного Тимом Бернерсом-Ли в 1991 году и формализованного в RFC 2616 (1999), затем в RFC 7230–7235 (2014) и текущем RFC 9110 (2022). WebFetch — это тонкая надстройка над этим протоколом: агент вызывает инструмент, инструмент делает GET-запрос, получает HTML или другой контент, чистит его (убирает теги, скрипты, иногда конвертирует в markdown) и отдаёт модели укороченный текст.

Вехи, которые привели к появлению таких инструментов:
- 2023 — OpenAI и Anthropic начинают массово внедрять «tool use»/«function calling» в API моделей — модель может не просто отвечать текстом, а вызывать внешние функции.
- 2024 — у Anthropic в Claude появляется набор встроенных инструментов (WebSearch, WebFetch, Bash, Read/Write файлов и т.д.), которые доступны агенту в Claude Code и в API-режиме с tool use.
- 2024–2025 — конкурирующие продукты (OpenAI Operator, Google Gemini с браузерными агентами, open-source фреймворки типа LangChain/AutoGPT) делают то же самое под другими именами: fetch_url, browse_page, read_url — семантика везде одинаковая.

Сейчас WebFetch как конкретный инструмент принадлежит Anthropic и встроен в Claude Code и Claude API (папка «инструменты», доступные модели по умолчанию), но сам паттерн «дай модели простой HTTP-fetch без браузера» — общий для всей индустрии агентов.

Что это такое

WebFetch решает узкую, но частую задачу: агенту дали URL (или он сам его нашёл через поиск), и ему нужно узнать, что там написано. Самый дешёвый и быстрый способ — не открывать полноценный браузер (это тяжело, медленно, требует памяти и процессора), а просто скачать HTML-код страницы одним HTTP-запросом, как это делает команда curl, и отдать текст модели.

Технически WebFetch — это функция с сигнатурой «на входе URL (и иногда — вопрос к содержимому), на выходе — текст». Внутри происходит: DNS-резолвинг домена → установка TLS-соединения (шифрование, см. статью про HTTPS в архиве) → отправка GET-запроса с заголовками (User-Agent, Accept и т.п.) → получение ответа → парсинг HTML в читаемый текст (часто через конвертацию в markdown, обрезание навигации, рекламы, скриптов) → передача этого текста в контекст модели, иногда с суммаризацией, если страница большая.

WebFetch vs headless-браузер (Playwright/Puppeteer/Chromium в фоновом режиме). Это ключевое различие, которое стоит прочно усвоить:

WebFetch vs WebSearch. Это не одно и то же и часто путается. WebSearch — это запрос в поисковую систему («найди мне страницы про X»), результат — список ссылок и сниппетов. WebFetch — это уже открытие конкретной ссылки и чтение её содержимого целиком. Обычно они работают в связке: сначала WebSearch находит адрес, потом WebFetch читает, что там на самом деле написано.

Аналогии из жизни

Аналогия 1 — почтовый ящик против личного визита. WebFetch — это как попросить кого-то забрать письмо из почтового ящика и прочитать его вам вслух: быстро, но вы получаете только то, что лежит в конверте на момент выемки. Headless-браузер — это как самому прийти в офис, дождаться, пока откроют все нужные двери, включат свет, разложат документы по папкам, и только потом читать. Где ломается: если содержимое письма само по себе — это указание «зайди в соседнюю комнату и посмотри там» (то есть страница подгружает контент через JavaScript уже в браузере пользователя), то вы, прочитав письмо, ничего важного не увидите — контента там физически не было в момент выемки.

Аналогия 2 — читать меню в окне ресторана против зайти внутрь. Проходя мимо, вы можете прочитать меню, приклеенное к стеклу — это быстро, бесплатно, не нужно ничего заказывать. Но если меню лежит только на столах внутри (а на стекле — просто вывеска), снаружи вы ничего не узнаете. Так и WebFetch: если весь полезный контент «нарисован» на стороне сервера в исходном HTML — прекрасно видно; если контент подгружается уже в браузере посетителя через API-запросы — WebFetch увидит пустую «вывеску». Где ломается: аналогия не передаёт того, что современные сайты часто специально усложняют «стекло» — добавляют проверки, что запрос идёт из настоящего браузера, а не от скрипта (см. антибот ниже).

Аналогия 3 — фотография вместо видео. WebFetch делает моментальный снимок страницы в момент запроса — как фотоаппарат щёлкает один кадр. Если страница содержит анимацию, бесконечную подгрузку контента при скролле, всплывающие окна через 3 секунды — снимок этого не покажет, для этого нужна «видеокамера», то есть браузер, который может подождать и провзаимодействовать со страницей. Где ломается: фотография технически честный слепок того, что было перед объективом; а WebFetch иногда получает вообще не то, что видит человек — сайт может специально отдавать роботам («по User-Agent» или IP) совсем другую, урезанную или ложную версию страницы (это называется cloaking).

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

Пошагово, на примере того, как агент вроде Claude обрабатывает вызов WebFetch:

1. Модель решает, что нужен внешний контент. Например, в диалоге всплывает: «посмотри, что написано на странице X». Модель формирует вызов инструмента: WebFetch(url="https://example.com/page", prompt="о чём эта статья").
2. Инструмент делает HTTP-запрос. Устанавливается TCP-соединение к серверу, поверх него — TLS-рукопожатие (если https://), затем отправляется запрос вида:
   GET /page HTTP/1.1 Host: example.com User-Agent: <какой-то идентификатор клиента> Accept: text/html
3. Сервер отвечает. Код состояния (200 — всё хорошо, 403 — доступ запрещён, 404 — не найдено, 429 — слишком много запросов, см. статью про rate limiting в архиве) плюс тело ответа — обычно HTML-документ.
4. Инструмент чистит и упрощает HTML. Убирает теги вёрстки, скрипты, стили, рекламные блоки, часто конвертирует в markdown или простой текст — модели не нужна вёрстка, ей нужен смысл.
5. Текст попадает в контекст модели. Если страница огромная, инструмент может обрезать или суммировать её, чтобы уложиться в лимит контекста.
6. Модель отвечает на исходный вопрос, опираясь уже на полученный текст, как будто прочитала документ.

Если на любом из шагов 2–3 что-то идёт не так — сайт требует JavaScript-проверку, показывает CAPTCHA, блокирует по User-Agent или IP, отдаёт WAF-страницу («доступ ограничен») — агент получает вместо полезного текста мусор или ошибку. Это ровно та ситуация, с которой вчера столкнулась исследовательская сессия: попытка WebFetch-ем пройтись по десяткам мировых порталов недвижимости (Zillow, Rightmove, китайские Beike/Anjuke и другие) для конкурентного анализа во многих случаях упиралась в 403 и защиту от ботов, и агенту приходилось переключаться на WebSearch (искать через поисковик закэшированные фрагменты) вместо прямого чтения.

Где встречается в обычной жизни

• Когда вы просите голосового помощника или чат-бота «глянь, что там на этом сайте написано» и присылаете ссылку — внутри почти наверняка отрабатывает аналог WebFetch.
• Когда вы используете расширение браузера или сервис, который «читает статью вслух» или «делает краткий пересказ страницы по ссылке» (например, читалки в стиле Pocket, Readwise Reader) — это фактически WebFetch плюс суммаризация.
• Онлайн-переводчики страниц по URL (вставили ссылку — получили перевод) чаще всего сначала скачивают HTML тем же способом.
• Сервисы предпросмотра ссылок в мессенджерах (когда вы вставляете ссылку в Telegram или WhatsApp и появляется картинка с заголовком) — это тоже мини-fetch страницы для извлечения метатегов (og:title, og:image).
• Проверка «битых ссылок» на сайте (SEO-инструменты, которые обходят все ссылки и смотрят, что они возвращают) — тот же принцип: запрос без браузера, только код ответа и содержимое.

Где встречается в IT и бизнесе

• ИИ-агенты и ассистенты — Claude, ChatGPT (в режиме browsing), Gemini используют аналоги WebFetch, чтобы отвечать на вопросы про свежий контент, которого не было в обучающих данных.
• Конкурентный анализ — именно так вчера использовался инструмент в работе над novostroy.ru: агент пытался обойти десятки порталов недвижимости мира (американский Zillow, британский Rightmove, китайские Beike/Lianjia/Anjuke, индийский 99acres, ближневосточный Bayut), чтобы понять, какие у них фичи — VR-туры, AI-подбор объявлений, индексы вроде Zestimate — и сравнить с текущим продуктом.
• Мониторинг цен и контента конкурентов — e-commerce-компании регулярно «фетчат» страницы конкурентов, чтобы отслеживать цены, наличие, описания товаров.
• RAG-системы (retrieval-augmented generation) — модель сначала ищет релевантные документы (в том числе через WebFetch), потом использует их как контекст для ответа, снижая «галлюцинации».
• QA и мониторинг сайтов — простые проверки «жив ли сайт, отдаёт ли он 200» строятся на том же HTTP-запросе, без браузера.

Кто пользуется

• Anthropic — WebFetch как встроенный инструмент в Claude API и Claude Code, доступен по умолчанию агентам, которым разрешено «видеть интернет».
• OpenAI — аналогичный механизм в ChatGPT (browsing tool) и в Operator/агентских продуктах.
• Google — Gemini с инструментами поиска и чтения страниц в связке с поисковым индексом Google.
• Разработчики на LangChain, LlamaIndex, AutoGPT и подобных фреймворках — там это часто называется requests_get, fetch_url, web_loader; счёт таких инструментов в open-source экосистеме идёт на тысячи внедрений.
• Оценить точные цифры по объёму трафика от подобных агентских fetch-запросов сложно — точных публичных данных нет, но по разным оценкам доля трафика от ИИ-краулеров и агентов к 2025–2026 годам составляет заметный (по некоторым отчётам Cloudflare — уже двузначный процент) кусок нечеловеческого трафика к сайтам, из-за чего многие сайты в 2024–2026 годах стали активно закрываться от таких запросов через robots.txt, WAF и антибот-сервисы.

Альтернативы и конкуренты

• Headless-браузер (Playwright, Puppeteer, Selenium). Плюс: видит полностью отрендеренную страницу, умеет кликать, скроллить, ждать. Минус: медленно, дорого по ресурсам, легче спалиться как бот при неаккуратной настройке.
• Прямой HTTP-клиент (curl, Python requests/httpx, curl_cffi). Плюс: полный контроль над заголовками, самое быстрое и дешёвое решение. Минус: требует ручной настройки под каждый сайт, не выполняет JS, часто банится антибот-системами быстрее, чем «доверенные» инструменты вроде WebFetch.
• API самого сайта (если есть). Плюс: структурированные данные, никакой парсинг HTML не нужен, официально разрешено. Минус: не у всех сайтов есть публичный API, часто требует ключей и имеет лимиты (rate limiting).
• Сервисы-прокси для чтения страниц (например, reader-прокси типа r.jina.ai или Wayback Machine как архив). Плюс: снимают часть антибот-проблем с вас, отдают уже очищенный текст. Минус: зависимость от третьей стороны, задержка, не всегда актуальные данные (архив может быть устаревшим).

Когда НЕ стоит использовать

• Когда сайт — SPA с рендерингом на клиенте. WebFetch получит пустой каркас, потому что весь контент строится JavaScript уже в браузере — нужен headless-браузер.
• Когда нужно взаимодействие со страницей (авторизация, клики, заполнение форм, ожидание динамической подгрузки) — WebFetch делает один статичный снимок и не умеет «действовать» на странице.
• Когда сайт прямо запрещает автоматический доступ в своём robots.txt или пользовательском соглашении и правовой контекст важен (например, персональные данные, контент за платным доступом) — тут вопрос не технический, а этический и юридический: массовое автоматизированное скачивание чужого контента без разрешения может нарушать условия использования сайта и законодательство о данных.

Связанные понятия

• HTTP — протокол передачи гипертекста, поверх которого работает любой WebFetch-запрос (разбирали в архиве).
• Headless-браузер — программа, запускающая полноценный браузерный движок без графического интерфейса, для случаев, когда простого fetch недостаточно (разбирали в архиве).
• CAPTCHA — механизм проверки «человек ли перед нами», один из способов сайтов блокировать автоматические fetch-запросы (разбирали в архиве).
• Rate limiting — ограничение количества запросов от одного клиента в единицу времени, ещё один барьер против автоматизированных обходов (разбирали в архиве).
• robots.txt — файл на сайте с указанием, каким автоматическим клиентам и что разрешено читать; этичные fetch-инструменты его учитывают.
• RAG (retrieval-augmented generation) — архитектурный паттерн, в котором модель сначала находит и читает внешние документы (в том числе через fetch), а потом отвечает на их основе.

Литература и источники

• RFC 9110 «HTTP Semantics» — официальная спецификация HTTP, https://www.rfc-editor.org/rfc/rfc9110 — для тех, кто хочет понять протокол на уровне байтов запроса.
• Документация Anthropic по инструментам Claude (tool use / встроенные инструменты) — искать в Google по запросу «Anthropic Claude tool use web fetch documentation».
• Wikipedia (en): статья «Web scraping» — https://en.wikipedia.org/wiki/Web_scraping — контекст вокруг автоматического извлечения контента с сайтов, включая юридические и этические аспекты.
• Отчёты Cloudflare Radar о доле «ИИ-краулеров» в интернет-трафике — искать в Google по запросу «Cloudflare Radar AI crawlers traffic report».
• Книга «Web Scraping with Python» (Ryan Mitchell, O'Reilly, есть несколько изданий 2015–2022, en) — практическое руководство по теме извлечения контента с сайтов, включая границы между простым fetch и headless-браузером.

Где встретилось у меня

Вчера, 12 сентября, в рамках исследования порталов недвижимости для проекта novostroy.ru агент (и его саб-агенты) массово использовал WebFetch, чтобы прочитать главные страницы около тридцати мировых конкурентов — от Zillow и Rightmove до китайских и ближневосточных площадок. Значительная часть попыток упиралась в защиту от ботов (403-е ошибки, CAPTCHA), что потребовало переключаться на WebSearch как обходной путь для получения информации о фичах конкурентов.

Краткое резюме

• WebFetch — инструмент ИИ-агента для получения содержимого веб-страницы одним HTTP-запросом, без запуска браузера и без выполнения JavaScript.
• Он быстрый и дешёвый, но «слепой» к контенту, который подгружается динамически на стороне клиента (SPA-сайты).
• Отличается от WebSearch (поиск ссылок) и от headless-браузера (полноценный рендеринг и взаимодействие со страницей).
• Массовое использование подобных инструментов ИИ-агентами — одна из причин, почему сайты в 2024–2026 годах активнее внедряют антибот-защиту, CAPTCHA и rate limiting.
• При конкурентном анализе (как во вчерашнем исследовании порталов недвижимости) WebFetch — первый и самый дешёвый инструмент, но нужно быть готовым к тому, что часть сайтов он просто не «пробьёт».