Разработка ИИ-агента для обработки заявок на работу

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

Содержание

• Что такое ИИ-агент для обработки заявок и зачем он нужен
• Архитектура ИИ-агента для автоматизации обработки заявок
• Инструменты и платформы для создания ИИ-агента
• Обработка истекших сессий и восстановление состояния
• Преодоление языковых барьеров в ИИ-агенте
• Адаптация к различным структурам форм
• Тестирование и внедрение ИИ-агента
• Управление ИИ-агентом после запуска
• Лучшие практики и рекомендации

Что такое ИИ-агент для обработки заявок и зачем он нужен

Представьте: кандидат отправляет резюме на LinkedIn, Indeed, HeadHunter или корпоративный сайт компании. Каждая платформа — свой набор полей, своя логика валидации, свои подводные камни. Рекрутер вручную переносит данные из одного формата в другой, тратя часы на рутину. ИИ-агент для бизнеса берёт эту задачу на себя.

Важно понимать разницу между обычной автоматизацией и автономным ИИ-агентом. Скрипт, который заполнит одну конкретную форму — это автоматизация. А система, которая сама определяет, какую форму перед ней, какие поля куда маппить и что делать, если что-то пошло не так — это уже агент. Он принимает решения на основе контекста. Чем отличается ИИ-агент от обычного ИИ? Тем, что у него есть цель, набор инструментов и способность планировать шаги для достижения результата.

Типичный сценарий работы такого агента выглядит так:

1. Получает задачу: «Отправить резюме кандидата на вакансию X на платформе Y».
2. Авторизуется на платформе (если сессия истекла — проходит логин заново).
3. Находит нужную вакансию или форму подачи.
4. Распознаёт структуру формы — какие поля обязательные, какие нет.
5. Заполняет поля данными кандидата, адаптируя их под формат платформы.
6. Отправляет заявку и подтверждает успешность.

Звучит просто? На практике каждый из этих шагов таит в себе десяток крайних случаев.

Архитектура ИИ-агента для автоматизации обработки заявок

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

Основные компоненты системы

Оркестратор (Brain). Центральный модуль, который планирует последовательность действий, вызывает нужные инструменты и принимает решения на основе результата. Именно здесь живёт «интеллект» агента. Обычно это LLM (GPT-4, Claude, локальная модель) с подключёнными функциями (function calling / tool use).

Модуль навигации. Отвечает за взаимодействие с веб-страницами — открывает URL, кликает по элементам, прокручивает, ждёт загрузки. Реализуется на базе Playwright, Puppeteer или Selenium.

Модуль распознавания форм. Анализирует HTML-структуру страницы и определяет, где поля ввода, выпадающие списки, чекбоксы, загрузка файлов. Использует комбинацию DOM-анализа и LLM для семантического понимания.

Модуль маппинга данных. Сопоставляет стандартизированные данные кандидата (имя, email, телефон, опыт, навыки) с конкретными полями формы на текущей платформе.

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

Хранилище состояния. Сохраняет промежуточные результаты, чтобы агент мог возобновить работу после сбоя. Это может быть база данных (PostgreSQL, MongoDB) или файловое хранилище.

Схема взаимодействия

Задача → Оркестратор → [Навигация, Распознавание, Маппинг] → Результат
 ↑ |
 └──── Обработка ошибок ←───────────────────┘

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

Инструменты и платформы для создания ИИ-агента

Выбор стека зависит от бюджета, требований к безопасности и масштаба задачи. Вот основные варианты для каждого слоя.

LLM как «мозг» агента

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

Фреймворки для построения агентов

• LangChain / LangGraph — самый популярный фреймворк для создания цепочек действий и агентных систем. LangGraph особенно удобен для построения графов состояний, где агент может циклически обрабатывать ошибки.
• CrewAI — платформа для создания мультиагентных систем. Подходит, если вы хотите разделить обязанности между несколькими специализированными агентами (например, один заполняет форму, другой проверяет результат).
• AutoGen (от Microsoft) — фреймворк для создания команд агентов, которые могут общаться друг с другом.

Инструменты веб-автоматизации

• Playwright — современный, быстрый, поддерживает все основные браузеры. Идеален для навигации по веб-страницам.
• Browser Use — интересная библиотека поверх Playwright, специально созданная для LLM-агентов. Даёт агенту возможность «видеть» страницу и взаимодействовать с ней.
• Selenium — старый надёжный инструмент, но медленнее и сложнее в настройке, чем Playwright.

Платформа для создания ИИ-агента «из коробки»

Если не хочется собирать всё с нуля, существуют готовые платформы: Dify, Flowise, n8n с AI-нодами. Они позволяют визуально собрать пайплайн агента, подключить LLM и инструменты. Однако для сложной задачи с обработкой заявок на работу гибкость кастомной разработки обычно побеждает.

Обработка истекших сессий и восстановление состояния

Это одна из самых частых проблем. Агент начинает заполнять форму, и вдруг — страница авторизации. Сессия истекла. Что делать?

Стратегия предотвращения

Первое правило: храните credentials в зашифрованном виде (Key Vault, HashiCorp Vault, AWS Secrets Manager) и обновляйте токены заранее. Если платформа поддерживает long-lived tokens или API-ключи — используйте их вместо логина через браузер.

Второе правило: перед началом работы проверяйте валидность сессии. Агент должен сначала зайти на страницу профиля или сделать простой API-запрос. Если ответ — 401 или редирект на страницу логина, обновляем сессию до начала заполнения формы.

Стратегия восстановления

Если сессия всё-таки упала посреди процесса, агент должен:

1. Обнаружить проблему. Распознать, что текущая страница — это не форма заявки, а страница авторизации. LLM анализирует содержимое страницы и делает вывод.
2. Сохранить прогресс. Записать в хранилище состояния: «Я на платформе X, заполнил поля A, B, C, данные кандидата такие-то».
3. Пройти авторизацию заново. Используя сохранённые credentials.
4. Вернуться к форме. Перейти обратно к вакансии и продолжить заполнение с того места, где остановился.

Обнаружение сбоя → Сохранение состояния → Авторизация → Восстановление → Продолжение

Ключевой момент — контекстное восстановление. Агент не начинает всё с нуля, а использует сохранённый стейт. Для этого в архитектуре нужен модуль, который сериализует текущий прогресс в структурированный формат (JSON) и десериализует при возобновлении.

Ещё одна частая проблема — капчи. Cloudflare Turnstile, reCAPTCHA, hCaptcha. Здесь вариантов немного: использовать сервисы распознавания капч (2Captcha, Anti-Captcha) — это работает, но добавляет стоимость и задержку. Либо строить пайплайн через API платформы, если таковой существует, минуя браузер целиком.

Преодоление языковых барьеров в ИИ-агенте

Заявки на работу подаются по всему миру. Платформа может быть на немецком, вакансия — на английском, а данные кандидата — на русском. Агент должен справляться со всем этим.

Многоязычное распознавание форм

Когда агент попадает на страницу заявки, ему нужно понять, что означает каждое поле. «Name» — это имя. «Nom» — тоже имя, но уже по-французски. «Nombre» — по-испански. LLM справляется с этим достаточно хорошо, если в системном промпте указать:

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

Современные модели (GPT-4o, Claude 3.5) поддерживают десятки языков «из коробки». Но если вы используете локальную модель, убедитесь, что она обучена на достаточном объёме многоязычных данных.

Трансляция данных

Иногда данные кандидата нужно перевести. Например, описание опыта работы на русском — а платформа ожидает английский. Здесь агент вызывает инструмент перевода (тот же LLM с промптом-переводчиком или специализированный API вроде DeepL).

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

Обработка локализации форматов

Даты, телефоны, адреса — всё это форматируется по-разному:

• Дата: 03/09/2026 (США) vs 09.03.2026 (Россия) vs 2026-03-09 (ISO)
• Телефон: +1 (555) 123-4567 vs +7 999 123-45-67
• Адрес: порядок «улица, город, штат, индекс» vs «индекс, город, улица»

Агент должен определять ожидаемый формат по контексту формы и преобразовывать данные соответственно. Один из подходов — хранить все данные в универсальном формате (ISO 8601 для дат, E.164 для телефонов) и конвертировать при маппинге.

Адаптация к различным структурам форм

Вот где начинается настоящая магия. Каждая платформа — свой зоопарк полей, валидации и логики.

Подход на основе семантического анализа

Вместо того чтобы писать отдельный парсер для каждой платформы (что быстро становится неподдерживаемым), агент использует LLM для анализа DOM-структуры страницы в реальном времени.

Алгоритм:

1. Извлечь HTML формы (или видимый текст страницы).
2. Передать в LLM с промптом: «Вот форма заявки на работу. Определи: какие поля обязательные, какие — опциональные. Какое семантическое значение у каждого поля (имя, email, телефон, опыт, образование, портфолио и т.д.). Есть ли специфические требования (максимальная длина, формат файла)».
3. Получить структурированный ответ — JSON-схему формы.
4. Маппить данные кандидата на эту схему.

Этот подход работает удивительно хорошо для большинства платформ. LLM понимает контекст даже без явных label тегов — по placeholder’ам, соседним элементам, структуре страницы.

Обработка специфичных элементов форм

Загрузка файлов. Резюме может быть в PDF, DOCX или TXT. Портфолио — архив или ссылка. Агент должен уметь конвертировать форматы (через LibreOffice в headless-режиме или специализированные библиотеки) и проверять ограничения по размеру файла.

Мульти-селекты и тег-инпуты. «Навыки» часто реализуются как autocomplete-поле, куда нужно вводить по одному навыку и нажимать Enter. Агент должен симулировать это поведение — вводить навык, ждать появления dropdown, кликать на подходящий вариант.

Динамические формы. Некоторые платформы показывают разные поля в зависимости от предыдущих ответов. Например, если вы выбрали «Студент» — появляется поле «ВУЗ», а если «Работник» — поле «Компания». Агент должен адаптироваться: после заполнения каждого поля заново анализировать, появились ли новые.

Многошаговые формы (wizards). Заявка может состоять из 3-5 шагов с кнопками «Далее» / «Назад». Агент отслеживает текущий шаг, заполняет поля на каждом, переходит дальше, а на финальном шаге нажимает «Отправить».

Кэширование схем платформ

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

Тестирование и внедрение ИИ-агента

Тестирование ИИ-агента — это не как тестирование обычного ПО. Результат может быть непредсказуемым, и нужно убедиться, что агент ведёт себя корректно в широком спектре ситуаций.

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

Юнит-тесты для отдельных модулей: маппинг данных, конвертация форматов, распознавание полей. Здесь всё классически — фиксированные входы и ожидаемые выходы.

Интеграционные тесты на реальных (или стабильно воспроизводимых) страницах. Запускаете агента на конкретной платформе и проверяете, что заявка действительно заполнена и отправлена. Проблема — веб-страницы меняются. Решение — использовать мокированные версии страниц для стабильных тестов и периодически прогонять на реальных.

E2E-тесты с LLM-оценкой. Это самый интересный уровень. Агент проходит весь пайплайн, а другая LLM-модель оценивает качество его работы. Правильно ли заполнены поля? Не пропустил ли обязательные? Не нажал ли лишних кнопок?

Метрики качества

• Успешность заполнения (%): доля заявок, заполненных и отправленных без ошибок.
• Точность маппинга: насколько корректно данные кандидата попали в нужные поля.
• Время обработки: от получения задачи до отправки заявки.
• Количество восстановлений: как часто агенту приходилось восстанавливаться после сбоев.
• Стоимость: расход токенов LLM на одну заявку.

Постепенное внедрение

Не внедряйте агента на все платформы сразу. Начните с одной-двух, где формы наиболее стандартные. Отработайте процесс, соберите метрики, выявите проблемные места. Затем постепенно добавляйте новые платформы. На каждом этапе — мониторинг и корректировка промптов и логики.

Сначала запуск в shadow mode: агент обрабатывает заявки параллельно с человеком, но не отправляет их. Оператор проверяет и подтверждает. Когда точность достигает приемлемого уровня — переход к полуавтоматическому режиму, а затем — к полностью автономному.

Управление ИИ-агентом после запуска

Запуск — это начало, а не конец. ИИ-агент требует постоянного мониторинга и настройки.

Мониторинг в реальном времени

Дашборд, где видно:

• Количество обработанных заявок (успешных / с ошибками).
• Среднее время обработки.
• Расход токенов и стоимость.
• Типы ошибок (истёкшая сессия, капча, неизвестная структура формы).
• Оповещения при аномалиях (внезапный рост ошибок на конкретной платформе).

Обработка новых типов ошибок

Платформы обновляются. Формы меняются. Новые капчи. Агент столкнётся с ситуациями, которые не были предусмотрены при разработке. Нужен процесс:

1. Агент логирует ошибку с полным контекстом (скриншот страницы, HTML, шаги, которые привели к ошибке).
2. Человек-оператор или разработчик анализирует лог.
3. Обновляет промпты, добавляет новые правила маппинга или новые инструменты.
4. Тестирует изменение.
5. Разворачивает обновление.

Чем быстрее замыкается этот цикл, тем надёжнее работает агент.

Обучение на ошибках

Можно реализовать систему, где ошибки автоматически превращаются в обучающие примеры. Если агент неправильно распознал поле формы, этот случай добавляется в датасет для few-shot примеров в промпте. Со временем агент становится всё точнее.

Лучшие практики и рекомендации

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

Начинайте с API, а не с браузера. Многие платформы (LinkedIn, Workday, Greenhouse) имеют API или хотя бы внутренние эндпоинты, которые можно использовать вместо парсинга HTML. Это быстрее, надёжнее и менее подвержено ломкам при изменении дизайна.

Используйте retries с экспоненциальной задержкой. Сети бывают нестабильны, платформы могут временно недоступны. Три попытки с задержкой 1, 2 и 4 секунды — минимум.

Логируйте всё. Каждый шаг агента, каждый вызов LLM, каждый клик на странице. Без детальных логов отладка превращается в гадание на кофейной гуще.

Не доверяйте LLM на 100%. Добавляйте валидацию на каждом этапе. LLM сказала, что поле «Имя» найдено? Проверьте, что соответствующий элемент действительно является input/textbox. LLM заполнила форму? Проверьте, что все обязательные поля заполнены, перед нажатием «Отправить».

Бюджетируйте токены. Один вызов GPT-4o стоит копейки, но при тысячах заявок в месяц сумма набегает. Используйте более дешёвые модели для рутинных задач (распознавание простых полей) и дорогие — для сложных решений (обработка непредвиденных ситуаций).

Делайте промпты конкретными. Вместо «Заполни форму» — «Заполни поле с label “Full Name” значением “Иван Иванов”. Не нажимай Enter после ввода. Ожидай 500мс перед следующим действием». Чем точнее инструкция, тем меньше ошибок.

Источники

1. Stack Overflow — Крупнейшее сообщество разработчиков с решениями по веб-автоматизации и интеграции API: https://stackoverflow.com/
2. Browser Use — Библиотека для интеграции LLM-агентов с веб-браузером: https://github.com/browser-use/browser-use
3. LangChain Documentation — Фреймворк для создания цепочек и агентов с поддержкой function calling: https://python.langchain.com/docs/
4. LangGraph — Инструмент для построения графов состояний агентных систем: https://langchain-ai.github.io/langgraph/
5. Playwright Documentation — Документация по автоматизации браузеров для навигации и взаимодействия со страницами: https://playwright.dev/python/
6. CrewAI — Платформа для создания мультиагентных систем с разделением ролей: https://www.crewai.com/

Заключение

Разработка ИИ-агента для автоматической обработки заявок на работу — амбициозная, но вполне реализуемая задача. Ключ к успеху — модульная архитектура, где оркестратор на базе LLM управляет специализированными инструментами, а каждый модуль (навигация, распознавание форм, маппинг данных, обработка ошибок) решает свою часть проблемы. Истёкшие сессии решаются через проверку и восстановление состояния, языковые барьеры — через многоязычные LLM и нормализацию форматов данных, а разнообразие структур форм — через семантический анализ страниц в реальном времени. Начните с одной платформы, отладьте процесс, замерьте метрики — и постепенно масштабируйте. ИИ-агенты для бизнеса уже сегодня способны взять на себя значительную часть HR-рутины, освобождая людей для более важной работы.