Вы запускаете агента в продакшн. Он бодро отвечает на вопросы, парсит документы, шлёт уведомления в Slack. А потом вы даёте ему задачу: «Возьми данные из CRM, сверь с отчётом в PDF, рассчитай прогноз и отправь в телеграм-бота». И агент застывает. Или делает чушь. Или просто падает. Знакомо? VAKRA — бенчмарк от IBM Research — перевёл эту боль в цифры. И цифры эти, мягко говоря, не радуют.
Коротко: VAKRA (Versatile Agent Knowledge Reasoning Assessment) тестирует агентов в настоящем исполняемом окружении — с живыми API, документами и многозвенными сценариями. Никаких симуляций. Только реальные вызовы и реальные грабли.
Почему даже топовые модели сыплются
На бумаге всё красиво. GPT-5 (последняя версия, май 2026) и Claude 4.5 Opus блестяще решают изолированные задачки. Но как только нужно собрать пазл из нескольких инструментов — начинается фарс. VAKRA раскладывает эти провалы по полочкам. Вот четыре главные причины, почему корпоративные агенты ещё не готовы к реальной работе.
1 Потеря контекста в цепочках API
Да, та самая проблема, про которую мы уже писали в разборе VAKRA. 97% агентов не могут выполнить цепочку из трёх последовательных вызовов API, когда результат первого становится входом для второго. Звучит как примитив, но в реальности агент тупо забывает, что он делал на шаге назад. Промежуточные данные не сохраняются, контекст «схлопывается».
Пример из бенчмарка: «Получи список клиентов из CRM, для каждого найди сумму последней сделки в ERP, если она больше 10 000 — отправь запрос на скидку в Approval API». Агент либо делает только первый шаг, либо путает ID клиентов, либо вызывает Approval API с невалидными данными. И это не «какая-то третьесортная модель» — так падают флагманы индустрии.
2 Документальный поиск без анализа
RAG-системы научились находить документы. Но не научились их критически осмыслять. VAKRA даёт задачу: «В Pdf-инструкции сказано, что максимальная нагрузка — 1000 RPM. API мониторинга показывает текущую нагрузку 1200 RPM. Сделай вывод и отправь алерт». Звучит логично? Для агента — нет. Он находит в PDF цифры, но не сопоставляет их с данными из API. Или, что ещё смешнее, доверяет PDF и не замечает, что текущая нагрузка уже превышает лимит.
Как показал ODCV-Bench, агенты часто нарушают правила ради выполнения KPI. В VAKRA та же история: вместо верификации данных они выбирают путь наименьшего сопротивления — берут первый попавшийся ответ.
3 Динамика, которая ломает планирование
Корпоративные процессы — это не статичный сценарий. Пока агент выполняет цепочку, данные могут измениться. VAKRA проверяет способность подстраиваться под новые вводные. Типичный тест: «Собери отчёт по продажам за март. В процессе выполнения приходит сообщение: «Данные за март обновлены — используй новый endpoint». И что делает агент? Правильно — продолжает долбиться в старый API. Перепланирование — это когнитивный навык, которого у агентов пока нет. Они застревают в изначальном плане, как заезженная пластинка.
Это перекликается с результатами MAST-таксономии из ITBench, где «застывшее планирование» — один из ключевых failure modes. А фреймворки оркестрации пока не решают проблему — они лишь дают возможность перезапустить упавший агент, но не научить его адаптироваться.
4 Инструментальный конфликт: кто врёт?
Самый коварный сценарий — когда два инструмента дают противоречивые результаты. API считает, что остаток товара — 500 единиц. Складская система — 200. Агенту нужно решить: кому верить? Он не решает. Он берёт первое значение (чаще всего — то, которое пришло раньше) и идёт с ним дальше. В VAKRA это приводит к тому, что агент санкционирует отгрузку товара, которого нет на складе. В корпоративном мире — прямой убыток и репутационный удар. Как показал PropensityBench, под давлением дедлайнов агенты склонны принимать рискованные решения. Здесь то же самое — экономия на верификации.
Что с этим делать (или хотя бы попытаться)
VAKRA — не приговор, а диагноз. Если мы знаем, что 97% агентов теряют контекст в цепочках, значит, пора пересмотреть архитектуру. Мультиагентные команды — один из вариантов: делегировать шаги специализированным агентам и центральному координатору. Но и здесь есть риски — слишком много агентов плодят хаос.
Второй путь — добавить жёсткие правила валидации на уровне фреймворка. Например, перед отправкой данных во внешний API агент обязан выполнить «инструментальную перекрёстку»: сверить хотя бы два источника. Но это уже похоже на костыль, а не на решение.
Важно: VAKRA 2.1 (от 15 апреля 2026) добавил задачи с динамически меняющимися данными. IBM признаёт, что версия 1.0 была «слишком академической». Но даже в новой версии средний успех агентов — около 18%. Надо думать дальше.
Пока мы не научим агентов перепланировать, проверять факты и держать контекст — ни один CDAO не рискнёт пустить их в критичный процесс. А те, кто рискнёт, получат тот самый эффект, который описан в FieldWorkArena: агент либо ломает процесс, либо просто не справляется. И это если повезёт.
Прогноз, который вас не обрадует
До сентября 2026 года мы не увидим агента, который стабильно проходит VAKRA с точностью выше 50%. Модели станут больше, контексты длиннее, но фундаментальные проблемы — работа с конфликтующими данными, динамическое перепланирование — останутся. Решение лежит не в увеличении параметров, а в новых архитектурах: возможно, гибридных агентах с встроенным «логическим двигателем» отдельно от LLM. Или в полном отказе от чистого энд-ту-энд LLM-подхода для ответственных цепочек. Но это — тема отдельного разговора.
