Корректность превыше результата: новый бенчмарк CoCoBench оценивает координацию ИИ-агентов

# Агенты выполнили задачу, но процесс был испорчен: что на самом деле проверяет CoCoBench

Приветствую. В мире разработки агентных систем часто возникает иллюзия успеха: тикет закрыт, тесты зелены, релиз опубликован. Метрика success_rate горит зеленым, и команда празднует. Но статистика обманчива. За этим «зеленым» светом могут скрываться критические архитектурные дефекты: агенты могли дублировать работу, нарушать причинно-следственные связи или конфликтовать за общие ресурсы.

Исследователи из Нанкинского университета, Tsinghua и AgiBot разработали инструмент, призванный отличать результат от процесса. На его основе необходимо строить архитектуру надежных мультиагентных систем.

Проблема скрытых ошибок в метриках успеха

Стандартная проверка часто сводится к простой логической эквивалентности конечного состояния системы и ожидаемого: final_state == expected_state. Этого недостаточно. Рассмотрим типичный сценарий в разработке:

1. Агент А собирает артефакт. 2. Агент Б должен подождать сборки и затем развернуть её. 3. Агент В запускает тесты.

Если в тестовом окружении операция развертывания идиомпотентна (выполняет действие, если артефакт уже существует, и молча возвращает успех), то даже если агент Б попытался развернуть несуществующий артефакт, система засчитает успех. В продакшн-среде такая же «терпеливая» инфраструктура может привести к гонкам, лишним затратам или повреждению состояния.

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

Четыре класса проблем координации

Исследователи смоделировали 897 сценариев в среде AI2-THOR, где роботы-агенты выполняют бытовые задачи (раскладка предметов, использование инструментов). Важна не сама обстановка, а проверяемые механизмы взаимодействия. Координацию разделили на четыре ключевых типа:

1. Распределение задач (Task Allocation) Вопрос заключается в том, как агенты делят независимые подзадачи. Если нужно убрать овощи и выключить свет, и каждый агент берет на себя часть работы параллельно — это хорошо. Если же пять агентов последовательно проверяют один и тот же файл или три агента одновременно ищут один и тот же предмет, производительность не растет, а затраты ресурсов растут.

2. Порядок действий (Action Order) Проверяются причинно-следственные зависимости. Классическая ошибка: агенты не согласовали состояние перед выполнением. Пример: редактирование кода, запуск тестов и создание коммита. Если агент, создающий коммит, не дождется результатов тестов, он нарушит предпосылку (precondition). Простого запрета в промпте недостаточно; среда выполнения должна жестко контролировать порядок операций.

3. Доступ к общим ресурсам (Shared Resource) Когда несколько агентов требуют эксклюзивный доступ к одному ресурсу (файл, ветка Git, база данных, GPU). Если агент 1 и агент 2 одновременно пытаются изменить конфигурацию, возникает конфликт записи. Система не должна бесконечно блокировать ресурс или заставлять агентов повторять попытки, но полагаться на «договоренности» в промпте — ненадежно.

4. Передача результатов (Handoff) Сценарий «производитель — потребитель». Один агент генерирует отчет, второй его анализирует. Ошибка возникает, если потребитель начинает работу раньше готовности артефакта или если производитель создает больше отчетов, чем их может обработать система. Бенчмарк измеряет переполнение буферов и ложные ожидания.

Разница между результатом и допустимостью

Ключевой вывод исследования: цель достигнута (goal_reached) и план был допустимым (legal_trajectory) — это разные метрики.

Например, модель Qwen3.6-Plus завершила 69,1% заданий, но допустимый план составила только 56,7% случаев. Модель могла закрыть тикет, нарушив при этом порядок шагов, что дало верный результат в конкретной ситуации, но сделало траекторию опасной.

В обратном случае, Claude Opus 4.8 строил допустимые планы в 96,3% случаев, но успешно завершал задачу лишь в 78,5%. Здесь агент соблюдал все правила, но из-за отсутствия глобальной картины не успевал достичь конечной цели.

Архитектурные выводы

Эксперименты показали несколько важных принципов для построения агентных систем:

1. Централизованное состояние. Текстовые сообщения между агентами («Я почти закончил») не заменяют структурированное хранение состояния (task_id, stage, artifact_location). Для надежности нужны явные зависимости, версии артефактов и журналы событий. 2. Роль среды. Блокировки, условия переходов и права доступа должны обеспечиваться самой средой выполнения, а не быть описаны в системном промпте. 3. Эффективность числа агентов. Добавление новых агентов не всегда дает выгоду. Если один агент со множеством инструментов справляется с задачей, превращение его в команду из пяти ролей только усложнит координацию и увеличит риск конфликтов. 4. Визуализация вторична. В бенчмарке отсутствие изображений почти не ухудшило результаты по сравнению с их наличием. Основное препятствие для агентов оказалось не в понимании контекста, а в способности выстроить логическую последовательность действий.

Заключение

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