1. Почему один агент теряет нить в большом репозитории
Когда объем корпоративного кода разрастается, стандартные методы работы с ИИ-агентами начинают буксовать. Агенту приходится выполнять длинную цепочку действий: изучать файлы, запускать программу, выполнять команды, отслеживать пути выполнения и сопоставлять противоречивые данные.
Такую задачу можно сравнить с расследованием, в котором каждый новый документ способен изменить первоначальную гипотезу. Одиночный агент обычно идет по одной последовательной траектории. По мере роста контекста ему становится труднее пересматривать план, а важное открытие, сделанное в конце, не всегда влияет на уже пройденные шаги.
Именно эту проблему охватывает исследование AgentRadio: AgentRadio: Passive Awareness for Long-Horizon Multi-Agent Collaboration. Статья опубликована на arXiv 30 июля 2026 года под номером arXiv:2607.28430. Ее подготовили исследователи Coral AI Labs и нескольких университетов.
Для проверки подхода авторы использовали SWE-Atlas QnA, набор из 124 вопросов по реальным производственным репозиториям. Ответы требуют не только чтения кода, но и запуска программ и выполнения команд. В экспериментах получили следующие результаты:
- один экземпляр Claude Code на модели Opus 4.6 решил 32,3% задач;
- один агент на Opus 4.8 достиг 57,2%;
- полная конфигурация AgentRadio достигла 62,1%.
Иными словами, улучшение связано не только с переходом на более мощную модель. Важную роль сыграла архитектура взаимодействия между агентами.
2. Как AgentRadio передает находки во время работы
Разделить задачу между несколькими агентами недостаточно. Если каждый работает в собственном информационном пузыре, команда просто получает несколько независимых версий расследования. Если агенты обмениваются данными только в конце раунда, важная находка может прийти слишком поздно.
AgentRadio добавляет к рабочей среде асинхронный слой сообщений. Это похоже на внутреннюю линию связи, по которой участник может предупредить коллегу о новой улике, не прерывая собственную команду.
Система использует три базовых инструмента:
- create_thread открывает поток общения между участниками.
- send_message добавляет сообщение в поток и сразу возвращает управление отправителю.
- wait_for_mention ожидает сообщения с упоминанием конкретного агента и передает ему сообщение вместе со снимком активных потоков.
За счет этого агент может продолжать основную работу, пока фоновый наблюдатель отслеживает обращения. Такая «пассивная осведомленность» не заставляет агента постоянно останавливать выполнение команд, но дает ему шанс скорректировать следующий шаг после получения новой информации.
В типичной конфигурации отдельный сервер хранит потоки, сообщения и упоминания. Агент взаимодействует с ним через три простых сценария командной строки. Жесткое требование одно: используемая оболочка должна уметь запускать команду в фоновом режиме. При этом для подключения к существующей системе потребуется адаптер, который запускает работников, назначает им идентификаторы, соединяет их с сервером и организует итоговый синтез.
3. Что показал эксперимент и когда подход оправдан
Наиболее наглядный пример в исследовании связан с системой MinIO. Для правильного ответа агентам нужно было проверить серверные логи, хотя в первоначальном плане это не было предусмотрено. В конфигурации без асинхронной связи два агента независимо обнаружили необходимость такой проверки, но не смогли передать находку друг другу во время выполнения команд. На этапе итогового обсуждения команда выбрала неверный ответ.
В конфигурации с AgentRadio один из агентов сразу отправил сведения о логах коллегам. В описанном авторами одном задании это помогло получить 16 из 16 баллов по проверяемым критериям. Это показательный пример пользы своевременного обмена, а не общий результат всех 124 задач.
Преимущество проявилось и в общей статистике. Для Opus 4.6 показатель вырос с 32,3% до 62,1%. Для DeepSeek V4 Pro результат увеличился с 29,0% до 50,8%. При этом координация стоит дороже: средние расходы на один Opus-агент составили 2,96 доллара за задачу, а полный стек AgentRadio обходился в 19,45 доллара.
Сравнение с шестью независимыми запусками показывает, почему дополнительные расходы не сводятся к простому увеличению числа попыток. При сопоставимых расходах в 17,76 доллара независимые запуски решили 37,9% задач, тогда как AgentRadio достиг 62,1%.
Это не означает, что нескольким агентам нужно поручать любую работу. Такой подход разумен, если задача:
- затрагивает несколько частей системы, которые влияют друг на друга;
- требует независимых гипотез или проверки важных выводов;
- достаточно сложна, чтобы одиночный агент мог упустить доказательства;
- связана с высокой ценой неполного или ошибочного ответа.
Подход может быть полезен при анализе архитектуры репозитория, расследовании инцидентов между сервисами, проверке безопасности, миграции зависимостей и крупных рефакторингах. Для локального изменения в одном известном файле или генерации шаблонного кода одиночный агент обычно остается более простым и экономичным выбором.
Код для воспроизведения экспериментов опубликован в репозитории Coral-Protocol/AgentRadio на GitHub под лицензией Apache 2.0. В документации указаны требования к окружению, включая контейнеры и токены Claude. Поэтому перед внедрением стоит проверить состояние репозитория и подготовить отдельный адаптер для своей агентной оболочки. Изменять базовую модель для самой идеи асинхронного обмена не требуется, но настройка окружения и итоговой сборки результатов остаются задачей команды.
У AgentRadio есть и ограничения. Быстрая передача сообщений может отвлечь агента от правильного пути, а общая коммуникация способна распространять ошибочную гипотезу. Кроме того, агенты не всегда формулируют нужный вопрос самостоятельно. В одном из примеров с Grafana они выполнили необходимые тесты, но не сформулировали отрицательную гипотезу, поэтому обе конфигурации пропустили четыре критерия.
Практический вывод прост: сначала оцените, может ли один контекст надежно удерживать всю задачу. Если нет, а части расследования зависят друг от друга, асинхронный канал связи может дать больший прирост точности, чем очередное масштабирование модели или добавление изолированных запусков. Начать можно с небольшого воспроизводимого эксперимента на собственном репозитории и заранее установить предел расходов, правила маршрутизации сообщений и этап обязательной проверки человеком. Подробнее: Tencent открыл доступ к Team Memory: как общие знания агентов помогут вам избежать ошибок.
