CordisBench — новий бенчмарк, представлений на arXiv у вересні 2026 року, перевіряє, чи здатні мовні моделі коректно міркувати про життєвий цикл компонентів у динамічних agent harness-системах. Йдеться не про те, чи модель вміє викликати інструмент або підагента, а про те, чи розуміє вона стан цього компонента в конкретний момент виконання задачі: щойно створений він, усе ще активний, чи вже знищений і його виклик небезпечний.

Для команд, що будують складні multi-component агентні системи — з підагентами, динамічними наборами інструментів, MCP-серверами, сесіями пам'яті, — це питання не абстрактне. Помилка в розумінні lifecycle означає звернення до компонента, якого вже немає в системі, або, навпаки, ігнорування щойно доданого. Обидва сценарії ведуть до непередбачуваної поведінки в продакшн-агентах, де компоненти зʼявляються й зникають на льоту, а не фіксуються заздалегідь у конфігурації.

За даними arXiv, CordisBench створено саме для перевірки цієї здатності — вміння моделі коректно міркувати про життєвий цикл компонентів у harness-системах, де набір доступних елементів агента змінюється безпосередньо під час виконання завдання, а не задається наперед одним статичним списком.

Що саме перевіряє CordisBench?

Бенчмарк оцінює, чи модель правильно відстежує статус компонента agent harness — активний, ще не ініціалізований чи вже знищений — і чи ухвалює на основі цього коректні рішення про подальші дії. Це принципово інша задача, ніж класичні agentic-бенчмарки, які здебільшого міряють, чи агент довів багатокроковий сценарій до успішного результату.

У більшості наявних тестів набір інструментів і підагентів фіксований від початку до кінця епізоду. CordisBench, за словами авторів, навпаки, змінює цей набір по ходу виконання — і саме в цій динаміці моделі найчастіше плутаються, бо їхнє внутрішнє уявлення про «доступний інструментарій» не встигає оновлюватися синхронно зі станом системи.

Чому життєвий цикл компонентів взагалі складний для LLM?

Відстеження lifecycle — це задача на memory-стан, схожа на керування ресурсами у звичайному програмуванні: об'єкт треба створити, використати, коректно звільнити. Мовні моделі тренуються переважно на статичних текстових завданнях, а не на послідовному відстеженні мінливого стану системи впродовж багатьох кроків взаємодії, тому таке «системне» міркування для них — окрема навичка, а не побічний ефект гарного розуміння мови.

Ймовірно, саме ця прогалина і стала приводом для створення CordisBench: якщо агент не бачить різниці між «компонент ще живий» і «компонент уже знищений», він або марно намагається викликати неіснуючий ресурс, або продовжує покладатися на застарілий стан, що виглядає як звичайна логічна помилка, а насправді є провалом системного, а не мовного міркування.

Кому і навіщо це важливо на практиці?

Найбільше це стосується команд, що збирають агентні пайплайни з кількома підагентами, MCP-серверами й інструментами, які підключаються та відключаються динамічно залежно від задачі. Саме там ціна помилки найвища: система не просто дає неправильну відповідь, а звертається до неіснуючого ресурсу або втрачає контроль над станом, що на проді може виглядати як зависання, дублювання дій чи тихий збій без явної помилки.

Це логічно продовжує ширшу тему оцінки агентів перед продакшном, яку ми вже розбирали в матеріалі про те, хто перевірить навички AI-агента, перш ніж він зіпсує продакшн — CordisBench додає до цієї перевірки ще один вимір: не лише «чи вміє агент виконати задачу», а й «чи розуміє він систему, всередині якої працює».

Висновок AiiN

Наша теза: поява таких бенчмарків, як CordisBench, означає зсув фокусу оцінки агентів із рівня задачі на рівень системи. Досі більшість тестів відповідала на питання «чи агент довів сценарій до результату», тепер зʼявляється питання «чи агент коректно розуміє стан інфраструктури, якою він оперує» — а це прямо впливає на те, наскільки безпечно давати агенту дедалі більше автономії в динамічних, а не заздалегідь сконфігурованих середовищах.

Що таке agent harness?

Agent harness — це середовище виконання, яке надає мовній моделі доступ до інструментів, підагентів, памʼяті та інших компонентів і керує їхнім підключенням під час роботи агента. У динамічному harness цей набір компонентів може змінюватися просто по ходу виконання задачі, а не залишатися фіксованим від старту до фінішу.

Чим CordisBench відрізняється від звичайних agentic-бенчмарків?

Класичні agentic-бенчмарки здебільшого перевіряють кінцевий результат виконання задачі агентом. CordisBench натомість фокусується на проміжному, системному аспекті — чи модель коректно відстежує стан кожного компонента harness-системи впродовж усього епізоду, що є передумовою надійної роботи в динамічних середовищах.