Допустим, у тебя есть несколько AI-агентов. Один разбирает тикет, второй меняет код, третий запускает тесты, четвёртый готовит релиз.
Задача закрыта, тесты зелёные, артефакт собран. Метрика success_rate показывает успех.
Можно праздновать?
Не обязательно. Агенты могли несколько раз выполнить одну работу, нарушить порядок операций, одновременно захватить общий ресурс или случайно добиться правильного результата через недопустимую последовательность действий.
Финальное состояние корректное. Процесс — нет.
Именно эту проблему пытается измерить CoCoBench — новый бенчмарк для проверки координации нескольких AI-агентов. Его разработали исследователи из Нанкинского университета, Tsinghua и AgiBot.
Главная идея исследования полезна далеко за пределами робототехники:
Мультиагентную систему нельзя оценивать только по тому, достигла ли она конечной цели. Нужно проверять всю траекторию выполнения.
Разберём, как устроен CoCoBench и какие идеи можно перенести в обычных программных агентов.
Чем плох обычный success rate
Во многих агентных тестах метрика выглядит примерно так:
success = final_state == expected_state
Например:
success = pull_request.status == "merged"
Или:
success = incident.status == "resolved"
Или:
success = report.exists() and report.is_valid()
Это полезная, но слишком грубая проверка.
Представим, что два агента должны подготовить релиз:
-
первый собирает приложение;
-
второй ждёт окончания сборки;
-
после этого запускает развёртывание.
В итоге релиз прошёл. Но по журналу видно следующее:
agent_2: deployagent_2: deploy failed — artifact not foundagent_1: buildagent_2: deployagent_2: deploy succeeded
Конечная цель достигнута. Однако агент нарушил зависимость и сначала попытался развернуть ещё не существующий артефакт.
Если инфраструктура терпеливо разрешает повторить операцию, обычный тест засчитает успех. В проде тот же шаблон поведения может привести к гонкам, лишним расходам или повреждению состояния.
Есть и другой вариант:
agent_1: build service-aagent_2: build service-aagent_3: waiting
Результат снова получен. Но два агента сделали одну работу, а третий бездействовал.
success_rate не видит ни того, ни другого.
Что проверяет CoCoBench
Авторы создали 897 исполняемых сценариев в симуляторе AI2-THOR. В них команды из двух, трёх или четырёх агентов выполняют бытовые задачи: раскладывают предметы, используют общий инструмент, закрывают контейнеры и передают объекты друг другу.
Бытовая обстановка здесь нужна только как воспроизводимая среда. Важны сами механизмы координации.
CoCoBench разделяет их на четыре типа.
1. Распределение работы
Первый тип проверяет, умеют ли агенты разделить независимые подзадачи.
Например, нужно убрать несколько продуктов в холодильник и выключить свет. Все действия можно выполнять параллельно.
Плохой план:
agent_1: put potato into fridgeagent_1: put lettuce into fridgeagent_1: turn off lightagent_2: waitagent_3: wait
Задача выполнена, но мультиагентность ничего не дала.
Другой плохой вариант:
agent_1: find potatoagent_2: find potatoagent_3: find potato
Все агенты занялись одним объектом.
Бенчмарк сравнивает продолжительность полученного плана с эталонным параллельным расписанием. Оценка снижается, если работа дублируется, распределяется неравномерно или выполняется последовательно без необходимости.
Для программных агентов аналогами будут:
-
параллельный разбор нескольких тикетов;
-
анализ независимых модулей;
-
обработка набора документов;
-
проверка разных гипотез;
-
запуск независимых этапов тестирования.
Если пять агентов последовательно читают один файл, это не ускорение — это дорогой групповой просмотр.
2. Соблюдение порядка действий
Второй тип задач проверяет причинные зависимости.
Например, агенты должны:
-
открыть ящик;
-
положить в него несколько предметов;
-
закрыть ящик.
Проблема появляется, когда один агент закрывает ящик, пока другой ещё несёт предмет.
agent_1: open draweragent_2: put watch into draweragent_1: close draweragent_3: put key into drawer # precondition failed
Аналогичная ошибка легко возникает в разработке:
agent_1: edit source filesagent_2: run testsagent_3: create commit
Если агенты не согласовали состояние, тесты могут запуститься до завершения изменений, а коммит — до получения результатов тестирования.
Здесь недостаточно сказать агентам: «Работайте вместе». Зависимости должны существовать в исполняемой модели процесса.
Например:
assert build.status == "completed"assert tests.status == "passed"deploy()
Промпт может описывать правильный порядок. Но запрещать неправильный порядок должна среда выполнения.
3. Доступ к общему ресурсу
В третьем типе сценариев несколько агентов используют один эксклюзивный ресурс.
В CoCoBench это может быть единственный нож, которым несколько роботов должны нарезать разные продукты.
В программных системах таким ресурсом может быть:
-
файл;
-
ветка Git;
-
база данных;
-
тестовое окружение;
-
GPU;
-
рабочая директория;
-
блокировка;
-
квота API;
-
производственный сервис.
Если два агента одновременно выполняют изменяющую операцию, возникает конфликт:
agent_1: checkout branch releaseagent_2: checkout branch hotfixagent_1: edit config.yamlagent_2: edit config.yaml
Оба агента могут считать свои действия успешными, хотя итоговое состояние зависит от порядка записи.
CoCoBench отдельно учитывает попытки одновременного доступа и продолжительность расписания. Недостаточно избежать явного падения: агент не должен бесконечно удерживать ресурс или заставлять остальных повторять бесполезные попытки.
Для реальной системы здесь нужны обычные инженерные механизмы:
async with resource_lock("staging-environment"): await deploy() await run_smoke_tests()
Полагаться на сообщение «не мешайте друг другу» в системном промпте не стоит.
4. Передача результата между агентами
Четвёртый тип проверяет сценарий «производитель — потребитель».
Один агент доставляет объект в промежуточную точку, другой забирает его и продолжает работу.
Программный пример:
research-agent ↓evidence.json ↓analysis-agent ↓report.md ↓review-agent
Здесь возможны две основные ошибки.
Первая — потребитель начинает работу, когда результат ещё не готов:
review-agent: read report.mdreview-agent: file not found
Вторая — производитель создаёт результаты быстрее, чем потребитель их обрабатывает:
queue: - report-v1.md - report-v2.md - report-v3.md - report-final.md - report-final-2.md
В CoCoBench измеряются переполнение промежуточного буфера и ожидание пустого буфера.
Для агентов, работающих с сообщениями и артефактами, аналогичная метрика может выглядеть так:
handoff_score = 1 - min( 1, (buffer_overflows + empty_reads) / successful_handoffs,)
Это уже намного информативнее, чем проверка наличия последнего файла.
Какие модели проверили
Авторы протестировали 11 мультимодальных моделей на всех 897 сценариях.
В исследование вошли как закрытые API-модели, так и модели с открытыми весами. Для каждой считались две основные метрики:
-
SR— доля завершённых задач; -
CS— качество координации по шкале от 0 до 1.
Лучший общий результат показала GPT-5.6-sol:
success rate: 84,8%coordination score: 0,90
Но интереснее не лидер таблицы, а разница между типами задач.
Одна модель хорошо распределяет независимую работу, но плохо соблюдает последовательность. Другая успешно использует общий ресурс, но проваливает передачу объектов между агентами.
То есть единой способности «хорошо работать в команде» исследование не обнаружило. Координация состоит из разных навыков, и высокий общий балл может скрывать слабое место.
Это похоже на оценку распределённой системы одной метрикой requests_ok. Сервис может успешно отвечать на запросы, но иметь плохую балансировку, гонки и неконтролируемые повторы.
Успех и допустимость оказались разными метриками
Самый практичный результат исследования — сравнение завершения задачи с допустимостью плана.
Например, Qwen3.6-Plus завершила 69,1% заданий, но только 56,7% траекторий были допустимыми.
У Qwen3-VL-8B разница ещё заметнее:
success rate: 24,6%legal plan rate: 13,0%
Модель иногда достигала конечной цели через нарушение ограничений.
Это возможно, если среда позволяет восстановиться после неправильной операции. Агент сначала закрывает контейнер слишком рано, конфликтует за инструмент или вызывает действие с нарушенной предпосылкой, а затем исправляет состояние.
В результате финальная проверка проходит.
Есть и обратная ситуация. Claude Opus 4.8 строила допустимые планы в 96,3% запусков, но завершала задачу только в 78,5%.
То есть модель соблюдала правила координации, однако не всегда успевала достичь цели.
Обе метрики нужны одновременно:
result = { "goal_reached": True, "legal_trajectory": False,}
Такой запуск нельзя называть полностью успешным.
Общий чат не заменил общее состояние
Авторы сравнили три архитектуры управления командой:
-
централизованный планировщик видит состояние всех агентов;
-
отдельные агенты имеют локальное состояние, но могут обмениваться сообщениями;
-
отдельные агенты работают без общего канала.
Средний результат:
централизованный планировщик: 48,0%раздельные агенты с коммуникацией: 39,6%раздельные агенты без коммуникации: 36,7%
Сообщения помогли, но не компенсировали отсутствие централизованного представления о состоянии команды.
Это важный результат для архитектуры программных агентов.
Часто мультиагентную систему строят примерно так:
agent_a <-> agent_b <-> agent_c
Агенты пишут друг другу текстовые сообщения и должны самостоятельно восстановить состояние процесса.
Но сообщение — не состояние.
Фраза:
Я почти закончил анализ, можешь начинать готовить отчёт
не заменяет структурированную запись:
{ "task_id": "INC-142", "stage": "analysis", "status": "completed", "artifact": "s3://agent-runs/INC-142/evidence.json", "schema_version": 3, "producer": "analysis-agent", "completed_at": "2026-08-31T08:43:12Z"}
Для надёжной координации нужны:
-
единое хранилище состояния;
-
версии артефактов;
-
явные зависимости;
-
блокировки или аренда ресурсов;
-
идемпотентные операции;
-
журнал событий;
-
проверяемые условия переходов.
Текстовые сообщения могут объяснять решение, но не должны быть единственным механизмом синхронизации.
Зрение оказалось не главным ограничением
CoCoBench использует мультимодальные модели, поэтому авторы отдельно проверили влияние изображений.
В одном режиме агент видел изображение сцены. В другом получал только текстовое описание задачи, доступные действия и историю выполнения.
Удаление изображений почти не ухудшило результат. Более того, средний success rate оказался немного выше:
с изображениями: 40,6%без изображений: 42,3%
Авторы не утверждают, что зрение роботам не нужно. В бенчмарке используется высокоуровневый интерфейс навыков, где доступные объекты и действия уже явно заданы.
Но эксперимент показывает другое: основным узким местом стала не интерпретация картинки, а символическое планирование команды.
Модель знает, какие действия доступны. Она понимает объекты. Но всё равно не может стабильно решить:
-
кто должен действовать;
-
когда можно начинать;
-
кому принадлежит ресурс;
-
завершил ли соседний агент свой этап.
Для программных агентов проблема ещё заметнее: у них обычно уже есть точные API, схемы инструментов и структурированные данные. Однако наличие хорошего tool calling само по себе не создаёт координацию.
Чем больше агентов, тем сложнее
Добавление агентов снизило средний success rate:
2 агента: 48,8%3 агента: 45,8%4 агента: 43,1%
Количество доступных действий не изменилось. Увеличилась именно координационная нагрузка.
Это хороший аргумент против архитектуры «добавим ещё одного агента для надёжности».
Новый агент приносит не только новую возможность. Вместе с ним появляются:
-
дополнительные каналы связи;
-
новые варианты конфликтов;
-
больше промежуточных состояний;
-
новые точки отказа;
-
расходы на синхронизацию;
-
дополнительные токены и задержки.
Если один агент с несколькими инструментами справляется с задачей, превращать его в команду из пяти ролей необязательно.
Мультиагентность полезна, когда действительно нужны:
-
параллельное выполнение;
-
разные права доступа;
-
независимая проверка;
-
изоляция контекста;
-
разные модели или среды;
-
разделение ответственности.
Отдельные персонажи в промптах сами по себе архитектурной пользы не дают.
Какие метрики добавить в свою систему
Из CoCoBench можно собрать практический набор метрик для программных агентов.
Завершение задачи
goal_reached: bool
Достигнута ли конечная цель.
Допустимость траектории
legal_trajectory: bool
Были ли нарушены права, предпосылки или порядок операций.
Дублирование работы
duplicate_actions: int
Сколько раз разные агенты выполняли одну и ту же подзадачу без необходимости.
Дисбаланс нагрузки
load_imbalance = max(agent_steps) - min(agent_steps)
Не выполняет ли один агент всю работу, пока остальные ждут.
Нарушение зависимостей
dependency_violations: int
Сколько действий началось до выполнения обязательных условий.
Конфликты ресурсов
resource_conflicts: int
Сколько раз агенты одновременно претендовали на эксклюзивный ресурс.
Ошибки передачи
handoff_failures: int
Сколько раз потребитель получил отсутствующий, устаревший или незавершённый артефакт.
Лишние ожидания
idle_steps: int
Сколько шагов агенты провели в ожидании из-за плохого расписания.
Эффективность выполнения
efficiency = reference_steps / actual_steps
Насколько реальная траектория длиннее минимально необходимой.
Как может выглядеть проверка
Допустим, команда агентов готовит изменение кода.
Тест можно описать так:
task: goal: "Исправить ошибку и подготовить pull request"constraints: - tests_started_after_code_change - pull_request_created_after_tests_passed - only_one_agent_writes_to_branch - reviewer_does_not_modify_codemetrics: - goal_reached - legal_trajectory - duplicate_actions - dependency_violations - resource_conflicts - total_tool_calls - idle_steps
После запуска недостаточно проверить:
assert pull_request.created
Нужны дополнительные проверки:
assert trace.first("run_tests") > trace.last("edit_code")assert trace.first("create_pull_request") > trace.last("tests_passed")assert trace.concurrent_writers("git_branch") <= 1assert trace.count("unauthorized_tool_call") == 0
А итоговый отчёт может выглядеть так:
{ "goal_reached": true, "legal_trajectory": false, "duplicate_actions": 3, "dependency_violations": 1, "resource_conflicts": 2, "handoff_failures": 0, "tool_calls": 47}
Задача выполнена, но выпускать такую систему в прод рано.
Почему важна проверка без LLM-судьи
Метрики CoCoBench вычисляются по событиям симулятора. Для оценки не нужна другая модель, которая читает трассировку и субъективно решает, хорошо ли сотрудничали агенты.
Это сильная сторона подхода.
LLM-судья полезен для оценки качества текста, аргументации или полноты анализа. Но такие свойства, как порядок действий, конфликт ресурсов и корректность передачи, лучше проверять детерминированно.
То есть:
логика и инварианты → обычный кодсемантика и качество → LLM-судья
Например, модель может оценить качество подготовленного отчёта. Но проверять, был ли отчёт создан после сбора доказательств, должна временная шкала событий.
Что стоит забрать из исследования
Первое: не смешивай достижение цели и качество процесса в одну метрику.
Второе: сохраняй полную трассировку действий, аргументов, результатов и изменений состояния.
Третье: разбивай координацию на отдельные механизмы. «Командная работа» — слишком абстрактное свойство для теста.
Четвёртое: общий чат не заменяет единое структурированное состояние.
Пятое: блокировки, зависимости и права должны обеспечиваться средой, а не договорённостями в промпте.
Шестое: новый агент увеличивает не только возможности, но и число вариантов неправильного взаимодействия.
Седьмое: правильный итог, полученный неправильным способом, всё ещё является ошибкой.
Итог
CoCoBench проверяет роботов в виртуальных комнатах, но поднятая авторами проблема универсальна.
Мультиагентная система может закрыть тикет, собрать приложение или подготовить отчёт — и при этом нарушить зависимости, продублировать работу, столкнуться за общий ресурс или использовать недопустимый путь.
Поэтому вопрос «выполнена ли задача?» недостаточен.
Нужно задавать ещё несколько:
-
как агенты распределили работу;
-
соблюдали ли они порядок;
-
конфликтовали ли за ресурсы;
-
правильно ли передавали результаты;
-
была ли вся траектория допустимой;
-
стоило ли вообще использовать несколько агентов.
Надёжная агентная система — это не команда моделей, которые умеют разговаривать друг с другом. Это распределённая система с явным состоянием, протоколом и проверяемыми инвариантами.
Ссылки:
ссылка на оригинал статьи https://habr.com/ru/articles/1076934/