Как взаимодействуют компоненты Claude Code: Skills, подагенты, MCP, хуки, плагины.

Что такое Claude Code с архитектурной точки зрения

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

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

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

CLAUDE.md: постоянный контекст проекта

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

• Фреймворк: Playwright с TypeScript
• Тесты интерфейса запускаются с помощью npm run test:e2e, тесты API — с помощью npm run test:api
• Учетные данные никогда не сохраняются в коде в виде жестко заданных значений
• Каждый новый конечный пункт API требует наличия тестов на отрицательные сценарии

Это позволяет инженерам не объяснять одни и те же правила снова и снова. Можно рассматривать этот файл как ответ на вопрос «Как работает этот проект?»

В этом файле должны храниться стабильные знания, необходимые Claude для постоянного использования: правила работы с репозиториями, требования к тестированию, принципы архитектуры, команды для сборки, правила нумерации, требования к безопасности и привычки команды. Он не должен превращаться в обширный руководство с пошаговыми инструкциями для каждой возможной задачи. Удобным критерием разделения является то, что файл CLAUDE.md описывает, что должен знать Claude о проекте, тогда как элементы типа Skill указывают, как выполнять определенный вид работы. Разделение этих элементов облегчает их обслуживание и сохраняет четкость контекста.

Skills: повторно используемые навыки

Навык представляет собой повторно используемые знания в виде рабочего процесса. Он может включать инструкции, скрипты и дополнительные ресурсы для выполнения специализированных задач: тестирования API, проверки кода, оценки безопасности, рефакторинга, создания документации или тестирования на регрессию. Однократное описание рабочего процесса позволяет избежать постоянных объяснений одной и той же задачи Claude. Навык отвечает на вопрос о том, как выполняется такая работа.

Например, навык тестирования API может последовательно проходить через следующие этапы:

1. Определение контракта API.
2. Проверка уже существующих тестов.
3. Создание положительных сценариев.
4. Создание отрицательных сценариев.
5. Создание граничных случаев.
6. Запуск тестов.
7. Анализ сбоев.
8. Составление отчета.

При поступлении запроса вроде «добавить покрытие регрессионными тестами для API оплаты» этот инструмент не сразу приступает к написанию кода тестов. Он применяет стандартную методологию тестирования, благодаря чему каждый API проходит тестирование согласно одним и тем же организационным стандартам.

CLAUDE.md против инструментов Skills

Разница заключается в контексте и процедуре. Файл CLAUDE.md описывает проект: тесты API выполняются с использованием Playwright, каждый эндпоинт требует негативного тестирования, учетные данные берутся из переменных окружения. Инструмент тестирования API описывает процедуру: анализируется контракт, генерируются положительные, негативные и граничные тесты, они выполняются, а сбои классифицируются. Один описывает, что агенту необходимо знать, а другой — как ему выполнять работу.

Подагенты: делегирование специфических задач

Подагенты — это специализированные работники, которые выполняют конкретную задачу в рамках своей сферы деятельности и отправляют результаты обратно главному агенту. Главный агент может делегировать задачи подагенту тестирования интерфейса, подагенту тестирования API и подагенту по вопросам безопасности. Каждый из них независимо исследует свою область, а главный агент объединяет их результаты в итоговый ответ.

Почему не использовать одного большого агента?

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

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

Навык против подагента

Навык описывает как следует выполнять работу, а подагент — кто выполняет его специализированную часть. Навык тестирования API определяет методологию организации. Подагент тестирования API берет конкретный API и анализирует его с использованием соответствующих инструкций и инструментов.

Подагенты и окно контекста

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

MCP и инструменты

Что такое MCP

MCP — это Model Context Protocol. Это механизм интеграции, с помощью которого агент взаимодействует с внешними системами и источниками данных. С одной стороны находится Claude Code, а с другой — GitHub, Jira, базы данных, API, браузеры и системы мониторинга. Это позволяет агенту выходить за рамки локальной среды программирования и взаимодействовать с системами, используемыми на протяжении всего жизненного цикла разработки.

Инженерия программного обеспечения редко ограничивается работой в редакторе. Разработчику могут понадобиться Jira для задач, GitHub для исходного кода и pull-запросов, базы данных для проверки, системы мониторинга для выявления ошибок в производственной среде и API для контроля поведения приложения. Благодаря MCP рабочий процесс может включать чтение задачи из Jira, изучение соответствующего репозитория, определение API, генерацию тестов, их выполнение и создание pull-запроса. Агент для программирования становится частью более широкого инженерного процесса.

MCP против инструментов

Это не одно и то же. MCP — это протокол или слой интеграции, а инструмент — это конкретная функция, которую может вызвать агент. Сервер MCP для Jira может предоставлять функции get_issue(), search_issues() и create_comment(). Эти функции являются инструментами, а MCP — способ их доступа. Короче говоря, MCP — это механизм подключения агента, а инструмент — то, что он может делать.

Какие инструменты предоставляются агенту

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

Виды инструментов

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

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

Вместе они позволяют системе наблюдать за своей средой, принимать решения, действовать и проверять результаты.

Хуки, команды и плагины

Хуки

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

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

Почему хуки важны в производственной среде

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

Команды

Команды — это явно запускаемые рабочие процессы, такие как /review, /test и /debug. Ввод команды /review намеренно запускает заранее определённый рабочий процесс ревью кода. Команда означает: «Я явно хочу запустить этот рабочий процесс».

Команды инициируются пользователем, в то время как хуки — событием. Ввод команды /test является явной командой. Изменение исходного кода и автоматическое выполнение тестов в ответ на это — пример автоматизации, основанной на событиях. Следовательно, команда запускается человеком, а хук — событием.

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

Плагины

Плагины собирают и распространяют расширения. Представьте организацию по тестированию, которая создала инструменты для тестирования API, тестирования безопасности, вспомогательные агенты для API и безопасности, механизмы верификации и интеграции с MCP. Вместо того чтобы каждый разработчик создавал эту среду заново, все компоненты поставляются вместе в виде одного плагина.

Именно поэтому плагины важны для корпораций. Они переводят практику проектирования с использованием агентов из категории личной продуктивности в категорию организационных возможностей. При отсутствии общей упаковки каждый инженер вынужден настраивать среду ИИ по-своему. Стандартный плагин может объединять стандарты проектирования, методы тестирования, специализированные агенты, правила автоматизации и интеграции, благодаря чему каждый проект получает идентичные возможности. С точки зрения архитектуры плагины относятся к уровню управления и стандартизации.

Как взаимодействуют компоненты

В одной компактной схеме каждому компоненту назначается определенная задача:

• CLAUDE.md знает детали проекта.
• Функции навыков определяют способы работы.
• Подагенты выполняют порученные специализированные задачи.
• Инструменты выполняют действия.
• MCP подключается к внешним системам.
• Хуки автоматизируют события жизненного цикла.
• Команды запускают рабочие процессы по требованию.
• Плагины упаковывают и распространяют функциональные возможности.

Claude Code находится посередине и координирует их действия. Они решают разные архитектурные проблемы и не являются взаимозаменяемыми функциями.

Один рабочий процесс от начала до конца

Возьмем требование «добавить покрытие тестами на регрессию для нового API оплаты». Вероятный ход выполнения выглядит следующим образом:

1. Требование. Claude Code получает запрос.
2. Контекст проекта. Файл CLAUDE.md содержит стандарты тестирования, команды, правила работы с репозиторием и требования к безопасности.
3. Выбор навыков. Навык тестирования API обеспечивает методологию организации.
4. Делегирование задач. Специализированные агенты анализируют функциональность API, проблемы безопасности и влияние регрессий.
5. Интеграции. Системы, подключенные через MCP, предоставляют доступ к соответствующим внешним платформам.
6. Инструменты. Claude Code читает код, ищет файлы, пишет тесты и выполняет команды.
7. Проверка. Функции-хуки выполняют проверку формата кода, форматирование, целевые тесты и другие проверки.
8. Подтверждение. Claude оценивает результаты и решает, требуется ли дальнейшая работа.
9. Итоговый результат. Агент возвращает тесты, их результаты, документацию и краткое описание выполненных действий.

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

Цикл агента

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

На практике процесс ближе к последовательности: контекст, действие, проверка, коррекция, снова проверка, затем завершение. Именно такая итерация отличает надежного агента от одноразовой генерации кода.

Проектирование среды тестирования ИИ

Мощная архитектура SDET в Claude Code может включать в себя:

• CLAUDE.md с фреймворками тестирования, описанием архитектуры, стандартами тестирования, правилами безопасности и критериями завершения работы.
• Навыки тестирования API, интерфейса, регрессионного тестирования и анализа сбоев.
• Подагентов для работы с интерфейсом, API, безопасностью и регрессионными тестами.
• Инструменты для поиска в репозиториях, редактирования файлов, выполнения команд и запуска тестов.
• Соединения MCP с GitHub, Jira, базами данных, API и системами мониторинга.
• Хуки, которые выполняют форматирование, проверку кода, тестирование и верификацию после внесения изменений.
• Команды вроде /api-test, /regression, /security-review и /debug.
• Плагин, объединяющий всё воедино, чтобы несколько инженерных команд могли его повторно использовать.

Оркестратор координирует эти компоненты в соответствии с требованиями.

Выбор подходящего механизма

Пять вопросов помогут определить подходящий элемент.

• Речь идет ли о знаниях, которые можно повторно использовать для выполнения задачи? Используйте Навык.
• Требуется ли специализированный, автономный работник? Используйте Подагента.
• Должен ли агент выполнять какую-либо операцию? Используйте Инструмент.
• Зависит ли действие от внешней платформы или источника данных? Рассмотрите MCP.
• Нужно ли что-то запускать автоматически каждый раз при возникновении события жизненного цикла? Используйте Хук.

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

Основной урок

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

• Контекст — чтобы агент мог понимать задачу.
• Навыки — для обеспечения возможности выполнения одинаковых действий.
• Делегирование — поскольку сложные задачи могут требовать специализированных исполнителей.
• Инструменты — чтобы агент мог действовать.
• Интеграция — для доступа к внешним инженерным системам.
• Автоматизация — чтобы обязательные процессы выполнялись надежно.

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

Упаковка — чтобы возможности можно было повторно использовать в разных командах.

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