Агентная система в 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 не остаются на бумаге. Они превращаются в список действий с исполнителем под каждое.

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

Собирай систему по пайплайну: spec-driven development вместо реплик в чат

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

Голосовой бриф. Надиктуй задачу через MacWhisper или Wispr Flow. Без структуры, в сыром виде, максимально подробно: что хочешь получить, зачем, для кого. Как сформулировать, что ты хочешь получить, чтобы агент шёл к результату, а не к артефакту, — в разборе метода «от конца» по докладу Ильи Красинского.

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

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

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

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

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

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

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

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

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

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

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

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

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

Если Claude Code у тебя уже стоит, его можно связать с Codex, чтобы агенты сами передавали друг другу задания, — как это сделать через терминал.

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

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