HEAR открывает агентной обвязке состояние движка модели

Агентные системы можно ускорить без смены модели и логики задач, если обвязка и движок выполнения модели обмениваются сведениями о ходе процесса и состоянии ресурсов. В препринте Harbin Institute of Technology (Shenzhen), который не рецензирован и содержит замеры самих авторов, протокол HEAR ускорил исследовательский сценарий до 2,45 раза. Для собственной инфраструктуры это превращает границу между оркестратором и сервером модели из простого API вызова в контур управления.

Как HEAR соединяет два неполных представления

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

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

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

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

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

Обратная связь помогает и очереди, и выбору режима

HEAR проверили на SCBench, Mooncake, BrowseComp-Plus и DeepResearchBench при параллельных запросах и ограниченной памяти. Первые два сценария показывали координацию очереди и кэша во время работы, вторые — подбор режима выполнения под роли исследовательского агента.

На SCBench защищённое ожидание вместе с планированием по состоянию кэша ускорило обработку пакета в 1,61 раза. Медианное время до первого токена, то есть ожидание начала ответа, сократилось в 2,23 раза. Защита не позволяла кэшированным запросам бесконечно обходить остальные.

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

В исследовательских сценариях основной агент и подагенты получали разные режимы. На BrowseComp-Plus сочетание vLLM для основного агента и H2O для подагентов ускорило весь прогон в 1,23 раза. Для DeepResearchBench лучше подошла другая связка — OmniKV и H2O; именно она дала результат, вынесенный в лид.

Эти замеры проводили с GLM-4.7-Flash, отдельными GPU H100 для ролей и исходной оркестрацией задач. Конфигурации заранее выбрали на этапе настройки и зафиксировали перед основной проверкой. Сравнением служили обычная очерёдность запросов для экспериментов с кэшем и vLLM для обеих ролей в исследовательских задачах; заметного ухудшения качества ответов не обнаружили.

Командам нужен контракт, а не ещё один планировщик

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

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

Показанные ускорения нельзя переносить на любой агентный продукт как готовый коэффициент. Выигрыш зависел от длины генерации, повторного использования контекста, роли агента и цели оптимизации. Например, применение конфигурации BrowseComp-Plus к DeepResearchBench увеличивало полное время работы на 14%, хотя обе задачи использовали одну архитектуру обвязки.

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

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

Источники

• Can Agent Harnesses and Inference Engines Hear Each Other? The HEAR Protocol for Agentic LLM Serving

Иллюстрация: рисунок из статьи «Can Agent Harnesses and Inference Engines Hear Each Other? The HEAR Protocol for Agentic LLM Serving», Jiaqi Zhao, Haodong Chen, Jitai Hao и др., CC BY 4.0