LinkedIn Hiring Assistant: как устроен агент для поиска, оценки и сопровождения кандидатов

Задача: помочь рекрутеру довести поиск до результата

Работа рекрутера сочетает решения, требующие понимания людей и вакансии, с повторяющимися операциями. Для одной позиции приходится сформулировать требования, найти несколько групп потенциальных кандидатов, сопоставить их опыт с критериями, подготовить сообщения и возвращаться к списку по мере появления новых людей. Hiring Assistant берёт на себя значительную часть поиска, оценки и коммуникации, чтобы рекрутер мог больше заниматься отношениями с кандидатами и решениями о найме.

Сложность возникает не в отдельном запросе к поиску. Вакансию нередко описывают неполно, результаты требуют проверки по контексту, а длительная работа должна продолжаться между диалогами. Поэтому LinkedIn рассматривала Hiring Assistant прежде всего как продукт: с понятным взаимодействием, работающими действиями внутри Recruiter, контролем качества и надёжным выполнением задач.

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

Три способности, без которых агент не был бы полезен

Первое требование — работа с большим пространством кандидатов. LinkedIn указывает более 1,2 млрд профилей в своей сети: это доступный масштаб профессионального графа, а не число профилей, которые обработал конкретный экземпляр Hiring Assistant. Поиск и оценка должны выдерживать тяжёлые фоновые задания с производительностью и надёжностью, приемлемыми для корпоративного продукта.

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

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

Экземпляр агента, сообщения и отдельные инструменты

Hiring Assistant построен поверх платформы жизненного цикла агентов, управляемой сообщениями. У каждого рекрутера есть отдельный экземпляр Hiring Assistant со своей идентичностью и собственным почтовым ящиком сообщений — mailbox. Система доставляет агенту события и ответы асинхронно; жизненный цикл не привязан к одному открытому HTTP-запросу или одному непрерывному разговору. Так можно сочетать разговор с рекрутером и задачи, которые продолжаются в фоне.

Рабочие действия выполняются через инструменты, то есть программные интерфейсы привычных функций LinkedIn Recruiter. Среди них поиск людей, управление вакансиями и кандидатами, задачи по найму, отправка сообщений, уточнение требований и получение данных из когнитивной памяти. Такие интерфейсы работают без необходимости вручную открывать и переключать страницы продукта.

Часть функций выделена в специализированных подагентов. Но для упрощения реализации LinkedIn представляет их именно инструментами центрального агента: подагент не получает собственного независимого идентификатора и почтового ящика. Это важная граница между отдельным Hiring Assistant для рекрутера и его внутренними исполнителями.

Рисунок 1 показывает, как запрос проходит через настройку среды, планировщик supervisor, выбор доступных инструментов и список задач. Для одной задачи включается подагент, который может последовательно вызывать инструменты; затем supervisor пересматривает оставшийся план. Синие стрелки обозначают путь запроса, красные — возврат к пользователю после завершения или необходимости человеческого участия. Схема объясняет управление работой, а устройство доставки сообщений остаётся за пределами рисунка.

Почему одного цикла ReAct оказалось недостаточно

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

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

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

План сначала, действия по шагам

LinkedIn выбрала Plan-and-Execute: сначала компонент Planner разбивает цель на понятные подзадачи и составляет план, затем Executor выполняет его по шагам. Внутри конкретной подзадачи исполнитель по-прежнему может работать как ReAct: оценить локальный результат, вызвать подходящий инструмент и продолжить. Такое разделение сохраняет гибкость при выполнении, но не заставляет одну длинную цепочку рассуждений одновременно помнить всю работу по вакансии.

На рисунке 3 показаны последовательность Plan → Task Plan → Execute → Tools и обратная петля replanning. Исполнитель возвращает результат, после чего план можно пересмотреть, сохранив оставшиеся действия. Общая схема Hiring Assistant дополнительно показывает выход к человеку, когда работа завершена или требует решения рекрутера. Схема объясняет, почему отдельную подзадачу можно закончить или переоценить, не теряя из виду общий план вакансии.

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

Два режима общения с рекрутером

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

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

Рекрутер не должен постоянно управлять каждым инструментом. Вместо этого он подключается там, где требуется уточнение, одобрение или решение. В публикации этот принцип назван human-in-the-loop: человек остаётся в контуре действий, за которые несёт ответственность. Для оценки кандидатов отдельно закреплено, что решение о продвижении по найму принимает рекрутер.

Таким образом, скорость диалога и скорость массового поиска — разные требования. Интерфейс должен оставаться отзывчивым, даже когда длительная задача ещё выполняется, а результаты должны быть доступны в момент, когда человек к ним возвращается.

Как агент получает рабочий контекст и управляет интерфейсом

Hiring Assistant использует общую агентную платформу LinkedIn: на ней размещены повторно используемые компоненты для работы агентов. Поверх неё действует клиентский SDK, встроенный в интерфейс Recruiter. SDK передаёт агенту актуальный контекст работы рекрутера: система ориентируется на те же данные и состояние рабочей области, которые доступны человеку. Это позволяет продолжать разговор о текущей вакансии или кандидате без нового пересказа каждого действия.

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

Связь между интерфейсом и серверной частью организована через GraphQL. Сервер возвращает дополненные модели представления — структурированные данные вместе с метаданными, которые нужны компоненту для отображения. Такой способ строить интерфейс по данным сервера или агента LinkedIn называет server-driven и agent-driven UI (SDUI/ADUI). В результате компоненты могут меняться вместе со сценарием работы, а не только вслед за жёстко заданным экраном.

Почему события важнее ожидания одного ответа

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

Клиент подписывается на темы своего агента по каналу реального времени на уровне сессии. По модели публикации и подписки (publish–subscribe) он получает уведомления, изменения задач и обновления интерфейса. Если языковая модель выполняет длинную операцию, ответ можно показывать частями: рекрутер видит движение задачи и предварительные результаты, не дожидаясь полного завершения.

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

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

Supervisor управляет запросами, исполнителями и решениями человека

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

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

Когда требуется контроль или утверждение, supervisor показывает соответствующую задачу рекрутеру. После ответа человека работа может продолжиться с учётом обновлённого контекста. Так планирование остаётся в центре процесса, а отдельные подагенты выполняют ограниченные части работы. Подагенты представлены инструментами supervisor, поэтому не следует мысленно строить для каждого отдельную независимую систему переписки с пользователем.

Какие задачи выделены в специализированные агенты

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

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

Сначала договориться, кого именно ищем

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

Для подготовки квалификаций он может опираться на подробности вакансии, удачные прошлые проекты рекрутера, сведения LinkedIn Economic Graph и общие знания. Это важно, потому что поиск по одному названию должности плохо выражает реальные ограничения: даже одинаково названные роли отличаются необходимым опытом и условиями работы.

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

Оценка кандидата должна показывать, на чём основан вывод

После согласования критериев evaluation agent сопоставляет их с информацией о конкретном кандидате. Он изучает профиль LinkedIn, резюме, сведения о предыдущем взаимодействии и другие доступные данные, ищет подтверждения выполнения каждого требования и формирует структурированную рекомендацию. Важно не просто назвать человека «подходящим», а показать рекрутеру, какие сведения подтверждают конкретную квалификацию.

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

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

Как совместить качество оценки, масштаб и короткое ожидание

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

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

Чтобы рекрутер быстро увидел результат и мог скорректировать критерии, команда применяет дообученные модели в собственной системе выполнения LLM со спекулятивным декодированием (speculative decoding). Эта техника ускоряет генерацию, предлагая варианты продолжения для быстрой проверки основной моделью. По заявлению авторов, оценка кандидата занимает секунды; это качественная характеристика отклика без точного перцентиля и методики замера.

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

От подходящих профилей к переписке и первичному скринингу

После поиска и оценки остаётся связаться с людьми. Candidate outreach agent может подготовить и отправить первоначальные сообщения и напоминания по разным каналам. В переписке он отвечает на вопросы о вакансии, опираясь на требования и ответы на типичные вопросы (FAQ), собранные при уточнении позиции. Через сообщения он также может согласовать время телефонного знакомства.

Следующую часть работы поддерживает candidate screening agent. Он подготавливает вопросы с учётом вакансии и профиля человека, может наблюдать за беседой, переводить речь в текст и составлять краткое содержание с заметками о кандидате. Это помогает рекрутеру вернуться к важным деталям разговора, не превращая каждое собеседование в ручную стенографию.

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

Поиск кандидатов как последовательность стратегий

Поиск специалистов требует знания рынка и умения переводить требования в разные способы отбора. Sourcing agent использует уже существующие инструменты LinkedIn Recruiter Search и Recommended Matches, а не заменяет всю поисковую систему одной языковой моделью. Он создаёт несколько запросов, запускает их, сохраняет потенциально подходящие профили и возвращается к формулировкам, если результаты не соответствуют задаче.

В набор стратегий входят логические запросы с условиями И/ИЛИ/НЕ (Boolean search), запросы, которые составляет LLM по требованиям вакансии, и история прежних поисков рекрутера как исходная подсказка. Последний источник помогает начать не с пустого листа: агент может использовать проверенные в работе формулировки, а затем изменить их с учётом новых обстоятельств.

Критическое ограничение — разделение данных заказчиков. LinkedIn прямо отмечает, что sourcing agent не использует клиентские данные за пределами соответствующего заказчика. Это относится и к поисковым стратегиям, построенным на исторических действиях; персонализация одного рекрутера не означает свободный обмен конфиденциальными данными между компаниями.

Как данные о рынке труда меняют область поиска

Поиск по профилям — лишь часть доступной информации. LinkedIn использует Economic Graph: представление связей и изменений на рынке труда, а также LinkedIn Talent Insights. На их основе агент может рассуждать не только о конкретных ключевых словах, но и о том, где вообще сосредоточены подходящие специалисты и какие перемещения происходят между компаниями.

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

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

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

Почему оценка меняет следующий поисковый запрос

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

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

Это рабочий цикл внутри поиска по вакансии: поиск → оценка → уточнение запроса → новый поиск. Он отличается от длительного обучения персональных предпочтений, где анализируются действия рекрутера на протяжении разных проектов. В статье не приводится отдельный эксперимент, измеряющий прирост качества именно от этого цикла, поэтому его роль объясняется архитектурой.

Как система учится на действиях рекрутера

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

Сначала агент опирается на прямые инструкции и исправления. Затем он постепенно адаптирует рекомендации, сопоставляя новые события с предыдущими решениями. Для опытного пользователя LinkedIn Recruiter отправной точкой может быть история работы ещё до его первого разговора с Hiring Assistant: это помогает не начинать персонализацию каждый раз с нуля.

Вспомогательные ML-инструменты анализируют действия как во время работы, так и асинхронно, пытаясь отделить устойчивые предпочтения от случайных событий. В случае необходимости learning agent обращается к когнитивной памяти, чтобы восстановить прежнее объяснение выбора или повторяющуюся особенность вакансий. История и события влияют на рекомендации; это не означает, что каждое действие немедленно переобучает основную языковую модель.

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

Зачем понадобилась когнитивная память

В ходе длительного найма информация распределяется между диалогами, действиями и проектами. Рекрутер уже мог объяснять, почему один профиль не подходит, или уточнять особенности похожей вакансии. Без устойчивого контекста агенту пришлось бы постоянно спрашивать одно и то же. Для этого LinkedIn выделила cognitive memory agent — компонент, способный сохранять и находить относящиеся к задаче воспоминания.

В общей архитектурной схеме отдельно указан инструмент Fetch Cognitive Memory Tool (CMA). Supervisor и специализированные функции могут получать через него нужный прошлый контекст; learning agent обращается к памяти, когда текущего события мало для понимания предпочтений. Память поддерживает принятие более согласованных решений по текущей задаче, а не заменяет поиск по профилям или оценочную модель.

Изоляция здесь является частью архитектуры продукта. LinkedIn заявляет, что содержимое памяти остаётся в среде рекрутера, клиент может управлять сохранёнными сведениями, а данные памяти не используются для обучения LLM. В этой статье показаны роль памяти в действиях Hiring Assistant и заявленные правила обращения с данными. Устройство хранилища и алгоритм поиска воспоминаний авторы здесь не раскрывают.

Первая опора качества: правила и допустимость действий

Качество Hiring Assistant — это не только отсутствие технических сбоев. Агент должен делать полезные выводы по данным кандидатов, соблюдать требования безопасности и законодательства и действовать в допустимых пределах. LinkedIn называет первую часть своей системы контроля product policy: набор ограничений, который определяет минимально приемлемое поведение модели и связанных с ней инструментов.

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

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

Вторая опора качества: проверка людьми и их поведением

Human alignment в описании LinkedIn означает согласование поведения агента с задачами реальных рекрутеров. Для этого команда использует данные, проверенные людьми: размеченные наборы примеров и фактические действия в Recruiter. Если рекрутер заинтересовался кандидатом и вступил с ним во взаимодействие, такое действие рассматривается как сильный положительный сигнал для дальнейших рекомендаций.

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

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

Что удалось построить и как понимать заявленные результаты

В инженерной публикации LinkedIn представила Hiring Assistant как агентный продукт, прошедший путь от работы с ранними заказчиками до глобальной доступности. Описаны разделение на планировщик и исполнителя, фоновая работа с поиском и оценкой, живое обновление интерфейса и персонализация на основе действий рекрутера. Авторы подчёркивают, что результат возник благодаря совместной разработке продукта, моделей, инфраструктуры и пользовательского опыта.

Заявленный масштаб сети — более 1,2 млрд профилей, не объём обработки агентом. Отдельно упомянуты фоновые задачи по миллионам профилей, ежедневное обновление списков, непрерывная оценка новых откликов и оценка кандидатов за секунды с собственными LLM. Численных сравнений качества, задержки, стоимости или доли успешно завершённых задач статья не приводит. Нет в ней и измеренного прироста откликов, наймов, скорости закрытия вакансий либо A/B-сравнения ReAct с Plan-and-Execute.

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

Итог: как Hiring Assistant ведёт задачу рекрутера

LinkedIn построила Hiring Assistant вокруг длительной работы по вакансии. Экземпляр агента закреплён за рекрутером, получает сообщения и координирует инструменты через supervisor. Разделение планирования и исполнения позволяет управлять последовательностью действий, а интерфейс показывает происходящее, пока поисковые и оценочные задачи выполняются в фоне.

Персонализация работает рядом с этим процессом: learning agent анализирует действия рекрутера, а cognitive memory возвращает нужный прошлый контекст. Это не обучение LLM во время обработки каждого запроса. Качество контролируют проверкой допустимости критериев, тестовыми сценариями оценки, правилами поведения и подтверждёнными людьми сигналами.

Статья демонстрирует архитектуру действующего продукта, но не количественное превосходство над ReAct или прирост наймов. Масштаб в 1,2 млрд профилей относится к сети LinkedIn. Главный урок — сочетать автономное выполнение повторяющейся работы с понятным состоянием задач, доказательствами по кандидатам и решениями, которые остаются за рекрутером.