Почему ИИ-агентам мешает общий чат и как организовать их совместную работу

Представим команду из пяти ИИ-агентов. У каждого есть доступ к общей переписке объёмом 10 тысяч токенов — условных единиц текста, за обработку которых приходится платить. Все пятеро читают одну и ту же историю, включая чужие рассуждения и промежуточные результаты. Вместо эффективного обмена знаниями получается многократная обработка одинаковой информации. К тому же ошибка одного участника может повлиять на работу остальных.

Автор статьи на Хабре, разработчик Temporality, предлагает разделить общение и выполнение задач. Агентам не нужен постоянный общий чат, если можно поручить каждому конкретную работу, определить зависимости между этапами и предусмотреть проверку результатов. В Temporality для этого созданы разные механизмы.

Первый — delegate, или делегирование. Руководящий агент поручает отдельному исполнителю исследовать API, написать код или проверить готовое решение. Исполнитель получает собственные инструкции, инструменты и ограничения, а после завершения возвращает результат. Передавать ему всю предыдущую переписку не требуется: достаточно самостоятельной и понятной постановки задачи.

При этом руководящий агент не может расширить права исполнителя простым указанием в задании. Доступ определяется настройками и правилами безопасности. В Temporality делегирование ограничено двумя уровнями, а одновременно можно запустить до восьми дочерних агентов.

Параллельная работа помогает выиграть время, но не обязательно деньги. Например, три независимых исследования по 40 секунд каждое при последовательном выполнении займут две минуты. Если запустить их одновременно, результаты можно получить примерно за 40 секунд. Однако все три агента по-прежнему расходуют токены на обработку заданий и подготовку ответов. А если они делают похожую работу, расходы могут оказаться избыточными.

Когда задачи зависят друг от друга, автор предлагает использовать plan — механизм управления последовательностью работ. Допустим, нужно добавить новую функцию в API. Сначала один агент изучает существующий интерфейс и ограничения, затем другой пишет код, третий запускает тесты, а четвёртый проверяет результат. Руководящий агент заранее описывает эту цепочку, после чего система сама запускает каждый этап, когда готовы необходимые для него данные.

Так руководителю не приходится снова обращаться к языковой модели после каждого результата, чтобы решить, кому передать работу дальше. Механизм поддерживает два режима: full, при котором система выполняет весь план самостоятельно, и wave, когда после каждого этапа управление возвращается руководителю. Первый обычно требует меньше ресурсов на координацию, второй позволяет проверить промежуточные результаты и вовремя скорректировать дальнейшие действия.

Особое внимание в Temporality уделили проверке и исправлению ошибок. Представим, что программист написал код, тестировщик его проверил, а затем другой агент обнаружил дефект и отправил реализацию на доработку. После исправления старые тесты уже ничего не доказывают: они проверяли предыдущую версию. Поэтому система отменяет актуальность зависимых результатов и запускает необходимые проверки повторно. Чтобы исправления не превратились в бесконечный цикл, число возвратов ограничено: по умолчанию двумя, максимум четырьмя.

Но не каждый вопрос требует отдельного задания. Если программисту нужно уточнить у исследователя, совместимо ли изменение API с существующей системой, достаточно адресного сообщения через ask_agent. Можно дождаться ответа или отправить запрос и продолжить работу. Второй режим используется по умолчанию: система сама доставит ответ, когда он появится, без постоянных проверок со стороны отправителя.

Даже если исследователь уже завершил свою работу, Temporality может ненадолго запустить его снова для ответа на конкретный вопрос. При этом обращаться можно только к участникам текущей совместной работы, а не к произвольным агентам системы. Сообщения поступают между рабочими шагами, чтобы не прерывать исполнителя посреди операции. Запросы, ответы и ошибки доставки сохраняются в журнале.

Есть и важное ограничение: дочерние агенты Temporality работают в общем пространстве проекта. Если двое одновременно редактируют один файл, собирают приложение или выполняют операции с Git, они могут помешать друг другу. Поэтому автор советует параллельно запускать независимые исследования и проверки, а изменения общих ресурсов выполнять последовательно.

Надёжность здесь зависит не только от выбранного способа взаимодействия. Системе нужны устойчивые идентификаторы задач, журнал событий, проверка прав, понятные правила отмены и ограничения повторных попыток. Temporality использует Temporal для сохранения состояния и восстановления работы после поддерживаемых перезапусков. Однако это не гарантирует, что внешняя операция не выполнится дважды: для таких случаев необходима отдельная защита от повторов.

Автор отдельно предупреждает, что сравнение способов взаимодействия основано на архитектурных особенностях и типичных сценариях, а не на испытаниях одинаковых моделей в одинаковых условиях. Универсально самого быстрого или дешёвого подхода нет. Если один агент способен выполнить задачу за пять шагов, привлекать ещё троих специалистов может быть бессмысленно.

Главный вывод прост: эффективная команда ИИ-агентов начинается не с общего чата, а с понятных задач, ответственности и правил передачи результатов. Разговор нужен, когда действительно требуется уточнение. Во всех остальных случаях лучше дать агентам работать.

Ранее в материале о переходе от GoClaw к Temporality рассказывалось, почему разработчик отказался от прежней архитектуры после пяти месяцев доработок.