Агентная система в Claude Code: как собрать команду агентов для анализа отчётов

Агент — это LLM, инструменты и цикл

Когда ты пишешь Claude, ChatGPT или Gemini в веб-версии, модель отвечает на вопрос и останавливается. Сама по себе LLM — ядро будущей системы, но ещё не агент. Никита Велс, который занимается автоматизацией бизнес-процессов с 2020 года, раскладывает агента на три части:

1. LLM — мозг, который рассуждает.
2. Инструменты (tools) — конкретные действия, которые модель умеет выполнять. Например, записать данные в Google Таблицу.
3. Цикл (loop) — механизм, который позволяет вызвать инструмент, получить результат и вызвать снова, пока цель не достигнута.

Цикл нужен даже на простой задаче. Загрузить отчёт из Word или Markdown в таблицу за один вызов часто не выходит: агенту нужно понять структуру таблицы, найти нужные листы, залить данные несколькими партиями. Без цикла модель делала бы один шаг и ждала следующей команды от человека. С циклом она действует сама: действие → ответ → следующее действие, пока работа не закончена.

Агентная система — это архитектура, а не код

В вайб-кодинге ты ставишь задачу — сервис, сайт, скрипт — и пишешь код с помощью агента. Результат — код. В агентной системе ты проектируешь, как агенты связаны между собой: кто какие данные получает, кому передаёт результат, в каком порядке они действуют. Ты пишешь не столько код, сколько инструкции.

По словам Никиты, это два разных навыка. Уверенный вайб-кодер не становится автоматически архитектором агентных систем.

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

Не заливай все отчёты в один чат

Типичная попытка: закинуть в чат отчёты по продажам, рекламе, финансам и конкурентам и попросить стратегию. Ответ получается либо поверхностным, либо контекст переполняется.

Причина — в контекстном окне, «оперативной памяти» модели. Даже при лимите в миллион токенов качество падает по мере того, как окно заполняется. Никита приводит такие оценки:

• около 200 тысяч токенов — точность примерно 96%;
• около 500 тысяч — примерно 80%;
• ближе к миллиону — теряется до 50–70% ценной информации.

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

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

Стадия 1, Analytics: один агент — один отчёт

Архитектура, которую показал Никита, делит работу на три стадии. Первая — аналитика.

Вместо одной модели, которая переваривает всё сразу, работают несколько узкоспециализированных агентов:

• аналитик продаж смотрит только продажи;
• аналитик рекламы — только рекламу;
• аналитик финансов — только финансы;
• аналитик конкурентов — только конкурентов.

Каждый получает ровно свой объём данных. Окно не перегружено, роль чёткая, и точность, по оценке спикера, держится близко к максимальной — условно на 95%. Агент продаж копает глубоко именно в продажах и не отвлекается на остальное. На выходе — детальный отчёт по каждому направлению вместо общей сводки обо всём.

Стадии 2 и 3: стратег ищет причины, исполнители действуют

Stage 2, Synthesis. Агент-стратег берёт отчёты аналитиков, ищет между ними связи и докапывается до первопричин. Пример из доклада: один рекламный канал просел — маленькая маржа, низкий ROI. Стратег идёт в отчёты аналитиков и выясняет, где причина: в самом канале, в рекламной стратегии целиком или в продукте — офферах, тарифах, актуальности для аудитории. Такой глубины, по словам Никиты, не даст ни одна нейросеть, в которую всё загрузили одним пакетом.

Stage 3, Actions. Стратег передаёт эстафету агентам-исполнителям. Каждый получает конкретную задачу:

• поднять рекламную ставку;
• переработать скрипты продаж;
• довести сайт до нужного состояния.

Сюда же можно отнести агентов, которые проверяют работу сотрудников: какие задачи выполнены на деле, а не по регламенту. Главное — выводы Synthesis не остаются аналитикой в вакууме. Они превращаются в список действий с исполнителем под каждое.

Итоговая цепочка выглядит так: аналитики по отчётам → стратег → исполнители, а оркестратор маршрутизирует запросы внутри групп.

Собирай систему по пайплайну, а не репликами в чат

«Накидать задачу в чат и понадеяться», по словам Никиты, в 99% случаев даёт результат, который не устраивает. Разработка превращается в бесконечную цепочку правок. Поэтому он собирает системы по пайплайну из открытого набора скиллов Мэтта Покока (Matt Pocock), а раньше пользовался фреймворком Superpowers. Шаги такие.

Голосовой бриф. Надиктуй задачу через MacWhisper или WhisperFlow. Без структуры, в сыром виде, максимально подробно: что хочешь получить, зачем, для кого.

Хочу собрать агентную систему для [компания или проект].
Что должно получиться на выходе: [результат — например, список действий по итогам анализа отчётов].
Зачем: [какая проблема сейчас не решается].
Для кого: [кто будет пользоваться результатом].
Какие данные есть: [отчёты по продажам, рекламе, финансам, конкурентам — где лежат, в каком виде].
Всё, что ещё приходит в голову: [сырые мысли, без структуры].

Grill Me. Скилл (в некоторых версиях — Grilling) задаёт уточняющие вопросы по брифу, пока не сложится чёткая конфигурация проекта. По ходу он подсказывает варианты, которые изначально не приходили в голову. Сам скилл, по словам Никиты, занимает буквально пару строк.

Вот мой бриф: [текст голосового брифа].
Задавай мне уточняющие вопросы по одному, пока не сложится чёткая конфигурация проекта.
Предлагай варианты, которые я мог не учесть.

ToSpec. Все ответы из Grill Me упаковываются в одну спецификацию — PRD, product requirements document. Смысл — письменно зафиксировать, каким должен получиться результат, до начала разработки. Без этого легко потерять фокус и получить не то, что планировал.

Собери все ответы из нашего обсуждения в единую спецификацию (PRD) проекта [название].
Опиши, что именно нужно построить, чтобы спецификацию можно было разбить на отдельные задачи.

ToTickets. Спецификация обычно слишком большая для одного контекстного окна — та же проблема, что и с отчётами. Скилл нарезает её на файлы-тикеты: в каждом одна фича или функция. Получается пошаговый to-do план.

Implement. Тикеты по очереди запускаются через скилл Implement: он сам реализует функцию, сам проводит код-ревью, сам тестирует и переходит к следующему тикету. Прогресс виден по каждому тикету.

Нарежь спецификацию [файл спецификации] на отдельные файлы-тикеты: один тикет — одна фича или функция.
Затем бери тикеты по очереди: реализация → код-ревью → тестирование → следующий тикет.

Короткие промпты здесь — не лень, а выбор. Полгода-год назад, говорит Никита, модели приходилось загонять в жёсткие рамки длинными инструкциями. Топовым моделям сейчас лучше дать свободу рассуждать: подробные рамки их скорее ограничивают.

Дай системе учиться и открой её команде

Eval-петля. Когда агенту указывают на ошибку, он исправляет не только текущий отчёт, но и переписывает промпт, по которому работает сам. По словам Никиты, так система учится на своих ошибках без ручной правки инструкций каждый раз.

Доступ для команды. Не каждый сотрудник умеет работать с VS Code и Claude Code, настраивать прокси и VPN, разбираться с оплатой API. Для этого Никита сделал Wells Cloud — веб-интерфейс на сервере компании, под капотом которого работает Claude Code с уже подключёнными MCP-серверами, CLI-инструментами, скиллами и агентами. Снаружи это обычный чат. Сотрудник заходит по логину и паролю с любого устройства, а в админ-панели каждому можно разграничить доступ к файлам и проектам. Если собираешь такое у себя, сверь схему с условиями тарифа: личные подписки рассчитаны на одного человека, для команды есть командные тарифы и API.

Сам Wells Cloud тебе не обязателен. Важен принцип: систему, которой пользуется одна команда, стоит упаковать так, чтобы её настройка не была заботой каждого сотрудника.

С чего начать сегодня

Вопросы и ответы