Claude Code: настройка, автоматизация и интеграция рабочих процессов

Основы Claude Code и настройка рабочего окружения

Представьте: вы сидите в терминале, описываете задачу обычным языком — и через минуту получаете готовый SQL-запрос, отформатированный отчёт или рабочий код. Без переключения между 15 вкладками браузера, без ручного копирования данных из API. Именно так работает Claude Code — AI-агент, который живёт в вашем терминале и взаимодействует с реальными инструментами: файлами, shell-командами, веб-поиском и внешними сервисами.

Это не чат-бот и не автодополнение кода. По сути, Claude Code — это цикл while True в терминале: получил задачу, выбрал инструмент, выполнил, оценил результат, решил следующий шаг. И так до завершения. Инструменты при этом настоящие: доступ к файловой системе, выполнение bash-команд, веб-поиск, подключение через MCP-серверы к базам данных и API.

Установка и первый запуск

Claude Code устанавливается через npm как глобальный пакет. Для работы потребуется подписка: Pro-план за 20 долл. в месяц подходит для знакомства и простых задач, а Max-план за 100 долл. снимает лимиты на использование.

Установка занимает одну команду:

После установки заходите в директорию проекта и запускаете:

Ключевой момент: вы запускаете агента внутри директории проекта. Claude Code видит файлы этой директории и может с ними работать — читать, редактировать, запускать тесты. Это фундаментальное отличие от облачных чат-интерфейсов: агент имеет прямой доступ к вашему коду.

Три уровня настройки окружения

Настройка Claude Code строится на трёх уровнях, каждый из которых решает свою задачу.

Глобальные настройки пользователя

Файл ~/.claude/settings.json хранит ваши личные настройки, которые применяются ко всем проектам. Здесь задаются предпочтения по языку, разрешения на выполнение команд и параметры поведения агента.

Этот уровень подходит для вещей, которые не зависят от конкретного проекта: общие разрешения, язык интерфейса, настройки MCP-серверов в области user.

Настройки проекта

Файл .claude/settings.json в корне проекта определяет правила для конкретного кодовой базы. Именно здесь вы указываете, какие команды разрешены, а какие — нет.

Этот файл можно закоммитить в репозиторий — тогда все члены команды получат единообразные настройки. Локальные переопределения хранятся в .claude/settings.local.json, который не попадает в контроль версий.

Файл CLAUDE.md

Третий и самый важный уровень — файл CLAUDE.md в корне проекта. Это не конфигурация в привычном смысле, а операционная система для агента: он читает его при каждом запуске и использует как инструкцию по работе с вашим проектом. Подробно о содержании и структуре CLAUDE.md — в следующей статье курса.

Рабочие режимы и базовые команды

Claude Code работает в нескольких режимах, которые переключаются по мере необходимости.

Интерактивный режим — вы запускаете claude и общаетесь с агентом в терминале. Это основной режим для разработки: вы описываете задачу, агент читает файлы, пишет код, запускает команды, показывает результат.

Одноразовый режим — claude -p "описание задачи". Агент выполняет задачу и завершает работу. Удобно для автоматизации в скриптах и cron-задачах.

Файловый ввод — claude -f file.txt. Агент читает задачу из файла. Полезно, когда инструкция слишком длинная для одной строки.

Базовые команды внутри сессии:

| Команда | Действие | |---------|----------| | /help | Справка по доступным командам | | /mcp | Статус подключённых MCP-серверов | | /compact | Сжатие контекста для экономии токенов | | Ctrl+C | Отмена текущего действия | | Ctrl+D | Выход из сессии |

Права доступа и безопасность

Claude Code может выполнять произвольные shell-команды — это мощно, но требует осторожности. Система прав работает по принципу белого списка: каждое действие запрашивает разрешение, если оно не разрешено заранее.

При первом запуске вы увидите запросы вида:

Выбор always добавляет правило в настройки проекта. Можно настроить права и заранее, через файлы настроек. Критически важно: никогда не разрешайте rm -rf, curl с незнакомыми URL или любые команды, которые отправляют данные наружу, без явного контроля.

Для продвинутых сценариев доступен режим --dangerously-skip-permissions, который отключает все проверки. Он оправдан только при запуске в изолированном окружении (контейнер, виртуальная машина) или при полном доверии к задаче.

Практический сценарий: настройка под маркетинговый проект

Допустим, вы ведёте блог и SMM-каналы. Ваша директория проекта выглядит так:

Настройка .claude/settings.json для этого проекта:

Теперь запускаете claude внутри content-hub/ и можете просить: «Прочитай черновики в blog/drafts, найди статьи без SEO-мета-тегов и добавь их по шаблону из social/templates/meta.md». Агент работает только с файлами проекта и не может случайно удалить что-то или отправить данные наружу.

Частые ошибки при первой настройке

Запуск не из директории проекта. Если запустить claude из домашней директории, агент увидит все ваши файлы, но не будет понимать контекст проекта. Всегда запускайте из корня нужного проекта.

Игнорирование CLAUDE.md. Без этого файла агент работает «вслепую» — не знает структуру проекта, стандарты кода, договорённости команды. Даже минимальный CLAUDE.md с описанием структуры каталогов в разы повышает качество ответов.

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

Отсутствие MCP-серверов. Claude Code без MCP ограничен файлами и shell. Даже один подключённый сервер (например, GitHub или PostgreSQL) открывает принципиально новые сценарии автоматизации. Подключение MCP-серверов — тема пятой статьи курса.

Что дальше

Вы настроили базовое окружение: установили Claude Code, определили права доступа, подготовили структуру проекта. Теперь агент может безопасно работать с вашими файлами. Но чтобы он работал осмысленно — понимал стандарты, контекст и правила вашего проекта — нужен CLAUDE.md. Именно этому посвящена следующая статья.

Управление контекстом через CLAUDE.md и правила

Почему один и тот же агент в одном проекте пишет код в вашем стиле, а в другом — выдаёт чужеродные конструкции с нестандартным форматированием? Разница — в контексте. И ключевой инструмент для его передачи — файл CLAUDE.md в корне проекта. Это не промпт и не конфигурация в привычном смысле. Это операционная система для агента: он читает его первым делом при каждом запуске и строит всю работу по записанным там правилам.

Структура эффективного CLAUDE.md

CLAUDE.md — это Markdown-файл без жёсткого формата. Нет обязательных секций или синтаксиса. Но практика показывает, что эффективные файлы содержат определённые блоки.

Описание проекта и архитектуры

Первый блок — краткое описание того, что представляет собой проект и как он устроен. Это помогает агенту понимать контекст принятия решений.

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

Стандарты кода и соглашения

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

Для маркетинговых проектов аналогичный блок может содержать стандарты оформления контента:

Структура каталогов

Третий блок — карта проекта. Агент видит файлы, но не всегда понимает логику организации. Явное описание экономит десятки итераций «ищи файл в другой папке».

Запреты и ограничения

Четвёртый блок — красные линии. Что агент не должен делать ни при каких обстоятельствах.

Иерархия CLAUDE.md: от глобального к локальному

Claude Code поддерживает несколько файлов CLAUDE.md, расположенных на разных уровнях. При запуске агент читает их все, от самого широкого контекста к самому узкому.

Глобальный — ~/.claude/CLAUDE.md. Ваши личные предпочтения, которые применяются ко всем проектам. Например, предпочитаемый язык общения, общие стандарты оформления или привычки форматирования.

Проектный — CLAUDE.md в корне репозитория. Основной файл, описывающий проект. Именно он задаёт архитектуру, стандарты и структуру.

Локальный — CLAUDE.local.md в корне. Личные дополнения к проектному файлу, которые не коммитятся в репозиторий. Удобно для временных инструкций или экспериментов.

Вложенный — CLAUDE.md в подкаталогах. Правила для конкретного модуля или компонента. Например, blog/CLAUDE.md может содержать специфические требования к оформлению статей, а social/CLAUDE.md — правила для постов в соцсетях.

Агент читает файлы сверху вниз: глобальный → проектный → локальный → вложенный. Правила из более узкого контекста дополняют (или переопределяют) правила из более широкого.

Динамический контекст: инструкции внутри задач

CLAUDE.md задаёт статический контекст — правила, которые не меняются от задачи к задаче. Но часто нужно передать агенту контекст конкретной задачи. Для этого существуют несколько приёмов.

Встраивание в промпт. Самый простой способ: вы описываете контекст прямо в задаче. «Используя шаблон из templates/article.md, напиши статью про тренды SMM в 2026 году. Целевая аудитория — маркетологи среднего звена.»

Файлы-справочники. Создайте в проекте файлы с часто используемой информацией и ссылайтесь на них в задачах. Например, docs/brand-voice.md с описанием тона бренда или docs/seo-checklist.md с чек-листом оптимизации.

Параметр --append-system-prompt. Для одноразовых запусков можно добавить инструкции к системному промпту:

Практический кейс: CLAUDE.md для маркетингового агентства

Вот реальный пример CLAUDE.md для агентства, которое ведёт блоги и соцсети для клиентов:

Такой файл превращает агента из универсального помощника в члена команды, который знает стандарты, процесс и ограничения.

Поддержание CLAUDE.md в актуальном состоянии

CLAUDE.md — живой документ. Он теряет ценность, если устаревает. Практические рекомендации по поддержанию:

Обновляйте при изменениях процесса. Добавили новый инструмент в стек — обновите архитектурный блок. Изменили стандарты форматирования — поправьте соответствующую секцию.

Просите агента помогать. После нескольких сессий можно спросить: «Какие правила из CLAUDE.md ты используешь чаще всего? Какие инструкции были неполными?» Агент даст обратную связь, которая поможет улучшить файл.

Храните версии в git. Поскольку CLAUDE.md коммитится в репозиторий, его история изменений показывает, как эволюционировали стандарты проекта.

Ограничивайте объём. CLAUDE.md.consume часть контекстного окна агента. Оптимальный размер — 100–200 строк. Если файл разрастается, вынесите детали во вложенные CLAUDE.md или в отдельные файлы-справочники и ссылайтесь на них.

Что дальше

CLAUDE.md задаёт контекст и правила. Но повторяющиеся сценарии — создание контент-планов, SEO-аудит, написание постов по шаблону — требуют не просто правил, а готовых инструкций, которые агент выполняет по запросу. Такие инструкции называются Skills, и им посвящена следующая статья.

Создание Skills для маркетинга и разработки

Каждый день вы выполняете одни и те же действия: составляете контент-план, пишете SEO-описания, делаете ревью кода по чек-листу, генерируете отчёты. CLAUDE.md задаёт правила, но не даёт готового рецепта выполнения конкретного сценария. Для этого существуют Skills — Markdown-файлы с инструкциями, которые превращают повторяющиеся задачи в вызываемые по имени операции.

Что такое Skill и как он работает

Skill — это .md файл в каталоге ~/.claude/skills/ (глобальный) или .claude/skills/ (проектный). Никакого SDK, API или сборки. Вы пишете инструкции на Markdown, и агент следует им, когда тема задачи совпадает с содержанием скилла.

Механизм прост: при запуске Claude Code сканирует каталоги со скиллами и загружает их содержимое в контекст. Когда вы формулируете задачу, агент проверяет, есть ли среди загруженных скиллов релевантная инструкция, и применяет её.

Анатомия хорошего скилла

Скиллы, которые реально работают, имеют определённую структуру. Разберём на примере скилла для SEO-аудита статьи.

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

Скиллы для маркетинга

Генерация контент-плана

Написание постов для соцсетей

Скиллы для разработки

Ревью кода по чек-листу

Генерация шаблонов кода

Семь ошибок при создании скиллов

Практика показывает семь типичных проблем, которые делают скиллы бесполезными или вредными.

Слишком общие инструкции. «Напиши хороший текст» — не скилл, а пожелание. Конкретизируйте: длину, структуру, формат, критерии качества.

Отсутствие триггеров. Если в скилле не указано, когда его применять, агент может не догадаться его использовать. Явно опишите ключевые слова и сценарии.

Смешение нескольких задач в одном скилле. Один скилл — одна задача. SEO-аудит и написание статьи — это два разных скилла.

Игнорирование формата вывода. Без указания формата агент выдаст результат в произвольном виде. Фиксируйте структуру отчёта или результата.

Слишком длинные скиллы. Содержимое скилла consumes контекстное окно. Оптимальный размер — 50–200 строк. Если скилл длиннее, разбейте на несколько или вынесите справочные данные в отдельные файлы.

Отсутствие примеров. Примеры входных и выходных данных резко повышают точность. Даже один пример лучше, чем его отсутствие.

Неточная формулировка шагов. «Проверь качество» — непонятно. «Проверь, что title содержит ключевое слово и не длиннее 60 символов» — конкретная инструкция.

Управление скиллами

Скиллы не требуют установки или активации — они работают автоматически. Но управлять ими нужно.

Глобальные vs проектные. Скиллы в ~/.claude/skills/ доступны во всех проектах. Скиллы в .claude/skills/ — только в конкретном проекте. Используйте глобальные для универсальных задач (SEO-аудит, ревью кода) и проектные для специфичных (генерация контента для конкретного клиента).

Версионирование. Проектные скиллы можно коммитить в репозиторий. Так вся команда получает одинаковые инструкции. Глобальные скиллы — личные, их стоит хранить в отдельном репозитории или dotfiles.

Тестирование. После создания скилла проверьте его работу: запустите Claude Code и дайте задачу, которая должна триггерить скилл. Если агент не применяет инструкции — уточните триггеры или переформулируйте шаги.

Что дальше

Скиллы автоматизируют повторяющиеся сценарии, но они работают в рамках одного контекста — одного «головного» агента. Когда задача сложная и включает несколько независимых подзадач (сбор данных + анализ + написание отчёта), эффективнее делегировать их параллельно. Для этого существуют субагенты — тема следующей статьи.

Делегирование задач субагентам и автоматизация процессов

Представьте, что вам нужно проанализировать активность клиентской базы за квартал: выгрузить данные из CRM, провести когортный анализ, построить воронку конверсий и написать итоговый отчёт. Если делать последовательно — уйдёт полдня. Но если разбить на три независимых потока и запустить параллельно — задача решится за 20 минут. Именно это делают субагенты в Claude Code.

Что такое субагенты

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

Это принципиально отличается от того, как работает один агент в одиночку. Один агент — один контекст. Если контекст переполняется, качество ответов падает. Субагенты решают эту проблему: каждый работает в изолированном контексте, не засоряя контекст главного агента промежуточными данными.

Механизм делегирования

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

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

Практический кейс: анализ маркетинговых данных

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

Главный агент разбивает это на три субагента — по одному на клиента. Каждый работает со своим CSV-файлом, своим шаблоном и своим выходным файлом. Параллельно. Через 5 минут все три отчёта готовы.

Практический кейс: разработка с ревью кода

Для разработчиков субагенты особенно ценны в сценариях, где написание кода и его проверка должны быть независимыми.

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

Субагенты vs Skills: когда что использовать

Скиллы и субагенты решают разные задачи, хотя иногда их путают.

| Критерий | Skills | Субагенты | |----------|--------|-----------| | Назначение | Инструкция для повторяющегося сценария | Изолированный поток для подзадачи | | Контекст | Общий с главным агентом | Свой изолированный контекст | | Параллельность | Нет — последовательное выполнение | Да — несколько субагентов одновременно | | Когда использовать | Стандартная процедура (аудит, шаблон) | Сложная задача, разбиваемая на части |

Правило простое: если задача стандартная и повторяющаяся — скилл. Если задача сложная и разбивается на независимые подзадачи — субагенты. Часто они работают вместе: субагент применяет скилл в своём изолированном контексте.

Teams: именованные агенты для долгих проектов

Помимо ad-hoc субагентов, Claude Code поддерживает Teams — несколько именованных агентов с общим списком задач, работающих над одним проектом. Это более структурированный подход для масштабных задач.

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

Автоматизация через cron и скрипты

Субагенты мощны в интерактивном режиме, но真正的автоматизация начинается, когда Claude Code работает без вашего участия. Для этого используются одноразовый режим и внешние планировщики.

Ежедневный отчёт через cron

Скрипт следит за каталогом incoming/. Когда появляется новый файл, запускается агент для его обработки. Это работает для любых входящих данных: CSV-файлов, JSON-экспортов из CRM, документов.

Интеграция с мессенджерами

Один из самых мощных сценариев — запуск агента по сообщению в мессенджере. Серверный агент, который работает 24/7, может читать сообщения из Telegram, интерпретировать задачу и запускать субагентов для её решения.

Архитектура: бот в Telegram получает сообщение → передаёт его Claude Code → агент анализирует и выполняет → результат возвращается в Telegram. Такой агент становится полноценным членом команды, который доступен круглосуточно.

Управление контекстом при делегировании

Субагенты решают проблему переполнения контекста, но создают новую: как передать им нужную информацию без дублирования?

Файлы как канал связи. Главный агент записывает промежуточные данные в файлы, субагенты читают их. Это надёжнее, чем передача данных через промпт.

CLAUDE.md как общий контекст. Субагенты тоже читают CLAUDE.md. Если там описаны стандарты и структура проекта, субагенты будут им следовать без дополнительных инструкций.

Skills как инструкции. Если субагенту нужна конкретная процедура (например, формат отчёта), подключите соответствующий скилл. Субагент применит его в своём контексте.

Ограничения и подводные камни

Субагенты — мощный инструмент, но с ограничениями.

Зависимости между подзадачами. Если подзадача B зависит от результата подзадачи A, их нельзя запустить параллельно. Главный агент должен сначала дождаться A, потом запустить B.

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

Сложность отладки. Если субагент вернул неправильный результат, разобраться сложнее: вы видите только итог, а не промежуточные шаги. Для отладки используйте явные инструкции по логированию в файлах.

Что дальше

Субагенты позволяют делегировать задачи внутри Claude Code. Но что, если нужные данные или инструменты находятся вне вашего проекта — в базе данных, в CRM, в мессенджере, в системе мониторинга? Для интеграции с внешними сервисами существуют MCP-серверы и хуки — тема финальной статьи курса.

Интеграция с внешними сервисами через MCP и хуки

Claude Code умеет читать файлы и выполнять shell-команды. Но ваша работа не ограничивается локальной файловой системой: данные лежат в PostgreSQL, задачи — в Jira, ошибки — в Sentry, обсуждения — в Slack. Без интеграции с этими сервисами агент остаётся отрезанным от реального рабочего процесса. MCP-серверы и хуки — два механизма, которые соединяют Claude Code с внешним миром.

MCP: универсальный разъём для внешних сервисов

Model Context Protocol — открытый стандарт, который позволяет подключать внешние инструменты к AI-агенту через единый интерфейс. Представьте его как USB-C для AI: один разъём, через который подключается что угодно — базы данных, API, мессенджеры, системы мониторинга.

Архитектура проста: Claude Code выступает в роли MCP-клиента, а внешний сервис оборачивается в MCP-сервер. Сервер exposes инструменты (tools), ресурсы (resources) и шаблоны промптов (prompts), которые клиент может вызывать.

Три типа возможностей MCP-сервера:

| Тип | Что делает | Пример | |-----|-----------|--------| | Tools | Выполняют действия | Запрос к БД, отправка сообщения, создание задачи | | Resources | Предоставляют данные для чтения | Конфигурация, документация, профили пользователей | | Prompts | Шаблоны взаимодействия | Чек-лист ревью, формат баг-репорта, шаблон отчёта |

Tools — самый используемый тип. Когда вы спрашиваете «какие ошибки в проде за последние сутки?», агент вызывает tool get_errors у Sentry MCP-сервера.

Установка первого MCP-сервера

Добавление MCP-сервера — одна команда. Вот как подключить GitHub:

Для локальных серверов, которые запускаются как процессы на вашей машине:

Обратите на синтаксис: все флаги (--transport, --env, --scope) идут перед именем сервера, а -- отделяет имя от команды запуска. Это предотвращает конфликты между флагами Claude и флагами сервера.

После добавления проверьте статус:

Или внутри сессии Claude Code — командой /mcp.

Области видимости: local, project, user

MCP-серверы можно настраивать на трёх уровнях, и выбор уровня критически важен для командной работы.

Local (по умолчанию) — хранится в ~/.claude.json под путём проекта. Доступен только вам и только в текущем проекте. Подходит для экспериментов и серверов с чувствительными учётными данными.

Project — хранится в .mcp.json в корне репозитория. Коммитится в git, доступен всей команде. Используйте для серверов, которые нужны каждому: Sentry, база данных проекта, внутренний API.

User — хранится в ~/.claude.json глобально. Доступен во всех ваших проектах. Подходит для личных утилит: GitHub, Notion, Slack.

При конфликте имён приоритет: local > project > user. Это позволяет команде共享 базовую конфигурацию через .mcp.json, а каждому разработчику — переопределить отдельные серверы локально.

Практические MCP-серверы для разных ролей

Для маркетолога

PostgreSQL — прямой доступ к данным аналитики:

Теперь можно спросить: «Найди 10 пользователей, которые не заходили 30 дней, и сгенерируй re-engagement email для каждого» — агент напишет SQL, получит данные и подготовит письма.

Slack — уведомления и взаимодействие с командой:

Агент может отправить готовый контент-план в канал, уведомить о завершении отчёта или найти обсуждение по теме.

Для разработчика

GitHub — управление репозиторием из терминала. Ревью PR, создание issues, поиск кода — без переключения в браузер.

Sentry — мониторинг ошибок в проде:

«Какие ошибки появились после последнего деплоя?» — агент проверяет Sentry, находит регрессии, связывает их с конкретными коммитами.

Playwright — автоматизация браузера для тестирования:

Для управления проектами

Linear/Jira — связь задач с кодом. Агент может взять описание задачи из трекера, реализовать фичу и обновить статус — в одном сессии.

Построение собственного MCP-сервера

Community-серверы покрывают популярные сервисы. Но когда нужна интеграция с внутренним API или специфическим инструментом, приходится строить свой сервер.

MCP-сервер — это Node.js-приложение, которое использует официальный SDK. Минимальный пример:

Ключевые правила при написании сервера:

Хуки: автоматические действия на события

MCP-серверы расширяют возможности агента — что он может делать. Хуки расширяют поведение агента — что происходит автоматически при определённых событиях.

Хук — это shell-команда, которая срабатывает на события внутри Claude Code: перед коммитом, после вызова инструмента, при доступе к определённым файлам.

Предохранитель от слива секретов

Самый частый сценарий — блокировка коммитов с чувствительными файлами:

Когда агент редактирует тестовый файл, хук автоматически запускает тесты. Результаты подхватываются агентом для дальнейших решений.

Уведомления о завершении задач

Когда длительная задача завершается, хук отправляет уведомление в Slack. Вы можете отойти от компьютера и узнать о результате через мессенджер.

MCP + хуки: связка для полной автоматизации

Отдельно MCP-серверы и хуки полезны. Вместе они создают полноценный автоматизированный конвейер.

Сценарий: автоматический деплой с проверкой качества.

Весь процесс — от написания кода до уведомления команды — без вашего участия.

Сценарий: ежедневный маркетинговый отчёт.

Управление контекстом при множестве MCP-серверов

Каждый MCP-сервер загружает описания своих инструментов в контекст агента. При 3–4 серверах это 50 000–100 000 токенов — значительная часть контекстного окна.

Tool Search — встроенная функция, которая решает эту проблему. Она динамически загружает описания инструментов только тогда, когда они действительно нужны, а не заранее. Экономия: до 85% контекста.

Tool Search требует модели Sonnet 4 или позже. На моделях Haiku недоступен.

Диагностика проблем с MCP

Самые частые ошибки и их решения:

«Connection closed» — Claude Code не может найти исполняемый файл сервера. Причина: окружение запуска subprocess отличается от вашего терминала. Решение: используйте абсолютные пути или добавьте cmd /c на Windows.

Сервер запускается, но tools не появляются — инструменты зарегистрированы после вызова server.connect(). Переместите registerTool() перед connect().

SyntaxError: Cannot use import statement — отсутствует "type": "module" в package.json сервера.

Логи засоряют протокол — вы используете console.log вместо console.error. Замените все вызовы: stdout зарезервирован для JSON-RPC сообщений.

Для глубокой диагностики включите отладку протокола:

Итог: агент как член команды

За пять статей курса мы прошли путь от установки Claude Code до построения полноценного автоматизированного конвейера. Резюме ключевых принципов:

CLAUDE.md — задаёт контекст и правила. Агент, который знает ваш проект, работает в разы эффективнее.

Skills — превращают повторяющиеся задачи в вызываемые операции. Один раз написали инструкцию — используете бесконечно.

Субагенты — позволяют делегировать сложные задачи параллельным потокам. Время выполнения сокращается пропорционально количеству потоков.

MCP-серверы — соединяют агента с внешним миром: базами данных, API, мессенджерами, системами мониторинга.

Хуки — добавляют автоматические проверки и действия на каждом этапе workflow. Без них автономная работа агента небезопасна.

Вместе эти механизмы превращают Claude Code из инструмента «вопрос-ответ» в автономного члена команды, который понимает ваши стандарты, работает с вашими инструментами и выполняет рутину без вашего участия.