Режим команды агентов
Ну что, будущее наступило, я сейчас описал команду, базовые роли, и дал продуктовую задачу. Сижу и наблюдаю, как они пишут спеки, дополняют требования, а вот сейчас пошли писать код, по расписанной продуктовой и системной аналитике, по разделенным на стори фичам, с описанными DoD’ами и полной аналитикой по UX
Как это работает: основной агент, может создавать агентов, делегировать им задачи, и коммуницировать с ними. У них есть общий список задач и агенты могут переписываться между собой (у них условный аналог почты). Ты основному агенту описываешь состав команды и говоришь — спавни (либо он может предложить сам решить задачу командой агентов, если посчитает, что задача этого стоит. И дальше начинает их тимлидить
Какие в целом причины выделять в агентов отдельные роли:
1. Фокусировка. Агенты, когда работают над задачей или список гипотез начинают тяготеть к одной из гипотез или к одному аспекту. Например ты скажешь ему «проверь прозводительность, безопасность и следование архитектуре». Он сделает первое хорошо, а остальное «по остаточному принципу. И чтобы повысить качество решения надо дать три задачи раздельно (прям как у людей)
2. Создание противоречия. Разработчик хочет побыстрее написать код, безопасник хочет, чтобы код был безопасным, QA — чтобы приложение работало. Они все три находятся в противоречии — выделив в отдельные роли и заставив их совместно работать, дебатируя и ищя консенсус мы повышаем качество результата (да-да, снова как и у людей)
3. Ограничение контекстного окна. Модель ограничена, нельзя дать ей весь проект целиком. Она в голове может удержать ограниченное количество данных, поэтому когда мы работаем тестировщиком, мы держим одни данные, а аналитиком — другие. Опять за счет фокуса на конкретной задаче снижаем объем данных, которые нужно держать «в голове» — а это, опять же, повышает внимание модели к деталям (чем меньше контекст, тем больше внимания. Опять же, как у человеков)
4. Конвергенция организационных паттернов (извините 🤓). Мы, как человеки, десятилетиями накапливали паттерны, которые повышают качество результата: продуктовые и функциональные требования, декомпозиция на стори таски, DoR/DoD, выделения ролей и границы ролей. Мы лечили проблемы человеков, а оказалось, что агенты страдают этими же проблемами. Оказалось закон Конвея имеет обратную силу (оказывается, что сама природа сложной задачи требует определенной организационной структуры)
5. Качество. Если хотим, например, чтобы на каждую аналитику приходил дизайнер и дополнял, и QA дополнял ее DoD’ами и писал план тестирования и сценарии для e2e/unit, которые должны быть покрыты
Короче, все как всегда. Вы думали будет «тык» и магия? Хрен. Проектируй процесс, ответственности, требования, гайдлайны, накапливай успешные решения и практики, применяй, анализируй, добавляй недостающие, выкидывай ненужное. Чем сложнее систему строишь, тем дороже потом её содержать, но тем выше качество по нужным тебе аспектам. Все как всегда свелось к простому — хочешь чтобы было красиво, трать ресурс на красиво, хочешь еще безопасность, бери в команду безопасника
Официальная дока: https://code.claude.com/docs/ru/agent-teams
П.С. Забавный факт, я попросил создать просто Software Engineer роль, но агент решил выделить отдельно фронтендера и бэкендера. Штош
Добавить комментарий