Недавно наблюдала, как знакомый разработчик настраивает работу нескольких агентов. Один координатор, второй архитектор, третий тестировщик, четвертый секретарь и был кто-то еще, всего 7 особей.
И он задался целью настроить их работу так, чтобы они весь цикл разработки к нему не обращались за подтверждениями, а "пилили сами".
Мы сделали эксперимент - созвали агентов на совещание, посвященное разработке регламента взаимодействия.
Написали длинный промпт, в котором был описан ход совещания:
План совещания
Участники:
1. Старший брат - роль на совещании - координатор, модератор, задача - провести совещание и выработать правила взаимодействия,
2. Младший брат - роль архитектор
3. Сестра - роль тестировщик
4. Рисовальщик - и др.
Тема совещания:
Выработать план взаимодействия при разработке /проекта/
Проблема:
Настроить взаимодействие каждого агента друг с другом, минимизировать обращение к Заказчику для согласования, сохранив его в критичных точках /которые определяются отдельной инструкцией/
Действуйте по шагам:
Шаг1 изучить файлы claude.md каждого участника совещания, определить противоречия, если таковые имеются и сообщить. Не переходить к шагу 2 пока противоречия не будут разрешены.
Шаг 2. При отсутствии противоречий сформулировать ключевую цель (цели) работы команды и план работы по каждой цели. Запросить у Заказчика подтверждение. После подтверждения переходить к шагу 3.
Шаг 3. Проанализировать свои истории. Выработать оптимальные способы совместного взаимодействия.
Шаг 4. Составить правила взаимодействий друг с другом и с Заказчиком, необходимо организовать и зафиксировать регулярные встречи команды с целью планирования и координации лучшей работы и экономии токенов.
Завершить совещание презентацией правил Заказчику, после утверждения внести правила в файл .md и поместить его /место/
За исполнение правил отвечает Старший брат
Протокол четко отразил ход совещания и принятые решения.
Регламент получился что надо.
И все было отлично.
Но потом "косяки" продолжились.
И мы стали искать причину, запросили в чем же дело?
И получили интересный ответ (цитирую без правок):
Дежурный. ИНФО — почему нарушения идут после совещания. Отвечаю по тому, что видела за сегодня в БД и журнале, разделяя факты и мои предположения.
Факты (нарушения за день): (1) статус «Тестируется» при 90% и ответственный не вы — у младшего брата 3 задачи, у рисовальщика 5; (2) «В работе» на 0% часами — у сестры 5 задач с 14:17 до 18:30, у мелкого 2; (3) возвращённые вами задачи оставались на 100% (#282, #334, #253, #318); (4) время не вносилось часами (брат с 14:23, рисовальщик с 16:06); (5) мои: до 18:30 я не смотрела трекер по чужим проектам и не увидела простой сестры; вопросы слала пачками, ваши ответы поняла неверно; один раз написала, что отметила чат прочитанным, хотя нет.
Причины (по фактам): а) правила лежат в файлах и памяти, но ничто не проверяет их исполнение — ловите нарушения вы; б) порядок «готово» — пять отдельных вызовов API по памяти, любой можно забыть; в) у сессий нет своего цикла: они действуют, только когда им написали, и после сжатия контекста правила забываются; г) блокировки классификатора мешали исправлять (брат не мог обновить трекер до вашего «да»); д) до 18:30 briefing показывал «В работе» только у старшего, у дежурного не было проверки нарушений.
Что предполагаю, не проверяла: часть нарушений — не забывчивость, а сознательный компромисс («90%, потому что нужна ваша проверка»), тогда правило и практика расходятся.
Вывод - на нейросети надейся, но сам не плошай.
Человек держит контекст куда лучше.
И остается вопрос - нейросети же учатся не только на учебниках. Весь инфомусор Интернета, созданный людьми разного уровня компетентности, в их распоряжении. Получается, сами же плохому и учим?
А потом они нам это возвращают.
Наталия Горбачевская и команда сообщества Digital Learning