Кто за что: MCP, фреймворк в агентном стеке

MCP агентный стек фреймворк чем отличается — вопрос, который я, Арина Михална, слышу всё чаще, и каждый раз люди имеют в виду что-то своё. Одни думают, что MCP это и есть фреймворк. Другие называют харнесом весь стек. Разложу это по полочкам: три слоя, три зоны ответственности, никакой каши.

Что такое MCP и за что он отвечает

MCP (Model Context Protocol) — это протокол, разработанный Anthropic. Не фреймворк, не библиотека, именно протокол: стандартизированный способ, которым модель подключается к внешним инструментам, данным и сервисам.

Представь розетку. Любой прибор с вилкой подходит к любой розетке стандарта. MCP работает так же: агент знает, как «воткнуть вилку» в любой MCP-сервер, и не важно, что внутри. Файловая система, база данных, GitHub, Slack — всё подключается через один протокол.

Что MCP делает конкретно:

• Предоставляет инструменты (Tools) — функции, которые агент может вызвать
• Предоставляет ресурсы (Resources) — данные, которые агент может читать
• Предоставляет промпты (Prompts) — готовые шаблоны инструкций

Что MCP не делает: он не управляет петлёй рассуждений, не хранит состояние между вызовами, не знает, в каком порядке агент будет вызывать инструменты. Это не его работа.

Что такое фреймворк и где живёт петля

Фреймворк — это оркестрация. Он отвечает за то, что происходит между вызовами модели и инструментов: петлю рассуждений (reasoning loop), память, маршрутизацию между агентами, условные переходы.

В 2026 году основные фреймворки:

Фреймворк	За что отвечает	Когда берут
LangGraph	Графы с циклами, параллельные ветки, сложная маршрутизация	Многошаговые задачи с условиями и откатами
PydanticAI	Строгая типизация, минимум магии, прямая работа с API	Когда нужен контроль и предсказуемость
AutoGen	Многоагентный чат, переговоры между агентами	Системы с несколькими специализированными агентами
Crew AI	Команды агентов с ролями и задачами	Бизнес-процессы с делегированием

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

Конкретный пример: ты просишь агента написать код, протестировать и задеплоить. LangGraph построит граф: узел «написать код» → узел «запустить тесты» → условие «тесты упали?» → если да, вернуться к узлу «исправить код», если нет — узел «деплой». MCP здесь только предоставит инструменты (запуск тестов, git push), но маршрут между ними — зона фреймворка.

Что такое харнес и зачем он нужен

Харнес (harness) — слой исполнения. Он оборачивает фреймворк и отвечает за то, что происходит снаружи: запуск, остановку, разрешения, логирование, восстановление после сбоя.

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

Что делает харнес:

• Управляет жизненным циклом агента (старт, пауза, рестарт)
• Держит разрешения: что агент может читать, писать, запускать
• Логирует действия и сохраняет трейсы для отладки
• Обрабатывает сбои: таймауты, падения модели, потерю соединения
• Персистирует состояние между запусками

Харнес не знает, как агент рассуждает (это работа фреймворка), и не знает, как устроены инструменты (это работа MCP). Он просто следит, чтобы всё это работало и не вылетало.

Кто владеет состоянием, инструментами и разрешениями

Здесь начинается путаница. Разложу по зонам ответственности:

Инструменты (Tools) — владеет MCP. Он предоставляет их агенту через стандартный интерфейс. Фреймворк вызывает инструмент, но не знает, как он устроен внутри. Харнес может ограничить доступ к инструменту (разрешения), но не управляет его логикой.

Петля (Loop) — владеет фреймворк. Он решает, в каком порядке вызывать инструменты, когда остановиться, когда повторить шаг. MCP про петлю ничего не знает. Харнес может прервать петлю (таймаут, сбой), но не управляет маршрутом.

Состояние (State) — владеют фреймворк и харнес вместе. Фреймворк хранит состояние внутри одной сессии (диалог, промежуточные результаты). Харнес персистирует состояние между сессиями (сохраняет в БД или файл).

Разрешения (Permissions) — владеет харнес. Он решает, может ли агент удалить файл, запустить команду, отправить деньги. Фреймворк и MCP про разрешения не думают: они предполагают, что харнес это уже проверил.

Восстановление (Recovery) — владеет харнес. Если модель упала, сеть оборвалась или агент завис — харнес откатывает транзакцию, сохраняет состояние и перезапускает. Фреймворк может помочь (чекпоинты внутри графа), но финальная ответственность — на харнесе.

Как выбрать фреймворк под задачу

Фреймворки не универсальны. У каждого своя ниша, и выбор зависит от того, какую задачу ты решаешь.

PydanticAI — когда нужна строгая типизация и контроль. Ты явно описываешь инструменты как Pydantic-модели, явно управляешь вызовами. Минимум магии, максимум предсказуемости. Подходит для продуктовых агентов, где нужно знать, что на входе и выходе.

LangGraph — когда нужны сложные графы с циклами и условиями. Агент, который пишет код, тестирует, исправляет ошибки и деплоит — это граф. LangGraph позволяет строить такие маршруты визуально и управлять переходами.

AutoGen — когда нужна многоагентная система. Один агент пишет код, второй ревьюит, третий тестирует. Они общаются друг с другом, переговариваются, приходят к консенсусу. AutoGen управляет этим чатом.

Crew AI — когда нужна команда с ролями. «Исследователь» собирает данные, «аналитик» делает выводы, «писатель» оформляет отчёт. Crew AI делегирует задачи и собирает результаты.

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

Нужен ли MCP, если у тебя уже есть фреймворк

Да, нужен. Но не всегда сразу.

Фреймворк может вызывать функции напрямую. Ты пишешь функцию read_file(path) на Python, регистрируешь её как инструмент в PydanticAI или LangGraph, и агент её вызывает. MCP здесь не нужен — всё работает внутри одного процесса.

MCP нужен, когда инструменты живут снаружи:

• Ты подключаешь сторонний сервис (GitHub, Slack, БД)
• Ты хочешь переиспользовать один MCP-сервер для разных агентов
• Ты строишь агента, который работает не только с твоим кодом, но и с чужими инструментами

Пример: ты делаешь агента для работы с проектами. Один MCP-сервер предоставляет доступ к GitHub (создать PR, прочитать issue). Другой — к Slack (отправить сообщение, прочитать канал). Третий — к твоей БД (запросы, обновления). Агент использует все три сервера через единый протокол. Фреймворк не знает, что внутри этих серверов — ему достаточно, что все говорят на MCP.

Если твой агент работает только с локальными файлами и не подключает сторонние сервисы — MCP можешь не трогать. Но как только захочешь стандартизировать подключение — он тебе понадобится.

Где в стеке живут безопасность и откаты

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

Конкретный пример: агент хочет удалить файл. MCP предоставляет инструмент delete_file(path). Фреймворк вызывает этот инструмент в нужной точке графа. Харнес перехватывает вызов, проверяет: а можно ли агенту удалять файлы? путь не ведёт за пределы проекта? это не системный файл? Если всё ОК — пропускает. Если нет — блокирует и возвращает ошибку.

Откаты (recovery) — тоже зона харнеса. Агент упал на середине задачи. Фреймворк может сохранить чекпоинт (текущий узел графа, состояние), но восстановить сессию и перезапустить агент — работа харнеса.

Что сломалось	Кто восстанавливает
Модель вернула ошибку (rate limit, таймаут)	Харнес — ретрай с бэкоффом
Инструмент вернул ошибку (файл не найден)	Фреймворк — обработка в графе или передача контроля агенту
Агент завис в бесконечной петле	Харнес — таймаут и остановка
Сбой сети или краш процесса	Харнес — восстановление состояния из персистентного хранилища

Харнес — это последняя линия защиты. Если он не справится, всё упадёт.

Практический кейс: агент на Claude Code

Разберу, как слои работают вместе на примере Claude Code (харнес) + LangGraph (фреймворк) + MCP (протокол).

Задача: агент должен прочитать issue на GitHub, написать код, протестировать и создать PR.

MCP-слой: три сервера — GitHub, filesystem, terminal. Каждый предоставляет свои инструменты:

• GitHub: read_issue(), create_pr()
• Filesystem: read_file(), write_file()
• Terminal: run_command()

Фреймворк (LangGraph): граф с узлами:

1. Прочитать issue (вызов read_issue())
2. Написать код (вызов write_file())
3. Запустить тесты (вызов run_command("pytest"))
4. Условие: тесты прошли?
   • Если нет → вернуться к узлу 2
   • Если да → узел 5
5. Создать PR (вызов create_pr())

Харнес (Claude Code): управляет запуском, держит разрешения (агент может писать только в папку проекта, не может запускать rm -rf), логирует действия, сохраняет состояние между сессиями. Если агент упал на узле 3 — харнес восстанавливает состояние и перезапускает с узла 3.

Все три слоя работают одновременно, но каждый делает своё. MCP не знает про граф. Фреймворк не знает про разрешения. Харнес не знает, как устроены инструменты. Это и есть разделение ответственности.

Какие проблемы решает разделение слоёв

Разделение на три слоя — это не академическая выдумка. Это решение реальных проблем, которые ломают агентов в продакшене.

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

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

Проблема 3: Агент упал, и нужно понять, где именно. Если всё в одном коде — ты копаешься в логах часами. Если слои разделены — ты видишь: сбой в MCP-сервере (инструмент вернул ошибку) или в фреймворке (граф завис) или в харнесе (таймаут).

Проблема 4: Нужно заменить модель. Если логика петли завязана на конкретный API — ты переписываешь всё. Если фреймворк абстрагирует модель — ты меняешь одну строку конфига.

По нашим замерам, агент с разделением слоёв восстанавливается после сбоя в среднем за 2 секунды против 30+ секунд для монолитного агента, который перезапускается с нуля.

По материалам: официальная документация Model Context Protocol, Agent Harness vs Agent Framework vs MCP — MarkTechPost, Building effective agents — Anthropic.

Читайте также

• ИИ-агент: что это в 2026 и чем отличается от чат-бота
• ИИ-агенты для бизнеса в 2026: где экономят
• Как собрать агента на Claude в 2026: пошаговый разбор архитектуры

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