10.09.2026

Как собрать агентный парсер, который проверяет код на реальных ответах API

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

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

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

Почему генерации кода недостаточно

Парсер работает не с описанием API, а с конкретными данными. В документации поле может называться items, а в ответе оказаться вложенным в data.products. Сервер может вернуть строку вместо числа, ограничить размер страницы или потребовать заголовок авторизации. Иногда успешный HTTP-ответ содержит сообщение об ошибке, а нужные данные появляются только после нескольких шагов.

Если модель не запускает написанный код, она не видит эти расхождения. Результат приходится проверять вручную:

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

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

Из чего состоит агентный цикл

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

создать или изменить файл с кодом;
выполнить команду в изолированной среде;
отправить HTTP-запрос к разрешённому адресу;
прочитать ответ и логи;
проверить результат по заданной схеме.

Логика цикла выглядит так:

ТЗ → план → код → запуск → ответ или ошибка
                 ↑              ↓
                 └── исправление ←

В техническом задании стоит явно описать входные данные, ожидаемую схему результата, допустимые адреса, правила авторизации, лимиты запросов и критерии готовности. Например, недостаточно написать «забрать каталог». Лучше указать: получить все страницы, сохранить идентификатор, название, цену и остаток, преобразовать цену в число, пропустить позиции без идентификатора и вернуть массив объектов в заданном формате.

Structured output важнее красивого объяснения

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

{
  "tool": "run_code",
  "arguments": {
    "file": "parser.py",
    "timeout_seconds": 30
  }
}

Инструмент возвращает результат отдельно:

{
  "ok": false,
  "exit_code": 1,
  "stdout": "",
  "stderr": "KeyError: 'products'"
}

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

Как сформулировать критерий готовности

Агент не должен останавливаться на первом ответе без ошибки. У него должен быть проверяемый критерий завершения. Для парсера это может быть набор условий:

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

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

Выбор модели для разных этапов

В Протоке можно разделить задачи по стоимости и сложности. Для первичного анализа схемы, преобразования полей и написания вспомогательных функций подойдёт GLM-5.2: на дату публикации его котировка составляет 3,66 ₽ за 1M входных токенов и 11,50 ₽ за 1M выходных.

Для агентного цикла важнее не только цена, но и стабильность работы с инструментами. В качестве одного из вариантов можно использовать GPT-5.6 Luna — 5,09 ₽ за 1M входных и 30,50 ₽ за 1M выходных токенов на дату публикации. Для более сложных технических заданий доступны GPT-5.6 Terra: 8,42 ₽ за 1M входных и 50,49 ₽ за 1M выходных токенов на дату публикации.

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

Для отдельных этапов можно выбрать GLM-5.3 Flash. Его котировка на дату публикации — 11,76 ₽ за 1M входных и 39,18 ₽ за 1M выходных токенов. Расходы списываются по факту за каждый запрос, поэтому архитектуру удобно разделять: недорогую модель использовать для рутинных преобразований, а более мощную подключать к отладке сложных случаев.

Пример подключения через API

Проток совместим с OpenAI и Anthropic SDK: достаточно заменить base_url на адрес Протока и передать ключ из кабинета. Подробности подключения приведены в документации: https://dualchat.pro/docs?utm_source=blog&utm_medium=article&utm_campaign=agentnyj-parser-s-proverkoj-api

# Клиент OpenAI SDK, совместимый с API Протока
client = Client(
    api_key="sk-dc-...",
    base_url="https://dualchat.pro/v1"
)

response = client.chat.completions.create(
    model="glm-5.2",
    messages=[
        {
            "role": "system",
            "content": "Ты агент, который пишет и проверяет парсеры. "
                       "Используй инструменты только в структурированном формате."
        },
        {
            "role": "user",
            "content": "Собери каталог по заданной схеме и проверь пагинацию."
        }
    ]
)

print(response.choices[0].message.content)

В параметре model указывается slug модели из котировок, а не отображаемое название. Ключ вида sk-dc-… создаётся в кабинете в разделе «Ключи». Пополнить баланс можно картой онлайн, по счёту для организации или через СБП.

Безопасность песочницы

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

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

Вывод

Агентный парсер — это не «модель, которая пишет код», а замкнутый процесс проверки: постановка задачи, генерация, запуск, наблюдение и исправление. Такой подход особенно полезен при подключении каталогов, нестабильных API и источников с неодинаковой структурой данных.

В Протоке можно собрать этот сценарий через единый API, выбрать модель под этап работы и оплачивать только фактические запросы. Посмотрите актуальные котировки и подключите первый прототип на сайте: https://dualchat.pro?utm_source=blog&utm_medium=article&utm_campaign=agentnyj-parser-s-proverkoj-api

← все материалы