При работе над алгоритмом извлечения отзывов из Telegram я дал одну задачу двум агентам. Claude Code предложил улучшения в рамках существующего алгоритма. Codex — переработать сам алгоритм. Такое расхождение в подходах стало поводом активнее использовать нескольких агентов.
Это происходило в Huginn and Muninn — исследовательском проекте по анализу сообщений Telegram с помощью LLM. Я определял бизнес-логику и критерии приёмки, совместно с агентами прорабатывал архитектуру, а реализация и тесты оставались за агентами.
Об общей организации разработки я уже писал. Здесь хочу подробнее рассказать, как предложение одного агента становилось предметом ревью другого.
Разные предложения помогают увидеть выбор
При работе над алгоритмом у меня уже были собственные идеи. Мне хотелось проверить, какие направления ещё стоит рассмотреть, и заодно сравнить работу двух агентов. Изначально я рассчитывал собрать больше вариантов, но получил концептуально разные решения: один агент предложил доработать существующую архитектуру, другой — пересмотреть её устройство.
Проверять оба варианта целиком времени не было, поэтому для дальнейшей работы нужен был один план. Я передал предложение каждого агента на ревью другому. Перекрёстное ревью и моя оценка помогли выделить общую часть, на основе которой мы составили план для дальнейшей проработки.
Как был устроен цикл ревью
Этот план я передавал агентам по очереди: каждый анализировал текущую версию и дорабатывал её. За несколько циклов обсуждения мы пришли к окончательному варианту.
Постепенно из этого сложился повторяемый порядок работы:
- Оба агента независимо готовят планы и предложения.
- Я оцениваю направление и участвую в выборе подхода.
- Агенты по очереди анализируют и дорабатывают общий план.
- Когда я считаю решение достаточно проработанным, передаю его на реализацию одному из агентов.
В такой схеме решение о том, что и как делать, остаётся за человеком. Что бы агенты ни предложили, их варианты нужно оценить и выбрать подходящий для задачи.
Больше самостоятельности можно дать агенту, когда заданы целевой показатель и все необходимые ограничения, а агент может сам измерить результат и проверить соблюдение этих ограничений. Тогда можно заняться своими делами и ждать, пока агент достигнет цели или потратит все лимиты в попытках.
Для передачи решения нужны записи
В обоих случаях агенту нужны ясная постановка задачи и явно заданные ограничения. При передаче плана на ревью к ним добавляется текущее решение. Всё это удобно сохранить в файле, чтобы следующий участник получил конкретный предмет обсуждения.
По опыту Huginn and Muninn я пришёл к тому, что ключевые требования, планы и решения полезно держать в локальных Markdown-файлах. С ними можно продолжить работу в другой сессии и передать их другому агенту.
Позже, в AI Docs Toolkit, я осознанно перенёс ведение текущих планов из удалённого таск-трекера в локальные Markdown-файлы. Их удобно передавать на перекрёстное ревью, просматривать изменения в Git и фиксировать коммитами историю решений по задаче.
Что я вынес из этого опыта
Качество алгоритма мы исследовали подробно. Я готовил итоговую разметку сообщений, а агент запускал разные варианты алгоритма и сравнивал результаты с этой разметкой. После переработки архитектуры и отладки нового варианта алгоритм стал заметно точнее.
Для меня работа с двумя агентами расширила круг вариантов. Один мог предложить направление, которое другой упустил, или помочь доработать его решение.
Чтобы агенты могли дополнять друг друга, нужны удобный способ передачи контекста и конкретно описанная задача, желательно с проверяемым результатом. Оценка предложений и выбор решения при этом остаются за мной.