HTTP и веб

Три ноды на этой странице решают три разные задачи, и путать их дорого: http_request ходит в любой API как шаг графа, fetch_webpage даёт агенту прочитать страницу по уже известной ссылке, а websearch ищет в интернете и возвращает ответ модели вместе с источниками и выдержками текста из них.

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

http_request — универсальная дверь наружу

Это единственная нода, которая делает произвольный HTTP-запрос: метод, адрес, заголовки, параметры строки запроса, тело. Всё, чего в платформе нет отдельной интеграцией, делается ею — от вызова внутреннего сервиса компании до API, про которое мы никогда не слышали.

• Исполнение + данные

Что настраивается

Шаблоны и секреты

Адрес, заголовки, параметры, тело и поля авторизации проходят через шаблонизатор. То есть в них работает и {{ inputs.input }}, и {{ nodes.<id>.output.<поле> }}, и {{ secret.ИМЯ }}.

URL      https://api.example.com/v1/orders/{{ inputs.input.order_id }}
Headers  {"X-Api-Key": "{{ secret.SHOP_API_KEY }}"}
Body     {"comment": {{ nodes.llm_1.output | tojson }}}

Ключ живёт в Настройки → Секреты, а не в графе. Это не гигиена ради гигиены: граф можно экспортировать, показать коллеге или отдать ассистенту, и вставленный прямо в JSON токен уедет вместе с ним.

Что нода отдаёт дальше

Ответ приходит одним объектом. {{ nodes.<id>.output }} — это весь он целиком.

Ветка ошибки здесь включена по умолчанию

У большинства нод выход on_error выключен и включается вручную (см. Ошибки нод). У http_request он включён сразу — это единственная нода каталога с таким дефолтом, и причина в природе задачи.

Чужой сервер отвечает 500, отдаёт 429, молчит до таймаута или роняет соединение — это не поломка вашего сценария, а нормальный, ожидаемый исход обращения к чужой инфраструктуре. Если бы ветка была выключена, самый частый сбой в продукте приводил бы к одному и тому же: весь запуск падает, клиент в чате не получает ничего, а автор узнаёт об этом из списка запусков. С включённой веткой вы решаете сами — написать «сервис недоступен, попробуйте позже», сходить в резервный источник, отправить письмо себе.

• Исполнение + данные

Что именно уводит управление в ветку ошибки: сетевой сбой, таймаут, а при включённом Fail on 4xx/5xx — ещё и любой не-2xx ответ. Выключите тумблер, если код ответа для вас — данные (например, 404 означает «такого клиента нет»): тогда нода всегда уходит в успех, а вы ветвитесь по {{ nodes.<id>.output.ok }} обычным условием.

В ветку ошибки приезжает объект с кодом и текстом. Тело чужого ответа автор видит: сервис за адресом принадлежит ему, и его слова — это и есть диагноз. Собеседнику в чате оно не показывается никогда.

Куда нода ходить не будет

Все исходящие запросы платформы идут через защищённый клиент. Он резолвит имя хоста и отказывает, если адрес попадает в приватный диапазон: loopback, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local 169.254.0.0/16 (это адрес метаданных облака), multicast и зарезервированное. Перенаправления при этом отслеживаются вручную и проверяются на каждом переходе — иначе публичный адрес, отвечающий 302 на http://169.254.169.254/, обходил бы проверку целиком.

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

Через прокси

Поле Прокси (в дополнительных настройках) отправляет запрос через http://, https://, socks5:// или socks5h://. Пусто — напрямую. Поле шаблонизируется, поэтому адрес с паролем стоит держать в секрете рабочего пространства и подставлять как {{ secret.PROXY }}, а не хранить в графе.

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

fetch_webpage — чтение страницы агентом

У этой ноды нет ни входа запуска, ни выхода успеха: она существует только как инструмент агента. Поставьте её на холст, протяните tool_out в порт «Расширения агента» ai_agent — и модель сама решит, когда открыть ссылку.

Что делает: скачивает страницу, вытаскивает основное содержимое и конвертирует HTML в Markdown, отбрасывая навигацию и разметку. Модель получает читаемый текст, а не тег <div> в тысячу символов. Настройки — предел длины (по умолчанию 8000 символов, до 50 000), таймаут (по умолчанию 20 секунд) и потолок на размер сырого ответа. Предел принадлежит автору, а не модели: модель не может попросить больше, чем вы разрешили.

Проверка адресов у неё та же, что у http_request: ссылку, ведущую во внутреннюю сеть, инструмент отклоняет, и модель получает ответ «этот адрес недопустим», а не текст с внутреннего сервиса.

websearch — поиск в интернете

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

Подключается она двумя способами, и выбирает способ поле Режим работы:

• Шаг сценария — обычная нода: вход Запрос, выход Результаты поиска. Когда искать, решаете вы, а сам запрос приходит с порта или из поля настроек.
• Инструмент — расширение агента: провод link_extension в порт Расширения агента. Искать ли и что именно спросить, решает модель.

Сколько источников забирать, задаёт поле Макс. результатов: по умолчанию пять, до двадцати пяти. Режимы поиска, движки, доменные фильтры и то, как считаются деньги, — на отдельной странице «Веб-поиск».

fetch_webpage работает с поиском в паре: поиск находит страницу и приносит выдержку, а fetch_webpage дочитывает её целиком, когда выдержки мало. К агенту они подключаются одинаково, и порядок выбирает модель.

• Расширение

Что дальше